Warehouse robot ERP integration means the movement order is born in the system the client already runs, and the confirmation lands back in the same place. In a 3PL the pallet move is the billable event, so the record of that move should be written by whatever performed it rather than typed up at the desk an hour later. Month end is where this shows. The client questions the handling lines on the storage invoice. Somebody on your side opens the inbound sheet, then the racking notes, then a run of emails from the shift that took the load, and rebuilds a fortnight of movements from three sources that half agree. Duties for vehicles and people sharing a yard are set out by the Health and Safety Executive. Those duties assume somebody knows where every load went, which is the same assumption your storage invoice makes.
The move is the product
I would rather a 3PL bought the movement record before it bought the vehicle.
Most of the operators I speak to want the truck first, because the truck is the thing you can show a client on a site visit. The record is the thing you invoice from.
Buy the vehicle without the interface and you own a fast machine whose work still gets typed up by a supervisor at the end of a shift. That supervisor is honest and tired, and the dock plate has been down since before the sun came up.
The load lands before the paperwork does
The ASN lands on Tuesday for a load that arrives on Wednesday. It promises a trailer of a client's stock, priced by pallet and by movement. A pallet fewer comes off, and the driver's note says so in biro.
The dock plate goes down. Your people put the stock away across several racking bays, one of them a temporary bay near the door because the client's own aisle is full. (It is always the temporary bay.) It is a normal Wednesday.
What happens next is the part you bill for. Between the trailer and the racking, a set of movements happened. Inbound to staging, staging to bay, bay to bay when the aisle cleared on Thursday. Those movements are the difference between a storage invoice the client signs off in a morning and one that sits in a queue for a fortnight while two teams compare notes.
In regulated distribution the same problem gets handled by letting the machine that made the move write the location history, instead of rebuilding it from a handheld afterwards. Pharmaceutical sites got there first because an auditor asks.
Do I need to replace my WMS to use AMRs?
Almost never, and the cases where you do are rarer than the people selling replacements suggest. A fleet layer sits above the warehouse system you already run, takes work out of it, and hands it to the vehicles. Your system stays the record of stock and of what the client is charged for.
Replacement only earns a conversation where the existing system cannot hand out open work at all, by interface or by a scheduled file. Even then, middleware is usually cheaper than a migration in your busiest quarter. (Nobody migrates in November.)
There is a safety argument too, which the finance argument tends to drown out. Handling, lifting and carrying accounted for roughly one in six of the non-fatal injuries UK employers reported in the last published year, as this week's piece on 3PL peak variance sets out. Moves taken off people are moves that stop appearing in that count.
How we would map a third party site
We have not done this inside a third party warehouse yet, and I would rather write that down than imply otherwise. Here is the first morning anyway.
We walk the chain from the ASN to the storage invoice and mark every point where a fact about a pallet gets written by a person. Then we mark which of those writings the invoice depends on. In a 3PL that list is short and nearly always the same. Inbound against the advance notice, putaway to a location, any move between locations, and despatch.
For example, say a client is billed a handling charge per pallet in and per pallet out, and a storage rate by pallet week. Every one of those lines traces to a movement that either exists in the system or exists in somebody's memory of Wednesday.
| Movement | Written by hand today | Written once by the move |
|---|---|---|
| Inbound against the advance notice | Sheet at the dock, keyed later | Confirmed at the trailer, on the device |
| Putaway to a location | Bay noted, typed at shift end | Written by the vehicle that moved it |
| Move between bays | Remembered, sometimes | Movement order, then a completion message |
| Despatch | Note signed, copied to the invoice | Signature posts against the same order |
| Storage invoice lines | Rebuilt at month end | Assembled from the movement record |
HMRC says VAT records must be kept for at least six years, and the movement history behind a storage invoice is part of what somebody may ask you to produce.
The table is the conversation we have in the second hour. It is rarely about robots.
The leg a machine can take
The physical leg is the easy part to picture and the last part to decide.
An autonomous forklift or pallet truck takes the inbound to racking run and the bay to bay run, and it takes them from a movement order raised in the system the client is already billed from. The vehicle reports the move back to the same place.
Where more than one make of vehicle is on site, a fleet layer issues the work so you are not running two sets of rules. Night cover is where the difference shows, because a scheduled fleet holds the same putaway rate at three in the morning as at eleven.
Vendor choice comes after the interface.
In a 3PL the pallet move is the billable event, so the record of that move should be written by whatever performed it rather than typed up at the desk an hour later.
Short answers, before you ask
What data does a robot fleet exchange with an ERP?
Task requests go one way. What to move, from where, to where, with a priority and a deadline. Back the other way come acceptance, progress, completion, exceptions and load confirmations, and those confirmations are what trigger a stock movement. Battery state and fault codes stay in the fleet layer and are summarised for reporting.
How do warehouse robots update stock levels in real time?
Each completed move sends a confirmation naming the load, the location it left and the location it reached. Your warehouse system posts that as a stock movement, so balances change as pallets change bay rather than at a shift end count. A failed or abandoned move has to raise an exception instead of posting quietly, which is the part worth testing before go live.
How do we integrate robots if our system has no API?
A scheduled export of open work and an import of confirmations is often enough to start with. Middleware handles the translation, the retries and the duplicates. It runs slower than a live interface and it needs clear timing rules, and it avoids opening up the core system, which is usually why people choose it.
How do 3PL companies bill for pallet movements?
Most charge a handling rate on the way in and out, and a storage rate by pallet for a period. The arithmetic is easy. The argument is always about which movements actually happened, and the movement record settles that faster than any rate card.
Can we start with one robot and add more later?
Start with one run and one vehicle. Adding vehicles is a fleet layer question once the interface exists, and a far smaller job.
Will warehouse robots make our storage invoice accurate on their own?
They cannot, and the premise is worth unpicking. A vehicle only writes a movement the system asked it to make. Where locations are not uniquely named and balances are already doubted, automating on top multiplies the error rather than removing it. Fix the location naming first, and the movement record becomes worth billing from.
The movement record is the cheapest thing to fix on a third party site and the last thing anyone budgets for.
Book a half day chain map, or read what we join up.
UK based engineers. No obligation. We reply within one business day.