Raising an order, getting it signed by the right people for its value, receiving the delivery against it, and the requisitions that show what a branch actually asked for.
The order is the commitment
A purchase order is the one document in the chain that knows a delivery was wanted. The goods receipt knows what arrived and the invoice knows what's being billed, and those two can agree perfectly about goods nobody ordered. That's why over-delivery is measured against the order, why an invoice can only be entered against an approved one, and why the prices on an order are frozen the moment it's raised.
The Purchase orders screen needs view_procurement or manage_purchase_order. Orders sort into tabs: Awaiting approval (oldest first, because it's somebody's queue), Draft, Open (approved or part received), Closed (received, cancelled or rejected) and All. A Supplier filter narrows every tab at once, and Export downloads the tab you're looking at. A row only opens the order. Nothing is approved from a list, because a decision taken from a row is a decision taken without reading the lines.
Raising one
Raise order (needs manage_purchase_order) asks for the outlet that's buying, the supplier, and an optional expected delivery date. Pick a supplier and their agreed price list appears; Add items from it and each comes across with its negotiated pack size and price. For something the supplier has no agreed price for, search the catalogue below and type a price yourself. A line with no price at all is refused, because a zero would sail through every tolerance later.
Quantities are in purchase units: cases, crates, 25 kg bags. The Price ex VAT box shows the agreed figure as a placeholder; type over it and the line is marked "overrides 3,750.00", which is how a price negotiated on the phone gets recorded. The running Order value ex VAT is shown large because it decides who has to sign.
Three shortcuts prefill the form: Duplicate on any row of the list (last week's order, re-priced to today), Draft order from these on Stock on Hand when you've filtered to below-minimum items, and Raise a purchase order on an approved requisition (more below). Prefills carry items and quantities, never prices; every price re-resolves to today's agreed figure.
Save as draft lands you on the order. Nobody is committed to anything until you press Send for approval, and there's no edit screen by design: a wrong draft is cancelled and raised again.
From that moment every price and pack size is snapshotted onto the line and never re-read from the price list. Somebody bulk-updating prices on a Friday afternoon can't quietly rewrite what an open order agreed to, and the invoice match later has a fixed figure to check against.
The approval ladder
The chain is derived from the order's subtotal ex VAT and the thresholds on the Procurement settings screen (readable with view_procurement, changed only by a Tenant Admin holding manage_procurement_settings), fresh every time the order is opened. VAT is a pass-through you reclaim, so measuring on the inclusive figure would make the ladder stricter for Tusker than for maize flour. With the default thresholds:
| Order value (ex VAT) | Who signs |
|---|---|
| Up to KES 20,000 | One holder of approve_purchase_order, and the raiser may sign their own |
| KES 20,001 to 100,000 | An Outlet Manager (approve_purchase_order), then Finance (approve_purchase_order_finance) |
| KES 100,001 to 500,000 | Finance, then a Tenant Admin (approve_purchase_order_admin) |
| Above KES 500,000 | A Tenant Admin alone |
Above the self-approval limit the raiser is refused whatever they hold: "You raised this order. Orders above KES 20000 must be approved by somebody else." One person can't take two rungs of one ladder either; the button greys out with "You have already signed this order; a second approver is required." Rejecting needs a reason. Approving an order never does, since there's no variance yet to explain.
One more rule, about the branch rather than the value. Above the self-approval limit, somebody actually assigned to the receiving outlet must have touched the order: raised it, approved it, or asked for it on a linked requisition. Otherwise head office could raise, approve and countersign an order that lands at a branch nobody there ever saw. When the last signature would complete a chain with no local person on it, the server refuses and tells you the order has to start from the branch.
Thresholds apply immediately, including to orders already waiting, so the queue can re-sort under somebody mid-review.
Cancelling
Cancel order is offered on drafts and open orders to anyone with manage_purchase_order. The reason is required and is appended to the order's notes; it's the only record of why a commitment to a supplier was withdrawn, and there's no un-cancel. An order with goods already received against it can't be cancelled, and the button says so: "Goods have already been received against this order. Reverse the receipt before cancelling it."
Receiving the delivery
The phone is where receiving belongs. The mobile Receive delivery screen (needs receive_goods) lists approved orders waiting for delivery. Pick one, pick where the stock is going, and each line opens with the ordered quantity already in the Delivered box, because the common case at the bay is a complete delivery. Type what actually came off the lorry. Anything sent back goes in Rejected with a reason, never as a smaller delivered number: writing 88 when 100 arrived and 12 were broken balances the stock and erases the claim. There's room for the delivery note number, the supplier's invoice number (legible now, gone by the afternoon), and a photo of the note. Save delivery queues it in the phone's outbox ("Delivery saved on this phone. It will send when you have signal.") and it posts exactly once; a retry on a bad connection returns the same receipt.
The web has its own Receive delivery button on an open order, for the bay that had no device and for the second receipt against a partial delivery. Its lines open at what's still outstanding rather than what was ordered, so a second receipt can't quietly double the first. It asks for a storage location, the arrival time, and the same paperwork.
On either surface, the same things hold:
- What reaches the stock ledger is delivered minus rejected, at the order's agreed price per stock unit. That price is the inventory cost; if the invoice later disagrees, that's a price variance, not a revaluation.
- Goods can only be received against an approved or part-received order: "Goods cannot be received against a cancelled order".
- Once accepted quantities reach 98% of the order it flips to Received; below that it sits at Part received and can be received against again.
- The receipt gets a number like GRN-000123 and appears under Deliveries against this order.
Two extra things can appear on the receive form, each only where it is owed.
The excise stamp question. A line whose item is flagged as carrying an excise stamp gets a third control beside Delivered and Rejected: Stamps present, No stamps, or unanswered. A flagged line cannot post without an answer, and "no stamps" means the whole delivered quantity on that line goes back with a reason. It is deliberately not asked about anything else, because a question asked about a bag of rice teaches people to answer without looking. See Excise Stamps at Receiving.
Crates and returnables. Where the supplier has containers in the catalogue, the form gains a small section with a received and a returned box per container, because the delivery note lists both. Each container posts two rows in the container ledger rather than one net row, so the exchange stays visible on the receipt afterwards, and reversing the delivery reverses them with it. None of it reaches the stock ledger: a crate is not stock, it carries a deposit rather than a cost, and it is never consumed. See Crates, Kegs & Deposits.
Over-delivery is a decision, not a typo. Up to 5% above the ordered quantity posts without fuss. Beyond that the server wants a reason ("Supply an over-receipt reason to accept it") and it wants the receiver to hold approve_purchase_order, which a storekeeper doesn't: "Accepting a delivery beyond the over-receipt limit needs an Outlet Manager. Record what arrived up to the ordered quantity, or fetch someone who can approve it." Without this gate a supplier could deliver stock nobody ordered and invoice for it, and the match would pass, because receipt and invoice would agree perfectly.
A receipt is never edited. If a delivery was booked against the wrong order or mis-keyed, someone with reverse_stock_movement opens it and presses Reverse delivery, with a reason. Every movement it posted gets an opposing row, the order goes back to its earlier state, and the receipt and its correction both stay visible. The reversal is refused while a signed invoice is measured against that delivery: cancel the invoice first, since somebody accepted it on the strength of quantities that are about to be withdrawn. A settled invoice blocks the document reversal outright; establish the physical balance through a stock count and take the settled-value difference up with the supplier.
Once goods are in, Enter invoice on the order takes whoever holds manage_supplier_invoice straight to entry with the order preselected. See Invoice Queue.
Requisitions: how a branch asks
A requisition is an outlet saying what it needs on the shelf. No supplier, no pack size, no price, and quantities in stock units, because the kitchen knows it needs 20 kg of rice and shouldn't have to know whether that's one 25 kg bag or half of a 50. Anyone with create_requisition raises one from Requisitions on the web (or the phone's Ask for stock screen), adds items, and sends it. Somebody with approve_requisition accepts or refuses the need; the raiser can't decide their own, and the server says so: "You raised this request, so somebody else has to decide it."
The Requisitions screen has the same tab shape: Awaiting decision, Draft, To order (accepted, no order yet), Closed and All, with an outlet filter.
An approved requisition shows Raise a purchase order to anyone with manage_purchase_order. Choose a supplier and the stock-unit quantities are converted into that supplier's packs, rounded up, because you can't order 1.2 crates and rounding down leaves the kitchen short. An item the supplier can't price refuses the whole draft rather than dropping the line silently; a line that vanished here would be a shortage discovered at the delivery bay days later. The order records which requisition it came from, the requisition moves to On an order, and it can be ordered against again when one request is split across suppliers: beer from one, spirits from another.
That link matters most above the finance threshold. In those bands no approver can be assigned to a branch, so the people on the requisition are what proves the branch asked. A consolidated high-value order with no requisition behind it can't complete.
FAQ
I hold approve_purchase_order. Why can't I approve my own KES 35,000 order?
Because it's above the self-approval limit, and the rule is about who raised the order, not what you hold. Small daily orders (KES 20,000 and under by default) can be self-approved so the morning vegetable order doesn't need a second signature it would only ever get as a rubber stamp. Above that, somebody else signs.
The order says Part received but the whole delivery came. What happened? Either something was rejected at the bay or a line came in short. Open the receipt under Deliveries against this order and read the Rejected column. An order closes at 98% of the ordered quantity, so a genuinely full delivery reads as Received.
Can I edit the quantities on a draft? No. There's no edit endpoint for an order, so there's no edit screen. Cancel the draft with a reason and raise it again; Duplicate gets you most of the way there.
Why was the storekeeper refused when the supplier sent an extra crate? Accepting more than the order allows is an Outlet Manager's call. The storekeeper can record up to the ordered quantity plus the 5% tolerance, or fetch the manager. That keeps one person at the bay from being able to accept unlimited unordered stock alone.
Where do the prices on the order come from? The supplier's agreed price list, as of the day the order is raised, snapshotted onto each line. Changing the price list afterwards doesn't touch the order. See Suppliers.