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.
Record a combined receipt for two members with 80.00 and 40.00 debt and an explicit 20.00 remitter remainder. Read member and remitter standing, then void the untouched remittance.
Member receipts settle only their own debt; the remitter holds 20.00; the combined void restores both debts and removes the held remainder. The complete chain remains proposed until one executable run proves its combined outcomes.
Coverage
Rulegap: FND-ACC-TRX-075
Transitiongap: FND-ACC-TRX-075
Validationcovered
Permissioncovered
Edgegap: FND-ACC-TRX-075
Failurecovered
Boundarycovered
Concurrencygap: FND-ACC-TRX-075
Invariantgap: FND-ACC-TRX-075
Interactioncovered
Test Scenarios
8 scenarios proving CAP-ACC-TRX-010; 6 bound to an existing test.
01Remittance authority also requires payment accesspermissionapinegativetest
[
{
"do": "Attempt entry and void as reader and inspect with remittance access alone.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/e2e/remittances.e2e.spec.js#it is refused recording and voiding as a reader, and reading as one without the payments’ key (403)"
}
]
[
{
"do": "Send 190.00 with no remainder and 200.00 with 10.00 remainder.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a total that is not the lines plus the remainder, writing nothing: remittance_total_mismatch"
}
]
Card and directly selected reference-required check methods exist.
Steps
[
{
"do": "Record with card, then with check lacking its number.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a card method: remittance_method_not_offline"
}
]
Cases include paid, foreign-currency, foreign-member, duplicate and excessive targets.
Steps
[
{
"do": "Record each case, placing excessive value after earlier valid members.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a line whose stated bill-to is not its invoice’s: business_unit_mismatch"
}
]
Expected
Every invalid request fails and earlier generated payments roll back.
Payroll expects 212 invoices but four members have left.
Steps
[
{
"do": "Record the 208 selected invoices and an explicit remainder.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js#it allocates each member’s payment wholly to that member’s invoice, and leaves the remainder unapplied on Metro Transit"
}
]
Expected
One transaction creates 208 member receipts and one employer-held remainder receipt with payer attribution.
Separate remittances are reusable, externally allocated and posted.
Steps
[
{
"do": "Void each and repeat the first void.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it voids every payment it made, taking their allocations back and returning the remainder"
}
]
Expected
Only the untouched receipt restores all debt; other and repeat requests preserve records.
An isolated workspace has eligible customers, products, matching accounts, an open period and two open batches. Each branch owns separate financial records.
Steps
[
{
"do": "Record a combined receipt for two members with 80.00 and 40.00 debt and an explicit 20.00 remitter remainder. Read member and remitter standing, then void the untouched remittance.",
"provenance": "proposed",
"source": "services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a line whose stated bill-to is not its invoice’s: business_unit_mismatch; services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js#it allocates each member’s payment wholly to that member’s invoice, and leaves the remainder unapplied on Metro Transit; services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it voids every payment it made, taking their allocations back and returning the remainder; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-012-record-and-void-a-remittance.md#WF-ACC-TRX-012; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-010-record-one-remitter-s-money-for-many-customers.md#BR-CAP-ACC-TRX-010-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-010-record-one-remitter-s-money-for-many-customers.md#BR-CAP-ACC-TRX-010-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-010-record-one-remitter-s-money-for-many-customers.md#BR-CAP-ACC-TRX-010-07; 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-01; 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-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-017-know-where-a-customer-stands.md#BR-CAP-ACC-TRX-017-01; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-017-know-where-a-customer-stands.md#BR-CAP-ACC-TRX-017-04"
}
]
Expected
Member receipts settle only their own debt; the remitter holds 20.00; the combined void restores both debts and removes the held remainder.
Data
Separate command keys, two customers, invoice lines, receipts and credit; controlled processor outcomes and a fixed calendar where the branch requires them.
Two independently keyed offline receipt requests contain distinct eligible member invoices with matching total amounts.
Steps
[
{
"do": "Submit the first with two hundred and fifty lines and the second with two hundred and fifty-one.",
"provenance": "proposed",
"source": "services-accounting:modules/transactions/aws/api/remittances.schemas.ts; services-accounting:modules/transactions/tests/unit/api/remittances-schemas.spec.js"
}
]
Expected
The first records the receipt; the second is refused during input validation without creating member payments.
Data
Branch-owned records in one configured workspace, valid accounting context and controlled requests at the stated boundary.