How Does Warehouse Automation Talk to Your WMS?

Every buyer asks the same early question: will it work with my WMS? It is a fair question and the wrong one. Almost any automation can be connected to almost any WMS. What decides the project is where the line sits between the two, meaning which system makes which decision.

Munro Footwear Group in Melbourne runs 205 Mushiny T-series robots against 5,239 shelf pods on its shelf-to-person system. The work on a site like that sits at the border between the inventory system and the robot fleet. This article explains the layers, why the position of that border matters more than the protocol across it, and what to ask a supplier before you sign.

One limit up front. This article describes the shape of the problem in general terms. It does not describe a specific Mushiny interface, message format or list of supported WMS products, because those belong in a conversation about your site. The questions at the end are the ones to put to us or to anyone else.

Is "will it work with my WMS" the right question?

No. The answer is nearly always yes, and it tells you almost nothing. The better question is who decides what. When an order arrives, someone has to decide which stock fills it, which pod or tote holds that stock, which robot fetches it, which station it goes to and in what order. If your WMS decides all of that, it has to know the inside of the automation. If the automation decides most of it, your WMS needs to know much less. That choice sets the size of the interface, the number of things that can break and how much each side can change without asking the other.

What does each layer own?

Most automated warehouses have three layers, even where suppliers draw the boxes differently.

The WMS owns inventory, orders, waves and your business rules. The WCS or WES layer owns what happens inside the automation: which robot, which pod, which station, in what order. Suppliers draw these boundaries differently, so treat the acronyms as job descriptions. The robots and machines execute.

Why does the position of the line decide the project?

There are two common shapes.

Shape one: the WMS keeps bin-level locations inside the automation. The WMS knows that an item sits in pod 212, shelf 3, and tells the automation which pod to bring. It feels natural, but now the WMS must know about pods. When the automation moves a pod or re-slots a fast mover, the WMS has to be told, and the two records must never disagree. The systems are tightly coupled. A layout change inside the grid becomes a WMS change, and a WMS upgrade becomes a risk to the automation.

Shape two: the automation owns storage internally. The WMS sees, in effect, "stock in the automation". It sends inbound quantities and order demand. The automation decides where stock lives, which pod comes and in what order, and reports back counts and confirmations. The interface is small, and either side can change without the other noticing.

The second shape is almost always better, for three reasons.

1. Fewer things can disagree. Every piece of state shared between two systems is a place for them to drift apart.
2. The automation can optimise freely. A goods-to-person system gets its rate partly from choosing which pod comes next. A WMS dictating pod-level instructions fights that logic.
3. Changes stay local. You can re-lay the grid or add pods without a WMS project, and you can replace your WMS later without rebuilding the automation interface.

This is a general principle, not a statement about any supplier's product. How a supplier answers this point is the most informative thing you will learn in the first meeting.

What gets exchanged between the systems?

Traffic falls into five groups.

• Inventory. What stock is in the automation. In shape two it is a quantity per item. In shape one it is a quantity per location.
• Inbound receipts. What you have received and want stored, and a confirmation when it is put away.
• Orders or tasks. What needs to leave, for which order, by when.
• Confirmations. What was picked, sorted or packed, so the WMS can update stock and close the order.
• Exceptions. Everything that did not go to plan.

How do the two systems connect?

There are four common routes, and a supplier may use more than one. A live interface passes messages between the systems as events happen. A file drop has one system write a file on a schedule for the other to read, which is simple and slow. A shared staging table lets both sides read and write agreed tables, which is easy to build and blurs who owns what. Middleware puts a third product between the two to translate, which helps with an old WMS and adds a third party to every fault.

The right one depends on how fast your WMS can respond and what your WMS vendor will support. Ask which the supplier uses and why.

Why are the exceptions the integration?

The happy path is short. An order comes in, stock is picked, the order is confirmed. A competent team can make that work quickly, and it will look finished.

The months go on everything else.

• Short picks. The system says six, the picker finds four. What does the WMS do about the missing two, and what happens to the rest of the order?
• Damaged stock. A unit is found broken at the station. It must leave available stock in both systems without leaving a phantom location.
• Orders cancelled mid-pick. The customer cancels while stock is already on a robot. Someone must decide where it goes and who records it.
• Cycle counts. Your count team finds a different quantity from the book. The correction must reach both systems and survive the next sync.
• Partial receipts. A pallet arrives a third short. Do you receive what is there, hold the rest open or reject it?

Each needs a rule, a message and a test. A demo never shows them, because a demo runs the happy path. Size the integration from the exceptions, not the normal flow.

What if you have no WMS, or only an ERP?

You have three realistic options.

Run on the automation's own software. A system that owns its storage already tracks its locations and runs its own task logic. For a smaller site that may be enough.

Connect the ERP directly. An ERP can release orders and take stock updates. It was not designed for wave planning, slotting or exception handling, so expect gaps.

Buy a WMS first or alongside. If you are about to automate, you may be about to outgrow an ERP's stock module. A WMS project and an automation project are separate workloads, so sequence them on purpose.

Who does the integration work?

Usually all three parties, on different parts. The automation supplier builds and tests its side of the interface. Your WMS vendor builds and tests its side, and often charges for it. You own the business rules and the test cases, because only you know what a short pick should do.

The risk is the gap between the first two, because a fault that falls between two vendors can be pointed at either. Integration and ongoing support are part of our engagement, so there is one party to ask. A multi-brand site is a different case, and an integrator is often the better answer there. The direct versus integrator article sets out the trade.

How does a Mushiny system connect?

Our systems connect to your warehouse management and order systems rather than replacing them. The Minisorter integrates with WMS, WCS, ERP and MES. On the PolyPacker, integration is smaller than people expect: you send the machine a label to print.

One detail about the robots is worth knowing. Our grid robots find their position from QR markers on the floor, inside a fenced area that people do not enter. A QR marker tells the robot where it is, not where to go. The route is worked out on the day by the robot and the fleet manager together, so a WMS has no reason to know anything about routes.

The transport, the message format and how much stock detail your WMS sees are settled during design, against your system rather than in general. Ask for all three in writing before you sign.

What should you ask a supplier about WMS integration?

1. What does my WMS see inside the automation? One location with a quantity, or every pod and bin?
2. Who decides which stock and which location fills an order? My WMS or your software?
3. How do you handle a short pick, and what do you send my WMS?
4. What happens when an order is cancelled after stock is already moving?
5. How do cycle counts and stock adjustments flow, in both directions?
6. If the link to my WMS is down for an hour, do the robots keep working, and how do the systems reconcile afterwards?
7. Have you connected to my WMS before? If not, to which others, and who did the work?
8. Who writes, owns and tests the interface specification?
9. What does a change on my side cost? A WMS upgrade, a new location format or a new zone.
10. Who do I call at 6am when the two systems disagree?

Vague answers to questions 1 to 5 mean the integration will be larger than the quote suggests. Bring your WMS name and version when you enquire, so the answers are about your site.

Frequently asked questions