SAP S/4HANA Route Optimization

What SAP ships today around transportation and delivery

SAP’s transportation and delivery surface is bigger than most ERPs. Drawing the line precisely matters when scoping a last-mile layer alongside it.

• SAP Transportation Management (TM). The SAP module for transportation planning. Multi-modal (rail, ocean, road TL/LTL), freight cost allocation, carrier orchestration, customs and trade integration. Built for shippers and 3PLs at enterprise scale, separately licensed, with its own data model and own user surface. Where deployed, TM owns the freight planning workload.
• SAP EWM and MM-IM. Warehouse-floor workflow: wave picking, putaway, packing, goods issue, inventory postings. Designed to maximize warehouse throughput. Hands off at the loading dock; last-mile starts after.
• SD outbound delivery. The standard S/4HANA document that represents a shipment from the warehouse to a customer. Captures items, quantities, ship-to address, requested delivery date. The optimization step (which truck, which order, which sequence) is not in scope of the outbound delivery itself.
• MRP-driven scheduling. Sales orders schedule delivery dates from material availability and standard lead times. Not a route-aware availability calculation; that needs a routing layer.
• SAP Fiori delivery apps. ERP-side Fiori apps for tracking outbound deliveries, monitoring shipment status, posting goods issue. ERP record surface, not driver-app or last-mile execution surface.

SAP’s job is ERP, finance and enterprise-scale supply chain. Where it stops, for an own-fleet last-mile operation, is the lightweight route plan itself, the driver-app workflow on the road, the live customer-facing tracking, and the route-aware slot calculation.

What own-fleet last-mile route optimization actually models

Constraint-aware own-fleet last-mile route optimization is a distinct problem from freight planning (TM’s strength) or warehouse picking (EWM’s strength). The optimizer has to model the truck, the road, the customer, the driver and the SLA, all at once, and re-plan continuously as the day unfolds.

• 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 plants, shipping points 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.

SAP TM can model some of this, but the surface is heavyweight: a TM deployment is months of engagement, not weeks, and the user experience is enterprise-transportation-planner, not lightweight last-mile dispatcher. For own-fleet last-mile operations the engagement model is wrong, even where the math is in TM’s wheelhouse.

Where S/4HANA users land today for own-fleet last-mile

Three patterns are common in S/4HANA customers that haven’t yet added a dedicated last-mile layer. None scale cleanly past 50+ in the field, multi-plant, or recurring patterns.

• Spreadsheets and manual planning. A planner exports the day’s outbound deliveries from SD 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.
• SAP TM configured for the case. Where TM is licensed, customers sometimes try to bend it to last-mile. The freight orientation, the deployment weight and the user-experience gap usually make this expensive and slow. Some succeed, many add a dedicated last-mile layer alongside TM for the execution surface.
• External routing tool with manual copy-paste. Plan in Tool A, key the result back into the outbound delivery in S/4HANA. 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 last-mile layer that reads S/4HANA 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 SAP plants and shipping points.
• 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 S/4HANA

The combined deployment leaves S/4HANA in place as the ERP and system of record. The integration runs over both products’ APIs.

1. Read from S/4HANA. eLogii pulls open outbound deliveries, business partner delivery addresses, material dimensions (weight, volume, pallet count from the material master) and plant / shipping point records from S/4HANA via OData (whitelisted on S/4HANA Cloud Public, broader on Private and on-prem). Pull on a schedule, or push via SAP Event Mesh on outbound delivery creation.
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 S/4HANA. Routes, stop sequences and ETAs write back to S/4HANA as updates against the 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, triggering SD goods issue posting, billing and inventory clearance.
4. EWM and TM continue unchanged. SAP EWM still governs the warehouse floor. Where SAP TM is licensed, TM continues to own freight and long-haul planning. eLogii starts once the truck is loaded and the last-mile leg begins.

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

Frequently asked questions

Does SAP S/4HANA have built-in route optimization?

SAP Transportation Management (TM) is the SAP module for transportation planning, but it is a separately-licensed product designed for enterprise freight and long-haul: multi-modal (rail, ocean, road TL/LTL), freight cost allocation, carrier orchestration, customs. Core S/4HANA (without TM) has no own-fleet last-mile route optimization engine; outbound deliveries are scheduled via MRP and SD logic with manual route grouping. Many S/4HANA customers do not license TM, and many of those that do still run a dedicated last-mile layer for own-fleet execution because TM was not built to be a lightweight last-mile driver-app workflow.

What do S/4HANA users typically do for own-fleet last-mile routing today without a dedicated layer?

Three common patterns: spreadsheets and manual planning (planner exports the day’s outbound deliveries and lays out stops by hand each morning), SAP TM configured for the case (heavyweight, not ideal for fast-changing last-mile execution), or an external routing tool with manual delivery copy-paste. None scale cleanly past 50+ in the field, multi-plant, or recurring patterns.

How does eLogii integrate with S/4HANA for routing?

Through both products’ APIs. eLogii pulls open outbound deliveries, business partner delivery addresses, material dimensions and plant / shipping point records from S/4HANA via OData services (whitelisted on S/4HANA Cloud Public, broader on Private and on-prem). The optimizer runs in eLogii against vehicles, depots, capacities, time windows, skills and SLAs. Routes, stop sequences, ETAs and completion data write back to S/4HANA via OData or BAPI, typically updating the outbound delivery so SD can post goods issue and trigger billing.

What route optimization constraints does eLogii model?

Vehicle capacity (weight, volume, pallet count), time windows (per business partner and per stop), driver skills, shift hours, depot start and end (mapped from SAP plant / shipping point), 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 or SD workflow?

No. SAP EWM continues to govern the warehouse floor: wave management, picking strategies, packing stations, goods issue posting. SD continues to own the sales order, outbound delivery and billing. eLogii picks up once the load is built and the truck is ready to roll, and writes back to the outbound delivery so SD can complete its workflow. The two systems hand off cleanly: SAP owns the warehouse and the ledger; eLogii owns the road.