Consider direct vendor-to-receipt relationship (deferred)

Summary

During manual testing of receipt processing, the question arose: should receipts have a direct relationship to vendors, or is the indirect linkage through work orders sufficient?

Currently there is no vendor field on receipts. The only path to associate a vendor with a receipt is indirectly: receipt → work order → vendor.

Discussion

Arguments for keeping indirect-only (via work order):

• Simpler data model — no new FK on receipts table
• Enforces process discipline: every expense has context through a work order
• Avoids multiple paths to the same outcome
• Easier reporting and data reasoning

Arguments for adding direct vendor-on-receipt:

• Not every receipt originates from a work order (supply runs, one-off purchases)
• Users may think in terms of "I paid this vendor" not "I paid this work order"
• Enables direct querying: "show me everything I've paid Vendor X"

Decision

Deferred. The indirect path through work orders covers the primary use case. No action until beta testers surface a need for direct vendor-receipt linkage.

This issue exists to document that the relationship was considered and intentionally deferred — not overlooked.

Origin

Discovered while executing TC-REC-008 (Inline Vendor Creation during receipt processing) — that test case describes a feature that does not exist and should be reviewed.

This is a recorded decision, not an implementation task. Start by reviewing TC-REC-008, which the issue identifies as describing a nonexistent feature. Done means the test case is reviewed and the deferred vendor-receipt decision remains accurately documented.