Warehouse management system: the warehouse that never lies

One ledger, every movement witnessed

DockingWare does not keep a balance as a fact. It keeps movements: a receive is a row, an allocation is a row, a pick, a pack, a shipment, a return, a damage write-off and a cycle-count adjustment are rows, each with a type, a bucket, a quantity, a reference, a user and a time. Every number on every screen is computed from those rows. If a number is wrong, the row that made it wrong is there to be found, with a name on it.

There is no quantity field to type over. Corrections go through a count with a reason, and the correction is itself a row.

Where the stock is, not just how much

Stock lives in buckets: pick face, bulk, allocated, received on dock, damaged, quarantined, on order, in transit. Each one is shown as its own chip. Available to promise is pick face plus bulk minus what earlier orders already own, computed once on the server; the dock, damaged and quarantined stock are never in it. Every screen reads the same fields. No client re-derives a number by subtraction.

The channel is told the truth, on time

Available to promise is published to each connected channel after every movement that changes it, not on a timer. A reconciliation pass compares what the channel holds against what the warehouse computed and names the difference. Each product can hold back a quantity or a percentage for wholesale; the more conservative result is what the channel sees.

The floor runs on scans that must match

Handheld and desktop station console write the same rows through the same services. Receive against a purchase order, put away to a location, pick to a tote, verify each line at the bench before the box can close, buy the label without leaving the screen. A scan that does not match exactly is refused by name; a prefix never verifies. Lookalikes cannot ship by accident.

Products that survive the floor

A lifecycle that means something: drafts cannot be sold, discontinued products sell down and refuse replenishment. Alternate barcodes let a product answer to a marketplace sticker or a vendor label while the ledger names the real SKU. Case conversions per product, piece-exact allocation. Lots and expiry with first-expired-first-out where you need it. Kits as catalog entities whose components are what the ledger tracks.

Counting is routine, not a shutdown

A few locations a day. Variance lines that cannot be approved without a reason. Approval writes an adjustment row that names the count. A nightly job replays every movement row and compares the result with the stored balance; if they ever disagree, the ledger is right and the run says so.

Who this is for

Brands selling through a store and a marketplace from one building. 3PLs running several clients on one platform with strict separation. Operations teams who have stopped trusting their own number and want a system that can show its work.

It is not for a team that wants a system that splits one order across several warehouses.

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. The buyer’s guide and its checklist tell you how to test any of it on a trial, ours or anyone’s.