--- id: ATS-ACC-TRX-008 scope: CAP-ACC-TRX-008 product_area: accounting module: transactions revision: 1 status: proposed approved_by: null approved_at: null source_sha: services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f scenarios: - id: ATS-ACC-TRX-008-01 title: Allocation rejects incompatible invoice context level: api proves: - BR-CAP-ACC-TRX-008-01 preconditions: Targets include a draft and a foreign-unit invoice. steps: - do: Record money against each target. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it refuses an invoice of another unit (business_unit_mismatch) expected: Both applications are rejected. negative: true data_needs: Invoices in two business units. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it refuses a draft invoice’s line (invoice_not_draft) - >- services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it refuses an invoice of another unit (business_unit_mismatch) - TST-ACC-TRX-081 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it refuses an invoice of another unit (business_unit_mismatch) category: validation test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js assertion: it refuses a draft invoice’s line (invoice_not_draft) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it refuses a draft invoice’s line (invoice_not_draft) - file: >- services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js assertion: it refuses an invoice of another unit (business_unit_mismatch) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it refuses an invoice of another unit (business_unit_mismatch) binding_review: [] - id: ATS-ACC-TRX-008-02 title: Customer eligibility applies across allocation paths level: api proves: - BR-CAP-ACC-TRX-008-02 - INV-DOM-ACC-TRX-003-08 preconditions: An employer receipt and an unrelated member invoice exist. steps: - do: >- Attempt initial, later, moved and planned-card applications, then select the employer’s invoice. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/customer-guard.integration.spec.js#it refuses allocating unapplied money to another customer’s invoice, leaving the payment unapplied expected: Foreign-customer requests fail and the matching-customer target succeeds. negative: true data_needs: Two separate customer identities. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/payments/customer-guard.integration.spec.js#it refuses receiving a payment with an allocation to another customer’s invoice, naming it plainly - >- services-accounting:modules/transactions/tests/integration/services/payments/customer-guard.integration.spec.js#it refuses allocating unapplied money to another customer’s invoice, leaving the payment unapplied - >- services-accounting:modules/transactions/tests/integration/services/payments/customer-guard.integration.spec.js#it refuses reallocating money onto another customer’s invoice, keeping the allocation it would have reversed - >- services-accounting:modules/transactions/tests/integration/services/payments/customer-guard.integration.spec.js#it refuses a card payment planned against another customer’s invoice - >- services-accounting:modules/transactions/tests/integration/services/payments/customer-guard.integration.spec.js#it accepts the payment’s own customer’s invoice - TST-ACC-TRX-072 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/customer-guard.integration.spec.js#it refuses allocating unapplied money to another customer’s invoice, leaving the payment unapplied category: boundary test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/payments/customer-guard.integration.spec.js assertion: >- it refuses receiving a payment with an allocation to another customer’s invoice, naming it plainly provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/customer-guard.integration.spec.js#it refuses receiving a payment with an allocation to another customer’s invoice, naming it plainly - file: >- services-accounting:modules/transactions/tests/integration/services/payments/customer-guard.integration.spec.js assertion: >- it refuses allocating unapplied money to another customer’s invoice, leaving the payment unapplied provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/customer-guard.integration.spec.js#it refuses allocating unapplied money to another customer’s invoice, leaving the payment unapplied - file: >- services-accounting:modules/transactions/tests/integration/services/payments/customer-guard.integration.spec.js assertion: >- it refuses reallocating money onto another customer’s invoice, keeping the allocation it would have reversed provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/customer-guard.integration.spec.js#it refuses reallocating money onto another customer’s invoice, keeping the allocation it would have reversed - file: >- services-accounting:modules/transactions/tests/integration/services/payments/customer-guard.integration.spec.js assertion: it refuses a card payment planned against another customer’s invoice provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/customer-guard.integration.spec.js#it refuses a card payment planned against another customer’s invoice - file: >- services-accounting:modules/transactions/tests/integration/services/payments/customer-guard.integration.spec.js assertion: it accepts the payment’s own customer’s invoice provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/customer-guard.integration.spec.js#it accepts the payment’s own customer’s invoice binding_review: [] - id: ATS-ACC-TRX-008-03 title: Target granularity controls distribution level: api proves: - BR-CAP-ACC-TRX-008-03 preconditions: One target is a line and another an invoice with two lines. steps: - do: Allocate the stated line amount and invoice amount. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it spreads the invoice target by pay priority: the second invoice’s first line takes 5000 expected: >- The line receives its exact target and invoice priority fills the first eligible line first. negative: false data_needs: A multiple-line invoice population. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it spreads the invoice target by pay priority: the second invoice’s first line takes 5000 - >- services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it allocates the line target exactly and the invoice target by pay priority, the second line taking the 3000 - TST-ACC-TRX-070 - TST-ACC-TRX-081 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it spreads the invoice target by pay priority: the second invoice’s first line takes 5000 category: rule test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js assertion: >- it spreads the invoice target by pay priority: the second invoice’s first line takes 5000 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it spreads the invoice target by pay priority: the second invoice’s first line takes 5000 - file: >- services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js assertion: >- it allocates the line target exactly and the invoice target by pay priority, the second line taking the 3000 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it allocates the line target exactly and the invoice target by pay priority, the second line taking the 3000 binding_review: [] - id: ATS-ACC-TRX-008-04 title: Overspending and races retain valid balances level: api proves: - BR-CAP-ACC-TRX-008-04 - INV-DOM-ACC-TRX-003-09 preconditions: A receipt holds 10.00 and a target line owes 40.00. steps: - do: >- Request 10.01 from the receipt, 40.01 on the line and competing final-value applications. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it serialize, and the second is refused by the database’s balance CHECK, not by code expected: Over-limit requests leave no writes and only one competing spend succeeds. negative: true data_needs: Two simultaneous clients. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses more than the payment holds (over_application), writing nothing - >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses more than a line owes (over_application) - >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it serialize, and the second is refused by the database’s balance CHECK, not by code - >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0321.spec.ts#ACT-ACC-0321 - TST-ACC-TRX-070 - TST-ACC-TRX-256 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it serialize, and the second is refused by the database’s balance CHECK, not by code category: concurrency test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js assertion: >- it refuses more than the payment holds (over_application), writing nothing provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses more than the payment holds (over_application), writing nothing - file: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js assertion: it refuses more than a line owes (over_application) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses more than a line owes (over_application) - file: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js assertion: >- it serialize, and the second is refused by the database’s balance CHECK, not by code provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it serialize, and the second is refused by the database’s balance CHECK, not by code - file: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0321.spec.ts assertion: ACT-ACC-0321 provenance: test source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0321.spec.ts#ACT-ACC-0321 binding_review: - binding: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0321.spec.ts#ACT-ACC-0321 completeness: not-verified provenance: observed source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0321.spec.ts#ACT-ACC-0321 note: >- This citation remains component evidence. A browser request driven through an API helper does not establish direct database checks or every branch of the combined scenario. - id: ATS-ACC-TRX-008-05 title: Allocation history resists direct mutation level: unit proves: - BR-CAP-ACC-TRX-008-05 - INV-DOM-ACC-TRX-003-10 preconditions: A retained allocation and payment amounts exist. steps: - do: Attempt update and deletion through the application database role. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses an UPDATE of an allocation row expected: Protected rows and derived amounts cannot be edited directly. negative: true data_needs: Application-role database access. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses an UPDATE of an allocation row - >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses a DELETE of an allocation row - >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses an UPDATE of the payment’s maintained amounts - TST-ACC-TRX-070 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses an UPDATE of an allocation row category: invariant test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js assertion: it refuses an UPDATE of an allocation row provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses an UPDATE of an allocation row - file: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js assertion: it refuses a DELETE of an allocation row provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses a DELETE of an allocation row - file: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js assertion: it refuses an UPDATE of the payment’s maintained amounts provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses an UPDATE of the payment’s maintained amounts binding_review: [] - id: ATS-ACC-TRX-008-06 title: Reallocation keeps its original trail level: api proves: - BR-CAP-ACC-TRX-008-06 preconditions: A 50.00 application paid the wrong invoice. steps: - do: >- Move 40.00 to the intended invoice and repeat reversal of the old application. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it writes a reversing row for the 5000 and a new row for the 4000, the original marked reversed in full expected: >- Opposing and replacement entries remain, 10.00 is available and the already reversed allocation fails. negative: false data_needs: A misallocated receipt. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it writes a reversing row for the 5000 and a new row for the 4000, the original marked reversed in full - >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses taking back an allocation already reversed (allocation_not_live) - >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0304.spec.ts#ACT-ACC-0304 - TST-ACC-TRX-070 - TST-ACC-TRX-242 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it writes a reversing row for the 5000 and a new row for the 4000, the original marked reversed in full category: transition test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js assertion: >- it writes a reversing row for the 5000 and a new row for the 4000, the original marked reversed in full provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it writes a reversing row for the 5000 and a new row for the 4000, the original marked reversed in full - file: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js assertion: >- it refuses taking back an allocation already reversed (allocation_not_live) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses taking back an allocation already reversed (allocation_not_live) - file: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0304.spec.ts assertion: ACT-ACC-0304 provenance: test source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0304.spec.ts#ACT-ACC-0304 binding_review: - binding: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0304.spec.ts#ACT-ACC-0304 completeness: not-verified provenance: observed source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0304.spec.ts#ACT-ACC-0304 note: >- This citation remains component evidence. A browser request driven through an API helper does not establish direct database checks or every branch of the combined scenario. - id: ATS-ACC-TRX-008-07 title: Void receipts cannot fund applications level: api proves: - BR-CAP-ACC-TRX-008-07 preconditions: The payment is already voided. steps: - do: Request an allocation. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses allocating a voided payment (payment_not_live) expected: Live-payment validation rejects it. negative: true data_needs: A void payment record. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses allocating a voided payment (payment_not_live) - TST-ACC-TRX-070 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses allocating a voided payment (payment_not_live) category: validation test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js assertion: it refuses allocating a voided payment (payment_not_live) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses allocating a voided payment (payment_not_live) binding_review: [] - id: ATS-ACC-TRX-008-08 title: First payment recognizes the quote level: api proves: - BR-CAP-ACC-TRX-008-08 preconditions: An issued pro forma has no recognized debt. steps: - do: Receive payment against it. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it converts an unconverted pro forma the first payment names, in the payment’s batch, and pays it (Commerce’s first payment makes it real) expected: Conversion recognizes the bill in the payment batch and settles it. negative: false data_needs: An eligible quote and payment context. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it converts an unconverted pro forma the first payment names, in the payment’s batch, and pays it (Commerce’s first payment makes it real) - TST-ACC-TRX-081 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it converts an unconverted pro forma the first payment names, in the payment’s batch, and pays it (Commerce’s first payment makes it real) category: interaction test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js assertion: >- it converts an unconverted pro forma the first payment names, in the payment’s batch, and pays it (Commerce’s first payment makes it real) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it converts an unconverted pro forma the first payment names, in the payment’s batch, and pays it (Commerce’s first payment makes it real) binding_review: [] - id: ATS-ACC-TRX-008-09 title: Released allocation value remains available only once category: interaction level: api proves: - BR-CAP-ACC-TRX-008-04 - BR-CAP-ACC-TRX-008-05 - BR-CAP-ACC-TRX-008-06 - BR-CAP-ACC-TRX-003-04 - BR-CAP-ACC-TRX-006-08 - BR-CAP-ACC-TRX-007-03 - BR-CAP-ACC-TRX-007-05 - BR-CAP-ACC-TRX-009-03 - BR-CAP-ACC-TRX-009-04 - BR-CAP-ACC-TRX-011-02 - BR-CAP-ACC-TRX-011-03 - BR-CAP-ACC-TRX-020-03 exercises: - CAP-ACC-TRX-008 - CAP-ACC-TRX-003 - CAP-ACC-TRX-006 - CAP-ACC-TRX-007 - CAP-ACC-TRX-009 - CAP-ACC-TRX-011 - CAP-ACC-TRX-020 preconditions: >- An isolated workspace has eligible customers, products, matching accounts, an open period and two open batches. Each branch owns separate financial records. steps: - do: >- Receive and allocate 80.00 offline, move that application to another bill and convert its 20.00 remainder into credit. Credit a separately paid bill to release money, and compare a processor-funded application with a credit-and-money settlement. Invoke the processor-funded branch through Commerce’s tender function and repeat its command key. provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it serialize, and the second is refused by the database’s balance CHECK, not by code; services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses an UPDATE of an allocation row; services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it writes a reversing row for the 5000 and a new row for the 4000, the original marked reversed in full; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-003-issue-or-void-a-credit-or-debit-memo.md#WF-ACC-TRX-003; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-005-record-money-received-by-hand-and-place-it.md#WF-ACC-TRX-005; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-006-take-a-card-or-bank-payment-through-the-processor.md#WF-ACC-TRX-006; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-003-reduce-or-add-to-an-issued-invoice-with-credit-and-debit.md#BR-CAP-ACC-TRX-003-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-006-record-money-received-by-hand.md#BR-CAP-ACC-TRX-006-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-03 expected: >- Each move retains opposing entries; credit removes exactly 20.00 from available receipt money; the memo releases only unnecessary paid value; processor and settlement paths preserve source and target bounds. negative: false data_needs: >- Separate command keys, two customers, invoice lines, receipts and credit; controlled processor outcomes and a fixed calendar where the branch requires them. bound_to: [] provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it serialize, and the second is refused by the database’s balance CHECK, not by code; services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses an UPDATE of an allocation row; services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it writes a reversing row for the 5000 and a new row for the 4000, the original marked reversed in full; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-003-issue-or-void-a-credit-or-debit-memo.md#WF-ACC-TRX-003; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-005-record-money-received-by-hand-and-place-it.md#WF-ACC-TRX-005; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-006-take-a-card-or-bank-payment-through-the-processor.md#WF-ACC-TRX-006; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-003-reduce-or-add-to-an-issued-invoice-with-credit-and-debit.md#BR-CAP-ACC-TRX-003-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-006-record-money-received-by-hand.md#BR-CAP-ACC-TRX-006-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-03 test_bindings: [] binding_review: [] evidence: - >- services-accounting at f47cb263875bbc0c5640fba7dae6785ec32695f8: the test files named in bound_to. - >- react-console at baf6dae382d6f41dce976c7f848667ccc37e076f: the Playwright journeys ACT-ACC-0304, 0321. - >- rhythm-v2-docs:specs/accounting/transactions/design: related workflows, domain invariants and state transitions examined for the back-fill. coverage: rule: covered transition: 'gap: FND-ACC-TRX-073' validation: covered permission: 'gap: FND-ACC-TRX-073' edge: 'gap: FND-ACC-TRX-073' failure: 'gap: FND-ACC-TRX-073' boundary: covered concurrency: covered invariant: covered interaction: covered coverage_notes: permission: >- No dedicated permission scenario covers the applicable conditions; the finding identifies the remaining specification work. edge: >- No dedicated edge scenario covers the applicable conditions; the finding identifies the remaining specification work. failure: >- No dedicated failure scenario covers the applicable conditions; the finding identifies the remaining specification work. transition: >- Selected transition scenarios exist, but the listed state paths still need explicit guard, effect and actor mappings. interaction_coverage: - to: CAP-ACC-TRX-003 scenarios: - ATS-ACC-TRX-008-09 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it serialize, and the second is refused by the database’s balance CHECK, not by code; services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses an UPDATE of an allocation row; services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it writes a reversing row for the 5000 and a new row for the 4000, the original marked reversed in full; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-003-issue-or-void-a-credit-or-debit-memo.md#WF-ACC-TRX-003; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-005-record-money-received-by-hand-and-place-it.md#WF-ACC-TRX-005; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-006-take-a-card-or-bank-payment-through-the-processor.md#WF-ACC-TRX-006; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-003-reduce-or-add-to-an-issued-invoice-with-credit-and-debit.md#BR-CAP-ACC-TRX-003-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-006-record-money-received-by-hand.md#BR-CAP-ACC-TRX-006-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-03 - to: CAP-ACC-TRX-006 scenarios: - ATS-ACC-TRX-008-09 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it serialize, and the second is refused by the database’s balance CHECK, not by code; services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses an UPDATE of an allocation row; services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it writes a reversing row for the 5000 and a new row for the 4000, the original marked reversed in full; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-003-issue-or-void-a-credit-or-debit-memo.md#WF-ACC-TRX-003; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-005-record-money-received-by-hand-and-place-it.md#WF-ACC-TRX-005; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-006-take-a-card-or-bank-payment-through-the-processor.md#WF-ACC-TRX-006; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-003-reduce-or-add-to-an-issued-invoice-with-credit-and-debit.md#BR-CAP-ACC-TRX-003-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-006-record-money-received-by-hand.md#BR-CAP-ACC-TRX-006-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-03 - to: CAP-ACC-TRX-007 scenarios: - ATS-ACC-TRX-008-09 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it serialize, and the second is refused by the database’s balance CHECK, not by code; services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses an UPDATE of an allocation row; services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it writes a reversing row for the 5000 and a new row for the 4000, the original marked reversed in full; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-003-issue-or-void-a-credit-or-debit-memo.md#WF-ACC-TRX-003; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-005-record-money-received-by-hand-and-place-it.md#WF-ACC-TRX-005; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-006-take-a-card-or-bank-payment-through-the-processor.md#WF-ACC-TRX-006; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-003-reduce-or-add-to-an-issued-invoice-with-credit-and-debit.md#BR-CAP-ACC-TRX-003-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-006-record-money-received-by-hand.md#BR-CAP-ACC-TRX-006-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-03 - to: CAP-ACC-TRX-009 scenarios: - ATS-ACC-TRX-008-09 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it serialize, and the second is refused by the database’s balance CHECK, not by code; services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses an UPDATE of an allocation row; services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it writes a reversing row for the 5000 and a new row for the 4000, the original marked reversed in full; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-003-issue-or-void-a-credit-or-debit-memo.md#WF-ACC-TRX-003; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-005-record-money-received-by-hand-and-place-it.md#WF-ACC-TRX-005; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-006-take-a-card-or-bank-payment-through-the-processor.md#WF-ACC-TRX-006; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-003-reduce-or-add-to-an-issued-invoice-with-credit-and-debit.md#BR-CAP-ACC-TRX-003-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-006-record-money-received-by-hand.md#BR-CAP-ACC-TRX-006-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-03 - to: CAP-ACC-TRX-011 scenarios: - ATS-ACC-TRX-008-09 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it serialize, and the second is refused by the database’s balance CHECK, not by code; services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses an UPDATE of an allocation row; services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it writes a reversing row for the 5000 and a new row for the 4000, the original marked reversed in full; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-003-issue-or-void-a-credit-or-debit-memo.md#WF-ACC-TRX-003; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-005-record-money-received-by-hand-and-place-it.md#WF-ACC-TRX-005; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-006-take-a-card-or-bank-payment-through-the-processor.md#WF-ACC-TRX-006; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-003-reduce-or-add-to-an-issued-invoice-with-credit-and-debit.md#BR-CAP-ACC-TRX-003-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-006-record-money-received-by-hand.md#BR-CAP-ACC-TRX-006-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-03 - to: CAP-ACC-TRX-020 scenarios: - ATS-ACC-TRX-008-09 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it serialize, and the second is refused by the database’s balance CHECK, not by code; services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses an UPDATE of an allocation row; services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it writes a reversing row for the 5000 and a new row for the 4000, the original marked reversed in full; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-003-issue-or-void-a-credit-or-debit-memo.md#WF-ACC-TRX-003; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-005-record-money-received-by-hand-and-place-it.md#WF-ACC-TRX-005; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-006-take-a-card-or-bank-payment-through-the-processor.md#WF-ACC-TRX-006; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-003-reduce-or-add-to-an-issued-invoice-with-credit-and-debit.md#BR-CAP-ACC-TRX-003-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-006-record-money-received-by-hand.md#BR-CAP-ACC-TRX-006-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-03 transition_coverage: - state_model: STATE-ACC-TRX-001 transition: 1 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/invoices/invoice-drafts.ts; services-accounting:modules/transactions/services/invoices/invoice-issue.ts; services-accounting:modules/transactions/services/invoices/invoice-changes.ts; services-accounting:modules/transactions/services/invoices/invoice-amendments.ts; services-accounting:modules/transactions/db/invoices.table.ts; services-accounting:modules/transactions/db/invoice-lines.table.ts; services-accounting:modules/transactions/tests/integration/services/invoices/create-draft.integration.spec.js#it refuses an inactive product (product_not_sellable) - state_model: STATE-ACC-TRX-001 transition: 2 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/invoices/invoice-drafts.ts; services-accounting:modules/transactions/services/invoices/invoice-issue.ts; services-accounting:modules/transactions/services/invoices/invoice-changes.ts; services-accounting:modules/transactions/services/invoices/invoice-amendments.ts; services-accounting:modules/transactions/db/invoices.table.ts; services-accounting:modules/transactions/db/invoice-lines.table.ts; services-accounting:modules/transactions/tests/integration/services/invoices/update-draft.integration.spec.js#it refuses an update at a version the draft has moved past (stale) - state_model: STATE-ACC-TRX-001 transition: 3 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/invoices/invoice-drafts.ts; services-accounting:modules/transactions/services/invoices/invoice-issue.ts; services-accounting:modules/transactions/services/invoices/invoice-changes.ts; services-accounting:modules/transactions/services/invoices/invoice-amendments.ts; services-accounting:modules/transactions/db/invoices.table.ts; services-accounting:modules/transactions/db/invoice-lines.table.ts; services-accounting:modules/transactions/tests/integration/services/invoices/issue.integration.spec.js#it gives it no batch, no accounting date and no recognition (FC-06) - state_model: STATE-ACC-TRX-001 transition: 4 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/invoices/invoice-drafts.ts; services-accounting:modules/transactions/services/invoices/invoice-issue.ts; services-accounting:modules/transactions/services/invoices/invoice-changes.ts; services-accounting:modules/transactions/services/invoices/invoice-amendments.ts; services-accounting:modules/transactions/db/invoices.table.ts; services-accounting:modules/transactions/db/invoice-lines.table.ts; services-accounting:modules/transactions/tests/integration/services/invoices/issue.integration.spec.js#it refuses the issue when the unit has no assignment rules (batch_required), the draft unchanged - state_model: STATE-ACC-TRX-001 transition: 5 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/invoices/invoice-drafts.ts; services-accounting:modules/transactions/services/invoices/invoice-issue.ts; services-accounting:modules/transactions/services/invoices/invoice-changes.ts; services-accounting:modules/transactions/services/invoices/invoice-amendments.ts; services-accounting:modules/transactions/db/invoices.table.ts; services-accounting:modules/transactions/db/invoice-lines.table.ts; services-accounting:modules/transactions/tests/integration/services/invoices/issue.integration.spec.js#it is paid at once, its line with it - state_model: STATE-ACC-TRX-001 transition: 6 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:docs/architecture/accounting-2.0/05-lifecycles.md#1. The invoice - state_model: STATE-ACC-TRX-001 transition: 7 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/invoices/invoice-drafts.ts; services-accounting:modules/transactions/services/invoices/invoice-issue.ts; services-accounting:modules/transactions/services/invoices/invoice-changes.ts; services-accounting:modules/transactions/services/invoices/invoice-amendments.ts; services-accounting:modules/transactions/db/invoices.table.ts; services-accounting:modules/transactions/db/invoice-lines.table.ts; services-accounting:modules/transactions/tests/integration/services/invoices/issue.integration.spec.js#it gives it no batch, no accounting date and no recognition (FC-06) - state_model: STATE-ACC-TRX-001 transition: 8 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/invoices/invoice-drafts.ts; services-accounting:modules/transactions/services/invoices/invoice-issue.ts; services-accounting:modules/transactions/services/invoices/invoice-changes.ts; services-accounting:modules/transactions/services/invoices/invoice-amendments.ts; services-accounting:modules/transactions/db/invoices.table.ts; services-accounting:modules/transactions/db/invoice-lines.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it converts an unconverted pro forma the first payment names, in the payment’s batch, and pays it (Commerce’s first payment makes it real) - state_model: STATE-ACC-TRX-001 transition: 9 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/invoices/invoice-drafts.ts; services-accounting:modules/transactions/services/invoices/invoice-issue.ts; services-accounting:modules/transactions/services/invoices/invoice-changes.ts; services-accounting:modules/transactions/services/invoices/invoice-amendments.ts; services-accounting:modules/transactions/db/invoices.table.ts; services-accounting:modules/transactions/db/invoice-lines.table.ts; services-accounting:modules/transactions/tests/integration/services/invoices/issue.integration.spec.js#it gives it no batch, no accounting date and no recognition (FC-06) - state_model: STATE-ACC-TRX-001 transition: 10 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/invoices/invoice-drafts.ts; services-accounting:modules/transactions/services/invoices/invoice-issue.ts; services-accounting:modules/transactions/services/invoices/invoice-changes.ts; services-accounting:modules/transactions/services/invoices/invoice-amendments.ts; services-accounting:modules/transactions/db/invoices.table.ts; services-accounting:modules/transactions/db/invoice-lines.table.ts; services-accounting:modules/transactions/tests/integration/services/document-edits/reassign-and-edit.integration.spec.js#it answers the invoice at revision 2 with the line added after the last, the line repriced and the totals re-derived - state_model: STATE-ACC-TRX-001 transition: 11 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/invoices/invoice-drafts.ts; services-accounting:modules/transactions/services/invoices/invoice-issue.ts; services-accounting:modules/transactions/services/invoices/invoice-changes.ts; services-accounting:modules/transactions/services/invoices/invoice-amendments.ts; services-accounting:modules/transactions/db/invoices.table.ts; services-accounting:modules/transactions/db/invoice-lines.table.ts; services-accounting:modules/transactions/tests/integration/services/credits/credits.integration.spec.js#it raises the line’s amount_paid: a line settled by store credit reads open until fully paid, then paid - state_model: STATE-ACC-TRX-001 transition: 12 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/invoices/invoice-drafts.ts; services-accounting:modules/transactions/services/invoices/invoice-issue.ts; services-accounting:modules/transactions/services/invoices/invoice-changes.ts; services-accounting:modules/transactions/services/invoices/invoice-amendments.ts; services-accounting:modules/transactions/db/invoices.table.ts; services-accounting:modules/transactions/db/invoice-lines.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it reverses the live allocation so the line owes again, and the payment item’s facts sum to zero (FC-16) - state_model: STATE-ACC-TRX-001 transition: 13 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/invoices/invoice-drafts.ts; services-accounting:modules/transactions/services/invoices/invoice-issue.ts; services-accounting:modules/transactions/services/invoices/invoice-changes.ts; services-accounting:modules/transactions/services/invoices/invoice-amendments.ts; services-accounting:modules/transactions/db/invoices.table.ts; services-accounting:modules/transactions/db/invoice-lines.table.ts; services-accounting:modules/transactions/tests/integration/services/change-memos/credit-memos.integration.spec.js#it makes the credited line cancelled and leaves the invoice open with the other line’s 80.00 - state_model: STATE-ACC-TRX-001 transition: 14 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/invoices/invoice-drafts.ts; services-accounting:modules/transactions/services/invoices/invoice-issue.ts; services-accounting:modules/transactions/services/invoices/invoice-changes.ts; services-accounting:modules/transactions/services/invoices/invoice-amendments.ts; services-accounting:modules/transactions/db/invoices.table.ts; services-accounting:modules/transactions/db/invoice-lines.table.ts; services-accounting:modules/transactions/tests/integration/services/change-memos/credit-memos.integration.spec.js#it returns the invoice’s balances to what they were before the memo - state_model: STATE-ACC-TRX-001 transition: 15 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/invoices/invoice-drafts.ts; services-accounting:modules/transactions/services/invoices/invoice-issue.ts; services-accounting:modules/transactions/services/invoices/invoice-changes.ts; services-accounting:modules/transactions/services/invoices/invoice-amendments.ts; services-accounting:modules/transactions/db/invoices.table.ts; services-accounting:modules/transactions/db/invoice-lines.table.ts; services-accounting:modules/transactions/tests/integration/services/write-offs/write-offs.integration.spec.js#it makes the whole line written_off and keeps the partly written-off line and the invoice open - state_model: STATE-ACC-TRX-001 transition: 16 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/invoices/invoice-drafts.ts; services-accounting:modules/transactions/services/invoices/invoice-issue.ts; services-accounting:modules/transactions/services/invoices/invoice-changes.ts; services-accounting:modules/transactions/services/invoices/invoice-amendments.ts; services-accounting:modules/transactions/db/invoices.table.ts; services-accounting:modules/transactions/db/invoice-lines.table.ts; services-accounting:modules/transactions/tests/integration/services/write-offs/write-offs.integration.spec.js#it answers the reversal: a second write-off, numbered next, its lines negating the first’s - state_model: STATE-ACC-TRX-001 transition: 17 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/invoices/invoice-drafts.ts; services-accounting:modules/transactions/services/invoices/invoice-issue.ts; services-accounting:modules/transactions/services/invoices/invoice-changes.ts; services-accounting:modules/transactions/services/invoices/invoice-amendments.ts; services-accounting:modules/transactions/db/invoices.table.ts; services-accounting:modules/transactions/db/invoice-lines.table.ts; services-accounting:modules/transactions/tests/integration/services/invoices/void.integration.spec.js#it appends an invoice_voided fact per line for minus the line’s balance, dated today - state_model: STATE-ACC-TRX-006 transition: 1 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it refuses a date in no open period (period_not_open) - state_model: STATE-ACC-TRX-006 transition: 2 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it settles the one the bank cleared: succeeded, settled_at, its capture item eligible, the settle event - state_model: STATE-ACC-TRX-006 transition: 3 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it settles the one the bank cleared: succeeded, settled_at, its capture item eligible, the settle event - state_model: STATE-ACC-TRX-006 transition: 4 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it settles the one the bank cleared: succeeded, settled_at, its capture item eligible, the settle event - state_model: STATE-ACC-TRX-006 transition: 5 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it records it offline: executed, the payment partially_refunded with 1000 refunded (FC-11, FC-14) - state_model: STATE-ACC-TRX-006 transition: 6 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it records it offline: executed, the payment partially_refunded with 1000 refunded (FC-11, FC-14) - state_model: STATE-ACC-TRX-006 transition: 7 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it records it offline: executed, the payment partially_refunded with 1000 refunded (FC-11, FC-14) - state_model: STATE-ACC-TRX-006 transition: 8 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it reverses the live allocation so the line owes again, and the payment item’s facts sum to zero (FC-16) - state_model: STATE-ACC-TRX-006 transition: 9 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it refuses a kind the method does not allow (reversal_kind_mismatch): an ACH return of a check, a bounced check of a card - state_model: STATE-ACC-TRX-006 transition: 10 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/dispute-inquiry-lost.integration.spec.js#it writes no payment reversal and leaves the payment succeeded, nothing reversed permission_coverage: - key: accounting.payments.update where_checked: api gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing permission scenarios are retained; assertion-level coverage of this grant at every declared surface remains unverified. evidence: - >- rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#CAP-ACC-TRX-008 - key: accounting.payments.read where_checked: api gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 note: >- Existing permission scenarios are retained; assertion-level coverage of this grant at every declared surface remains unverified. evidence: - >- rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#CAP-ACC-TRX-008 rule_coverage: - rule: BR-CAP-ACC-TRX-008-01 scenarios: - ATS-ACC-TRX-008-01 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it refuses an invoice of another unit (business_unit_mismatch) - rule: BR-CAP-ACC-TRX-008-02 scenarios: - ATS-ACC-TRX-008-02 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/customer-guard.integration.spec.js#it refuses allocating unapplied money to another customer’s invoice, leaving the payment unapplied - rule: BR-CAP-ACC-TRX-008-03 scenarios: - ATS-ACC-TRX-008-03 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it spreads the invoice target by pay priority: the second invoice’s first line takes 5000 - rule: BR-CAP-ACC-TRX-008-04 scenarios: - ATS-ACC-TRX-008-04 - ATS-ACC-TRX-008-09 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it serialize, and the second is refused by the database’s balance CHECK, not by code - rule: BR-CAP-ACC-TRX-008-05 scenarios: - ATS-ACC-TRX-008-05 - ATS-ACC-TRX-008-09 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses an UPDATE of an allocation row - rule: BR-CAP-ACC-TRX-008-06 scenarios: - ATS-ACC-TRX-008-06 - ATS-ACC-TRX-008-09 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it writes a reversing row for the 5000 and a new row for the 4000, the original marked reversed in full - rule: BR-CAP-ACC-TRX-008-07 scenarios: - ATS-ACC-TRX-008-07 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses allocating a voided payment (payment_not_live) - rule: BR-CAP-ACC-TRX-008-08 scenarios: - ATS-ACC-TRX-008-08 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it converts an unconverted pro forma the first payment names, in the payment’s batch, and pays it (Commerce’s first payment makes it real) executable_gaps: - scenario: ATS-ACC-TRX-008-09 gap: FND-ACC-TRX-073 provenance: unknown source: FND-ACC-TRX-073 evidence: - >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it serialize, and the second is refused by the database’s balance CHECK, not by code; services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses an UPDATE of an allocation row; services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it writes a reversing row for the 5000 and a new row for the 4000, the original marked reversed in full; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-003-issue-or-void-a-credit-or-debit-memo.md#WF-ACC-TRX-003; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-005-record-money-received-by-hand-and-place-it.md#WF-ACC-TRX-005; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-006-take-a-card-or-bank-payment-through-the-processor.md#WF-ACC-TRX-006 invariant_coverage: - invariant: INV-DOM-ACC-TRX-003-08 scenarios: - ATS-ACC-TRX-008-02 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/customer-guard.integration.spec.js#it refuses allocating unapplied money to another customer’s invoice, leaving the payment unapplied note: >- The cited scenario and its constituent test assertions are the proof boundary. - invariant: INV-DOM-ACC-TRX-003-09 scenarios: - ATS-ACC-TRX-008-04 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it serialize, and the second is refused by the database’s balance CHECK, not by code note: >- The cited scenario and its constituent test assertions are the proof boundary. - invariant: INV-DOM-ACC-TRX-003-10 scenarios: - ATS-ACC-TRX-008-05 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses an UPDATE of an allocation row note: >- The cited scenario and its constituent test assertions are the proof boundary. --- # Allocate and relocate received money: Capability Test Specification ## Coverage The category map separates specified examples from recorded gaps. The table lists a scenario or finding for each rule requiring proof; a listed scenario may still be proposed. Executable bindings cover their cited assertions, while the transition, permission and invariant registers identify combinations that need further proof. | Required rule | Scenario or finding | |---|---| | `BR-CAP-ACC-TRX-008-01` | `ATS-ACC-TRX-008-01` | | `BR-CAP-ACC-TRX-008-02` | `ATS-ACC-TRX-008-02` | | `BR-CAP-ACC-TRX-008-03` | `ATS-ACC-TRX-008-03` | | `BR-CAP-ACC-TRX-008-04` | `ATS-ACC-TRX-008-04`, `ATS-ACC-TRX-008-09` | | `BR-CAP-ACC-TRX-008-05` | `ATS-ACC-TRX-008-05`, `ATS-ACC-TRX-008-09` | | `BR-CAP-ACC-TRX-008-06` | `ATS-ACC-TRX-008-06`, `ATS-ACC-TRX-008-09` | | `BR-CAP-ACC-TRX-008-07` | `ATS-ACC-TRX-008-07` | | `BR-CAP-ACC-TRX-008-08` | `ATS-ACC-TRX-008-08` | ## Interactions With Related Capabilities Receive and allocate 80.00 offline, move that application to another bill and convert its 20.00 remainder into credit. Credit a separately paid bill to release money, and compare a processor-funded application with a credit-and-money settlement. Invoke the processor-funded branch through Commerce’s tender function and repeat its command key. Each move retains opposing entries; credit removes exactly 20.00 from available receipt money; the memo releases only unnecessary paid value; processor and settlement paths preserve source and target bounds. The complete chain remains proposed until one executable run proves its combined outcomes.