WMS vs WCS CoreConvey

WMS vs WCS: Who does what in an automation project?

ByCoreConvey Team

If you’re planning conveyors, sortation, or AMRs, there’s one question to settle early: what lives in the WMS and what lives in the WCS? Get that wrong and you’ll fight delays, finger-pointing, and data you can’t trust. Get it right and the hardware just works.

This post breaks down the roles in plain terms, shows how a parcel moves through the stack, and lists the decisions you should make before actually installing warehouse automation.

The three layers

  • ERP: Orders, customers, products, billing. It cares about what you sold and to whom.
  • WMS: Inventory, tasks, wave planning, cartonization, shipping labels. It decides what should happen in the warehouse.
  • WCS: Real-time device control for conveyors, sorters, scanners, scales, photo capture, AMRs. It decides how it physically happens right now, in the next second.

Think of the WMS as the planner and the WCS as the traffic controller. The planner says “send item X to lane 23.” The traffic controller makes the rollers spin, verifies the barcode, checks weight, and kicks it to lane 23. If something goes wrong, WCS handles the detour and tells WMS what happened.

A parcel’s journey (what good looks like)

  1. WMS assigns routing.
    WMS tells WCS: “Parcel ABC123 → destination D23.” It may also send expected weight/dims and service level.
  2. Induct & identify.
    WCS triggers the scanner and camera. If read succeeds, it ties the read to ABC123. If not, it sends the item to an exception spur.
  3. Check & validate.
    WCS compares measured weight/dims to the WMS expectation (within tolerance). Out-of-tolerance? Flag it and route to check-weigh.
  4. Route & divert.
    WCS sets speeds, gaps, and actuates diverters. The parcel lands in D23 (bag, bin, chute, cage, or belt).
  5. Report back.
    WCS posts events: ARRIVED, READ_OK, DIVERTED:D23, or EXCEPTION: NO_READ / OOT_WEIGHT. WMS updates the order and shipping docs.

This sounds simple because it should be. Problems start when steps are half-defined or shared between systems without a clear owner.

Common failure modes (and how to avoid them)

  • No single source of routing truth.
    Fix: WMS owns routing; WCS executes it. If WCS needs local rules (e.g., lane full), document them and the fallback path.
  • Data drift on SKUs.
    Fix: Agree which system is the master for item size/weight. Set tolerances in writing (e.g., “±10% or ±100g”).
  • Late label logic.
    Fix: Decide where labels are created and when. If printing is downline, make sure WCS and WMS share the same order ID at induction.
  • Ambiguous exception handling.
    Fix: Define “NO_READ,” “DUPLICATE,” “TOO_LARGE,” “OVERSIZE,” and where each goes. Who resolves it and in what screen?
  • Tight coupling.
    Fix: Use stable APIs and small messages. Don’t bury business rules inside device PLCs.

The integration you actually need

Keep it light, predictable, and testable.

Core message types (WMS ↔ WCS):

  • Routing request (WMS → WCS): item_id, dest_code, optional expected_weight/dims, service_level
  • Event (WCS → WMS): item_id, event_type, timestamp, station, optional measured_weight/dims, photo_url, error_code
  • Lookup (WCS → WMS, if needed): ask for routing when only a barcode is known
  • Heartbeat: “I’m alive” checks to monitor the link

Transport: REST API is clean. FTP drops still work and are fine for batch flows. Use idempotent calls and retries.

Example event (simple JSON):

{
  "item_id": "ABC123",
  "event_type": "DIVERTED",
  "dest_code": "D23",
  "station": "XBELT-02",
  "timestamp": "2025-08-19T10:15:27Z",
  "measured_weight_g": 740,
  "photo_url": "https://files/coreconvey/photos/ABC123.jpg"
}

Lock this spec before FAT (Factory Acceptance Test). It saves weeks later.

What the WCS should handle locally

  • Scanner triggers, camera timing, scale reads
  • Zone speeds, gaps, merge logic, jam recovery
  • Lane full/blocked handling and temporary re-routes
  • Health checks: motor faults, e-stops, photoeye status
  • Immediate safety stops and controlled restarts

The WCS doesn’t need to know your whole business. It just needs enough to move each item correctly and tell the WMS what happened.

Acceptance tests that prove it works

Write tests from the operator’s point of view, not just device I/O.

  • Read rate: e.g., 99.5% on standard labels at design speed
  • Throughput: target items/hour sustained for 30 minutes
  • Accuracy: % of items to the correct lane under a mixed wave
  • Tolerances: out-of-tolerance items are caught and diverted
  • Exceptions: NO_READ, lane full, jam, scanner offline—each with a clear outcome
  • Data: events land in WMS within X seconds; no duplicates

Pass/fail is a lot easier when numbers are on paper.

Configure or customize?

  • Configure: lane names, speeds, scanner windows, tolerances, API endpoints, user roles.
  • Customize: only where it saves real money or time (e.g., a special bagging chute or a unique routing rule you use daily).
    Every custom line of code has a maintenance cost. Keep it lean.

A short checklist before you buy

  1. Who owns routing logic—WMS or WCS?
  2. What events are sent, in what format, and how fast?
  3. What are the read-rate, throughput, and accuracy targets?
  4. How are exceptions defined and resolved?
  5. Where are labels produced and verified?
  6. What are the weight/dimension tolerances and the master system?
  7. What does “site ready” mean—power, data, floor, safety?
  8. What’s the SAT criteria and who signs it?

Answer these and your project will run smoother, go live faster, and give you cleaner data on day one.

At CoreConvey, we keep the split simple: WMS plans, WCS moves, and the two talk clearly. If you want a sample spec or a quick review of your current setup, we’re happy to help! Contact us here

Similar Posts