SAP EWM Route Optimization

What SAP EWM ships today around delivery

SAP EWM is comprehensive on the warehouse side, and several of its modules touch the delivery problem. Drawing the line precisely matters when scoping a routing layer alongside it.

• EWM picking, packing and staging. Standard SAP EWM warehouse workflow. Tracks the pick task, the pack station and the shipment confirmation. Sequences picks within a wave but does not optimize a multi-stop delivery route across capacity, time windows and constraints.
• SAP EWM. The full warehouse management module. Wave management, picking strategies, mobile-scan workflows. Designed to maximize warehouse throughput. Hands off at the loading dock; routing starts after.
• EWM EWM shipping flow integration. Rate-shop and label-print against UPS, FedEx, DHL, USPS. Designed for parcel handoff: which carrier and service is cheapest for this shipment, generate the label, attach the tracking number. Not for own-fleet routing where you choose the stop order.
• EWM stock and slotting. Demand planning, replenishment, distribution requirements planning. Inventory-side decisions, not routing-side.
• Sales order date picker. Customers (or CSRs) can capture a requested delivery date on the order. SAP EWM does not check whether that date is achievable against the current optimized route plan; that calculation needs a routing layer.

SAP EWM was not built to be a routing engine, and the workflows above are the right tools for what they cover. Where SAP EWM stops is the route plan itself, the order each stop runs in, and the constraint set the optimizer enforces.

What real route optimization actually models

Constraint-aware route optimization is a distinct problem from stop sequencing or warehouse picking. The optimizer has to model the truck, the road, the customer, the driver and the SLA, all at once.

• Vehicle capacity. Weight, volume, pallet count, refrigerated space, hazmat zones. Different vehicles in the fleet carry different mixes of items.
• Time windows. Customer-confirmed delivery windows. Store opening hours. Driver shift bounds. School-zone restrictions. Loading-bay availability at the depot.
• Multi-stop sequencing. Hundreds of stops per truck per day. The order matters: a poorly sequenced 40-stop route adds 30%+ drive time over an optimal one.
• Multi-depot. Several depots, branches or cross-dock locations. The optimizer chooses which depot loads which truck for which stops.
• Multi-day. Long-haul routes and recurring service programs that span days. Overnight stops modeled directly.
• Skills and SLAs. Certain customers require a driver with a specific cert. Certain stops have a contracted SLA that can’t be missed.
• Dynamic re-optimization. A canceled stop, a no-access visit, a late driver. The plan re-optimizes on the fly without breaking customer-confirmed slots.

None of this is what EWM picking, packing and staging or EWM EWM shipping flow is designed to do. It is a separate workload that needs its own engine.

Where SAP EWM users land today without a routing layer

Three patterns are common in SAP EWM customers that haven’t yet added an optimization layer. None scale cleanly past 50+ in the field, multi-depot, or recurring patterns.

• Spreadsheets and manual planning. A planner exports the day’s open orders to Excel each morning, groups them by region and vehicle, sequences stops by hand, prints route sheets. Works at small scale, scales linearly with the planner’s hours, breaks at the first big day or the first planner sick day.
• Basic stop sequencer. A point tool that orders the stops once vehicles are pre-assigned. Does not balance load across vehicles, doesn’t respect customer time windows beyond a soft sort, doesn’t handle multi-depot. Better than spreadsheets, still not optimization.
• External routing tool with manual copy-paste. Plan in Tool A, key the result back into SAP EWM. Disconnected. The route is correct on Monday morning and out of date by Monday afternoon when the first order cancels.

The path forward is a routing layer that reads SAP EWM directly and writes back. That is the role eLogii plays.

How eLogii does route optimization

eLogii’s optimizer is built around two engines and six configurable modes, all callable via REST. The planner sees the rules in their dispatch desk and can adjust them; the optimizer doesn’t hide behind a black-box ML score.

