The buyer's path: submit for approval
This is the path your customer's buyer walks at checkout. You will rarely walk it yourself, and you need to know it exactly: almost every procurement support call is somebody describing this journey badly over the phone.
What the buyer does not choose
Start here, because it is the part that gets misexplained.
The buyer never chooses between "order" and "request for approval". The shop submits the cart to the procurement app, and the app decides on the server whether it becomes an order, a purchase request or a refusal. A buyer who tells you "I clicked the wrong button" has not: whatever they clicked, the rules made the decision.
That is also why the controls cannot be bypassed from the shop: the decision is not the browser's to make. Keep one exception in mind. An order created directly from an order list in the Cockpit does not pass through the procurement app at all: no rule is read, no budget is booked, and the list's stored prices are used. For customers with approval rules, put list items into the cart and check out normally.
1. Cost centre on the line
Each line in the cart carries its own cost centre, because one delivery routinely covers three departments.
Which cost centres a line may use is decided by the restrictions on each cost centre: by contact, role, product, category, catalogue or punchout account. The shop asks the cost-centers app per line and gets back the usable cost centres, and an automatic choice when exactly one is left:
| Situation | What the shop gets |
|---|---|
| Exactly one cost centre usable on that line | That one, marked for automatic selection. The buyer need not choose |
| Several usable | The list to choose from, with code and name, for example 4711 Werkstatt Halle 2 |
| None usable | Nothing to offer for that line |
Automatic selection decides whether this feels like governance or like data entry. If your customer's buyers pick a cost centre on every line of every order, the restrictions are too loose: go back to Cost centres.
A cost centre stored on an order list position does not travel into the cart. The buyer books those lines at checkout like any other.
2. Submit
One submission. On the server, three kinds of answer can come back:
| Result | What it carries |
|---|---|
| Order | No rule asked for approval. The order with its number. The budget is booked against it at once |
| Purchase request | A rule asked for approval. The request with its PR number and the approvals it waits for. The budget is reserved |
| Refused | Nothing is created. The reason says why: a Prevent rule with its own reason text, a cost centre with no active budget (named by its code), or amounts in a currency the cost centre or the personal limit is not held in |
Most carts should land in the first row. If your customer's buyers see a request more often than not, the thresholds are too low; see Approval models.
When a rule is marked Show condition, the answer also names which kind of condition caught the cart, for example Personal limit, so the shop can tell the buyer why. The amount behind it is never passed on.
When a request is created, the budget is held immediately. A colleague cannot spend the same money while the request waits. Two things to know, though. A budget on its own stops nothing: without a rule on Available budget, a cart above the remainder is booked anyway and the cost centre's last budget goes below zero. And two carts submitted at the very same moment can both see the same remainder. The ledger shows either case.
A double click or a dropped connection is harmless. The submission is tied to the cart: sending the same cart again returns the order or request it already produced, never a second one. A cart whose request was declined or cancelled is refused; the buyer starts a new cart.
3. Follow it
You see every request under Procurement › Purchase requests, newest first, with PR number, status, buyer, organisation, total and, once there is one, the order. Filter by PR number, status or organisation. A request's Approvals tab shows each open and decided approval with its cost centre, step and approver; the History tab shows each outcome with its time.
What can happen next:
| Outcome | What follows |
|---|---|
| Approved | The order is placed and linked from the request. The reservation is confirmed against it |
| Declined | The request ends with the approver's reason. The reserved budget comes back |
| Cancelled | The buyer can cancel their own pending request, an administrator any pending one. The reserved budget comes back |
| Lines corrected while pending | Totals and the budget reservation follow the lines. The rules are not run again |
The apps send no message to the buyer about any of these. What the buyer sees of a request after submitting depends on what your shop shows from the procurement app.
What to check
Run these three carts as a buyer at the customer, before go-live, and look at each result in the Cockpit:
- A small cart, everything selected automatically. It becomes an order with no cost-centre choice at all. If the buyer had to choose anything, fix the restrictions.
- A cart slightly over a threshold. A purchase request appears under Purchase requests with status Pending, its Approvals tab names the expected approver, and the cost centre's budget shows a Reservation entry in its ledger.
- A cart with two lines on two cost centres. Both cost centres show on the request's lines, and later on the order lines that reach the ERP.
Common calls, and what they mean
| The buyer says | Look at |
|---|---|
| "It won't let me order" | Whether a Prevent rule matched, whether a cost centre on the cart has no active budget, or whether a line has no usable cost centre |
| "It made a request, I have permission" | Their personal limit, the cost centre's remaining budget, and the rules for their role |
| "The cost centre is missing" | The restrictions on that cost centre: product, category, catalogue, role, contact or punchout account |
| "Nothing happened after I submitted" | Purchase requests, filtered by the buyer's organisation. It almost always did |
| "I want to submit it again" | A declined or cancelled cart cannot be resubmitted. A new cart can |
Next
- The approver's path — the other half.
- Approvals that get stuck — when it stops moving.