Operation receipts

An operation receipt gives a guarded action a stable key and an outcome. It records the action, expected revision, result state, occurrence time, optional external reference, effect references and failure reason. Every receipt points to a parent work order. When an action has a receipt, its recorded state tells an operator whether that attempt completed, failed, remains pending or needs review.

Consider an approval attempt for a submitted zone assignment. The reviewer is looking at a particular revision of the parent work. If the action is repeated, the operation key gives the team a way to identify that it is the same intended effect. For a completed receipt, check the effect references against the related decision. A failed receipt needs a failure reason that lets Admin and Warehouse Manager investigate before anyone tries again.

• Identity. Operation key and action distinguish a specific attempted effect from another task on the same work order.
• Revision. Expected revision states which version the action was meant to use.
• Outcome. Pending, Completed, Failed and needs review values support follow-up without losing the original attempt.

Agree which operational actions need a receipt and how the operation key is generated. The key should be stable for a repeat of the same intended action. Set a procedure for reading effect references and external references so a shift manager can locate the result. Decide who investigates a failed or needs-review receipt and what evidence they check before retrying an action. A receipt records an outcome; the team still needs the linked work order and decision to understand its business meaning.

Pay attention to the expected revision. When a work order changes after an operator first opens it, a later effect should be considered against the current record rather than assumed valid from the earlier screen. Keep the receipt under the parent work order so an auditor of the job can follow the plan, decision and result in sequence.

Use a submitted assignment for a named work order. Record the review decision against its source revision. For a case with an operation receipt, inspect the recorded result. Compare the receipt’s expected revision with the work order revision, then use the operation key to identify any repeated attempt. If the result is Completed, follow the effect references to the decision. If it is Failed, read the failure reason and have Admin determine the next safe step. A needs review result should stay in an explicit queue until a person resolves it.

Run another case where the parent work order was edited during review. Warehouse Manager should see the revision difference before accepting the work. The goal is a clear trail of what the team intended, what version it used and what result was actually recorded.

• Operation exceptions — Failed and needs-review outcomes requiring investigation.
• Review history — Decisions linked to the same parent work order.
• Work awaiting review — Parent jobs where an unresolved action may matter.

See review assignments for the decision and accept work for final checks. Implementation covers the rehearsal.