SAP Basic Shipping case study on freight charge calculation

A greenfield implementation of SAP S/4HANA took place at our western Hungarian partner with a manufacturing profile. Due to their smaller yard size – around 50-60 trucks enter a day – instead of the advanced SAP TM (Transportation Management), its simplified version, Basic Shipping was chosen. Since it’s part of the standard S/4HANA package, licensing issues were also averted.

The company doesn’t have its own fleet of vehicles to carry out the carriage tasks but outsources it entirely to external partners. Therefore, one of the key functionalities of their transportation management system – besides the planning of the routes and contents of the trucks – is the charge calculation and that is the main focus of this paper.

Business process summary

The process is integrated with the core S/4HANA and the embedded EWM system.

1. source: Lauterbach, Sauer, Gottlieb, Sürie, Benz (2019). Transportation Management with SAP. Boston, MA: SAP Press.

The process starts with the creation of a sales or purchase order in the main ERP system. From that the out- or inbound delivery is produced. In the case of import the EWM system is never integrated with the TM system, however, for export the main process is an integrated scenario. After the creation of the delivery if it’s relevant for TM a freight unit is created automatically and if relevant for EWM the delivery is distributed.

Because of the packaging process and the profile of the finished products it is not possible to standardize their size required for delivery, so the first step of the planning process is the determination of the loading meter by the responsible business people. This task is carried out outside the SAP system; however, the necessary information is available in a custom, editable report where it is possible to save the results.

Based on the given size data, the loading or unloading locations and the dates of the freight units a freight order can be created. A freight order symbolizes a truck and it can contain several freight units. After the shipping instruction is sent to the carrier a transport unit is created in the EWM system based on the freight order. The system finds the previously distributed deliveries and assigns them to a TU.

The link between EWM and TM

EWM (Extended Warehouse Management) is the module of SAP made for the management of more complex warehouses where it is possible to manage every material from the moment they enter the warehouse until they leave.

Originally, it integrates with TM via a web service, an XML message is generated when the freight order is transferred from TM and then another when it comes back. Apart from these two occasions there is no communication between the two systems, which means that any change made in one system won’t be available in the other.

However, with the 2020 version of SAP came a simplified way where the two modules integrate seamlessly, without using the transportation unit in EWM.

The picking, packing, staging and then the loading and goods issue all happen in the EWM system then the process comes back to the TM system after the truck leaves the plant. If the delivery is not relevant for EWM the arrival and the loading or unloading is handled within the TM system with the changing of the relevant statuses.

The transportation-based actions such as the arrival to a loading point is managed within the TM system. After the truck leaves the last destination the charge calculation can be started.

The cost is based on the loading meters and the zone of the destinations – a zone can contain several locations, and a location is equivalent to a business partner. It is important for the calculation to be accurate as for the more important carriers the invoicing is based on a self-billing process.

Under the hood: BOPF

The SAP Transportation Management module, like most SCM (Supply Chain Management) products (e.g., APO, EWM), is based on SAP BOPF (Business Object Processing Framework) technology. Every previously mentioned TM document has its corresponding business object.

BOPF is an object-oriented (OO) ABAP framework, a general package of services and functions that focuses on a specific business object, in our case, for example, a freight order and related operations. According to SAP’s original goals, this can speed up and standardize development.

Customer requirements

We bumped into several customer specifics needs where we had to think outside the box to find solutions that were satisfactory enough without straying too far from the standard process.

Hub and spoke charge calculation

The first problem we encountered was caused by the way how the locations were managed.

According to the first setup, besides the loading meter, the charge was calculated based on both the starting and the destination zones. However, this couldn’t work for two reasons. One of the problems was that it would have meant that from each zone we would need to create a transport lane to every other zone and with almost a thousand of them it seemed like a vast amount of surplus work.

The other reason was that during our implementation new contracts were signed with the carriers for the next few years where the cost would be calculated as though their plant would be the starting location for each stage (or destination location in case of imports). For example, suppose that there is a freight order with three stages, one from our plant (hub) to location A, then from location A to location B and finally from location B to location C. For the planning we need these stages, however, for the charge calculation we look at the transportation as if for every destination location the starting location would be our plant, so the three stages will be our plant to location A, our plant to location B and our plant to location C.

The solution for this was to remove the starting location (in case of import deliveries the destination location) from the charge calculation matrix, meaning that from the three variables it was reduced to two. This way the route planning wasn’t changed, the charge calculation produced accurate costs meaning the self-billing process could work properly. However, the cost distribution became incorrect as the product which goes to the last location is also travelling in all previous locations where the given cost is divided among every product that goes through there. Since this makes a negligible difference, the customer accepted the solution.

Loading meter

Another problem was caused by the method how the loading meters were handled. First, the total length is calculated for each separate freight unit based on the packing instructions from the customers so that the building of a freight order is possible. After the freight order is finished and it is clear which freight unit will travel with the given truck the length is redetermined as it is possible that some products from different deliveries can be stacked on each other.

