Status Transitions
Most systems store status as a dropdown value and hope nothing sets it to something silly. Documents here define the lifecycle as permitted transitions — from this status, to that status — and anything undeclared cannot happen.
Where to find it
The transition list belongs to a document type, so start at Architect Panel → ERP - Setup → Document Types. The transitions themselves are held in a datastore of their own; where your panel does not surface it directly, open the document status list from All Datastores.
Why transitions rather than statuses
The difference shows the first time somebody tries to reopen a posted invoice. With a list of statuses nothing prevents it — the field accepts a new value and a document that has already hit the ledger returns to draft.
With transitions, "a posted invoice cannot return to draft" is an enforced property of the system rather than a rule people are asked to remember.
It also documents itself. Reading the transition list tells you exactly what can happen to a document and in what order, which is the question a new administrator, an auditor or your future self will ask.
Defining a lifecycle
Add one row per permitted move, naming the type, the from status and the to status. A sales invoice might allow draft to approved, approved to posted, approved back to draft, and posted to cancelled — and nothing else.
Note what is absent: there is no route from posted back to draft. That absence is the whole point.
Terminal statuses
A status with no outbound transitions is terminal. Posted and cancelled usually are, or nearly so.
Be deliberate: a terminal status is a promise the document will not change again, which is what makes it safe for the ledger and for reporting to depend on.
Who may make a move
Transitions govern what is structurally possible, not who is allowed. Combine them with security groups and field-level permissions so approving a document is both a legal move and a restricted one.
Worked example
A purchase order allows: draft → submitted, submitted → approved, submitted → draft (rejected back for amendment), approved → sent, sent → received, sent → cancelled. There is no route from received to anything, because a received order is history. Approval is additionally restricted to the buying manager group.
Designing it
Start with the smallest set that reflects reality. Every status multiplies the transitions you must think about, and a lifecycle nobody can hold in their head will be worked around. If a status exists only so somebody can filter a list, a flag or a date column is the better answer.
Recommendations
- Draw it on paper first. Five statuses is usually plenty.
- Leave the dangerous move out rather than restricting it by permission — absence is stronger.
- Make posted terminal wherever the ledger depends on it.
- Review the list when somebody asks for a new status; often they want a flag.