1. E-procurement Portal
  2. Features
  3. Evidence and exceptions
Feature · Evidence and exceptions

Evidence and exceptions

Evidence and exceptions for the procurement team and its reviewers.

OverviewFailed Operation Queue
E-procurement Portal · Evidence and exceptions

Failed Operation Queue

Operation receipts

New
Operation keyActionExpected revisionResult stateOccurred atFailure reason
OK-644ACT-744320Failed09 OctCut to length
OK-846ACT-194380Needs review07 OctWeld frame
OK-481ACT-66330Failed26 OctDrill and tap
OK-918ACT-61250Needs review16 OctDeburr
OK-456ACT-514340Failed22 OctAssemble
6 of 6 records
OK-644Operation receipts · OR-31760
Failed
ActionACT-744
Expected revision320
Occurred at09 Oct
Failure reasonCut to length
Example screen with sample data

What you can do

Evidence and exceptions

An attachment records a title, file, evidence type, upload date, uploader and Internal or Shared visibility under its purchase request. A review decision records the person and revision behind approval or rejection. An operation receipt records the action key, expected revision and result state. Operations Overview brings failed actions and pending reviews into one queue.

How the work is organized

  • Attachment. Buyer gives each file an evidence type and Internal or Shared visibility.
  • Decision. A review decision names the reviewer, reason and request revision considered.
  • Exception. A receipt records Failed or needs review with an operation key and failure reason.

The Auditor starts with the parent request, then follows its attachments, decision and operation receipts. A failed award receipt must not be treated as a completed tender. The Purchasing Approver can inspect the revision behind a decision, while the Buyer checks the action result before retrying. Keep the receipt and its failure reason with the parent so the next person can see what happened.

What to agree during setup

Agree which evidence types are used, who sets Shared visibility and who investigates a failed operation. Establish the route for a decision whose source revision no longer matches the current request.

Choose one buying organization for the first cycle. Identify the person who can correct the record when the case fails a check. Write down the expected decision and evidence for the pilot before people begin using the queue. This makes it possible to distinguish a record awaiting action from a record that is ready to close.

Check the handoff on an actual case

Attach a pilot quotation and check its visibility. Check the decision against the request revision. Open a Failed receipt and confirm its parent, key and reason lead to a specific next action. Have an Auditor reconcile the request state with the decision and receipt.

Ask the next person to open the same parent request and explain the next action from the record itself. They should point to the responsible owner, current status and supporting decision or receipt. If those disagree, return the case to the person who owns the correction and record the reason. Rehearse the failure route as well as the successful one.

What your team sees

  • Failed Operation Queue — Inspect the action, expected revision and failure reason before a retry.
  • Shared Evidence — Check which attachments are marked Shared on the parent request.

What it keeps track of

Data model
Record attachments
Evidence files attached to a purchase request with visibility scope.
Review decisions
Independent reviewer decisions recorded against a purchase request revision.
Operation receipts
Idempotent receipts for every guarded operation executed against a purchase request.
Purchase requests
Demand records raised by buyers, carrying lifecycle, budget and supplier context.

Who uses it

Permissions
Auditor
Leads this part of the process.
Buyer
Carries operational records; Purchasing Approver reviews eligible decisions; Auditor reads the resulting evidence.

Set up E-procurement Portal your way.

Start free, then use Proto to change fields, steps and approvals before your team goes live.

How to get started