--- id: TST-ACC-TRX-110 title: Record remittance suite kind: integration product_area: accounting module: transactions revision: 1 status: draft source_sha: services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8 repository: services-accounting files: - >- modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js implements: - ATS-ACC-TRX-010-05 implements_parts: - scenario: ATS-ACC-TRX-010-05 assertion: >- it writes 209 payments in the one transaction: 208 members’ and the remainder on Metro Transit provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js#it writes 209 payments in the one transaction: 208 members’ and the remainder on Metro Transit - scenario: ATS-ACC-TRX-010-05 assertion: >- it allocates each member’s payment wholly to that member’s invoice, and leaves the remainder unapplied on Metro Transit 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 - scenario: ATS-ACC-TRX-010-05 assertion: >- it allocates every member payment to its own member’s invoice and to no one else’s provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js#it allocates every member payment to its own member’s invoice and to no one else’s environment: local implementation_state: implemented latest_result: not-run latest_run_at: null latest_run_ref: null conformance: not-verified estimated_minutes: 3 isolation: >- Suite-marked records in the prepared local test database; fixture teardown removes owned records. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js evidence: - provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js assertion_titles: - 'recordRemittance: one employer, many members (integration)' - >- pre-fills from the expected remittances: the 212 invoices, each owing 180.00, billed to its member, expected from Metro Transit (premise) - >- records the remittance: number 1,000,000, recorded, Metro Transit by paper check, total = lines + remainder - >- writes 209 payments in the one transaction: 208 members’ and the remainder on Metro Transit - >- names Metro Transit the payer of every one, a paper check with the remittance’s reference, under the derived keys - >- allocates each member’s payment wholly to that member’s invoice, and leaves the remainder unapplied on Metro Transit - >- allocates every member payment to its own member’s invoice and to no one else’s - >- pays the 208 invoices and leaves the four of the members who left open, owing 180.00 each - 'still expects the four open invoices from Metro Transit, and no paid one' - >- writes one remittance line per line, in request order, each naming its member, its invoice and its own member’s payment - >- nets the receivable facts: the payments’ items sum to minus the remainder, the paid invoices’ to zero - >- answers the remittance with its 208 lines and its 209 payments, the remainder’s last, money in minor units - reads back the same remittance it answered - writes the remittance’s record document event - >- shows Metro Transit’s summary holding the remainder as its own unapplied money, not another party’s - a replay - answers the stored remittance and writes nothing - 'refuses the key with another body: idempotency_key_reused' imports: - 'const { sql } = require(''drizzle-orm'');' - 'const { stage } = require(''@rhythmsoftware/macroservice-testing/stage'');' - >- const { recordRemittance, getRemittance, listExpectedRemittances } = require('../../../../services/remittances/remittance-commands'); - >- const { summarizeCustomer } = require('../../../../services/customers/customer-summary'); - '} = require(''../../remittances-fixtures'');' - "\t\tconst { invoices } = world.require();" - "\t\tconst { items } = expectedBefore.require();" - "\t\tconst { remittance } = recorded.require();" - "\t\tconst { left } = recorded.require();" - "\t\tconst { remittance, kept } = recorded.require();" - "\t\tconst { remittance } = recorded.require();" - "\t\tconst { remittance } = recorded.require();" - "\t\tconst { remittance } = recorded.require();" - "\t\t\tconst { request } = recorded.require();" - "\t\t\tconst { remittance } = recorded.require();" - "\t\t\tconst { answer, before, after } = replayed.require();" - "\t\t\tconst { request } = recorded.require();" test_double_declarations: [] --- # Record remittance suite ## Verification Boundary The suite exercises transaction commands and database protections in the local prepared test environment. Registration records the existing executable file; it does not report a run or establish product approval. ## What This Suite Proves Its cited assertions contribute evidence for employer excess stays with the employer. The structured assertion bindings identify which parts of combined scenarios it executes. ## What It Does Not Prove Local commands and route invocations do not establish deployed routing, live processor guarantees or the complete staff browser experience. An unbound feature chain remains proposed, and this registration carries no execution result. ## Real Dependencies and Test Doubles The suite uses the imported commands, route handlers or persistence code against the local test database. Fixture helpers supply accounting context; any stepped clock, dummy processor or substituted external client is retained in the evidence declarations. ## Must Not Be Doubled The command or persistence behavior under assertion and its relevant database protections must remain real. Substituting the final financial result removes evidence of transactional effects.