After getting the question 'Can the Package Builder create a package hierarchy?' now several times with increasing urgency, I want to clarify the status quo of the currently available package builder functionality for this.
First of all: What does package hierarchy mean (to me)? The order is based on product items. Those are packaged into boxes / cartons and those are placed onto pallets. With all kinds of variations in the process.
And the (official) answer to the above question is: NO. The standard Package Builder (PB) component packs products directly into packages or onto pallets and those are used for the planning process afterwards including load planning in SAP TM. This is was the scope of the package builder project, this is how the frontrunner customers required it, and this is how the function is documented.
BUT... I did foresee this requirement. Even if this would not be required for transportation, the goal of reusing the PB also in the EWM context would bring it up. So technically the PB does not care if a product is a product or a package, and already checks for created packages if there are further package instructions maintained.
So let's check step-by-step if we can make a product into a carton onto a pallet scenario work:
Product Definition: Here it is possible to maintain for the inbetween carton all required data. I can define its size and weight, and also the packaging data onto the pallet. I define it as closed package on the tab 'Pkg Data'. So here 6 boxes make a full pallet.
For the product, that i before had to pack directly onto the pallet, I change the definitions now pointing rather to the carton (packaging instruction to CA1 and not PAL). 2 pieces of my product fit into this carton.
Product - Package Type Assignment: From a definition point of view it is possible to maintain the required product - package type assignment without any hierarchy restriction. So I can do this:
2 products into carton type A, 2 products into carton type B. Both cartons onto the same pallet type.
Now I create an order. My scenario is in Thailand transporting stuff from Bangkok to Chiang Mai. I add 3 products to the order and save.
The standard TM Freight Unit Builder (check here how to make the PB run in general) now creates the Freight Unit(s) including a call to the PB. Checking the tab 'Items' we see - hurrrrrraayyyy - a product - package hierarchy. The PB correctly packaged the products into the cartons and - somehow - put them onto pallets. That looks already nice. But the devil is in the details.
But positive aspects first: We can see that the PB corrrectly combined 2 different products using the same carton onto the same pallet. We can also see with package 20, that the mixed package building for products works also fine in this scenario as the PB consolidated products A and B into the same carton following the available definitions and space.
As I am a big fan of testing 'my' component decoupled from the using application (even if it is my home turf TM), I use test report /SCMB/TEST_PB to validate the functionality. This helps me also in error situations to detect if I have a PB issue or an application problem (in the TM context: Freight Unit Builder).
So I start the report in se38:
Thanks to the great effort of Matthias Mueller improving the result tree (SCMB PB note 2394496), the result looks like this:
So now you can start to setup the scenario that you want to get running and validate the results. And here one hint that I give to all consultants approaching me: Start with the easiest scenario and make it run. Then add the complexity. Because this way you recognize when the PB stops doing what you want him to do. Often consultants setup the final scenario involving many products and high quantities, and then ask me why it does not work. Checking it I then see that it did not even work with the A (1) + B (1) because they forgot the simplest setting (like a maximum height or product size when using a volume based mixed pallet building).
And now to the devil in the details: My gut feeling is that you should very carefully validate
The first two points will be improved a lot with note 2459638, which I currently finalize.
Again, the package hierarchy is no standard function and we are not talking error here. But of course we want happy customers, are willing to listen and improve what is there. Already the PB has grown much beyond what we wanted to deliver, because nice customers asked nice questions and got almost in all case a nice solution.
Last word: Why is it no standard yet? Because the complexity of consolidation grows dramatically and even if I am typically not afraid to take such risks, here I had a bad feeling of releasing it pro-actively. For example combined scenarios where some products are packaged into boxes and some directly go onto the pallet, additional stacking constraints, and so on I could not cover with the available capacity. But step-by-step I think it will evolve.
And as always with the PB: At almost all spots in the component, there is an enhancement spot available.
First of all: What does package hierarchy mean (to me)? The order is based on product items. Those are packaged into boxes / cartons and those are placed onto pallets. With all kinds of variations in the process.
And the (official) answer to the above question is: NO. The standard Package Builder (PB) component packs products directly into packages or onto pallets and those are used for the planning process afterwards including load planning in SAP TM. This is was the scope of the package builder project, this is how the frontrunner customers required it, and this is how the function is documented.
BUT... I did foresee this requirement. Even if this would not be required for transportation, the goal of reusing the PB also in the EWM context would bring it up. So technically the PB does not care if a product is a product or a package, and already checks for created packages if there are further package instructions maintained.
So let's check step-by-step if we can make a product into a carton onto a pallet scenario work:
Product Definition: Here it is possible to maintain for the inbetween carton all required data. I can define its size and weight, and also the packaging data onto the pallet. I define it as closed package on the tab 'Pkg Data'. So here 6 boxes make a full pallet.
For the product, that i before had to pack directly onto the pallet, I change the definitions now pointing rather to the carton (packaging instruction to CA1 and not PAL). 2 pieces of my product fit into this carton.
Product - Package Type Assignment: From a definition point of view it is possible to maintain the required product - package type assignment without any hierarchy restriction. So I can do this:
2 products into carton type A, 2 products into carton type B. Both cartons onto the same pallet type.
Now I create an order. My scenario is in Thailand transporting stuff from Bangkok to Chiang Mai. I add 3 products to the order and save.
The standard TM Freight Unit Builder (check here how to make the PB run in general) now creates the Freight Unit(s) including a call to the PB. Checking the tab 'Items' we see - hurrrrrraayyyy - a product - package hierarchy. The PB correctly packaged the products into the cartons and - somehow - put them onto pallets. That looks already nice. But the devil is in the details.
But positive aspects first: We can see that the PB corrrectly combined 2 different products using the same carton onto the same pallet. We can also see with package 20, that the mixed package building for products works also fine in this scenario as the PB consolidated products A and B into the same carton following the available definitions and space.
As I am a big fan of testing 'my' component decoupled from the using application (even if it is my home turf TM), I use test report /SCMB/TEST_PB to validate the functionality. This helps me also in error situations to detect if I have a PB issue or an application problem (in the TM context: Freight Unit Builder).
So I start the report in se38:
Thanks to the great effort of Matthias Mueller improving the result tree (SCMB PB note 2394496), the result looks like this:
So now you can start to setup the scenario that you want to get running and validate the results. And here one hint that I give to all consultants approaching me: Start with the easiest scenario and make it run. Then add the complexity. Because this way you recognize when the PB stops doing what you want him to do. Often consultants setup the final scenario involving many products and high quantities, and then ask me why it does not work. Checking it I then see that it did not even work with the A (1) + B (1) because they forgot the simplest setting (like a maximum height or product size when using a volume based mixed pallet building).
And now to the devil in the details: My gut feeling is that you should very carefully validate
- the attributes of the created packages / pallets
- how the PB consolidated different package types
- how the integrating application behaves when initially saving the created item hierarchy
- how the integrating application behaves when order updates have to be processed
The first two points will be improved a lot with note 2459638, which I currently finalize.
Again, the package hierarchy is no standard function and we are not talking error here. But of course we want happy customers, are willing to listen and improve what is there. Already the PB has grown much beyond what we wanted to deliver, because nice customers asked nice questions and got almost in all case a nice solution.
Last word: Why is it no standard yet? Because the complexity of consolidation grows dramatically and even if I am typically not afraid to take such risks, here I had a bad feeling of releasing it pro-actively. For example combined scenarios where some products are packaged into boxes and some directly go onto the pallet, additional stacking constraints, and so on I could not cover with the available capacity. But step-by-step I think it will evolve.
And as always with the PB: At almost all spots in the component, there is an enhancement spot available.
- SAP Managed Tags:
6 Comments
| User | Count |
|---|---|
| 11 | |
| 7 | |
| 4 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 |
