Connecting WMS and ERP Across Production, the Warehouse and Shipping

A pallet is born three times. The line produces it, the warehouse puts it in a location, and shipping ties it to an order. When each step has its own screen and its own count, the team spends the end of the day making the numbers match by hand. The job of the integration is that the pallet moves once, and every system sees that same movement.

In this article we explain how we connect WMS and ERP across production, the warehouse and shipping, why a scan-driven operator screen is part of the flow, and what keeps a record from disappearing when the transfer breaks.

Three records, one movement

On the enterprise side there are usually three records.

• The production record says the work order is closed, and how much was good or rejected.
• The warehouse record says which location and which case the goods are in.
• The ERP record is the official stock, order and financial movement.

All three describe the same event. The first software decision is which fact is born in which system. Work orders and customer accounts are born in ERP. Locations and pick sequences are born in the warehouse. Produced quantity closes on the line. The integration does not move those birthplaces. It carries each movement once, from the system that owns it to the others.

Our industrial device, line and WMS/ERP integration service designs that carry and the floor screen together.

The steps of the operation

A warehouse day is a few steps. Each step has a document and a scan.

1. Goods receipt. The incoming pallet or line is matched to the expected order. Over, short and damaged quantities are recorded separately.
2. Put-away. Accepted goods go to a location. Without a location scan, stock sits somewhere unspecified in the warehouse.
3. Picking. The order line, the location and the quantity are shown together. The picked quantity closes with a scan.
4. Shipping. The loaded unit is compared with the order. A unit that does not match raises a warning before it goes on the truck.
5. Returns. Goods that come back are recorded as a movement tied to the original shipment, not as a fresh receipt.

At one manufacturer, warehouse and shipping teams used several screens and manual checks to keep WMS and ERP data aligned. In our warehouse and shipping operations software we built scan-driven screens for goods receipt, picking and shipping, and connected those screens to WMS and ERP. Background services carry the transfer with a queue, retries and logging. The operation runs through a single flow.

Identity: barcodes, cases and pallets

A scan only means something when the unit's identity is already defined. The GS1 SSCC identifies a logistic unit put together for storage or transport: a case, a pallet or a parcel. When the barcode is read, the physical unit is matched to the electronic record of its contents.

In pharmaceuticals the identity goes one step further. If the pack, case and pallet relationship was built in aggregation, scanning the pallet at shipping also checks the serials inside. We describe that relationship in our aggregation article. For material tracked by weight, the identity is the weighing record. How the measurement is bound to the work order is in our scale integration article.

We do not invent the identity scheme. The site's standard, and the smallest unit the job requires, decide it. In general manufacturing, batch and quantity are enough. For a serialized product, the record goes down to that level.

Two directions, and timing

What comes down from ERP is the order, the material, the customer and the work order. What goes back is the receipt, the consumption, the shipment and the return. If both sides write the same field, the result is a duplicate. Every field has an owner. The owner updates it, and the other side reads it.

Timing is a rule as well. Production is not posted to stock before the line closes. A shipment does not become an invoice before the loading check is finished. How the e-document is produced once shipping closes is in our e-invoice and e-waybill article. The warehouse screen should not show a loading as complete when its document does not exist yet.

When the transfer breaks

The floor cannot wait, and the service must not drop the record. The transfer layer does three jobs together:

• A queue. The screen completes the movement locally. The trip to the enterprise system waits its turn.
• Retry, once only. After a timeout the same movement is tried again and does not open a second stock movement. Every operation is tracked with a key.
• A visible error. A rejected line lands on the operator's screen with the reason. An error that lives only in a log becomes a surprise on shipping day.

This layer is the warehouse form of our API and integration work. It is designed as the promise behind the operator screen, not as a separate project.

The screen on the floor

A warehouse screen is not a desktop report. It has to be simple enough for someone standing up, with a scanner in one hand. Large targets, one job, a line that closes when it is scanned. The error text should be a sentence, not a code.

The same flow can run at a fixed station or on a handheld terminal. If the aisle has no network, the screen says so and does not pretend ERP was updated. The movement waits locally and joins the queue when the link returns. The terminal application itself is part of our mobile applications service.

How a project proceeds

The first job is to walk one pallet. From production close to the location, from the location to the pick, and from the pick to the truck, we map which screen, which piece of paper and which manual check is in play. The missing link is often a single one: receipt is still typed, or the shipping check is still a second list. We keep the scope to that link, try it for a shift, then widen it.

When the shift closes

Whether the integration is doing its job shows up as the shift closes. Three quantities should sit side by side: what the line closed, what the warehouse received, and what ERP posted to stock. If they match, the shift closes. If they differ, the line stays open with the reason.

The cause is often outside the transfer itself: a rejected pack posted to stock, a weighing outside tolerance, or a return still tied to an open shipment. The screen separates those sources, so the team does not open a second list to force the numbers to agree. The difference is still there the next morning. Who reconciled which line, and when, stays on the record.

Where a receipt line is tracked by weight, the quantity comes from the weighing record. When shipping closes, that same line is the quantity the e-document uses.

Choosing the technology

WMS/ERP integration is not tied to one programming language. What matters is that a movement is written once, that an error is visible, and that the floor screen keeps up with the work. Your existing WMS and ERP stay in place. We choose the technology to fit your infrastructure and the team that will keep it running.

Frequently Asked Questions

Do you need to replace our WMS or ERP?

Usually, no. We complete the link between the systems you already have, and the operator screen on the floor.

What if the two systems show different quantities for the same stock?

Every fact has an owner. The owner writes it, and the other side reads it. A difference appears on the screen at the moment of transfer, rather than piling up until the end of the day.

Can serialized pharmaceuticals use this flow?

Yes. The case and pallet relationship built in aggregation becomes the input for the shipping scan.

Is a handheld terminal required?

No. A scan-driven screen works at a fixed station or on a terminal. In an aisle without a network, the movement waits locally.

Facing a similar challenge? Tell us about your project and we'll get back to you within one business day.