Discover SAP EWM MFS
Rearrange HUs in multi-depth storage bins
Note: This blog is part of the series ‘SAP EWM meets Automation’ and shows an EWM standard logic which is rarely mentioned in any of the EWM books and documentations but tackles a process which is essential in automated warehouses with SAP EWM MFS multi-depth storage bins.
The content provided here has been created in cooperation with the SAP EWM team at Swisslog. Feel free to visit their website in case you want to learn more about EWM @ Swisslog!
Note that you need to have a rough understanding of the MFS component as well as some basic ABAP knowledge in order to understand the content of this article.
What is the problem we are looking at?
Multi-depth storage can be used to save space in automated storage types. It results in fewer working aisles and resources and a higher storage density. Multi-depth storage bins can contain multiple handling units (HUs) stored horizontally behind each other.
Usually, goods are retrieved following the LIFO (last in, first out) principle but this cannot always be ensured (e.g. in warehouses with the necessity to store HUs with different products on the same multi-depth bin or in case different strategies are used as part of the picking rules). In such a situation it might become necessary to rearrange the HU on the front position in order to access the HU on the back position (the back storage bin always has the highest bin depth – here ‘02’ – and will be filled first).
In this example here, pallet A is on position 02 and pallet B is on position 01. We created a warehouse task and want to retrieve pallet A.
In order to achieve this we need to rearrange pallet B at first. Based on the status of HU B we do have two options in EWM standard here:
– Rearrange pallet B (in case pallet B does not have a HU WT already, we can move it to another free bin)
– Remove pallet B from stock (in case pallet B does already have a HU WT we cannot create a new one but have to process the existing one)
.This sounds straightforward but it has some hiccups and specialties. Let us have a look at the details.
Customizing prerequisites
The following settings are needed on storage type level in order to work with multi-depth bins:
Where do we find the standard logic?
Badi /SCWM/EX_MFS_MD_REARR_HU with fallback class /SCWM/CL_EI_MFS_MD_REARR_HU is called from include /SCWM/LMFS_MAINF06, subroutine call_badi_multi_deep:
1st step: method check_hu_in_bin
2nd step: method transfer_hu
…that is the basic structure. Now let us have a deeper look into the standard logic!
Content/logic of the standard strategy
Precondition for method check_hu_on_bin to be called is
– The next WO/WT to be processed was selected via standard or custom logic (Badi /SCWM/EX_MFS_WO_DET2)
– The source storage type of the selected WT is setup for multi-depth storage
The method checks whether the source storage bin of the WT can hold more than one HU and if yes, select all HUs physically on the bin.
Then we
1. Sort all HUs by the logical position (as mentioned above, position 1 is always the front position)
2. If the pallet on position 1 is equal to the pallet of the WT to be processed (~ iv_huident) we do not need to do anything > EXIT
3. If the pallet on position 1 is different than the pallet in the WT, it needs to be rearranged
This value defines the maximum number of consecutive stock transfers allowed per HU in an aisle before the HU must be moved out of the aisle. When the HU reaches the threshold, the system moves the HU out of the automated aisle to a dedicated bin. This allows you to, for example, realign the content of the HU to ensure it is still correctly placed in the HU (e.g. goods on a pallet might slightly move/shift with each physical movement of the pallet). As soon as the HU moves out of the automated aisle, the system resets the number of stock transfers to zero.
The default error bin can be maintained via transaction /SCWM/MFS_RSRC
Within this loop EWM is doing some checks on the storage type customizing, enriches the penalty table mentioned above (do not want to go into detail here) and finally reaches method select_empty_bins:
As the last part of this blog we want to think about how to enhance the standard fallback here.
How to enhance the EWM MFS storage bin standard here?
In case you want to enhance here you should create a new subclass that inherits from the standard fallback class /SCWM/CL_EI_MFS_MD_REARR_HU. Some possible scenarios to be considered for your warehouse and potential reason for an enhancement here:
– Inconsistencies of storage bin data: As you know, EWM sometimes tends towards the creation of inconsistent bin master data (e.g. capacity data like current number of HUs on the bin). Unfortunately, the standard fallback classes makes use of this master data in order to decide whether to apply the rearrangement logic or not. This is kind fragile and you might want to replace it with a different logic in your project:
– Cancellation of tasks: As shown above, open tasks for HUs on position 01 are being processed in case they exists. For your process it might more better to cancel those tasks, execute the rearrangement and create them again once done (e.g. in case the corresponding delivery should not be picked/processed at this point in time)
– Movements of multiple HUs from one bin (e.g. triple-depth warehouse): This is not supported by the standard logic at all and has to covered by a z-logic in case it is needed or your operation:
Finally, we handover a list of possible empty destination bins to the caller:
That’s it!
In case you are faced with challenges in or around EWM MFS, feel free to get in touch with the EWM team @ Swisslog.
I hope this blog post provides value to you and you could learn something. Please feel free to subscribe to my blog updates or my youtube channel in case you want to be notified about new posts!
Get my monthly blog-updates!
Subscribe to my Youtube channel!
