Following up on the last MKS (MKS53 – Package Building Process and MKS54 – Package Building Profile), today’s post deals with the assignment of the different package types to certain products during the package building.

Remember that for the process in SAP Transportation Management, the Freight Unit Builder passes the already grouped (mandatory split criteria like incompatibilities already applied) and compatible product items to the package building function (when activated in the FUB rule). The process in general can be steered using the package building profile. So the next question is how does the package builder decide for each product into/onto which package it goes.

To enable flexible assignments, a new product master data transaction is available called ‘Define Product Package Assignment’. In SAP TM 9.3 you can find this under Master Data -> General next to ‘Define Product’. Transaction code is /SCMB/PB_PRD_PKG_***. Within this transaction, it is possible to define for a combination of product, business partner and location the package type to be used.


Most important: To reduce the effort when maintaining those definitions, it is possible to work with generic patterns. I can imagine that you usually start with a generic entry like product = ‘*’ and set the package type. Later you define then the exceptions.

So why the product, partner and location key combination? Scenario: Product A is usually delivered with an EU pallet stacked up to 1.5 meters (first entry). But when delivering this product to customer X from your warehouse Y, you use a different pallet type containing product A stacked up to 1.3 meters, because the customer can only handle pallets up to this height (second entry as exception).

Which entry is picked for a product line item? 3 key fields allowing also pattern values are tricky. The PB will always prefer the most specific entry. So it will start to search for an entry matching all 3 key fields exactly. In case nothing is found, it will score all other keys in the following manner: How many keys match exactly? How many keys match by pattern? How many keys are initial? Then it will select the key with the highest score. For very complicated scenarios there is an enhancement spot to overrule the standard logic. (technical detail: deterimation logic is here /SCMB/CL_PB->DETERMINE_ITEM_PACKAGE_TYPE). Note that the PB will always pick only 1 entry and not combine two. For example you could think that you define generally valid attributes on the generic entry and only overwrite the differences on the most specific entry. Nope…

What can be defined? First thing as the transaction code says – define the target package type. There are multiple options for this. You can set the package material. When doing this the base unit of measure of this package and also dimensions and weight are considered. Second option is the package unit of measure. This points directly to the product alternative units of measure for the conversion rules, but no package attributes are considered. When set in combination with the package material, it can overrule the base unit of measure of this package. Third option is the definition of the equipment group and type. This enables in SAP TM the creation of container, trailer, or railcar units. It does not affect the logic and at least the package unit of measure must also be defined.

Secondly, the definition allows to set specific limits regarding weight and height the PB shall consider when packing the product. It is possible to set generally valid limits on the package material (for example you can oly stack a EU pallet up to 1.8 meters and put 900 kg on it). In the assignment, you can lower those limits product, customer and location specific.

Thirdly, there are flags to steer the process when creating mixed packages/pallets. First of all you have a layer unit of measure field. This points to the product master data defintions required to create a mixed package (how many pieces fit into a product layer). In addition, you can define if a product can be split over multiple mixed packages, if additional packing material is required and how mixed product layers shall be created. The mixed package building will be the topic of one of the next MKS for sure.

After evaluating this assignment table, the PB knows for each product line item how it shall be packaged. Now it will check for the conversion rules defined on product master data level.

Two more things:

  • There are BAPI function modules available to up- and download the assignments.




  • Currently there is no package type optimization or dynamic package type determination available (something like for a specific product set I would pick pallet X, and for another set pallet Y; or for the to-be-consolidated product items I will determine a package type fitting to the quantities).
To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Michael Seifert

    Hi Marcus,

    thanks again for your interesting information on this topic! However, to be able to evaluate the usability of the package building feature, could you shed a light on how SAP thinks of the relation between Package Builder in TM, existing Picking/Packing logic in EWM, and the packaging rules in ERP?

    For example, I know that in our EWM system a lot ot effort has been spent to enable the creation of mixed pallets, starting from an ERP delivery with different products (say, two boxes, three bags and one 200 liter drum) – though I don’t know the details. Coming around saying “Hey, let’s use package building in TM” without a basic idea of the interaction would be quite masochistic, I guess 😉

    1. Marcus Zahn Post author

      Thanks for the comment. Didn’t MKS53 say at least a few words about this? That we are aware of this ERP – TM – EWM setup and therefore designed the component as generic as possible considering WM info?–53-tm-93-load-planning-enhancement-build-packages

      I know that the warehouse has the logic. But whenever presenting this to customers and talking about it, it becomes clear that the transportation process is before the warehouse and needs to know the pallets. Otherwise you can’t optimize your transportation. So there is no other way that TM learns such a function. A pure ‘we ask any WM and just handle the result’ is not possible as TM can be setup standalone. Of course we want for customers having invested a lot in the package building in (E)WM a smooth process without having the get the TM PB to work separately. My understanding is that mid-term both systems must use the same engine (for example the sophicticated PackSpec integrated into the ‘new’ PB component allowing the customer to choose which logic shall be applied). For ERP: Well, not so easy to replace anything there. Nevertheless there are plans ti support also those processes.

      Hope that clarifies a bit.

      1. Michael Seifert

        No because I was fully satisfied with your answer 🙂

        We still have processes where the personnel doing the picking decides how things are packed on a pallet (EWM just provides the warehouse pallets telling the guy how many drums, bags… to pick from the pallet, and if he decides that the shipping pallet is full, he hits a button and a new one is provided). Of course you can’t (at least not without considerable effort) model such things in any system regardless of how good the logic is…

        For the ERP part, we have some custom logic based on material classification to not have to maintain packaging instructions for every “number of pieces – secondary packaging” combination, but only one per packaging material (CP3 pallet, for example). As far as I understand, the new logic is different in that the number of pieces per pallet is not fixed but is determined dynamically based on the dimensions of the pieces – exited to see this working in practise some day 🙂

        And I am also looking forward to your next MKS telling about mixed package building!!


Leave a Reply