Close Run
What It Is
A close run is the saved request and outcome for one period close, year close or reopen. It identifies the period, requester, request time and command content. A durable job performs its steps. The run stays recognizable when the job fails or a retry starts another job for the same request.
A period close and year close use the same six-step workflow, with year scope adding checks for the final period. Reopening uses three steps. Saving the request and job together lets the service return the run while execution continues. Staff follow that execution through its page rather than keeping the submitting browser connection open.
A command key protects repeated requests after a lost response. Matching command content returns the existing run. A competing request for a period already held by another run is refused. The saved run consequently provides the common reference for progress, recovery and the record produced by successful closing.
What It Is Not
The run is distinct from its job attempts. Retry creates a new job but does not create another closing request. It is also separate from a batch posting run, which handles ledger work within a period. The retained close record is the evidence from successful finalization; failed or cancelled runs still have execution history without acquiring that record.
How It Is Used
A controller starts closing after review and confirmation. The run page displays ordered steps, attempts, produced records and events. Revalidation may discover required work that was absent from the earlier screen. That refusal releases the period and explains why a fresh close is needed after correction.
Other failures can leave the period protected. The controller inspects the failed step and chooses an eligible recovery action. Retry keeps committed recognition work. Cancellation is restricted once recognition or reversal has committed. A correction to a completed month uses a reopen run, and another close later records the corrected state.
Its Facets
Run kind. Period close, year close and reopen determine the workflow, relevant checks and recovery permission.
Execution standing. Queued and running indicate work still proceeding. Failed can permit retry; succeeded and cancelled are final run outcomes.
Durable steps. Steps through close finalization lock the period and reuse committed results. Future-year generation follows separately and commits years individually.
Command key. The request carries a key and matching content can return the original result. The implementation currently omits requester identity from that comparison.
Explanation and review. A close can include a note and acknowledged warnings. A reopen requires a reason, which remains available to later reviewers.
Close-owned revenue. Recognition produces the system batch used for the period’s deferred revenue. Reopening calls its matching reversal. Cost of goods sold remains skipped.
Recovery choices. The period’s retained state and committed revenue effects determine whether retry or cancellation is allowed.
Execution history. Events and attempts span the run’s jobs, allowing reviewers to follow retries and recorded warnings without treating each job as another close.
How It Relates
The run takes and changes a fiscal period. Closing consumes readiness, invokes revenue processing, requests aging and asks Books for future years. Successful finalization writes the close snapshot. A reopen identifies the close whose work it reverses and adds to that close’s linked history. Platform supplies the durable execution machinery used for these jobs.
What It Could Become
The product should enforce the recorded requester-identity ruling for command replay and remove the wait for aging required by the approved plan. It should decide when to re-check the original requester’s authority and how to alert staff to stranded execution. Recovery wording needs to describe the allowed action honestly. Partial future-year generation also needs clearer replay expectations and acceptance evidence.