At a Glance
Persona: Outlet Manager (consuming location) · Module: store-requisition · Workflow stages: draft → in_progress (first approval stage; retract / amend on send-back) · Key permissions: create / edit / submit draft, withdraw draft, retract at first stage, amend after send-back
What this persona does: Raises the SR — picks source/destination + sr_type, adds lines with requested_qty, submits for approval, and amends on send-back.
The Requester persona is the Outlet Manager (kitchen, bar, banquet, restaurant) — the person at the consuming location who identifies stock needs and raises the requisition against a source warehouse or central store. The Requester owns the editable draft: they pick the source location and destination outlet, choose the movement type (sr_type = issue for direct-cost consumption pulls, sr_type = transfer for moves into another inventory-holding location), add product lines with requested_qty and a required date (expected_date), attach supporting notes (recipe demand snapshot, banquet event detail, par-level rationale), and submit the document for approval. On entry the requester is logged in with create-SR permission and is a member of tb_store_requisition.department_id; the requester is permitted to act between the chosen from_location_id and to_location_id. The SR states owned by this persona are draft (full edit rights) and a sliver of in_progress — the requester can retract their own SR while the workflow is still at the first approval stage and no approver has yet acted (SR_AUTH_004), and can amend / resubmit when an approver sends the document back for correction (the requester stage is re-entered via the workflow). Segregation of duties forbids the requester from approving their own SR (SR_AUTH_011) — the SR module enforces this at the approve action.
The Requester holds full edit rights at draft and re-enters in_progress only when an approver sends the document back for correction. Segregation of duties (SR_AUTH_011) forbids the Requester from approving their own SR — the module enforces this at the approve action.
| Action | draft |
in_progress (send-back only) |
completed |
cancelled / voided |
|---|---|---|---|---|
| Create SR | ✅ (SR_AUTH_001) |
— | — | — |
| Edit header (locations, dates, description, dimension) | ✅ (SR_AUTH_002) |
✅ send-back only | ❌ | ❌ |
Add / edit / delete lines (requested_qty) |
✅ (SR_AUTH_002) |
✅ send-back only | ❌ | ❌ |
| Attach supporting evidence (comments / attachments) | ✅ | ✅ | ❌ | ❌ |
Submit for approval (draft → in_progress) |
✅ (SR_AUTH_003) |
— | — | — |
| Resubmit after send-back | — | ✅ (SR_AUTH_003) |
— | — |
| Withdraw / cancel own draft | ✅ (SR_AUTH_004) |
✅ at first approval stage only (SR_AUTH_004) |
❌ | — |
| View SR (read-only) | ✅ | ✅ | ✅ | ✅ |
| Approve own SR | ❌ (SOD: Requester ≠ Approver per SR_AUTH_011) |
❌ | — | — |
ℹ️ Send-back loop: When an Approver sends the SR back for correction, the SR remains at
doc_status = in_progressbut theworkflow_current_stagereturns to the requester stage. The Requester amends and resubmits; already-approved lines are not reversed.
Entry point: Three paths into draft creation.
sr_type (issue or transfer); start adding line items.[recipe](/en/inventory/recipe) module computes ingredient quantities for an upcoming production / banquet event at the outlet and posts an SR draft for the requester to review; info.recipe_id carries the back-reference. The requester opens the pre-populated draft, adjusts quantities if needed, and continues from step 4 below.review_message per line; the requester re-enters the same workflow stage they originated, amends quantities / notes, and resubmits.Primary flow (happy path, 10 steps):
issue, or another inventory store for transfer).tb_store_requisition at doc_status = draft; sr_no is assigned per tenant numbering policy; requestor_id / requestor_name / department_id / department_name are populated from the logged-in user's profile.from_location_id (typically a tb_location.location_type = 'inventory' warehouse); destination is to_location_id (direct for sr_type = issue, inventory for sr_type = transfer). The screen surfaces the location-type / movement-type compatibility check from SR_VAL_003.sr_date (defaults to today), expected_date (the date the outlet needs the goods by — used for fulfilment prioritisation), description (free-text rationale: "weekly replenishment", "banquet event Friday", "emergency pull"), and the cost-dimension dimension JSON if the outlet splits across multiple cost-centres.requested_qty (in the product's UoM); the line writes one row to tb_store_requisition_detail. Repeat for each product needed.dimension JSON (per the unique index SRT1_*). Identical product+dimension is a duplicate (SR_VAL_007).tb_store_requisition_comment.attachments) or to individual lines (via tb_store_requisition_detail_comment.attachments).SR_VAL_009 source-availability check (per tenant config: hard block or soft warn) — for each line, current source on-hand minus reservations from other open SRs is shown; lines breaching the cap are flagged. The requester adjusts requested_qty or accepts the soft warning.SR_VAL_001–SR_VAL_009, sets doc_status = draft → in_progress, advances the workflow to the first approval stage, populates user_action.execute from that stage's permitted users (typically the requester's Department Head), writes the submitted entry into last_action / workflow_history, and appends a submit entry to each line's history JSON. The requester is notified that the SR is now under approval; the document is no longer editable from the requester's hands (except via send-back).SR_VAL_009 soft mode): the source on-hand is less than the requested quantity. The requester chooses to (a) reduce requested_qty to match the available stock, (b) submit anyway with the soft warning recorded (the approver will see the warning at approval time and decide whether to trim or approve as-is, accepting that the fulfiller may need to commit a partial), or (c) raise an additional SR against a different source location if multiple warehouses can supply the product.SR_VAL_009 hard mode): the submit is rejected. The requester must either (a) reduce requested_qty to within availability, (b) raise the SR against a different source, or (c) request the inventory controller to enable / widen the soft-warn config.product_id, each with its own dimension JSON (per the unique index SRT1_*). The two lines flow independently through approval and fulfilment.description flagged as emergency, sets expected_date to today / tomorrow, and may attach an emergency rationale memo; the approver and fulfiller see the urgency flag in their queues. There is no separate emergency_flag column on the schema — urgency is conveyed via description and info extension; the workflow may have an emergency-stage routing in tenant config.info.recipe_id as the back-reference.review_message per affected line. The requester sees the document in their queue at doc_status = in_progress but at the requester workflow stage; they may edit requested_qty or description, address the reviewer's note, and resubmit (which re-routes the document to the approval stage). Note: the requester cannot bypass an active send-back — they must respond.in_progress → cancelled per SR_AUTH_004) with a reason. Past that point, the requester must ask the approver to reject the document.The Requester's involvement on a given SR ends at one of four boundaries:
in_progress and held in the approver's queue; the requester is in monitor-only mode until either a send-back routes the document back or the approver's decision moves the workflow forward.review_message, edits as needed, and re-submits. This is a loop within in_progress, not a status change.in_progress → cancelled per SR_AUTH_004; document terminates; the requester may raise a new SR if the need persists.in_progress → cancelled automatic per SR_POST_004; the requester sees the document in cancelled with per-line reject_message explaining why; the requester may raise a revised SR with tighter quantities, different source, or additional justification.After successful commit by the fulfiller, the Requester is in observer / receiver-coordination mode: they may monitor the destination Receiver's acknowledgement and flag any discrepancy back to the Receiver. In small outlets the Requester and Receiver are often the same person wearing two hats; in larger operations the Requester focuses on demand planning while the Receiver handles physical receipt at the dock.
draft / in_progress / completed / cancelled / voided) on enum_doc_status, the global state machine that this persona's path traverses, and the cross-persona handoff table.../carmen/docs/store-requisitions/SR-User-Experience.md § Creating a Store Requisition — carmen/docs source for the requester (named "Alex Chen, Store Manager" in the persona narrative); journey steps map onto Section 2 above.../carmen/docs/store-requisitions/SR-Overview.md § User Roles → Requester row — carmen/docs source for the persona's responsibility scope.../carmen/docs/store-requisitions/Store Requisitions.md § UC-68 (Create and Manage Store Requisition) — use-case main success scenario for create / submit.issued_qty per line.enum_doc_status, enum_sr_type, and the tb_store_requisition_detail columns the requester writes (product_id, requested_qty, dimension).SR_VAL_001–SR_VAL_009 (submit-time gates the requester encounters), SR_AUTH_001–SR_AUTH_004 (the requester's authority scope), SR_AUTH_011 (Requester ≠ Approver SoD).draft for the requester to review and submit.