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.

If a split fails partway (say the first vendor's PO was created but the second wasn't), you can close the dialog and reopen it, then retry — it recognizes the POs already created for that requisition and only creates the missing ones instead of duplicating the first.

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.

The New Purchase Order form also shows a read-only Part # column beside each line's item, filled in from the catalog entry (a dash if it has none), so you can check the part number without leaving the form. The New PO and Receive Goods dialogs are wider than they used to be so every column fits.

• 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.
• Managers can stand in for another approver on a step, but only on non-admin steps. A step whose Required Role is admin can only be decided by an admin (or the admin it was assigned to) — a manager doesn't see the override option there, and the server rejects it if attempted.
• 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.

If a Work Order already used some of that part before the stock was received (so the Work Order could only take what was on hand, and the Parts list shows a “used before received” badge), recording the receipt settles it: those units come off the incoming quantity automatically. A receipt of 3 for a part that two Work Orders had already used 3 of leaves quantity on hand at 0, not 3.

The status changes the moment the receipt is recorded — you don't have to click Done or keep the page open. 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.

Reports in the Equipt sidebar opens a tabbed page. Two tabs cover money spent:

• Parts Spend — spend on catalog items categorized as maintenance parts, with a date range picker (Last 6 months, Last 12 months, or All time; default is 12 months). Canceled and rejected POs are excluded, and each PO is placed in a month by its PO Date. The cards show Total Parts Spend, Avg Parts PO Value, Total POs, and Open POs, followed by a monthly trend and the top 5 vendors. The four cards are clickable — each opens the list of line items or POs behind that number (for Avg Parts PO Value, the parts-only amounts it's averaged from).
• Repair Cost — what maintenance actually cost, taken from the lines on each work order's Costs tab: Parts, Labor, and Vendors / Subs, with the same date range picker, a Preventive vs. Reactive split, a monthly breakdown, and the top 5 assets by repair spend. Total Repair Spend, Parts, Labor, and Vendors / Subs are clickable and open the individual cost lines behind them.

The Equipt Dashboard's Parts Spend MTD card also shows a smaller repairs MTD figure beneath it — the same repair-cost definition as the Repair Cost report, for the current month.

• 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.