The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.
| # | Surface | Action | Capability | Expected | Provenance |
|---|---|---|---|---|---|
| 1 | /console/{tenantId}/accounting/batches/{batchId} | Post the collection containing an annual membership invoice. | CAP-ACC-BAT-019 | Its deferred revenue plan contains twelve monthly releases. | test |
| 2 | /console/{tenantId}/accounting/close (Month-End Close, Close Period) | Complete the period-close workflow. | CAP-ACC-BAT-020 | The period’s deferred-revenue system batch records the month’s recognition in its fiscal context. | test |
| 3 | /console/{tenantId}/accounting/batches/new | Request a new batch dated in the closed month. | CAP-ACC-BAT-001 | The calendar refusal identifies the period; a current-date batch can still be created. | documented services-accounting:docs/milestones/walkthroughs/ACCT-M3-handoff.md#Start here (step 8) |
| 4 | unpostBatches | Request ordinary recovery of the month’s invoice collection. | CAP-ACC-BAT-016 | The closed-period guard leaves the collection Posted. | test |
| 5 | /console/{tenantId}/accounting/batches/{batchId} (the deferred revenue batch) | Inspect the fiscal system collection. | CAP-ACC-BAT-004 | Its ordinary action list is empty and attempted staff actions fail. | test services-accounting:modules/batches/tests/e2e/system-batches.e2e.spec.js#offers an administrator no action for the system batch |
| 6 | /console/{tenantId}/accounting/close (Reopen) | Reopen the month through fiscal close. | CAP-ACC-BAT-020 | System accounting adds mirrors of the retained originals, opens the system batch and resets that month’s recognition. | test |
| Path | From step | Condition | Path taken | Outcome | Provenance |
|---|---|---|---|---|---|
| alternate | 2 | A proportional membership credit follows three recognised months. | Its adjustment plan reduces the remaining nine unrecognised months. | Later close recognises the adjusted remaining releases. | test |
| failure | 2 | Accounting work still holds the period when close begins. | The shared period guard serializes the conflicting work. | The held posting transaction completes before the close can advance. | test services-accounting:modules/batches/tests/integration/services/close/posting-period-guard.integration.spec.js#holds the period row FOR SHARE for the rest of the caller's transaction |
| Id | Statement | Provenance |
|---|---|---|
01 | The closed period’s system collection holds the recognition completed for that period. | test 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 |
02 | Closed-period safeguards reject creation, fiscal relocation, posting and ordinary unposting in that period. | test |
03 | Fiscal reopening retains original recognition entries, adds mirrors and resets the applicable recognition facts. | test 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 |
04 | Ordinary staff actions remain unavailable for the system collection. | test services-accounting:modules/batches/tests/e2e/system-batches.e2e.spec.js#leaves the batch unchanged after every refused action |
End-to-end policy: required: Browser acceptance is required across fiscal close and batch inspection to demonstrate the closed-period safeguards and reopening result.