Rhythm 2.0 Specifications

Appearance

DOM-ACC-CLS-002Close Readiness

Markdown

DOM-ACC-CLS-002

Close Readiness

Markdown
  • DocumentDraft
  • ImplementationObserved

Planning

Specified by
CON-ACC-CLS-002

Design

Owned by
SVC-ACC-CLS-fiscal-close

KindDomain objectProduct areaAccountingModuleMonth-End ClosingRevision1

Read atservices-accounting f47cb263react-console baf6dae3

Close Readiness ​

What It Models ​

Readiness brings a month’s outstanding accounting work into one review. Finance staff receive checks, a verdict, payment context and a preview of closing effects. Execution uses the same evaluator before committing the close’s financial work.

Identity and Attributes ​

A standalone read creates no readiness record. Its subject and scope identify what was evaluated, while time and caller describe the circumstances. A registry selects the ordered checks. Requirement and outcome determine the verdict, and bounded supporting lists lead staff to the work behind each check.

Relationships ​

The evaluation consumes the calendar, batches, money documents, recognition schedules, payment assessment and close policy. A run keeps the calculation made during revalidation. Finalization copies that calculation and its reconciliation section into the close snapshot.

Invariants ​

The invariant rows define verdict calculation, failure isolation, bounded evidence and the distinction between preview and execution. Required missing evidence blocks; unsuccessful advisory checks contribute warnings. Caller authority also contributes to the current verdict.

How It Is Stored and Shared ​

Accounting reads the inputs in process within one transaction. Standalone evaluation makes that transaction read-only; job evaluation joins the writable close transaction. Neither path explicitly freezes every input at one database snapshot. Stored evaluations live with their run or snapshot. The verification setting lives on Books’ settings row.

Open Design Questions ​

Product must decide whether viewer authority should influence the month’s verdict and where administrators change bank verification. Additional readiness checks remain proposals until their purpose and evidence are established.

Relationships

ToCardinalityOwnershipCrosses a serviceOn archive or delete
DOM-ACC-CLS-001many evaluations of one periodThe calculation consumes the period and the business unit’s calendar.no
DOM-ACC-CLS-003one binding evaluation per close runRevalidation writes the run’s binding calculation; the run retains that copy.no
DOM-ACC-CLS-004one captured evaluation per successful closeThe successful close stores its own immutable copy of the calculation.no

Invariants

InvariantProtectsEnforced atProvenance
INV-DOM-ACC-CLS-002-01
Any required check that is blocked, pending or in error makes the overall result not ready.
servicetest
services-accounting:modules/fiscal-close/tests/unit/readiness/readiness-verdict.spec.js#is not ready for a required check pending: missing evidence never passes
INV-DOM-ACC-CLS-002-02
An evaluator failure becomes an error check with the applicable requirement, after its savepoint is rolled back, while other evaluators continue.
service, databasetest
services-accounting:modules/fiscal-close/tests/integration/services/persistence/readiness-transactions.integration.spec.js#rolls an evaluator’s failure back to its savepoint and keeps the transaction usable
INV-DOM-ACC-CLS-002-03
A standalone readiness transaction is read-only and rejects writes.
databasetest
services-accounting:modules/fiscal-close/tests/integration/services/persistence/readiness-transactions.integration.spec.js#refuses a write in it
INV-DOM-ACC-CLS-002-04
The close’s revalidation stores its readiness while holding the period lock in the same transaction.
servicetest
services-accounting:modules/fiscal-close/tests/integration/services/jobs/close-job.integration.spec.js#keeps the readiness the close evaluated on the run
INV-DOM-ACC-CLS-002-05
Period scope runs nine ordered checks; fiscal-year scope adds three checks after them.
servicetest
services-accounting:modules/fiscal-close/tests/e2e/fiscal-close-readiness.e2e.spec.js#adds the year checks for the fiscal_year scope
INV-DOM-ACC-CLS-002-06
Each check includes its total supporting-item count and returns at most fifty items.
servicetest
services-accounting:modules/fiscal-close/tests/unit/readiness/batches-posted.spec.js#keeps the first 50 items and the total beside them
INV-DOM-ACC-CLS-002-07
Payment-check items retain Reconciliation’s findings rather than deriving replacements.
servicetest
services-accounting:modules/fiscal-close/tests/unit/readiness/reconciliation-checks.spec.js#is blocked by a blocker, its findings the items unchanged, blockers first
INV-DOM-ACC-CLS-002-08
Unverified payouts warn by default and block when the workspace requires bank verification.
servicetest
services-accounting:modules/fiscal-close/tests/unit/readiness/reconciliation-checks.spec.js#blocks, required, for an unverified payout when the tenant requires verification
INV-DOM-ACC-CLS-002-09
Readiness queries, including recognition previews, are restricted to the selected workspace.
databasetest
services-accounting:modules/fiscal-close/tests/integration/services/persistence/recognition-previews.queries.integration.spec.js#never answers another tenant’s schedules
INV-DOM-ACC-CLS-002-10
The screen’s readiness read does not authorize execution; the job evaluates readiness again.
servicedocumented
services-accounting:docs/milestones/plans/ACCT-M4-plan.md#4a row 74 (class A; plan approved 2026-10-21)

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software