Resolve posting accounts and retain their snapshots

Purpose

Posting chooses the financial destinations that apply now and preserves the choices used for later correction.

How It Works

Customers can issue documents while financial configuration is incomplete. Posting resolves the account purposes needed for each eligible line. It uses applicable product configuration and unit defaults, then retains the accounting it actually used. Later corrections consult that original accounting. New configuration influences later postings without rewriting earlier ones. An unresolved account prevents the affected batch from posting and gives finance staff a specific setup problem.

Relationships

Related outcome: Inspect posting readiness before submission, which addresses the connected batch work.
Related outcome: Produce document entries using the applicable accounting method, which addresses the connected batch work.

Show evidence (sources, provenance, origins, pinned commits)

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes: Account choices reflect applicable configuration and remain traceable through stored snapshots.
Surfaces: consolejob
Constraints: Products and Books maintain the configuration and policies used by account resolution.
Intent sources: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-1services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-2services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-3

Controls

16 controls apply, from the corpus control catalogue.

TC-IAM-001 TC-IAM-005 TC-IAM-006 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-TEN-004 TC-DAT-001 TC-LOG-002 TC-LOG-003 TC-PI-003 TC-PI-005

Business Rules

11 rules, 11 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

Id	Rule	Kind	Enforced at	Provenance
`01`must prove Proposed	Posting resolves accounts rather than issuance, allowing invoices, memos and write-offs to issue before financial configuration exists. origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-1 proved by `ATS-ACC-BAT-014-01`, `TST-ACC-BAT-012`, `TST-ACC-BAT-102`	policy	service	test services-accounting:modules/batches/tests/integration/services/posting/gl-resolution-at-posting.integration.spec.js#issues the invoice and creates the memos and the write-off with no GL account, default or setup anywhere
`02`must prove Proposed	Resolution uses the product setup and then unit defaults for the account purpose, with missing-product revenue handled by the unit’s fallback account. origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-1 proved by `ATS-ACC-BAT-014-01`, `ATS-ACC-BAT-014-10`, `ATS-ACC-BAT-015-12`, `TST-ACC-BAT-012`, `TST-ACC-BAT-102`	calculation	service	test services-accounting:modules/batches/tests/integration/services/posting/gl-resolution-at-posting.integration.spec.js#posts the invoice to the resolved accounts: the receivable from the unit’s default, the revenue from the product’s setup, the discounted line net of its discount
`03`must prove Proposed	If no account resolves, the batch fails without entries and identifies the affected document, line, purpose and relevant configuration choices. origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-1 proved by `ATS-ACC-BAT-012-05`, `ATS-ACC-BAT-013-22`, `ATS-ACC-BAT-014-02`, `ATS-ACC-BAT-014-08`, `ATS-ACC-BAT-014-09`, `TST-ACC-BAT-011`, `TST-ACC-BAT-102`	validation	service	test services-accounting:modules/batches/tests/integration/services/posting/gl-resolution-at-posting.integration.spec.js#fails the batch’s validation with an error naming the invoice, the missing accounts receivable account, the product’s setup and the unit’s default
`04`must prove Proposed	Posting writes account, method and time snapshots to posted lines, and later corrections reuse the original line’s accounting destinations. origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-1 proved by `ATS-ACC-BAT-014-03`, `TST-ACC-BAT-102`	invariant	service	test services-accounting:modules/batches/tests/integration/services/posting/gl-resolution-at-posting.integration.spec.js#posts the credit memo and the write-off to the accounts the invoice’s entry used, the write-off’s debit to the product’s write-off account
`05`must prove Proposed	Later configuration changes preserve existing entries and snapshots and affect the next posting’s resolution. origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-1 proved by `ATS-ACC-BAT-014-03`, `TST-ACC-BAT-102`	invariant	service	test services-accounting:modules/batches/tests/integration/services/posting/gl-resolution-at-posting.integration.spec.js#alters neither October’s posted entries nor its snapshot
`06`must prove Proposed	At posting, the unit’s write-off policy chooses bad-debt expense, the invoice’s original revenue account or an allowance account, with a missing required allowance preventing the batch from posting. origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-2 proved by `ATS-ACC-BAT-014-04`, `TST-ACC-BAT-013`, `TST-ACC-BAT-115`	calculation	service	test services-accounting:modules/batches/tests/integration/services/posting/write-off-policy.integration.spec.js#fails the batch naming the write-off, the allowance purpose and the unit; nothing posts, not even the invoice
`07`must prove Proposed	A write-off reversal mirrors that write-off’s recorded entry regardless of subsequent policy changes. origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-2 proved by `ATS-ACC-BAT-014-04`, `TST-ACC-BAT-013`, `TST-ACC-BAT-115`	invariant	service	test services-accounting:modules/batches/tests/integration/services/posting/write-off-policy.integration.spec.js#posts the reversal as the mirror of the write-off’s entry: the write-off expense account credited, the receivable debited
`08`must prove Proposed	The current discount method credits revenue net of discount without a separate discount entry and retains gross, discount, net and the discount-product account in the snapshot. origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-3 proved by `ATS-ACC-BAT-014-05`, `TST-ACC-BAT-102`	calculation	service	test services-accounting:modules/batches/tests/integration/services/posting/gl-resolution-at-posting.integration.spec.js#preserves the discount in the posted snapshot: the gross, the discount and the net on the line, the discount product’s revenue account and the net-of-revenue method
`09`must prove Proposed	Tax resolves to the rate’s payable account for the unit or its sales-tax default, failing without either and recording the selected account on the tax line. origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-1 proved by `ATS-ACC-BAT-014-06`, `TST-ACC-BAT-110`	calculation	service	test services-accounting:modules/batches/tests/integration/services/posting/rebuilt-tax.integration.spec.js#puts the batch in error naming the rate and the unit when neither the rate nor the unit names a tax payable account, writing no entry
`10`must prove Proposed	Posting reads current splits, departments and projects rather than retaining their issue-time configuration. proved by `ATS-ACC-BAT-014-07`, `TST-ACC-BAT-097`, `TST-ACC-BAT-105`	calculation	service	test 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
`11`must prove Proposed	Cross-unit product revenue needs the inter-unit receivable and liability account pair, but the examined product provides no configuration writer for that pair. proved by `ATS-ACC-BAT-014-11`	validation	service	inferred services-accounting:modules/batches/db/business-unit-inter-entity-accounts.table.ts; FND-ACC-BAT-011

Scenarios

Id	Given	When	Then	Provenance
`01`	A dues invoice issued before accounts were configured.	Finance supplies receivable and revenue accounts and posts its batch.	The entry uses the configured destinations and retains them on the invoice lines.	test react-console:acceptance/accounting/playwright/journeys/batches-posting/ACT-ACC-0522.spec.ts#ACT-ACC-0522
`02`	Three units use different write-off policies for equal amounts.	Their batches post and a write-off is later reversed.	Each policy selects its own debit destination and the reversal mirrors its original write-off.	test react-console:acceptance/accounting/playwright/journeys/batches-posting/ACT-ACC-0523.spec.ts#ACT-ACC-0523

Planning

Implementation

Resolve posting accounts and retain their snapshots ​

Purpose ​

How It Works ​

Relationships ​