The packing happens in the EWM system and after the freight order is available in TM once more the charge calculation can be started based on the loading meter.

Besides the fact that the standard field is not exactly loading meter but a general field for length, it had several problems:

• During the standard process its value is automatically determined from the material master and cannot be changed manually. However, due to the nature of the finished products and the customer specific needs it is not possible to set a fixed value.
• This field can be determined for each item separately, however, due to the possibility of stacking the products on each other a header level value was required.
• After the packing is finished in the EWM system the whole item structure is reconstructed from FU > product to FU > package > product. It is possible that an item line had ten pieces of a given product which had a length of three meters altogether, however, after these were packed into ten separate handling units in EWM they come back to TM in different item lines while each of them keeps the original length, meaning from the total of three meters the length became ten times three meters.

To overcome these issues, we first tried to modify the standard process, however, it became so complicated that we decided to go in another direction. We found that it is a much more ideal solution to create a new, custom field instead of the standard length with properties tailored to our needs.

Using the capabilities of the BOPF structure and the Fiori Floorplan Manager with the appropriate FBI views it was possible to assign a new custom field to the freight unit. This new value was adjusted to the specific needs,; therefore, it was placed on the header level of the freight unit and as a result of its independence it is editable manually and doesn’t fall to pieces after the EWM processing.

A customizable user interface: FPM and FBI

SAP Transportation Management uses the Floor Plan Manager (FPM) to realize its User Interfaces. FPM is a Web Dynpro ABAP application that provides a framework for developing new Web Dynpro ABAP application interfaces consistent with the SAP UI guidelines. Using FPM, UIs can be configured without coding.

The Floor Plan Manager BOPF Integration (FBI) is used in SAP Transportation Management to integrate FPM with the BOPF-based Business Objects. FBI provides generic FPM application feeder classes together with the relevant application configuration that allows consuming services of Business Objects modeled in BOPF.

Taking advantage of the possibilities granted by the BOPF structure we were able to make a mass maintenance report where – besides other attributes – the loading meter could be determined for multiple documents at the same time so that it’s not necessary to open each document one by one. This table structured query is based on a POWL list what makes it highly customizable with both general settings that can be simply adjusted from the back-end (such as the character length and data types of the fields) and user specific modifications (like personalized layouts) which can be done on the user interface by each individual for themselves.

The modern way of reporting: POWL

The predecessor of the POWL (Personal Object Worklist) was the Universal Worklist (UWL) which was used as a generic worklist, however, due to the lack of user-level configuration SAP made the choice to replace it with the Personal Object Worklist which is embedded in a web-design environment.

It enables users to manage their work by bringing together object assignments from different systems, which themselves are not a part of the workflow (including alerts, knowledge management (KM) notifications, and collaboration tasks).

There is one need that is currently pending due to the limited time left before the rapidly approaching go-live date. Currently, the value of the loading meter is not integrated with the charge calculation, thus it is only possible to maintain it through manual determination, however, our aim after the launch is a process where this is given by the system automatically.

It was also important that we can send out the loading meters to our carriers. It was possible to customize the forms that are printed from the TM system so the cumulated length values for each location is displayed on the shipping instruction which is sent out by email during the planning process controlled by SAP’s PPF technology.

A simpler output management: PPF

TM uses PPF (Post Processing Framework) for the printing and sending of forms (e.g., CMR, Shipping Instruction). It is used to execute program logic that is considered a follow-up action to a certain business process step.
It is only possible to send outputs from PPF which already exist, meaning the necessary steps during the planning were made, thus all data is available. This prevents the user to send out documents preliminary, while after sending it, it is removed from the active database, meaning – without deliberate manual intervention – it is not possible to send a document twice.

Despite the limits of the basic shipping scenario of the TM module – compared to the advanced version – it is still possible to configure it in a way to fulfil very specific customer needs. Using the capabilities of the modern SAP solutions, such as the PPF technology or the BOPF structure, adjusting unique requests into standard processes can be done in a standardized and a more accessible way. Taking advantage of these we were able to provide a highly tailored system for a very special charge calculation process with barely any sacrifices.

Ending thoughts about the SAP Basic Shipping freight charge calculation for a hub and spoke network

It is possible to cover the charge calculation needs of a company with such size and complexity within the Basic Shipping scenario which is available in the S/4HANA natively with minimal custom development.

Its further advantage is that it supports license optimization, therefore in the first round it is recommended to investigate this solution and only then move on to the SAP advanced TM (Transportation Management) product which requires a separate license.

Are you facing a freight charge calculation or a similar challenge in S/4HANA? Contact us now and request a consultation with our experts!

Discover our other posts in this category!

Discover our latest posts!

Do you have a question regarding our services?

Contact Onespire's experts!