The stock system that runs your warehouse

Stock Enquiry is the screen everyone has open. Goods In, Picking and Despatch belong to the scanners on the floor.

A typical business running one of these has one or two warehouses with 8,000 to 20,000 pallet locations, 25 to 60 staff over two shifts, an office of four or five, and a dozen to thirty customers whose stock it holds, moving 300 to 1,000 pallets a day. Whether it was written in 2010 or 2019, it does the same job, and the floor runs on it the same way.

Many 3PLs this size run a bought warehouse management package. This page is about the homegrown system, or the custom customer reporting bolted onto a package.

In the office's words, a delivery is booked in against the customer's notice or the paperwork on the pallet, labelled and put away by scanner into aisle, bay and level. Orders arrive by email and CSV in whatever shape the customer sends, are keyed or imported, picked in waves, and go out with a despatch note and carrier label. At eleven each night every customer is emailed their stock, and on the first of the month someone turns the pallet count into the storage invoice in a spreadsheet.

Each customer stayed for rules like these:

• One customer's stock is picked oldest best-before first, another's oldest received first, and two customers ban part-pallets from the top level.
• Storage counts pallets at midnight on Sunday for most accounts, on the last day of the month for one, and a half-pallet is a whole one for another.
• Stock held pending the customer's quality check is charged for storage but never shows as available.
• A pick short by more than one case goes to a supervisor before despatch.
• A location blocked for damaged racking stays out of putaway until a named person clears it.

Ask where those are written and the office points at the screen.

Written somewhere between 2008 and 2013 by a small local developer as a .NET Framework program on SQL Server, to replace the Access database and the spreadsheets before it. SSRS reports were added for the customers, one customer at a time, and the same program reaches the handheld scanners through a terminal session. It lives on a server in the warehouse office with the reporting server on the same box, and the office PCs open it from a shortcut on the desktop.

The developer moved on some years ago and took the working knowledge with them. Changes stopped when they left, spreadsheets have crept back in for the storage invoice and the stock count, and the scanners it was written for are no longer made. It cannot be opened from home, and the customers cannot see into it at all.

The same system built between 2016 and 2022, usually by a small agency or a freelancer, as a web system in PHP or React, Angular or Node, with a scanner app in Ionic for the floor. Some were put together in Zoho Creator or Power Apps by an operations manager over a quiet winter. The office opens it in a browser, the customers have a login of sorts, and the scanners are ordinary phones in rugged cases. From the office it looked like the problem was solved for good.

Despatch is usually where this one gives out. The label printing was wired to one courier's old booking link, and when the courier switched that off the despatch desk went back to the courier's own website, a parcel at a time. Each customer's report is a one-off page the agency wrote, so a new customer means a developer the business no longer has, and the agency itself has been bought and gone quiet. Since 2023 a few warehouses have tried an AI app builder for the customer portal, and it stalled once it had to count pallets by each customer's rule. For all its browser screens, it is as stranded as the program on the office server.

A warehouse that can find any pallet in seconds, and customers who trust the numbers.

A 3PL sells confidence. A customer hands over their stock and wants to know, each morning, what is there, what went out and what is on hold, without ringing. The nightly report answers that, and the fact that it has arrived at eleven every night for a decade is why the customer's own planning runs on it. Behind it, the scanner on the floor means the office knows what was done rather than what was planned: the pallet is where the system says it is.

The other half is the storage invoice. Pallet-weeks by customer, each with their own counting rule, is where the margin lives, and the system's count is the only record of it. When a customer disputes the invoice, the answer is the movement history for that pallet.

New customers come on without a new system, because the rules are per customer and the office has learnt where to put them.

Nothing in it is broken. What changed is what the customers and the floor expect.

The customers want a login and get a PDF. The report goes out at eleven and the customer's planner wants live stock at ten in the morning, and to key their own orders. Instead, orders arrive as spreadsheets in every shape, and someone in the office re-keys them. Customers who sell online want web shop and marketplace orders out the same day with a courier label, and the system cannot take them in.

The scanners cannot be replaced. On the older system the handhelds run Windows Mobile through a terminal session, and the program on the other end was written for that; on the newer one the scanner app was built for phones nobody sells now and will not install on the ones they do. Replacements come from auction sites, the batteries are worse each year, and there is no path to a handheld that can be bought new without a new program on both ends.

