These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
- E-procurement Portal
- Features
- Review and award
Review and award
Review and award for the procurement team and its reviewers.
OverviewReview Decision Register×
E-procurement Portal · Review and award
New
Review Decision Register
Review decisions
| Parent | Source revision | Decision | Decided at | Reason | Operation key | |
|---|---|---|---|---|---|---|
| PR-50525 | 540 | Approve | 17 Oct | Approve rd-949 | OK-368 | |
| PR-33501 | 100 | Return | 10 Oct | Reject rd-973 | OK-774 | |
| PR-69821 | 820 | Approve | 26 Oct | Return rd-237 | OK-954 | |
| PR-93301 | 720 | Return | 18 Oct | Approve rd-112 | OK-317 | |
| PR-69448 | 750 | Approve | 19 Oct | Reject rd-727 | OK-447 |
6 of 6 records
Approve rd-949Review decisions · RD-20255
ApproveParentPR-50525
Source revision540
Decided at17 Oct
Operation keyOK-368
What you can do
Review and award
An independent decision records the request revision, reviewer, choice and reason. For an evaluated tender, the Buyer executes an approved award against its frozen revision. The award operation validates the approved decision, persists an idempotent operation receipt and then marks the tender Completed. The operation key and expected revision make a repeated or conflicting attempt visible.
How the work is organized
- Request decision. The decision record names the reviewer, source revision, choice and reason.
- Tender outcome. An approved tender revision is the input to the award action.
- Operation result. The receipt records the key, expected revision and result before the tender becomes Completed.
The Purchasing Approver reads the submitted request and its decision history. The Buyer checks the approved tender revision before executing award. If the operation returns Failed or needs review, the team reads the failure reason and parent request before retrying. A repeated key should resolve to its recorded outcome. A Completed tender should have a matching completed receipt, not merely an approved label.
What to agree during setup
Agree who can approve a request, who evaluates tenders, and who investigates Failed or needs review receipts. Keep the person who prepared the demand separate from the reviewer.
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
Approve a pilot tender and run the award. Check that a Completed receipt points to the parent request before the tender is Completed. Repeat the operation key and confirm it resolves to the original outcome. Inspect a failed receipt for its reason and expected revision.
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
- Approved Tenders for Award — Check the approved tender revision before the Buyer runs award.
- Failed Operation Queue — Read the failure reason and expected revision before investigating.
Follow the work through
Follow demand and review, tender evaluation and award, then receipt and evidence.
What it keeps track of
Data model- Review decisions
- Independent reviewer decisions recorded against a purchase request revision.
- Tender submissions
- Sealed tender submissions evaluated and awarded against a purchase request.
- 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- Purchasing Approver
- 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.