If an employee makes the target quantity, may the management screen show everything finished? Reading work completion and order-delivery handling in the actual service led me to separate their meanings in a small state example.
Ask what exactly is complete
The source manages good output separately from order-item delivered quantities. Finished production and no remaining delivery are distinct conditions. A representative should not infer that goods reached a customer solely from an unspecified complete badge.
The independent status returns production and delivery separately. Meeting the production target completes production while no delivery stays not started. Partial delivery remains partial; only the target delivered amount completes it. Inventory is the good stock remaining between those flows.
Read the same ten units at different stages
With a synthetic target of ten, record six good units and then four more. Production is complete, inventory is ten and delivery has not started. Deliver three and the status becomes partial with seven remaining. Sending the remainder makes both completion conditions true. This is a synthetic sequence, not a reconstructed client transaction.
A production percentage alone hides stock waiting for dispatch, while delivery percentage alone can hide already completed output. The useful summary depends on the representative’s question. Retaining each number’s basis makes later confirmation possible.
Bound delivery by available stock
Delivery requires a positive integer within current inventory. Apply first checks that inventory equals good minus delivered, then increases delivery and decreases stock equally. This small invariant connects cumulative meaning to a remaining balance.
The original business service contains orders, items, movement records and delivery documents. This module handles one synthetic target only; it verifies neither proof of delivery nor physical handover. A recorded event cannot by itself establish a completed real-world shipment.
Completion date is another contract
The historical correction record questions whether later production could overwrite a prior completion date. The current service includes a condition preserving the first completion. I read that distinction rather than repeat the historical finding as a current defect. The new example implements no completion timestamp.
Adding rework and scheduling requires defining first completion, recompletion and correction separately. The absence of a date is not filled with an invented today value. A convenient default could change the meaning of a management record that users reasonably treat as factual.
Cancellation and returns remain separate flows
The synthetic module accepts positive production and delivery events only. It implements no return, cancellation or post-inspection adjustment, and rejects negative quantities used as an improvised reversal. Real reversal events need their own reason, authorization and original-event reference.
This limit matters during reuse. A small demo should not read as a complete order lifecycle. Existing atomic-workflow and history contracts can support another integration while the state example retains its narrower promise. Making those boundaries readable is part of responsible generalization.
Let two screens ask different questions of the same events
The twenty-five tests include completed production before any delivery, completed delivery and stock-overrun rejection, passing in source and extraction. No warehouse, order or shipping service was called and no customer record was used. Document-local state illustrates the relationship between employee entry and management review.
An employee asks what was made today; a representative asks what remains on an order. Different questions need distinct summaries of the same events rather than unrelated numbers. The reusable judgment is to specify the object of completion instead of using that word more broadly.