Getting AS/RS and WMS to Talk: WCS Handshakes, Task Messages, and Exception Handling in Practice

Frankly, nine out of ten AS/RS projects don't fail on the stacker cranes or the racking tolerances — they fail on the layer in between: the WCS. The equipment is bought, the WMS is already there, but the two don't speak the same language, so you need a translator in the middle. And if that translator is bad, the faster the AS/RS runs, the faster the chaos spreads. There are two sides to this. One side is technical integration — get the messages flowing. The other side is who calls the shots when something goes wrong — and that's the side that actually kills you.

Here's my conclusion up front: the WMS is the brain, the WCS is the cerebellum, the AS/RS is the hands and feet. Integration isn't about "connecting" — it's about all three layers agreeing on what "inventory truth" and "task status" mean. If they disagree, smooth message flow is just a timed bomb.

How AS/RS and WMS Actually "Talk": The Three-Layer Split

First, get the division of labor straight:

The round-trip: the WMS issues a task — task ID, pallet ID (or LPN), source and destination stations, priority. The WCS queues it and assigns it to equipment. When the equipment finishes, the WCS reports back: success, failure, reason code. Three details cause most of the trouble: first, on timeout, exactly one side owns the retry — not both, not neither. Second, the same task ID must be idempotent — if the network hiccups and the message goes out twice, the crane must not execute it twice. Third, book inventory in the WMS and physical inventory in the WCS must use the same definitions — a pallet the WMS calls "in stock" must be genuinely findable by the WCS. These three belong in writing before integration testing starts.

Here's a landmine buried at the selection stage: who owns inventory truth? The WMS says "I'm the books, the books rule." The WCS says "I hold the physical goods, the goods rule." The most common fight is over "in-transit" status — a pallet already pulled off the rack and riding the conveyor. The WCS considers it "not in storage"; the WMS still considers it "in stock and allocatable." Then an urgent order comes in, the WMS assigns that pallet to another task, the crane goes to the station, and grabs air. If this definition isn't settled before go-live, you'll argue about it every day. My position is simple: physical reality wins. The WMS's "in stock and allocatable" must exclude the WCS's in-transit quantity. Write it into the interface contract and stop arguing.

I've seen too many projects where integration testing only covers the happy path: task issued, equipment executes, acknowledgment succeeds, everyone applauds. Then week one of go-live starts teaching lessons.

The Three Classic Wrecks I've Seen Too Many Times

Wreck one: the WCS goes down, and the WMS keeps issuing tasks. During pre-peak-season integration at one site, the WCS server rebooted in the middle of the night for about ten minutes. The WMS never noticed and kept issuing hundreds of tasks. When the WCS came back, the backlog flooded the equipment all at once and the sequence was destroyed — urgent orders buried behind routine replenishments. It took an entire day shift to untangle the task queue. The postmortem found the root cause: the heartbeat interval was set so long that a full reboot slipped through undetected.

Wreck two: inventory reconciliation definitions at war. The WMS books showed a pallet in AS/RS Zone A; the WCS showed it had been pulled down abnormally to the manual area a week earlier, and the return message was lost in a network jitter. So the system said "in stock" and the equipment said "nope," and the pick task waited at the station for nothing. Worse, you can't chase this kind of book-to-physical gap with manual cycle counts — the daily pallet throughput of an AS/RS would take a manual crew a month to count. They ended up reconciling pallet by pallet, WCS physical snapshots against WMS books, until every stray pallet was found.

Wreck three: exception acknowledgments nobody handles. A crane reports "pick failure." The WCS converts it into a generic error code and throws it at the WMS. The WMS interface program doesn't recognize the code and drops it. The task is neither success nor failure — it just hangs there. The operator stares at the screen waiting for goods that never come, calls IT, and IT says the system shows "issued." Three parties staring at each other. The root cause was almost funny: the error code table was defined casually by the integrator, and the WMS side never mapped it.

Here's a contrarian take: the more automated you are, the more you depend on your degradation plan. People think an AS/RS means sleeping easy. It's the opposite — the biggest risk of an AS/RS isn't broken equipment, it's the system believing the equipment isn't broken. A broken crane you can see; a lost message you can't.

One more detail most people miss: task priority. The WMS's "rush order first" becomes simple queue-jumping when translated at the WCS layer — running tasks get interrupted constantly, crane empty-travel rates shoot up. The rush order gets faster, overall throughput gets worse. Priority strategy has to be designed at both layers together: the WMS sets business priority, the WCS sets execution batching, each minding its own business. Every project where the WMS directly commands equipment ends in a mess.

Keeping AS/RS and WMS Talking: Four Iron Rules

First, the interface contract comes before everything. Before integration testing, align the task state machine: issued, executing, succeeded, failed, exception-hold — five states, no fewer. Who can transition each state, how long a timeout counts as failure — in writing. Retry ownership belongs to exactly one side. Idempotency keys must flow through the entire chain. Error code tables must be mapped line by line on both sides — a code like "general error" is not allowed to exist.

Second, the degradation plan. What happens when the WCS goes down? The WMS must be able to pause issuance immediately, and in-flight tasks must be exportable as a list for manual handling. Degradation isn't "wait for IT to fix it" — it's a switchover procedure you've actually rehearsed. A plan that's never been rehearsed is no plan. My acceptance criteria for clients always include one line: disconnect the WCS for ten minutes; after recovery, tasks and inventory must reconcile. If they don't, hold the final payment.

Third, reconciliation. Every shift, the WMS and WCS reconcile: book inventory against physical locations. Differences may never be fixed by hand-editing the books — they go through the exception process: find where the pallet went, find where the message was lost, then adjust. Books can be wrong, but wrong with a trail. Hand-editing feels good for a moment; the whole warehouse cries at reconciliation time.

Fourth, the integration checklist. Message stress tests, network-outage drills, full coverage testing of every error code — none optional. Especially the outage drill: unplug the network cable between WCS and WMS for ten minutes, then check whether tasks and inventory still reconcile after recovery. If they do, the project is genuinely connected. So many projects die on "everything was fine during integration" — of course the network was fine during integration; you've never seen what "not fine" looks like.

For those of you selecting a vendor right now, three questions to ask the integrator before signing: one, when the WCS goes down, can the WMS automatically pause issuance, and can the in-flight task list be exported in one click? Two, is the error code table mapped line by line into the WMS, or are there vague codes nobody owns? Three, does shift-level book-to-physical reconciliation run automatically or depend on someone remembering? If they can't answer one of the three, the implementation will cost extra — not maybe, definitely.

Next time an integrator tells you "the interfaces are all connected," ask them one question: the WCS loses network for ten minutes — does your inventory still reconcile?

By Lao Mi, Supply Chain Veteran (20 yrs)