Ordering from a supplier who is already in the system
Every purchase order gets typed twice: once by you, once by them. Everything that goes wrong afterwards starts with that second typing.
Here is a purchase order's actual life in most repair shops.
You work out what you need. You write it in an email, or a WhatsApp message, or into a portal that belongs to your supplier and looks like it was built in 2011. Somebody at the other end reads it and types it into their own system. They reply with what they can do and what it costs. You read that and type it back into yours.
Two people, typing the same list, into two systems that will never speak to each other again.
Everything downstream inherits that
Once the same order exists in two places, every later question becomes an archaeology exercise.
The box arrives short — short against what? Your sent folder, or their picking note? The price on the invoice is not the price you remember — remember from where, the email or the reply to the email? A part goes back and a credit is agreed — agreed by whom, and against which order?
None of these are dramatic. Each is £30 or £60 and twenty minutes. They are invisible because there is no single record either party can point at, so nobody can be shown to be wrong and nothing gets fixed.
The fix is not a better email
It is that the order is one record with two viewers.
You raise a purchase order in your own system, off your own stock levels. It arrives in the supplier's system as an incoming order. Not a PDF of your order. Not a notification prompting them to go and type it. The order.
From there, the interesting parts are the ones that used to be conversations:
They can only supply some of it. They send back a quotation with the lines they can do, at the prices they can do them. You approve line by line. What you did not approve is cancelled rather than assumed.
The price has changed. The re-quote is a new version of the same document, with a reason attached. You see that the price moved and why, before it turns up on a bill.
They offer an alternative. A different part, as a line-level suggestion you accept or decline — not a substitution that appears in the box and gets discovered on a Tuesday.
Reserving is not sending
This is the part most systems get wrong, and it is worth being fussy about.
When a supplier approves your order, the stock should be reserved — held against your order, not available to be sold to the next shop that rings. But it has not left their building yet, so it should not have left their stock figures either.
Those are two different events, and collapsing them into one is how a supplier ends up selling the same four screens twice. Reserve on approval. Deduct on dispatch. If a system cannot tell you which of those has happened, its stock figure is a guess.
Receiving is where the money is
The box arrives, and this is the moment worth thirty seconds of somebody's time.
Book in what actually turned up, line by line, and let the outcomes be different from each other: accepted, damaged, missing, wrong item. Only the accepted goods should reach the shelf. Everything else should open something — a discrepancy, a return, a credit expected — rather than being absorbed into a shrug.
A process with only "received" and "not received" cannot record thirty-six against an order of forty. So it records forty, and the four are gone.
Paying, and being believed
The last unglamorous piece: you pay, and the supplier's statement still says you owe it.
The honest model is that a payment you record is a claim until the other side confirms it. Not because anyone is lying, but because two ledgers take time to agree and it is useful for both parties to see which items are agreed and which are still in flight. A claim awaiting confirmation should never quietly reduce a confirmed balance — that is how one side ends up arguing from a number the other has never seen.
Is it realistic?
Only if your supplier is on the same system, and today most will not be. That is worth saying plainly rather than pretending otherwise.
But the parts that do not depend on them are worth doing anyway. Raise real purchase orders. Receive against them, per line, with real outcomes. Keep bills matched to receipts. All of that works with a supplier who has never heard of your software, and it is where most of the leaked money is.
The connected version is what happens when the supplier is on it too. Then the second typing — the one every later problem descends from — simply does not happen.
How this works in SlickCell Pro, from the shared catalogue to the payment confirmation, is on Supplier network. The supplier-agnostic half is on Purchase orders & receiving.