The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.
| # | Surface | Action | Capability | Expected | Provenance |
|---|---|---|---|---|---|
| 1 | placeCheckout | Place the duplicate phone purchase containing two mugs and a single-use promotion, then leave it unpaid. | CAP-COM-ORD-005 | The placed purchase holds the inventory units and consumes the promotion use. | test services-commerce:modules/checkout/tests/e2e/holds-and-claims.e2e.spec.js#places one order with four lines, each purchase freezing its claims: the converted hold, the capacity claim, none, the lease |
| 2 | /console/{tenantId}/orders/{orderId} | Choose Void Order and enter Duplicate as the reason. | CAP-COM-ORD-008 | The purchase becomes voided and its history records the intervention reason. | test services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#answers 200 with the order voided, carrying the reason, its lines and the history |
| 3 | voidOrder | Allow the void work to release the purchase’s resources. | CAP-COM-ORD-008 | The mugs become available, the promotion use is released and the pro forma is removed. | test services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#released the participant’s claim, the ledger and the obligations |
| 4 | /console/{tenantId}/orders | Inspect the purchase in the Orders table. | CAP-COM-ORD-010 | It appears voided with no balance and does not count as unpaid. | test react-console:components/commerce/orders/__tests__/orders-list-screen.test.tsx#marks a voided order's balance as none rather than zero |
| Path | From step | Condition | Path taken | Outcome | Provenance |
|---|---|---|---|---|---|
| alternate | 2 | Staff leave the purchase unattended | The minute sweep clears it at the end of its tender window | The system records the void and performs the release | test services-commerce:modules/orders/tests/integration/services/orders/tender-window-sweeper.integration.spec.js#voided each in its own tenant: the reason tender_window_expired, the reservation released, the obligation cancelled, the history told by the system |
| alternate | 2 | The purchase has partial card and store-credit funding | Refund the card leg before crediting the invoice and restoring store credit | The funding is returned through its original paths without repetition | test services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#ran the plan through the adjustment worker: the card leg refunded under the void’s key, then the memo of the sale invoice |
| failure | 2 | A caller tries to void an already voided purchase | Reject the repeated void request | The purchase remains voided | test services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#refuses a second void, 409 order_not_voidable, and a read answers the order voided |
| Id | Statement | Provenance |
|---|---|---|
01 | Released inventory units and promotion usage are available to a subsequent buyer. | test |
02 | Accounting no longer retains the voided purchase’s pro forma invoice. | test services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#deletes the pro forma in Accounting and records it on the history |
03 | The refund plan returns each partial payment once. | test services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refunds nothing twice: a second void is 409, a re-run of the plan sends nothing and a replayed request answers the same plan |
End-to-end policy: optional: API evidence proves release and financial reversal; the console component tests cover the reason required by the void dialog.