Purchase Orders, Requisitions & Receiving

Procurement moves through three separate record types, each in Purchasing in the sidebar: Requisitions (an internal request), Purchase Orders (the formal order sent to a vendor), and Receiving (a read-only ledger of what's actually arrived — there is no “+ New Receipt” button; every receipt starts from a PO).

A Requisition and the PO it produces are two separate, independently approved records — converting an approved Requisition to a PO does not skip or inherit PO-level approval. The new PO always starts fresh at Requested.

Go to Purchasing > Requisitions and click + New Requisition. Fields: Title (required), Vendor (optional unless your org's Required Fields settings make it mandatory), Notes, and a line-items table. Each line picks an item from the Products/Parts catalog — quantity, unit cost (pre-filled from the catalog using your org's costing method, editable), an optional Project (only offered on Stocked Material / Project Material lines — never on a Maintenance Part line), and a computed line total. Tax Rate, Shipping, and Discount apply to the whole requisition.

Save as Draft to keep working on it later, or Submit for Approval to route it to the first approver in your org's chain.

Rejected has exactly one way forward — Reset to Draft. This is a bare status change; it doesn't clear the rejection reason from the approval history or restart a chain automatically. You'll need to submit again once you're ready.

Open an Approved requisition and click Convert to Purchase Order. This opens the New PO form pre-filled with the requisition's vendor and line items — nothing is created until you actually submit that form. Submitting creates a brand-new, fully independent Purchase Order (its own PO number, starting at status Requested), and the requisition's status jumps straight to Ordered the instant the PO is created, not when the PO is later actually ordered or received.

If line items span multiple vendors, use Split by Vendor instead — it groups the requisition's lines by each item's catalog vendor and creates one PO per vendor group in one action.

Nothing locks a requisition after conversion — you can click Convert (or Split) again and create additional POs from the same requisition. Its own line items are never modified by converting.

A PO can be created directly (Purchasing > Purchase Orders > + New Purchase Order) or arrive pre-filled from a requisition conversion — either way it's the same form and starts at the same status. Fields: Vendor, PO Date (defaults today), Payment Type (Check / ACH / Credit Card), Invoice Number, Notes, and line items — same pattern as a requisition, plus one addition: each line has a Taxable toggle (on by default), letting you exempt a specific line — a delivery fee, for example — from sales tax. Requisition lines don't have this toggle; if a requisition is converted, every resulting PO line defaults to taxable regardless.

• Requisitions and POs each go through your org's configured Approval Flow independently — see the Approval Flows guide for how a chain is built. If no flow is configured for that record type (or the flow has zero steps), the record auto-approves immediately.
• A step with no specific person assigned resolves to every user holding the required role — any one of them approving satisfies that step for everyone else at it. If nobody in the org holds that role, it silently falls back to the first admin as a catch-all.
• An admin submitting their own requisition/PO automatically clears any manager-level step in the chain (the step still shows in history, just marked skipped) — admins outrank managers in this flow.
• Only the approver whose turn it currently is can act — trying to approve or reject out of turn is rejected server-side with “It's not your turn to approve this yet — an earlier step is still pending.”

There's no standalone “New Receipt” screen — Receiving is a read-only ledger you search by receipt #, vendor, or PO #. Every receipt starts from a PO: open one with status Ordered or Partially Fulfilled and click Send to Receiving.

Each line pre-fills with whatever's still outstanding — ordered minus everything already received across any earlier partial receipts on the same PO — so partial receiving across multiple deliveries works correctly out of the box. Maintenance Part quantities round to whole units; material quantities allow two decimal places. Tax and any PO-level discount are prorated onto each partial receipt proportionally, so a discount isn't double-counted across multiple receipts. You must pick a Received By person before recording.

Recording a receipt does two things, in order: first, inventory updates — quantity on hand increases and a new cost layer is appended (see the Inventory Costing Methods guide for how that cost is computed) — and only after that succeeds is the receipt itself saved. If a line can't be matched to a catalog product, the whole receipt is rejected with an error and never saved.

Once every line on a PO is fully received, its status automatically moves to Completed; if only some lines are fully received, it moves to Partially Fulfilled instead. You can correct a receipt you already recorded by editing its quantities — the system applies the difference to inventory rather than re-receiving from scratch, so lowering a quantity by mistake correctly pulls the stock back down too.

• No GL code field exists on Requisition or PO line items today — if you're looking for GL coding on a purchasing line, it isn't there yet.
• PO/Requisition/Receipt numbers aren't strictly sequential. They're generated client-side from a timestamp, not a gapless counter — fine for day-to-day use, but don't treat them as audit-grade sequential IDs.
• Requisitions have no per-line taxable flag; POs do. If you need a tax-exempt line, that only becomes possible once it's a PO line.
• Nothing prevents converting the same requisition twice. Convert or Split by Vendor can be clicked more than once, creating extra POs against the same requisition — there's no lock after the first conversion.