--- id: TST-ACC-BAT-105 title: Batch integration rebuilt documents 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/posting/rebuilt-documents.integration.spec.js implements: - ATS-ACC-BAT-007-04 - ATS-ACC-BAT-007-06 - ATS-ACC-BAT-013-09 - ATS-ACC-BAT-014-07 - ATS-ACC-BAT-015-01 - ATS-ACC-BAT-015-03 - ATS-ACC-BAT-015-06 - ATS-ACC-BAT-015-10 - ATS-ACC-BAT-016-03 - ATS-ACC-BAT-016-05 - ATS-ACC-BAT-017-06 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-007-04 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/posting/rebuilt-documents.integration.spec.js#refuses, in the database, moving a document out of a posted batch (RHA05) - scenario: ATS-ACC-BAT-007-06 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/posting/rebuilt-documents.integration.spec.js#refuses the void of a credit memo whose batch is posted, batch_not_open - scenario: ATS-ACC-BAT-013-09 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/posting/rebuilt-documents.integration.spec.js#records the batch's statistics: the documents counted by kind and their base totals - scenario: ATS-ACC-BAT-014-07 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/posting/rebuilt-documents.integration.spec.js#credits the revenue as the splits stand at posting: 50.00 to the line’s revenue account, 50.00 to the split’s, not the 25% the product had at issue - scenario: ATS-ACC-BAT-015-01 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/posting/rebuilt-documents.integration.spec.js#writes one entry per live document, none for the void invoice - scenario: ATS-ACC-BAT-015-03 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/posting/rebuilt-documents.integration.spec.js#posts the credit memo against the invoice line it reduces: the receivable credited, the revenue debited - scenario: ATS-ACC-BAT-015-06 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/posting/rebuilt-documents.integration.spec.js#refuses November alone while October is open: November in error, naming the memo's invoice and October's status - scenario: ATS-ACC-BAT-015-06 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/posting/rebuilt-documents.integration.spec.js#records the dependency on October (DEF-ACT-0515): October names November as its dependent, and the dependents route answers it - scenario: ATS-ACC-BAT-015-10 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/posting/rebuilt-documents.integration.spec.js#balances every entry in the base currency and in its transaction currency - scenario: ATS-ACC-BAT-015-10 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/posting/rebuilt-documents.integration.spec.js#traces every line of every entry to a line of a document in the batch - scenario: ATS-ACC-BAT-016-03 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/posting/rebuilt-documents.integration.spec.js#refuses to unpost October while November, which depends on it, is posted - scenario: ATS-ACC-BAT-016-05 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/posting/rebuilt-documents.integration.spec.js#posts October again as a new posting, whose entries equal the first and are the only set - scenario: ATS-ACC-BAT-017-06 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/posting/rebuilt-documents.integration.spec.js#answers another tenant none of the entries, by batch or by transaction (the row-level policy) evidence: - provenance: observed source: >- services-accounting:modules/batches/tests/integration/services/posting/rebuilt-documents.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/posting/rebuilt-documents.integration.spec.js#suite header note: >- The first posting runs through the posting job (the local inline runner), so the job's record and the posting row's actor - provenance: documented source: >- services-accounting:modules/batches/tests/integration/services/posting/rebuilt-documents.integration.spec.js#suite header note: >- Real: the integration database, the invoice, memo and write-off commands, the posting job through the local runner, the native - provenance: documented source: >- services-accounting:modules/batches/tests/integration/services/posting/rebuilt-documents.integration.spec.js#suite header note: >- posting engine (`post-batches`, `unpost-batches`, `preview-batches`) and the persistence services. Doubled: nothing. unbound_scope: null --- # Batch integration rebuilt documents ## 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 Live invoice and memo documents generate their applicable entries and retain fiscal placement and source-line traceability. 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 and the exercised persistence or accounting functions are real. Controlled clocks, imported test fixtures and any suite-specific doubles delimit the asserted behavior. ## Must Not Be Doubled The database constraints, transaction boundaries and exercised accounting functions must remain real when qualifying the asserted persistence or generation behavior.