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.
Receive 100.00 for an 80.00 bill, move the receipt to another open batch, reallocate its applied value to an equivalent bill, then void an eligible receipt in a separate branch. Complete another bill through credit and an offline settlement.
The moved receipt and its allocations retain their value; relocation restores the first bill and pays the second; void restores debt; settlement keeps payment and credit application separate. The complete chain remains proposed until one executable run proves its combined outcomes.
Coverage
Rulecovered
Transitiongap: FND-ACC-TRX-071
Validationcovered
Permissiongap: FND-ACC-TRX-071
Edgecovered
Failurecovered
Boundarycovered
Concurrencygap: FND-ACC-TRX-071
Invariantcovered
Interactioncovered
Test Scenarios
10 scenarios proving CAP-ACC-TRX-006; 9 bound to an existing test.
01Invalid money cannot become a receiptboundaryapinegativetest
[
{
"do": "Submit EUR value and noninteger minor-unit value.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it refuses an amount in another currency (currency_mismatch)"
}
]
Unknown, inactive, channel-excluded and reference-required methods are available as cases.
Steps
[
{
"do": "Enter receipts against each invalid choice.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/payments/payment-methods.integration.spec.js#it refuses a paper check named by id without its number, 400 payment_reference_required, writing nothing"
}
]
Expected
Each method refusal leaves payment data untouched.
[
{
"do": "Select each for a check, then omit an account.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it refuses a bank account of another unit (cash_account_mismatch)"
}
]
One unit has assignment rules and another has none.
Steps
[
{
"do": "Omit batch selection in both, then select an eligible batch explicitly.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it refuses a payment naming no batch in a unit with no batch assignment rule (batch_required), writing nothing"
}
]
Expected
Assignment chooses the active batch, absence fails, and explicit selection is retained.
[
{
"do": "Record the check using that date.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it refuses a date in no open period (period_not_open)"
}
]
[
{
"do": "Record two successful checks.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it numbers the tenant’s first payment 1,000,000, succeeded, in the bank account and the unit’s batch"
}
]
Expected
References advance from one million to its next number.
[
{
"do": "Receive 2,500.00 and settle only the debt.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it writes the payment item’s facts: minus the whole amount, then plus each allocation, summing to minus the unapplied money"
}
]
Expected
The remaining 1,500.00 agrees with the negative sum of payment receivable facts.
[
{
"do": "Record CRM and named offline payers, attempt processor payer entry and later payer editing.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/payments/payment-payer.integration.spec.js#it writes the payer once: the write-once trigger refuses a change (RHF01)"
}
]
Expected
Offline attribution is retained, processor input fails and later mutation is blocked.
A payment already retains its method and behavior.
Steps
[
{
"do": "Try method updates through the application and another database writer.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/payments/payment-methods.integration.spec.js#it refuses any other writer a change of a payment’s method (the write-once trigger, RHF01)"
}
]
Expected
Grant restrictions and the write-once constraint prevent either change.
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 100.00 for an 80.00 bill, move the receipt to another open batch, reallocate its applied value to an equivalent bill, then void an eligible receipt in a separate branch. Complete another bill through credit and an offline settlement.",
"provenance": "proposed",
"source": "services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it writes the payment item’s facts: minus the whole amount, then plus each allocation, summing to minus the unapplied money; services-accounting:modules/transactions/tests/integration/services/payments/payment-methods.integration.spec.js#it refuses any other writer a change of a payment’s method (the write-once trigger, RHF01); 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/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-006-record-money-received-by-hand.md#BR-CAP-ACC-TRX-006-10; 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-06; 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-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-015-move-a-transaction-to-another-batch-and-correct-its-details.md#BR-CAP-ACC-TRX-015-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-015-move-a-transaction-to-another-batch-and-correct-its-details.md#BR-CAP-ACC-TRX-015-04"
}
]
Expected
The moved receipt and its allocations retain their value; relocation restores the first bill and pays the second; void restores debt; settlement keeps payment and credit application separate.
Data
Separate command keys, two customers, invoice lines, receipts and credit; controlled processor outcomes and a fixed calendar where the branch requires them.