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 https://blogs.sap.com/2019/07/12/monday-knowledge-snippet-mks-99-tm-9.6-normalized-and-load-consumption-quantities-of-documents/.
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 https://blogs.sap.com/2020/03/31/capability-of-package-building-in-freight-order-in-embedded-transportation-management-tm-in-s-4hana-1909-release/. 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.
Nenhum comentário:
Postar um comentário