Streamlining Incoterm Management in SAP TM: What's New?

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.

1. You define your incoterms: SPRO > Sales & Distribution > Master Data > Business Partners > Customers > Billing Document > Incoterms > Define Incoterms.
2. T-code BP > BP-Role “Customer SD” > Sales and Distribution > Billing. At the sales organization level, the incoterm and incoterm location can be maintained.

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:

1. A text field is way too prone to errors. If the user makes a typo in the sales order incoterm field, the location ID won´t be determined in the freight unit and the stage building fails. Subsequently, the entire planning process will be affected.
2. For ocean freight, special incoterm code groups are applicable: the c-group (CFR, CIF, CPT, CIP, FH). Here the special thing is that if we have, for example, transport from Port Hamburg to Port Shanghai and CFR is agreed, the shipper would plan and pay for the transport until Port Shanghai, but the risk for the goods would go over to the customer. Once at Port Hamburg, the goods are handed over to the carrier. Meaning a second location is required in the system.

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:

• Incoterm Version: 2020
• Incoterms: CPT
• Incoterm Location1 ID: PORT_SHN (Port of Destination)
• Incoterm Location 1: Address of the incoterm location
• Incoterm Location2 ID: PORT_HAM (Port of Departure)
• Incoterm Location 2: Address of the incoterm location

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:

• Stage Building Variant: “A – Advanced” (only then are both incoterm locations getting propagated to the freight unit)
• Incoterm Loc. Stage Bldng type: “Two Active Stages – Type 1” (without an incoterm, all determined stages would be planning-relevant with this setting)
• Incoterm is CPT
• Incoterm location 1 is: Port Shanghai
• Incoterm location 2 is: Port Hamburg

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.