Receiving Sessions: Schrödinger’s Pallet Is Not a Storage Strategy
Why receiving is a session with a number, a beginning and an end — 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 manifest lines are still open, and when the work stopped.
In ReVend OS, receiving is a session — a real entity in the database with its own number (RECEIV-2026-00042, handed out per tenant per year by the same counter that numbers your orders), a start, an end, and a status. It’s not a vibe. It’s a row.
What a session contains
Each session belongs to an inbound order and records who opened it, when it opened, when it closed, its status — open, paused or closed — its notes, and the collection it came from where there is one. Every asset your operators create during the session is linked to that session row, so you can later answer “what came in on Tuesday afternoon” without grepping through emails. While the session is not closed it can be linked to a pallet, so the assets scanned in that run land on the pallet they physically sit on.
Assets are created as assets, straight away. There is no “received item” limbo that somebody has to promote to inventory later; the moment a row is committed in the session it exists in the live asset register with its session and its inbound order attached.
Scanning, grid, bulk
The QuickGrid intake is built for keyboard-only operation: Tab between cells, Enter to commit a row, Alt+↓ to pick from the brand suggestions. It fits on a tablet without horizontal scrolling, so the dock doesn’t need a desktop monitor on a forklift. The mobile receiving screens show who is logged in and for which organization, with sign-out one tap away — a shared scanner is only as trustworthy as the account holding it.
For loads where scanning one asset at a time is the wrong pace, the manifest tab on the inbound order offers bulk receive: select the pending manifest lines, give them one condition, and the platform creates the received assets for those lines in one go. Serial lists come in through the Excel or CSV manifest import; bulk receive then turns claim into stock. Useful when 200 identical Latitudes show up on one pallet.
No order? Start anyway
A truck that turns up without a prepared inbound order is still a truck. Standalone receiving opens a session and creates a shell inbound order to hang it on, so the assets have a parent from the first scan and the paperwork catches up with the pallets.
Pause, close, and the stuck case
Sessions can be paused and resumed — the shift ends, the session doesn’t have to. Closing is a status change to closed, written to Activity with who did it; several sessions can close against one inbound order when a shipment arrives in two trucks. Session assets can be sent to testing straight from the session page. A session stuck in a state that no longer matches reality gets a force-finalize path — for when the operational truth is clear and the status is what needs correcting.
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. The Receiving overview and the Pipeline use one shared rule for what counts as open receiving work — an order not fully received, or a session still open or paused — so a fully received order without an active session disappears from both screens at once. Two entities. One rule. Predictable Wednesday.