Inventory flow from receiving to shipping: where the record is written

01 / FIELD NOTE

Keep the decision tied to the operating context.

An inventory record is a claim about where something is. Every operational decision downstream — what to promise, what to reorder, what to pick — is made against that claim rather than against the shelf. The purpose of tagging goods is not to know that a tag exists; it is to make the claim true at the moment it is read.

That framing changes what a system has to do. A reader detects a tag in its field. A warehouse system needs a movement: goods arrived against a document, goods were put away at a location, goods were picked for an order, goods left under a particular dispatch. Detection and movement are different things, and the gap between them is where most operational trouble lives.

Receiving is where the record is created, so it is where its quality is decided. Goods arrive against an expected document — a purchase order, an advance shipment notice, a transfer. The receiving process has to answer three questions: what is physically here, does it match what was expected, and where does it go. Bulk capture helps with the first, comparison with the document answers the second, and only then is the third worth deciding.

Tags are the physical layer. A label on an item, a hangtag on a garment, a tag on a carton or a pallet all make the same trade: finer granularity gives you item-level truth and costs more labels and more care in application, while coarser granularity is cheaper but can only ever tell you about the unit it was applied to. A pallet tag cannot report which carton is missing, because it was never asked about cartons.

The air interface is standardized, which is what makes a mixed equipment estate workable. Passive UHF systems implement the ISO/IEC 18000-63 protocol, also published as GS1 UHF Gen2, and the EPC carried in the tag gives each tagged entity a standards-based identity that readers, software and trading partners can agree on. That agreement is the reason a tag applied by a supplier can be read by a receiver.

Put-away is the step that converts receipt into a location. Goods that were received correctly and then placed somewhere the system does not know about are, for picking purposes, lost. Capturing the destination at the moment of placement — by reading a location label as well as the goods, or by confirming a guided placement — is what keeps the item-to-location relationship intact.

Internal movement is the quiet source of drift, because it looks like housekeeping rather than a transaction. A pallet moved to make room, stock shifted to a seasonal overflow area, goods staged near a dock for tomorrow: none of these are meant to change anything, and all of them do, unless the system is told. Every unrecorded move widens the gap between the record and the floor.

Counting is how that gap is measured. A count compares what the system believes against what the reader can find, and its useful output is not a single accuracy figure but a list of exceptions: expected and not found, found and not expected, found somewhere else, and found more than once. Those four categories point at different causes, and treating them as one number throws away the diagnosis.

Picking is where the record meets a promise. The order line says which item and how many; the shelf either holds it or does not. Verifying the picked items against the order before packing catches the error while it is still cheap to fix, and it catches a specific class of error that counting alone cannot: the wrong item picked from the right location.

Packing verification is the last point at which a correction is inexpensive. Reading the contents of a tote or carton against the order confirms that the right goods, in the right quantity, are in the right container — before the container is sealed and staged.

Shipping is the point where a record stops being an internal belief and becomes a commitment. Reading goods at the outbound control point confirms what actually left, under which dispatch. This is also the point where a false event does the most damage: marking goods as shipped when they are still staged near the door removes them from available stock and tells a buyer something is on its way when it is not.

Returns close the loop and are usually the least-designed part of it. A returned item has to be identified, its original movement found, and a decision recorded — back to sellable stock, to inspection, to repair, or to write-off. Without that step the item physically returns while the record does not, which produces a discrepancy that no count can resolve because the cause was never captured.

The common thread is that each of these steps needs one event at one defined point, and needs the system to be able to say no. A portal that reads the pallet staged near the door as well as the pallet crossing it has not improved the record; it has added noise to it. Designing where a read counts, and where it must not, is the part that decides whether the rest of the flow can be trusted.