--- id: ATS-COM-ORD-009 scope: CAP-COM-ORD-009 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-009-01 title: Only deposit policies permit their offered plans level: api proves: - BR-CAP-COM-ORD-009-01 preconditions: A deposit policy offers one plan and another policy requires immediate payment. steps: - do: 'Choose an unoffered plan, use the pay-now policy and clear a valid selection.' provenance: test source: >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#refuses a plan the order type does not offer, 400 installment_plan_not_offered naming what is offered expected: The invalid choices are refused and clearing removes the quote. negative: true data_needs: Use the controlled records and transports established by the cited tests. bound_to: - >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#refuses a plan the order type does not offer, 400 installment_plan_not_offered naming what is offered - >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#refuses a plan under a pay-now ordering profile, 400 ordering_profile_not_deposit, whatever plans it lists - >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#clears the choice with null: the preview quotes nothing - TST-COM-ORD-079 provenance: test source: >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#refuses a plan the order type does not offer, 400 installment_plan_not_offered naming what is offered category: validation expected_provenance: test expected_source: >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#refuses a plan the order type does not offer, 400 installment_plan_not_offered naming what is offered - id: ATS-COM-ORD-009-02 title: A cart displays the quoted deposit schedule level: api proves: - BR-CAP-COM-ORD-009-02 preconditions: The cart totals sixty-two dollars under a four-part arrangement. steps: - do: Request its installment preview. provenance: test source: >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#answers the preview with the schedule Accounting quotes: 1550 up front of 6200, three installments of 1550, each line split expected: The result shows 15.50 up front and three installments of 15.50 with line allocation. negative: false data_needs: Use the controlled records and transports established by the cited tests. bound_to: - >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#answers the preview with the schedule Accounting quotes: 1550 up front of 6200, three installments of 1550, each line split - TST-COM-ORD-079 provenance: test source: >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#answers the preview with the schedule Accounting quotes: 1550 up front of 6200, three installments of 1550, each line split category: rule expected_provenance: test expected_source: >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#answers the preview with the schedule Accounting quotes: 1550 up front of 6200, three installments of 1550, each line split - id: ATS-COM-ORD-009-03 title: Deposit payment accepts the frozen plan sale level: api proves: - BR-CAP-COM-ORD-009-03 preconditions: A cart has a quoted deposit arrangement. steps: - do: Place and pay the required up-front portion by card. provenance: test source: >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#froze the plan and the quoted schedule on the order, and billed the DEPOSIT pro forma: each line at its up-front part expected: Deposit invoice lines retain their parts and payment accepts the order while requesting vaulting. negative: false data_needs: Use the controlled records and transports established by the cited tests. bound_to: - >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#froze the plan and the quoted schedule on the order, and billed the DEPOSIT pro forma: each line at its up-front part - >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#accepted the order on the deposit of 1550 (what it owes now, not its total), the card sent with vault: true - TST-COM-ORD-079 provenance: test source: >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#froze the plan and the quoted schedule on the order, and billed the DEPOSIT pro forma: each line at its up-front part category: transition expected_provenance: test expected_source: >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#froze the plan and the quoted schedule on the order, and billed the DEPOSIT pro forma: each line at its up-front part - id: ATS-COM-ORD-009-04 title: The schedule is linked after acceptance level: api proves: - BR-CAP-COM-ORD-009-04 preconditions: A deposit order has met its payment requirement. steps: - do: Inspect schedule creation and the order’s schedule response. provenance: test source: >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#created the schedule under the order’s key after the acceptance, wrote it on the order and reflected it on the mirror expected: The stable-key schedule is recorded on the order and reflected as scheduled in its money summary. negative: false data_needs: Use the controlled records and transports established by the cited tests. bound_to: - >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#created the schedule under the order’s key after the acceptance, wrote it on the order and reflected it on the mirror - >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#answers the schedule route: the plan, the frozen quote, the schedule as Accounting holds it, scheduled - TST-COM-ORD-079 provenance: test source: >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#created the schedule under the order’s key after the acceptance, wrote it on the order and reflected it on the mirror category: transition expected_provenance: test expected_source: >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#created the schedule under the order’s key after the acceptance, wrote it on the order and reflected it on the mirror - id: ATS-COM-ORD-009-05 title: Installment payment requires a payable installment level: api proves: - BR-CAP-COM-ORD-009-05 preconditions: Fixtures provide a scheduled installment and an order without a schedule. steps: - do: 'Attempt early payment, due payment, repeat payment and payment without a schedule.' provenance: test source: >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#refuses an installment before Accounting invoices it, 409 installment_not_due, charging nothing expected: >- Only the due unpaid case succeeds; the others identify not-due, already-paid or missing-schedule reasons. negative: true data_needs: Use the controlled records and transports established by the cited tests. bound_to: - >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#refuses an installment before Accounting invoices it, 409 installment_not_due, charging nothing - >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#answers succeeded: an installment attempt of 1550 with Accounting’s payment, the order still accepted - >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#refuses paying it again, 409 installment_already_paid, and an installment that is not on the schedule, 400 installment_not_found - >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#refuses an installment tender on an order with no schedule (a pay-now order), 409 no_installment_schedule, and answers its schedule route no_plan - TST-COM-ORD-079 provenance: test source: >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#refuses an installment before Accounting invoices it, 409 installment_not_due, charging nothing category: boundary expected_provenance: test expected_source: >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#refuses an installment before Accounting invoices it, 409 installment_not_due, charging nothing - id: ATS-COM-ORD-009-06 title: Cancellation reduces future collection level: api proves: - BR-CAP-COM-ORD-009-06 preconditions: A two-item plan has one installment already paid. steps: - do: Cancel the mug and then the remaining shirt. provenance: test source: >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#credits the mug’s up-front part alone (the memo 300, the refund 300), never its financed part expected: >- The mug’s deposit part and future shares are removed without rewriting the paid installment; complete cancellation ends the schedule. negative: false data_needs: Use the controlled records and transports established by the cited tests. bound_to: - >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#credits the mug’s up-front part alone (the memo 300, the refund 300), never its financed part - >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#reduced the remaining installments: the mug’s part gone from the two scheduled ones, the paid one untouched, on the history - >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#cancels the schedule whole once every item line is cancelled, the T-shirt’s deposit refunded - TST-COM-ORD-079 provenance: test source: >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#credits the mug’s up-front part alone (the memo 300, the refund 300), never its financed part category: interaction expected_provenance: test expected_source: >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#credits the mug’s up-front part alone (the memo 300, the refund 300), never its financed part - id: ATS-COM-ORD-009-07 title: Schedule reads can reconcile deferred work level: api proves: - BR-CAP-COM-ORD-009-08 preconditions: An accepted plan order lacks a completed schedule link or has changed Accounting installments. steps: - do: Read its schedule twice using a controlled transport. provenance: proposed source: >- services-commerce:modules/orders/services/installments/installment-schedule.ts:readOrderInstallmentSchedule expected: >- The recovered schedule uses the original key and current invoice links and money figures appear without duplicate schedule creation. negative: false data_needs: 'A controlled workspace with the parties, commercial setup and application responses described above.' bound_to: [] provenance: proposed source: >- services-commerce:modules/orders/services/installments/installment-schedule.ts:readOrderInstallmentSchedule category: failure expected_provenance: proposed expected_source: >- services-commerce:modules/orders/services/installments/installment-schedule.ts:readOrderInstallmentSchedule - id: ATS-COM-ORD-009-08 title: Plan cancellation updates both future collection and current money category: interaction level: api proves: - BR-CAP-COM-ORD-009-06 - BR-CAP-COM-ORD-014-13 preconditions: A deposit sale has a paid installment and future unpaid shares. steps: - do: Cancel one line and inspect the schedule and order money. provenance: proposed source: - >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#reduced the remaining installments: the mug’s part gone from the two scheduled ones, the paid one untouched, on the history - >- services-commerce:modules/orders/tests/e2e/cancellations.e2e.spec.js#shows the cancellation’s credit on the order’s money mirror at once, read right after the cancel expected: >- The paid installment is unchanged, future shares shrink and the cancellation credit appears on the order. 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/installments.e2e.spec.js#reduced the remaining installments: the mug’s part gone from the two scheduled ones, the paid one untouched, on the history - >- services-commerce:modules/orders/tests/e2e/cancellations.e2e.spec.js#shows the cancellation’s credit on the order’s money mirror at once, read right after the cancel exercises: - CAP-COM-ORD-009 - CAP-COM-ORD-014 related_capabilities: - CAP-COM-ORD-014 expected_provenance: proposed expected_source: - >- services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#reduced the remaining installments: the mug’s part gone from the two scheduled ones, the paid one untouched, on the history - >- services-commerce:modules/orders/tests/e2e/cancellations.e2e.spec.js#shows the cancellation’s credit on the order’s money mirror at once, read right after the cancel - id: ATS-COM-ORD-009-09 title: Deposit acceptance and later cancellation meet at the schedule category: interaction level: api proves: - BR-CAP-COM-ORD-009-01 - BR-CAP-COM-ORD-007-01 - BR-CAP-COM-ORD-014-01 preconditions: A plan purchase has an accepted deposit and a future unpaid installment. steps: - do: 'Create the schedule, cancel one line and read current and future money.' provenance: proposed source: - 'services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js' - 'services-commerce:modules/orders/services/placement/place-order.ts:installmentsOfPlacement' - 'services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js' - >- services-commerce:modules/orders/services/installments/installment-schedule.ts:ensureInstallmentSchedule - >- services-commerce:modules/orders/services/installments/installment-schedule.ts:readOrderInstallmentSchedule - 'services-commerce:modules/orders/services/installments/installment-tender.ts' - 'services-commerce:modules/orders/services/installments/installment-cancellation.ts' expected: >- Acceptance stands, the cancellation credit is visible and future collection excludes the cancelled share. 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/installments.e2e.spec.js' - 'services-commerce:modules/orders/services/placement/place-order.ts:installmentsOfPlacement' - 'services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js' - >- services-commerce:modules/orders/services/installments/installment-schedule.ts:ensureInstallmentSchedule - >- services-commerce:modules/orders/services/installments/installment-schedule.ts:readOrderInstallmentSchedule - 'services-commerce:modules/orders/services/installments/installment-tender.ts' - 'services-commerce:modules/orders/services/installments/installment-cancellation.ts' exercises: - CAP-COM-ORD-009 - CAP-COM-ORD-007 - CAP-COM-ORD-014 workflows: - WF-COM-ORD-007 expected_provenance: proposed expected_source: - 'services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js' - 'services-commerce:modules/orders/services/placement/place-order.ts:installmentsOfPlacement' - 'services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js' - >- services-commerce:modules/orders/services/installments/installment-schedule.ts:ensureInstallmentSchedule - >- services-commerce:modules/orders/services/installments/installment-schedule.ts:readOrderInstallmentSchedule - 'services-commerce:modules/orders/services/installments/installment-tender.ts' - 'services-commerce:modules/orders/services/installments/installment-cancellation.ts' evidence: - >- Examined reference: services-commerce:modules/orders/services/installments/installment-schedule.ts:readOrderInstallmentSchedule - >- Examined reference: services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#accepted the order on the deposit of 1550 (what it owes now, not its total), the card sent with vault: true - >- Examined reference: services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#answers succeeded: an installment attempt of 1550 with Accounting’s payment, the order still accepted - >- Examined reference: services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#answers the preview with the schedule Accounting quotes: 1550 up front of 6200, three installments of 1550, each line split - >- Examined reference: services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#answers the schedule route: the plan, the frozen quote, the schedule as Accounting holds it, scheduled - >- Examined reference: services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#cancels the schedule whole once every item line is cancelled, the T-shirt’s deposit refunded - >- Examined reference: services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#clears the choice with null: the preview quotes nothing - >- Examined reference: services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#created the schedule under the order’s key after the acceptance, wrote it on the order and reflected it on the mirror - >- Examined reference: services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#credits the mug’s up-front part alone (the memo 300, the refund 300), never its financed part - >- Examined reference: services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#froze the plan and the quoted schedule on the order, and billed the DEPOSIT pro forma: each line at its up-front part - >- Examined reference: services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#reduced the remaining installments: the mug’s part gone from the two scheduled ones, the paid one untouched, on the history - >- Examined reference: services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#refuses a plan the order type does not offer, 400 installment_plan_not_offered naming what is offered - >- Examined reference: services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#refuses a plan under a pay-now ordering profile, 400 ordering_profile_not_deposit, whatever plans it lists - >- Examined reference: services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#refuses an installment before Accounting invoices it, 409 installment_not_due, charging nothing - >- Examined reference: services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#refuses an installment tender on an order with no schedule (a pay-now order), 409 no_installment_schedule, and answers its schedule route no_plan - >- Examined reference: services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#refuses paying it again, 409 installment_already_paid, and an installment that is not on the schedule, 400 installment_not_found coverage: rule: covered transition: covered validation: covered permission: 'gap: FND-COM-ORD-066' edge: 'gap: FND-COM-ORD-066' failure: covered boundary: covered concurrency: 'gap: FND-COM-ORD-066' invariant: 'gap: FND-COM-ORD-066' interaction: covered coverage_definition: Covered means a design scenario exists; executable coverage and execution results are separate. permission_coverage: - key: commerce.checkouts.update where_checked: api scenarios: [] gap: FND-COM-ORD-066 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-066 - key: commerce.orders.read where_checked: api scenarios: [] gap: FND-COM-ORD-066 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-066 - key: commerce.orders.tender where_checked: api scenarios: [] gap: FND-COM-ORD-066 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-066 transition_coverage: [] invariant_coverage: - invariant: INV-DOM-COM-ORD-001-01 scenarios: [] gap: FND-COM-ORD-066 provenance: unknown source: 'services-commerce:modules/checkout/db/checkouts.table.ts:checkouts_placed_order_check' note: Broader invariant coverage remains open beyond the concrete examples. - invariant: INV-DOM-COM-ORD-001-02 scenarios: [] gap: FND-COM-ORD-066 provenance: unknown source: 'services-commerce:modules/checkout/db/checkouts.table.ts:checkouts_placed_order_uq' note: Broader invariant coverage remains open beyond the concrete examples. - invariant: INV-DOM-COM-ORD-001-03 scenarios: [] gap: FND-COM-ORD-066 provenance: unknown source: >- services-commerce:modules/checkout/db/checkouts.table.ts:checkouts_currency_check, checkouts_ordering_profile_source_check note: Broader invariant coverage remains open beyond the concrete examples. - invariant: INV-DOM-COM-ORD-001-04 scenarios: [] gap: FND-COM-ORD-066 provenance: unknown source: 'services-commerce:modules/checkout/services/persistence/checkouts.ts:CHECKOUT_TRANSITIONS' note: Broader invariant coverage remains open beyond the concrete examples. - invariant: INV-DOM-COM-ORD-001-05 scenarios: [] gap: FND-COM-ORD-066 provenance: unknown source: >- services-commerce:modules/checkout/tests/e2e/placement.e2e.spec.js#leaves the checkout placed, naming the order, its items frozen with what prepare attested, and its trail telling the story; services-commerce:modules/checkout/services/persistence/checkouts.ts:updateCheckout, appendCheckoutEvent note: Broader invariant coverage remains open beyond the concrete examples. - invariant: INV-DOM-COM-ORD-001-06 scenarios: [] gap: FND-COM-ORD-066 provenance: unknown source: 'services-commerce:modules/checkout/db/checkouts.table.ts:checkouts_ship_to_check' note: Broader invariant coverage remains open beyond the concrete examples. - invariant: INV-DOM-COM-ORD-001-07 scenarios: [] gap: FND-COM-ORD-066 provenance: unknown source: 'services-commerce:modules/checkout/tests/e2e/checkout-security.e2e.spec.js' note: Broader invariant coverage remains open beyond the concrete examples. - invariant: INV-DOM-COM-ORD-001-08 scenarios: [] gap: FND-COM-ORD-066 provenance: unknown source: >- services-commerce:modules/checkout/db/checkout-items.table.ts:checkout_items_quantity_check; modules/checkout/services/checkout/checkout-part-checks.ts note: Broader invariant coverage remains open beyond the concrete examples. - invariant: INV-DOM-COM-ORD-002-01 scenarios: [] gap: FND-COM-ORD-066 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-066 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-066 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-066 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-066 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-066 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-066 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-066 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-066 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-066 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-066 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-066 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-066 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-001 scenarios: - ATS-COM-ORD-001-19 gap: FND-COM-ORD-066 provenance: proposed source: - 'services-commerce:modules/checkout/tests/e2e/ordering-profile-resolution.e2e.spec.js' - 'services-commerce:modules/checkout/services/checkout/purchasing-roles.ts' - >- services-commerce:modules/checkout/tests/e2e/holds-and-claims.e2e.spec.js#refuses another buyer the booth: 409 hold_unavailable with the participant’s reason, and their preview marks the item unavailable - 'services-commerce:modules/checkout/tests/e2e/checkout-preprocessing.e2e.spec.js' - 'services-commerce:modules/checkout/tests/e2e/participant-unavailable.e2e.spec.js' - 'services-commerce:modules/checkout/tests/e2e/product-purchase-eligibility.e2e.spec.js' - 'services-commerce:modules/checkout/tests/e2e/accounting-tax.e2e.spec.js' - 'services-commerce:modules/checkout/tests/e2e/checkouts.e2e.spec.js' - 'services-commerce:modules/checkout/aws/lambda/SWEEPER.ts:handler' - workflow: WF-COM-ORD-004 scenarios: - ATS-COM-ORD-007-19 gap: FND-COM-ORD-066 provenance: proposed source: - >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a second tender of the accepted order, 409 order_not_tenderable - 'services-commerce:modules/orders/services/tender/tender-refusals.ts' - 'services-commerce:modules/orders/services/persistence/orders.ts:recordTender' - >- 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 - >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#tells the story on the history: placed, billed, the tender recorded, submitted and resolved, the transition to accepted - 'services-commerce:modules/orders/services/orders/financial-sweeps.ts:sweepFinancials' - workflow: WF-COM-ORD-006 scenarios: - ATS-COM-ORD-001-20 gap: FND-COM-ORD-066 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' - workflow: WF-COM-ORD-007 scenarios: - ATS-COM-ORD-009-09 gap: FND-COM-ORD-066 provenance: proposed source: - 'services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js' - 'services-commerce:modules/orders/services/placement/place-order.ts:installmentsOfPlacement' - 'services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js' - >- services-commerce:modules/orders/services/installments/installment-schedule.ts:ensureInstallmentSchedule - >- services-commerce:modules/orders/services/installments/installment-schedule.ts:readOrderInstallmentSchedule - 'services-commerce:modules/orders/services/installments/installment-tender.ts' - 'services-commerce:modules/orders/services/installments/installment-cancellation.ts' - workflow: WF-COM-ORD-010 scenarios: - ATS-COM-ORD-014-19 gap: FND-COM-ORD-066 provenance: proposed source: - >- services-commerce:modules/orders/tests/e2e/cancellations.e2e.spec.js#refuses a placed order 409 order_not_cancellable, another member 403 not_your_party, a reader 403 permission_missing, another tenant 404 - >- services-commerce:modules/orders/tests/e2e/cancellations.e2e.spec.js#refuses a member on the console approve route 403, and a clerk approving 403 permission_missing - >- services-commerce:modules/orders/tests/e2e/cancellations.e2e.spec.js#fences a DELIVERED seat through the participant’s commerce_claim_cancellation, and the participant’s cancel gives the capacity back - 'services-commerce:modules/orders/services/cancellations/cancellation-workflow.ts' - >- services-commerce:modules/orders/services/cancellations/cancellation-settlement.ts:settleCancellationAfterObligation - >- services-commerce:modules/orders/tests/e2e/cancellations.e2e.spec.js#raises the fee invoice, applies the freed money to it and refunds the remainder - >- services-commerce:modules/orders/tests/e2e/cancellations.e2e.spec.js#shows the cancellation’s credit on the order’s money mirror at once, read right after the cancel interaction_coverage: - with: CAP-COM-ORD-014 scenarios: - ATS-COM-ORD-009-08 unproved_rules: - rule: BR-CAP-COM-ORD-009-07 gap: FND-COM-ORD-066 provenance: unknown source: 'services-commerce:docs/milestones/plans/COMM-realignment-2026-10-22.md#5. The milestones, revised' --- # Purchase with a deposit and scheduled payments: Capability Test Specification ## Coverage | Rule | Scenario or finding | |---|---| | `BR-CAP-COM-ORD-009-01` | `ATS-COM-ORD-009-01`, `ATS-COM-ORD-009-09` | | `BR-CAP-COM-ORD-009-02` | `ATS-COM-ORD-009-02` | | `BR-CAP-COM-ORD-009-03` | `ATS-COM-ORD-009-03` | | `BR-CAP-COM-ORD-009-04` | `ATS-COM-ORD-009-04` | | `BR-CAP-COM-ORD-009-05` | `ATS-COM-ORD-009-05` | | `BR-CAP-COM-ORD-009-06` | `ATS-COM-ORD-009-06`, `ATS-COM-ORD-009-08` | | `BR-CAP-COM-ORD-009-07` | no scenario: `FND-COM-ORD-066` | | `BR-CAP-COM-ORD-009-08` | `ATS-COM-ORD-009-07` | ## Interactions With Related Capabilities Plan cancellation updates both future collection and current money. A deposit sale has a paid installment and future unpaid shares. Cancel one line and inspect the schedule and order money. Crossing workflow examples also cover preparation, commitment and recovery at their service handoffs. Their structured bindings distinguish specified outcomes from executable evidence.