Improved Incoterm Handling in SAP TM
Dear friends of SAP TM,
We already covered here the topic of incoterm locations in documents of SD/LE/MM and how they are mapped to ‘real’ location master data objects in SAP TM. And furthermore we talked about the freight unit stage building depending on the incoterm location in this blog post.
Now it’s time to give an update as with release SAP S/4HANA oP2022 some new features have been released:
- SAP TM is now able to consider the incoterm version, including those clauses that include incoterm location 2.
- Thereby, in documents of SD/LE/MM now ‘real’ location master data objects can be maintained replacing the ‘free text’ with its mapping to ‘real’ locations.
Let’s start with some background…most of you will already be familiar with incoterms and their semantics. Hereby it’s important to mention that incoterms have evolved in different versions (2000, 2010, 2020) to cover logistic processes more accurate. Means, clauses have been added and removed. And we now also have clauses where a second incoterm location can be maintained. With that, it can be differentiated better where cost and risk transfer actually happen during a transport.
New features of improved incoterm handling in SAP TM
SAP TM has now been enhanced with the capability to consider the incoterm version and the incoterm location 2 from a predecessor document in SD/LE/MM, where this information can be maintained. And considering the incoterm location 2, an additional setting in the logistics integration profile is now available regarding stage building.
As part of this improved incoterm handling, documents of SD/LE/MM are now enabled to have incoterm locations as ‘real’ location master data objects. So in logistics integration, the error prone mapping between a ‘free text’ and the location is not necessary anymore.
Enhancement of logistics integration profile
But let us get into details…starting with the customizing of the logistics integration profile:
Here, the existing settings have been moved to a section called ‘Static Stage Building’.
What is new is the option for ‘Advanced Stage Building’, which means the following:
- Incoterm location 2 is considered here (and only here, not in the Static Stage Building)
- It can be decided whether only planning-relevant stages should be built.
Enhancement in incoterm handling
To show the enhancements, we make an example with the following scenario:
The supplier, where the customer purchases his goods, has a delivering company which differs from the selling company, meaning we have a scenario of intercompany sales. This makes things a bit more complex, as now incoterm locations 1 and 2 come into play for the external and internal transfer of costs and risk. And our supplier has incoterm FAS (Free Alongside Ship) with incoterm location 1 of MHA_UNLOAD for the handling within the enterprise (‘internal incoterm’)..
With that, we want to create a sales order with incoterm CIF (Costs, insurance & freight) for the arrangement between supplier and customer (‘external incoterm’). Furthermore, we have incoterm location 1 of MHA_PORT and incoterm location 2 of MHA_UNLOAD in our sales order.
- The delivering company carries the cost from the source location to loading / unloading point MHA_UNLOAD.
- The selling company carries the cost from the loading / unloading point MHA_UNLOAD to the port of discharge MHA_PORT.
- At the port of discharge MHA_PORT the cost and risk is transferred to the customer
So we create the following sales order:
Here you see, that additional fields regarding incoterm handling have been implemented. Especially, incoterm locations 1 and 2 are now location master data objects which can also be selected with a respective search help.
This means, that during logistics integration no mapping between free text and location is considered anymore but the location is just taken over to the TM freight unit. This obviously makes life much easier because I’m sure many of you (and myself…) struggled here with typos or case-sensitive location names.
Furthermore, the locations are together with the other information about incoterms and the setting from the logistics integration profile passed to the stage building algorithm, resulting in the following freight unit:
Here you see, that the stages have been build according to the maintained incoterm locations:
- Stage 1 represents the transport until the internal transfer of cost from delivering to selling company
- Stage 2 represents the transport until the external transfer of cost to the customer
So, the accurate consideration of incoterms in regards to incoterm version, incoterm locations 1 and 2 is surely another big step for SAP TM, enhancing the planning capabilities significantly.
Those enhancements are available with release SAP S/4HANA oP2022.
I appreciate any comment or question!
Thanks for Sharing.
I am still wondering why the Incoterm is not part of the Transportation-Relevance in the Logistics Integration.
Thanks for your comment. What exactly do you mean by the transport-relevance in logistics integration? Which setting are you missing there?
I was thinking of the (IMG) -> Integration with other SAP COmponents -> Transportation Management -> logistics Integration -> Define Transportation-Relevance of (e.g.) Delivery Documents
Here you only have the Ship. Point, Del. Type and Shp. Condition as identifier.
For sure there is always the standard BAdI to enhance, but maybe two examples where I faced issues:
1.) Scenario Outbound with EWM, the Incoterm FCA is not relevant for Transportation planning, but Shipping Point, Del. Type and Shp. Condition is the same for DDP (relevant for Planning) and FCA (not relevant).
As soon as the delivery is transportation relevant, EWM expects a TU created from TM.
[As in this case outbound deliveries were created early, FUBR and VSR helped to set it up, but with a lot of configurations and the assumption, that every delivery is one FU is one FO]
2.) Scenario Inbound with YL and EWM, Inb. Deliveries with Incoterm DDP should/can not be planned in TM as it is unknown which deliveries/purchase orders will be combined on one truck. YL should create the TU in EWM and do the linkage to the Inbound Delivery Order, but is not allowed to do so as the Status in the IDO only allows Linkage between the IDO and a TU created from TM as the inbound delivery was relevant for Transportation planning.
Maybe my topic wander from the main topic of this blog, but I just wanted to mention that Incoterm could be a good selection criteria for the transportation relevancy.
Ok, thanks for explaining! I think now I got your point!
I will discuss that with my colleagues, but just some thoughts....adding the incoterm on that level would mean that it has effect on every delivery with that delivery type / shipping point / ship. cond. Couldn't it be that you have also scenarios without EWM with such deliveries where you do want transport planning? And where the incoterm is considered then properly in stage building? Or would you then have e.g. another delivery type?
And this might also be relevant 'only' in EWM scenarios, whereas this is without a doubt a very important scenario! But it could be a question whether scenario-specific settings should be added on that level. Coming back to me previous thought, if you have EWM and non-EWM scenarios, you're definitely forced to use e.g. different delivery types.
Just loud thinking...as said, I will feed my colleagues with your valuable input!
Thanks for sharing this valuable insight. One question please: Looking at a sales order in the brand new S/4HANA 2022, there are no values shown when I use the search help for incoterm location1 or location2. Same issue for those fields in the business partner.
Do I need to activate something for that or what kind of location master data can be selected in the sales order for incoterm1 & 2?
That sounds strange...to my knowledge there's nothing that needs to be activated and all location master data objects as e.g. visible in transaction /SCMTMS/LOC3 should be selectable. At least if you input them directly it should work.
Thank you Michael. Checking again, it works fine - one just need to select the location in the "location ID" field and not in the location itself. Clicking in the latter one shows a F4 symbol thats why I was misleading.
You're right, just checked it by myself 🙂
Nice to hear that it works fine now!
Thanks Michael for the interesting information.
One question- When you say "incoterm locations 1 and 2 are now location master data objects" does this mean all locations are available in the Sales order F4 help in standard? you also mentioned that there is no need to do the mapping. So just wondering what locations are available for the sales order.
Yes, all location master data objects can be provided, e.g. all you can display in transaction /SCMTMS/LOC3 and have been created in various ways.
Thanks for your response. Much appreciated.
Thanks for clear explanation on this.
When we have more than 2 stages, is that also possible through incoterm?
Example: Shipping Point -> Port of Loading -> Port of Destination->Ship to Party
From Port of Destination, Ship to Party will take care of the goods.
i.e Port of Destination to Ship to Party, not relevant for planning.
Basically, I would see no reason why this is not possible. I think is quite a common case you're mentioning.
Hello Michael! Hope you are doing well.
In my opinion... It would be much better to have a condition for that! And probably easier to be implement by SAP.
I'm assuming that the free text is still available because the incoterm locations are not always the same!
Thanks, I'm fine! Hope you're doing well too! 🙂
What condition do you mean exactly? As far as I know you can still enter the free text in SD/LE/MM but it's already there mapped to a 'real' location so we receive always the location in TM integration. If this is true (what I assume) the behavior didn't change for a user and entering directly the 'real' location is a feature on top.
I'm doing well tks! 🙂
I mean BRF+ condition as we have for the stage profile.
But then don't you still have the issue with the error prone input of the free text? This is what we wanted to get rid of.
Got your point. I agree, it is okay in that case.
Hello Michael, Is it possible to down port this functionality in S/4HANA 2020 version?
Unfortunately I have to tell you that no such downport is planned.