--- id: ATS-COM-ORD-008 scope: CAP-COM-ORD-008 product_area: commerce module: orders revision: 2 status: proposed approved_by: null approved_at: null source_sha: services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b macroservice-libraries: 54536a441935c6e09fdb7f96f0bec71c52ba4e03 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f scenarios: - id: ATS-COM-ORD-008-01 title: Void authority includes a mandatory bounded reason level: api proves: - BR-CAP-COM-ORD-008-01 preconditions: 'Fixtures provide reader, portal and administrator contexts.' steps: - do: 'Attempt voiding in each context and test missing, excessive and valid reasons.' provenance: test source: >- services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#refuses a reader without commerce.orders.void, 403 permission_missing, and a portal member the route expected: >- Unauthorized contexts fail, invalid reasons return 400 and the valid administrator request records its reason. negative: true data_needs: Use the controlled records and transports established by the cited tests. bound_to: - >- services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#refuses a reader without commerce.orders.void, 403 permission_missing, and a portal member the route - >- services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#refuses a void without a reason, 400 naming it - >- services-commerce:modules/orders/tests/unit/orders/void-request.spec.js#refuses a reason of 501 characters saying the limit, not that it is missing - TST-COM-ORD-032 - TST-COM-ORD-137 provenance: test source: >- services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#refuses a reader without commerce.orders.void, 403 permission_missing, and a portal member the route category: permission expected_provenance: test expected_source: >- services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#refuses a reader without commerce.orders.void, 403 permission_missing, and a portal member the route - id: ATS-COM-ORD-008-02 title: An already cleared or accepted order cannot be voided level: api proves: - BR-CAP-COM-ORD-008-02 preconditions: One order is voided and another is accepted. steps: - do: Request an independent void for each. provenance: test source: >- 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 expected: The response is order_not_voidable and leaves the state unchanged. negative: true data_needs: Use the controlled records and transports established by the cited tests. bound_to: - >- 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 - TST-COM-ORD-032 provenance: test source: >- 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 category: validation expected_provenance: test expected_source: >- 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: ATS-COM-ORD-008-03 title: Clearing a sale releases its resources level: api proves: - BR-CAP-COM-ORD-008-03 preconditions: The order commits a scarce resource and capacity claim. steps: - do: 'Void it and inspect the application, ledger, obligations and events.' provenance: test source: >- services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#released the participant’s claim, the ledger and the obligations expected: 'Claims and reservations release, pending work cancels and the order retains release history.' negative: false data_needs: Use the controlled records and transports established by the cited tests. bound_to: - >- services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#released the participant’s claim, the ledger and the obligations - >- services-commerce:modules/checkout/tests/e2e/holds-and-claims.e2e.spec.js#releases a placed order’s committed claims on void, cancels its pending obligations and leaves claims_released on its history - TST-COM-ORD-032 - TST-COM-ORD-029 provenance: test source: >- services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#released the participant’s claim, the ledger and the obligations category: transition expected_provenance: test expected_source: >- services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#released the participant’s claim, the ledger and the obligations - id: ATS-COM-ORD-008-04 title: Released code use can be redeemed again level: api proves: - BR-CAP-COM-ORD-008-04 preconditions: Placement consumed the only permitted code use. steps: - do: Void the order and inspect the redemption and counters. provenance: test source: >- services-commerce:modules/orders/tests/integration/services/placement/promotion-placement.integration.spec.js#voids the order and releases its redemption with order_voided expected: The redemption is released with order_voided and both use counters are restored. negative: false data_needs: Use the controlled records and transports established by the cited tests. bound_to: - >- services-commerce:modules/orders/tests/integration/services/placement/promotion-placement.integration.spec.js#voids the order and releases its redemption with order_voided - >- services-commerce:modules/orders/tests/integration/services/placement/promotion-placement.integration.spec.js#gives both counters back - TST-COM-ORD-110 provenance: test source: >- services-commerce:modules/orders/tests/integration/services/placement/promotion-placement.integration.spec.js#voids the order and releases its redemption with order_voided category: transition expected_provenance: test expected_source: >- services-commerce:modules/orders/tests/integration/services/placement/promotion-placement.integration.spec.js#voids the order and releases its redemption with order_voided - id: ATS-COM-ORD-008-05 title: Void records invoice clearing after commitment level: api proves: - BR-CAP-COM-ORD-008-05 preconditions: A placed order has an issued unpaid pro forma. steps: - do: Void it and inspect Accounting and order events. provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#deletes the pro forma in Accounting and records it on the history expected: The provisional invoice is deleted and the history records the Accounting result. negative: false data_needs: Use the controlled records and transports established by the cited tests. bound_to: - >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#deletes the pro forma in Accounting and records it on the history - TST-COM-ORD-075 provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#deletes the pro forma in Accounting and records it on the history category: failure expected_provenance: test expected_source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#deletes the pro forma in Accounting and records it on the history - id: ATS-COM-ORD-008-06 title: A partially funded void refunds before crediting level: unit proves: - BR-CAP-COM-ORD-008-06 preconditions: A fifty-dollar sale holds twenty dollars card money and ten dollars credit. steps: - do: Assemble the void refund plan including unreadable-payment cases. provenance: test source: >- services-commerce:modules/orders/tests/unit/orders/void-refund.spec.js#refunds the paid part of a part-paid order before the memo of its line is cut expected: >- The card refund precedes the memo, credit returns through its own treatment and unreadable legs are escalated. negative: false data_needs: Use the controlled records and transports established by the cited tests. bound_to: - >- services-commerce:modules/orders/tests/unit/orders/void-refund.spec.js#refunds the paid part of a part-paid order before the memo of its line is cut - >- services-commerce:modules/orders/tests/unit/orders/void-refund.spec.js#plans a store-credit part by the memo alone, and the card part refunded before it - >- 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 - >- services-commerce:modules/orders/tests/integration/services/orders/void-refund.integration.spec.js#raises adjustment_failed on the tender for a person, and records the leg as unresolved - TST-COM-ORD-136 - TST-COM-ORD-075 - TST-COM-ORD-097 provenance: test source: >- services-commerce:modules/orders/tests/unit/orders/void-refund.spec.js#refunds the paid part of a part-paid order before the memo of its line is cut category: rule expected_provenance: test expected_source: >- services-commerce:modules/orders/tests/unit/orders/void-refund.spec.js#refunds the paid part of a part-paid order before the memo of its line is cut - id: ATS-COM-ORD-008-07 title: Adjustment replay does not send another refund level: api proves: - BR-CAP-COM-ORD-008-07 preconditions: A partial-payment void already has a completed adjustment. steps: - do: 'Request another void, replay the adjustment and request its plan again.' provenance: test source: >- 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 expected: The independent void is refused and replay sends no further payment command. negative: true data_needs: Use the controlled records and transports established by the cited tests. bound_to: - >- 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 - TST-COM-ORD-075 provenance: test source: >- 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 category: invariant expected_provenance: test expected_source: >- 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 - id: ATS-COM-ORD-008-08 title: Expired pay-now windows are cleared in bounded batches level: api proves: - BR-CAP-COM-ORD-008-08 preconditions: 'Workspaces contain expired and live pay-now orders, terms orders and accepted orders.' steps: - do: Run window processing repeatedly with a small limit. provenance: test source: >- 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 expected: >- Expired placed orders are voided in window order with invoice clearing while unrelated states remain intact. negative: false data_needs: Use the controlled records and transports established by the cited tests. bound_to: - >- 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 - >- services-commerce:modules/orders/tests/integration/services/orders/tender-window-sweeper.integration.spec.js#left the live, the terms, the accepted and the already voided orders as they were - >- services-commerce:modules/orders/tests/integration/services/orders/tender-window-sweeper.integration.spec.js#takes at most the limit, oldest window first, and leaves the rest to the next run - TST-COM-ORD-096 provenance: test source: >- 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 category: transition expected_provenance: test expected_source: >- 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 - id: ATS-COM-ORD-008-09 title: Void recovery joins money and released resources level: api proves: - AS-JNY-COM-ORD-004-01 - AS-JNY-COM-ORD-004-02 - AS-JNY-COM-ORD-004-03 preconditions: 'Orders combine holds, a single-use offer and partial payment.' steps: - do: Clear them with recorded reasons. provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#deletes the pro forma in Accounting and records it on the history expected: >- The demonstrated components release resources and uses and return each captured payment without duplicate commands. negative: false data_needs: Use the controlled records and transports established by the cited tests. bound_to: - >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#deletes the pro forma in Accounting and records it on the history - >- 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 - >- services-commerce:modules/orders/tests/integration/services/placement/promotion-placement.integration.spec.js#gives both counters back - TST-COM-ORD-075 - TST-COM-ORD-110 provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#deletes the pro forma in Accounting and records it on the history category: interaction expected_provenance: test expected_source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#deletes the pro forma in Accounting and records it on the history - id: ATS-COM-ORD-008-10 title: A payment deadline crosses midnight by elapsed minutes category: boundary level: unit proves: - BR-CAP-COM-ORD-008-09 preconditions: Placement occurs thirty minutes before the fixture’s next-day deadline. steps: - do: Calculate the thirty-minute deadline. provenance: test source: >- services-commerce:modules/orders/tests/unit/placement/tender-window.spec.js#ends a thirty-minute window across midnight UTC on the next day expected: The result is on the next UTC day with the original millisecond precision. negative: false data_needs: Use an isolated workspace with the records and responses named in the preconditions. bound_to: - >- services-commerce:modules/orders/tests/unit/placement/tender-window.spec.js#ends a thirty-minute window across midnight UTC on the next day - TST-COM-ORD-140 provenance: test source: >- services-commerce:modules/orders/tests/unit/placement/tender-window.spec.js#ends a thirty-minute window across midnight UTC on the next day expected_provenance: test expected_source: >- services-commerce:modules/orders/tests/unit/placement/tender-window.spec.js#ends a thirty-minute window across midnight UTC on the next day - id: ATS-COM-ORD-008-11 title: Expired payment actions retain the permitted void action category: permission level: browser proves: - BR-CAP-COM-ORD-008-10 preconditions: Order detail receives an unpaid pay-now order whose deadline has passed. steps: - do: Render with payment and void authority. provenance: test source: >- react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows neither once the tender window has passed, except Void Order expected: Take Payment is absent and Void Order remains visible. negative: true data_needs: Use an isolated workspace with the records and responses named in the preconditions. bound_to: - >- react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows neither once the tender window has passed, except Void Order - TST-COM-ORD-017 provenance: test source: >- react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows neither once the tender window has passed, except Void Order expected_provenance: test expected_source: >- react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows neither once the tender window has passed, except Void Order - id: ATS-COM-ORD-008-12 title: A void retains its domain result when invoice clearing fails category: interaction level: api proves: - BR-CAP-COM-ORD-006-01 - BR-CAP-COM-ORD-008-05 preconditions: A placed order links an issued pro forma. steps: - do: 'Void while Accounting cannot delete it, then read the sale and history.' provenance: proposed source: - >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#billed the order at placement: billed, placed, one pro forma sale invoice linked under the first bill key, the line carrying its invoice line - >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#deletes the pro forma in Accounting and records it on the history expected: The sale stays voided with the deletion outcome recorded for review. negative: false data_needs: Use an isolated workspace with the records and responses named in the preconditions. bound_to: [] provenance: proposed source: - >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#billed the order at placement: billed, placed, one pro forma sale invoice linked under the first bill key, the line carrying its invoice line - >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#deletes the pro forma in Accounting and records it on the history exercises: - CAP-COM-ORD-008 - CAP-COM-ORD-006 related_capabilities: - CAP-COM-ORD-006 expected_provenance: proposed expected_source: - >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#billed the order at placement: billed, placed, one pro forma sale invoice linked under the first bill key, the line carrying its invoice line - >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#deletes the pro forma in Accounting and records it on the history - id: ATS-COM-ORD-008-13 title: Void returns the resources held by a selling application category: interaction level: api proves: - BR-CAP-COM-ORD-008-03 - BR-CAP-COM-ORD-012-08 preconditions: A placed sale has a committed application claim and pending delivery. steps: - do: 'Void it and inspect the application claim, reservation and delivery records.' provenance: proposed source: - >- services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#released the participant’s claim, the ledger and the obligations - >- services-commerce:modules/participants/tests/unit/plain/plain-product-participant.spec.js#claims nothing for an item: ok, no claim, an attested empty payload and one unit to deliver expected: The claim and reservation release and pending delivery is cancelled. negative: false data_needs: Use an isolated workspace with the records and responses named in the preconditions. bound_to: [] provenance: proposed source: - >- services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#released the participant’s claim, the ledger and the obligations - >- services-commerce:modules/participants/tests/unit/plain/plain-product-participant.spec.js#claims nothing for an item: ok, no claim, an attested empty payload and one unit to deliver exercises: - CAP-COM-ORD-008 - CAP-COM-ORD-012 related_capabilities: - CAP-COM-ORD-012 expected_provenance: proposed expected_source: - >- services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#released the participant’s claim, the ledger and the obligations - >- services-commerce:modules/participants/tests/unit/plain/plain-product-participant.spec.js#claims nothing for an item: ok, no claim, an attested empty payload and one unit to deliver - id: ATS-COM-ORD-008-14 title: Void releases both initial and later offer uses category: interaction level: api proves: - BR-CAP-COM-ORD-008-01 - BR-CAP-COM-ORD-004-01 - BR-CAP-COM-ORD-015-01 preconditions: A placed sale has an initial promotion and a later promotion amendment. steps: - do: Void it and replay the adjustment; inspect both redemptions and captured legs. provenance: proposed source: - >- 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 - 'services-commerce:modules/orders/services/orders/void-refund.ts:voidRefundLegsOf' - >- services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#released the participant’s claim, the ledger and the obligations - 'services-commerce:modules/orders/services/orders/void-order.ts:voidOrder' - >- 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 - 'services-commerce:modules/fulfillment/services/register/intervention-audit.ts:auditIntervention' expected: Both redemptions release and completed settlement sends no duplicate refund. negative: false data_needs: Use an isolated workspace with the records and responses named in the preconditions. bound_to: [] provenance: proposed source: - >- 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 - 'services-commerce:modules/orders/services/orders/void-refund.ts:voidRefundLegsOf' - >- services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#released the participant’s claim, the ledger and the obligations - 'services-commerce:modules/orders/services/orders/void-order.ts:voidOrder' - >- 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 - 'services-commerce:modules/fulfillment/services/register/intervention-audit.ts:auditIntervention' exercises: - CAP-COM-ORD-008 - CAP-COM-ORD-004 - CAP-COM-ORD-015 workflows: - WF-COM-ORD-005 expected_provenance: proposed expected_source: - >- 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 - 'services-commerce:modules/orders/services/orders/void-refund.ts:voidRefundLegsOf' - >- services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#released the participant’s claim, the ledger and the obligations - 'services-commerce:modules/orders/services/orders/void-order.ts:voidOrder' - >- 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 - 'services-commerce:modules/fulfillment/services/register/intervention-audit.ts:auditIntervention' evidence: - >- Examined reference: services-commerce:modules/checkout/tests/e2e/holds-and-claims.e2e.spec.js#releases a placed order’s committed claims on void, cancels its pending obligations and leaves claims_released on its history - >- Examined reference: services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#refuses a reader without commerce.orders.void, 403 permission_missing, and a portal member the route - >- Examined reference: 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 - >- Examined reference: services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#refuses a void without a reason, 400 naming it - >- Examined reference: services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#released the participant’s claim, the ledger and the obligations - >- Examined reference: services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#deletes the pro forma in Accounting and records it on the history - >- Examined reference: 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 - >- Examined reference: 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 - >- Examined reference: services-commerce:modules/orders/tests/integration/services/orders/tender-window-sweeper.integration.spec.js#left the live, the terms, the accepted and the already voided orders as they were - >- Examined reference: services-commerce:modules/orders/tests/integration/services/orders/tender-window-sweeper.integration.spec.js#takes at most the limit, oldest window first, and leaves the rest to the next run - >- Examined reference: 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 - >- Examined reference: services-commerce:modules/orders/tests/integration/services/orders/void-refund.integration.spec.js#raises adjustment_failed on the tender for a person, and records the leg as unresolved - >- Examined reference: services-commerce:modules/orders/tests/integration/services/placement/promotion-placement.integration.spec.js#gives both counters back - >- Examined reference: services-commerce:modules/orders/tests/integration/services/placement/promotion-placement.integration.spec.js#voids the order and releases its redemption with order_voided - >- Examined reference: services-commerce:modules/orders/tests/unit/orders/void-refund.spec.js#plans a store-credit part by the memo alone, and the card part refunded before it - >- Examined reference: services-commerce:modules/orders/tests/unit/orders/void-refund.spec.js#refunds the paid part of a part-paid order before the memo of its line is cut - >- Examined reference: services-commerce:modules/orders/tests/unit/orders/void-request.spec.js#refuses a reason of 501 characters saying the limit, not that it is missing coverage: rule: covered transition: 'gap: FND-COM-ORD-065' validation: covered permission: 'gap: FND-COM-ORD-065' edge: 'gap: FND-COM-ORD-065' failure: covered boundary: covered concurrency: 'gap: FND-COM-ORD-065' invariant: 'gap: FND-COM-ORD-065' interaction: covered coverage_definition: Covered means a design scenario exists; executable coverage and execution results are separate. permission_coverage: - key: commerce.orders.void where_checked: api scenarios: - ATS-COM-ORD-008-01 gap: FND-COM-ORD-065 note: >- The listed examples do not establish a complete allow-and-deny matrix for this key; unused catalogue keys need no invented route. provenance: unknown source: FND-COM-ORD-065 transition_coverage: - state_model: STATE-COM-ORD-003 from: held to: committed trigger: Placement converts a hold or a later pass confirms a placed lease. scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: >- services-commerce:modules/checkout/tests/e2e/holds-and-claims.e2e.spec.js#places the checkout: the hold re-affirmed and converted in TX-P, the ledger committed on the line, the claim frozen on the purchase note: 'Individual examples do not exhaustively prove this transition, its guard and side effects.' - state_model: STATE-COM-ORD-003 from: held to: expired trigger: The reservation pass discovers a lapsed unplaced hold. scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: 'services-commerce:modules/orders/services/reservations/reservation-sweeper.ts:sweepReservations' note: 'Individual examples do not exhaustively prove this transition, its guard and side effects.' - state_model: STATE-COM-ORD-003 from: held to: released trigger: Item removal or cart abandonment returns held resources. scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: 'services-commerce:modules/checkout/services/checkout/hold-release.ts:releaseHeldReservations' note: 'Individual examples do not exhaustively prove this transition, its guard and side effects.' - state_model: STATE-COM-ORD-003 from: committed to: released trigger: Void or after-sale execution returns committed resources. scenarios: - ATS-COM-ORD-008-03 provenance: test source: >- services-commerce:modules/checkout/tests/e2e/holds-and-claims.e2e.spec.js#releases a placed order’s committed claims on void, cancels its pending obligations and leaves claims_released on its history note: The cited test exercises this transition; other transitions retain separate gaps. - state_model: STATE-COM-ORD-003 from: committed to: consumed trigger: Delivery completes using the committed claim. scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: 'services-commerce:modules/orders/services/persistence/reservations.ts:RESERVATION_TRANSITIONS' note: 'Individual examples do not exhaustively prove this transition, its guard and side effects.' - state_model: STATE-COM-ORD-003 from: held to: mismatch trigger: Lease confirmation reports expired capacity or conflict. scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: 'services-commerce:modules/orders/services/placement/lease-confirmation.ts:confirmLease' note: 'Individual examples do not exhaustively prove this transition, its guard and side effects.' - state_model: STATE-COM-ORD-004 from: placed to: accepted trigger: 'Billing permits terms or no-payment acceptance, or successful payment covers the required amount.' scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#answers 200: the attempt succeeded with Accounting’s payment, the order accepted, the pro forma converted by that first money note: 'Individual examples do not exhaustively prove this transition, its guard and side effects.' - state_model: STATE-COM-ORD-004 from: placed to: tender_uncertain trigger: Accounting cannot give a final payment result. scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#answers uncertain, the order tender_uncertain, the attempt uncertain naming Accounting’s intent note: 'Individual examples do not exhaustively prove this transition, its guard and side effects.' - state_model: STATE-COM-ORD-004 from: tender_uncertain to: accepted trigger: Recovery confirms enough captured payment to accept. scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#accepts the order once Accounting holds the payment, with one charge and the payment on the attempt note: 'Individual examples do not exhaustively prove this transition, its guard and side effects.' - state_model: STATE-COM-ORD-004 from: tender_uncertain to: placed trigger: Recovery ends without enough payment or finds no remaining open attempt. scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: 'services-commerce:modules/orders/services/tender/tender-order.ts' note: 'Individual examples do not exhaustively prove this transition, its guard and side effects.' - state_model: STATE-COM-ORD-004 from: placed to: voided trigger: A staff void or elapsed-deadline pass ends the sale. scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: >- 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 note: 'Individual examples do not exhaustively prove this transition, its guard and side effects.' - state_model: STATE-COM-ORD-004 from: accepted to: cancelled trigger: Completed cancellation leaves no item quantity standing. scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: >- services-commerce:modules/orders/tests/e2e/cancellations.e2e.spec.js#lists the order’s cancellations and reads one; cancelling the mug too closes the order cancelled (B5) note: 'Individual examples do not exhaustively prove this transition, its guard and side effects.' - state_model: STATE-COM-ORD-004 from: accepted to: closed trigger: The lifecycle offers closure without a current producer. scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: 'services-commerce:modules/orders/services/persistence/orders.ts:ORDER_TRANSITIONS' note: 'Individual examples do not exhaustively prove this transition, its guard and side effects.' invariant_coverage: - invariant: INV-DOM-COM-ORD-002-01 scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: 'services-commerce:modules/orders/db/orders.table.ts:orders_total_check, orders_amounts_check' note: Broader invariant coverage remains open beyond the concrete examples. - invariant: INV-DOM-COM-ORD-002-02 scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: >- services-commerce:modules/checkout/tests/e2e/idempotency.e2e.spec.js#answers the stored status and body, marked Idempotent-Replayed, and runs the placement once: one order row; services-commerce:modules/orders/db/orders.table.ts:orders_checkout_uq note: Broader invariant coverage remains open beyond the concrete examples. - invariant: INV-DOM-COM-ORD-002-03 scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: 'services-commerce:modules/orders/db/orders.table.ts:orders_number_uq, orders_number_check' note: Broader invariant coverage remains open beyond the concrete examples. - invariant: INV-DOM-COM-ORD-002-04 scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: 'services-commerce:modules/orders/services/persistence/orders.ts:ORDER_TRANSITIONS' note: Broader invariant coverage remains open beyond the concrete examples. - invariant: INV-DOM-COM-ORD-002-05 scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: 'services-commerce:modules/orders/db/order-lines.table.ts:order_lines_quantity_check' note: Broader invariant coverage remains open beyond the concrete examples. - invariant: INV-DOM-COM-ORD-002-06 scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: >- services-commerce:modules/orders/db/order-line-purchases.table.ts:order_line_purchases_write_once_trigger note: Broader invariant coverage remains open beyond the concrete examples. - invariant: INV-DOM-COM-ORD-002-07 scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#resumes the same attempt on a retry, whatever card the retry names, and moves nothing while the intent is processing note: Broader invariant coverage remains open beyond the concrete examples. - invariant: INV-DOM-COM-ORD-002-08 scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: 'services-commerce:modules/orders/db/order-invoices.table.ts:order_invoices_idempotency_key_uq' note: Broader invariant coverage remains open beyond the concrete examples. - invariant: INV-DOM-COM-ORD-002-09 scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: 'services-commerce:modules/orders/db/order-events.table.ts' note: Broader invariant coverage remains open beyond the concrete examples. - invariant: INV-DOM-COM-ORD-002-10 scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: 'services-commerce:modules/orders/db/order-lines.table.ts:order_lines_order_fk' note: Broader invariant coverage remains open beyond the concrete examples. - invariant: INV-DOM-COM-ORD-002-11 scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: 'services-commerce:modules/orders/db/orders.table.ts:orders_installment_schedule_check' note: Broader invariant coverage remains open beyond the concrete examples. - invariant: INV-DOM-COM-ORD-002-12 scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#never stores the card: the attempt keeps a reference of the merchant account and the token’s last four only note: Broader invariant coverage remains open beyond the concrete examples. - invariant: INV-DOM-COM-ORD-002-13 scenarios: [] gap: FND-COM-ORD-065 provenance: unknown source: >- services-commerce:modules/orders/db/reservations.table.ts:reservations_subject_check; modules/orders/services/persistence/reservations.ts:RESERVATION_TRANSITIONS note: Broader invariant coverage remains open beyond the concrete examples. workflow_coverage: - workflow: WF-COM-ORD-005 scenarios: - ATS-COM-ORD-008-14 gap: FND-COM-ORD-065 provenance: proposed source: - >- 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 - 'services-commerce:modules/orders/services/orders/void-refund.ts:voidRefundLegsOf' - >- services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#released the participant’s claim, the ledger and the obligations - 'services-commerce:modules/orders/services/orders/void-order.ts:voidOrder' - >- 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 - 'services-commerce:modules/fulfillment/services/register/intervention-audit.ts:auditIntervention' - workflow: WF-COM-ORD-006 scenarios: - ATS-COM-ORD-001-20 gap: FND-COM-ORD-065 provenance: proposed source: - 'services-commerce:modules/checkout/aws/lambda/SWEEPER.ts:handler' - 'services-commerce:modules/orders/services/reservations/reservation-sweeper.ts:sweepReservations' - 'services-commerce:modules/orders/services/orders/tender-window-sweeper.ts:sweepTenderWindows' - 'services-commerce:modules/checkout/aws/lambda/SWEEPER.ts:handler' - 'services-commerce:modules/orders/services/orders/financial-sweeps.ts:sweepFinancials' - 'services-commerce:modules/entitlements/services/register/entitlement-sweeper.ts:sweepEntitlements' - 'services-commerce:modules/checkout/aws/lambda/SWEEPER.ts:handler' interaction_coverage: - with: CAP-COM-ORD-006 scenarios: - ATS-COM-ORD-008-12 - with: CAP-COM-ORD-012 scenarios: - ATS-COM-ORD-008-13 unproved_rules: [] --- # Clear an unaccepted order and return its resources: Capability Test Specification ## Coverage | Rule | Scenario or finding | |---|---| | `BR-CAP-COM-ORD-008-01` | `ATS-COM-ORD-008-01`, `ATS-COM-ORD-008-14` | | `BR-CAP-COM-ORD-008-02` | `ATS-COM-ORD-008-02` | | `BR-CAP-COM-ORD-008-03` | `ATS-COM-ORD-008-03`, `ATS-COM-ORD-008-13` | | `BR-CAP-COM-ORD-008-04` | `ATS-COM-ORD-008-04` | | `BR-CAP-COM-ORD-008-05` | `ATS-COM-ORD-008-05`, `ATS-COM-ORD-008-12` | | `BR-CAP-COM-ORD-008-06` | `ATS-COM-ORD-008-06` | | `BR-CAP-COM-ORD-008-07` | `ATS-COM-ORD-008-07` | | `BR-CAP-COM-ORD-008-08` | `ATS-COM-ORD-008-08` | | `BR-CAP-COM-ORD-008-09` | `ATS-COM-ORD-008-10` | | `BR-CAP-COM-ORD-008-10` | `ATS-COM-ORD-008-11` | ## Interactions With Related Capabilities A void retains its domain result when invoice clearing fails. A placed order links an issued pro forma. Void while Accounting cannot delete it, then read the sale and history. Void returns the resources held by a selling application. A placed sale has a committed application claim and pending delivery. Void it and inspect the application claim, reservation and delivery records. Crossing workflow examples also cover preparation, commitment and recovery at their service handoffs. Their structured bindings distinguish specified outcomes from executable evidence.