Document states
The schema below describes the document state transitions for all system objects.
The states Reposted and Voided and the associated state transitions don't apply to non-financial-transaction elements. The Posted state should be considered Approved for non-financial-transaction elements.
The document is locked for editing by a user. Financial documents in this state can't be included in reports.
The document has not been claimed for editing. Documents are expected to pass through this state, not remain in it indefinitely. Financial documents in this state can be included in reports (but are excluded by default).
The document has been reviewed and approved; in case of a financial document, the document has been included in the regular financial reports. Contrary to a document in the Posted/Reposted state, a document in the plain Posted state doesn't have an associated document.
The document was not deemed suitable. Further editing isn't desirable. A financial document in this state is excluded from all reports (by default).
The document's financial effects have been reversed by way of posting of another document in the Voiding state. Both the current document and the other (voiding) document are included in all financial reports as regular transactions.
The document's financial effects reverse those of another document. The associated document has a Voided state. ('Voided' is an annotation of the Voiding state indicating the state of the associated document.)
The document's financial effects have been reversed by way of posting another document - like the Voided state. Additionally, similar (adjusted) financial effects may have been re-introduced by way a third document created initially into the Locked state for editing. This third document may or may not have ended up being posted.
The current document and its voiding counterpart are excluded from all reports (by default) the same way as documents in the Deleted state.
This document's financial effects reverse those of another document. The associated document has a Reposted state. ('Reposted' is an annotation of the Voiding state indicating the state of the associated document.)
This document supersedes an earlier document for which the financial effects have been undone; the associated document is in a Reposted state. ('Reposted' is an annotation of the Voiding state indicating the state of the associated document.)
From the initial state, creates a new empty document into a locked state.
From the initial state, creates a new document based on the content of an existing document into a locked state.
Stores a document, releasing its locked state, into a Saved state. Next actions can be to post, delete or edit the document.
From a Saved state, reserves a document for editing by bringing the document in a locked state.
From a Saved state, moves a document into the Deleted state, thereby making it hidden from regular reports.
From a Saved state, moves the document into the Posted state, thereby including it in regular (financial) reports.
From a Saved state, moves the document into the Posted/Reposted state for transactions which sprung to life as a consequence of the Repost state transition.
Nullifies the effect of a current financial transaction by creating a new document - from the initial state directly into the Posted state. Void applies to AR/AP transactions whereas Reverse applies to GL and payment transactions.
This state transition affects the state of the current transaction and generates a new transaction, which explains the Void state transition from the initial state.
Nullifies the effect of the current financial transaction by creating a new document - as Void does - as well as a new document based on the current document - as Copy-to-new does. The current and the voiding document are hidden, removing them from regular reports.
The replacing document is created into the locked state, essentially restarting the state transition diagram. There are no guarantees that the replacing document will be posted into the balance sheet.
This state transition affects the state of the current transaction and generates two new transactions; one voiding transaction and a reposting transaction, which explains the two state transitions from the initial state.
The state transitions
- Post
- Void
- Repost
may be subject to approval (through workflow configuration) to enforce peer review. Because of that, approval isn't a state in the document's state diagram.
Note: In order to prevent one user from editing the transaction while another user is reviewing that (set of) transaction(s), resulting in a non-reviewed transaction to be posted (a concern of Chris's), additional measures are required. Making state transitions an RPC call with an argument which identifies the transaction in the state it was at the time of starting the review allows us to reject the state transition if the transaction is no longer in that state.
When peer review isn't desired, the difference between the Saved and Posted states is irrelevant in the presence of a Repost state transition. Configuration may combine these into a single Post state transition.
The above schema deprecates the 'save-as-new' state transition, because it requires in-place editing of an existing document, which holds a high risk of inadvertently overwriting the document being edited.