Product
The purchase order isn't finished when you send it
Sending the PO is the middle of the job. What actually arrives — and whether the record says so — is what decides if next week's suggested quantity is worth anything.
Sending the order is the middle of the job, not the end
An order has two halves, and only one feels like work. The first is the decision — what to buy, how much, from whom, at what price — and it ends with an email. The second half happens weeks later, on a dock, usually while something else is on fire — and it is the half that decides whether the first half was true.
Assisty's Purchase Orders page puts it plainly: a purchase order isn't done when it's drafted. Review line items, email the PO to your supplier, and receive against it when stock arrives — with tax types, landed-cost allocation, and your own custom columns carried through every step. It sits alongside drafting and emailing because it belongs to the same object, not a separate chore.
Receiving is three acts, not one: take possession, inspect against the purchase spec, accept. The middle act is the one that gets skipped when a truck is waiting and a signature closes the visit. Skipping it is how a short shipment gets recorded as a full one — and the record, once wrong, is wrong quietly.
What a partial delivery does to the number you see next week
Every suggested quantity is arithmetic you can read: demand over your cover period, less incoming from open POs, less on hand, rounded to your case sizes and capped at your maximum stock levels.
Two of those terms are receiving's business. Incoming from open POs is what you're owed. On hand is what you have. Close a PO as fully received when only part of it landed and you move units across that line without them ever existing: incoming falls to zero, on hand rises by the full ordered amount, and both numbers are now confidently wrong in the same direction. The suggestion computes correctly on false inputs, which is the worst kind of wrong — it looks fine.
Suppose the buying table suggests 84 units of a mug: 168 units of demand over a 14-day cover period, less 60 units already incoming on an open PO, less 24 on hand. When that open PO lands, only 40 of the 60 units are in the cartons. Close it as fully received and on hand is recorded as 84 when the shelf actually holds 64. Twenty units now exist only in the database. The next suggestion subtracts all 84, so it under-orders by exactly the 20 that never showed up — and every cycle after that inherits the gap until someone counts the shelf. (Numbers illustrative, matching the worked example on the Smart Buying Table page.)
The failure mode is silence rather than error. If the record overstates on-hand, replenishment simply doesn't fire, because the system believes the need is already covered. There's no alert, because nothing crossed a threshold. You find out when a customer does. The standard term for this is phantom inventory — stock a system counts as available that isn't — and it isn't rare: RELEX, citing ECR Loss research, puts up to 60% of retail inventory records in error.
Short shipment, substitution, wrong case count: what actually arrives
The mental model behind most of this is binary: a PO is open, then it's closed. Physical delivery doesn't work that way — ordered and delivered quantities routinely differ, and the difference has to be recorded by someone at the dock rather than assumed away by a signature.
Four discrepancies show up at the dock, and the packing list is the reference document for all of them: short shipment, over shipment, substitution, and damage. Substitution is the sneaky one — a different variant arrives against the ordered line, the count matches, the paperwork looks clean, and two SKUs are now wrong at once. Damage is worse still, because possession and sellability part ways: the units are in the building and cannot be sold.
Then there's the case count. Suggestions get rounded to your case sizes, so you order in cases and you receive in cases — and a case that holds fewer units than you believe is a quantity error that passes every check based on counting cartons. The only version of receiving that catches it is the one that counts against the purchase spec.
A receiving-discipline contrast, not two product settings.
| What it does | Closed as fully received | Received for what actually arrived |
|---|---|---|
| What the record says | The full ordered quantity, unverified | The quantity someone counted |
| Next suggested quantity | Computed against stock that isn't there | Computed against the shelf as it is |
| When the gap surfaces | At the shelf, in front of a customer | At the dock, against the packing list |
| Cost of correcting it | A stock adjustment with no paper trail behind it | A count, at the moment you have the goods in hand |
| What the supplier conversation is about | Whether it ever shipped | A documented difference on a specific line |
Receive against the PO, and the loop closes itself
Receiving against the PO rather than into a void is what makes the correction cheap, because the PO already knows the things a bare stock adjustment doesn't. It was seeded from suggested quantities, so it carries what you meant to buy. It asks which location receives the stock, so the arriving units land somewhere specific rather than into a company-wide pile. It carries tax types, landed cost per line, and your custom columns through every step, so the cost that attaches to received units is the cost you negotiated, not a fresh guess.
It also dates itself. You set lead times per supplier when you assign their products, and the gap between the day a PO went out and the day stock actually landed is the only evidence you have about whether that number is still true. A supplier who consistently quotes one lead time and delivers on another isn't a problem you fix by ordering more — it's a field that needs updating, and receiving is when you learn it.
| Input | Where it comes from | What receiving controls |
|---|---|---|
| Sales velocity | Your sales history, in the suggestion's arithmetic (buying-table.html) | Nothing — the sales record is its own source |
| Lead time | Set per supplier when you assign their products (purchase-orders.html) | The evidence for whether the number you set still matches reality |
| Incoming from open POs | Subtracted in the suggestion's math panel (buying-table.html) | Receiving is what syncs those units out of incoming and into stock |
| On hand | Subtracted in the suggestion's math panel (buying-table.html) | Everything — this is the number a receipt writes |
| Case size and maximum stock level | Rounding and capping applied to every suggestion (buying-table.html) | Whether the case you received holds the units the case size assumes |
| Receiving location | The PO asks which location receives the stock (purchase-orders.html, buying-table.html) | Which location's on-hand the arriving units land in |
| Landed cost and custom columns | Carried through every step of the PO (purchase-orders.html) | The cost that attaches to the units you received |
Six of the seven inputs above are touched at the dock — every one except the sales record itself. That's the ratio worth remembering: the risk-flagging that tells you three items run out before a reorder can land, and the fit-to-budget arithmetic that trims the plan, all run on numbers a receipt either confirms or corrupts.
None of this makes physical counting optional: reconciling system quantities against physical counts on a schedule remains the backstop, because receipts drift for reasons no document catches. But a periodic backstop is no substitute for a record that was right on the day.
The buying table commits nothing until you create the order, and the Purchase List will hold staged items, priced with each supplier's tax and currency, until you've finished reviewing. All that care upstream is spent on inputs. The receiving step is where you find out whether the inputs were real — and it's the last point where fixing them is free.