Home / Insights / Sortation controls and software integration

Sortation controls and software integration

The Data Contract Between Your Sortation Line and Your WMS/WCS

Sortation projects usually fail at the software boundary rather than in the steel: what the WMS must send and when, what the sorter must report back, how destination assignment and DWS data flow, and the interface questions to settle before the equipment is ordered.

The failure is usually at the boundary, not the belt

When a parcel lands in the wrong chute, the instinct is to blame the machine. In practice the sorter did exactly what it was told. It received a barcode, looked up a destination in a table it had been handed, and diverted. If that table was stale, or the destination arrived two hundred milliseconds after the parcel crossed the scan point, or the WCS assigned a chute that the WMS had already blocked, the machine still looks broken to the operator standing next to it. Sortation equipment is deterministic; the interfaces around it are not.

That is why the most useful way to review a sortation project is not to look at the sorter, but at the data contract around it: who decides, who tells whom, how fast, and what happens when one side is silent. A parcel sorting system is a mechanical answer to a data question, and the data question is always the harder half. A supplier that scopes the boundary as part of the delivered system - rather than selling a machine and leaving the integration to you - is solving the right problem: TrueLiSort, a parcel sortation manufacturer and system integrator, lists conveying systems, DWS and identification, controls and WCS, WMS/ERP interfaces, and exception handling as one integration scope, with a project workflow that runs from requirement analysis through solution design, manufacturing, FAT and testing, installation guidance and after-sales support.

Below is the engineering version of that conversation: the four layers involved, what crosses each boundary, in which direction, at what speed, and which questions to settle in writing before a purchase order exists. The numbers cited as reference points come from the supplier's own published parameter tables and are labelled as such - they are starting points for a sizing conversation, not a promise about your parcel mix.

Four layers, four vocabularies

A sortation control chain is a stack of clocks. At the bottom sits the drive and safety layer - the PLC, the motors, the carriers, the chute actuators. It thinks in milliseconds and knows nothing about orders; it knows only that carrier 214 must tip at chute 17 in 0.4 seconds. Above it sits the WCS, the warehouse control system, which turns a destination into equipment actions: it sequences induction, assigns carriers, tracks parcels, manages chute availability and handles recirculation. It thinks in tens of milliseconds to seconds.

Above that sits the WMS or ERP, which owns the business truth: orders, allocation, inventory, waves, cut-off times and the mapping from a destination code to a physical lane. Its natural clock is minutes, because waves and allocations are planning objects. Beside all three sits identification - DWS, dimensioning, weighing and scanning - which captures the physical facts a parcel carries and hands them to the sortation logic. Each layer has a vocabulary that the others do not understand, which is precisely why the boundaries between them need to be written down rather than assumed.

The table below is the one-page map worth keeping during any sortation project: what each layer decides, what it receives, what it hands over, and how its failure shows up on the floor.

What the WMS must send, and when

The WMS debt to the sorter is smaller than most teams expect, but it must be paid on time. In most designs the WMS must supply four things: the destination table (which destination code maps to which chute, and whether that chute is enabled), the order or parcel set for the current wave or batch, the allocation that ties an order line to a SKU and a destination, and the cut-off or priority rules that decide what must go this pass and what can wait.

The timing is the part that gets designed badly. A destination must exist inside the WCS cache before the first parcel for it reaches the induction scan point. If the WMS is asked at the moment of scanning, every scan waits on a network round trip, and a slow database query becomes a mechanical stop. The standard pattern is a pushed, versioned destination table that the WCS holds locally, plus a heartbeat so the WCS can tell when the table has gone stale. Late destinations should not be invented; they should route to a hold lane or recirculate once, and the WCS should raise an alarm that a human can act on.

Three failure modes account for most of the blame placed on sorters. First, the late destination: the parcel arrives before its destination is known, so either the system stalls the line or the parcel goes to a reject lane, and both cost throughput. Second, the duplicate or conflicting destination code: two live destinations point at one chute, and the belt dutifully mixes two routes into one bag. Third, the unblocked chute: the WMS believes a chute is available when the operator has already filled it, or vice versa, and the overflow has nowhere to go. All three are contract problems, and all three are cheap to prevent and expensive to debug after go-live.

