Skip to Content
Personal Insights

Capability of Normalized quantity in embedded Transportation Management ( TM ) in S/4HANA 1909 Release

Effective utilization of truck capacity is a challenge and it gets very complicated if there are different kinds of products with different requirements of packaging. Transportation industry uses the concept of Normalized quantity or Loading meters to harmonize diverse packaging materials to a uniform or single Unit of Measurement (UoM) for efficient planning and optimization of loading space.

Normalized quantity indicates the consumption of ‘Loading space’ for transportation resource like Truck. A shipper generally orders the truck from its freight forwarder by informing the ‘Normalized quantity’ or ‘Loading meters’ . Calculation of ‘Loading meters’ is also quite complex and is generally calculated with length , width , number of packages along with stacking factor. And this calculation gets even more complicated when it is combined with the orientation of package and mixed pallets etc.

SAP has released the functionality of Normalized quantity (NLQ) in embedded Transportation management ( TM ) with S/4HANA 1909 release and in standalone TM with TM 9.6 release.  Marcus Zahn (of SAP Development) has described the features of Normalized quantity in his blog  in link

My present blog is to describe some simple use cases with ‘Normalized quantity’ and ‘Additional normalized quantity’ to showcase their capability in embedded TM in S/4HANA 1909 release.

Normalized quantity in Freight unit (from delivery) and Freight order

Let us consider a simple scenario as depicted in below image. 5 pieces of product FG09 are to be packed in a pallet or packing box PB_PAL_01 and 4 pieces of product FG10 in a pallet or packing box PB_PAL_02.  Dimension of Pallet  PB_PAL_01 is double of PB_PAL_02. Unit of measurement (UoM) for Normalized quantity has been defined as NP1 (in this blog). Now the pallet  PB_PAL_01 is being considered (set in system) as 1 NP1 and PB_PAL_02 as 0.5 NP1. A Truck can be loaded with 20 NP1 and an additional normalized quantity UoM has been defined as PAN for the capacity of the truck (i.e 1 PAN = 20 NP1 has been set in the system).

Now, let us create a sales order and a delivery (image 1) with 8 pc of FG10 and 20 pc of FG09. Note that the delivery has 2 Freight units (image 2) indicating

  • 2 pallets of PB_PAL_02 (each with 0.5 NP1) combining normalized quantity to 1 NP1 (image 3)
  • 4 pallets of PB_PAL_01 (each with 1 NP1) combining normalized quantity to 4 NP1 (image 4)

which will help the Transport planner with the information of consumed capacity for truck i.e 5 NP1 or 25% of total capacity of 20 NP1 for the truck.

If a freight order is created combining these 2 freight units, then the freight order shows that the consumed capacity with these 2 freight units is 25% of the truck as shown in below image. So, it helps the transport planner to plan for the remaining normalized quantity of 15 NP1 to optimize the freight cost.

Normalized quantity in Freight unit from sales order

Transportation planning is done at sales order level if the lead time to procure (or plan) for transport (or truck) is high. Freight units are created from sales order in those scenarios. Order management team can then get the requirement for transport capacity in normalized quantity which is essential in many of the business scenarios. A sales order is created with the same materials & quantity and the below image shows the combined normalized quantity for 2 freight units as 5 NP1 i.e 25% of truck capacity.

Note that this functionality of normalized quantity is available only for road transport as of S/4HANA 1909 release and its design is based on Package building functionality as described in my blog This blog considers simple scenarios to describe the concept of normalized quantity in transportation scenarios in embedded TM in S/4HANA. However, it can also be modelled for more real , complex scenarios and also for charge calculation.

This blog is based on my personal tests and observations. Will appreciate your feedback / comments.


You must be Logged on to comment or reply to a post.
  • Hi Mrinal, thank you for sharing this. It shows well how it works and the pictures and screenshots are really helpful. I have looked at normalized quantity as standard functionality as I had a customer who has several types of pallets with different material conversions which needed to be converted into footprints, so that the capacity would be calculated. In truck transportation, especially for packed products, companies think in pallets and loading meter, not only in weight or volume. Since our customer had 4 pallet types P12, p24, p18 and p16, we needed different units of measure with the same name in the material master and convert these as normlaized pallet qty. We could not use the quantity field as pallets (PAL) because we needed the quantity as well on the fu. we wanted to see only number of pallets and number of footprints. Number of pallets was a type independent figure (P12 could be stacked, P24 not and so we needed the double of p12) . Normalized qty could not be used as 8 units fitted on type p12, but 16 units on p24.  In addition, we needed footprint which would indicate how much space (on the floor) is used in the truck. the conversion to footprint was straight forward. At the end, we ended up showing (normalized) pallet qty and footprint quantity on the FU. we could not have used standard normalized qty because the conversion for pallets also depended whether or not a customer allowed mixed pallets or not. Also, each pallet type had a different conversion to the normalized qty. in your example, you show packages. We started looking at the package builder in the TM Freight unit which has quite extensive functionality to build packages. Unfortunately, it is not possible to change the proposal from the package builder when we pick the real pallets in ewm. Therefore, we ended up pre-calculating the pallets and footprints with our own logic on the freight unit (Custom freight unit building process controller strategy) and freight order and show the fields and the related utilization in the cockpit. This way, the estimated pallet quantity is visible for the transport planner and via a picking list the warehouse can see how many pallets they can build for a given order. But, they can pack differently if they want. In practice, packers find all kind of ways to pack smartly. Not being able to change the theoretic proposal was a no go for the business. Loading meters can be calculated in charge calculation with a custom helper class that multiplies the pallet quantity by 0,2 or 0,4 depending on the stacking factor. While deciding what to do, it is critical to consider what the optimizer can take into account too. For this purpose, it is good that sap has offered a new field in addition to volume and weight that can be taken into account. I hope that there will be ways in the future to have normalized pallet quantity and normalized footprint quantity which can be influenced and are ok to be influenced by a custom logic. That was the next reason why we could not use it. Since, there is a standard logic for normalized quantity, we did not find it clean to overwrite this logic with our special needs.It was better to have a real custom field for pallet qty and footprint qty. Even though we went away from standard which I always try to avoid, I wanted to share this as there were a lot of discussions at several tm customers about this point and these took time. Maybe, this can provide input.


    • Hi Petra,

      Thanks for your comments on blog and highlighting practical issues with Package building (PB).

      Yes, this PB for optimization of loading space is one of the requirement for most customers. We also had to build custom solution for a Retail Logistic company for ‘Truck building’ in S/4HANA 1709 environment. Also, transfer of PB information from TM to EWM is in SAP’s roadmap and that will be very useful.

      With regards,