Purchase orders — the formal buy, from request to send

A purchase order is the piece of paper — these days, the digital record — that turns “we should buy more tomatoes” into a commitment. It names the supplier, lists what you’re ordering and at what price, and sits in a known state until the goods arrive at the back door and get checked off against it. Without it, the kitchen orders by phone, the accountant pays whatever invoice the supplier sends, and nobody ever finds out whether the basil arrived at the price the supplier promised on the call.

This page covers the buying side — the request, the approval, the sending. The mirror page, receiving overview, covers what happens when the boxes actually land at the back door and stock has to move.

What it does

Most kitchens that grow beyond a couple of staff hit the same problem. The head chef knows what’s running low, the sous knows what’s needed for Saturday’s banquet, the bar manager knows the gin is down to two bottles — and three different people quietly phone three different suppliers. Two of them order the same thing. Nobody writes anything down. The invoices arrive a week later and the owner discovers they spent €4,200 on produce in a fortnight without ever seeing a budget.

The purchase-request and purchase-order pair solves that with a small, deliberate friction. Anyone who notices a shortage opens a purchase request — a draft list of what they think the kitchen needs — and submits it for approval. The owner or manager sees the list, can edit the quantities and prices, can reject the whole thing, or approves it. Once approved, the request is converted into one or more purchase orders, one per supplier, which is the formal “we are buying this” record that goes out to the vendor. When the boxes arrive, the back door receives them against the purchase order — so the invoice the supplier sends a week later can be checked against a number that was agreed in advance.

The third reason this flow exists is consolidation. Three line cooks each filing a request for olive oil shouldn’t generate three orders to the same supplier — that’s three deliveries, three invoices, three trips on the supplier’s van. When several approved requests share a supplier, the system suggests combining them into one order so the supplier sees one clean list and ships it once.

The rule

The request is a wish; the order is a commitment. Anyone who notices a shortage can request; only an approver can turn a request into an order that goes to a supplier. Every kilo that enters the kitchen is later received against an order — that’s how the cost stamped on the pantry row stays honest.

How the flow works

The whole sequence has three stages. Each one is its own screen, but they hand off automatically.

Stage one — the purchase request

Open Admin → Orders → New Purchase Request (or + New PR from the orders hub). The form opens with a date picker for Needed by and a Priority dropdown — Low, Normal, High, Urgent. Below that, the Items editor lets you pick from inventory, type a quantity in purchase units (tins, cases, bottles — whatever the supplier sells in), and watch the line total tick up as you go. The header above the editor shows a Below par banner the moment you open the form: if the system spots inventory items currently under their par level, it offers an Add all to request button that drops every short item onto the draft in one tap. That alone saves the morning audit of the dry-goods shelf.

When the list reads the way you want, click Submit for Approval. The request gets a number (something like PR-0042), moves to the Submitted status, and lands in the approver’s queue. You can also click Save Draft to come back to it later — drafts are private to you until you submit them.

Stage two — the approval

The owner or procurement manager opens the orders hub and sees the submitted requests in the Pending Approval list. Tap into one and you see the request in full: every line, the requestor’s name, the date they need the goods by, an estimated total. You have three actions: Approve the request as-is, Edit the lines and then approve (you’ll be asked to leave a note explaining why you changed them — the requestor sees the comment), or Reject with a written reason.

Editing is where this stage earns its keep. A line cook may have over-ordered out of habit; the manager halves the quantity. A price on a row may be out of date; the manager corrects it. The edit history is preserved on the request, so a month later it’s clear who changed what. Approval moves the request to Approved, ready to be turned into one or more purchase orders.

Stage three — the purchase order

From the orders hub, approved requests roll up under a PR combine suggestion banner: “2 requests share Pasta Vera — combine into one purchase order?”. Tap the suggestion and a new purchase order opens with every relevant line already filled in, the supplier pre-selected, the prices inherited from the supplier’s catalogue. You confirm the Expected delivery date, the Payment terms (which default to whatever the supplier record says — NET 30, COD, whatever), and the Currency. Each line shows a small vs catalog badge if you’re pricing it above or below the supplier’s standard rate — useful when the supplier offered a one-off discount on the call.

You can also create a purchase order from scratch, with no preceding request, when the situation calls for it — Admin → Orders → New Purchase Order, pick the supplier on step one, fill in the lines on step two. That path is for one-off ad-hoc buys (a special bottle for tonight’s tasting menu, a piece of equipment).

When the order reads the way you want, click Create PO. The order gets its own number (PO-0118 or similar), and is ready to go out to the supplier. The order then sits in the system in a known state, waiting for the goods to arrive — at which point the kitchen receives them against this order, the receiving flow stamps fresh costs on every pantry row, and the loop closes.

Worked example

Anna runs a small Italian kitchen. Tuesday morning, Marco the sous chef opens the kitchen and notices the pantry shelf is light: tomatoes are short for Friday’s bolognese run, the parmesan is on its last wheel, the olive oil is down to one bottle, and they’re nearly out of basil.

He opens Admin → Orders → New Purchase Request on his phone. The form opens and a banner at the top says 6 items below par — Add all to request. He taps it. Six lines drop into the editor: tomatoes (3 cans short), parmesan (1 wheel short), olive oil (4 litres short), basil (1 bunch short), pecorino (2 wheels short), and 00 flour (2 sacks short). He adjusts the basil to 3 bunches and the olive oil to 6 litres — Friday’s prep will need it.

Priority: Normal. Needed by: Friday. He taps Submit for Approval. PR-0042 lands in Anna’s queue.

Anna opens it from the dashboard ten minutes later. The estimated total is €312. She reads through, agrees with everything except the basil — three bunches feels like too much for a four-service week. She clicks Edit, halves the basil to 1 bunch, leaves a comment (“plenty of basil from the garden this week”), and clicks Approve.

Back on the orders hub, she sees a green banner: ⚡ 1 PR combine suggestion — PR-0042 → Pasta Vera (5 items) + PR-0041 → Pasta Vera (3 items): combine into one PO?. She taps it. A new purchase order opens with all 8 lines pre-filled, Pasta Vera selected, expected delivery defaulted to Thursday (the supplier’s standard lead time of two days from a Tuesday order). The total is €418.

Two lines show a +2.1% vs catalog badge in red — the supplier’s last price list quoted slightly lower. Anna leaves a sticky note in her head to ring them about that. She confirms the Payment terms as NET 30 (inherited from the supplier record) and clicks Create PO. PO-0118 is created and sits in Sent status.

Thursday morning, the Pasta Vera van pulls up at the back door. Marco opens Receiving → Receive a delivery, picks PO-0118 from the supplier-grouped list, photographs the delivery note, taps Confirm Receipt & Update Stock. Stock goes up across all 8 rows; the cost stamps on each pantry item are now current to today’s prices. The bolognese recipe that uses the tomatoes recomputes; the cacio e pepe that uses the pecorino recomputes; the dashboard’s food-cost percentage refreshes overnight.

From “the shelf looks light” Tuesday morning to “the boxes are unpacked and the costs are honest” Thursday lunchtime — three taps from Marco, three from Anna, one delivery, one invoice, one number per ingredient.

Receiving — overview — the mirror flow: what happens when the goods from a purchase order actually arrive at the back door.
Suppliers — overview — the directory of who you buy from, and the price lists that drive the per-unit prices the request and order use.
Inventory — overview — the pantry rows the request reads par levels from, and the rows the order’s eventual delivery raises stock on.
Prices, costs, and margins — the rule about how the cost stamped by a received order ripples through every recipe and dish that uses the ingredient.