The stock and purchasing system your warehouse picks from

The buyer opens it before the kettle has boiled. The pickers work from what it prints until the last van has gone.

A typical business running one of these has 20 to 80 staff, a main warehouse and one or two branches, 5,000 to 20,000 stock codes, 50 to 200 supplier purchase orders a week and somewhere between 300 and 1,000 pick lines a day. A few million pounds of stock sits in it. Whether it grew out of an Access database in 2004 or went live in a browser in 2019, the job is the same, and the warehouse leans on it in the same way.

Every morning the suggested order list comes up, built from the reorder levels, the stock on hand and the orders already placed. The buyer corrects it from memory and raises the purchase orders, which go to the suppliers as PDFs by email. Goods-in books each delivery against its order, prints the bin labels and notes the shorts and the overs. The warehouse prints pick lists in bin order, raises the transfers for the branch and posts the adjustments. Once a month the valuation runs for the accountant, the dead-stock report runs for the MD, and twice a year the count sheets come out for the stock-take.

The rules only this system knows:

• Reorder levels are per location, and the branch's is a fraction of the warehouse's, set by the manager who opened it.
• Some suppliers have a minimum order value or a carriage-paid threshold, and the suggested order rounds up to reach it when it is close.
• Stock at the branch belongs to the warehouse until the transfer is booked, so the valuation counts it once.
• Goods-in accepts an over-delivery of up to a tenth on some product groups and none on others.
• A product that is out can be picked as a substitute, from a list of pairs the buyer maintains.

Started around 2004 as a Microsoft Access database for the reorder levels, written by the buyer of the day or a contractor. When the second location opened, around 2010, a small software house wrote the goods-in and picking screens as a .NET Framework desktop program and moved the data into SQL Server. An IT contractor added the SSRS reports for the monthly valuation a few years later. The Access screens are still what the buyer uses for suppliers and reorder levels. All of it runs on one Windows server in the warehouse office, with the goods-in program installed on the PC at the goods-in desk.

The software house has since closed. The Access half can be edited by anyone brave enough and the .NET half by nobody, because nobody has its source. The branch works from a printout, the valuation still slows the pick, and the server under both is running out of support.

The same stock system built between 2016 and 2022, usually by an agency or a freelancer as a web system in PHP or React, Angular or Node, or put together in Power Apps by an operations manager, with a scanner app for goods-in built in Ionic. From the office it is a stock screen in a browser, a suggested order the buyer can open from home, and handhelds at goods-in that book against the purchase order. Since 2023 a few distributors have had a stock screen started in an AI app builder, which counted stock at one location and stalled at the second.

The handhelds are where it gives way. The scanner app was built for one model of device and never republished, so the replacements bought last year will not install it, and goods-in is back on paper for half the week. The reorder calculation lives in the agency's code, and a change to it once doubled every suggested quantity for a morning, after which the buyer stopped asking for changes. The agency's attention went to larger accounts, and the servers have not had an update since launch. It went live a dozen years or more after the Access database, and it is stuck just as fast.

One buyer covering thousands of codes, and a stock figure the accountant will sign.

The suggested order is the reason the business has one buyer and not three. It does the arithmetic across every code every morning, so the buyer's day is spent on the exceptions: the supplier who is late again, the product that is suddenly moving, the carriage threshold that is nearly reached. Stock sits at the level the business decided, and the cash tied up in it is a known number rather than a guess.

Goods booked against an order mean a supplier invoice can be matched, and disputed when it is wrong. Transfers are recorded, so stock does not vanish between the warehouse and the branch. The pick list comes out in bin order, which is why a new picker is useful on the first morning. And when the year end comes, the valuation is the system's figure, and the auditor accepts it.

Two locations, two truths. The branch's stock figure lags the warehouse's by a transfer that was loaded but not yet booked, so the branch works from a printed list and phones to check. The stock-take finds the difference twice a year and nobody can say where it went.

The reorder levels are older than the buyer. They were set by the person who opened the branch in 2011, carried across unchanged when any newer system went in, and adjusted by hand since. The buyer overrides the suggested order from memory every morning, and when the buyer is on holiday it goes out as suggested and the wrong things arrive.

The reports take all morning. The valuation and the dead-stock report run on the same SQL Server 2016 that prints the pick lists, so when the valuation runs the pickers wait. SQL Server 2016 updates ended in July 2026, and the Windows Server 2016 under it ends in January 2027.

