Fiscal Period

What It Models

A fiscal period gives finance staff a monthly boundary for each business unit’s books. Books owns its calendar identity, dates and label. Month-End Close owns the attached closing state, attribution, run reference and reopen count. Posting modules consult this state before applying work to the month.

Identity and Attributes

The year and period number identify the month. Its business unit comes from the calendar. Closing and reopening are protected working states that can persist after execution fails. Starting a reopen clears the current close attribution; the completed close’s record preserves the earlier evidence. The calendar computes which month is current rather than storing that designation.

Relationships

One period can accumulate many close and reopen runs. A partial unique index limits queued or running requests for that period, while its protected state also prevents replacement of a retained failed run. Readiness belongs to an evaluation; the retained record belongs to the successful close.

Invariants

The invariant rows specify state validity, attribution, sequencing and posting protection. State changes and postings contend on the same period row. That lock protects one month; sequence checks alone do not establish serialization across neighbouring months.

How It Is Stored and Shared

Books stores the shared period and year rows. Close tasks write the closing fields through the state writer, and the database derives year status. Batch management and Reconciliation read these rows in their posting paths. The close service supplies the console’s calendar response. The design has no custom-field use; registration declarations remain unverified.

Open Design Questions

Business-unit permission scope, signals for stranded work and cross-month concurrency need resolution or proof. Calendar ownership stays with Books while those questions are addressed.