---
id: TST-ACC-BAT-076
title: Batch integration batch posting record
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/jobs/batch-posting-record.integration.spec.js
implements:
  - ATS-ACC-BAT-013-01
  - ATS-ACC-BAT-013-03
  - ATS-ACC-BAT-013-06
  - ATS-ACC-BAT-013-09
  - ATS-ACC-BAT-013-12
  - ATS-ACC-BAT-016-02
  - ATS-ACC-BAT-016-07
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-013-01
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/integration/services/jobs/batch-posting-record.integration.spec.js#refuses
      a posting that names one batch it has and one it does not, naming the
      missing one (DEF-ACT-0506)
  - scenario: ATS-ACC-BAT-013-03
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/integration/services/jobs/batch-posting-record.integration.spec.js#answers
      the job still posting the same batch with it, under another idempotency
      key (DEF-ACT-0514)
  - scenario: ATS-ACC-BAT-013-06
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/integration/services/jobs/batch-posting-record.integration.spec.js#is
      not posted by the action, and stays open (DEF-ACT-0503)
  - scenario: ATS-ACC-BAT-013-06
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/integration/services/jobs/batch-posting-record.integration.spec.js#is
      not posted by a job: the check step fails with the lock, and the batch
      stays open (DEF-ACT-0503)
  - scenario: ATS-ACC-BAT-013-06
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/integration/services/jobs/batch-posting-record.integration.spec.js#is
      posted once its lock is released (DEF-ACT-0503, DEF-ACT-0504)
  - scenario: ATS-ACC-BAT-013-09
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/integration/services/jobs/batch-posting-record.integration.spec.js#answers
      the posting job that posted it, and the time it was posted (DEF-ACT-0511)
  - scenario: ATS-ACC-BAT-013-12
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/integration/services/jobs/batch-posting-record.integration.spec.js#posts
      a batch whose description is a 1.0 test directive, as any other
      (DEF-ACT-0512)
  - scenario: ATS-ACC-BAT-016-02
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/integration/services/jobs/batch-posting-record.integration.spec.js#has
      no posting time after the unposting job, which is its last job
      (DEF-ACT-0513)
  - scenario: ATS-ACC-BAT-016-07
    provenance: test
    source: >-
      services-accounting:modules/batches/tests/integration/services/jobs/batch-posting-record.integration.spec.js#is
      not unposted by the action (DEF-ACT-0503)
evidence:
  - provenance: observed
    source: >-
      services-accounting:modules/batches/tests/integration/services/jobs/batch-posting-record.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/jobs/batch-posting-record.integration.spec.js#suite
      header
    note: >-
      Real: the integration database, the submission, the job engine's writes,
      the task handler and the native posting engine. Doubled: none.
unbound_scope: null
---

# Batch integration batch posting record

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

Posting records retain current and retired generations with their recorded accounting metadata. 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.