At a Glance
Persona: Auditor + System Administrator · Module: vendor-pricelist · Workflow stages: off-path — observes Template / Campaign / Invitation / Pricelist chain; Sysadmin configures policy · Key permissions: audit/read across the chain + downstream PR/PO/GRN (Auditor); numbering, RBAC, portal-token policy, validation rules, token-revocation (Sysadmin)
What this persona does: Auditor verifies end-to-end procurement-pricing trail and SoD; Sysadmin owns numbering, RBAC, token policy, validation, integration, and audit retention.
The Audit / Config persona axis groups two distinct roles that both sit outside the transactional happy path of the vendor-pricelist module but are essential to its governance and operability. The Auditor is a read-only persona whose interest spans the end-to-end procurement-pricing chain — Template → Campaign → Invitation → Vendor Portal Submission → Pricelist Approval → downstream PR / PO / GRN consumption — and who uses each tier's activity log (tb_pricelist_template_comment, tb_request_for_pricing_comment, tb_request_for_pricing_detail_comment, tb_pricelist_comment, tb_pricelist_detail_comment), the application-derived campaign / invitation statuses (vendor-pricelist/02-business-rules § 5.2, § 5.3), the validation engine output stored in tb_pricelist.info.validation_results + quality_score, the portal-token telemetry written as system comments on the invitation row, and the cross-document bridges (PR pricelist_detail_id back-reference, PO snapshot, GRN variance entries) to verify policy compliance, segregation of duties (VPL_AUTH_014: Vendor ≠ Purchaser, high-value Purchaser ≠ Approver), validation-engine integrity, token-security posture (VPL_AUTH_007), and traceability from vendor quote through to invoiced position. The Auditor has no write surface in the module: cannot approve, reject, inactivate, edit detail rows, revoke tokens, or change configuration. The System Administrator is a configuration persona who owns the policy and integration surface for the module — pricelist numbering scheme that drives tb_pricelist.pricelist_no, the RBAC role-to-permission map for VPL_AUTH_001–VPL_AUTH_015, the portal-token policy (default expiration, IP allowlist defaults, concurrent-session limits, IP tracking), the email-integration wiring (SMTP / transactional-email provider, email-template registry, bounce handling), the validation-rule registry consumed by the validation engine (VPL_XMOD_009), the tenant FX rate source and currency-permitted list consumed by Finance (VPL_CALC_005, VPL_XMOD_008), the audit-log retention policy, and — when needed — the token-revocation right (VPL_AUTH_015) that immediately invalidates a vendor's portal access. Neither role is on the create-to-activate happy path; each has its own entry point, surface, and exit semantics: the Auditor exits via a generated report with no pricelist state change, the Sysadmin exits via a saved configuration (or a revoked token) that takes effect for new pricelists / campaigns / invitations while preserving snapshot semantics for those already in flight.
The two roles have separate entry points and flows; each is addressed below.
Entry point: Sidebar → Audit workspace → Pricelist Activity Queries (or, when starting from a known document, Sidebar → Vendor Management workspace → open a Template / Campaign / Pricelist → Activity Log tab / Related Documents tab). The Auditor lands on a query-builder surface scoped to the pricelist-tier document family (template / campaign / invitation / pricelist) plus the downstream cross-document chain (PR → PO → GRN → invoice), not on the Submitted-awaiting-review or Active Pricelists queues used by the Purchaser.
Primary flow (happy path — Auditor):
VPL_XMOD_005", "Quality-score distribution by vendor", "Token-revocation events", "Segregation-of-duties violations") or build an ad-hoc query against the comment tables, info JSON, and the cross-document bridges.created_at, submitted_at, effective_from_date, effective_to_date), vendor, currency, business unit, status (template status, derived campaign / invitation status, pricelist status), submission method, quality-score band, validation-failure category. Filter chips render above the result table; empty filter set is rejected to prevent unbounded scans.VPL_AUTH_014: vendor user holding token ≠ Carmen user approving; high-value Purchaser ≠ Approver), and that every transition has both an actor and a justification where required.VPL_AUTH_004/VPL_AUTH_005, a token revocation without a system comment justification, a quality_score < threshold approved without Manager review, a vendor portal access from a non-allowlist IP), flag the document in the audit case file with a note. Flagging does not change the pricelist — it writes to an audit-side store only.Entry point: Sidebar → Configuration workspace → Pricelist Numbering & Templates (for pricelist_no and campaign name schemes), Pricelist RBAC & Roles (for the VPL_AUTH_* role-to-permission map), Portal Token Policy (for default expiration, IP allowlist, concurrent-session limits, suspicious-activity thresholds), Email Integration Settings (SMTP / provider wiring, email-template registry, bounce handling), Validation Rule Registry (for the rules the validation engine runs at VPL_VAL_018–VPL_VAL_023 and VPL_XMOD_009), Currency & FX Sources (currency permitted list and FX rate source consumed by Finance), or Audit Retention Policy. Each surface is a separate page under the same workspace. In addition, the Sysadmin can exercise the per-invitation Revoke Token action from a single Campaign / Invitation page (this is the only place the Sysadmin touches a transactional document directly, per VPL_AUTH_015).
Primary flow (happy path — Sysadmin, configuration change):
pricelist_no under the new scheme. For email-integration changes the panel runs a connectivity probe. The Sysadmin can revise or discard the draft at this point.effective_from timestamp, records the change in the system-side configuration audit log (independent of the module-side comment tables), and notifies the affected user populations (e.g., Purchasers whose new pricelists will use a different numbering scheme; Finance whose FX rate source has been updated). Templates / campaigns / pricelists already in flight retain their original snapshot of the configuration in force at their respective state transitions — workflow stage chain, numbering, token policy, validation rule set, email template, FX source URL all preserved per the snapshot semantics that protect downstream PR / PO / GRN snapshots. New documents created after effective_from use the new configuration.tb_request_for_pricing_detail row. Confirm with the second-factor / step-up auth flow. The action writes tb_request_for_pricing_detail.pricelist_url_token = NULL and appends a system comment in tb_request_for_pricing_detail_comment capturing the reason and actor. The vendor's next portal access returns 401; auto-save drafts are preserved on the server side; the case can be re-routed by issuing a new invitation with a fresh token (the Purchaser's flow Step 4–5).VPL_AUTH_004/VPL_AUTH_005 rights, a multi-currency pricelist activated without Finance Manager co-signoff per VPL_AUTH_010, a portal token used from an unrecognised IP without justification, a quality_score < 70 auto-approved instead of routed to Manager review): the Auditor cannot act on the document in-module (read-only). The Auditor escalates via the audit case file — flags the document, attaches the evidence (activity-log excerpt, configuration version diff, validation-rule trace, segregation-of-duties pairing) — and routes the case to the responsible business owner (Purchasing Manager, Finance Manager, Compliance, or department head) for out-of-band remediation. If remediation requires a system-level action (e.g., inactivation under VPL_POST_019, fresh campaign launch, token revocation), that action is performed by the Purchaser / Purchasing Manager / Sysadmin under their respective authorization rights, not by the Auditor.effective_from.VPL_AUTH_015 is immediate; the vendor's next portal access returns 401. The draft pricelist in tb_pricelist (status = draft) is preserved on the server for audit and may be (a) soft-deleted by the Purchaser if the data is not salvageable, (b) re-routed through a fresh invitation to the same vendor under a separate campaign (the Purchaser launches the new campaign, the vendor receives a new token, fills in fresh), or (c) accepted as-is by the Purchaser uploading the partial draft as an email-method pricelist after vendor confirmation out-of-band. The configuration audit log records the revocation actor and reason.The Audit / Config persona axis exits in one of the following ways, depending on which role acted:
VPL_POST_019 under their authority; if it recommends a token revocation, the Sysadmin acts under VPL_AUTH_015.effective_from timestamp and recorded in the configuration audit log. Documents created after effective_from use the new configuration; documents already in flight retain their original snapshotted configuration. Notifications to affected user populations fire on save. Handoff is forward in time — the next Purchaser who creates a campaign / pricelist sees the new behaviour automatically.effective_from; documents created between the original change and the rollback are not retroactively re-evaluated (snapshot semantics), but new documents created after the rollback use the reverted configuration. The configuration audit log captures both the forward change and the rollback.tb_request_for_pricing_detail.pricelist_url_token = NULL write plus a system comment. Handoff is to the Vendor (loses portal access immediately) and to the Purchaser (notification — pursue re-issue if needed). Document state at handoff: invitation expired (effective immediately); any in-progress draft pricelist preserved at draft for the Purchaser's decision.Document state across all Audit / Config exits is governed by the three status enums (template draft / active / inactive, pricelist draft / active / inactive / expired) and the application-derived campaign / invitation statuses. The Auditor flow never moves a document across these; the Sysadmin's configuration flow never moves a document across these (only future documents are affected); the Sysadmin's token-revocation action moves the invitation to derived expired immediately but does not change the pricelist's status. The only pricelist status changes triggered by escalation from an audit finding are the inactivation (Purchaser under VPL_POST_019) and, where the Purchasing Manager decides to launch a fresh collection, the new pricelist's VPL_POST_015–VPL_POST_017 cycle.
VPL_AUTH_009 (Finance Officer read-only — same pattern the Auditor inherits in scope), VPL_AUTH_011 (Receiver read-only — same pattern), VPL_AUTH_012 (Sysadmin configures policy and integration), VPL_AUTH_013 (Auditor read-only across the chain), VPL_AUTH_014 (segregation of duties — verified by the Auditor in chain audit), VPL_AUTH_015 (token revocation — Sysadmin / Manager action).VPL_POST_017 / VPL_POST_018 / VPL_POST_019 (the transitions audited; the Sysadmin's elevated escalations on token revocation indirectly affect these via vendor access loss), VPL_POST_021 (auto-expire via cron — Sysadmin configures the cron schedule; Auditor verifies executions), VPL_POST_014 (invitation auto-expire — same).VPL_XMOD_009 (validation engine contract — Sysadmin configures the rule registry; Auditor verifies the engine actually ran them), VPL_XMOD_008 (currency master — Sysadmin's FX configuration; Auditor's cross-currency chain audit), VPL_XMOD_006 (product master — orphan hygiene reports audited).../carmen/docs/vendor-pricelist-management/VENDOR_MANAGEMENT_TECHNICAL_SPECIFICATION.md — RBAC matrix used in Section 2.2 and tied to the VPL_AUTH_001–VPL_AUTH_015 rule family.../carmen/docs/vendor-pricelist-management/requirements.md § Requirement 28 (Advanced Portal Session Management) — primary carmen/docs source for the portal-token policy surface (Section 2.2 step 2).../carmen/docs/vendor-pricelist-management/design.md § Phase 6 (Data Validation & Quality Control) — the validation-rule registry surface and quality_score computation that the Sysadmin configures and the Auditor verifies.