In the past some of our customers might initially have been confused by the result of our planning due to the way our system interprets the pickup&delivery windows during optimization/scheduling. In some cases this is based on a misconception that the scheduling tries to fit the departure/arrival time in the corresponding freight unit windows. What it actually tries to fit is the loading/unloading times. Per default on an outbound stop the system will try to fit the loading start, on inbound stops the unloading end.
For those who have not yet worked to much with times in TM, just a quick introduction on the most relevant ones for this blog below. All of them can be found on the BO Node TOR~Stop.
Input for scheduling:
Output from Scheduling:
But let's take a scenario: We have a requested delivery to a customer at 3pm. Based on our contract we are obliged to deliver exactly at 3pm. (This means freight unit acceptable start&end will both be at 3pm for the freight unit inbound stop) In our system we have maintained a loading and unloading time of 2hours each and the travel time will be calculated with 3 hours. For simplicity there are no constraints for when the goods can be picked up from our warehouse.
If we now do a simple VSR run the result will come back as ilustrated below.
For some customers (from different industries) this result is unexpected as according to their business logic a delivery time at 3pm means that the truck actually has to arrive at 3pm.
For those of you, who belong to the group confused by this behavior: I believe the rationality behind the default on inbound, is that the cargo/delivery is handed over when it is unloaded fully from the truck not when the truck arrives at the customer location.
Our customer is actually expecting his scheduling result to look as below:
To support this requirement, with S4HANA 2020, we enhanced our Pickup&Delivery window condition with a new result parameter "Calculation Base" to controll how the system should actually interpret the window during scheduling, if either start or end of (un-)loading should be considered. If initial the system will apply the default as described above, otherwise the values E and S can be set to tell the system how to behave.
The integration in the PUDL window condition offers a nice flexibility to for example treat customer stops differently as your own stops during inbound etc.
For those who have not yet worked to much with times in TM, just a quick introduction on the most relevant ones for this blog below. All of them can be found on the BO Node TOR~Stop.
Input for scheduling:
- ACC_START/END: Hard Constraint for planning that must not be violated. E.g. determined by Material Availbility Date on Sales Order
- REQ_START/END: Soft Constaint for planning that can be violated but lead to penalty cost during Optimization (if set-up).
Output from Scheduling:
- PLAN_TRANS_TIME: Planned departure Date&Time for Outbound; planned arrival Date&Time for Inbound
- ASSGN_START/END: Planned Loading Start&End for Outbound; planned Unloading Start&End for Inbound
But let's take a scenario: We have a requested delivery to a customer at 3pm. Based on our contract we are obliged to deliver exactly at 3pm. (This means freight unit acceptable start&end will both be at 3pm for the freight unit inbound stop) In our system we have maintained a loading and unloading time of 2hours each and the travel time will be calculated with 3 hours. For simplicity there are no constraints for when the goods can be picked up from our warehouse.
If we now do a simple VSR run the result will come back as ilustrated below.
Default Scheduling Behavior
For some customers (from different industries) this result is unexpected as according to their business logic a delivery time at 3pm means that the truck actually has to arrive at 3pm.
For those of you, who belong to the group confused by this behavior: I believe the rationality behind the default on inbound, is that the cargo/delivery is handed over when it is unloaded fully from the truck not when the truck arrives at the customer location.
Our customer is actually expecting his scheduling result to look as below:
Desired Scheduling Result
To support this requirement, with S4HANA 2020, we enhanced our Pickup&Delivery window condition with a new result parameter "Calculation Base" to controll how the system should actually interpret the window during scheduling, if either start or end of (un-)loading should be considered. If initial the system will apply the default as described above, otherwise the values E and S can be set to tell the system how to behave.
Pickup and Delivery Window Condition
The integration in the PUDL window condition offers a nice flexibility to for example treat customer stops differently as your own stops during inbound etc.
- SAP Managed Tags:
4 Comments
| User | Count |
|---|---|
| 10 | |
| 8 | |
| 5 | |
| 4 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 2 |
