Review and evidence

A review decision names its parent request, reviewer, source revision, decision, date and reason. Approve, Reject and Return are distinct outcomes. The source revision matters because a later edit can change the request under review. A reviewer should be able to see which version was approved before any stock effect is associated with the request.

Attachments add the supporting file, title, evidence type, upload date and uploader. Visibility distinguishes Internal from Shared evidence. Teams can attach a count sheet, photo or receiving note to the request that prompted the work. The file is context for a human decision; it is not a substitute for the decision record.

• Collect support. Inventory Coordinator links the relevant document or image to the request and identifies its visibility.
• Decide on the revision. Inventory Reviewer reads the current request, records Approve, Reject or Return, and gives a reason.
• Check the outcome. The reviewer examines operation receipts and linked effects when an action completed, failed or needs review.

Operation receipts carry an operation key, action, expected revision, result state and time. They can also hold an external reference, effect references and failure reason. These details tell the team whether an attempted action produced the expected linked records. A Completed outcome should be checked against those effects rather than inferred from a successful click.

Decide what evidence each kind of stock request needs before review. Define which files can be Shared and who can see Internal attachments. Set a revision policy for edits after approval. Decide how a returned request gets corrected and resubmitted, including whether the same reviewer may decide the new revision.

Establish who investigates Failed and needs review outcomes. The operation key must stay stable across a retry of the same action, and a new authorized action needs its own identity. When an outside system is connected, its reference can help reconcile a response, but the team should first inspect the local linked effect and expected revision.

A coordinator requests a stock correction after a count. The count sheet is attached to the request, with a visibility setting appropriate for the people involved. The reviewer compares the requested change with the count and the current revision, then records an approval or return with a reason. If the request changes afterward, the older decision remains in the history but should not be treated as approval of the changed quantity.

The correction attempt produces an operation receipt. If it says Failed, the coordinator reads the failure reason before trying again. If it says needs review, the reviewer compares any linked movement with the expected change. A second click is not evidence of a second authorized correction. The receipt, decision and attachment together explain the outcome to an auditor.

• Operations needing review — Outcomes whose effects require comparison with the request.
• Failed operations — Attempts with failure reasons for investigation.
• Review decisions — Decisions by source revision, reviewer and date.

Read request review for the approval handoff and reconciliation for uncertain outcomes.