Fiscal Calendar

What It Models

The fiscal calendar assigns accounting dates to a unit’s years and monthly periods. Controllers extend its coverage explicitly; Close maintains period standing. This separates calendar setup from the work that closes or reopens financial activity.

Identity and Attributes

Generated year identities stay fixed when staff rename a year. Periods retain their existing names after that rename. Each period has fixed dates and numbering, with close details maintained separately.

Year standing is stored but derived from period standing. The current-period lookup selects an open year first and then its earliest open period; if that year has no open period, the result is absent.

Relationships

The unit supplies the fiscal starting month and owns the calendar. Unit creation writes two initial years atomically; eligible later year deletion can remove that coverage. Financial records and Close runs may prevent removal through their references.

Invariants

Database constraints protect calendar structure and derived year standing. Service guards limit generation and direct year removal. Generation writes a complete requested extension or rolls it back; date lookups never extend coverage.

How It Is Stored and Shared

Books owns calendar generation, naming and ordinary removal. Close writes period standing through its own transition rules. Consumers read the shared calendar rather than a separate published read operation. Workspace date and time zone drive generation; the rows have no custom-field capability and are protected by workspace row policies.

Open Design Questions

There is no examined advance warning for schedules approaching the coverage boundary. Coordination between year deletion, generation and Close needs stronger concurrency proof before claiming a universal calendar guarantee. A nonmonthly fiscal structure requires a separate product decision.