Dead stock in the warehouse, and the count that disagrees: where they hide in your program

What dead stock is

Dead stock is the items that have not sold for a whole year. Paid for, put on a shelf, and nobody asked for them; the money is still there, as cartons. The owner says they are “asleep”; when he types, it is dead stock; the accountant calls them the non-moving items in the warehouse. Three names, one shelf.

A year is our threshold: an item that has not moved in twelve months is not slow, it is dead. Not every dead item is a mistake — some are spare parts that have to stay. And you only know which is which from the full list, by name and quantity.

Where they hide in your program

Your program keeps, for every item, the date of its last sale and the quantity remaining. Those two are enough to tell the dead from the rest, and a dead-stock report rests on nothing else; but they sit on screens nobody opens. The Reading, two pages from your exports, reads those two for every item and writes down the total. In its example — a Damascus distributor — 820 of 2,829 items had been asleep all year: 29% of the book.

Your own figure is the one that matters, and the Reading runs the same count on your book: how many items, which ones, since when. The dead stock has been in your program since the day it stopped selling; all it lacks is a reader.

Suddenly you can see.

The Reading: two pages from your exports

The Reading starts with three files you export from your program, after a signed undertaking from us reaches you. From them come two pages with three to five findings, each a number and a name: this item, this quantity, since this date. They are handed over on paper, at your desk.

Dead stock is the Reading’s first finding: the easiest to prove, because the shelf is there and you can stand in front of it. On this site the names are removed and the figures rounded; at your desk you see them as they are.

Why the physical count does not match the program

The shortage that shows up in the warehouse on count day is no mystery: the program knows only what was typed into it. The differences build all year, then appear at once in the annual warehouse count: a shortage here, a surplus there, and adjustments the accountant enters until the book matches the shelf again. The physical count does not match the program? The surprise is not the difference; it is that this is the first time it has been seen.

No fault in the program, none in the warehouse; these are small movements between two invoices that never reached a screen:

• A pull nobody recorded.
• A return put back on the shelf and never entered.
• Damaged goods taken off the shelf and never recorded.

Count day in the warehouse, from the phone

The System is a layer over your program: it puts the program’s quantities on every phone and refreshes them every hour. On count day, whoever counts stands at the shelf with the phone in hand: what he sees and what the book says, aisle by aisle. The difference is seen on the spot, not a month later in an Excel file.

Counting stays with whoever counts; MIDDLEWARE sells no counting app, and the adjustment stays the accountant’s entry. If you want a pull recorded the moment it happens, that is the Exception: built for your company alone, over the program you already run, never sold off a shelf.

The accountant gets a login that reads and never writes: he tries an edit, it is refused. He deletes it whenever he likes.