Product Information
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.
That means:
- 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!
Best regards,
Michael
Thanks for Sharing.
I am still wondering why the Incoterm is not part of the Transportation-Relevance in the Logistics Integration.
Hello Jens,
Thanks for your comment. What exactly do you mean by the transport-relevance in logistics integration? Which setting are you missing there?
Best regards,
Michael
Hello Michael,
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.
Hello Jens,
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!
Best regards,
Michael
Hello Michael,
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?
Best regards
Stefan
Hello Stefan,
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.
Best regards,
Michael
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.
Thanks
Karthick
Hello Karthick,
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.
Best regards,
Michael
Thanks for your response. Much appreciated.
Thanks
karthick
Hello Michael,
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.
Thank you.
Hello Toshihiro,
Basically, I would see no reason why this is not possible. I think is quite a common case you're mentioning.
Best regards,
Michael
Hello Michael,
Thanks a lot for the detailed documentation on this topic.
Couple for queries 🙂
Q1)
We have tried the advanced stage building option with two incoterm location, however its not working as expected, system is creating only one active stage from Incoterm location to Destination location, checked this in both inbound(PO) and outbound (SO) scenario, outcome is same- Incoterm location 2 is not getting recognized, is there any specific settings that needs to be checked
Q2)
We have similar requirement, below
Example: Supplier Location -> Port of Loading -> Port of Destination->Receiving Plant
Expectation is 3 stages will be created by the system,
Stage 1 --> Supplier location to Port of loading is relevant for planning (this will be done by company's US purchase org.)
Stage 2--> Port of Loading to Port of Destination- not relevant for planning
Stage 3--> Port of Destination to Receiving plant - relevant for planning (this will be done by company's CA purchase org)
through incoterm based stage building how to achieve this?
In the Sales Order/purchase order, Ship to party/supplier and shipping point/receiving point will be there, how system will determine the port of loading and port of destination location in the FU stages?
Is it possible, that Inco term location 1 and Location 2 can be treated as Port of loading and port of destination for the stage building. - we tried this, however this not working, when two incoterm location 1 & 2 are maintained and advanced stage building is enabled, still system is creating only one stage in the FU from Incoterm location 1 to Receiving plant.
Thanks a lot for your post!!
Regards
Selva
Hello Selva,
Regarding Q1, it might dependent on the incoterm 2 you use. Incoterm Location 2 only comes into play with C-Clauses, when the risk responsibility is transferred at a different location than planning/cost responsibility, e.g. in an intercompany sales scenario.
But this is only one possible cause. There are several settings involved so this needs deeper analöysis by matching your scenario with the settings.
Regarding Q2, I'm not quite sure if incoterm locations are the right means to cover this. I assume the transport between the ports is organized by any ocean carrier / LSP. I might be wrong but I would rather expect that the route with the two ports is derived during transport planning e.g. with a default route and a schedule or by adding intermediate stops or by the optimizer etc. And the freight unit between the two stops is then a matter of external planning by the ocean carrier on an ocean booking.
Means..if I get it right you want to use the incoterms more for the transfer of risk and responsibility between the purchasing orgs and the ocean carrier, rather then with the customer. But may be I just misunderstood the scenario. Anyway...I never heard of this usage of incoterm, but may be someone else reading this did, would be interesting to know!
Best regards,
Michael
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!
tks
Eduardo Chagas
Hi Eduardo,
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.
Best regards,
Michael
I'm doing well tks! 🙂
I mean BRF+ condition as we have for the stage profile.
best regards
Eduardo
Hi Eduardo,
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.
Best regards,
Michael
Got your point. I agree, it is okay in that case.
Best regards
Eduardo
Hello Michael, Is it possible to down port this functionality in S/4HANA 2020 version?
Hello Prashant,
Unfortunately I have to tell you that no such downport is planned.
Best regards,
Michael
Hey Michael,
Hope you're doing well. This article has been very helpful! Do you have any idea as to why the "IncLoc1 ID" field is not available in my purchase order?I can see from the screenshot above that it's available in the SO so curious as to why it's not a field in the PO.
Thanks for your insight in advance.
Thanks
Jacob
Hi Jacob,
Thanks for the feedback!
Please check whether your PO is TM relevant. Only then, the field is available.
Best regards,
Michael