Procurement End-to-End Behaviors

View Interactive Prototype →

Cross-cutting procurement lifecycle scenarios that span multiple areas within the Procurement domain. These use cases cover full lifecycle verification, top-level business outcomes, the continuous improvement loop, and non-functional persistence requirements.

PRO::E2E::0001 — Order Lifecycle End-to-End

Verify the complete procurement lifecycle from item availability through receipt and fulfillment. A card traverses the full state sequence: AVAILABLE, REQUESTING, REQUESTED, IN_PROCESS, FULFILLED.

Persona	David Dealsworth (Purchasing Manager), Keisha Clerkson (Receiving Clerk), Owen Ownerton (Business Principal)
Depends	PRO::OQ, PRO::PO, PRO::RCV
Status	Proposed
Priority	MVP3

PRO::E2E::0001::0001.UC — Full Lifecycle from Items to Receiving

The scenario exercises three application pages in sequence — Items, Order Queue, and Receiving — and confirms that sidebar badge counts update correctly at each state transition. Starting from the Items page, a user with at least one Kanban Card in AVAILABLE or FULFILLED state clicks “Add to cart” on an item. The system fires POST /event/request, the card transitions to REQUESTING, and the Order Queue badge increments.

On the Order Queue page, the Purchasing Manager locates the card in the “Ready to Order” tab, accepts it (transitioning to REQUESTED), and then starts processing (transitioning to IN_PROCESS). The card moves from the “Ready to Order” tab to the “Recent Orders” tab. Finally, the Receiving Clerk navigates to the /receiving page, selects the card from the “Receiving” tab, and marks it as received. The system fires POST /event/fulfill, the card transitions to FULFILLED, and the item moves to the “Recently Received” tab.

Acceptance criteria include correct badge increments at each step, correct tab placement after each transition, and the card appearing in the “Recently Received” tab after fulfillment.

PRO::E2E::0002 — Business Outcome

Top-level business outcomes: the procurement loop prevents stockouts and replaces memory-based communication of supply needs. These are not discrete use cases but the motivating value propositions that the entire procurement lifecycle delivers.

Persona	Owen Ownerton (Business Principal)
Status	Proposed
Priority	MVP3

PRO::E2E::0002::0001.US — Avoid Workflow Interruptions from Missing Consumables

This scenario captures the top-level business outcome that the procurement loop delivers. Before the system, shop floor workers would halt work when a bin ran empty and wait for someone to notice and reorder. With the kanban-driven procurement loop, the replenishment signal is triggered at the moment stock is consumed, not after work has already stopped.

The measurable result is fewer workflow interruptions caused by missing consumables, shorter average lead times between the reorder trigger and restocking, and greater team confidence that materials will be available when needed. This outcome is realized by the combination of all other procurement use cases; this scenario exists to anchor the feature set to a concrete business justification.

PRO::E2E::0002::0002.US — Replace Memory-Based Communication of Supply Needs

The card-based queue replaces verbal and memory-based communication of supply needs. Without the system, a shop floor worker who opened the last unit of a consumable had to remember to tell the purchasing manager before the end of their shift. Communication failures, shift changes, and competing priorities regularly caused this message to be lost.

With the system, scanning or clicking to add a card to the queue creates a durable, visible record of the supply need. The purchasing manager sees it in the Order Queue the next time they review orders, regardless of whether the original worker is still present. This scenario motivates the always-visible Order Queue badge count and the durability guarantees of the optimistic-UI persistence model.

PRO::E2E::0003 — Continuous Improvement Loop

When a wrong SKU is ordered, a pack-size mismatch causes an over-order, or a supplier URL is stale, the correction should happen at the point of error and persist for all future orders.

Persona	Owen Ownerton (Business Principal)
Depends	PRO::PO::0009
Status	Proposed
Priority	MVP3

PRO::E2E::0003::0001.US — Fix It Once, Fixed Forever

When David notices that the system has the wrong vendor SKU for an item while preparing an order, the ideal behavior is to correct the Item or ItemSupply record immediately so that all future orders inherit the fix. This scenario extends the Data Propagation use case (PRO::PO::0009), which pushes upstream entity changes into open PO fields, to cover the broader “fix at point of error” correction loop.

Concretely: if David notices a wrong URL on an order line while reviewing a PO draft, he should be able to navigate to the ItemSupply record, correct the URL, and have that correction reflected in the current PO (via update propagation) and in all subsequent orders that draw from the same ItemSupply record. The value of the system compounds over time as data quality improves with each correction.

PRO::E2E::0004 — Instant Persistence

Changes made during a replenishment trigger must be saved instantly and reliably. The user needs confidence that the system will follow through even if they immediately switch back to physical work.

Persona	Sam Scansworth (Shop Floor Worker)
Status	Proposed
Priority	MVP3

PRO::E2E::0004::0001.FS — Optimistic UI with Background Persistence

This is a cross-cutting non-functional requirement applicable to all procurement interactions. When Sam scans a QR code and taps “Add to order queue,” he should receive immediate visual confirmation (toast notification, badge increment) and be able to put down his phone within one second without risking that the action was lost. The system must optimistically update the UI state while persisting to the backend in the background.

If the background persist fails, the system must surface a recoverable error with a retry option rather than silently losing the action. The scenario also implies conflict resolution: if the same card is added by two users concurrently, the system should handle the duplicate gracefully (idempotent request event) rather than producing a corrupted card state. This requirement influences the design of all order queue entry points.

Summary

Use Case	Scenarios	US	FS	UC
PRO::E2E::0001 Order Lifecycle End-to-End	1	0	0	1
PRO::E2E::0002 Business Outcome	2	2	0	0
PRO::E2E::0003 Continuous Improvement Loop	1	1	0	0
PRO::E2E::0004 Instant Persistence	1	0	1	0
Total	5	3	1	1

---