Close Record

What It Models

A close record lets a reviewer inspect the evidence retained when a month closed. Its immutable core contains the binding readiness, payment assessment and close totals. The service adds the request, execution view and subsequent reopen history when someone reads it.

Identity and Attributes

The run identifies the record. Stored documents preserve the earlier calculation despite later changes to the books. The service reconstructs audit entries from requests and successful completions; cancellation attribution remains in operational history. The aging request is available through the run’s finalization output rather than the snapshot.

Relationships

The snapshot references exactly one run and repeats its period identity. A correction followed by another close creates another run and snapshot. Earlier evidence remains attached to its original close.

Invariants

The invariant rows define snapshot uniqueness, period correspondence, bounded storage and update protection. The normal service path makes capture part of successful finalization. The database foreign key alone does not require a successful run status or close kind.

How It Is Stored and Shared

The snapshot table enforces workspace isolation and withholds update privileges from application roles. The record operation assembles the console’s evidence view. Customer export embeds the snapshot inside its run; names are resolved by the console from returned person references.

Open Design Questions

The service still owes resolved closer names under the approved plan. Linked reopen history is silently bounded, audit entries are not globally chronological, and the record lacks a requested-or-ready aging signal. These limitations need decisions or implementation corrections before preparation.