GroundWorks · Purchasing & Ordering
The compliant route is the easiest one, and every exception reaches a named owner.
Guide compliant buying, resolve purchase-order exceptions and keep ERP execution aligned with policy.
The Workblock
Purchasing & Ordering · GroundWorks Buyline
- Can we remove a real handoff without creating a shadow order or a weaker approval path?
- Buying and ordering system of work
- 0 reference / 2 defined / 3 roadmap
Modules
- Guided buying: Match demand to policy, catalogue, supplier and approval paths before ERP execution.
- Requisition policy evaluation and routing: Validate catalogue, budget, supplier, category and authority conditions and send valid demand straight through.
- Purchase order orchestration: Create, dispatch, reconcile, change and close routine orders within explicit commercial and policy bounds.
- Purchase order exception resolution: Classify and resolve order exceptions with the right records and authority.
- Goods receipt and service-entry coordination: Ingest delivery evidence, reconcile quantities and schedules and coordinate the attestations only people can supply.
The question, answered
When that happens, an error code names the symptom and a person rebuilds the case. The buyer opens the requisition in one system, the order and its versions in another, the message log in a third, the supplier's response in a fourth, then decides what the code meant, who owns the fix and whether a resend is safe. Each system holds its part of the truth. Nobody holds the case.
On the requester side the same distance shows up earlier. The route that applies depends on policy, an agreement, supplier status and budget, and those facts sit outside the buying screen. So the request comes back for rework, waits on a question no one owns, or slips off contract because the compliant path was the harder one to find.
Can we remove a real handoff without creating a shadow order or a weaker approval path?
The buying stack largely works. Catalogue, punchout, requisition, approval, order, receipt: the ERP and the suite run the sequence, and they run it well. The cost sits where the sequence breaks: a failed order, a supplier who rejects or changes a line, a delivery that does not match, a status feed that goes quiet.
What changes
The exception arrives as one case: the affected order version, the evidence for its cause, the owner, the authority each option needs and the next valid action. It closes when the owning system shows the corrected state, not when a retry is sent.
Demand that matches an approved category, supplier and budget moves on the policy's authority, with the full record kept. People see the cases that carry an exception, missing evidence or material spend, and an exception can never quietly become routine.
The exception arrives as a case
A failed order raises an error code in a worklist. The resolver opens each related system, works out the cause by hand and closes the ticket once a retry is sent.
Attention follows materiality
Every request walks the same approval chain, so approvers clear queues of routine requests while the exceptional ones wait in the same line.
The principles it holds to
A proposal is never an order
A proposed route, correction or change carries its own state and never wears the language of a committed transaction. It becomes a requisition, an order or a receipt only when a named person or a validated policy commits it in the system that owns the record, and the committed result is confirmed at the source rather than assumed.
The ERP keeps the transaction
Catalogue, supplier network, receiving and finance records stay where they are. The Workblock assembles the policy, agreement, supplier and budget facts around the case, then carries only the approved action into the system that owns it. No shadow requisition, no shadow order.
An uncertain write never retries blind
A timeout leaves the commit state unknown, so the authoritative system is read before anything is resent. The attempt history is kept, a retry runs only under a named recovery owner, and one approved action produces exactly one transaction.
The records it authors
Buying request. A normalized statement of business need and context used to present policy-valid buying options before a requisition or commitment exists.
Purchase order exception. A deduplicated, policy-classified order variance that requires automated correction, monitored tolerance, or explicit commercial authority.
Return or delivery claim. A governed case for returning goods or recovering value after a short, damaged, rejected, substituted or otherwise non-conforming delivery.
Order line. A committed item or service instruction with quantity, price, delivery, accounting and fulfilment state.
Purchase order. A committed buying instruction with exact supplier, contract, value, delivery, accounting, authority and downstream reconciliation state.
Receipt. A committed record that goods or a measurable delivery were received, rejected or accepted with variance against order and despatch evidence.
Receipt line. A line-level accepted, rejected, damaged or short quantity against a committed order line.
Requisition. A policy-evaluated internal request for procurement commitment, including accounting, budget, authority and routing state.
Requisition line. A separately classifiable and routable requested item or service with quantity, price, supplier, delivery and accounting intent.
Service entry sheet. A governed claim and acceptance record for time-, milestone- or outcome-based services delivered against order and contract evidence.
Order response. An immutable supplier acknowledgement, rejection or proposed change to an order, normalized before any change becomes committed.
Shipment. A normalized despatch event linking packages, transport, quantities and expected delivery to committed order lines.
Case records
Durable, owned units of work. Each one holds the condition that opened it, the evidence gathered against it, the proposed action and the committed disposition, and it stays open until the condition is answered.
Transaction records
The commercial substance itself, canonical and versioned down to the line, with source provenance preserved beside the platform's own processing state.
Document records
Authored and received artefacts, kept at native fidelity as immutable versions, so the extracted terms never displace the thing they were extracted from.
Event records
Immutable observations that something happened, time-bounded and linked to their source, and never a decision in themselves.
The roles it serves
Execution flow and task definitions are not published. The dossiers name what each Workblock owns and how much of it there is; the definitions themselves travel with a delivery.
Workblocks can be versioned and changed independently, enabling continuous client tailoring.
Requester
State the need, the constraints and what was actually received. What is the right way to buy this, and where is my request now?
Procurement buyer
Own order creation and every supplier-facing change. What broke on this order, and what single action puts it right?
Budget owner
Own the spend and its business consequence. Do I have enough in front of me to approve this, and what happens if I do?
Receiver or service owner
Confirm what was actually received or accepted, and nothing more. What is due, what arrived, and what do I do about the difference?
ERP or integration owner
Protect transaction and interface integrity across order, message and status flows. Did that write commit, and is it safe to send again?
Module maturity
0 reference / 2 defined / 3 roadmap, of this Workblock's five business modules.
The rest of the register
- Previous
Supplier & Third-Party Risk Management (TPRM)
Every risk decision has an owner, a case file and a proportionate response.
Open the Workblock - The map
The GroundWorks map
Five stages and nine domain Workblocks, summarised once, each linked to the register page that holds it.
Back to the map - Next
Invoicing & Payment (AP)
A payment queue where every exception carries its records and its owner.
Open the Workblock