At a Glance
Module: purchase-order · Total scenarios: ~10 cross-persona + per-persona drill-downs across all personas · Personas covered: Purchaser, Procurement Manager, Vendor, Receiver, Finance, Audit / Config
Run order: Audit / Config setup → primary persona happy paths → cross-persona scenarios
Each persona's drill-down is04-test-scenarios-<role>.md
This page is the overview entry point for the test-scenario set of the purchase-order module. The PO lifecycle spans six personas — Purchaser, Procurement Manager, Vendor, Receiver, Finance, and Audit / Config — and test coverage is split accordingly: each persona has a dedicated file (linked in Section 3) that enumerates that persona's functional, authorization, validation, edge, and golden-journey scenarios. This overview file gives the global picture: who is in scope, what each persona's tests cover at the headline level, the cross-persona handoff scenarios that stitch the individual journeys into a complete end-to-end flow, and the mapping from each scenario back to the Playwright spec files that exercise it.
Scope of testing on the PO module covers four broad areas: functional coverage of every action available on the PO list, detail, create wizards (Blank, From Price List, From PR), edit mode, and post-approval toolbar; RBAC / authorization of who can perform each action at each state (Purchaser-only edit on draft, FC-only approval on in_progress, read-only for Sent/Completed); edge cases around empty data, no-permission users, save-without-items, dynamic skip when seed data is absent; and three-way match rules at PO ↔ GRN ↔ invoice handoff, which span the Receiver and Finance personas and are exercised primarily through the cross-persona scenarios in Section 4.
sent → partial → completed receipt-state transitions. No dedicated E2E spec yet — partial / final receipt behaviour is exercised through the cross-persona scenarios in Section 4.The scenarios below trace the PO across multiple personas. Each row anchors the handoff sequence to the document state at the boundary and the expected end state. They are derived from the handoff table in 03-user-flow.md Section 4.
| # | Scenario | Personas in order | Pre-condition | Expected end state |
|---|---|---|---|---|
| X-PO-01 | Full happy path (high-value, from PR) | Purchaser → Procurement Manager → Vendor → Receiver → Finance | Approved PR exists; high-value threshold applies; vendor reachable | completed (every line received; three-way match posted) |
| X-PO-02 | Manual PO (no PR linkage) | Purchaser → Procurement Manager → Vendor → Receiver → Finance | Vendor in catalogue; pricelist optional; no source PR | completed (manual flow; no PR consumed) |
| X-PO-03 | Partial receipt then final balance | Purchaser → Procurement Manager → Vendor → Receiver (partial GRN) → Receiver (second GRN) → Finance | PO sent; vendor delivers in two shipments |
completed via partial (state crosses sent → partial → completed) |
| X-PO-04 | Three-way match quantity discrepancy | Purchaser → Procurement Manager → Vendor → Receiver → Finance (flags) → Purchaser (resolve) | Invoice qty ≠ GRN qty for at least one line | Bounce-back to Purchaser; PO remains partial or completed until reconciled |
| X-PO-05 | Amendment cycle on Sent PO | Purchaser → Procurement Manager (approve amendment) → Vendor (re-transmit) | PO sent; vendor accepts amendment |
PO sent with revision history; vendor re-acknowledged |
| X-PO-06 | High-value rejection at final stage | Purchaser → Procurement Manager (reject) | PO in_progress at final stage; reason provided |
voided (workflow terminated; reason recorded) |
| X-PO-07 | Void mid-flight (no GRN posted) | Purchaser → Procurement Manager (void) | PO in_progress or sent; no GRN against any line; reason provided |
voided |
| X-PO-08 | Vendor decline after acknowledgement | Purchaser → Procurement Manager → Vendor (declines) | PO sent; vendor cannot fulfil |
Bounce-back to Purchaser (amend) or voided (cancel) |
| X-PO-09 | Close partial PO (vendor cannot supply remainder) | Purchaser → Procurement Manager → Vendor → Receiver (partial GRN) → Inventory Manager (close) | PO partial; outstanding balance treated as cancelled |
closed (remaining qty written as cancelled_qty) |
| X-PO-10 | Send-back during approval (item-level Review) | Purchaser → Procurement Manager (Send Back) → Purchaser (revise) → Procurement Manager (approve) | PO in_progress; one or more line items marked Review |
sent (after revise + re-approve) |
Three Playwright specs exist for the PO module under ../carmen-inventory-frontend-e2e/tests/. Only the Purchaser and Procurement Manager (FC Approver) personas have dedicated specs today. Vendor, Receiver, Finance, and Audit / Config persona files note "no dedicated E2E spec yet — see shared 401-po.spec.ts for general PO list coverage" and rely on the cross-persona scenarios in Section 4 to anchor expected behaviour for downstream automation.
401-po.spec.ts — General / shared coverageMixed-persona spec running both purchase@blueledgers.com (Purchaser) and requestor@blueledgers.com (no-PO-permission negative cases). Covers:
SKIP_NOTE_BACKEND / SKIP_NOTE_TIME (documented but not executable through the UI)Cross-persona coverage: X-PO-02 (manual PO entry point), X-PO-01 (PR-sourced PO entry point), general list/search/filter scenarios used by every downstream persona.
402-po-purchaser-journey.spec.ts — Purchaser personaRuns as purchase@blueledgers.com. Sourced from docs/persona-doc/Purchase Order/Purchaser/INDEX.md. Covers Steps 1–5 plus a Golden Journey (TC-PO-060101 through TC-PO-060901):
Cross-persona coverage: X-PO-01 (happy path PR-sourced), X-PO-02 (manual flow), X-PO-05 (amendment via edit mode), X-PO-07 (void via Close-without-receipt path), X-PO-09 (close partial).
403-po-approver-journey.spec.ts — Procurement Manager (FC Approver) personaRuns as fc@blueledgers.com. Sourced from docs/persona-doc/Purchase Order/Approver/INDEX.md. Covers Steps 1–3 plus a Golden Journey (TC-PO-070101 through TC-PO-070901):
IN PROGRESSAPPROVED / SENTCross-persona coverage: X-PO-01 / X-PO-02 (approval leg), X-PO-06 (high-value rejection), X-PO-07 (void via reject path), X-PO-10 (Send-Back during approval).
../carmen-inventory-frontend-e2e/tests/401-po.spec.ts../carmen-inventory-frontend-e2e/tests/402-po-purchaser-journey.spec.ts../carmen-inventory-frontend-e2e/tests/403-po-approver-journey.spec.ts