Rhythm 2.0 Specifications

Appearance

ATS-ACC-TRX-008Allocate and relocate received money: Capability Test Specification

Markdown

ATS-ACC-TRX-008

Allocate and relocate received money: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-ACC-TRX-008

Design

Executed by
TST-ACC-TRX-070, TST-ACC-TRX-072, TST-ACC-TRX-081, TST-ACC-TRX-242, TST-ACC-TRX-256

KindAcceptance test setProduct areaAccountingModuleTransactionsRevision2

Read atservices-accounting f47cb263react-console baf6dae3

Allocate and relocate received money: Capability Test Specification ​

Coverage ​

The structured coverage map distinguishes specified examples from missing category coverage. Every required rule names its proving scenarios in the structured rule coverage register. A scenario’s executable binding applies only to the cited assertions; the transition and permission registers retain the combinations that still need explicit proof.

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.

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

Test Scenarios

9 scenarios proving CAP-ACC-TRX-008; 8 bound to an existing test.

01 Allocation rejects incompatible invoice contextvalidationapinegativetest
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.
Data
Invoices in two business units.
Bound to
Source
services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it refuses an invoice of another unit (business_unit_mismatch)
02 Customer eligibility applies across allocation pathsboundaryapinegativetest
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.
Data
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
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
03 Target granularity controls distributionruleapitest
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.
Data
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
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
04 Overspending and races retain valid balancesconcurrencyapinegativetest
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.
Data
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 serialize, and the second is refused by the database’s balance CHECK, not by code
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
05 Allocation history resists direct mutationinvariantunitnegativetest
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.
Data
Application-role database access.
Bound to
Source
services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses an UPDATE of an allocation row
06 Reallocation keeps its original trailtransitionapitest
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.
Data
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)
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
07 Void receipts cannot fund applicationsvalidationapinegativetest
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.
Data
A void payment record.
Bound to
Source
services-accounting:modules/transactions/tests/integration/services/payments/allocate.integration.spec.js#it refuses allocating a voided payment (payment_not_live)
08 First payment recognizes the quoteinteractionapitest
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.
Data
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)
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)
09 Released allocation value remains available only onceinteractionapiproposed
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
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.
Data
Separate command keys, two customers, invoice lines, receipts and credit; controlled processor outcomes and a fixed calendar where the branch requires them.
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

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

Rhythm Software