At a Glance
Persona: Audit / Config (Auditor + System Administrator) · Module: inventory-adjustment · Workflow stages: Off-path observers — Sysadmin owns reason-code list (tb_adjustment_type), thresholds, RBAC, period config; Auditor reads the full adjustment dataset including soft-deleted compensating reversals · Key permissions: Sysadmin configures rules and thresholds; Auditor read-only (no document state writes)
What this persona does: Configures adjustment-module rules / thresholds / reason codes (Sysadmin); audits document trails and compensating-reversal chains (Auditor).
Both sub-personas are non-transactional — they do not raise, approve, edit, post, or void adjustment documents. Their work is on the boundaries: configuration (System Administrator) and read-only inspection (Auditor). Rows are derived from Section 2 (Entry Point and Primary Flow) of this file; rule citations refer to inventory-adjustment/02-business-rules § 4 (Authorization Rules) and § 5 (Posting Rules).
| Action | System Administrator | Auditor |
|---|---|---|
View all tb_stock_in / tb_stock_out (any status, incl. soft-deleted) |
✅ | ✅ (ADJ_AUTH_009) |
View workflow_history, last_action_by_id, approval signatures |
✅ | ✅ (ADJ_AUTH_009) |
| View attachments (photos, damage reports, recall notices) | ✅ | ✅ (ADJ_AUTH_009) |
| View inventory transaction and cost-layer effects | ✅ | ✅ |
| Export sensitive fields (cost-per-unit, vendor terms) | ✅ | ✅ (secondary-approval audit pattern) |
CRUD on tb_adjustment_type reason codes (ADJ_AUTH_008) |
✅ (ADJ_AUTH_008) |
❌ |
Set info.glAccount, info.requiresDocument, info.requiresQualityCheck |
✅ (ADJ_AUTH_008) |
❌ |
| Configure threshold ladder (auto-approve / Controller / Finance / SoD) | ✅ (ADJ_AUTH_008) |
❌ |
Manage tb_user_location scope and RBAC |
✅ | ❌ |
Define tb_workflow stages for adjustment documents |
✅ | ❌ |
SoD compliance check (ADJ_AUTH_010 — receiver ≠ adjuster) |
❌ | ✅ — flag violations in audit report |
Verify void chains (compensating reversal exists per ADJ_POST_004) |
❌ | ✅ — orphaned voids are hard-fail audit findings |
| Lot-recall trace (receipt → consumption → adjustment → void chain) | ❌ | ✅ — via shared tb_inventory_transaction join |
| Raise / approve / void adjustment documents | ❌ (ADJ_AUTH_008 — config only) |
❌ |
ℹ️ Configuration scope: System Administrator changes apply prospectively — new and future draft documents inherit the updated reason codes, thresholds, and workflow stages. Existing
draft/in_progressdocuments retain the config active at their submit time.completeddocuments are immutable and retain their reason-code snapshot per inventory-adjustment/01-data-model § 3.
ℹ️ Sensitive-field export: Single-Auditor export of cost-per-unit and joined vendor-pricelist data requires a secondary-approval step per the audit pattern. This is enforced at the platform layer, not within the adjustment module itself.
The Audit / Config persona group folds two carmen/docs roles — Auditor and System Administrator — that share the property of being non-transactional in the adjustment module. Neither raises, approves, edits, posts, nor voids adjustment documents; their work is on the boundaries of the transactional flow (read-only inspection, master-data configuration, integration).
Auditor responsibilities:
tb_stock_in / tb_stock_out documents across the property, including soft-deleted (deleted_at non-null), cancelled, and voided documents per ADJ_AUTH_009.info.glAccount mappings at the time of post — via cost-layer snapshot), attachments (photos, vendor RMAs, recall notices, supervisor sign-offs), approval signatures (workflow_history, last_action_by_id, last_action_at_date), journal entries (resolved via the inventory transaction → cost-layer ledger join → Finance subsystem), and void chains (compensating-reversal sequences per ADJ_POST_004).ADJ_AUTH_010 — flag cases where the same user appears as both receiver and adjuster for the same lot above the SoD threshold.tb_inventory_transaction join.System Administrator responsibilities:
tb_adjustment_type (reason codes) per ADJ_AUTH_008:
code, name, descriptiontype (stock_in or stock_out) — the direction filteris_active flaginfo.glAccount — GL account mapping that drives the post's journal entryinfo.requiresDocument — flag forcing attachment requirement per ADJ_VAL_010info.requiresQualityCheck — flag bypassing auto-approve and forcing Controller reviewADJ_AUTH_010.tb_user_location mapping — scopes which Store Keepers can act on which locations.tb_workflow rows referenced by tb_stock_in.workflow_id / tb_stock_out.workflow_id that drive the stage-by-stage approval routing.Neither role can post / approve / void / edit adjustment documents directly. Configuration changes apply prospectively (existing draft / in_progress documents inherit at-submit-time config; completed documents are immutable). Sensitive Sysadmin operations (reason-code GL-account change, threshold change) are audit-logged.
Entry points: Four doors into Auditor work on adjustments.
completed / voided adjustments in the period. Default filters: period, location, reason. Driven by external audit cycle.tb_stock_out write-offs in the period, flagging cases where the same user appears as both tb_good_received_note.created_by_id (receiver) and tb_stock_out.created_by_id (adjuster) for the same lot above the SoD threshold.Auditor primary flow (Adjustment Trail review for an audit window, 7 steps):
<period range>. The report aggregates: total stock-in cost (period), total stock-out cost (period), by reason, by location, by department, by user.workflow_history (stage-by-stage transitions with actor / timestamp), the resulting tb_inventory_transaction row(s) with cost-layer effects, and (for posted documents) the GL journal entries.ADJ_AUTH_010. Violations are flagged with the offending pair (receiver / adjuster IDs).voided document, confirm the compensating reversal exists per ADJ_POST_004 (look for a paired tb_stock_in / tb_stock_out with info.voidsAdjustmentId = <original>). Orphaned voids (status voided without compensating reversal) are flagged.Auditor secondary flow — Lot Recall Trace (4 steps):
lot_no and product_id.tb_stock_out_detail join via current_lot_no on the inventory-side), credit-note quantity adjustments, transfer-outs.Entry points: Four doors into Sysadmin configuration work for adjustments.
tb_adjustment_type reason codes. Exercised by the E2E spec 031-adjustment-type.spec.ts.tb_user_location, threshold-parameter overrides per user / department.tb_workflow definitions for adjustment documents (stage-by-stage approval routing).Sysadmin primary flow (add a new adjustment-type reason code, 7 steps):
code (e.g. INSURANCE_WRITE_OFF), name (display name), description, type (stock_out for write-offs), is_active = true.info JSON. Critical fields:
glAccount: the GL expense / loss account for the reason (e.g. 6535 — Insurance-claimable Losses).requiresDocument: typically true for insurance-claimable losses (need the claim reference / photos).requiresQualityCheck: typically true (bypass auto-approve to force Controller review).ADJ_VAL_001-equivalent (code uniqueness on tb_adjustment_type), info.glAccount resolves to a valid GL account, code-and-name non-empty.Sysadmin secondary flow — Threshold change:
Change auto-approve / Controller / Finance / SoD thresholds. Audit-logged. Applies prospectively at submit time — documents already at in_progress retain the threshold-routing they entered with; new submits use the new threshold.
ADJ_VAL_011 but historical instances may surface).info.glAccount correction); never repurpose an existing reason (would corrupt historical reporting).is_active = false hides the reason from new-document pickers but does not invalidate historical documents. Soft-delete (deleted_at) is more aggressive — used when the reason was created in error and should not appear in reporting; rare.The Audit / Config persona's involvement on a given adjustment / configuration ends at one of the following boundaries:
tb_adjustment_type row, threshold change, RBAC change, workflow change. Applies prospectively at submit; existing in-flight documents retain their original config. No handoff for the configuration itself; downstream personas (Store Keeper / Controller / Finance) inherit at next submit / approval.ADJ_POST_004 — but Sysadmin does not initiate those documents directly.tb_adjustment_type reasons and tb_user_location scope the Store Keeper picks from.info.glAccount mappings Finance verifies; Auditor reviews the period-end adjustment trail Finance signs off.tb_adjustment_type shape (Sysadmin CRUD target), tb_user_location (Sysadmin scoping target), tb_workflow reference, workflow_history JSON (Auditor primary read target).ADJ_AUTH_008 (Sysadmin configuration scope), ADJ_AUTH_009 (Auditor read scope), ADJ_AUTH_010 (SoD — Auditor primary verification target), ADJ_VAL_002 (reason-direction match — Sysadmin design constraint), ADJ_VAL_010 (requiresDocument flag), ADJ_POST_004 (void chain — Auditor primary verification target).INV_AUTH_008 (Sysadmin configuration scope spanning location-type / costing-method / period definitions in addition to adjustment-type), INV_AUTH_009 (Auditor read scope spanning all inventory data).ADJ_POST_006 on count commit) for reasonableness and SoD compliance.../carmen-inventory-frontend-e2e/tests/031-adjustment-type.spec.ts — the canonical Sysadmin CRUD spec for tb_adjustment_type; covers reason-code uniqueness, code-and-name validation, list / search / pagination, security cases.