• Two engines. The Default engine optimizes 100 tasks in under 10 seconds for high-throughput daily planning. The Advanced engine takes more factors into account and is the choice for multi-depot, multi-day, long-haul and constraint-heavy operations.
• Three assignment modes. Optimize Everything (creates fresh routes including all assignments), Add to Routes Keep Existing Assignments (incorporates new tasks into existing routes while preserving driver assignments), and Add to Routes Keep Existing Assignments and ETAs (inserts new tasks into available slots without modifying existing stop sequences or ETAs).
• Three load-balancing modes. Most Efficient Routes (fewest vehicles), Balance the Minimum Number of Routes (across load, time, distance or job count), and Use All Vehicles Finish as Soon as Possible (maximise speed across the fleet).
• Multi-day and long-haul. Plan a single day or an entire month in one run; multi-day routes with overnight stops modeled directly.
• Multi-depot. Route across multiple depots, branches or home start locations in a single optimization run. Maps directly onto EWM warehouse numbers and storage bins.
• Recurring patterns. Task and route template groups: weekly, monthly, quarterly, bespoke cadences modeled at the data layer, not bolted on at scheduling time.
• Rule-based re-optimization. Operator-visible rules; live re-optimize while protecting locked SLAs and customer-confirmed slots.

How the integration sits with SAP EWM

The combined deployment leaves SAP EWM in place as the warehouse system of record. The integration runs over both products’ REST APIs.

1. Read from SAP EWM. eLogii pulls open delivery orders, customer delivery addresses, item dimensions (weight/cube from the item record) and depot/Location records from SAP EWM via EWM OData services. Pull on a schedule, or push via a SAP enhancement spot on order approval.
2. Optimize in eLogii. The optimization run produces routes with vehicle assignments, stop sequences, ETAs and any cross-day constraints honored. Planner reviews in eLogii’s dispatch desk or accepts an Auto run.
3. Write back to SAP EWM. Routes, stop sequences and ETAs write back to SAP EWM as updates against the sales order or a linked outbound delivery (typical pattern; the exact target depends on your tenant). Completion data and proof of delivery references flow back when the driver finishes the stop, so EWM can post Goods Issue and the upstream ERP can invoice.
4. EWM picking, packing and staging continues unchanged. SAP EWM still governs the warehouse floor. eLogii starts once the truck is loaded.

Most teams complete the integration in 3 to 5 weeks. Typical first wave: one depot, one region or one business unit (often the route the planner spends most time on by hand). Validate on real historical orders, then expand.

Frequently asked questions

Does SAP EWM have built-in route optimization?

No. SAP EWM ships warehouse-floor workflow (EWM picking, packing and staging; SAP EWM) and parcel-carrier integration (EWM EWM shipping flow for UPS, FedEx, DHL, USPS rate-shop and label-print) but no constraint-aware multi-stop route optimization engine. EWM picking, packing and staging sequences stops within a wave; it is not a routing optimizer. Customers running own delivery fleets typically add a routing layer downstream of SAP EWM.

What do SAP EWM users typically do for routing today without an optimizer?

Three common patterns: spreadsheets and manual planning (planner lays out stops by hand each morning), a basic stop sequencer (orders the stops once vehicles are assigned but does not optimize against time windows or capacity), or an external routing tool with manual order copy-paste. None scale cleanly past 50+ in the field, multi-depot, or recurring patterns.

How does eLogii integrate with SAP EWM for routing?

Through both products’ REST APIs. eLogii pulls open delivery orders, customers, item dimensions and depot/Location records from SAP EWM via EWM OData services (scheduled or pushed via SAP enhancement spot on order approval). The optimizer runs in eLogii against vehicles, depots, capacities, time windows, skills and SLAs. Routes, stop sequences, ETAs and completion data write back to SAP EWM, typically against custom fields on the sales order or a linked outbound delivery.

What route optimization constraints does eLogii model?

Vehicle capacity (weight, volume, pallet count), time windows (per customer and per stop), driver skills, shift hours, depot start and end, SLA windows, customer-confirmed slots, multi-day routes, multi-depot routes, return-to-depot rules, recurring service patterns. Two engines: Default for high-throughput single-day planning (100 tasks in under 10 seconds), Advanced for multi-depot, multi-day, constraint-heavy work. Six modes: three assignment plus three load-balancing.

Does adding eLogii change SAP EWM’s EWM picking, packing and staging workflow?

No. EWM picking, packing and staging continues to govern the warehouse: wave management, picking strategies, packing stations, shipment confirmation. eLogii picks up once the load is built and the truck is ready to roll. The two workflows hand off cleanly: SAP EWM owns the warehouse floor; eLogii owns the road.