The scenario

Imagine the following, common transportation scenario consisting of 4 locations and 3 legs:

Locations A and D are the shipping and destination warehouses respectively, whereas B and C are ports of loading and unloading respectively.

• Leg 1 is the truck transportation from the warehouse to the port of loading.
• Leg 2 is the ocean freight.
• Leg 3 is again the truck transportation for the port of unloading ot the destination warehouse.

The incoterm is FOB (free on board) Port B. It means that the seller covers shipment cost and insurance up to loading at Port B. After loading, the goods are owned by the buyer and the buyer covers the rest of the costs.

On top of that, the seller has a very good rates and service from the ocean freight company and agrees to plan and pay the ocean part of the shipment. Still, as defined by the FOB incoterm, the buyer assumes the ownership and is responsible for the insurance starting from the port of loading, Location B.

To reap all the benefits of early planning, we are working with sales order-based TM, i.e. a shipment is planned right after a sales order is created and an outbound delivery is driven by the transportation scheduling.

That is a real life scenario – see the following discussion on LinkedIn:  Need recommendation for a Rail Scenario. (LinkedIn group SAP Transportation Management membership is required to view the linked post. The group is of Listed type, hence only the members can view the content.)

SAP TM implementation

How could that be modelled in SAP TM? Location B could be implemented as an incoterm location and a location C as handover location, if handover location was supported by S/4HANA. Unfortunately it is not – see the note 2677594 – Entering Handover Date for confirmed quantities in MM document leads to wrong error message

Instead, the scenario can be modelled with SAP TM default route. Here, the legs 1 and 2 can be defined as planned ones and the leg 3 as a statistical, not planned one. It works perfectly up to the point of delivery creation.

Hyperspeed – integration singularity

The planning goes perfectly, unless the freight order dates change after an outbound delivery is created which is a case more often than never.

Let’s put some scheduling perspective into the scenario (for the sake of simplicity I don’t consider any holidays or weekends):

• Leg 1 takes 1 day
• Leg 2 takes 8 days
• Leg 3 takes 1 day

In total the journey takes 10 days.

Now, the requested delivery date as defined in the sales order is 20.01. So by backward scheduling, the following dates are calculated:

I am again simplifying here – there are not constraints, restrictions or PUDL windows.

Notice that the last leg is statistical, so SAP TM does not assume responsibility for the date at Location D. It is taken from the sales order schedule line. Also, the delivery gets transportation planning status “partially planned”.

That approach seems logical and it has been explained in detail by the note 3076868 – Delivery document shipment dates are not in sync with TM Freight Order execution dates.

The date at Location A is also the delivery picking date.

Surprisingly this logic has daring consequences! We are living in turbulent times so plans do change. Say that our shipment is delayed by a month and we update the date at Location A to 09.02 – TM promptly recalculates all the dates but the last one. Remember – the last stage is statistical and TM does not care about the date at Location D. Now the delivery integration goes haywire and we end up with the dates like this:

The delivery date is still 20.01, which is way before the picking date of 09.02! In other words the delivery will get to the buyer before it is even picked in the warehouse!!! Star Trek Starship Enterprise would not go faster than that.

There is no warning here, no message, no log, nothing – as if going back in time is common. I have discussed the problem at length with SAP Support. It has been confirmed and designated as works as designed.

Honestly, I cannot understand why SAP is so indulgent about such mind blowing inconsistencies – whatever logic, whatever design, a delivery cannot get to its destination before it is even picked and packed.

Resolution

The resolution is to implement a custom enhancement with the following logic:

1. Get the end date of the last planned leg.
2. Summarize the durations of all statistical legs (there might be more of them).
3. Add the duration from step 2 to the date from step 1 and use it as the delivery date.

The logic is very straightforward and I wish it made its way to SAP standard.

Depending on S/4HANA release the enhancement can be implemented either with the /SCMTMS/DLVP_CHG_DATA or /SCMTMS/BADI_LI_TM_LE BAdI – see the note 3072722 – /SCMTMS/DLVP_CHG_DATA BAdI usage in S/4HANA 2020 for details.

Credits

icons: Flaticon.com