After kicking off the topic for SAP Transportation Management, but having the re-use for EWM in mind, we see the component growing into this process. So I do not call it TM Package Builder any longer, but Supply Chain Execution Package Builder. This enables our customers to use the functions at different spots in the end-to-end process, but on shared master data and definitions resulting in synchronized results. This enables better and more efficient processes.
Today I would like to extend the MKS 55 and MKS 56 a bit. Together both lay the foundation to make the PB run, but this blog gets more specific setting up and growing a real scenario. The questions to answer are: What is required at least to make the PB package a product? What is required to enable the PB to consolidate 2 products onto a mixed pallet?
Package a product - minimal definitions
So let's start! First of all I need a product. I don't even fill any weight nor the dimensions, but just add an alternative unit of measure definition. Let's say 600 pieces shall fill a complete pallet.
In the product - package type assignment, I add an entry for my product pointing just to the Package Type (UoM) without a specified package material.
I run report /SCMB/TEST_PB, enter my product MKS_MAT_01 with 900 pieces and the result is:
Wow, my first Package Builder result after maybe 1 minute! Not knowing the transactions from the top of your head I give you 5 minutes. Analyzing the result we see that the PB applied the split quantity of 600 and created the expected items. The package item quantity was set to 1, also for the incomplete package only holding 300 pieces. This is due to the fact that the PB applies for the quantity calculation a height based approach and without any height information it rounds up to 1. I might improve this in the future for this type of scenarios using a split quantity based approach, but so far so good. You also see that all weight and dimension fields of the result items are empty as I did not maintain anything.
For scenarios where just the split is interesting and no further result package attributes are required this is already pretty good. And of course no attributes of the physical package material itself is considered.
To improve the result quality a bit I enrich the product master data and define basic product attributes.
The result now looks a bit better:
Still, for the pallets the PB is not capable of filling all attributes and for the incomplete pallet it sets the full pallet height and a quantity of 1.
First question is answered. What is required to make the PB package a product? Very little.
Consolidate 2 products
Now I add another product pointing to the same package type (unit of measure). I already define the basic product attributes.
The assignment is of course also the same:
Of course as an alternative I could also stick to a single definition using MKS_MAT* as key, but for the better overview I use 2 separate definitions.
Running this scenario we get the following result:
Hmmm. Good, the PB packaged both products. But for the incomplete quantities of both products it did not create a mixed pallet. Reason is simple: It neither has any layer definitions nor can it apply the volume based filling approach. Why? It doesn't know the maximum volume. The maximum height is defined, but the length and width is not known. Those fields are not available at the unit of measure because this is typically maintained in the package material master data. But there is hope! Again we enrich the product master data and fill for the full pallet definition also the length and width.
Re-running the very same scenario, the result is:
Look's better, doesn't it? Even if you only maintain length and width for a single product, the PB will use it whereever the package type UoM is assigned. Both products are consolidated and also package attributes filled.
Second question is answered! What is required to enable the PB to consolidate 2 products onto a mixed pallet? Very little.
So after maybe 10 minutes we have our first PB consolidation scenario we can build on.
Bring in the details
Of course for a realistic and productive scenario more info is required. The physical weight and dimension of the package material consumes capacity and influences the result items. So let's add a pallet:
We adjust the product - package type assignment
Note that the 'PL1' is actually NOT required. The standard PB will always try with the Base Unit of Measure of the assigned package material.
Then we run our single product scenario with a full pallet quantity:
As you can see the height and weight increased by the pallet attributes.
Setting the package material also for the second product, the consolidation leads to this:
My assumption is that as soon as you define a package as master data material, you DON'T define length and width in the product master data packaging definitions.
Alternative Packaging definitions
So far we ran the PB with just a package unit of measure and then with an assigned package material. We saw that it works also in a combination (1 product with UoM and 1 product with package material having the same package UoM as base UoM). Now it gets tricky: What to do when the base UoM is different to the available packaging definitions? Or multiple definitions exist and we want to point to them customer or location specific? In this case you can combine the package material with the package UoM.
So we add another definition in the product defining a split quantity for 'PL2'. Note that the length and width definitions are the same (and actually not required, because they are picked up from the package material).
Now we change the product package type assignment. In reality we would have (at least) two definitions for this product (maybe with different locations or business partners).
And now the PB creates this result:
Gotta stop here, but hope this shines a little light on how to start with the PB and what you can expect based on the available definitions.
If the above described does not work for you, first try note 2482165 No package building based on UoM. The features are avilable in all PB releases.
Today I would like to extend the MKS 55 and MKS 56 a bit. Together both lay the foundation to make the PB run, but this blog gets more specific setting up and growing a real scenario. The questions to answer are: What is required at least to make the PB package a product? What is required to enable the PB to consolidate 2 products onto a mixed pallet?
Package a product - minimal definitions
So let's start! First of all I need a product. I don't even fill any weight nor the dimensions, but just add an alternative unit of measure definition. Let's say 600 pieces shall fill a complete pallet.
In the product - package type assignment, I add an entry for my product pointing just to the Package Type (UoM) without a specified package material.
I run report /SCMB/TEST_PB, enter my product MKS_MAT_01 with 900 pieces and the result is:
Wow, my first Package Builder result after maybe 1 minute! Not knowing the transactions from the top of your head I give you 5 minutes. Analyzing the result we see that the PB applied the split quantity of 600 and created the expected items. The package item quantity was set to 1, also for the incomplete package only holding 300 pieces. This is due to the fact that the PB applies for the quantity calculation a height based approach and without any height information it rounds up to 1. I might improve this in the future for this type of scenarios using a split quantity based approach, but so far so good. You also see that all weight and dimension fields of the result items are empty as I did not maintain anything.
For scenarios where just the split is interesting and no further result package attributes are required this is already pretty good. And of course no attributes of the physical package material itself is considered.
To improve the result quality a bit I enrich the product master data and define basic product attributes.
The result now looks a bit better:
Still, for the pallets the PB is not capable of filling all attributes and for the incomplete pallet it sets the full pallet height and a quantity of 1.
First question is answered. What is required to make the PB package a product? Very little.
Consolidate 2 products
Now I add another product pointing to the same package type (unit of measure). I already define the basic product attributes.
The assignment is of course also the same:
Of course as an alternative I could also stick to a single definition using MKS_MAT* as key, but for the better overview I use 2 separate definitions.
Running this scenario we get the following result:
Hmmm. Good, the PB packaged both products. But for the incomplete quantities of both products it did not create a mixed pallet. Reason is simple: It neither has any layer definitions nor can it apply the volume based filling approach. Why? It doesn't know the maximum volume. The maximum height is defined, but the length and width is not known. Those fields are not available at the unit of measure because this is typically maintained in the package material master data. But there is hope! Again we enrich the product master data and fill for the full pallet definition also the length and width.
Re-running the very same scenario, the result is:
Look's better, doesn't it? Even if you only maintain length and width for a single product, the PB will use it whereever the package type UoM is assigned. Both products are consolidated and also package attributes filled.
Second question is answered! What is required to enable the PB to consolidate 2 products onto a mixed pallet? Very little.
So after maybe 10 minutes we have our first PB consolidation scenario we can build on.
Bring in the details
Of course for a realistic and productive scenario more info is required. The physical weight and dimension of the package material consumes capacity and influences the result items. So let's add a pallet:
We adjust the product - package type assignment
Note that the 'PL1' is actually NOT required. The standard PB will always try with the Base Unit of Measure of the assigned package material.
Then we run our single product scenario with a full pallet quantity:
As you can see the height and weight increased by the pallet attributes.
Setting the package material also for the second product, the consolidation leads to this:
My assumption is that as soon as you define a package as master data material, you DON'T define length and width in the product master data packaging definitions.
Alternative Packaging definitions
So far we ran the PB with just a package unit of measure and then with an assigned package material. We saw that it works also in a combination (1 product with UoM and 1 product with package material having the same package UoM as base UoM). Now it gets tricky: What to do when the base UoM is different to the available packaging definitions? Or multiple definitions exist and we want to point to them customer or location specific? In this case you can combine the package material with the package UoM.
So we add another definition in the product defining a split quantity for 'PL2'. Note that the length and width definitions are the same (and actually not required, because they are picked up from the package material).
Now we change the product package type assignment. In reality we would have (at least) two definitions for this product (maybe with different locations or business partners).
And now the PB creates this result:
Gotta stop here, but hope this shines a little light on how to start with the PB and what you can expect based on the available definitions.
If the above described does not work for you, first try note 2482165 No package building based on UoM. The features are avilable in all PB releases.
- SAP Managed Tags:
4 Comments
| User | Count |
|---|---|
| 10 | |
| 7 | |
| 3 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
