Fiscal Close Service Module
What This Service Is For
Finance staff use this service to review monthly readiness, close the books, reopen eligible months and inspect retained evidence. Durable jobs carry out the financial sequence while the request remains available for progress and recovery. The module makes no model calls.
Boundary
Close owns period-closing fields, readiness, runs, their jobs and immutable close snapshots. It calls the calendar, posting, financial-document and reconciliation owners within Accounting. Platform supplies execution and aging infrastructure. Deployment currently places reads and recovery in Reconciliation, submissions in Books configuration and tasks in batch posting. No separate close function is declared.
Operations in Words
Calendar and authorization reads establish the subject and available actions. Readiness calculates a fresh review without independently writing records. Close and reopen submissions validate authority, request shape and calendar sequence, then save a request with its execution job. The API returns ordinary success with a run; asynchronous acceptance status is not declared.
History operations list requests and assemble one request’s task history or close record. Recovery retries retained failed work or cancels an eligible waiting or failed request. Its action grant depends on the request kind. Every operation records an unpublished Submissions reason; publication policy remains subject to verification of the external standard.
Events and Jobs
Two declared state machines execute close and reopen task catalogues. The module has no owned queue or schedule and declares no domain event-bus publication. Its events are job-local history. Several are appended after their domain transaction and can therefore be absent after a post-commit failure. Infrastructure alarms observe failed or timed-out executions; customer attention and notifications are not produced here.
Consistency Guarantees
Recognition and reversal retain their domain results with run output. Finalization atomically closes the month, captures evidence, accepts an aging request and succeeds the run. Aging contention can prevent that transaction from committing. Calendar maintenance and job history have separate commit boundaries. Period locks protect one month’s changing work; neighbouring sequence reads and the failure callback’s pre-lock run read need stronger concurrency proof.