Inventory discrepancies: when the rack and the system disagree

What it looks like on the floor

The system says twelve. The shelf holds nine. Somebody says “the system is always off on that one” and moves on. Next month the system says fifteen and the shelf holds nine again, because the missing three were never found, just tolerated.

Why it happens

Inventory records break in the gap between what happened and what was recorded. A pallet is moved and the move is not scanned. A picker grabs the neighbouring product because the two boxes look alike and the label was never checked. A return is put back on the shelf by whoever was nearest. A spreadsheet correction runs twice because two people were fixing the same number.

None of those events leave a trace in a system that stores a balance. The balance was overwritten, the previous value is gone, and the difference is just a number nobody can explain.

What DockingWare does

It does not store a balance. Every change to stock is a movement row: type, bucket, quantity, reference, user and time. The balance on every screen is computed from those rows. When the rack disagrees with the screen, the rows that made the screen say what it says are there to be read, and one of them will be the row that should not exist, or the row that is missing.

Scans are exact. A prefix never matches. A product answers to its own barcode and to any alternate code you have registered for it, a marketplace sticker or a vendor label, but the ledger always names the real SKU. On the desktop pack bench every line must be scanned before a box can close, so a lookalike cannot ship unnoticed.

Counting is part of the routine, not a yearly event. A cycle count records what was found; the difference against the record becomes a variance line, and that line cannot be approved without a reason code or a note. Approval writes an adjustment movement that names the count, so the correction is on the ledger with everything else.

The handheld and the desktop station write the same rows. There is one writer per movement type and it does not matter which screen the operator used.

What it does not do

It does not prevent a person from moving a box without scanning. No software does. What it guarantees is that the movements that were scanned are all on one record, that the count that finds the gap is on the same record, and that the correction carries a reason and a name.

What you can verify

Every rule above is enforced in code and covered by a test that fails first, then passes. The changelog names the version each one shipped in.