Four Things a Scan Does Not Decide

A scan answers one question: what is this? Everything else you might want at the moment of the beep — how many, who says so, which one, and whose it is — is a separate question that the barcode cannot answer and the system does not pretend to.

That sounds obvious written down. It is not obvious in a warehouse at seven in the morning, and it is not obvious in a demonstration, where a scan and a stock movement happen half a second apart and look like one act.

What the bridge actually is

A person at a desktop opens a session. A phone pairs to it with a token that has a fingerprint, a last-used time, a soft expiry and a hard expiry, and can be revoked. From then on the phone is a scanner for that session and the desktop is the screen.

Each scan is stored as an event, and the event is far richer than a barcode. It carries the code, when it was scanned, the device label and fingerprint, the address it came from, who the actor was, what the code resolved to and with what status, an exception code if it resolved to nothing, the action that was chosen afterwards, and when the event was consumed.

That is a genuinely auditable capture. A month later you can answer which device scanned what, when, under whose account, and what happened next — including the scans that failed to resolve, which are usually the interesting ones.

The scan is evidence of an identification. It is not evidence of a decision.

The four things it does not decide

1. How many

   A barcode identifies a product, not an amount. Our quantities are whole numbers with no unit of measure attached, so the person scanning still has to say whether that beep meant one bottle, one case of twelve or one pallet — and the system has no way to know which convention your catalogue uses. Covered in full in A Quantity That Cannot Have a Decimal Point.

2. Whether it is allowed

   Scanning is identification; approval is a separate act with its own permissions, its own value threshold and its own separation of duties. A scan cannot approve a write-off and should not be able to. Where this catches people out is in expectations: a scanned adjustment is not a fast-tracked one.

3. Which unit this is

   A product barcode is the same on every unit of that product. Individual identity would need a serial, and our stock serial register is a table with screens and no way to write to it — see A Register That Cannot Be Filled. So a scan tells you the model, never the specimen.

4. Whether it is yours

   Stock in this product has no ownership concept, so a scan cannot distinguish your goods from a supplier's consignment sitting on the same rack. The scan resolves to an item; the item is assumed to be yours.

Why this matters more in a scattered, high-turnover operation

Peruvian distribution — Lima out to the regions, mining and industrial supply into remote sites, retail across a geography with real logistical friction — has two characteristics that make the boundary important.

The first is that the person scanning is often the only person present. There is no supervisor at the receiving door of a remote site. The scan is the whole record of what arrived, which means everything the scan does not carry has to be carried by the process around it.

The second is staff turnover. A scanning workflow is learned in an hour, which is its great virtue, and the four boundaries above are learned by being told. Nobody discovers them from the interface, because the interface behaves identically whether the operator understands them or not.

The fourth row is the one nobody uses and everybody should. Unresolved scans are recorded with an exception code. A weekly look at them will find your missing barcodes, your duplicate labels and your untrained operators faster than any report designed for the purpose.

Frequently asked questions