1. E-procurement Portal
  2. Features
  3. Purchase demand
Feature · Purchase demand

Purchase demand

Purchase demand for the procurement team and its reviewers.

OverviewMy Purchase Requests
E-procurement Portal · Purchase demand

My Purchase Requests

Purchase requests

New
Record numberSubjectStatusRequired byRequested amount USDRevision
PR-48403Draft pr-964Draft15 Oct820860
PR-23362Submitted pr-679Submitted05 Oct750480
PR-84381Approved pr-223Approved13 Oct500670
PR-40272Ordered pr-530Ordered10 Oct100440
PR-99460Received pr-568Received10 Oct940510
6 of 6 records
Draft pr-964Purchase requests · PR-48403
Draft
Required by15 Oct
Requested amount USD820
Revision860
Example screen with sample data

What you can do

Purchase demand

A Buyer raises demand under a buying organization, assigns an owner and supplier, and records the required date, budget code and requested amount. Purchase lines capture each requested quantity and unit price. A submitted request gives the Purchasing Approver a specific revision to consider. The linked decision record shows the reviewer, reason and request revision behind the outcome.

How the work is organized

  • Scope. Buyer records the subject, required date, requested amount and budget code on the request.
  • Lines. Requested quantities and unit prices explain the amount under the parent request.
  • Review. Purchasing Approver checks the submitted revision against its linked decision record before work proceeds.

A request can be Draft, Submitted, Approved, Ordered, Received, Rejected or Cancelled. The Buyer uses those states to find the next task, while the reviewer needs the exact revision behind an approval. If the supplier or amount changes after a decision, compare the decision source revision with the request revision. Keep the original decision visible while the changed request is reviewed again.

What to agree during setup

Agree who owns the request, how the budget code is chosen, and who verifies that the amount reflects its lines. Set a convention for changing a reviewed 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

Raise a pilot request with two lines and a required date. Confirm the Buyer sees it in My Purchase Requests. Submit it, inspect the same revision in Requests Awaiting Review, then check the linked decision. Change the amount and check whether the decision still refers to the revision in front of the reviewer.

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

  • My Purchase Requests — Find owned requests by status and required date.
  • Requests Awaiting Review — Open the submitted revision and its lines for a decision.

What it keeps track of

Data model
Purchase requests
Demand records raised by buyers, carrying lifecycle, budget and supplier context.
Purchase lines
Line items belonging to a purchase request, with requested and accepted quantities.
Organizations
Buying organizations that own procurement records.
Team members
Authenticated platform identities with a role inside an organization.
Suppliers
Registered suppliers eligible to receive tender invitations and orders.

Who uses it

Permissions
Buyer
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