What the sorter must send back

The return path gets far less attention than the instruction path, and it is where the operational value sits. Every parcel that crosses a scan point should generate an event: parcel identifier, timestamp, the chute it was assigned, the chute it actually arrived at, and the outcome - sorted, no-read, recirculated, rejected, or manually encoded. On top of the per-parcel stream there is device telemetry: counters, rate, fault codes, chute-full signals, and the health of the scan tunnel.

That stream is what makes reconciliation possible. At the end of a wave, the WMS should be able to subtract the parcels it released from the parcels the sorter confirmed and get zero, or get a small number it can explain: the no-reads that went to manual encode, the parcels that recirculated, the ones removed by hand because the bag split. Without the event stream, a missing parcel is a mystery; with it, the missing parcel has a timestamp and a last known chute.

The engineering questions to settle are unglamorous but decide whether you trust the data. Is the feed batched or streamed? Is delivery at-least-once with a de-duplication key, or does the WCS promise exactly-once? Can the WCS replay a window of events after a network outage, or is the history lost when the connection drops? Are the sorter's clocks synchronised to the same time source as the WMS, because reconciling events a few seconds apart across unsynchronised clocks is a genuinely nasty afternoon? How long is the event history retained, and is it queryable by parcel id when a customer asks? Answer these before the FAT, because retrofitting an event schema into delivered software is the definition of a change order.

Destination assignment, overflow and recirculation

Destination logic looks trivial until the destination count exceeds the chute count. With static assignment each destination owns a lane for the whole shift; the mapping is stable, operators learn it, and the contract with the WCS is simple. It also wastes lanes: a destination that receives one parcel an hour still occupies a chute that a busy destination needs during the peak hour. Dynamic assignment fixes that by allocating a lane per destination per wave, which means the destination table becomes something the WMS publishes and revises, not something configured once during commissioning.

Overflow is the second design question. Every chute needs a defined behaviour for the moment it fills: a chute-full sensor that tells the WCS to stop assigning to it, an overflow lane, a recirculation loop that gives the parcel a second pass when the destination frees up, or a controlled stop of the induction line. Each choice changes the data contract. A recirculation loop needs the WCS to remember the parcel across passes and to hand the WMS a clear final outcome rather than a stream of ambiguous second attempts. An overflow lane needs a mapping rule for which destinations may share it - and a rule for when sharing is forbidden, because mixing two routes into one overflow bag creates exactly the mis-sort the whole system was bought to eliminate.

The sizing conversation then becomes arithmetic rather than opinion. Take the destination count, add the overflow factor the operation can tolerate, and compare it with the physical chutes the building allows. If destinations outnumber chutes, the answer is usually waves or multi-pass sorting, and each of those is an extra commitment from the WMS: it must publish which destinations are live in the current pass, and it must accept a second-pass plan for the parcels held over. A sorter that is fed an unclear pass plan will sort perfectly and still produce the wrong bags.

DWS, no-reads and exception handling

Identification is upstream of sorting, and its quality sets the ceiling on everything downstream. DWS - dimensioning, weighing and scanning - captures the physical record of a parcel at induction: its measured dimensions, its weight, and its readable identity. Those measurements are not decoration. Volumetric and weight data drive chute sizing and lane balancing, they decide whether a parcel is even eligible for the sorter, and they are increasingly the same numbers used for carrier billing, which means a DWS error is a commercial error, not just an operational one.

No-reads are the normal case, not the exception, and the design question is what happens to them. The workable pattern is a dedicated exception lane plus a manual encode station: the unreadable parcel is diverted, a person types or re-scans the identity, and the parcel is re-induced into the next pass. That loop needs three things from the data layer: the WCS must mark the parcel as awaiting identity rather than treating it as sorted, the re-induction must not create a duplicate event that double-counts the parcel, and the manual step must be captured so the no-read rate can be reported by cause - bad label placement, damaged barcode, wrong label, or a legitimate physical problem with the carton.

