Receiving Sessions: Schrödinger’s Pallet Is Not a Storage Strategy
Why receiving is a session with a beginning, an end, and a signed handoff — instead of a vibe.
Receiving needs to stay predictable from the first scan. A truck arrives, the manifest says one thing, the driver says another, and somebody may scan the wrong barcode for the first hour. The session model keeps that work answerable: what arrived, who scanned it, which discrepancies were found, and when the handoff became inventory.
In ReVend OS, receiving is a session — a real entity in the database with its own ID (RECEIV-NNNNN), a start, an end, and a signed handoff that says "these assets are now inventory, stop asking." It's not a vibe. It's a row.
What a session contains
Each session is anchored to an inbound order, the operator on duty, the dock or station they're working at, and the time it opened. Every asset scanned during the session is linked to that session row, so you can later answer "what came in on Tuesday afternoon at AMS-Dock-2?" without grepping through emails. The QuickGrid intake component is built for keyboard-only operation: Tab between cells, Enter to commit a row, Alt+↓ to pick from the brand suggestions. The grid was rebuilt to fit on a tablet without horizontal scrolling, so the dock doesn’t need a desktop monitor on a forklift.
Bulk receive
For loads where scanning one asset at a time is the wrong pace, the inbound-detail manifest tab now has a bulk-receive flow: paste or upload a serial list, the platform reconciles it against the manifest in one round, and creates the asset rows in one transaction. Discrepancies surface in the same view as the per-asset scanner — same reconciliation logic, different ergonomics. Useful when 200 identical Latitudes show up on one pallet and the per-asset scan rhythm becomes a bottleneck.
The handoff
Closing a session is a deliberate act. The operator marks the count, the discrepancies, and any condition exceptions. The system writes a signed handoff record — RLS-protected, tamper-evident, append-only — and the assets transition from "received" to "inventory." A separate role (warehouse manager) can sign off on discrepancies that exceed a threshold, so the operator can't paper over a missing pallet by themselves.
Why the entity exists
Because "the inbound order is also the receiving record" was wrong. An inbound order is a contractual claim about what's coming. A receiving session is a physical record of what showed up. Conflating them meant you couldn’t reopen receiving without reopening the order — and you couldn’t close the order until receiving was done — which created the kind of state-machine deadlock that ends in somebody emailing a CSV. Two entities. One handoff. Predictable Wednesday.