Skip to content

ATS-COM-ORD-008Clear an unaccepted order and return its resources: Capability Test Specification

Markdown

ATS-COM-ORD-008

Clear an unaccepted order and return its resources: Capability Test Specification

Markdown
  • DocumentProposed

KindAcceptance test setProduct areaCommerceModuleCustomer purchases, purchased benefits and vendor stockRevision2

Read atservices-commerce c8b66a98macroservice-libraries 54536a44react-console baf6dae3

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

Test Scenarios

14 scenarios proving CAP-COM-ORD-008; 11 bound to an existing test.

01 Void authority includes a mandatory bounded reasonpermissionapinegativetest
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.
Data
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
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
02 An already cleared or accepted order cannot be voidedvalidationapinegativetest
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.
Data
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
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
03 Clearing a sale releases its resourcestransitionapitest
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.
Data
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
Source
services-commerce:modules/checkout/tests/e2e/order-void.e2e.spec.js#released the participant’s claim, the ledger and the obligations
04 Released code use can be redeemed againtransitionapitest
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.
Data
Use the controlled records and transports established by the cited tests.
Bound to
Source
services-commerce:modules/orders/tests/integration/services/placement/promotion-placement.integration.spec.js#voids the order and releases its redemption with order_voided
05 Void records invoice clearing after commitmentfailureapitest
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.
Data
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
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
06 A partially funded void refunds before creditingruleunittest
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.
Data
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
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
07 Adjustment replay does not send another refundinvariantapinegativetest
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.
Data
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
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
08 Expired pay-now windows are cleared in bounded batchestransitionapitest
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.
Data
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
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
09 Void recovery joins money and released resourcesinteractionapitest
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.
Data
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
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
10 A payment deadline crosses midnight by elapsed minutesboundaryunittest
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.
Data
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
Source
services-commerce:modules/orders/tests/unit/placement/tender-window.spec.js#ends a thirty-minute window across midnight UTC on the next day
11 Expired payment actions retain the permitted void actionpermissionbrowsernegativetest
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.
Data
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
Source
react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows neither once the tender window has passed, except Void Order
12 A void retains its domain result when invoice clearing failsinteractionapiproposed
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.
Data
Use an isolated workspace with the records and responses named in the preconditions.
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
13 Void returns the resources held by a selling applicationinteractionapiproposed
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.
Data
Use an isolated workspace with the records and responses named in the preconditions.
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
14 Void releases both initial and later offer usesinteractionapiproposed
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.
Data
Use an isolated workspace with the records and responses named in the preconditions.
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

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.