At a Glance
Persona: Receiver (destination outlet representative) · Module: store-requisition · Scenarios: ~20
Categories: Happy Path · Permission · Validation · Edge Case
E2E coverage: manual / planned at this time; closest automated coverage is implicit intests/701-sr.spec.tsTC-SR-120001..120004 (Issuance) in../carmen-inventory-frontend-e2e/
This page captures the test scenarios that the Receiver persona (the destination outlet representative at the consuming outlet or destination warehouse) directly drives in the store-requisition module. The Receiver's involvement begins when an SR transitions to doc_status = completed (the Fulfiller has committed the issue at source and the linked inventory transactions have been written) and ends when the receipt is acknowledged in full or the discrepancy is resolved by the Inventory Controller via [inventory-adjustment](/en/inventory/inventory-adjustment). The Receiver has no commit authority on the SR — the SR is already terminal at completed when they pick it up; their role is verification, acknowledgement, and discrepancy signal-raising. Scenarios are grouped into happy paths (full match acknowledgement, multi-line full match, lot verification against linked inventory transaction, paired-GRN destination acknowledgement for inter-warehouse transfers), RBAC (Receiver at destination only, cannot edit SR, cannot post adjustments directly), validation (negative tests around discrepancy reporting completeness), and edge cases around short receipt, over receipt, wrong-lot delivery, damaged goods, late arrival vs expected_date, and the missing-on-arrival path. Cross-persona handoffs that pivot off the Receiver (Scenario 7 in the parent overview — discrepancy flag to Inventory Controller) live in 04-test-scenarios.md, not here.
| # | Scenario | Pre-condition | Steps | Expected |
|---|---|---|---|---|
| RCV-HP-01 | Full match acknowledgement on single-line SR | SR SR-A at doc_status = completed; sr_type = issue; destination Main-Kitchen; line: issued_qty = 10; physical delivery at the kitchen dock = 10 units, lot label matches the linked inventory transaction's tb_inventory_transaction_detail.lot_no. |
1. Receiver opens SR-A from the inbound queue. 2. Counts physical delivery = 10 units. 3. Inspects lot label, matches linked inventory transaction. 4. Appends user comment "received in full, condition good, lot 2026-04-Z matches" via tb_store_requisition_detail_comment. 5. Closes the SR view. |
SR remains doc_status = completed (no state change per SR_POST_013); a tb_store_requisition_detail_comment row is written on the line with the acknowledgement text and timestamp / user; the receipt is logged in the activity feed for audit; the Requester (often the same outlet manager in small operations) sees the acknowledgement; no other persona is notified. |
| RCV-HP-02 | Multi-line full match with lot verification | SR SR-B: three lines including two lot-controlled perishables; physical delivery matches issued_qty on every line and lots match the linked inventory transactions. |
1. Open SR-B. 2. For each line: count physical, inspect lot, write acknowledgement comment. 3. (Optional) Append a header-level acknowledgement comment summarising the receipt. |
Per-line _detail_comment rows for each acknowledgement; optional header-level tb_store_requisition_comment row; SR stays completed; the audit trail shows the Receiver's signature (via created_by_id on each comment) for every line. |
| RCV-HP-03 | sr_type = transfer destination on-hand verified |
SR SR-C: source WH-Central, destination WH-Pool; sr_type = transfer; line: issued_qty = 50; destination on-hand was incremented from 30 → 80 by the source-side commit. |
1. Receiver opens SR-C at WH-Pool. 2. Physically counts the delivery = 50 units. 3. Cross-checks tb_inventory_status[WH-Pool, product].quantity_on_hand = 80 (matches expected post-commit value). 4. Appends acknowledgement. |
The Receiver's role for transfer is verification that physical equals the system-side increment; on full match, the acknowledgement is logged; if the count differed from 50, the Receiver would flag a discrepancy (RCV-EDGE-01). |
| RCV-HP-04 | Paired-GRN destination acknowledgement for inter-warehouse transfer | Tenant uses the paired SR + GRN pattern for inter-warehouse transfers between legal entities; SR SR-D is completed at source; destination GRN GRN-D is in draft at the destination, pre-populated from SR-D with sr_no back-reference. |
1. Receiver opens GRN-D at destination (via the good-receive-note flow, not the SR flow). 2. Counts physical, records received_qty and accepted_qty per line, populates lot data on GRN-D. 3. Saves and commits GRN-D per the GRN flow. |
The SR-side acknowledgement is implicit in the paired GRN commit (which writes its own destination-side inventory transaction). The original SR SR-D stays completed; the link between SR and GRN is via sr_no in the GRN's description or info extension. Audit can trace the pair. Note: this scenario is governed by good-receive-note/04-test-scenarios-receiver; this entry is for completeness. |
| # | Scenario | Expected behaviour (allow/deny + reason) |
|---|---|---|
| RCV-PERM-01 | Receiver at destination outlet appends acknowledgement comment | Allow. Writing user comments on the SR header or its lines (via tb_store_requisition_comment / tb_store_requisition_detail_comment) is enabled for users with read access to the SR's to_location_id. The Receiver's role does not require write access to the SR's tb_store_requisition_detail columns — only the comment tables. |
| RCV-PERM-02 | Receiver at a different outlet attempts to acknowledge | Deny — destination scope. A Receiver at WH-North cannot acknowledge an SR whose to_location_id = Main-Kitchen. The SR detail is read-only for non-destination users by default (RBAC); the Add Comment action is hidden / disabled. Direct API call rejects with "You are not authorized to acknowledge requisitions delivered to Main-Kitchen." |
| RCV-PERM-03 | Receiver attempts to change doc_status or edit issued_qty |
Deny — Receiver scope. Receiver has no authority over doc_status or any column on tb_store_requisition_detail. The detail view is read-only on those fields; the only write surface is the comment tables. Per SR_AUTH_008. To correct an issued_qty mistake, the Receiver flags a discrepancy and the Inventory Controller posts an adjustment via [inventory-adjustment](/en/inventory/inventory-adjustment). |
| RCV-PERM-04 | Receiver attempts to void or cancel completed SR |
Deny — terminal state + Receiver scope. completed is locked across all personas (no completed → voided transition exists); the Receiver in particular has no void authority at any state. Post-commit corrections use inventory-adjustment. |
| RCV-PERM-05 | Receiver attempts to post inventory adjustment directly | Deny — adjustment authority. Inventory-adjustment posting is the Inventory Controller's right (Audit / Config persona), not the Receiver's. The Receiver flags the discrepancy via comment; the Inventory Controller decides on the adjustment. Per SR_XMOD_009 (post-commit corrections flow through inventory-adjustment, not through Receiver action). |
| # | Scenario | Trigger | Expected error |
|---|---|---|---|
| RCV-VAL-01 | Receiver flags discrepancy with empty comment | Receiver clicks Flag Discrepancy and submits without entering text. | Reject — comment body is required for discrepancy flags. Server returns "Discrepancy comment requires a description of the issue (e.g. received quantity vs expected, lot mismatch, damage)." |
| RCV-VAL-02 | Receiver flags discrepancy with the received quantity equal to issued_qty |
Receiver opens the discrepancy form but enters received = issued_qty (no actual gap). |
Warn — no discrepancy detected. UI surfaces a soft warning ("Received quantity matches issued quantity — is there still a discrepancy to flag? E.g. wrong lot, damaged goods?"). User confirms or amends. The comment may still be saved (e.g. flagging lot mismatch without quantity gap), but the system flags the entry as a non-quantitative discrepancy. |
| RCV-VAL-03 | Receiver attempts to flag discrepancy on a non-completed SR |
The SR is at doc_status = in_progress (still at fulfilment stage); Receiver tries to flag a discrepancy. |
Reject — premature. Server returns "Discrepancy flags are available only after the SR has been committed (doc_status = completed)." Receiver waits for the Fulfiller to commit; if the SR is stuck at in_progress past SLA, the Inventory Controller intervenes. |
| # | Scenario | Condition | Expected |
|---|---|---|---|
| RCV-EDGE-01 | Short receipt at destination (received < issued_qty) |
SR SR-E completed with issued_qty = 10 on line 1; physical delivery = 7 (3 short — possibly broken in transit, miscounted at source, or lost in transit). |
Receiver flags a discrepancy on line 1 via tb_store_requisition_detail_comment with: received_qty = 7, gap = 3, suspected cause, attached photo of broken cartons. SR stays completed. Inventory Controller is notified (config-dependent system event); investigates source vs destination counts; posts an inventory-adjustment to reconcile destination on-hand (the destination was already incremented by 10 at source-side commit for transfer, or charged for 10 at expense for issue — adjustment corrects by -3). |
| RCV-EDGE-02 | Over receipt at destination (received > issued_qty) |
Physical delivery = 12 when SR shows issued_qty = 10. |
Receiver flags an over-receipt discrepancy. Inventory Controller investigates: either (a) source records were wrong (source had 12 dispatched but recorded 10 — corrective adjustment increases destination on-hand by 2 and decreases source on-hand by 2 to match physical), or (b) physical delivery included pilferage-bound extras (less common). The SR stays completed; reconciliation via adjustment. |
| RCV-EDGE-03 | Wrong lot received | SR's linked tb_inventory_transaction_detail.lot_no = "Lot-A"; physical goods carry Lot-B label. |
Receiver flags wrong-lot discrepancy. For non-perishables this is often cosmetic (right product, wrong lot recorded); for perishables it matters because expiry tracking is broken. Inventory Controller decides: (a) lot-correction comment if the physical lot is in the source's records but was mis-recorded on this SR (no on-hand adjustment, just a lot-trace fix), or (b) full inventory-adjustment if the physical lot is from a different cost layer (cost-of-goods correction). |
| RCV-EDGE-04 | Damaged goods on arrival | Physical delivery arrived damaged in transit (carton crushed, container leaking). Quantity correct but condition unusable. | Receiver records the damage with photos and quantity affected. Two paths: (a) Accept and write off — Receiver accepts the goods at destination, the Inventory Controller posts an inventory-adjustment with reason damaged-on-arrival decreasing destination on-hand by the damaged quantity; (b) Refuse the damaged portion — Receiver refuses physically at the dock, the Inventory Controller coordinates with source / vendor / insurance for return logistics. SR stays completed either way; the damage handling lives in the adjustment / return process. |
| RCV-EDGE-05 | Late arrival vs expected_date |
SR SR-F expected_date = 2026-05-12; physical delivery arrived 2026-05-14 (2 days late). Production at the outlet was delayed. |
Receiver appends a comment noting the lateness; Inventory Controller may track chronic-lateness patterns for supply-chain review (which warehouse, which products, which route consistently arrives late). No state change on the SR; no adjustment needed unless there is also a quantity / quality issue. |
| RCV-EDGE-06 | Goods never arrived (missing-on-arrival) | SR SR-G completed 3 days ago; goods never arrived at destination; source records show dispatched, transit records show in-progress but no delivery. |
Receiver flags received_qty = 0 against non-zero issued_qty — a critical discrepancy. Inventory Controller initiates a search (transit records, alternate destination check, security review); failing recovery, posts a compensating loss adjustment at the destination via [inventory-adjustment](/en/inventory/inventory-adjustment) (the source was already debited at commit; the missing goods are a loss event, written off to the appropriate loss / shrinkage account by Finance). |
| RCV-EDGE-07 | Receiver = Requester (small outlet, one person wearing two hats) | Outlet Manager purchase@blueledgers.com is both Requester and Receiver for SR-H. They raised the SR, the Approver and Fulfiller acted, the SR committed, and the same user now acknowledges receipt. |
No SoD enforced between Requester and Receiver. The system does NOT block self-acknowledgement (SoD is between Requester / Approver and Approver / Fulfiller — not Requester / Receiver). The audit trail shows the same created_by_id on the initial draft and on the acknowledgement comment. Tenants concerned about this overlap may configure a workflow stage requiring a different user to acknowledge, but it is not a default. |
| RCV-EDGE-08 | High-volume receipts at end of shift | Receiver has 20 SRs to acknowledge at end of shift. | Bulk acknowledgement (if supported). Tenant config may provide a bulk-acknowledge action that appends the same comment template across multiple SRs; otherwise the Receiver works through them one by one. Either way, audit captures each acknowledgement separately. Discrepancy flags must always be per-SR (no bulk discrepancy). |
SR_AUTH_008 (Receiver scope: confirm receipt, flag discrepancies, no state change); Section 5 — SR_POST_013 (Receiver discrepancy flag does NOT move doc_status); Section 6 — SR_XMOD_009 (post-commit corrections via inventory-adjustment, not SR editing).../carmen-inventory-frontend-e2e/tests/701-sr.spec.ts — note: the canonical SR Playwright spec does NOT have a dedicated Receiver describe block; Receiver scenarios (RCV-HP-01..04, RCV-EDGE-01..08) are manual / planned at the time of writing. The closest automated coverage is the post-commit verification implicit in TC-SR-120001..120004 (Issuance) where the inventory transaction is checked, but the destination-side acknowledgement flow is not yet automated.id for audit.sr_type = transfer) was incremented at source-side commit; RCV-HP-03 verifies the system on-hand matches physical.