In our previous post, we introduced the new Business Process Scheduling (BPS) framework and outlined how TM’s order‑scheduling capabilities have evolved. In this article, we focus on a practical and business‑relevant scenario which makes use of TM‑derived transportation durations to calculate reliable sales order delivery dates. This approach, introduced with Transportation Requirement Scheduling (TRS) in SAP S/4HANA, allows organizations to align order confirmation dates more closely with real transportation effort without adding unnecessary operational complexity during order entry.
The scheduling of a sales order uses the determination capabilities of BPS, which rely on Transportation Management (TM) for duration determination. It is important to note that TM’s contribution in this scenario is limited to providing duration data. BPS subsequently treats the entire transportation process as a single, consolidated activity. As a result, certain transportation‑specific constraints—such as intermediate stop operating hours, scheduled departure windows, or potential waiting times—are not fully reflected in the resulting schedule.

The component interaction can be summarized as follows:
1. Sales Order Input to BPS:
When a sales order is created, the system looks at what the customer wants—delivery date and quantity. The requested delivery date and quantity from the sales order schedule line are passed to the Business Process Scheduling (BPS) application, which is responsible for confirming the delivery dates
2. Duration Request to TM:
BPS sends a duration determination request to Transportation Management (TM) to calculate the loading, transportation, and unloading times based on the source and destination locations provided by the user during order entry.
3. Duration Determination by TM:
TM calculates the total time based on available routes and returns a combined duration. When multiple network stages are involved—such as pre-carriage, main carriage, and on-carriage legs—TM aggregates the individual durations into a single overall transportation duration.
4. BPS Calculates Picking Start Date:
Using the loading start date, BPS calculates the picking start date by applying the pick/pack duration maintained at the shipping point. This date represents when the material must be available—also known as the requested material availability date—which is then forwarded to ATP.
5.Material Availability Date Confirmation:
ATP confirms the material availability date for the requested product and quantity. If this confirmed date is later than the requested material availability date, the system triggers forward scheduling.
Customer Service Representatives (CSRs) and order management teams are often required to confirm reliable delivery dates at the time a sales order is created. These delivery commitments are not only critical for managing customer expectations but also serve as a key input for downstream planning activities, such as production scheduling, warehouse operations, and transportation execution.
To support both customer commitments and internal planning, organizations need delivery dates that are based on realistic transportation timelines, including transit durations and operational activities such as loading and unloading. When such logistics information is not considered, delivery dates are often based on estimates, increasing the risk of replanning, production disruptions, and missed customer commitments.
The following example demonstrates how Business Process Scheduling (BPS), in combination with Transportation Management (TM), enables delivery dates to be calculated using actual route-based transportation durations. This allows organizations to commit confidently to customers while simultaneously providing reliable dates that downstream production and logistics teams can use for effective planning.
In this example, Business Process Scheduling (BPS) uses Transportation Management to obtain the transportation time, based on the rules defined in the Transportation Duration Determination Profile. You can think of this profile as a set of business rules that guides the system on how to calculate the expected transportation time for a sales order.
Within the profile, we define multiple options for determining transportation time and set their priority. For example, the system first attempts to calculate the duration using a default route. If no valid duration is found, it automatically moves on to the next option—such as a transportation lane—and finally falls back to a straight-line distance‑based calculation using location coordinates. As soon as the system finds a reliable transportation time, it uses that value and stops checking further options.
In addition to transportation time, the profile also allows us to factor in handling activities that impact delivery commitments. For this scenario, we assigned a planning profile that defines a fixed loading duration of 1 hour at the source and a 30‑minute unloading duration at the destination stop.
This ensures that the overall delivery schedule reflects not only the travel time, but also the time required to prepare the goods for shipment and process them upon arrival.

Next, we create a Sales order that is relevant for BPS scheduling and enter the required details—such as customer (ship‑to party), plant, shipping point, Requested Delivery date, order quantity etc.—so scheduling can take place.

For the selected source (Shipping Point US21) and destination (Customer US11), a default route is already available with a calculated transportation duration of 7 hours and 45 minutes.

A fixed loading and unloading duration of 1 hour is maintained in the Planning Profile for the intermediate stop SD_HUB within the default route.


When you choose the Document option under Sales Order → Header, the system triggers scheduling. Scheduling also occurs automatically when the order is saved. Once scheduling is completed, the system opens the Review Availability Check Result (RACR) screen, where you can review the durations calculated for the various scheduling activities.
Note: Activating aATP is a prerequisite for the use of the RACR screen.

As shown on the results screen above, the system uses the requested Delivery Date and Time 17.04.2026 13:00 PT as the basis for performing backward scheduling. It calculates a total transit duration of 9:45 hours, which includes 7:45 hours from the default route and an additional 2 hours of fixed loading and unloading time—maintained in the Planning Profile for the intermediate stop SD_HUB.


The picking duration of 1 hour (maintained at the Shipping Point) is subtracted from the Loading Start Date/Time — 17.04.2026 04:15 CST — to determine the Material Availability Date. Because this time falls outside the working hours assigned to the Shipping Point (08:00 to 18:00 CST), the system adjusts the picking activity accordingly.
As shown in the message log, the end of the Pick activity is shifted from 17.04.2026 04:15 CST to 16.04.2026 18:00 CST to comply with the defined working hours. Consequently, the system determines a Pick activity start date/time of 16.04.2026 17:00 CST. Since the material is already available at 16.04.2026 17:00 CST, no forward scheduling is required.

1. Supported Only in Embedded TM Deployments
TM-based scheduling is available exclusively for embedded TM in S/4HANA. Standalone (sidecar) TM systems are not supported.
2. Aggregated Transport Durations for Multi-Leg Shipments
Although TM calculates the overall transport duration, it does not generate individual timestamps per transport stage when multiple legs are involved. Instead, durations are aggregated into a single total.
3. Scheduling of the loading, transport, and unloading activities performed by BPS and not TM
TM only delivers duration, but does not do scheduling, hence, limited information from TM can be incorporated in the Scheduling result generated by BPS.
4. No capacity consideration
Although BPS retrieves durations for loading, transport, and unloading via TM, it does not evaluate resource capacities or constraints during scheduling.
5. No Incorporation of Departure Wait Times or Intermediate Operating Times
Because BPS treats the entire transportation phase as a single activity, intermediate operating hours, scheduled departure waits, and stop-specific time elements cannot be reflected in the calculated schedule.
TM duration-based scheduling provides organizations with a practical way to improve delivery commitment accuracy by incorporating transportation durations directly into the sales order scheduling process. By leveraging transportation network data maintained in SAP TM, organizations can reduce dependency on traditional route-based scheduling while improving consistency between logistics planning and customer commitments.
While this approach does not account for all transportation-specific constraints, it offers a scalable and relatively simple method for generating more realistic delivery dates across sales and fulfillment processes.
In the next post in this series, we will explore TM-based scheduling in greater detail, where Business Process Scheduling delegates scheduling activities directly to Transportation Management to incorporate additional transportation planning constraints and operational considerations.
To learn more about how SAP TM scheduling can improve delivery commitment accuracy in SAP S/4HANA, connect with an ArchLynk expert.