CASE STUDY · DISTRIBUTION WAREHOUSE RUNNING AN ON-PREMISE ERP
Four scan stations, one shared source of truth
Receiving, bin locations, packing and counts all ran on paper and memory. Four small scan apps now write straight into the ERP, with a name on every entry.
THE PROBLEM
A short delivery was found six weeks later, when the books were checked. Nobody could say who packed the order that went out wrong. And the count that would have caught both takes the building offline for a day.
- 4apps, one shared truth
- 0new staff accounts to manage
- 3ERP records per scan
- Same dayshort deliveries caught
The problem
Four separate jobs on one warehouse floor, all running on paper, memory, and the two people who knew how it really worked.
Receiving was a printed purchase order and a pen. Short deliveries turned up at month end, long after the supplier would credit them. Bin locations lived in one person’s head, so a new picker walked the aisles hunting for stock the system said was somewhere. Packing had no record of who did it, so a badly packed order was a mystery and nobody learned anything from it. Counting happened once a year, took the building offline, and produced numbers that were already out of date by the time they were typed in.
Every one of these was the same problem in different clothes: the work happened away from a desk, and the record of it got written down later, by somebody else, from memory.
What we built
Four small apps, one per job, all writing into the ERP the client already runs.
At receiving, the operator opens the purchase order on a tablet and scans the delivery. Case barcodes are matched to their unit barcode and case size automatically, so a pallet of cases doesn’t have to be counted in pieces. Over-deliveries are flagged at the door. When every line is done, the session closes itself after a five-second countdown.
Bin locations gives a searchable map of what’s in which slot, with quick plus and minus buttons for adjustments made in the aisle, and a spreadsheet export for anyone who still wants the list on paper.
The pack station is deliberately the simplest thing in the building: tap your name, scan the order. The first scan is the packer signing for it, the second is the checker confirming it, and a third is refused. Two times and a name, written straight into the ERP’s own columns.
Counts run on a phone. Scan the shelf tag and the screen shows the bin it should be in, how many are already promised to open orders, and what’s on the way from suppliers — so the person counting isn’t counting blind. Enter cases and loose pieces and the app shows the arithmetic back in plain words before saving. A change bigger than a set threshold stops and asks.
The technical decision worth naming: where these apps have logins, they check against the ERP’s own staff list rather than keeping their own. There’s no second list of people to maintain, and switching someone off in the ERP locks them out of the floor immediately.
The result
Problems are caught at the door instead of at month end, while the supplier will still credit them. Every quantity change carries a name and a time, written into the client’s own records so it shows up in their existing reporting with no extra work. Counting happens continuously on a phone instead of once a year with the doors shut.
The four apps never talk to each other. They connect through the ERP: the counting screen reads the pack station’s times to warn that an item is being picked right now, reads the bin app’s data to tell the counter where to look, and reads the receiving app’s updates to flag stock that arrived this morning. One source of truth, four windows onto it, and no middleman to go wrong.
Why it holds up
- Changes are safe and reversible. Receiving updates the order line, the order header and the item quantity as one chain. Anything that fails goes into a retry queue rather than vanishing. Every receipt can be undone, and the undo is built to survive a half-finished failure.
- A second delivery doesn’t wipe out the first. The receiving app records the ERP’s starting quantity the first time it touches a line, so a second delivery against the same order adds to what’s there instead of replacing it.
- Clocks are handled on purpose. Times are pinned to the warehouse’s own time zone, and one app takes its time from the database itself so its history lines up exactly with the ERP’s.
- Each app installs, updates and removes with one command, backing up its data before every update, with health checks and automatic restarts throughout.
INSIDE THE SYSTEM
What it actually looks like
NEXT
Related work
Stop overselling across every storefront
Two customers bought the last one within an hour of each other, on two different stores, because neither store knew the other had already sold it. Somebody had to phone one of them and apologize.
Read the case studyFrom scan to printed label, one screen
The packer reads the address off one screen and types it into another, weighs the box and types that in too, compares carrier tabs by eye, then goes back into two systems to paste the tracking number. Per box.
Read the case study