Receiving Behaviors
Manages the physical flow of materials into a facility from suppliers. Covers receiving orders against open purchase orders, lightweight receiving for organizations without a formal dock process, the receiving list view, and completing the purchase order lifecycle after all lines have been received.
PRO::RCV::0001 — Receive Shipment
Section titled “PRO::RCV::0001 — Receive Shipment”Process deliveries at the dock, marking items received and transitioning cards to FULFILLED so the kanban loop can close.
| Persona | Keisha Clerkson (Receiving Clerk) |
| Depends | PRO::PO::0004, RES::KC |
| Status | Proposed |
| Priority | MVP3 |
PRO::RCV::0001::0001.UC — Receive Shipment Against PO
Section titled “PRO::RCV::0001::0001.UC — Receive Shipment Against PO”The Receiving Clerk navigates to the Receiving page. The system displays POs and cards in IN_PROCESS state grouped by supplier. The clerk selects a PO (or individual lines within a PO) and clicks “Receive.” The system sends receive events to the associated cards, transitioning them from IN_PROCESS to FULFILLED. If all lines in the PO are received, the PO advances to RECEIVED. If only some lines are received, the PO remains in PARTIALLY_RECEIVED state until the remaining lines are processed.
Precondition: A PO exists in SUBMITTED or IN_PROCESS state. Cards associated with the PO are in IN_PROCESS state.
Postcondition: Received cards are in FULFILLED state. PO status reflects whether all lines were received (RECEIVED) or only some (PARTIALLY_RECEIVED). Fulfilled cards appear in the “Recently Received” tab.
PRO::RCV::0001::0002.UC — Record Receiving Against PO (Lifecycle Stub)
Section titled “PRO::RCV::0001::0002.UC — Record Receiving Against PO (Lifecycle Stub)”Lifecycle sub-use-case placeholder for recording receipt against a submitted purchase order. This stub reserves the identifier in the lifecycle taxonomy and documents that detailed interaction flows and API routes are not yet fully defined. The high-level behavior is described by PRO::RCV::0001::0001.UC; this entry tracks the outstanding specification work for the backend implementation of the receiving event pipeline.
PRO::RCV::0001::0003.UC — Release Card to Production
Section titled “PRO::RCV::0001::0003.UC — Release Card to Production”| Persona | Keisha Clerkson (Receiving Clerk), Irene Itemsworth (Inventory Manager) |
After materials have been received and verified, the card is released from the receiving area to the production floor. In the current implementation, this action is part of the View Procurement Queue “Fulfill” action, which transitions cards directly to FULFILLED without passing through a separate FULFILLING (in-transit) intermediate state. This skip is by design at this stage to simplify card management.
The physical side of this use case includes pairing the received card with the restocked bin, returning the bin to its shelf location, and confirming that the item is now available for use. This physical closure of the kanban loop — card back in the bin, bin back on the shelf — is the final step of the replenishment cycle. Future iterations may make the FULFILLING transition configurable to support facilities that need to track in-transit inventory between the receiving dock and the point of use.
PRO::RCV::0001::0004.UC — Receive Incoming Shipment (E2E)
Section titled “PRO::RCV::0001::0004.UC — Receive Incoming Shipment (E2E)”From the /receiving page “Receiving” tab, the clerk locates an item and uses the status dropdown to mark it as received. The system fires POST /event/fulfill for the associated card. The card transitions to FULFILLED. The item row moves from the “Receiving” tab to the “Recently Received” tab.
Precondition: The item appears in the “Receiving” tab with at least one card in IN_PROCESS state.
Postcondition: The card is in FULFILLED state. The item is visible in the “Recently Received” tab. The RES::KC card state machine has recorded the receive event (FS-CSM-003).
PRO::RCV::0002 — Lightweight Receiving
Section titled “PRO::RCV::0002 — Lightweight Receiving”A middle ground between full PO-based digital receiving and skipping receiving entirely via “Submit and Release.” Provides quick mark-as-received interactions without the overhead of the full receiving workflow.
| Persona | Keisha Clerkson (Receiving Clerk), Owen Ownerton (Business Principal) |
| Depends | PRO::PO::0004 |
| Status | Proposed |
| Priority | MVP3 |
PRO::RCV::0002::0001.US — Quick Mark-as-Received
Section titled “PRO::RCV::0002::0001.US — Quick Mark-as-Received”A simplified receiving path designed for organizations that want to record receipt but find the full PO-based receiving workflow too heavyweight for their operations. The interaction could be a scan-to-receive (scan a QR code on the package to mark the associated card as received) or a check-to-receive (check a box on the receiving list to mark a line as received without opening the full PO detail).
This sits between the two existing options — full PO-based receiving (PRO::RCV::0001::0001.UC) and skipping receiving entirely via “Submit and Release” (PRO::PO::0004::0002.UC) — and serves small teams that unbox deliveries themselves at a shared workstation without a dedicated receiving dock role.
PRO::RCV::0003 — View Receiving List
Section titled “PRO::RCV::0003 — View Receiving List”Browse orders pending receipt, grouped by supplier.
| Persona | Keisha Clerkson (Receiving Clerk) |
| Depends | GEN::LST::0001, GEN::LST::0003, GEN::LST::0004, GEN::LST::0006 |
| Status | Proposed |
| Priority | MVP3 |
PRO::RCV::0003::0001.UC — View Receiving List (Actor-Goal)
Section titled “PRO::RCV::0003::0001.UC — View Receiving List (Actor-Goal)”The Receiving Clerk navigates to the Receiving page. The system displays two tabs:
- Receiving: cards and PO lines in
IN_PROCESSstate, grouped by supplier. This tab shows what is expected to arrive or has recently arrived but not yet been confirmed. - Recently Received: cards that transitioned to
FULFILLEDwithin the last 24 hours, grouped by supplier. This tab provides a confirmation view for just-processed shipments.
Items in both tabs are searchable and filterable by item name, SKU, or supplier. Grouping by supplier makes it easy to batch-process all items from the same vendor when a shipment arrives.
Precondition: One or more POs have been submitted (associated cards are in IN_PROCESS state).
Postcondition: The actor has visibility into what is expected to arrive and what has recently been received.
PRO::RCV::0003::0002.UC — View Receiving List (E2E)
Section titled “PRO::RCV::0003::0002.UC — View Receiving List (E2E)”Load the /receiving page with both tabs visible. The page fires badge-refresh calls on load to update the sidebar badge count. The “Receiving” tab is active by default. A search bar is visible above the list. The page structure mirrors the Order Queue layout: tabs at the top, grouped items below, with supplier group headers.
PRO::RCV::0003::0003.UC — Switch Between Receiving Tabs (E2E)
Section titled “PRO::RCV::0003::0003.UC — Switch Between Receiving Tabs (E2E)”Toggle between the “Receiving” tab (showing REQUESTED and IN_PROCESS cards grouped by supplier) and the “Recently Received” tab (showing FULFILLED cards). Switching tabs does not clear any active search filter; the filter value is preserved and applied to the newly active tab’s content. This allows the clerk to search for a specific item name and then switch tabs to see if it has already been received.
PRO::RCV::0003::0004.UC — View Recently Received Items (E2E)
Section titled “PRO::RCV::0003::0004.UC — View Recently Received Items (E2E)”The “Recently Received” tab displays cards in FULFILLED state that were fulfilled within the last 24 hours, grouped by supplier. Each row shows: item name, SKU, receipt date and time, and quantity received. This view provides a same-day receipt confirmation record without requiring navigation to the full PO history. Items fulfilled more than 24 hours ago are no longer shown in this tab and must be found via the PO list view (PRO::PO::0002).
PRO::RCV::0004 — Complete Purchase Order
Section titled “PRO::RCV::0004 — Complete Purchase Order”Mark the final step of the procurement lifecycle after all items have been received.
| Persona | David Dealsworth (Purchasing Manager), Keisha Clerkson (Receiving Clerk) |
| Status | Proposed |
| Priority | MVP3 |
PRO::RCV::0004::0001.UC — Complete a Purchase Order (Lifecycle Stub)
Section titled “PRO::RCV::0004::0001.UC — Complete a Purchase Order (Lifecycle Stub)”Lifecycle sub-use-case placeholder for the completion step after all PO lines have been received. When a PO reaches RECEIVED state (all lines received), a completion step may be triggered to advance it to CLOSED or ARCHIVED. Detailed interaction flows, closure conditions, and the distinction between RECEIVED, CLOSED, and ARCHIVED states are not yet fully defined. This stub reserves the identifier and tracks the outstanding specification work.
Summary
Section titled “Summary”| Use Case | Scenarios | US | FS | UC |
|---|---|---|---|---|
PRO::RCV::0001 Receive Shipment | 4 | 0 | 0 | 4 |
PRO::RCV::0002 Lightweight Receiving | 1 | 1 | 0 | 0 |
PRO::RCV::0003 View Receiving List | 4 | 0 | 0 | 4 |
PRO::RCV::0004 Complete Purchase Order | 1 | 0 | 0 | 1 |
| Total | 10 | 1 | 0 | 9 |
Copyright: © Arda Systems 2025-2026, All rights reserved