--- id: TST-ACC-BAT-116 title: Batch integration batch roller kind: integration product_area: accounting module: batches revision: 1 status: draft product_intent: proposed implementation_evidence: observed source_sha: services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8 repository: services-accounting files: - >- modules/batches/tests/integration/services/roll/batch-roller.integration.spec.js implements: - ATS-ACC-BAT-009-05 - ATS-ACC-BAT-009-09 - ATS-ACC-BAT-010-01 - ATS-ACC-BAT-010-02 - ATS-ACC-BAT-010-03 - ATS-ACC-BAT-010-04 - ATS-ACC-BAT-010-05 environment: local implementation_state: implemented latest_result: not-run latest_run_at: null latest_run_ref: null conformance: not-verified estimated_minutes: 5 isolation: >- The suite owns its test workspace or fixed integration fixtures in the prepared local database. assertion_sources: - scenario: ATS-ACC-BAT-009-05 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/roll/batch-roller.integration.spec.js#opens the first batch at once, from the plan, its occurrence the create’s instant - scenario: ATS-ACC-BAT-009-05 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/roll/batch-roller.integration.spec.js#saves a recurring batch whose first batch is refused, with the refusal and no batch - scenario: ATS-ACC-BAT-009-05 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/roll/batch-roller.integration.spec.js#opens the first batch when an inactive recurring batch is reactivated - scenario: ATS-ACC-BAT-009-09 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/roll/batch-roller.integration.spec.js#takes its empty active batch with it - scenario: ATS-ACC-BAT-010-01 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/roll/batch-roller.integration.spec.js#opens the new batch, dated the occurrence’s local date in Denver, and points the recurring batch at it - scenario: ATS-ACC-BAT-010-02 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/roll/batch-roller.integration.spec.js#names the new batch with the " (2)" suffix when the previous batch is kept and still holds the name - scenario: ATS-ACC-BAT-010-03 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/roll/batch-roller.integration.spec.js#deletes the previous active batch, which nothing named - scenario: ATS-ACC-BAT-010-03 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/roll/batch-roller.integration.spec.js#posts nothing when the previous batch was empty and so deleted (RB-20, D13) - scenario: ATS-ACC-BAT-010-03 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/roll/batch-roller.integration.spec.js#posts the previous batch the roll leaves closed: one posting job of it, named in the run’s outcome - scenario: ATS-ACC-BAT-010-04 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/roll/batch-roller.integration.spec.js#opens nothing for the same occurrence delivered again, and answers the same batch - scenario: ATS-ACC-BAT-010-05 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/roll/batch-roller.integration.spec.js#throws, so the queue retries the run - scenario: ATS-ACC-BAT-010-05 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/roll/batch-roller.integration.spec.js#leaves nothing: no new batch, the first batch still the active one, open evidence: - provenance: observed source: >- services-accounting:modules/batches/tests/integration/services/roll/batch-roller.integration.spec.js note: >- The executable file is inspected at the pinned revision; duration is an unmeasured planning estimate. - provenance: documented source: >- services-accounting:modules/batches/tests/integration/services/roll/batch-roller.integration.spec.js#suite header note: >- Real: PostgreSQL, the persistence services, the roll and its planning, the fiscal period lookup, the Liquid renderer, the - provenance: documented source: >- services-accounting:modules/batches/tests/integration/services/roll/batch-roller.integration.spec.js#suite header note: >- execution context and its transactions under `rhythm_accounting_app`. Doubled: in the failure case only, a roller that fails after - provenance: documented source: >- services-accounting:modules/batches/tests/integration/services/roll/batch-roller.integration.spec.js#suite header note: >- the real roller has written. Never doubled: the statements, the plan or row-level security. unbound_scope: null --- # Batch integration batch roller ## Verification Boundary This suite exercises the imported batch services or storage against the prepared local database. It does not imply that a deployed workflow is contacted. ## What This Suite Proves First intake, scheduled replacement, repeated occurrence identity, predecessor disposition and rollback are checked through the registered roll consumer. The assertion anchors identify the supported portions of the bound scenarios. ## What It Does Not Prove Local assertions do not establish deployment configuration, remote delivery guarantees, or unasserted lifecycle and concurrency paths. ## Real Dependencies and Test Doubles PostgreSQL, rendering, planning, persistence and scheduled work are real. Only the rollback case wraps the real roller with a failure after its write. ## Must Not Be Doubled The database constraints, transaction boundaries and exercised accounting functions must remain real when qualifying the asserted persistence or generation behavior.