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.
Read financial standing and transaction rows after a service-created bill and receipt. Move the receipt to another batch, reload available actions, then change eligibility before executing an earlier action.
Displayed position still agrees with the financial records after movement; the changed action is rechecked and refused; the original service attribution remains retained. The complete chain remains proposed until one executable run proves its combined outcomes.
Coverage
Rulecovered
Transitionnot-applicable
Validationcovered
Permissioncovered
Edgegap: FND-ACC-TRX-081
Failuregap: FND-ACC-TRX-081
Boundarycovered
Concurrencygap: FND-ACC-TRX-081
Invariantcovered
Interactioncovered
Test Scenarios
8 scenarios proving CAP-ACC-TRX-016; 7 bound to an existing test.
01Action lists explain lifecycle and protectionpermissionunittest
Draft, issued, quote and locked documents exist with administrator and reader identities.
Steps
[
{
"do": "Inspect each action list.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/unit/actions/invoice-actions.spec.js#it lists issue, void and delete on a draft locked against updates and deletes, each with the lock’s refusal as disabled_reason"
}
]
Expected
Eligible transitions vary by standing, locks explain disabled actions and the reader receives none.
A reader and already issued invoice are available.
Steps
[
{
"do": "Attempt issue as the reader and issue on the real invoice.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/e2e/invoices.e2e.spec.js#it answers 409 to the issue action on an issued invoice"
}
]
Expected
Authority failure preserves the draft and lifecycle conflict rejects the second issue.
[
{
"do": "Open money records and their entry controls, then try writes.",
"provenance": "test",
"source": "react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0331.spec.ts#ACT-ACC-0331"
}
]
Expected
Disabled controls explain restrictions and attempted changes fail.
Two independent workspaces hold financial records.
Steps
[
{
"do": "Read and issue foreign invoices and inspect foreign memos and write-offs.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/e2e/invoices.e2e.spec.js#it answers 404 to issuing the other tenant’s invoice in this tenant, and leaves it a draft"
}
]
Credited, partly paid and refund-reserved records exist.
Steps
[
{
"do": "Query the combined financial dataset.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/db/transactions-views-d7.integration.spec.js#it answers the same invoice as credited in transactions_v, the list of every kind"
}
]
Expected
Credited billing has zero open value, partial billing has 40.00 and receipt value excludes its reservation.
Readers operate in either workspace or no workspace.
Steps
[
{
"do": "Read the transaction datasets in each context.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/db/transactions-view.integration.spec.js#it answers tenant B’s reader its own invoice alone, its customer’s name null where CRM has no such contact"
}
]
Expected
Each workspace exposes its own records and absent context exposes none.
[
{
"do": "Read its retained document events.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/persistence/document-events.queries.integration.spec.js#it lists the invoice’s three events oldest first, not the credit memo’s of the same id nor another tenant’s"
}
]
Expected
Three ordered events carry attribution and omit unrelated kind or workspace events.
An isolated workspace has eligible customers, products, matching accounts, an open period and two open batches. Each branch owns separate financial records.
Steps
[
{
"do": "Read financial standing and transaction rows after a service-created bill and receipt. Move the receipt to another batch, reload available actions, then change eligibility before executing an earlier action.",
"provenance": "proposed",
"source": "services-accounting:modules/transactions/tests/unit/actions/invoice-actions.spec.js#it lists issue, void and delete on a draft locked against updates and deletes, each with the lock’s refusal as disabled_reason; services-accounting:modules/transactions/tests/e2e/invoices.e2e.spec.js#it answers 409 to the issue action on an issued invoice; services-accounting:modules/transactions/tests/integration/db/transactions-views-d7.integration.spec.js#it answers the same invoice as credited in transactions_v, the list of every kind; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-016-find-transactions-and-see-what-can-be-done-next.md#BR-CAP-ACC-TRX-016-01; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-016-find-transactions-and-see-what-can-be-done-next.md#BR-CAP-ACC-TRX-016-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-016-find-transactions-and-see-what-can-be-done-next.md#BR-CAP-ACC-TRX-016-06; 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; 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-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-02; 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-06"
}
]
Expected
Displayed position still agrees with the financial records after movement; the changed action is rechecked and refused; the original service attribution remains retained.
Data
Separate command keys, two customers, invoice lines, receipts and credit; controlled processor outcomes and a fixed calendar where the branch requires them.