In a plant warehouse the hard part is almost never capturing the event. A forklift puts a pallet of axle assemblies away at 06:12 and a scanner records it perfectly. The difficulty is what you are allowed to do with that fact, because the ERP may not yet have a document to attach it to. Most integrations handle that in one of two bad ways: they hold the whole transaction and lose the observation, or they invent a reference so the flow completes. The first wastes evidence you already had. The second puts a number into a system of record that nobody can trace. There is a third option, and it is the one this page is about: capture the observation, mark it blocked, name what is missing, and release it the moment the number exists. Ask for the deployment brief.
The Pallet Moved Before the Paperwork Existed
Receipt and put-away events, line feed replenishment, the transfer that files to two documents, and what to do with an observation that has nowhere to go yet.
Three Outcomes, and Only One Is an Error
Most integration designs have a success path and an error queue. That is one state too few, and the missing one is where warehouse integrations actually live.
A failure is a transport problem and should fix itself by retrying on a widening schedule. A hold is a confidence problem and needs a person, because the reading itself cannot be trusted. Blocked is neither: the observation is sound and the destination is not ready. Supply the document number and it goes. Collapsing all three into a single error bucket produces a queue mixing things that will fix themselves with things that never will, which is how a queue becomes something nobody reads.
The blocked state is also the honest one. It says plainly that put-away and returns wait on an ERP document number rather than pretending the dependency is not there. An integration that never shows you a blocked item is either genuinely never blocked, which is unlikely in a plant, or it is filling in the reference itself.
What Each Warehouse Event Actually Files As
Facts should be filed as the document type they genuinely are, not as whatever the integration found convenient. Swipe the table sideways on mobile.
| Event | What happens on the floor | What it files as |
|---|---|---|
| Receipt | A trailer of chassis rails arrives and is checked in | Files as a transport document. Quantity, time and condition, with evidence attached. Needs no ERP reference to be captured. |
| Put-away | The pallet is moved to its location | Files as a stock movement. This is the step that most often has nowhere to go yet, because the receiving document may not exist until later. |
| Line feed replenishment | A kanban pull brings seat modules to the station | Files as a stock movement between locations inside the plant. High frequency, low value individually, and the one most often left entirely unrecorded. |
| Returns and repack | A damaged wheel set comes back from the line | Files as a stock movement, and usually also raises a quality record against the part and the supplier. |
| Stock transfer | Material moves between sites | Two documents, deliberately. A goods issue where it left and a stock movement where it arrived. |
Line feed replenishment is the row worth lingering on. Individually each pull is trivial — a rack of seat modules moved thirty metres. Collectively it is the highest-frequency stock movement in the building and the one most commonly left out of the system entirely, which means the plant's own internal consumption is invisible precisely where the line is most sensitive to it.
How many put-aways are waiting on a document number right now?
On most sites nobody can answer, because blocked and failed went into the same queue and the queue stopped being read some time ago. In thirty minutes we will separate the two against your own dock and show what is actually waiting rather than broken.
The Transfer That Files Twice
One physical move, two documents, and getting this wrong is the clearest possible signal about a vendor's experience.
A rack of wheel sets leaving a consolidation site and arriving at the truck plant is not one posting. It is a goods issue where the stock left and a stock movement where it arrived, because the two ends are different facts happening at different times with a transit period between them. Filing both against a single record keeps the aggregate correct while leaving both sites wrong, and it is the giveaway that a vendor has never actually run one of these.
The transit period is the reason. Between the issue and the receipt the material genuinely exists in neither place and in both, depending on what you are asking. A single record forces you to choose a moment, and whichever one you choose makes the other site's balance wrong for the duration.
Who Owns Which Number
The architecture question underneath all of this, and the one that decides whether you end up with reconciliation or with a second argument.
The running stock figure stays where the business plans and bills from. An observation layer that tries to become the balance of record creates a second number, and a second number is a reconciliation problem rather than a solution.
Where a pallet physically is, which bay, which rack, which line-side rack. That is the WMS's job and it is better at it than anything else in the building.
That a thing moved, when, in what quantity, with evidence. It is the record of what happened rather than the record of what is — and those are different kinds of fact.
The temptation with any observation layer is to let it become the balance, because it has the freshest data. Resisting that is what keeps it useful. The moment two systems both claim to hold the running stock figure, the organisation has to decide which one is right every time they differ — and it will differ, because they are measuring at different moments.
Reconciliation Cadence
Five rhythms rather than one, because the parts feeding a truck line do not all deserve the same attention.
Capture the movement as it happens rather than at shift end. A record written four hours later is a recollection.
Work the blocked queue before it ages. A blocked put-away from this morning is a phone call; one from last Tuesday is an investigation.
The parts feeding the line every day are where error compounds fastest and where a count is cheapest to perform.
Axle assemblies and powertrain modules justify individual attention in a way fasteners never will.
The two documents give you two chances to notice a discrepancy, and the difference should be visible as the counter types rather than after submission.
The target is worth stating because it is higher than people expect. MRP and ERP systems require inventory record accuracy in the range of 95% to 99% to function properly — below that the planning output degrades, safety stock rises to compensate, and people start working from what they can see on the rack rather than from the system. That last behaviour is the real cost, because once the floor stops trusting the record it stops feeding it.
Why This Matters More on a Vehicle Line
A general warehouse can absorb a bad record. A line feeding chassis cannot, and the reason is structural rather than cultural.
Vehicle assembly consumes in fixed combinations against a known build. A missing fastener is an irritation; a missing axle assembly against a specific chassis is a stopped station, because there is no substitute and no buffer to draw from. The parts most likely to be wrong in the record are also the ones moving most often, since every line feed pull is a stock movement and most plants record a fraction of them.
It also compounds downstream. A part consumed but never recorded leaves inventory that exists on paper and not on the rack, which is discovered at the worst possible moment by somebody who needed it. The same discipline that keeps a maintenance record trustworthy applies here: an event is recorded when it happens, by whoever saw it, with evidence, or it is a recollection written down later.
How FleetRabbit Handles This
Four things, all of them about keeping an observation usable when the paperwork is not ready for it.
An observation with no ERP document to attach to is captured, marked blocked with the reason named, and released the moment the number exists. It is never discarded and never guessed.
Goods issue where it left, stock movement where it arrived, as two records for one physical move — which is what keeps both sites correct rather than only the total.
On a transfer receipt, the variance appears as the counter types rather than after the posting, so a miscount is a correction rather than an adjustment.
Oneflow does not try to own the running stock figure. It records what moved, with evidence, and files it into the system that does.
Questions Plant Teams Ask
What happens when there is no ERP document to post against?
The observation is captured and marked blocked, with the reason named. It is not discarded and no reference is invented for it. Supply the document number and it posts. That state exists specifically so a real dependency does not become a lost event. See the Blocked State.
Why separate blocked from failed?
Because they need opposite responses. A failure is a transport problem that fixes itself on retry. A blocked item needs somebody to supply something. Mixed into one queue, the self-healing items bury the ones that need a human and the queue stops being read. Separate the queues.
Why does a stock transfer need two documents?
Because the two ends are different facts at different times with transit between them — a goods issue where the stock left and a stock movement where it arrived. A single record forces you to pick one moment, which leaves the other site's balance wrong until it catches up. Check your transfer handling.
Should the observation layer hold the stock balance?
No. The running balance stays with the ERP, where the business plans and bills from. Two systems both claiming the balance means somebody has to adjudicate every difference, and they will differ because they measure at different moments. Check Who Owns the Balance.
What accuracy do we actually need?
MRP and ERP systems need inventory record accuracy around 95% to 99% to function well. Below that, planning degrades, safety stock climbs to compensate, and the floor starts working from what it can see rather than from the record. Review Your Reconciliation Cadence.
Which events get missed most often?
Line feed replenishment, by a wide margin. Each pull is individually trivial and collectively it is the highest-frequency movement in the plant, so leaving it out makes internal consumption invisible exactly where the line is most sensitive. Capture the pulls.
When should a variance be visible?
While the count is being entered, not after it is submitted. A difference shown as the counter types is a correction made by the person who is standing there; the same difference found later is an adjustment made by somebody who was not. Show it at entry.
Can we start on one dock rather than the whole site?
That is the sensible way in. One dock gives you the receipt, put-away and blocked behaviour against real traffic without touching the balance of record, and the write-back stays off until you have read what it would have sent. Try It on One Dock.
Capture the Event Whether or Not the Document Exists
Oneflow records receipt, put-away, line feed and returns as they happen, files each as the document type it actually is, holds what cannot post yet as blocked with the reason named, and leaves the running balance where it belongs.
