Case study 3 – Accept Finally: business decision logic
This case study examines the final acceptance transition in detail. Accept Finally is not a simple status click; it is a business decision that must be traced back to state, role, responsibility, approvals and consistency rules.
Starting point
Accept Finally is only available from state Authorized for Shipment. That state already expresses a provisional shipping decision. Final acceptance goes further: it confirms that quality requirements for the MQLS have been met.
Authorisation
The acting user must hold the role Quality Customer and must be the Quality Manager assigned to the MQLS. Without this assignment the decision is not authorised — even if the user generally has customer-quality rights.
Business requirements and guards
- MQLS data are consistent and correct
- at least one positively decided approval request exists
- where modelled, a positive decision by a second approver is required
- open contradictions in the submission block final acceptance
Resulting state and effects
On success the MQLS enters Finally Accepted. The model publishes the final status, finalises the MQLS context, closes remaining approval requests, aligns related attachment and notification contexts, and derives closing communication (final letter / notification) as business content that can be structured further.
Negative path
If approval or consistency conditions are not met, Accept Finally must not succeed. The alternative from the same state remains rejection, which leads to Rejected and finalises dependent contexts without implying quality acceptance.
Takeaway
Decision logic is not hidden in prose or program code alone. It is expressed as part of the semantic model and can therefore be explained, tested and projected into process and runtime views.