Enhance SAP EWM
Warehouse Order Creation Rules
The purpose of this series of blogs/videos is to give an overview about how to enhance specific functional areas of SAP EWM. This series is useful for developers jumping (or being pushed ) from other modules into EWM or for more experienced consultants in order to gain a deeper understanding of specific topics.
In this blog/video I will be talking about warehouse order creation rules (WOCRs). Note that I will not explain the basic, thus expecting that you do at least know in which context WOCRs are used and what they can do for us. Will explain those basics in a separate blog/video of the series Understand SAP EWM. For now, you can refer to the SAP Online Help if you are a beginner in this area.
Even though we will not go into detail, let us have a look at this picture to get a rough overview:
1. WOCRs are being applied upon wave release respectively during other options (e.g. manual WT creation against an ODO) where we trigger the 2. – warehouse task creation
3. Once created, the tasks are grouped by queue and activity area (source vs. destination AA based on the WOCR AA of the WPT). Thus, warehouse task with a different queue or a different activity area can never end up in the same warehouse order
4. First real WOCR-related step is the determination of the WOCR itself (either pre-defined via the warehouse process type or based on the source/destination AA and the activity itself)
5. Once we found a WOCR we start with applying filters on item level(e.g. filter out WTs based on warehouse process type, wave template type or maximum weight/volume)
6. Then we sort the WTs (6) before we apply filter on subtotal/CG (7) levels (e.g. only consolidation groups with less than X WTs)
8. Next thing we do is to check limits on level of the warehouse order which is to be created. This could be total weight/volume or maximum number of WTs/HUs
9. WTs which passed the filters and limits are sorted again and then tackled by the packing profile (where it is possible but not mandatory to create planned pick-HUs and assign the WTs to those HUs)
10. Last thing we do is to sort the WTs one more time (now within the WOs which have been created)
Let’s hike across the Badis in the WOCR-World! It will give us 15 spots to take a rest!
Enhancement spot /SCWM/ES_WHO collects all those Badis which are being called in the context of function module /SCWM/WHO_CREATE.
Let us have a look on them one-by-one. For this purpose, I set breakpoints at every single BAdi and included the current stack in the screenshot. This way you get a good picture about where/when the Badis are called and whether they could be an option for your specific need to enhance the standard logic.
1. /SCWM/EX_WHO_DSTGRP – Overwrite Consolidation Group
The first Badi on our journey is Badi /SCWM/EX_WHO_DSTGRP which can be used to overwrite the consolidation group of the warehouse tasks. Changes here will have an impact e.g. on the limits for subtotals or e.g. on the max number of consolidation groups assigned to one pick-HU.
Field dstgrp in changing structure lt_to is the one you want to look at:
2. /SCWM/EX_WHO_CREATE – Full WO Creation Using BAdI
The next Badi where we stop is /SCWM/EX_WHO_CREATE where you can implement a 100% custom WO creation (the screenshots below show the parameters importing the WOs as well as potential pick-HUs). In case this Badi is being applied, everything else (standard logic as well as all other Badis here) will be skipped. I could imagine having sophisticated WOCR logic from a 3rd party somewhere in the cloud in the future (so this Badi could offer an API which could be consumed by an external solution):
3. /SCWM/EX_WHO_FLT_IL – Use Additional Filters at Item Level
The next one on our trip is Badi /SCWM/EX_WHO_FLT_IL, where we can apply additional filters at item level. We are importing table it_to (based on ordim_o structure (type /scwm/tt_ordim_o_int)) from where we can select the WTs which we want to filter out and write those WTs into changing table ct_to_failed. This table will be appended to internal table et_failed, which does already carry the WTs which had been filtered out before based on standard filter logic:
4. /SCWM/EX_WHO_SORT – Use Additional WT Sorting
Now we arrive at the first spot where we call Badi /SCWM/EX_WHO_SORT. The first sorting of WTs happens here before applying the subtotal filters. Here we have the option to influence the collection of WTs which are later grouped into one WO. You will see that we call this Badi a multiple times later again where it can be used to influence the sorting before packing and later within one WO. The custom sequence should be returned via changing table ct_to:
5. /SCWM/EX_WHO_FLT_SL – Use Additional Filters at Subtotal Level
The next we can do is apply additional Filters on Subtotal Level (level of consolidation group) by using Badi /SCWM/EX_WHO_FLT_SL. Here we could restrict based on any kind of characteristic cumulated over all WTs of a given consolidation group. Simply kick a consolidation group by setting the variable cv_failed to true.
6. /SCWM/EX_WHO_LIM_OVERRULE – Overwrite Limit Values
The next one that we find during runtime is Badi /SCWM/EX_WHO_LIM_OVERRULE which can be used to change the limit values (adjust structure ls_wcrlimit). Note that we are doing nothing else than changing the limit values here before those limits are then being applied via standard coding:
7. /SCWM/EX_WHO_PMAT_DET – Determine Possible Packaging Materials for Det. the HU
In EWM standard we can find packaging specifications via condition records in order to get packaging materials which are to be used for the planned pick-HUs. Pick-HUs can be created in the context of WOCRs via the packing profile. The Badi /SCWM/EX_WHO_PMAT_DET can be used to find packaging specifications based on custom logic instead of using the standard approach via condition records determining packaging specifications:
8. /SCWM/EX_WHO_PMAT_CHECK – Check and Sort Found Packaging Materials
The next stop on our Badi-Hike is include /SCWM/LWHO_MAINF28, where we call Badi /SCWM/EX_WHO_PMAT_CHECK. This Badi can be used to adjust the selection of packaging materials found by the standard before. So if we are not using Badi /SCWM/EX_WHO_PMAT_DET (see previous stop) but rather let the standard select packaging materials based on condition records, we can still manipulate the result here (even manipulate the master data of the materials which have been found via structure ct_pmat):
9. /SCWM/EX_WHO_SORT – Use Additional WT Sorting
In case the pack mode is set to ‘A’ or ‘B’ in our packing profile, we will now be faced with Badi /SCWM/EX_WHO_SORT again. This time we can manipulate the sorting of WTs ahead of packing (so we can manipulate the assignment of WTs to the planned pick HUs). Note that this Badi will only be called in case a sort rule is maintained in the packing profile:
10. /SCWM/EX_WHO_PACK_CHECK – Check Whether WT Is to Be Packed into HU
In case the pack mode is set to ‘A’ or ‘B’ in our packing profile, we will now be faced with Badi /SCWM/EX_WHO_PACK_CHECK. The logic is pretty simple. We are looping over all WTs which are still left and have the option to suppress the assignment of the given WT to the given pre-planned pick-HU. In order to do so we must set the variable cv_exit to true within the implementation of the Badi.
11. /SCWM/EX_WHO_PACK_DIM – Check for Length, Width, Height
Also Badi /SCWM/EX_WHO_PACK_DIM is only called in case the packing profile is set to ‘A’ or ‘B’ and in case the ‘dimension check’ is active in the packing profile of the WOCR. The first time when this Badi is called it is only called for HU warehouse tasks (Side note: Probably there are not many scenarios where you create HU WTs with a WOCR having a packing profile with active pick-HU creation). A couple of lines later it is called one more time for product warehouse tasks:
Note that this Badi is only being called in case the standard checks of product UOM against max values for packaging material length/with/height do not fail (so in case standard checks fail we are already terminating the logic before we even reach this Badi).
If you want to reject here, simply set the changing variable cv_ok to initial in order to let the dimension check fail for the given WT:
12. /SCWM/EX_WHO_PACK_DSTGRP – Overwrite Consolidation Group
Next stop – one more Badi which is only being called in case the packing profile is set to ‘A’ or ‘B’. Another precondition for the call it is that we have defined a maximum number of consolidation groups per HU in the WOCR customizing and our current basked of WTs has more than one consolidation group (we are looping over internal table lt_sto and only reach the Badi in case we find a new consolidation group during the loop).
With this Badi we can decide whether WTs of a specific consolidation group should be assigned to one pick-HU or not (while setting the variable lv_skip to true we are leaving the current loop pass and proceed with the next WT):
13. /SCWM/EX_WHO_PACKING – HU Determination for Warehouse Order
In case the pack mode is set to ‘C’ instead we will pass Badi /SCWM/EX_WHO_PACKING, where we can implement our own pick-HU creation logic based on the packaging materials which had been determined before via standard or custom logic. Note that this Badi is only being called in case the pack mode is set to ‘C’ in packing profile of the WOCR:
14. /SCWM/EX_WHO_HDR_PROCTY – Overwrite Warehouse Process Type on WO Level
Now we are almost done. The next one on our trip is Badi /SCWM/EX_WHO_HDR_PROCTY where we can overwrite the Warehouse Process Type on WO Level:
15. /SCWM/EX_WHO_SORT – Use Additional WT Sorting
We have almost reached our destination. Badi /SCWM/EX_WHO_SORT is the last Badi within our extensive WOCR hike here. Warehouse Orders have basically been fully created within the previous steps and even pick-HUs might already be there. With this Badi – which we actually call the 3rd time now – we have the option to manipulate the sorting of WTs within the single WOs. This could be useful e.g. to optimize the travel path for the picker or make sure to have heavy items at the bottom of the pick-HU.
We made 15 stops on our journey. You saw that almost everything in the context of WOCRs can be enhanced. However, with every enhancement that you implement, consider that you are building a complex machine which still has to be maintained and understood in the future. Most probably not by yourself