Skip to content
KeystoneOps KeystoneOps Docs

Purchase orders

For the helpdesk team

Purchase orders

Section titled “Purchase orders”

A purchase order (PO) is your structured commitment to a supplier — what you’re buying, from whom, for how much, on what timeline. Once raised it carries through approval, ordering, receiving, and closure.

The lifecycle

Section titled “The lifecycle”

POs move through a fixed sequence of statuses:

raised → approved → ordered → delivered → invoiced → paid
   ↘         ↘         ↘          ↘           ↘
        cancelled (available from any stage up to paid)
  • raised — created. Awaiting approval.
  • approved — green-lit. Can now be ordered.
  • ordered — placed with the supplier. Start tracking delivery.
  • delivered — the goods have arrived.
  • invoiced — the supplier’s invoice is in, against invoice_reference.
  • paid — settled. Final state; nothing transitions out of it.
  • cancelled — abandoned. Reachable from any stage except paid; also final.

Transitions are gated — each status only allows the next step (or cancelled). You can’t jump from raised straight to delivered; record the steps in between. Cancelling is always an option until the PO is paid.

What’s on a PO

Section titled “What’s on a PO”

A PO is a single header record — there are no line items. It captures one order, with one total:

  • Supplier — picked from the suppliers register.
  • Reference — your PO reference.
  • Description — what the order is for.
  • Total — total_pence, a single pence-precise amount for the whole order, with a currency.
  • Dates — raised, approved, ordered, expected delivery, delivered, invoiced, paid; each stamped as the PO moves through its statuses.
  • Invoice reference — captured when the PO reaches invoiced.
  • Notes — anything that doesn’t fit elsewhere.

Assets can be linked back to the PO they were bought under (the asset record carries the purchase_order_id), which is how “what did we pay for this and when?” gets answered from the asset register.

Moving a PO along

Section titled “Moving a PO along”

Advance the PO one status at a time as reality changes — approve it, mark it ordered, then delivered, invoiced and finally paid. Because there are no line items, there’s no partial-receipt step: delivered is a single header state for the whole order.

If the delivery doesn’t match (wrong item, damaged), don’t mark it delivered — raise a warranty claim or supplier issue and leave the PO where it is, or cancel it, while it’s resolved.

Gotchas

Section titled “Gotchas”
  • There are no line items and no per-line VAT. The PO carries a single total_pence for the whole order — record the gross figure your finance process expects.
  • Amounts are stored as pence integers. If you’re reconciling against a CSV in pounds, convert.
  • paid and cancelled are terminal — nothing transitions out of either. If you need to correct something afterwards, the audit log is your evidence; raise a new PO for any spend correction.
Section titled “Related”