---
id: TST-ACC-BAT-106
title: Batch integration rebuilt payments
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-payments.integration.spec.js
implements:
  - ATS-ACC-BAT-007-05
  - ATS-ACC-BAT-007-06
  - ATS-ACC-BAT-015-01
  - ATS-ACC-BAT-015-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-007-05
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/integration/services/posting/rebuilt-payments.integration.spec.js#refuses,
      in the database, an allocation row into the posted batch (RHA05)
  - scenario: ATS-ACC-BAT-007-05
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/integration/services/posting/rebuilt-payments.integration.spec.js#refuses
      an allocation with no batch named when the payment’s batch is posted and
      the unit has no rule (batch_required)
  - scenario: ATS-ACC-BAT-007-06
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/integration/services/posting/rebuilt-payments.integration.spec.js#refuses
      the void of a posted payment, batch_not_open (M2 package 2: a void is a
      reversal, which must name an open batch)
  - scenario: ATS-ACC-BAT-007-06
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/integration/services/posting/rebuilt-payments.integration.spec.js#refuses
      the void of the credit made from it, batch_not_open
  - scenario: ATS-ACC-BAT-015-01
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/integration/services/posting/rebuilt-payments.integration.spec.js#writes
      no entry for the check voided before the posting (a payment that is not
      live posts nothing)
  - scenario: ATS-ACC-BAT-015-05
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/integration/services/posting/rebuilt-payments.integration.spec.js#posts
      the payment: cash debited its total, the invoice line's receivable
      credited the allocation, unapplied cash credited the rest
  - scenario: ATS-ACC-BAT-015-05
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/integration/services/posting/rebuilt-payments.integration.spec.js#posts
      the order the tender named on the payment entry, and none on a payment
      with no order (DEF-ACT-0528)
  - scenario: ATS-ACC-BAT-015-05
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/integration/services/posting/rebuilt-payments.integration.spec.js#posts
      the row as a payment allocation: unapplied cash debited, the line's
      receivable (the gala line's, the unit's default) credited, naming its
      payment
  - scenario: ATS-ACC-BAT-015-05
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/integration/services/posting/rebuilt-payments.integration.spec.js#posts
      the manual credit: its expense debited, its liability credited
  - scenario: ATS-ACC-BAT-015-05
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/integration/services/posting/rebuilt-payments.integration.spec.js#posts
      the application: the credit's posted liability debited, the invoice line's
      receivable credited
  - scenario: ATS-ACC-BAT-015-05
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/integration/services/posting/rebuilt-payments.integration.spec.js#posts
      the bounced check as the money leaving: the bank account credited its
      total, unapplied cash debited
evidence:
  - provenance: observed
    source: >-
      services-accounting:modules/batches/tests/integration/services/posting/rebuilt-payments.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-payments.integration.spec.js#suite
      header
    note: >-
      Real: the integration database, the invoice, payment and credit commands,
      the native posting engine (`post-batches`,
  - provenance: documented
    source: >-
      services-accounting:modules/batches/tests/integration/services/posting/rebuilt-payments.integration.spec.js#suite
      header
    note: >-
      `unpost-batches`, `preview-batches`) and the persistence services.
      Doubled: the clock (the fixtures' fixed one).
unbound_scope: null
---

# Batch integration rebuilt payments

## 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

Payments, credits, applications and subsequent money outflows generate the applicable ledger patterns and downstream dependencies. 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.