As a consequence of the high number of new features of the Supply Chain Execution Package Builder (SCE PB), it became obvious that the component had to support the maintenance of package building definitions better. Most of the new features require some sort of new product attributes and the product package type assignment became even more complex than it had been before.
So the basic idea of grouping products that behave the same during package building together was taken over. On the product / material master there had already been a field Reference Product (RefP for Pack.). After some discussions, it was decided that this field could not be re-used to not endanger existing customer scenarios, because this field is in use by other components and applications. The new, very specific field Reference Product for Package Building was introduced under the Package Building settings.
The reference products can be defined in a hierarchical manner, meaning that not only to the real products a reference product can be assigned. But also a reference product can have a superior reference product.
The product hierarchy can be used for the following purposes:
Example
The company using an application having the SCE PB integrated produces and transports beverages. Those are structured as follows:
Customer maintains NO package building definitions at all on the products, but most on the first level reference products. For example all products A* are small cans of the same size and package the same (actually only the weight is a bit different). Customer has lots of different products in this group, but only defines for CAN_SMALL that 100 pieces make a full pallet and 10 pieces make a full layer.
For the packaging in this example only a single product package type assignment is required: AMBIENT -> PALLET. If we enhance the example by products that need to be cartonized first, only a single new reference material is required to express that all products below do not go directly to the pallet, but into a carton first.
Using the hierarchy carefully, it is possible to reduce the effort drastically. Even for very complicated packaging, it should be possible to limit the number of product package type assignments to only a few.
Attribute and Assignment Determination Logic
The SCE PB will always use definitions made for the product first. If it does not find values, it will search on the next level reference product and continue climbing up the hierarchy until it finds something.
Best Practices
From already pretty realistic and complex test scenarios, I would like to give the following guidelines:
Overview and Maintenance
Hierarchical definitions only visible in single master data instances are hard to understand and hard to maintain. To tackle this, the package builder test report /SCMB/TEST_PB has been enhanced to cover the reference product hierarchy:
As I would like to spend a whole MKS on the cool new features in the test report, I only highlight the best options here:
Using this tool, it is much easier to find out obsolete or erroneous definitions.
From my perspective a very powerful step forward for the SCE PB. I am open for feedback and your ideas!
So the basic idea of grouping products that behave the same during package building together was taken over. On the product / material master there had already been a field Reference Product (RefP for Pack.). After some discussions, it was decided that this field could not be re-used to not endanger existing customer scenarios, because this field is in use by other components and applications. The new, very specific field Reference Product for Package Building was introduced under the Package Building settings.
SCM Product Master
S4 Material Master
The reference products can be defined in a hierarchical manner, meaning that not only to the real products a reference product can be assigned. But also a reference product can have a superior reference product.
The product hierarchy can be used for the following purposes:
- Reduce maintenance effort
- It is possible to define package building relevant attributes only for the reference product saving the effort for each grouped product. For example, you can define the product orientation (MKS80) not for each product, but for the grouping reference product. Especially important for example for the full package quantity and the full layer quantity.
- It is possible to define the package type assignment now on the reference product level making the definitions more transparent. So far the product package type assignment only supported pattern entries (ABC*).
- It is possible to define any new required restriction (stacking, incompatibility, ...) always also on the reference product.
- Defined preferred product grouping
- When the PB creates mixed packages, it will try to combine products with the same reference product first and then climb up the hierarchy.
Example
The company using an application having the SCE PB integrated produces and transports beverages. Those are structured as follows:
Customer maintains NO package building definitions at all on the products, but most on the first level reference products. For example all products A* are small cans of the same size and package the same (actually only the weight is a bit different). Customer has lots of different products in this group, but only defines for CAN_SMALL that 100 pieces make a full pallet and 10 pieces make a full layer.
For the packaging in this example only a single product package type assignment is required: AMBIENT -> PALLET. If we enhance the example by products that need to be cartonized first, only a single new reference material is required to express that all products below do not go directly to the pallet, but into a carton first.
Using the hierarchy carefully, it is possible to reduce the effort drastically. Even for very complicated packaging, it should be possible to limit the number of product package type assignments to only a few.
Attribute and Assignment Determination Logic
The SCE PB will always use definitions made for the product first. If it does not find values, it will search on the next level reference product and continue climbing up the hierarchy until it finds something.
Best Practices
From already pretty realistic and complex test scenarios, I would like to give the following guidelines:
- Any hierarchical definition requires carefully thinking! Make your mind up for what exact purpose you introduce a new reference product (level). Do you model it to maintain packaging definitions? Is it meant to express grouping when building mixed packages?
- Only introduce a new reference product (level) when it is really required! Of course checking hierarchical definitions cost runtime and makes the process slower. Even though this has been analyzed and implemented the best way possible, it still is what it is.
- When a reference product (level) is meant to hold packaging definition, avoid mixing definitions! No subordinate product grouped by the reference product should hold the same or even deviating values for the same attribute. This is of course possible and supported, but makes the sense of the additional product hard to understand. (Example: Do not maintain that 100 pieces make a full pallet for any of the A* products. Do not maintain that 95 pieces make a full pallet for some A* products -> create a new reference product expressing this and group it under the same second level reference product).
- Do not use a real product as reference product: Even though this is technically also supported, I myself find it very hard to understand when it comes to the hierarchical aspects of grouping. I always use a clear naming convention for the reference products and separate them from the real products.
- Do not use pattern definitions any longer in the product package type assignment, but only reference product definitions.
Overview and Maintenance
Hierarchical definitions only visible in single master data instances are hard to understand and hard to maintain. To tackle this, the package builder test report /SCMB/TEST_PB has been enhanced to cover the reference product hierarchy:
Package Builder Test Report - New Mode
Reference Product Hierarchy
As I would like to spend a whole MKS on the cool new features in the test report, I only highlight the best options here:
- Direct jump into product master to display and change data
- Display of existing product package type assignments
- Mass maintenance of assignments to superior reference product
Using this tool, it is much easier to find out obsolete or erroneous definitions.
From my perspective a very powerful step forward for the SCE PB. I am open for feedback and your ideas!
- SAP Managed Tags:
7 Comments
| User | Count |
|---|---|
| 10 | |
| 9 | |
| 5 | |
| 4 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