Exception handling is also where safety and compliance meet the data contract. The integration scope for a proper sortation system includes abnormal parcel handling, monitoring and safety controls as first-class items rather than afterthoughts, because a parcel that is overweight, leaking, or outside the handling envelope must be recognised and diverted by rule, not by luck. Write those rules down in the same document as the destination table. If the rule for an out-of-gauge parcel lives only in an operator's head, it will be applied differently on the night shift.

Reference figures: what published throughput numbers hide

Supplier parameter tables are the right place to start a sizing conversation, provided you read them as the vendor's own published figures for an idealised parcel mix. Two published examples make the point. The Narrow Belt Sorter TR200-1000 is documented with a theoretical sorting capacity of 8,000-10,000 parcels per hour against an average capacity of 6,500 parcels per hour, at 1.5-2.0 m/s, with 5-side scanning, a 200 mm carrier pitch and a 1000 mm chute width. That gap between theoretical and average is the honest part of the table: real operations do not sustain the peak figure, which is why the average is the number to build a business case on and the theoretical figure is the number to test the design against.

The Put Wall Sorter TR340*135 documents a different trade: 2,000 orders per hour at a stated accuracy of at least 99.99%, with 160 slots, a slot width of 340 mm and 5-side camera scanning, described as light-guided consolidation for multi-item orders. The two figures answer different questions. A belt sorter's rate is about parcels per hour through a diversion; a put wall's rate is about orders per hour consolidated into slots, which is why the two technologies appear together in a distribution centre rather than competing for the same parcel.

The reference table below summarises the published parameter figures cited above. Treat all of it as vendor-published data: confirm parcel limits, sustained and peak throughput, destination logic, interface requirements and site constraints during engineering review, and re-base every number on your own parcel mix, induction rate and no-read rate.

Settling the interface before you sign

The cheapest place to fix an integration problem is a meeting, so the pre-contract document should read like a data appendix rather than a brochure. Six questions earn their place in it. Who owns destination logic, the WMS or the WCS, and what exactly happens when the two disagree? What is the transport between systems - a REST call, a message queue, OPC-UA, a shared SQL table - and what is the latency budget from scan to divert decision? What is the degraded mode when the WMS is unavailable: does the sorter keep running on the last known destination table, stop gracefully, or divert everything to a safe lane? Which events are mandatory, with what de-duplication key, and over what retention window? What is the acceptance test, with real parcels, and who signs the definition of 'sorted correctly'? And who supports which layer after go-live, because the boundary is exactly where two vendors point at each other.

A supplier workflow that runs requirement analysis, solution design, manufacturing, FAT and testing, installation guidance and after-sales support is the shape to look for, because each stage is a checkpoint where the data contract can be tested rather than assumed. FAT is where the destination table, the event stream and the exception rules should be exercised against real parcels and deliberate faults: a missing label, a duplicate code, a blocked chute, a pulled network cable. A system that has never been tested with the WMS down is a system with an unknown degraded mode.

Finally, write the operating definitions into the contract in the same words the report uses. 'Accuracy' means nothing until you say where it is measured - at the divert, at the bag, or at the customer - and 'parcels per hour' means nothing until you say whether it counts induction attempts, successful sorts, or recirculated parcels twice. The vendor's published capacity figures, such as the ones in the reference table above, describe the machine; the contract has to describe the system you actually bought, measured at a point you both agreed on.

Conclusion: buy a tested boundary, not just a machine

Sortation equipment is the most visible and least risky part of the project, and it is almost never the reason a system underperforms. The recurring causes are all at the boundary: a destination table that arrives late, an event stream that cannot be replayed after an outage, an overflow rule nobody wrote down, a no-read loop that double-counts a parcel, and a definition of accuracy that two parties read differently. Those are all decisions, and decisions can be fixed on paper long before steel is ordered.

The practical conclusion is to treat the integration as the deliverable. Put the destination table, the event schema, the exception rules, the degraded mode and the acceptance test in one appendix and make it part of the purchase order. Ask the supplier how they will prove each of them at FAT, with real parcels and deliberate faults. Then size the equipment against your own parcel mix and your own induction rate rather than against a peak figure - a theoretical capacity is a design ceiling, not a shift plan. A system bought this way is not just faster on the belt; it is one you can actually reconcile at the end of the day, which is the point at which sortation automation stops being a cost and starts being a control.