The reporting server lost its updates in July 2026. SQL Server 2016, and SSRS with it, sit on the same box, and the nightly reports depend on it. The biggest customer's supplier audit now asks which version, and the answer costs points.

Month end is a spreadsheet only one person runs. The pallet-week count comes out of the system, gets pasted in, and each customer's rule is applied by hand over three days. A wrong figure is argued for a fortnight, and nobody else has ever run it.

The same stock ledger, with the customers, the scanners and the invoice connected to it.

Each of these is built on something the system already does.

Live stock for the customers. A login showing their own stock, on hold and available, with order entry in place of the emailed spreadsheet. The nightly PDF keeps going for the customers who want it.

Scanners that can be bought new. A handheld app on scanners that are still made, against the same database and running the same putaway and pick logic, so the floor's process does not change when the device does.

The storage invoice from the system. Each customer's counting rule in data, the month-end figure ready on the first working day, and a dispute answered from the movement log instead of the spreadsheet.

Web shop orders in, courier labels out. Orders from the customers' web shops and marketplaces land on the pick list without keying, and despatch prints the courier's label and sends the tracking back.

Goods in from the advance notice. The customer's notice becomes the expected delivery, and the pallets are booked in by scanning against it rather than keyed from the paperwork.

Counts that do not stop the warehouse. Cycle counts from the scanner during the shift, by aisle, in place of the weekend stock take on paper.

Reports off the unsupported server. The SSRS reports on a reporting server that is still supported, or rebuilt, with the subscriptions the customers rely on kept running throughout.

The old program stays running through all of it, whichever generation it is. Each piece is added beside it, on the same data.

The paperwork at goods in, the orders that still arrive by email, and the stock questions no report answers.

AI takes what arrives in writing and what the office gets asked, and leaves the floor to the supervisor:

Delivery notes and packing lists read at goods in. The pallet arrives with a packing list, a delivery note or a photo of a label, and a clerk keys the SKUs, the batches, the best-before dates and the quantities against the customer's notice. AI reads the paperwork and pre-fills the booking, and the clerk checks it against the pallet rather than typing it. With a few hundred pallets a day coming in, each delivery's list keyed line by line, the goods-in desk typically gets two hours or so a day back.

Orders read from the customers who keep emailing. Some customers will never use the login, and their orders keep arriving as spreadsheets and PDFs. AI reads each one into the order the system expects, flags a SKU it does not recognise, and the clerk approves the order rather than keys it. Where a handful of the dozen to thirty customers still email, that is typically half an hour of re-keying back each morning.

Questions no report answers. "Which of this customer's pallets have not moved since March?" "Why did August's pallet count jump?" AI answers from the movement log in plain words, listing the pallets and movements behind the answer for the office manager to check before it goes to the customer. The half day a month of one-off spreadsheets typically goes back to the office.

Not worth doing: AI slotting for a warehouse this size. The supervisor knows which pallets belong where, and the racking rules the system already holds say what may not go on the top level.

Nothing should read or write the stock ledger before it is safe to change, so AI waits for the first stage. The assessment finds where AI would pay back soonest in this warehouse.

Stabilise first, then the scanners, because they are the thing most likely to stop the floor.

1. Stabilise. Source code found or recovered, for either generation, the database and the reporting server on supported versions, a backup restored on purpose, and a test copy to try changes against. First because the reports the customers depend on run on a server out of support, and because no new scanner can be pointed at anything until there is a test copy to point it at.
2. The scanners. A handheld app on scanners that are still made, against the same database, one process first, usually putaway. The old handhelds keep working beside it until the last one dies.
3. The customer login. Live stock and order entry on the same data. The nightly report keeps sending.
4. Storage invoicing from the system. The counting rules out of the spreadsheet into data, run in parallel with the spreadsheet for a month end or two.
5. The office screens in a browser, then retire the old program when nothing depends on it. The last thing to go is usually a report one customer's finance team has used for years.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a stock system that means a few days with the office, the floor and the code, finding how the scanners talk to it, where each customer's rules live and which reports the customers open, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work, what drives the price and the payment terms each have a page, and so does each technology in the system: .NET Framework, SQL Server, SSRS and the spreadsheets beside it, and for the newer generation old PHP, React, Angular and Node and the Ionic scanner app.