--- id: ATS-COM-ORD-007 scope: CAP-COM-ORD-007 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-007-01 title: Unresolved card retries resume the original attempt level: api proves: - BR-CAP-COM-ORD-007-01 preconditions: Accounting has not supplied a final answer for a card request. steps: - do: Retry with another token and later resolve the original intent. provenance: test 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 expected: 'The retry resumes the original attempt, one payment is retained and resolution accepts the order.' 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#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#resumes the same attempt on a retry, whatever card the retry names, and moves nothing while the intent is processing - >- 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 - TST-COM-ORD-075 provenance: test 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 category: invariant expected_provenance: test expected_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 - id: ATS-COM-ORD-007-02 title: Expired and accepted orders reject normal payment level: api proves: - BR-CAP-COM-ORD-007-02 preconditions: One placed order is past its window and another is accepted. steps: - do: Attempt the normal tender action for both. provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a tender after the window 409 tender_window_expired and gives the sentence plain in the details, without the error class prefix (COMM-M2 R2-5) expected: The responses identify tender_window_expired and order_not_tenderable. 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#refuses a tender after the window 409 tender_window_expired and gives the sentence plain in the details, without the error class prefix (COMM-M2 R2-5) - >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a second tender of the accepted order, 409 order_not_tenderable - TST-COM-ORD-075 provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a tender after the window 409 tender_window_expired and gives the sentence plain in the details, without the error class prefix (COMM-M2 R2-5) category: boundary expected_provenance: test expected_source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a tender after the window 409 tender_window_expired and gives the sentence plain in the details, without the error class prefix (COMM-M2 R2-5) - id: ATS-COM-ORD-007-03 title: Frozen method choices distinguish staff offline payment level: api proves: - BR-CAP-COM-ORD-007-03 preconditions: An order predates policy removal of a method and another policy lists no offline choice. steps: - do: 'Try portal offline payment, a retained frozen method and staff cash.' provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses an offline tender by a member, 403 tender_kind_staff_only, and a kind the profile does not allow, 409, read from the ORDER’s snapshot: the order placed before the change still allows it (22 §9) expected: 'Portal offline payment is refused, the earlier frozen choice remains usable and staff cash succeeds.' 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#refuses an offline tender by a member, 403 tender_kind_staff_only, and a kind the profile does not allow, 409, read from the ORDER’s snapshot: the order placed before the change still allows it (22 §9) - >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#lets staff record cash for the rest although the policy lists no offline method, accepting the order - >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#still refuses a member an offline tender under that policy, 409 tender_kind_not_allowed - >- services-commerce:modules/orders/tests/unit/tender/tender-kinds-of-profile.spec.js#admits terms only for a profile offering a collection option, and nothing for one offering nothing - TST-COM-ORD-075 - TST-COM-ORD-143 provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses an offline tender by a member, 403 tender_kind_staff_only, and a kind the profile does not allow, 409, read from the ORDER’s snapshot: the order placed before the change still allows it (22 §9) category: permission expected_provenance: test expected_source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses an offline tender by a member, 403 tender_kind_staff_only, and a kind the profile does not allow, 409, read from the ORDER’s snapshot: the order placed before the change still allows it (22 §9) - id: ATS-COM-ORD-007-04 title: Attempt output masks its payment token level: api proves: - BR-CAP-COM-ORD-007-04 preconditions: A card payment uses a token and merchant account. steps: - do: Inspect the returned payment attempt. provenance: test 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 expected: The instrument reference contains the account and token suffix but excludes the complete token. 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#never stores the card: the attempt keeps a reference of the merchant account and the token’s last four only - TST-COM-ORD-075 provenance: test 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 category: invariant expected_provenance: test expected_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 - id: ATS-COM-ORD-007-05 title: A decline permits a later attempt on the same order level: api proves: - BR-CAP-COM-ORD-007-05 preconditions: An unpaid pay-now order has a usable window. steps: - do: Submit a declining card and then an approving card. provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#answers 200 declined with the processor’s code, the order still placed with its pro forma, the attempt declined expected: The decline preserves the sale; the next attempt accepts it under the next sequence and key. 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#answers 200 declined with the processor’s code, the order still placed with its pro forma, the attempt declined - >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#accepts the order on the next attempt, under the next sequence and key - TST-COM-ORD-075 provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#answers 200 declined with the processor’s code, the order still placed with its pro forma, the attempt declined category: transition expected_provenance: test expected_source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#answers 200 declined with the processor’s code, the order still placed with its pro forma, the attempt declined - id: ATS-COM-ORD-007-06 title: Financial sweeps reconcile uncertain attempts level: api proves: - BR-CAP-COM-ORD-007-06 preconditions: 'A payment intent can be processing, completed or unresolved beyond fifteen minutes.' steps: - do: Run the tender reconciliation cases. provenance: test source: >- services-commerce:modules/orders/tests/integration/services/orders/financial-sweeps.integration.spec.js#moves nothing while Accounting’s intent is still processing, and escalates nothing before fifteen minutes expected: >- Processing retains uncertainty, completed payment accepts once and persistent uncertainty raises an exception. 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/financial-sweeps.integration.spec.js#moves nothing while Accounting’s intent is still processing, and escalates nothing before fifteen minutes - >- services-commerce:modules/orders/tests/integration/services/orders/financial-sweeps.integration.spec.js#resumes the attempt once Accounting’s sweeper has finished the intent: the payment on the attempt, the order accepted, one charge - >- services-commerce:modules/orders/tests/integration/services/orders/financial-sweeps.integration.spec.js#raises tender_uncertain on an attempt still uncertain past fifteen minutes - TST-COM-ORD-095 provenance: test source: >- services-commerce:modules/orders/tests/integration/services/orders/financial-sweeps.integration.spec.js#moves nothing while Accounting’s intent is still processing, and escalates nothing before fifteen minutes category: transition expected_provenance: test expected_source: >- services-commerce:modules/orders/tests/integration/services/orders/financial-sweeps.integration.spec.js#moves nothing while Accounting’s intent is still processing, and escalates nothing before fifteen minutes - id: ATS-COM-ORD-007-07 title: Only applied amounts satisfy the payment requirement level: api proves: - BR-CAP-COM-ORD-007-07 preconditions: A seventy-five-dollar sale has limited credit and two card legs. steps: - do: Apply credit and the successive card payments. provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#accepts the order on the leg that completes the total (08 row 14), the first leg captured expected: >- Only fifteen dollars of credit counts, and acceptance waits until the remaining successful legs cover the amount. 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#accepts the order on the leg that completes the total (08 row 14), the first leg captured - >- services-commerce:modules/orders/tests/unit/tender/tender-rules.spec.js#leaves a credit leg that applied less than it asked at what it applied, so the order still owes the rest - >- services-commerce:modules/orders/tests/unit/tender/tender-rules.spec.js#declines a credit leg whose settlement applied nothing - >- services-commerce:modules/orders/tests/unit/tender/tender-rules.spec.js#is the total less the legs that succeeded, ignoring the declined and uncertain ones - TST-COM-ORD-075 - TST-COM-ORD-145 provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#accepts the order on the leg that completes the total (08 row 14), the first leg captured category: rule expected_provenance: test expected_source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#accepts the order on the leg that completes the total (08 row 14), the first leg captured - id: ATS-COM-ORD-007-08 title: Single-payment limits permit staff recovery methods level: api proves: - BR-CAP-COM-ORD-007-08 preconditions: A single-payment policy governs a portal sale alongside staff offline cases. steps: - do: Attempt a second member payment and record the supported staff methods. provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a member a second payment, 409 split_tender_not_allowed naming the policy expected: The member receives split_tender_not_allowed while staff recording succeeds. 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#refuses a member a second payment, 409 split_tender_not_allowed naming the policy - >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#lets staff record a money order and a cashier’s check as split payments, each under its Accounting method - TST-COM-ORD-075 provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a member a second payment, 409 split_tender_not_allowed naming the policy category: permission expected_provenance: test expected_source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a member a second payment, 409 split_tender_not_allowed naming the policy - id: ATS-COM-ORD-007-09 title: Terms conversion retains a purchase-order reference level: api proves: - BR-CAP-COM-ORD-007-09 preconditions: A placed order’s policy permits deferred payment. steps: - do: Choose terms with the supplied purchase-order number. provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#pay later converts the pro forma to a real invoice and accepts the order on terms expected: The invoice becomes real and the order accepts without a payment charge. 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#pay later converts the pro forma to a real invoice and accepts the order on terms - TST-COM-ORD-075 provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#pay later converts the pro forma to a real invoice and accepts the order on terms category: transition expected_provenance: test expected_source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#pay later converts the pro forma to a real invoice and accepts the order on terms - id: ATS-COM-ORD-007-10 title: Merchant account and amount checks precede charging level: api proves: - BR-CAP-COM-ORD-007-10 preconditions: A frozen account cannot settle the fixture currency and the policy limits card amounts. steps: - do: 'Try that default, an eligible alternative and an out-of-range amount.' provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#asks Accounting whether the merchant account may settle the tender: the order’s frozen default refused when ineligible, 409 merchant_account_not_eligible, a request naming an eligible account accepted expected: 'The first fails eligibility, the alternative succeeds and the range check refuses the last request.' 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#asks Accounting whether the merchant account may settle the tender: the order’s frozen default refused when ineligible, 409 merchant_account_not_eligible, a request naming an eligible account accepted - >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a card outside the profile’s acceptance range on an order placed under it, 409 tender_kind_not_allowed naming the range, from the order’s snapshot - TST-COM-ORD-075 provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#asks Accounting whether the merchant account may settle the tender: the order’s frozen default refused when ineligible, 409 merchant_account_not_eligible, a request naming an eligible account accepted category: validation expected_provenance: test expected_source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#asks Accounting whether the merchant account may settle the tender: the order’s frozen default refused when ineligible, 409 merchant_account_not_eligible, a request naming an eligible account accepted - id: ATS-COM-ORD-007-11 title: Unanswered invoice creation prevents payment level: api proves: - BR-CAP-COM-ORD-007-11 preconditions: The placed order’s billing transport remains unavailable. steps: - do: Attempt payment while billing retry also receives no answer. provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses the tender 409 order_not_billed when billing it now gets no answer either, charging nothing expected: The result is order_not_billed and Accounting receives no charge. 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#refuses the tender 409 order_not_billed when billing it now gets no answer either, charging nothing - TST-COM-ORD-075 provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses the tender 409 order_not_billed when billing it now gets no answer either, charging nothing category: failure expected_provenance: test expected_source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses the tender 409 order_not_billed when billing it now gets no answer either, charging nothing - id: ATS-COM-ORD-007-12 title: Composer recovery retains the created order level: unit proves: - BR-CAP-COM-ORD-007-13 preconditions: 'Controlled adapters return decline, success, unpaid-close, check and terms cases.' steps: - do: Exercise submission and each supported recovery or method choice. provenance: test source: >- react-console:components/order-composer/__tests__/live-composer.test.tsx#places the order, then takes a card: declined first, approved on the same order expected: 'The same order remains visible with the appropriate payment result, check reference or terms reference.' negative: false data_needs: Use the controlled records and transports established by the cited tests. bound_to: - >- react-console:components/order-composer/__tests__/live-composer.test.tsx#places the order, then takes a card: declined first, approved on the same order - >- react-console:components/order-composer/__tests__/live-composer.test.tsx#keeps the placed order, awaiting payment, when the card pop-up is closed unpaid - >- react-console:components/order-composer/__tests__/live-composer.test.tsx#records a check against the placed order with its number - >- react-console:components/order-composer/__tests__/live-composer.test.tsx#bills on terms with the purchase order number, and takes no money - >- react-console:components/order-composer/__tests__/live-composer.test.tsx#offers the payment methods the checkout policy allows, and no others - TST-COM-ORD-018 provenance: test source: >- react-console:components/order-composer/__tests__/live-composer.test.tsx#places the order, then takes a card: declined first, approved on the same order category: interaction expected_provenance: test expected_source: >- react-console:components/order-composer/__tests__/live-composer.test.tsx#places the order, then takes a card: declined first, approved on the same order - id: ATS-COM-ORD-007-13 title: Order detail renders appropriate financial actions level: unit proves: - BR-CAP-COM-ORD-007-14 preconditions: 'Sample orders span unpaid pay-now, terms, paid and missing-permission cases.' steps: - do: Render their action cards. provenance: test source: >- react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows Take Payment and Void Order on an unpaid pay-now order inside its window expected: >- The cards show pay-now actions or the Accounting terms link as appropriate and hide unauthorized actions. negative: false data_needs: Use the controlled records and transports established by the cited tests. bound_to: - >- react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows Take Payment and Void Order on an unpaid pay-now order inside its window - >- react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows Receive Payment as a link to Accounting's Settle Invoices with the invoice selected, and no Take Payment - >- react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows none of them on a paid order - >- react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows none of them to someone without the permissions - TST-COM-ORD-017 provenance: test source: >- react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows Take Payment and Void Order on an unpaid pay-now order inside its window category: permission expected_provenance: test expected_source: >- react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows Take Payment and Void Order on an unpaid pay-now order inside its window - id: ATS-COM-ORD-007-14 title: Staff phone sale survives an initial decline level: browser proves: - AS-JNY-COM-ORD-001-01 - AS-JNY-COM-ORD-001-02 - AS-JNY-COM-ORD-001-03 preconditions: 'A live workspace has a customer address, product, promotion and development processor cards.' steps: - do: >- Build the purchase, place it, decline the first card, pay with the replacement and inspect the order. provenance: proposed source: FND-COM-ORD-032 expected: >- The browser retains one order through the decline and later successful charge, with both attempts and invoice conversion visible. negative: false data_needs: 'A controlled workspace with the parties, commercial setup and application responses described above.' bound_to: [] provenance: proposed source: FND-COM-ORD-032 category: interaction expected_provenance: proposed expected_source: FND-COM-ORD-032 - id: ATS-COM-ORD-007-15 title: Organization terms sale can be paid through Accounting level: browser proves: - AS-JNY-COM-ORD-002-01 - AS-JNY-COM-ORD-002-02 - AS-JNY-COM-ORD-002-03 preconditions: A contact without a purchasing role acts for an organization under a terms-capable policy. steps: - do: 'Place with a purchase-order reference, follow the Accounting payment link and return to detail.' provenance: proposed source: FND-COM-ORD-032 expected: The browser links the terms sale to its later Accounting payment and eligible delivery. negative: false data_needs: 'A controlled workspace with the parties, commercial setup and application responses described above.' bound_to: [] provenance: proposed source: FND-COM-ORD-032 category: interaction expected_provenance: proposed expected_source: FND-COM-ORD-032 - id: ATS-COM-ORD-007-16 title: Two same-key payment writers retain one attempt category: concurrency level: api proves: - BR-CAP-COM-ORD-007-01 - INV-DOM-COM-ORD-002-07 preconditions: Two database connections record payment with one key on a placed order. steps: - do: 'Hold the first transaction until the second waits, then commit.' provenance: test 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 expected: The second receives the first attempt and one payment-attempt record remains. negative: false data_needs: Use an isolated workspace with the records and responses named in the preconditions. bound_to: - >- services-commerce:modules/orders/tests/integration/services/persistence/orders.integration.spec.js#lets the first record the tender - >- services-commerce:modules/orders/tests/integration/services/persistence/orders.integration.spec.js#answers the second the same tender, created: false, once the first committed - >- services-commerce:modules/orders/tests/integration/services/persistence/orders.integration.spec.js#leaves exactly one tender on the order - TST-COM-ORD-103 provenance: test 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 expected_provenance: test expected_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 - id: ATS-COM-ORD-007-17 title: A partially paid void returns only captured money category: interaction level: api proves: - BR-CAP-COM-ORD-007-07 - BR-CAP-COM-ORD-008-06 preconditions: A placed sale has a captured card leg and an applied credit leg. steps: - do: Void it and replay the money adjustment. provenance: proposed source: - >- services-commerce:modules/orders/tests/unit/tender/tender-rules.spec.js#leaves a credit leg that applied less than it asked at what it applied, so the order still owes the rest - >- 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 invoice credit, the credit follows its own treatment and replay sends no extra 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/orders/tests/unit/tender/tender-rules.spec.js#leaves a credit leg that applied less than it asked at what it applied, so the order still owes the rest - >- 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 exercises: - CAP-COM-ORD-007 - CAP-COM-ORD-008 related_capabilities: - CAP-COM-ORD-008 expected_provenance: proposed expected_source: - >- services-commerce:modules/orders/tests/unit/tender/tender-rules.spec.js#leaves a credit leg that applied less than it asked at what it applied, so the order still owes the rest - >- 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-007-18 title: Applied payments update the order’s balance category: interaction level: api proves: - BR-CAP-COM-ORD-007-07 - BR-CAP-COM-ORD-010-06 preconditions: A billed sale receives less credit than requested. steps: - do: 'Read its money, pay the remainder and read again.' provenance: proposed source: - >- services-commerce:modules/orders/tests/unit/tender/tender-rules.spec.js#leaves a credit leg that applied less than it asked at what it applied, so the order still owes the rest - >- services-commerce:modules/orders/tests/integration/services/mirror/refresh-money-mirror.integration.spec.js#raises accepted_without_invoice_line on the billed line the view lacks, one open row counting both findings, and still writes the mirror it could derive expected: The first read retains the unpaid remainder and the second shows acceptance with that remainder covered. 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/unit/tender/tender-rules.spec.js#leaves a credit leg that applied less than it asked at what it applied, so the order still owes the rest - >- services-commerce:modules/orders/tests/integration/services/mirror/refresh-money-mirror.integration.spec.js#raises accepted_without_invoice_line on the billed line the view lacks, one open row counting both findings, and still writes the mirror it could derive exercises: - CAP-COM-ORD-007 - CAP-COM-ORD-010 related_capabilities: - CAP-COM-ORD-010 expected_provenance: proposed expected_source: - >- services-commerce:modules/orders/tests/unit/tender/tender-rules.spec.js#leaves a credit leg that applied less than it asked at what it applied, so the order still owes the rest - >- services-commerce:modules/orders/tests/integration/services/mirror/refresh-money-mirror.integration.spec.js#raises accepted_without_invoice_line on the billed line the view lacks, one open row counting both findings, and still writes the mirror it could derive - id: ATS-COM-ORD-007-19 title: Uncertain deposit payment resumes the original attempt category: interaction level: api proves: - BR-CAP-COM-ORD-007-01 - BR-CAP-COM-ORD-006-01 - BR-CAP-COM-ORD-009-01 preconditions: A billed deposit sale loses its card response. steps: - do: 'Retry with another token, run recovery and read the schedule after success.' 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' expected: One attempt resolves and acceptance initiates one schedule under the sale key. 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#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' exercises: - CAP-COM-ORD-007 - CAP-COM-ORD-006 - CAP-COM-ORD-009 workflows: - WF-COM-ORD-004 expected_provenance: proposed expected_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' evidence: - >- Examined reference: react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows Receive Payment as a link to Accounting's Settle Invoices with the invoice selected, and no Take Payment - >- Examined reference: react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows Take Payment and Void Order on an unpaid pay-now order inside its window - >- Examined reference: react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows none of them on a paid order - >- Examined reference: react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows none of them to someone without the permissions - >- Examined reference: react-console:components/order-composer/__tests__/live-composer.test.tsx#bills on terms with the purchase order number, and takes no money - >- Examined reference: react-console:components/order-composer/__tests__/live-composer.test.tsx#keeps the placed order, awaiting payment, when the card pop-up is closed unpaid - >- Examined reference: react-console:components/order-composer/__tests__/live-composer.test.tsx#offers the payment methods the checkout policy allows, and no others - >- Examined reference: react-console:components/order-composer/__tests__/live-composer.test.tsx#places the order, then takes a card: declined first, approved on the same order - >- Examined reference: react-console:components/order-composer/__tests__/live-composer.test.tsx#records a check against the placed order with its number - >- Examined reference: services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#accepts the order on the leg that completes the total (08 row 14), the first leg captured - >- Examined reference: services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#accepts the order on the next attempt, under the next sequence and key - >- Examined reference: 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 - >- Examined reference: services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#answers 200 declined with the processor’s code, the order still placed with its pro forma, the attempt declined - >- Examined reference: 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 - >- Examined reference: services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#asks Accounting whether the merchant account may settle the tender: the order’s frozen default refused when ineligible, 409 merchant_account_not_eligible, a request naming an eligible account accepted - >- Examined reference: services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#lets staff record a money order and a cashier’s check as split payments, each under its Accounting method - >- Examined reference: services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#lets staff record cash for the rest although the policy lists no offline method, accepting the order - >- Examined reference: 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 - >- Examined reference: services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#pay later converts the pro forma to a real invoice and accepts the order on terms - >- Examined reference: services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a card outside the profile’s acceptance range on an order placed under it, 409 tender_kind_not_allowed naming the range, from the order’s snapshot - >- Examined reference: services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a member a second payment, 409 split_tender_not_allowed naming the policy - >- Examined reference: services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a second tender of the accepted order, 409 order_not_tenderable - >- Examined reference: services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a tender after the window 409 tender_window_expired and gives the sentence plain in the details, without the error class prefix (COMM-M2 R2-5) - >- Examined reference: services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses an offline tender by a member, 403 tender_kind_staff_only, and a kind the profile does not allow, 409, read from the ORDER’s snapshot: the order placed before the change still allows it (22 §9) - >- Examined reference: services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses the tender 409 order_not_billed when billing it now gets no answer either, charging nothing - >- Examined reference: 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 - >- Examined reference: services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#still refuses a member an offline tender under that policy, 409 tender_kind_not_allowed - >- Examined reference: services-commerce:modules/orders/tests/integration/services/orders/financial-sweeps.integration.spec.js#moves nothing while Accounting’s intent is still processing, and escalates nothing before fifteen minutes - >- Examined reference: services-commerce:modules/orders/tests/integration/services/orders/financial-sweeps.integration.spec.js#raises tender_uncertain on an attempt still uncertain past fifteen minutes - >- Examined reference: services-commerce:modules/orders/tests/integration/services/orders/financial-sweeps.integration.spec.js#resumes the attempt once Accounting’s sweeper has finished the intent: the payment on the attempt, the order accepted, one charge - >- Examined reference: services-commerce:modules/orders/tests/unit/tender/tender-kinds-of-profile.spec.js#admits terms only for a profile offering a collection option, and nothing for one offering nothing - >- Examined reference: services-commerce:modules/orders/tests/unit/tender/tender-rules.spec.js#declines a credit leg whose settlement applied nothing - >- Examined reference: services-commerce:modules/orders/tests/unit/tender/tender-rules.spec.js#is the total less the legs that succeeded, ignoring the declined and uncertain ones - >- Examined reference: services-commerce:modules/orders/tests/unit/tender/tender-rules.spec.js#leaves a credit leg that applied less than it asked at what it applied, so the order still owes the rest coverage: rule: covered transition: 'gap: FND-COM-ORD-064' validation: covered permission: 'gap: FND-COM-ORD-064' edge: 'gap: FND-COM-ORD-064' failure: covered boundary: covered concurrency: covered invariant: 'gap: FND-COM-ORD-064' interaction: covered coverage_definition: Covered means a design scenario exists; executable coverage and execution results are separate. permission_coverage: - key: commerce.orders.tender where_checked: api scenarios: - ATS-COM-ORD-007-13 gap: FND-COM-ORD-064 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-064 - key: commerce.orders.read where_checked: console scenarios: - ATS-COM-ORD-007-13 gap: FND-COM-ORD-064 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-064 transition_coverage: - 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-064 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: - ATS-COM-ORD-007-01 provenance: test 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: The cited test exercises this transition; other transitions retain separate gaps. - state_model: STATE-COM-ORD-004 from: tender_uncertain to: accepted trigger: Recovery confirms enough captured payment to accept. scenarios: - ATS-COM-ORD-007-01 provenance: test 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: The cited test exercises this transition; other transitions retain separate gaps. - 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-064 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-064 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-064 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-064 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.' - state_model: STATE-COM-ORD-006 from: pending to: submitted trigger: The recorded attempt proceeds to remote dispatch. scenarios: [] gap: FND-COM-ORD-064 provenance: unknown source: 'services-commerce:modules/orders/services/tender/tender-order.ts:tenderOrder' note: 'Individual examples do not exhaustively prove this transition, its guard and side effects.' - state_model: STATE-COM-ORD-006 from: submitted to: succeeded trigger: Accounting confirms the money movement. scenarios: - ATS-COM-ORD-007-07 provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#accepts the order on the leg that completes the total (08 row 14), the first leg captured note: The cited test exercises this transition; other transitions retain separate gaps. - state_model: STATE-COM-ORD-006 from: submitted to: declined trigger: Accounting or the processor reports a declined outcome. scenarios: - ATS-COM-ORD-007-05 provenance: test source: >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#answers 200 declined with the processor’s code, the order still placed with its pro forma, the attempt declined note: The cited test exercises this transition; other transitions retain separate gaps. - state_model: STATE-COM-ORD-006 from: submitted to: uncertain trigger: The request loses its answer or the intent remains unresolved. scenarios: [] gap: FND-COM-ORD-064 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-006 from: uncertain to: succeeded trigger: Recovery identifies the original successful payment. scenarios: - ATS-COM-ORD-007-01 provenance: test 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: The cited test exercises this transition; other transitions retain separate gaps. - state_model: STATE-COM-ORD-006 from: uncertain to: declined trigger: Recovery identifies a declined original attempt. scenarios: [] gap: FND-COM-ORD-064 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.' invariant_coverage: - invariant: INV-DOM-COM-ORD-002-01 scenarios: [] gap: FND-COM-ORD-064 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-064 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-064 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-064 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-064 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-064 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: - ATS-COM-ORD-007-16 gap: FND-COM-ORD-064 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-064 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-064 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-064 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-064 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-064 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-064 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-003 scenarios: - ATS-COM-ORD-006-16 gap: FND-COM-ORD-064 provenance: proposed source: - 'services-commerce:modules/orders/tests/e2e/order-discount-tax.e2e.spec.js' - 'services-commerce:modules/orders/services/billing/bill-order.ts:billOrder' - >- 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#bills a real invoice at placement and accepts the order on terms, the obligation waiting on the invoice - 'services-commerce:modules/orders/services/orders/financial-sweeps.ts:sweepBilling' - workflow: WF-COM-ORD-004 scenarios: - ATS-COM-ORD-007-19 gap: FND-COM-ORD-064 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-064 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-064 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-008 scenarios: - ATS-COM-ORD-010-12 gap: FND-COM-ORD-064 provenance: proposed source: - 'services-commerce:modules/orders/services/mirror/refresh-money-mirror.ts:refreshMoneyMirrorOf' - >- services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#mirrors Accounting’s position: invoiced and paid in full, nothing due - 'services-commerce:modules/orders/services/mirror/refresh-money-mirror.ts' - 'services-commerce:modules/fulfillment/services/facts/financial-facts-handler.ts' - 'services-commerce:modules/orders/services/orders/financial-sweeps.ts:sweepFinancials' - workflow: WF-COM-ORD-011 scenarios: - ATS-COM-ORD-015-15 gap: FND-COM-ORD-064 provenance: proposed source: - >- services-commerce:modules/orders/tests/e2e/amendments.e2e.spec.js#refuses a change order itself (409 order_not_amendable), an unknown product (409 product_not_found), another member, a reader and another tenant - >- services-commerce:modules/orders/tests/e2e/amendments.e2e.spec.js#marked the original line amended with its successor (nothing to fence: the type claims nothing), and wrote a modify obligation superseding the delivered fulfilment - >- services-commerce:modules/orders/tests/e2e/amendments.e2e.spec.js#credited the unused value from the original payment and applied it to the change invoice; the document awaits the buyer’s tender - 'services-commerce:modules/orders/services/amendments/amendment-settlement.ts:onChangeOrderVoided' - 'services-commerce:modules/orders/services/orders/accept-order.ts:acceptOrder' - >- services-commerce:modules/orders/tests/e2e/amendments.e2e.spec.js#completes once the buyer’s card accepts the change order and the worker delivers the modify: the original fulfilment superseded interaction_coverage: - with: CAP-COM-ORD-008 scenarios: - ATS-COM-ORD-007-17 - with: CAP-COM-ORD-010 scenarios: - ATS-COM-ORD-007-18 unproved_rules: - rule: BR-CAP-COM-ORD-007-12 gap: FND-COM-ORD-064 provenance: unknown source: 'services-commerce:docs/milestones/plans/COMM-M2-plan.md#A10' --- # Collect payment without duplicate charges: Capability Test Specification ## Coverage | Rule | Scenario or finding | |---|---| | `BR-CAP-COM-ORD-007-01` | `ATS-COM-ORD-007-01`, `ATS-COM-ORD-007-16`, `ATS-COM-ORD-007-19` | | `BR-CAP-COM-ORD-007-02` | `ATS-COM-ORD-007-02` | | `BR-CAP-COM-ORD-007-03` | `ATS-COM-ORD-007-03` | | `BR-CAP-COM-ORD-007-04` | `ATS-COM-ORD-007-04` | | `BR-CAP-COM-ORD-007-05` | `ATS-COM-ORD-007-05` | | `BR-CAP-COM-ORD-007-06` | `ATS-COM-ORD-007-06` | | `BR-CAP-COM-ORD-007-07` | `ATS-COM-ORD-007-07`, `ATS-COM-ORD-007-17`, `ATS-COM-ORD-007-18` | | `BR-CAP-COM-ORD-007-08` | `ATS-COM-ORD-007-08` | | `BR-CAP-COM-ORD-007-09` | `ATS-COM-ORD-007-09` | | `BR-CAP-COM-ORD-007-10` | `ATS-COM-ORD-007-10` | | `BR-CAP-COM-ORD-007-11` | `ATS-COM-ORD-007-11` | | `BR-CAP-COM-ORD-007-12` | no scenario: `FND-COM-ORD-064` | | `BR-CAP-COM-ORD-007-13` | `ATS-COM-ORD-007-12` | | `BR-CAP-COM-ORD-007-14` | `ATS-COM-ORD-007-13` | ## Interactions With Related Capabilities A partially paid void returns only captured money. A placed sale has a captured card leg and an applied credit leg. Void it and replay the money adjustment. Applied payments update the order’s balance. A billed sale receives less credit than requested. Read its money, pay the remainder and read again. Crossing workflow examples also cover preparation, commitment and recovery at their service handoffs. Their structured bindings distinguish specified outcomes from executable evidence.