Nobody has the source for the goods-in program. The software house that wrote it closed, and the last install file is on the goods-in PC. A barcode scanner cannot be added because nothing in the program can be changed, and if that PC fails, goods-in stops with it.

A stock figure that is right at every location, and reports that never slow the pick.

Each of these grows out of something the system already does.

One stock figure everywhere. Goods-in, put-away, the pick and the transfer written to one record as they happen, from a scanner. The branch stops phoning, and the stock-take confirms the figure rather than discovering it.

Reorder levels from what sold. Levels recalculated from the sales history and the real lead times, with the buyer's overrides recorded as data. The suggested order is right when the buyer is away.

Reports off the picking server. The valuation and the dead-stock report as a dashboard against a reporting copy, in seconds, while the SSRS reports keep running until each has been replaced. Picking never waits for a report again.

Purchase orders that come back acknowledged. Orders sent electronically, acknowledgements read back in, and the late-supplier list live on a screen instead of monthly on paper.

Goods-in on a scanner. The goods-in screen on a handheld, booking against the order with the over-delivery rules intact. The goods-in PC stops being the one PC.

Stock-take without count sheets. Counted on the handheld, differences posted the same day, and a rolling count through the year in place of the twice-yearly shutdown.

The old screens are not switched off for any of this, whether they are Access and a .NET program or the agency's site. Each piece is added beside them, on the same stock records.

In supplier paperwork, questions the order history can answer, and slow movers nobody has time to find.

The buying decisions stay with the buyer. AI works on what the system already holds or receives:

Price lists and acknowledgements read in. Suppliers send price lists as PDFs or spreadsheets in their own layouts, and acknowledgements as emails with a changed delivery date halfway down. AI reads each one, matches the supplier's codes to the stock codes, and drafts the cost changes and the new dates against the open orders for the buyer to accept or correct. At 50 to 200 purchase orders a week, and a few minutes to read and re-date each acknowledgement, that is typically between a couple of hours and most of a day of the buyer's week.

Supplier questions answered from the orders. What did we last pay for this code, and which supplier has been late with it most this year? AI answers in a sentence from the purchase orders and goods-in bookings, and lists the orders it used for checking. Asked a few times a day, that is typically twenty minutes to half an hour of searching the buyer keeps.

Slow movers found before the valuation. The dead-stock report lists what has already stopped selling. AI reads the sales history across every code and location, picks out the codes whose demand is fading, and drafts a clear-out list naming the branch that could use each one. Across 5,000 to 20,000 codes that list typically runs to a few dozen lines, a quarter of an hour's review where the report took a morning with a highlighter.

Not worth doing: a chat interface for the pickers. A scanner with three buttons beats it on a cold warehouse floor, and nobody in gloves types a question.

The drafts land on open orders and live stock records, so they wait until the stock system can be changed without stopping the pick. The assessment shows where on this system they would repay first.

The first move takes the two dated risks out of the room.

1. Stabilise. The database on a version that is still supported, on a server that is still supported, a backup restored on purpose, the .NET program's source (or the agency's code) found or its behaviour documented screen by screen, and a test copy of the whole thing. This goes first because a goods-in program with no source is what stops the warehouse, and nothing should be built on a server that ends in January 2027.
2. Goods-in and transfers on a scanner. The goods-in screen on a handheld, writing to the same stock records the Access screens read. Small, live in weeks, and the end of the two truths.
3. Reorder levels from history. The calculation rebuilt from sales and lead times, the buyer's overrides kept as data, the Access suggested-order screen reading the result until the new one replaces it.
4. Reports off a reporting copy. The valuation as a dashboard, the SSRS reports retired one at a time as each has a replacement the accountant accepts.
5. Electronic purchase orders, picking on the scanner, the rolling stock-take. Each a stage, each priced on its own.
6. Retire Access and the .NET program, or the agency's site, when nothing still opens them. The supplier screen in Access is usually the last to go, because the buyer trusts it.

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 buyer, the goods-in desk and the database, finding where the levels and the rules live and how far the figures have drifted from the shelves, 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 the system is built on: Microsoft Access, .NET Framework, SQL Server and SSRS, and for the newer generation old PHP, React, Angular and Node and Ionic.