Monday Knowledge Snippet (MKS) – 101 Package Building from simple to complex scenarios (part I)
With today’s blog I would like to start a small series of MKS explaining how to setup package building scenarios starting from very simple and step by step increasing the complexity. Soem of this stuff is already available in some of the previous MKS, but never presented in a flow.
So let’s start with a product (TA: MM01): I pick an industry sector fitting my scenario and make it a ‘Finished Product’.
I give it a lazy description and set the Base Unit of Measure to ‘EA’.
As of now I am not defining anything else, not even its weight and dimensions.
Using this in Package Building test report /SCMB/TEST_PB bring up no result, as the key definition is missing. A package type assignment must be created to make the product relevant for package building. So let’s do this: I only tell the PB to put this to standard unit of measure PAL because I know it will in reality end up on a pallet. So far I have no package material maintained.
If I run this now in the PB test tool (you may recognize that I did not even enter a PB Profile – PB will run with defaults including the volume based consolidation mode),
I already get a result:
Let us check: The assignment was done, but no further attribute (neither for the product nor for the package) are available. Well, no surprise, where should they come from?
I can also now run this with a higher quantity of the product. It will result in the same assignment as the PB does not know any split criteria.
I know that 10 EA make a full pallet, so I go back to the material maintenance and define this:
Now my PB test result looks different:
The split was done correctly, the assigned quantities fit. Great! Still no attributes, that might help in later process steps. Dimensions and weight would be great. So let’s go back to the material maintenance and add this. I know the dimensions of the full pallet (including the package material) and add this to the split criteria:
Well, that improved the PB result:
The full pallet with the assigned 10 EA of my product looks okay as the PB has taken over my attributes. But also for the incomplete pallet a few things changed: I can see width and length filled and some weight and volume limits (PB assumes that the full pallet is the maximum). Height is not filled. You might argue why this is: could it not be calculated using the height of the full pallet? In our case: Why is it not 750mm, because half of the product quantity is assigned? Remember that the full quantity definition includes the package material, so this would kind of be wrong as it would include only the height of half of a pallet. So I decided not to apply such a logic. If you want correct result attributes, define the required master data.
As a next step, I do this and go back to the material maintenance. Here I now add product dimension and weight:
From the dimensions you can derive, that 2 EA make a layer (even though I do not maintain this now), the pallet weight is 50 KG and the pallet height is 10 cm.
Here is the package building result:
We see that the system calculated the weight of the incomplete pallet as 5 x single product weight. The height is calculated out of the total product volume / package material surface. You might now argue it could include the derived pallet attributes. But it does not: For our example it is pretty straight forward to come to a automatic layer logic. But I decided that based on just a package material unit of measure this is where we stop as we focused on scenarios where customers define such attributes on the package material.
So at the end of this blog we still don’t have a PB profile defined, use no layer definitions, have no package material. But already the result is usable. Stay tuned for the next steps.