FLOW-0004 — Receiving You Can Trust

Deliveries are where paper meets reality: what the vendor claims arrived, what actually arrived, and what the order expected are three different numbers, and disputes live in the gaps between them. This scenario shows how one capture at the dock records all three separately, freezes them into a permanent record, and lets the order’s received amounts maintain themselves — so nothing is re-keyed, and a discrepancy is a five-minute comparison instead of an archaeology project.

Use cases traversed

This flow is a path across use cases, in order. Identifiers are the immutable prefix form defined in the naming convention; a flow is not a level-4 scenario.

Domains crossed: Receiving, Procurement.

Step	Use case	What happens
1	PRO::RCV::0003	The receiving list is viewed
2	PRO::RCV::0001	A shipment is received against the order
3	PRO::PO::0011	Quantities are validated against physical reality
4	PRO::RCV::0004	The purchase order is completed

The business value: shrinkage and vendor-dispute protection with zero duplicate data entry.

Actors and domains

• Keisha Clerkson — receiving. Captures the delivery and makes the accept/reject decision.
• David Dealsworth — procurement. Reads the order’s received amounts; never re-keys them.
• Vera Vendorson — the external supplier. Her packing slip is the stated claim the capture keeps, inert, next to what was actually counted.

The diagram conventions — the domain colors, the dependency ordering, and the arrow meanings — are those of the scenario catalog.

The scenario at domain level

The capture separates claims from facts

A receiving line records four things that ordinary systems blur into one number: what the order expected (an item version pin and quantity, frozen on the attribution when the line attaches), what the vendor stated on the packing slip (kept as an inert claim — never trusted arithmetic), what was accepted, and what was rejected with the reason why. The carrier that delivered is captured too, as a version pin into the reference data.

The carrier pin is deliberately ungated: receiving captures the carrier that actually showed up, retired or not — capture records reality, it doesn’t gate it.

The freeze makes the record permanent

Receive is the freeze. In one act the line’s accepted and rejected counts, the rejection reason, the captured facts, and the attribution actuals are written and become the permanent record — and the accepted goods are born as an inventory pool located at the dock, in the line’s custody until it releases them. The attribution’s actual is written exactly once, by the freeze itself, on receiving’s own record — receiving never posts to the order.

When Vera’s packing slip says ten and the count says eight, the frozen record holds both — her stated claim and the accepted and rejected counts with the reason — and that shared evidence is what protects both sides of the dispute.

The order reconciles itself

The received amounts on the order are maintained by nobody. As material distributes, receiving records production deliveries against the demand item; the Demand module announces each delivery; Orders listens and accrues the amount to every line that demand item services. Receiving is not a party to the wire, and no clerk ever types a received quantity into the order. Because the amounts derive from the delivery records, a missed announcement is repairable by re-reading them — the reconciliation is self-healing. (The announcement’s emission is designed but not yet wired up in the running system — see the Demand page.)

Where the behavior is specified

• Receiving — capture, the freeze, attributions, and the guarantees (accepted and rejected explicit; actuals written exactly once; delivery lists only grow).
• Orders — the received amounts and the computed Receiving view they drive.
• Demand — production deliveries and the accrual announcement.
• Inventory Items — pool birth and the one-custodian rule.