WMS and ERP integration: how an RFID event becomes a business transaction

01 / FIELD NOTE

Keep the decision tied to the operating context.

A warehouse management system and an enterprise resource planning system hold different truths. The warehouse system knows where things are and what has physically happened. The planning system knows what was ordered, what was promised and what it cost. Neither is a copy of the other, and the interface between them is where an RFID project either delivers a benefit or produces a second set of numbers to reconcile.

The common mistake is to treat the interface as a data feed, in which the warehouse system reports its inventory position and the planning system consumes it. Position is a summary that changes constantly and means different things at different moments: stock on hand, stock available, stock committed, stock in transit. A feed of positions leaves the receiving system to infer what changed between them, which is exactly the inference the sender was in a position to state.

What should cross the boundary is events. Goods were received against a document; goods were put away to a location; goods were picked for an order; goods left the building. Each is a discrete, dated fact with a reference to the document it belongs to. The receiving system applies it to whatever it holds, and because the event carries its own context, the two systems do not have to agree on a snapshot at any instant.

This is also where capture fits. A reader produces observations, not events, and the translation happens in a layer that decides which observations are eligible to become a business step. Receiving a tag at a dock portal is a receipt; the same tag passing the same portal an hour later because a pallet was moved is not. The rule that distinguishes them belongs in the middleware rather than in either system, because both systems would get it wrong for different reasons.

Sequence matters when events cross a boundary, and it is easy to get wrong in a way that only shows under load. If a dispatch event reaches the planning system before the pick that produced it, the planning system records a shipment of goods it does not yet believe were assembled. Nothing breaks immediately — the error is invisible until someone reconciles a period — which is why ordering guarantees are worth stating explicitly rather than assuming the transport preserves them.

The failure that hurts most is a partial write. An event that updates the warehouse system but not the planning system leaves two records that disagree by one movement, and because both look internally consistent, the disagreement is found by a person rather than by the system. Recording enough about an event to retry it, and being able to say which events have been applied, is what allows the interface to recover without manual reconstruction.

The identifier is the part that has to be agreed in advance. A tag carries a standard identity, and that identity has to mean the same thing to both systems: this unit, this carton, this pallet, this batch. Where the two systems model different units — one thinking in pallets and the other in cases — the interface has to state the conversion rather than leave each side to infer it, because an inference that holds in normal operation is exactly the one that fails at the edge.

Where goods are committed rather than merely held is a distinction the planning system owns and the warehouse system should not attempt to reproduce. A unit promised to a buyer, a unit reserved for a production run and a unit physically present but unavailable because it failed inspection are all present in the same location and are commercially different. Keeping the commitment in the planning system and the location in the warehouse system avoids two definitions of available drifting apart.

The reconciliation path is what makes the interface survivable. Whatever the design, events will be lost, applied twice, or arrive for documents the receiving system has not seen. Having a defined way to ask what the other system believes about a specific document or unit — and a person whose job it is to act on the answer — is worth more than attempting to make the interface infallible.

Standards do most of the work in the physical layer, which is what allows the software layer to be simpler than it otherwise would be. A standard air interface and a standard product identity mean a label applied by a supplier can be read by a receiver without the two having agreed anything beyond the standard, and the identity that arrives is the identity the planning system already knows from the purchase order.

Cost and effort belong in the comparison as recurring figures rather than one-off ones. Whatever the mechanism between the systems, someone in the business has to understand the flow, notice when it stops and know who to call. Where that responsibility rests on one person who is also running the warehouse, the interface is one absence away from failing quietly, and the failure will present as an inventory discrepancy rather than as an integration fault.

The test of a working interface is whether a question can be answered without a phone call. If establishing what happened to a consignment requires asking the goods-in supervisor, the two systems have not been connected in any sense that matters, however many tags are in use. The aim is a record that answers across the boundary — and that comes from agreeing which events cross it, not from how much data is pushed across.