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.

Open EWM-Jobs @

SAP EWM Service Engineer
SAP EWM Developer

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:

. In addition to this, you need to define the bin depth of the bin types and the required depth of the HU types: .Once done, the logical position will be visible in the stock/HUs of this storage type as well as in the warehouse tasks to move stock into or out of this type:

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:

.Standard will try to rearrange here in the context of determining the next WO/WT to be processed by the subsystem:

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

The table with the HU(s) (in the standard implementation always one HU only) is handed over to the calling method. Taking this as an input, we call method transfer_hu:

Here we first read the warehouse process type for rearrangement from the PLC customizing:

The next step is the determination of the maximum number of stock transfers:

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

Before we now create the rearrangement task we check whether the HU which is in scope for rearrangement might already have a warehouse task (e.g. a pick task for another delivery). If this is the case EWM writes the task into the returning variable and leaves the method:

Note that this logic might cause problems for your operations as you will remove pallets from stock which might have been planned for a removal much later only. As an alternative for a Z-solution you might want to think about cancelling the task and re-create a new one once the stock transfer is done. In case the HU in scope does not have a warehouse task, EWM now creates a new one: – Number of stock transfer in HU header < resource threshold: A HU task with the WPT from PLC customizing (details above) – Number of stock transfer in HU header >= resource threshold: A HU task towards the error bin of the resource (details above)

…and that’s it. To close the method we fill the return variable and hopefully log a success message:

The task is handed over to the calling program and eventually to FM /SCWM/MFS_WT_DET which initially triggered the rearrangement logic and is responsible to set the next WT to be processed.

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!

Open positions at Swisslog

SAP EWM MFS Developer

SAP EWM MFS Solution Architect

Other openings