Discover SAP EWM MFS - Rearrange in multi-depth Storage Bins

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). 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 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)