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.
Render an issued 80.00 bill, amend an unpaid line to 100.00, then render and send the changed bill under a fresh delivery key.
The later document shows the revised amount and revision; delivery submission retains the current rendering without replacing the earlier financial history. The complete chain remains proposed until one executable run proves its combined outcomes.
Coverage
Rulecovered
Transitionnot-applicable
Validationcovered
Permissioncovered
Edgecovered
Failurecovered
Boundarycovered
Concurrencygap: FND-ACC-TRX-070
Invariantcovered
Interactioncovered
Test Scenarios
8 scenarios proving CAP-ACC-TRX-005; 6 bound to an existing test.
01Rendering selects the applicable document designruleapitest
Examples use invoice, unit and default templates plus inactive and wrong-kind choices.
Steps
[
{
"do": "Render each invoice.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/invoices/render-invoice.integration.spec.js#it is the invoice’s own template over its unit’s"
}
]
Expected
The precedence selects the proper design and invalid named choices fail.
[
{
"do": "Request HTML and an unsupported format.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/e2e/invoice-documents.e2e.spec.js#it refuses a format other than html: 400"
}
]
Expected
Fresh HTML contains the document data; unsupported format fails without a stored rendering.
Draft, addressless contact, organization and addressed contact examples exist.
Steps
[
{
"do": "Attempt each send, supply explicit recipients, then submit eleven or malformed addresses.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/invoices/email-invoice.integration.spec.js#it refuses a draft: it has no number and no receivable"
}
]
Expected
Ineligible sends fail; explicit recipients replace the default and invalid recipient lists fail.
[
{
"do": "Send without a key, then repeat a keyed send.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/invoices/email-invoice.integration.spec.js#it refuses an e-mail without an idempotency key: 400 idempotency_key_required"
}
]
Expected
Missing identity fails and repetition retains one submission reference.
The communication sender throws during submission.
Steps
[
{
"do": "Request invoice delivery.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/integration/services/invoices/email-invoice.integration.spec.js#it writes nothing, not even the event, when the sender’s statement fails: the command’s transaction rolls back"
}
]
Expected
Neither the communication request nor e-mail event remains.
[
{
"do": "Request document and e-mail through each identity.",
"provenance": "test",
"source": "services-accounting:modules/transactions/tests/e2e/invoice-documents.e2e.spec.js#it refuses the e-mail to a principal holding only accounting.invoices.read: 403, submitting nothing"
}
]
An isolated workspace has eligible customers, products, matching accounts, an open period and two open batches. Each branch owns separate financial records.
Steps
[
{
"do": "Render an issued 80.00 bill, amend an unpaid line to 100.00, then render and send the changed bill under a fresh delivery key.",
"provenance": "proposed",
"source": "services-accounting:modules/transactions/tests/e2e/invoice-documents.e2e.spec.js#it refuses a format other than html: 400; services-accounting:modules/transactions/tests/integration/services/invoices/email-invoice.integration.spec.js#it refuses an e-mail without an idempotency key: 400 idempotency_key_required; services-accounting:modules/transactions/tests/integration/services/invoices/email-invoice.integration.spec.js#it writes nothing, not even the event, when the sender’s statement fails: the command’s transaction rolls back; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-016-e-mail-an-invoice.md#WF-ACC-TRX-016; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-005-send-a-customer-their-invoice.md#BR-CAP-ACC-TRX-005-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-005-send-a-customer-their-invoice.md#BR-CAP-ACC-TRX-005-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-005-send-a-customer-their-invoice.md#BR-CAP-ACC-TRX-005-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-002-correct-or-cancel-an-issued-invoice-before-its-batch-posts.md#BR-CAP-ACC-TRX-002-01; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-002-correct-or-cancel-an-issued-invoice-before-its-batch-posts.md#BR-CAP-ACC-TRX-002-03"
}
]
Expected
The later document shows the revised amount and revision; delivery submission retains the current rendering without replacing the earlier financial history.
Data
Separate command keys, two customers, invoice lines, receipts and credit; controlled processor outcomes and a fixed calendar where the branch requires them.
An issued bill has ten distinct valid explicit recipients and a working sender.
Steps
[
{
"do": "Send to ten recipients, then submit a separately keyed request naming eleven.",
"provenance": "proposed",
"source": "services-accounting:modules/transactions/services/invoices/invoice-emails.ts:emailInvoice; services-accounting:modules/transactions/tests/integration/services/invoices/email-invoice.integration.spec.js#it refuses more than ten addresses: 400"
}
]
Expected
The first request supplies one communication for the ten recipients; the second fails before submission.
Data
Branch-owned records in one configured workspace, valid accounting context and controlled requests at the stated boundary.