--- id: ATS-ACC-BAT-014 scope: CAP-ACC-BAT-014 product_area: accounting module: batches revision: 2 status: proposed source_sha: services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f rhythm-v2-docs: 37405d50d1465ea0571a66095d98ebec4db04175 scenarios: - id: ATS-ACC-BAT-014-01 title: Posting resolves configuration after issuance level: api proves: - BR-CAP-ACC-BAT-014-01 - BR-CAP-ACC-BAT-014-02 preconditions: Unit and product accounts are initially absent. steps: 'Issue invoices, memos and a write-off, configure accounts and post.' expected: >- Issuance needs no accounts; posting uses current product and unit settings, including unit defaults for the unconfigured debit-memo line. negative: false data_needs: Provide the gl-at-posting fixtures. bound_to: - TST-ACC-BAT-102 - TST-ACC-BAT-012 provenance: test source: >- 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 category: rule test_evidence: - >- 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 - >- 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 - >- services-accounting:modules/batches/tests/integration/services/posting/gl-resolution-at-posting.integration.spec.js#posts the debit memo’s added line (a product with no setup) to the unit’s defaults - >- react-console:acceptance/accounting/playwright/journeys/batches-posting/ACT-ACC-0522.spec.ts#ACT-ACC-0522 - id: ATS-ACC-BAT-014-02 title: Missing account errors identify the affected line level: browser proves: - BR-CAP-ACC-BAT-014-03 preconditions: >- The batch contains a valid invoice and another lacking product revenue configuration. steps: 'Post, configure the missing account and retry.' expected: >- The first attempt writes nothing and identifies the invoice, line and revenue purpose; the configured retry succeeds. negative: true data_needs: Provide no fixtures beyond the stated setup. bound_to: - TST-ACC-BAT-102 - TST-ACC-BAT-011 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/posting/gl-resolution-at-posting.integration.spec.js#fails the batch naming the gala invoice, its line and the missing revenue purpose, the dues invoice unnamed category: failure test_evidence: - >- 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 - >- services-accounting:modules/batches/tests/integration/services/posting/gl-resolution-at-posting.integration.spec.js#fails the batch naming the gala invoice, its line and the missing revenue purpose, the dues invoice unnamed - >- services-accounting:modules/batches/tests/integration/services/posting/gl-resolution-at-posting.integration.spec.js#leaves nothing partially posted: no entry, no snapshot, the documents issued and unposted - >- react-console:acceptance/accounting/playwright/journeys/batches-posting/ACT-ACC-0521.spec.ts#ACT-ACC-0521 - id: ATS-ACC-BAT-014-03 title: Snapshots preserve historical account choices level: api proves: - BR-CAP-ACC-BAT-014-04 - BR-CAP-ACC-BAT-014-05 - INV-DOM-ACC-BAT-003-04 preconditions: October has posted. steps: >- Inspect snapshots, change product configuration and post a November memo against October. expected: >- Snapshots retain accounts and resolution time; the memo uses those choices and October remains unchanged. negative: false data_needs: Provide no fixtures beyond the stated setup. bound_to: - TST-ACC-BAT-102 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/posting/gl-resolution-at-posting.integration.spec.js#alters neither October’s posted entries nor its snapshot category: invariant test_evidence: - >- services-accounting:modules/batches/tests/integration/services/posting/gl-resolution-at-posting.integration.spec.js#writes the posting’s snapshot on every posted line: the accounts it posted to, the method and the instant - >- 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 - >- services-accounting:modules/batches/tests/integration/services/posting/gl-resolution-at-posting.integration.spec.js#alters neither October’s posted entries nor its snapshot - >- services-accounting:modules/batches/tests/integration/services/posting/gl-resolution-at-posting.integration.spec.js#posts the later batch to the configuration as it stands then - id: ATS-ACC-BAT-014-04 title: Write-off policy selects the debit account level: browser proves: - BR-CAP-ACC-BAT-014-06 - BR-CAP-ACC-BAT-014-07 preconditions: >- Units use expense, original-revenue and allowance policies; one allowance account is missing. steps: 'Post their write-offs, change policy and reverse one.' expected: >- The selected accounts follow each policy; missing allowance configuration fails its batch; reversal mirrors the original account choices. negative: true data_needs: Provide the write-off policy fixtures. bound_to: - TST-ACC-BAT-115 - TST-ACC-BAT-013 provenance: test source: >- 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 category: rule test_evidence: - >- services-accounting:modules/batches/tests/integration/services/posting/write-off-policy.integration.spec.js#echo (direct, bad_debt_expense): the receivable credited, write-off expense debited to the product’s write-off account - >- services-accounting:modules/batches/tests/integration/services/posting/write-off-policy.integration.spec.js#foxtrot (direct, revenue_reversal): the receivable credited, the revenue account the invoice posted to debited (1.0’s direct method) - >- services-accounting:modules/batches/tests/integration/services/posting/write-off-policy.integration.spec.js#golf (allowance): the receivable credited, the unit’s allowance default debited, bad-debt expense untouched - >- 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 - >- 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 - >- react-console:acceptance/accounting/playwright/journeys/batches-posting/ACT-ACC-0523.spec.ts#ACT-ACC-0523 - id: ATS-ACC-BAT-014-05 title: Discounts reduce credited revenue level: api proves: - BR-CAP-ACC-BAT-014-08 preconditions: An invoice line has a discount. steps: Post the invoice. expected: >- Revenue is net with no separate discount line; the snapshot retains gross, discount, net, discount account and method. negative: false data_needs: Provide no fixtures beyond the stated setup. bound_to: - TST-ACC-BAT-102 provenance: test source: >- 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 category: rule test_evidence: - >- 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 - id: ATS-ACC-BAT-014-06 title: Tax account resolution has a fallback level: api proves: - BR-CAP-ACC-BAT-014-09 preconditions: >- A taxed invoice exists and a later invoice lacks both rate and unit tax accounts. steps: 'Post each, configure the unit default and retry the later invoice.' expected: >- Tax uses and snapshots the selected account; the missing-account failure identifies rate and unit before configuration permits retry. negative: true data_needs: Provide tax rates. bound_to: - TST-ACC-BAT-110 provenance: test source: >- 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 category: validation test_evidence: - >- services-accounting:modules/batches/tests/integration/services/posting/rebuilt-tax.integration.spec.js#writes the account each tax line was credited to back on the tax line as the posted snapshot (gl-at-posting), the invoice’s and the memos’ - >- 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 - >- services-accounting:modules/batches/tests/integration/services/posting/rebuilt-tax.integration.spec.js#posts the same invoice once the unit names its default again, the City Tax lines credited to it - id: ATS-ACC-BAT-014-07 title: Posting reads current dimensions and splits level: api proves: - BR-CAP-ACC-BAT-014-10 preconditions: >- One invoice product’s split rises from twenty-five to fifty percent after issuance; another has department and project settings. steps: Post both invoices. expected: >- Posting credits fifty dollars through the revised split, and the revenue lines retain the configured department and project codes. negative: false data_needs: Provide no fixtures beyond the stated setup. bound_to: - TST-ACC-BAT-105 - TST-ACC-BAT-097 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 category: rule test_evidence: - >- 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 - >- services-accounting:modules/batches/tests/integration/services/posting/dimension-codes-at-posting.integration.spec.js#carries the department’s stored code on the revenue line - id: ATS-ACC-BAT-014-08 title: Account correction changes readiness category: interaction level: api proves: - BR-CAP-ACC-BAT-012-03 - BR-CAP-ACC-BAT-014-03 exercises: - CAP-ACC-BAT-014 - CAP-ACC-BAT-012 workflows: [] preconditions: Morning’s invoice product has no resolvable revenue account. steps: 'Preview, configure the missing account and preview again.' expected: >- The first result names the missing account and the second includes Morning as a candidate. negative: false data_needs: >- An isolated workspace with the stated business-unit calendar, documents and configuration. bound_to: [] provenance: proposed source: >- services-accounting:modules/batches/services/engine/preview-batches.ts:previewBatchPostings; 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 - id: ATS-ACC-BAT-014-09 title: Account refusal leaves no partial ledger category: interaction level: api proves: - BR-CAP-ACC-BAT-013-10 - BR-CAP-ACC-BAT-014-03 exercises: - CAP-ACC-BAT-014 - CAP-ACC-BAT-013 workflows: - WF-ACC-BAT-005 preconditions: >- Morning holds an issued invoice whose product and unit have no revenue account. steps: >- Submit posting and inspect the batch, entries and the line’s resolution error. expected: >- Morning is Error with an identifying account reason and no current entries. negative: false data_needs: >- An isolated workspace with the stated business-unit calendar, documents and configuration. bound_to: [] provenance: proposed source: >- services-accounting:modules/batches/tests/integration/services/posting/rebuilt-posting-edges.integration.spec.js#posts January, puts April in error naming the application whose credit's batch is not posted, and May in error as April's dependent; 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 - id: ATS-ACC-BAT-014-10 title: Resolved destinations drive generated entries category: interaction level: api proves: - BR-CAP-ACC-BAT-014-02 - BR-CAP-ACC-BAT-015-03 exercises: - CAP-ACC-BAT-014 - CAP-ACC-BAT-015 workflows: - WF-ACC-BAT-005 preconditions: >- An issued invoice line lacks product accounting but the unit has its revenue default. steps: Post the batch and inspect the line snapshot and revenue ledger line. expected: Both identify the unit’s resolved revenue account. negative: false data_needs: >- An isolated workspace with the stated business-unit calendar, documents and configuration. bound_to: [] provenance: proposed source: >- 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; services-accounting:modules/batches/tests/integration/services/posting/rebuilt-tax.integration.spec.js#posts the invoice per line: the receivable debited the total with the tax, revenue credited the net, and a tax credit per tax line to its account - id: ATS-ACC-BAT-014-11 title: Cross-unit revenue requires both clearing accounts category: validation level: api proves: - BR-CAP-ACC-BAT-014-11 preconditions: >- A product uses another unit’s revenue account and the required inter-unit mappings are incomplete. steps: >- Attempt posting with one mapping missing, supply the pair through a controlled fixture and retry. expected: >- The first attempt refuses generation; the complete mapping permits balanced inter-unit account movements. negative: true data_needs: >- Owned records in an isolated workspace with the stated calendar and accounting setup. bound_to: [] provenance: proposed source: >- services-accounting:modules/batches/db/business-unit-inter-entity-accounts.table.ts; FND-ACC-BAT-011 evidence: - services-accounting at f47cb263: 'Inspected references: scenario-bound tests in modules/batches/tests.' - react-console at baf6dae3: >- Inspected references: acceptance/accounting/playwright/journeys/batches-posting (ACT-ACC-0521, 0522, 0523). - >- Pinned design objects, state models and workflows identify invariant and interaction obligations; scenario test anchors remain in test_evidence. product_intent: proposed coverage: rule: covered transition: not-applicable validation: covered permission: not-applicable edge: 'gap: FND-ACC-BAT-068' failure: covered boundary: 'gap: FND-ACC-BAT-068' concurrency: 'gap: FND-ACC-BAT-068' invariant: covered interaction: covered coverage_notes: transition: >- Account resolution computes and snapshots destinations during posting; it defines no independent lifecycle. permission: >- Resolution has no public operation or separate grant; posting permission is exercised by the posting capability. edge: >- Cross-unit account pairs, concurrent configuration changes, account-resolution exception handling and immutable snapshot boundaries need focused proof. boundary: >- Cross-unit account pairs, concurrent configuration changes, account-resolution exception handling and immutable snapshot boundaries need focused proof. concurrency: >- Cross-unit account pairs, concurrent configuration changes, account-resolution exception handling and immutable snapshot boundaries need focused proof. rule_coverage: - rule: BR-CAP-ACC-BAT-014-01 scenarios: - ATS-ACC-BAT-014-01 provenance: proposed source: >- 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 - rule: BR-CAP-ACC-BAT-014-02 scenarios: - ATS-ACC-BAT-014-01 - ATS-ACC-BAT-014-10 provenance: proposed source: >- 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 - rule: BR-CAP-ACC-BAT-014-03 scenarios: - ATS-ACC-BAT-014-02 - ATS-ACC-BAT-014-08 - ATS-ACC-BAT-014-09 provenance: proposed source: >- 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 - rule: BR-CAP-ACC-BAT-014-04 scenarios: - ATS-ACC-BAT-014-03 provenance: proposed source: >- 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 - rule: BR-CAP-ACC-BAT-014-05 scenarios: - ATS-ACC-BAT-014-03 provenance: proposed source: >- services-accounting:modules/batches/tests/integration/services/posting/gl-resolution-at-posting.integration.spec.js#alters neither October’s posted entries nor its snapshot - rule: BR-CAP-ACC-BAT-014-06 scenarios: - ATS-ACC-BAT-014-04 provenance: proposed source: >- 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 - rule: BR-CAP-ACC-BAT-014-07 scenarios: - ATS-ACC-BAT-014-04 provenance: proposed source: >- 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 - rule: BR-CAP-ACC-BAT-014-08 scenarios: - ATS-ACC-BAT-014-05 provenance: proposed source: >- 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 - rule: BR-CAP-ACC-BAT-014-09 scenarios: - ATS-ACC-BAT-014-06 provenance: proposed source: >- 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 - rule: BR-CAP-ACC-BAT-014-10 scenarios: - ATS-ACC-BAT-014-07 provenance: proposed 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 - rule: BR-CAP-ACC-BAT-014-11 scenarios: - ATS-ACC-BAT-014-11 provenance: proposed source: >- services-accounting:modules/batches/db/business-unit-inter-entity-accounts.table.ts; FND-ACC-BAT-011 transition_coverage: [] permission_coverage: [] executable_coverage: bound_scenarios: 7 unbound_scenarios: - ATS-ACC-BAT-014-08 - ATS-ACC-BAT-014-09 - ATS-ACC-BAT-014-10 - ATS-ACC-BAT-014-11 gap: FND-ACC-BAT-068 --- # Resolve posting accounts and retain their snapshots: Capability Test Specification ## Coverage The scenarios define focused checks for this outcome. The coverage map distinguishes specified checks from unresolved proof; executable bindings identify inspected assertions and carry no execution result. | Rule | Proof Specification or Gap | |---|---| | `BR-CAP-ACC-BAT-014-01` | `ATS-ACC-BAT-014-01` | | `BR-CAP-ACC-BAT-014-02` | `ATS-ACC-BAT-014-01`, `ATS-ACC-BAT-014-10` | | `BR-CAP-ACC-BAT-014-03` | `ATS-ACC-BAT-014-02`, `ATS-ACC-BAT-014-08`, `ATS-ACC-BAT-014-09` | | `BR-CAP-ACC-BAT-014-04` | `ATS-ACC-BAT-014-03` | | `BR-CAP-ACC-BAT-014-05` | `ATS-ACC-BAT-014-03` | | `BR-CAP-ACC-BAT-014-06` | `ATS-ACC-BAT-014-04` | | `BR-CAP-ACC-BAT-014-07` | `ATS-ACC-BAT-014-04` | | `BR-CAP-ACC-BAT-014-08` | `ATS-ACC-BAT-014-05` | | `BR-CAP-ACC-BAT-014-09` | `ATS-ACC-BAT-014-06` | | `BR-CAP-ACC-BAT-014-10` | `ATS-ACC-BAT-014-07` | | `BR-CAP-ACC-BAT-014-11` | `ATS-ACC-BAT-014-11` | ## Interactions With Related Capabilities Account correction changes readiness. Account refusal leaves no partial ledger. Resolved destinations drive generated entries. These checks use the related capability’s outcome as part of the setup or verification. Unbound interactions remain proposed until a suite executes the complete chain.