Purchase order automation in an engineering stores means the part a fitter asks for is typed once, on the requisition, and read by everybody after it. The buyer reads it. Goods in reads it when the box lands. The invoice match reads it three weeks later, when a supplier wants paying and somebody has to prove what was ordered. On most sites it does not work that way. A fitter writes a part number on the back of a job card, the stores controller copies it into a spreadsheet, the buyer keys it into the purchase ledger, and the number is written three times before anyone touches the shelf. Guidance on invoicing and taking payment sets out what a supplier has to put on the document you are matching against. You are matching against your own handwriting too.

I would rather buy late than twice

I think the spreadsheet in the middle is the real problem, and nobody defends it out loud.

Every stores has one. It sits between the job cards and the purchase ledger, it has a tab per supplier, and one person understands it. That person is also the one who knows which merchant still supplies the obsolete bearing. Take the spreadsheet away and buying slows down for a fortnight.

Leave it there and you pay for a part that is already on a shelf upstairs, because the shelf was never in the spreadsheet.

What the stores hatch actually sees

A fitter arrives at the hatch with a job number and half a part number.

The rest is on the old unit, which is still on the machine, so somebody walks back out with a phone camera. The stores controller finds it on the shelf or does not. If not, it goes on the list. The list is a pad by the kettle, or a spreadsheet, or a message to the buyer, and on a bad week it is all three. (The pad wins.) By the time an order is raised the job card has moved on, nobody has written the part against the job, and the cost lands nowhere.

Then there is the stepladder. Slow movers live above head height, which is why the min and max levels on those lines are a work of fiction and the buyer is the last to find out.

How does purchase order automation work if the stores is on paper?

You start by moving the requisition, not the purchase order.

The requisition is where the part number is born, so that is the only place worth being strict about. A fitter raises it against the job, on a device at the hatch, picking from a list of parts that already exist in the system with a named supplier and a last price. The buyer approves a line rather than retyping one. Goods in books the delivery against that same line, and the invoice arrives into a three way match nobody has to assemble by hand.

HMRC says VAT records must be kept for at least six years, which is a great deal easier when the order, the delivery and the invoice were never three separate pieces of paper. Records are half of this work anyway, as our piece on servicing a regulated line sets out, where the maintenance log and the validated state both have to be current before anything restarts.

Where we would start in an engineering stores

We have not done this in an MRO stores yet, so here is where we would begin.

The first morning is at the hatch. You want the lines that actually move, the merchant on each one, and an honest answer about what the spreadsheet does that the system does not. Say a site carries four hundred stock lines and a hundred of them turn over every week. Those hundred are the ones worth a last price, a min level and a named supplier, and the rest can stay as free text until they earn better. That is a worked example rather than a benchmark.

Where the bottleneck turns out to be moving rather than buying, the answer is a different one, which our piece on flexing pallet capacity covers. Most of the time it is the buying. Joining up what you already run is the work we do, and it starts with the fact, not the software.

StepTyped twiceTyped once
Part identifiedOn the job card, then a padOn the requisition, against the job
Order raisedKeyed into the ledger from a listApproved from the requisition line
Delivery arrivesNote signed, keyed at the desk laterBooked against the order at the hatch
Invoice checkedThree documents found and comparedMatched on the line that exists
Spend against jobAdded up at month endCarried on the line from the start

What we built for a food wholesaler in Tottenham

We built and run the system behind a food wholesaler in north London, trade customers only, on Odoo.

Purchase orders are raised in that same system. That matters more than it sounds, because everything else the business does reads from it. Customers order on a trade website with a basket, or by message from a phone, and either way the order is keyed once. An order is checked against stock before anyone picks it. Pickers work on a warehouse device and each picked line takes a photo. The driver takes a signature on a device at the drop. Invoices and the VAT return come out of the same system and nobody retypes them.

An engineering stores is not a food wholesaler. Parts are slower, lines are longer lived, and nothing has a date on it. (Dates are the entire argument in food.) The habit is the same though. One place where the fact is born, and everything downstream reads it rather than copying it.

The leg a machine can take

Kitted parts still have to reach the job, and that is the leg worth giving to a machine. Autonomous forklifts take a movement order from the system that raised it and report the move back to the same place. One fact, one home. Which machine does the carrying matters less than whether one fleet manager can command machines from more than one maker, the point of our piece on controllers, where the controller underneath sets the safety rating and the navigation as well. The Health and Safety Executive workplace transport pages cover the duty side.

Purchase order automation in an engineering stores means the part a fitter asks for is typed once, on the requisition, and read by everybody after it.

Questions that come up at the hatch

Can autonomous forklifts integrate with our ERP?

They do not connect to it directly. A fleet layer sits in between, takes work from your business system over a documented interface, and turns it into missions. Completions and load confirmations go back the same way, so the system you already run stays the record of stock.

How do we integrate robots if our system has no API?

A scheduled export and import still works. Open work goes out on a timetable, confirmations come back, and middleware handles translation, retries and duplicates. It is slower than a live interface and it needs clear timing rules, but it leaves the core system alone, which on an older finance package is usually the whole point and the reason the project gets signed off at all.

What is a three way match in purchase ordering?

It is the check that the order, the delivery and the invoice agree before anybody pays. Done by hand it means finding three documents. Done on one record it means reading one line, because all three events were written against it.

Do we need to replace our finance system to automate purchase orders?

Usually not. Most of the pain sits before the ledger, where requisitions arrive on paper, in spreadsheets and as messages to the buyer.

Who should raise the requisition in an engineering stores?

The person who knows the part, which is the fitter or the stores controller, rather than the buyer. Buyers approve and negotiate. Asking a buyer to interpret a part number written on the back of a job card is how the wrong bearing arrives on a Thursday.

How long does purchase order automation take to set up?

Less time than tidying the data takes. Connecting the parts is rarely the long pole. Agreeing which stock lines deserve a named supplier, a last price and a min level is, and that work belongs to your stores rather than to us.

If the part number in your stores gets written out three times before anybody touches a shelf, that is the chain we would map first, from our office in Wimbledon in south west London.

Book a half day chain map, or read what we join up.

UK based engineers. No obligation. We reply within one business day.