Incoterms (international commercial terms) are a crucial part of information in transportation logistics.
This is because they define the spot in the transportation part of the supply chain where, for one party (e.g. a shipper), the duty to plan transportation and pay the cost ends, and for the other party (e.g. a customer), the duty to plan transportation and pay the cost begins.
In SAP Transportation Management (SAP TM), the applicability of incoterms in the transportation planning process was very easy, from a setup and transactional data point of view, prior to SAP S/4HANA 2022.
Here’s how it broke down: Two main spots for setup must be considered.
As the incoterm location in the business partner master data record is a text field, a mapping must be done via “Assign location to incoterm location” to tell the system which location ID must get mapped to the location entered in the text field. As a result you will have a freight unit where the incoterm and incoterm location are propagated. Based on this information, the stage split can be done and the planning relevance for each stage can be determined, once this was defined in the logistics integration profile.
SAP recognized that this concept had some issues and must be evolved. The main issues to fix were the following:
With the delivery of SAP S/4HANA 2022, SAP updated the incoterm functionality to remedy these two issues. We’ll see how in the rest of this post.
Incoterms are updated on a 10-year frequency. Under the following customizing path, it is possible to define a combination of incoterm 1 and incoterm 2 and the location type for both. This combination must be assigned to an incoterm version. You can do this by following this menu path: Sales and Distribution > Master Data > Business Partners > Customers > Billing Document > Incoterms > Map incoterms to Version.
This post is focusing on incoterm version in the context of incoterm 1 and incoterm 2 location. We will focus on this entry: “Version 2020 / CPT / Location2 mandatory – Optional –” as the incoterm 2 feature is relevant only in the context of c-group incoterms.
Use this menu path: Sales and Distribution > Master Data > Business Partners > Customers > Billing Document > Incoterms > Assign Incoterms Location Types to Incoterms. Here it´s required to tell the system which location type (e. g. port of destination/departure) the respective incoterm location is supposed to be.
The reason for different incoterm versions is that incoterms might get changed. For instance, the 2010 version had the DAT (delivered at terminal) incoterm, which was replaced by DPU (delivery at place unloaded).
Once you have defined incoterm locations 1 and 2, you can maintain this data at the sales organization level in the business partner master data record.
Once this data is in place, it will get automatically populated into the sales order once the respective business partner is assigned as the sold-to party.
In the figure below, you’ll see that the following fields were populated:
Accordingly, the freight unit would look like the following.
On the freight unit general data tab, the incoterm and incoterm locations are propagated from the sales order.
The logistics integration profile has the following:
As we’re working with a multi-modal ocean freight scenario where just one port (Port Hamburg) is relevant, we apply a default route, which does split the freight unit into three stages (pre-, main, and on-carriage).
Here we see that based on the described setup, customer-specific incoterm information is propagated to the freight unit and the planning relevance for the stages is determined as well. These are all based on incoterm location 1 and incoterm code information. By having incoterm location 2, sellers and buyers are made aware just where the risk for goods will be shifted from seller to buyer.
With this feature delivered in SAP S/4HANA 2022, users of SAP Transportation Management can now cover the two issues of error-prone text fields and the necessity of second locations.