At a Glance
Persona: Inventory Controller + Finance + Sysadmin + Auditor · Module: store-requisition · Workflow stages: off-path — oversight, GL verification, RBAC / workflow config, pre-commit void · Key permissions: read audit chain, configure workflow / RBAC / thresholds, admin-void of draft / in_progress, period-close signoff
What this persona does: Configures and oversees the SR lifecycle — variance monitoring, GL reconciliation, period close, RBAC, and pre-commit administrative void.
The Audit / Config persona covers four overlapping operational roles that together govern the SR module's correctness, completeness, and configuration: the Inventory Controller (oversees the SR flow end-to-end, monitors variance and partial-fulfilment patterns, reconciles inventory sub-ledger against GL postings, manages approval thresholds, signs off on period-end activity, and is the administrative-void authority for draft / in_progress SRs), the Finance Team (verifies cost-centre mapping and journal entries on completed SRs, reconciles outlet food-cost reports against SR postings, ensures cost allocation between departments is accurate at period close, and blocks closed-period commits via SR_VAL_014), the System Administrator (owns RBAC for create / approve / fulfil authority, the workflow stage configuration in tb_workflow, approval value thresholds, segregation-of-duties relaxations for low-value SRs, and the auto-create wiring from [recipe](/en/inventory/recipe)), and the Auditor (read-only review of SR history — per-line signatures, history JSON timelines, comment threads, linked inventory transactions, journal entries — to confirm controls are operating, variance is being investigated, and SoD is enforced). None of these roles act on the SR happy path; they act on the periphery — before any SR exists (config), during the flow (variance monitoring), and after commit (signoff, period close, audit trace). Two of them — Inventory Controller and System Administrator — hold the administrative-void authority (SR_AUTH_013) for pre-commit SRs; none can void a completed SR (corrections after commit flow through [inventory-adjustment](/en/inventory/inventory-adjustment)).
These roles act on the periphery of the SR lifecycle — before any SR exists (Sysadmin config), during the flow (Inventory Controller variance monitoring), and after commit (Finance signoff, Auditor trace). None advance the happy-path lifecycle; two hold administrative-void authority for pre-commit SRs.
| Action | Inventory Controller | Finance Team | System Administrator | Auditor |
|---|---|---|---|---|
| View SR at any status | ✅ (SR_AUTH_009) |
✅ (SR_AUTH_010) |
✅ | ✅ (read-only) |
View per-line signature chain and history JSON |
✅ | ✅ | ✅ | ✅ |
Monitor variance dashboard (requested − issued) |
✅ (SR_AUTH_009) |
✅ | — | ❌ |
Pre-commit administrative void (draft / in_progress → voided) |
✅ (SR_AUTH_013) |
❌ | ✅ (SR_AUTH_013) |
❌ |
Void completed SR |
❌ (SR_POST_010 — not allowed; use inventory-adjustment) |
❌ | ❌ | ❌ |
| Investigate and resolve Receiver discrepancy | ✅ | ✅ (GL side) | — | ❌ |
| Co-author inventory adjustment for post-commit correction | ✅ (SR_XMOD_009) |
✅ (verify GL balance) | — | ❌ |
Block closed-period commits (SR_VAL_014) |
— | ✅ (SR_AUTH_010) |
— | ❌ |
Configure workflow stages (tb_workflow) |
— | — | ✅ (SR_AUTH_014) |
❌ |
| Manage RBAC (assign / revoke roles per location) | — | — | ✅ | ❌ |
| Configure SoD-relaxation thresholds | — | — | ✅ | ❌ |
Wire recipe auto-create ([recipe](/en/inventory/recipe) → SR draft) |
— | — | ✅ | ❌ |
| Edit SR header / lines | ❌ | ❌ | ❌ | ❌ |
| Approve lines | ❌ | ❌ | ❌ | ❌ |
| Commit / issue goods | ❌ | ❌ | ❌ | ❌ |
ℹ️ Void scope: Administrative void (
SR_AUTH_013) is pre-commit only. AcompletedSR cannot be voided by any sub-role here — corrections flow through[inventory-adjustment](/en/inventory/inventory-adjustment)with the SRidas back-reference (SR_XMOD_009).
Entry points (one per sub-role):
completed SRs in a period with computed requested_qty − issued_qty (Section 3.2 of 02-business-rules.md), filterable by outlet, source location, requester, approver, and date range. Also: pre-commit SR queue (draft / in_progress SRs that look stale or anomalous).completed SRs in the current period, surfacing each SR's linked inventory transactions and the journal entries they generated; filterable by cost-centre, outlet, and date range. Also: period-close dashboard.tb_workflow configuration screen, approval-stage editor, RBAC matrix per location / department, SoD-relaxation thresholds, auto-create wiring (recipe → SR).workflow_history, per-line history JSON, inventory transactions, journal entries; signature trace by user / date / action.Primary flow (oversight / configuration, 10 steps — runs continuously across periods, not per-SR):
tb_workflow (e.g. Stage 1 = Department Head, Stage 2 = Operations Manager above value threshold); set user_action.execute defaults per stage; configure SoD-relaxation thresholds (e.g. "Approver = Fulfiller allowed for SRs < ฿5,000"); wire the auto-create source from [recipe](/en/inventory/recipe). Set per-location costing methods (the source's FIFO vs moving-average choice — owned by [costing](/en/inventory/costing) but referenced here).in_progress queue for: stale SRs (no action for > tenant SLA), anomalous patterns (chronic over-requesting from a specific outlet, chronic rejection from a specific approver), source-availability cascades (one outlet's SR blocking another's). Intervene by escalating to the workflow's next stage manually, or by administratively voiding a stuck SR (SR_POST_010).requested_qty − issued_qty gaps. Trace the cause: approver trim (look for the per-line approved_message), at-issue stock-out (look for the per-line system comment from the fulfiller), receiver discrepancy (look for the receiver's discrepancy comments). Decide whether the variance is a controlled outcome (chronic over-requesting that the outlet needs to address) or a system gap (source stock-out that needs supply-chain attention).SR_AUTH_013: draft → voided or in_progress → voided with a mandatory reason. No inventory or GL impact. Terminal.completed SR has linked inventory transactions and the journal entries they generated through the finance posting layer. Finance verifies: debit-side accounts (destination cost-centre expense for sr_type = issue, destination inventory for sr_type = transfer), credit-side accounts (source inventory), amounts (source cost_per_unit × issued_qty), and that Σ Dr = Σ Cr per SR_POST_007. Mismatches are escalated to the inventory controller and the source costing module.SR_VAL_014 automatically blocks new commits with a posting date in the closed period; Finance handles the operational case where a fulfiller needs to issue today against a closed-period date (escalation: either reopen the period, or shift the posting date forward).completed SRs in the period (per outlet, per cost-centre). Any unreconciled gap is investigated: the gap may be a missed adjustment, a mis-allocated dimension, an FX issue (if multi-currency tenants), or a timing issue (SR committed in one period with goods physically arriving in the next).created_by_id, Approver via approved_by_id per line, Fulfiller via last_action_by_id at the commit transition) shows SoD was enforced (Requester ≠ Approver per SR_AUTH_011, Approver ≠ Fulfiller per SR_AUTH_012); verify the per-line history JSON timeline matches the workflow_history and the comment threads; verify variance was investigated where material.completed SR is found to be wrong (post-commit), the correction flows through [inventory-adjustment](/en/inventory/inventory-adjustment), NOT through SR editing or void. The adjustment is co-authored: the Inventory Controller raises the adjustment with the corrective movement, Finance verifies the reversing journal entries balance, the Sysadmin may need to enable adjustment posting if the controlling thresholds block it. The original SR stays completed; the adjustment document carries a back-reference to the SR id.requested_qty − issued_qty is within the outlet's historical band. Inventory Controller closes the variance review with no action; logged for trend analysis.SR_POST_013) — Receiver posted a comment that physical receipt differs from issued_qty. Inventory Controller investigates source vs destination counts, decides on the corrective adjustment, and posts via [inventory-adjustment](/en/inventory/inventory-adjustment) with the SR id back-reference.in_progress past the SLA. Inventory Controller decides: (a) push the fulfiller to commit if the goods are physically issued but the system action was missed; (b) administratively void (SR_POST_010) if the SR is obsolete; (c) leave it and re-evaluate next period if the destination still needs the goods.SR_VAL_014 blocks. Finance decides: (a) reopen the period briefly (rare, requires CFO sign-off); (b) ask the Fulfiller to advance the posting date to the current period; (c) void the SR and raise a fresh one with a current-period date if the underlying transaction is no longer correct.[recipe](/en/inventory/recipe) module fails to generate a draft SR for a planned production event. Sysadmin investigates the wiring (recipe-product mapping, source-location resolution, requester-default user, location-permission check); ad-hoc fix posts the SR draft manually with info.recipe_id carried over.The Audit / Config persona's involvement does not "end" per SR — it is ongoing oversight. However, individual oversight actions have well-defined handoffs:
SR_AUTH_013 → SR_POST_010) — Inventory Controller / Sysadmin moves a draft or in_progress SR to voided; document terminates; the original requester is notified and may raise a replacement SR.[inventory-adjustment](/en/inventory/inventory-adjustment) with a back-reference to the SR; the SR itself stays completed.completed SRs in the period have valid journal entries and reconcile to outlet food-cost reports; Auditor reviews the signoff against the SR sample. No SR state changes; the period is locked, blocking further commits with posting dates in that period (SR_VAL_014).tb_workflow or RBAC change; new rules apply prospectively to subsequent SRs; existing in-flight SRs may need to be re-routed (the Sysadmin coordinates with Inventory Controller on the re-routing).The Audit / Config persona is the safety net of the SR module — they do not advance the happy-path lifecycle, but they intervene when the lifecycle goes wrong, configure the rails the other personas run on, and verify that the rails were followed at audit time.
voided (admin void)" anchor this persona's exits.../carmen/docs/store-requisitions/SR-Overview.md § User Roles → Manager row (which collapses Inventory Controller / Finance Manager / Sysadmin into a single "Manager" role with "View all SRs; access reports; manage settings"); this page disaggregates that role.../carmen/docs/store-requisitions/SR-User-Experience.md § Persona 4 (Finance Manager — Sarah Johnson) — carmen/docs source for the finance sub-role's cost-centre / journal-entry concerns.../carmen/docs/store-requisitions/Store Requisitions.md § UC-67 (Monitor Requisition Processing) — use-case source for the Inventory Controller's monitoring view.SR_VAL_014) gates the fulfiller's commit; Auditor verifies SoD between Approver and Fulfiller (SR_AUTH_012).[inventory-adjustment](/en/inventory/inventory-adjustment).tb_store_requisition.workflow_id (Sysadmin config), per-line signature columns (Auditor trace), dimension JSON for cost-centre allocation (Finance), enum_doc_status.voided (Inventory Controller / Sysadmin admin path).SR_VAL_014 (closed-period block — Finance owns), SR_AUTH_009–SR_AUTH_010 (Inventory Controller and Finance authority), SR_AUTH_011–SR_AUTH_012 (SoD rules — Auditor verifies), SR_AUTH_013 (admin void), SR_AUTH_014 (workflow-derived authorization — Sysadmin owns), SR_POST_010 (void posting effects), SR_POST_013 (Receiver discrepancy flag → Inventory Controller).