The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.
| # | Surface | Action | Capability | Expected | Provenance |
|---|---|---|---|---|---|
| 1 | getDependentBatches | Inspect the collection’s downstream dependencies. | CAP-ACC-BAT-002 | The lookup returns no dependent batch for this recovery case. | test services-accounting:modules/batches/tests/e2e/batches.e2e.spec.js#answers no batch depending on it |
| 2 | /console/{tenantId}/accounting/batches/{batchId} (More Actions › Unpost) | Select Unpost and acknowledge deletion of the ordinary entries. | CAP-ACC-BAT-016 | Recovery progress succeeds and the reloaded collection is Open without a current posting. | test |
| 3 | /console/{tenantId}/accounting/batches/{batchId} (Subledger Entries tab, Include reversed entries) | Inspect the entry list with historical reversals included. | CAP-ACC-BAT-018 | No ordinary ledger rows or compensating reversal entries remain for that posting. | documented services-accounting:docs/milestones/walkthroughs/ACCT-M3-handoff.md#Start here (step 6) |
| 4 | /console/{tenantId}/accounting/batches/{batchId} (Transactions tab › Move to Another Batch) | Move the misplaced invoice to another Open collection in the same unit. | CAP-ACC-BAT-007 | The target collection now owns the invoice. | test |
| 5 | /console/{tenantId}/accounting/batches/{batchId} (Post) | Submit posting for the corrected collection. | CAP-ACC-BAT-013 | A fresh result contains the remaining documents and excludes the moved invoice. | test |
| Path | From step | Condition | Path taken | Outcome | Provenance |
|---|---|---|---|---|---|
| alternate | 1 | A downstream collection is already Posted. | Recover that dependent collection before its source. | Both collections can then be corrected and posted in dependency order. | test services-accounting:modules/batches/tests/integration/services/posting/rebuilt-documents.integration.spec.js#refuses to unpost October while November, which depends on it, is posted |
| failure | 2 | Fiscal close has protected the collection’s period. | The period guard refuses ordinary recovery. | The collection remains Posted; any correction in another period needs its applicable document workflow. | test 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 |
| failure | 2 | Staff can post but lack recovery access. | Unpost is unavailable and an unauthorized request fails. | The posted accounting result remains intact. | test |
| Id | Statement | Provenance |
|---|---|---|
01 | Ordinary recovery removes the first posting’s entries and lines without adding reversals. | test services-accounting:modules/batches/tests/integration/services/posting/unpost-deletes-entries.integration.spec.js#lists, history included, only the fresh set after the repost: no stale entry, no reversal |
02 | History retains the recovered posting alongside the new current posting. | test services-accounting:modules/batches/tests/integration/services/posting/unpost-deletes-entries.integration.spec.js#keeps the posting history: the first posting reversed, the second current |
03 | The replacement posting owns exactly one fresh current entry set. | test services-accounting:modules/batches/tests/integration/services/posting/unpost-deletes-entries.integration.spec.js#writes one fresh set when the batch is posted again, equal in size to the first |
04 | The moved invoice contributes to the target collection’s accounting result. | test |
End-to-end policy: required: Browser acceptance is required to show ordinary deletion, subsequent document correction and the fresh accounting result consistently.