Connecting ERP, WMS and Warehouse Equipment

When an automated warehouse stops, the cause is often not a motor or a sensor. It is a message that arrived twice, arrived late or never arrived, and two systems that now disagree about where a pallet is.

This article is about designing the connections between enterprise resource planning (ERP), the warehouse management system (WMS), the warehouse control system (WCS) and the programmable logic controllers (PLCs) that run the equipment. If you need an introduction to what each layer does, start with WMS, WCS and WES.

Decide responsibilities before choosing technology

Every interface carries a decision from one system to another. Before anyone discusses formats, write down which system makes each decision and which systems only receive the result. A typical split gives the ERP responsibility for commercial orders and financial inventory, the WMS responsibility for locations, tasks and operational stock, and the WCS responsibility for routing and equipment state. Your split may differ. What matters is that it is written, agreed and has no gaps.

Source of truth

For each data set, name a single owner:

• Item master: descriptions, units of measure, dimensions, weights and handling attributes. Automation depends on accurate dimensions; decide who maintains them and how changes reach the equipment.
• Inventory: the ERP often holds the financial view and the WMS the operational view by location. Agree which is authoritative for what, and how differences are resolved.
• Orders: who can change or cancel an order once it has been released to the warehouse, and up to which point.
• Locations: whether automated storage positions are visible to the WMS individually or managed inside the WCS as a black box.

Events, commands and acknowledgements

Most traffic falls into two kinds. Events report something that happened: goods received, a pick confirmed, stock adjusted. Commands ask another system to do something: move this tote, release this wave. A command needs an acknowledgement that it was accepted and, later, a separate confirmation that it was completed or failed.

Keep accepted and completed distinct. A WCS that has accepted a task has not moved anything yet. If the WMS treats acceptance as completion, inventory will be wrong whenever a task fails on the way.

The transport itself can vary. Application programming interfaces (APIs), file transfers, message queues and middleware are all used. Electronic data interchange (EDI), commonly based on the ANSI X12 or UN/EDIFACT standards, is still widespread between businesses, for example between a warehouse and its customers. The design questions below apply whichever you use.

Duplicates, ordering and idempotency

Assume every message may be delivered more than once, and that messages may arrive out of order. Retries after a timeout are a normal cause: the sender cannot tell whether the first attempt was processed, so it sends again.

The defense is to make processing idempotent: handling the same message twice has the same effect as handling it once. In practice that means every message carries a unique identifier, and the receiver records which identifiers it has already applied. A repeated pick confirmation is then recognized and ignored instead of decrementing stock a second time.

For ordering, include a sequence number or timestamp per object, so a receiver can tell that a cancellation was issued after the release it refers to, even if it arrived first. Decide what the receiver does with a message that refers to something it has not yet seen: hold it, reject it or raise an alert.

Reconciliation between systems

Even well-designed interfaces drift. Plan a regular reconciliation that compares what each system believes: inventory by location between WMS and WCS, open orders between ERP and WMS, open tasks between WMS and WCS. Define the tolerance, the report and the person who resolves each kind of difference. A difference found the same day is usually easy to explain; one found at a stock count weeks later often is not.

When an interface fails

Interfaces fail in a small number of ways: the network drops, one system is down for maintenance or a fault, or a queue stops moving because one malformed message blocks everything behind it. Each needs a designed response.

• Store-and-forward. The sender buffers messages locally and delivers them in order when the link returns. Decide how long the buffer can hold and what happens when it fills.
• Local autonomy. Equipment controls can often keep running work already released to them for a period without the WMS. Define how much work is buffered at each layer and how the system catches up.
• Poison messages. A message that cannot be processed should be moved aside to an error queue with an alert, not retried forever at the head of the line.
• Manual fallback. Agree which processes can continue on paper or handheld devices, and how those transactions are entered afterward without duplication.

Recovery: who does what

Write the recovery runbook before go-live. It should say who is called for each failure type, who decides to switch to fallback, who restarts which interface, and who signs off that systems are reconciled before normal running resumes. In a site with an ERP team, a WMS supplier, an equipment supplier and an operations team, an incident without named roles tends to become a discussion about whose fault it is.

Monitoring and alerting

Monitor the interfaces as part of the operation, not only as IT infrastructure. Useful signals include queue depth and age of the oldest message, error-queue counts, time since the last message on each interface, and tasks that have been accepted but not completed within an expected time. Route alerts to someone who can act on them during the shift, and keep a history so recurring faults are visible.

Interface specifications and testing

An interface specification should define every message, its fields and formats, mandatory and optional data, identifiers, expected acknowledgements, timeouts, retry behavior and error codes. It should also describe the failure behavior above, because that is where suppliers' assumptions most often differ.

Test in stages: each message in isolation, then end-to-end flows, then failure cases deliberately induced. Disconnect the network, restart the WMS mid-wave, send duplicates and out-of-order messages, and fill a queue. Run volume tests at the peak rates the business case depends on. The delivery approach for any software project should allow time for this.

Security at the OT/IT boundary

Integration connects information technology (IT), such as ERP and WMS, with operational technology (OT), such as PLCs and equipment networks. That boundary needs deliberate design.

• Segmentation. Keep equipment networks separate from office networks, with controlled and documented paths between them.
• Least privilege. Give each system account and user only the access its function requires. An interface that sends tasks should not have rights to change PLC programs.
• Remote access. Control and log supplier remote access, and enable it only when needed.
• Patching and change. Agree how security updates are tested and applied without disrupting operations.

The ISA/IEC 62443 series is the family of standards for the security of industrial automation and control systems, and its approach of grouping assets into zones connected by controlled conduits is a useful reference when designing this boundary with your IT security team.

Change management over the life of the site

Interfaces outlive the project that built them. ERP upgrades, a new WMS release, an added sorter or a new customer's data requirements will all touch them. Keep the specification under version control, record which version each system runs, and require that any change is tested against both sides before release. Treat a change to a message format with the same care as a change to the equipment.

Integration design is a central part of software integration work, and it is easier to get right during warehouse automation planning than after the equipment is installed.