Shipment verification: what a portal should be asked to confirm

01 / FIELD NOTE

Keep the decision tied to the operating context.

A portal at a receiving door does one thing: it reports which tags passed through it. Everything a warehouse wants from that — a verified receipt, a discrepancy alert, a released payment — is a conclusion drawn on top of it, and the drawing is where projects succeed or fail.

The comparison itself is simple to state. The system holds an expected set, usually from an advance shipment notice or a purchase order, and the portal produces an observed set. Matching the two gives three outcomes: expected and observed, expected and not observed, and observed but not expected. A receipt is the first of those, and the value of the whole exercise is in how the other two are handled.

Expected and not observed is the outcome that stops a receipt, and it is worth being precise about what it means. It does not mean the goods are missing. It means the tag was not read at the portal, which has several possible causes: the item is genuinely absent, it is in the vehicle but shielded, its tag is damaged or unreadable, or the read zone did not cover the part of the load where it travelled. Each of those has a different remedy, and only one of them is a claim about the supplier.

Observed but not expected is the outcome teams handle worst, because the natural response is to accept it. Goods that arrived and were not on the notice are physically present, so rejecting them creates a problem in the yard while accepting them creates a problem in the record. What the design has to provide is a disposition path — receive against a known exception, hold pending confirmation, or record as an over-shipment — so that the operator has a correct action rather than a choice between two wrong ones.

Read reliability is the constraint everything else rests on, and it is a property of the installation rather than the tags. A portal reads a load as it passes, so a tag on the far side of a pallet may be shielded by the pallet itself, a tag facing away from the antenna may be marginal, and a load that pauses in the zone will be read many times while one that moves quickly may be read once. Measuring the read rate against a known load at commissioning is what converts any of this from a surprise into a documented limitation.

That measurement is what makes the discrepancy categories usable. If the portal is known to read a full pallet at a stated rate, then a single missing tag is worth investigating and a systematic gap at one position in the load is a coverage problem. Without the measurement, both look identical, and the team learns to discount the exceptions rather than act on them.

Duplicate reads are the mechanism’s normal behaviour rather than a fault. A tag in the field reports continuously, so a load that takes ten seconds to pass produces many observations of the same identity. Deciding when a tag has left the zone, and how long it must be absent before a second pass counts as a second movement, is what turns a stream of observations into one event per crossing.

What the portal is asked to confirm should follow from what the receiving process can act on. Confirming that the right pallets arrived is a coarse claim that supports a dock decision. Confirming that the right cartons arrived within those pallets supports a put-away decision. Confirming individual units supports a receipt at unit level, which is the only level at which a later shortage can be attributed to this delivery rather than to anything that happened afterwards. The tag level chosen decides which of these is available, and it is settled before the labels are applied.

Verification at dispatch is the mirror image and carries a different risk. Goods recorded as departed while still staged near the door are removed from available stock and counted as fulfilled, which converts a physical problem into a buyer-facing one. Reading at the control point rather than in the vicinity is what separates a genuine departure from a read of something that has not left yet.

Where the portal sits relative to the paperwork matters as much as the read. A portal that fires before the vehicle is checked in produces events with no document to attach to; one that fires after the load is broken down produces a receipt that cannot stop a dispute. The sequence of gate passage, document match and put-away should be designed as one flow, with each step’s exceptions visible to the person who can resolve them.

The integration question is where a portal stops being a device and becomes part of the operation. Something has to decide that a crossing is a receipt, attach it to a document, and post it. Whether that decision is made at the reader, in a middleware layer, or in the warehouse system determines how much can be changed later without redeploying hardware, and a project that leaves the decision in the device tends to find it hard to revise.

The honest scope is that a portal confirms presence at a point in time, and nothing more. It does not prove the contents of a sealed container, it does not verify condition, and it cannot distinguish a missing tag from a missing item. A receiving process built on it still needs a defined path for what to do when the answer is not a clean match — and the quality of that path, more than the read rate, decides whether the record stays trustworthy.