--- id: ATS-ACC-BAT-020 scope: CAP-ACC-BAT-020 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-020-01 title: Close submissions are keyed and repeatable after reopening level: api proves: - BR-CAP-ACC-BAT-020-01 - BR-CAP-ACC-BAT-020-02 - INV-DOM-ACC-BAT-003-07 preconditions: An Open period has recognition entries due. steps: >- Post its system batch, repeat the key with unchanged and changed entries, then reopen and submit a new key. expected: >- The initial post uses the period context; equivalent replay writes nothing, changed replay fails and re-close reuses the batch with fresh entry references. negative: true data_needs: Provide close fixtures. bound_to: - TST-ACC-BAT-069 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/close/post-system-batch.integration.spec.js#writes the batch already posted, in the period, named and dated as given category: invariant test_evidence: - >- services-accounting:modules/batches/tests/integration/services/close/post-system-batch.integration.spec.js#writes the batch already posted, in the period, named and dated as given - >- services-accounting:modules/batches/tests/integration/services/close/post-system-batch.integration.spec.js#answers the same batch and posting, not created - >- services-accounting:modules/batches/tests/integration/services/close/post-system-batch.integration.spec.js#is refused with other entries (`event_key_reused`) - >- services-accounting:modules/batches/tests/integration/services/close/post-system-batch.integration.spec.js#posts the same batch again under the new key - >- services-accounting:modules/batches/tests/integration/services/close/post-system-batch.integration.spec.js#stores the second posting's entries under the caller's ids suffixed `-2` - id: ATS-ACC-BAT-020-02 title: System-entry inputs must be valid level: unit proves: - BR-CAP-ACC-BAT-020-03 preconditions: No special setup is necessary. steps: >- Submit unbalanced, too-short, negative, over-precision, duplicate, foreign-unit, empty and out-of-period entries. expected: Each invalid submission reports its specific refusal. negative: true data_needs: Provide no fixtures beyond the stated setup. bound_to: - TST-ACC-BAT-069 - TST-ACC-BAT-121 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/close/post-system-batch.integration.spec.js#refuses unbalanced entries (`entry_unbalanced`) category: validation test_evidence: - >- services-accounting:modules/batches/tests/integration/services/close/post-system-batch.integration.spec.js#refuses unbalanced entries (`entry_unbalanced`) - >- services-accounting:modules/batches/tests/integration/services/close/post-system-batch.integration.spec.js#refuses no entries (`entries_required`) - >- services-accounting:modules/batches/tests/integration/services/close/post-system-batch.integration.spec.js#refuses a date outside the period - >- services-accounting:modules/batches/tests/unit/close/close-rules.spec.js#is refused with an amount of three decimals - >- services-accounting:modules/batches/tests/unit/close/close-rules.spec.js#is refused naming another unit's account, judged by the account's own unit - id: ATS-ACC-BAT-020-03 title: Fiscal state controls recognition and reversal level: api proves: - BR-CAP-ACC-BAT-020-04 preconditions: 'Periods represent Open, Closing, Closed and Reopening.' steps: >- Apply strict checks, system posting, recognition, reversal and unrecognition. expected: >- Posting and recognition allow Open or Closing; reversal and unrecognition allow Closed or Reopening. negative: true data_needs: Provide period statuses. bound_to: - TST-ACC-BAT-071 - TST-ACC-BAT-121 provenance: test source: >- services-accounting:modules/batches/tests/unit/close/close-rules.spec.js#refuses system_reversal in a period that is open (period_not_closed) category: rule test_evidence: - >- services-accounting:modules/batches/tests/integration/services/close/posting-period-statuses.integration.spec.js#allows post_system_batch, which posts the batch - >- services-accounting:modules/batches/tests/integration/services/close/posting-period-statuses.integration.spec.js#refuses reverse_system_batch (`period_not_closed`) - >- services-accounting:modules/batches/tests/unit/close/close-rules.spec.js#refuses system_reversal in a period that is open (period_not_closed) - >- services-accounting:modules/batches/tests/unit/close/close-rules.spec.js#allows system_posting in a period that is closing - id: ATS-ACC-BAT-020-04 title: Close recognises due entries atomically level: api proves: - BR-CAP-ACC-BAT-020-05 - BR-CAP-ACC-BAT-020-06 - INV-DOM-ACC-BAT-005-05 preconditions: Two schedules include a late-booked July entry. steps: Close successive months and attempt recognition outside a transaction. expected: >- Each close recognises due entries, including the earlier straggler; the final close completes both schedules and the standalone call fails. negative: true data_needs: Provide close fixtures. bound_to: - TST-ACC-BAT-072 - TST-ACC-BAT-073 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/close/revenue-recognition.integration.spec.js#sweeps in B's back-dated July entries with A's and B's August entries category: transition test_evidence: - >- services-accounting:modules/batches/tests/integration/services/close/revenue-recognition.integration.spec.js#posts the entries in July's deferred revenue batch, named and dated as 1.0 did, with one entry per schedule entry - >- services-accounting:modules/batches/tests/integration/services/close/revenue-recognition.integration.spec.js#sweeps in B's back-dated July entries with A's and B's August entries - >- services-accounting:modules/batches/tests/integration/services/close/revenue-recognition.integration.spec.js#closes both schedules, their last entries recognized - >- services-accounting:modules/batches/tests/integration/services/close/revenue-recognition.integration.spec.js#refuses recognition outside a transaction (`transaction-required`) - >- services-accounting:modules/batches/tests/integration/services/close/reverse-system-batch.integration.spec.js#leaves nothing once the caller rolls back: two entries, the posting unreversed, the batch posted - id: ATS-ACC-BAT-020-05 title: Reopen reverses only the selected recognition period level: browser proves: - BR-CAP-ACC-BAT-020-07 - BR-CAP-ACC-BAT-020-08 preconditions: September has closed. steps: Reopen it. expected: >- Reversal entries accompany retained originals, the posting is reversed and batch Open; September recognition resets while earlier months remain recognised. negative: false data_needs: Provide a closed period. bound_to: - TST-ACC-BAT-073 - TST-ACC-BAT-072 - TST-ACC-BAT-018 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/close/reverse-system-batch.integration.spec.js#writes a reversing entry for each entry, debits and credits swapped, and keeps the originals category: interaction test_evidence: - >- services-accounting:modules/batches/tests/integration/services/close/reverse-system-batch.integration.spec.js#writes a reversing entry for each entry, debits and credits swapped, and keeps the originals - >- services-accounting:modules/batches/tests/integration/services/close/reverse-system-batch.integration.spec.js#marks the posting reversed and the batch open, with no count or posting time - >- services-accounting:modules/batches/tests/integration/services/close/revenue-recognition.integration.spec.js#un-recognizes A's and B's September entries and opens both schedules again - >- services-accounting:modules/batches/tests/integration/services/close/revenue-recognition.integration.spec.js#leaves the July and August entries recognized - >- react-console:acceptance/accounting/playwright/journeys/batches-posting/ACT-ACC-0528.spec.ts#ACT-ACC-0528 - id: ATS-ACC-BAT-020-06 title: System reversal rejects invalid targets level: api proves: - BR-CAP-ACC-BAT-020-09 - BR-CAP-ACC-BAT-020-10 preconditions: >- Targets include an ordinary posting, a reversed system posting and an already-posted system batch. steps: Reverse the first two and submit another post for the third. expected: >- Ordinary reversal fails; repeated reversal writes nothing; reposting without reopening reports the posted-system refusal. negative: true data_needs: Provide close fixtures. bound_to: - TST-ACC-BAT-073 - TST-ACC-BAT-069 provenance: test source: >- services-accounting:modules/batches/tests/integration/services/close/reverse-system-batch.integration.spec.js#refuses a transaction batch's posting (`not_a_system_batch`) category: edge test_evidence: - >- services-accounting:modules/batches/tests/integration/services/close/reverse-system-batch.integration.spec.js#refuses a transaction batch's posting (`not_a_system_batch`) - >- services-accounting:modules/batches/tests/integration/services/close/reverse-system-batch.integration.spec.js#answers a second call by the posting id as not reversed, writing nothing - >- services-accounting:modules/batches/tests/integration/services/close/post-system-batch.integration.spec.js#refuses a new key while the batch is posted (`system_batch_posted`) - >- services-accounting:modules/batches/tests/integration/services/close/post-system-batch.integration.spec.js#refuses a name another batch of the unit has (`name_in_use`) - id: ATS-ACC-BAT-020-07 title: Closed periods protect both ordinary and system records level: browser proves: - BR-CAP-ACC-BAT-020-11 preconditions: An invoice batch posted before its month closed. steps: >- Unpost the invoice batch and invoke every action on the period’s system batch. expected: >- The period guard blocks ordinary recovery and system-batch guards reject all staff actions. negative: true data_needs: Provide the acceptance workspace. bound_to: - TST-ACC-BAT-018 - TST-ACC-BAT-074 provenance: test source: >- react-console:acceptance/accounting/playwright/journeys/batches-posting/ACT-ACC-0528.spec.ts#ACT-ACC-0528 category: interaction test_evidence: - >- react-console:acceptance/accounting/playwright/journeys/batches-posting/ACT-ACC-0528.spec.ts#ACT-ACC-0528 - >- services-accounting:modules/batches/tests/integration/services/close/system-batch-guard.integration.spec.js#refuses the action unpost of the posted system batch, submitting no job - id: ATS-ACC-BAT-020-08 title: Fiscal collections reject ordinary controls category: interaction level: api proves: - BR-CAP-ACC-BAT-004-09 - BR-CAP-ACC-BAT-020-11 exercises: - CAP-ACC-BAT-020 - CAP-ACC-BAT-004 workflows: [] preconditions: Fiscal close has produced a Posted deferred-revenue system batch. steps: 'Retrieve its ordinary actions and attempt Close, Archive and Unpost.' expected: >- The action list is empty and each attempted ordinary action is refused without changing fiscal entries. negative: true data_needs: >- An isolated workspace with the stated business-unit calendar, documents and configuration. bound_to: [] provenance: proposed source: >- services-accounting:modules/batches/tests/e2e/system-batches.e2e.spec.js#offers an administrator no action for the system batch; react-console:acceptance/accounting/playwright/journeys/batches-posting/ACT-ACC-0528.spec.ts#ACT-ACC-0528 - id: ATS-ACC-BAT-020-09 title: Fiscal close blocks ordinary recovery category: interaction level: api proves: - BR-CAP-ACC-BAT-016-08 - BR-CAP-ACC-BAT-020-11 exercises: - CAP-ACC-BAT-020 - CAP-ACC-BAT-016 workflows: [] preconditions: A posted ordinary batch belongs to a Closed period with a system batch. steps: >- Attempt ordinary recovery and inspect both the ordinary and system accounting. expected: Recovery is refused; both postings and their entries stay intact. negative: true 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/close/posting-period-guard.integration.spec.js#refuses the batch action `unpost` (`period_not_open`), submitting no job; react-console:acceptance/accounting/playwright/journeys/batches-posting/ACT-ACC-0528.spec.ts#ACT-ACC-0528 - id: ATS-ACC-BAT-020-10 title: Fiscal reopening restores pending releases category: interaction level: api proves: - BR-CAP-ACC-BAT-019-08 - BR-CAP-ACC-BAT-020-08 exercises: - CAP-ACC-BAT-020 - CAP-ACC-BAT-019 workflows: - WF-ACC-BAT-008 preconditions: A current deferred plan has due entries in three successive periods. steps: >- Recognise the periods, reopen the final period and inspect plan status and fiscal entries. expected: >- Only the selected releases become pending again; earlier recognition remains and mirrored system entries accompany the retained originals. 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/unit/rules/schedule-truncation.spec.js#inverts the nine unrecognised months at half each on their own dates and nothing for the recognised three; services-accounting:modules/batches/tests/integration/services/close/revenue-recognition.integration.spec.js#un-recognizes A's and B's September entries and opens both schedules again - id: ATS-ACC-BAT-020-11 title: Fiscal accounting rolls back as one caller transaction category: failure level: api proves: - BR-CAP-ACC-BAT-020-06 - BR-CAP-ACC-BAT-020-07 preconditions: >- A current deferred plan has due releases and the fiscal caller transaction has a controlled write failure. steps: >- Recognise and post within that transaction, force the failure, then read schedule and system records from another transaction. expected: No partial recognition or new fiscal generation remains after rollback. 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/tests/integration/services/close/revenue-recognition.integration.spec.js#refuses recognition outside a transaction (`transaction-required`); services-accounting:modules/batches/tests/integration/services/close/reverse-system-batch.integration.spec.js#writes a reversing entry for each entry, debits and credits swapped, and keeps the originals 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-0528.spec.ts. - >- 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: 'gap: FND-ACC-BAT-074' validation: covered permission: not-applicable edge: covered failure: covered boundary: 'gap: FND-ACC-BAT-074' concurrency: 'gap: FND-ACC-BAT-074' invariant: covered interaction: covered coverage_notes: permission: >- Fiscal functions execute in the caller transaction; this capability has no ordinary public permission. Ordinary action refusal is tested as an interaction. failure: >- Concurrent fiscal requests, rollback at each recognition and system-posting seam, input precision boundaries and interactions with partly recognised ordinary recovery need focused proof. boundary: >- Concurrent fiscal requests, rollback at each recognition and system-posting seam, input precision boundaries and interactions with partly recognised ordinary recovery need focused proof. concurrency: >- Concurrent fiscal requests, rollback at each recognition and system-posting seam, input precision boundaries and interactions with partly recognised ordinary recovery need focused proof. rule_coverage: - rule: BR-CAP-ACC-BAT-020-01 scenarios: - ATS-ACC-BAT-020-01 provenance: proposed source: >- services-accounting:modules/batches/tests/integration/services/close/post-system-batch.integration.spec.js#writes the batch already posted, in the period, named and dated as given - rule: BR-CAP-ACC-BAT-020-02 scenarios: - ATS-ACC-BAT-020-01 provenance: proposed source: >- services-accounting:modules/batches/tests/integration/services/close/post-system-batch.integration.spec.js#is refused with other entries (`event_key_reused`) - rule: BR-CAP-ACC-BAT-020-03 scenarios: - ATS-ACC-BAT-020-02 provenance: proposed source: >- services-accounting:modules/batches/tests/integration/services/close/post-system-batch.integration.spec.js#refuses unbalanced entries (`entry_unbalanced`) - rule: BR-CAP-ACC-BAT-020-04 scenarios: - ATS-ACC-BAT-020-03 provenance: proposed source: >- services-accounting:modules/batches/tests/unit/close/close-rules.spec.js#refuses system_reversal in a period that is open (period_not_closed) - rule: BR-CAP-ACC-BAT-020-05 scenarios: - ATS-ACC-BAT-020-04 provenance: proposed source: >- services-accounting:modules/batches/services/close/close-rules.ts:recogniseSchedule; services-accounting:modules/batches/services/close/revenue-recognition.ts:recognise_due_entries - rule: BR-CAP-ACC-BAT-020-06 scenarios: - ATS-ACC-BAT-020-04 - ATS-ACC-BAT-020-11 provenance: proposed source: >- services-accounting:modules/batches/tests/integration/services/close/revenue-recognition.integration.spec.js#refuses recognition outside a transaction (`transaction-required`) - rule: BR-CAP-ACC-BAT-020-07 scenarios: - ATS-ACC-BAT-020-05 - ATS-ACC-BAT-020-11 provenance: proposed source: >- services-accounting:modules/batches/tests/integration/services/close/reverse-system-batch.integration.spec.js#writes a reversing entry for each entry, debits and credits swapped, and keeps the originals - rule: BR-CAP-ACC-BAT-020-08 scenarios: - ATS-ACC-BAT-020-05 - ATS-ACC-BAT-020-10 provenance: proposed source: >- services-accounting:modules/batches/tests/integration/services/close/revenue-recognition.integration.spec.js#un-recognizes A's and B's September entries and opens both schedules again - rule: BR-CAP-ACC-BAT-020-09 scenarios: - ATS-ACC-BAT-020-06 provenance: proposed source: >- services-accounting:modules/batches/tests/integration/services/close/reverse-system-batch.integration.spec.js#refuses a transaction batch's posting (`not_a_system_batch`) - rule: BR-CAP-ACC-BAT-020-10 scenarios: - ATS-ACC-BAT-020-06 provenance: proposed source: >- services-accounting:modules/batches/tests/integration/services/close/post-system-batch.integration.spec.js#refuses a new key while the batch is posted (`system_batch_posted`) - rule: BR-CAP-ACC-BAT-020-11 scenarios: - ATS-ACC-BAT-020-07 - ATS-ACC-BAT-020-08 - ATS-ACC-BAT-020-09 provenance: proposed source: >- react-console:acceptance/accounting/playwright/journeys/batches-posting/ACT-ACC-0528.spec.ts#ACT-ACC-0528 transition_coverage: - state_model: STATE-ACC-BAT-004 transition: 2 from: current to: reversed gap: FND-ACC-BAT-074 provenance: unknown source: >- services-accounting:modules/batches/tests/integration/services/close/reverse-system-batch.integration.spec.js#writes a reversing entry for each entry, debits and credits swapped, and keeps the originals note: >- The existing scenario set is not an exhaustive proof of this transition and all its side effects. - state_model: STATE-ACC-BAT-005 transition: 1 from: open to: recognized gap: FND-ACC-BAT-074 provenance: unknown source: >- services-accounting:modules/batches/services/close/close-rules.ts:recogniseSchedule; modules/batches/services/close/revenue-recognition.ts:recogniseDueEntries note: >- The existing scenario set is not an exhaustive proof of this transition and all its side effects. - state_model: STATE-ACC-BAT-005 transition: 2 from: recognized to: open gap: FND-ACC-BAT-074 provenance: unknown source: >- services-accounting:modules/batches/tests/integration/services/close/revenue-recognition.integration.spec.js#un-recognizes A's and B's September entries and opens both schedules again note: >- The existing scenario set is not an exhaustive proof of this transition and all its side effects. permission_coverage: [] executable_coverage: bound_scenarios: 7 unbound_scenarios: - ATS-ACC-BAT-020-08 - ATS-ACC-BAT-020-09 - ATS-ACC-BAT-020-10 - ATS-ACC-BAT-020-11 gap: FND-ACC-BAT-074 --- # Post and reverse fiscal-close system batches: 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-020-01` | `ATS-ACC-BAT-020-01` | | `BR-CAP-ACC-BAT-020-02` | `ATS-ACC-BAT-020-01` | | `BR-CAP-ACC-BAT-020-03` | `ATS-ACC-BAT-020-02` | | `BR-CAP-ACC-BAT-020-04` | `ATS-ACC-BAT-020-03` | | `BR-CAP-ACC-BAT-020-05` | `ATS-ACC-BAT-020-04` | | `BR-CAP-ACC-BAT-020-06` | `ATS-ACC-BAT-020-04`, `ATS-ACC-BAT-020-11` | | `BR-CAP-ACC-BAT-020-07` | `ATS-ACC-BAT-020-05`, `ATS-ACC-BAT-020-11` | | `BR-CAP-ACC-BAT-020-08` | `ATS-ACC-BAT-020-05`, `ATS-ACC-BAT-020-10` | | `BR-CAP-ACC-BAT-020-09` | `ATS-ACC-BAT-020-06` | | `BR-CAP-ACC-BAT-020-10` | `ATS-ACC-BAT-020-06` | | `BR-CAP-ACC-BAT-020-11` | `ATS-ACC-BAT-020-07`, `ATS-ACC-BAT-020-08`, `ATS-ACC-BAT-020-09` | ## Interactions With Related Capabilities Fiscal collections reject ordinary controls. Fiscal close blocks ordinary recovery. Fiscal reopening restores pending releases. 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.