Discover SAP EWM

MFS Putaway Strategy 

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 becomes more and more relevant in an environment of an increasing degree of automation within warehouses. Discover SAP EWM MFS Putaway Strategy.

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 basic understanding of the MFS component as well as some ABAP knowledge in order to understand all parts of this blog post.
For the time being simply imagine a warehouse like this:
– Automated high-bay warehouse with a couple of aisles/cranes, each having one pick-up and one deposit position
– Pallet conveyor with a couple of infeeds, i-points and outfeeds:

 Important terminology in order to understand this article:
– Cranes: Operating in one aisle; executing the putaway and removal tasks
– Communication points: Point along the conveyor at which the communication between EWM and the PLC occurs (displayed as storage bin in EWM).
– Pick-up points: The communication point / part of the conveyor where the cranes pick-up HUs which are to be putaway:

.
Where do we find the standard MFS Putaway Strategy?The EWM standard MFS putaway strategy is encapsulated in class /SCWM/CL_CORE_PUTSTRA which is not used for non-automated storage types.

.Customer classes can inherit from this class to influence the MFS putaway strategy. BAdIs /SCWM/EX_MFS_ACT_CASE_RBD, /SCWM/EX_CORE_PTS_EMPTY_BIN and /SCWM/EX_CORE_PTS_MD_ADDBIN can be used to implement a custom logic and make use of the class mentioned before. The idea of course is to re-use as much standard as possible only re-define certain methods to get to the desired behavior.

We look at the empty bin determination as an example here –
In automated storage types EWM standard will handle the empty bin determination almost entirely separated from the empty bin determination of non-automated storage types.

As mentioned before, the standard logic is sitting in class /SCWM/CL_CORE_PUTSTRA. This class will be called via the fallback class /SCWM/CL_EX_CORE_PTS_EMPTY_BIN of Badi /SCWM/EX_CORE_PTS_EMPTY_BIN:

.
Content/logic of the standard strategy

During runtime we are looping through the storage types given in the storage type search sequence while trying to find a putaway bin. Only if the given storage type is of role ‘MFS’, the fallback class becomes relevant and the standard putaway logic (which is e.g. used for non-automated storage types) will not be executed:

This also means for all non-MFS relevant storage types (storage type role) this fallback class will never do anything and for all MFS-relevant storage types the putaway bin has to be determined within this fallback class or within a custom implementation of this Badi. Other options in standard are not possible as it will be skipped based on the variable shown above.

.
Now let us have a look into the functionalities that this example implementation (respectively the class mentioned above) offer in addition to the standard non-MFS putaway strategies.

For the purpose of this blog we will ignore method init_4_destbin_at_wt_crea. It only serves to set some attributes of the class object based on the source data of given WT. Those attributes are relevant for processing later but not important in order to understand the core logic of the given method/class here.
A deeper look into method det_empty_bin_at_wt_crea reveals the core of the standard strategy for the empty bin determination in a MFS environment:
The method is importing the preferred storage type, section and bin type based on standard customizing. The objective is to export a list of bins which can be used as a destination for the WT.

1.
The first important step is the determination of possible destination aisles:

.
In a MFS environment the putaway tasks are usually created at the i-point or an intermediate communication point on the way between the I-point and the final putaway bins. For each of those communication points we can define via customizing which aisles for which destination storage types are accessible. Method get_aisles reads this data:

Another option is to determine the final destination bin once the HU is handed over to the resource (this could also happen in exceptional cases e.g. in case of task re-creation while the HU is already on a crane but the initial destination bin is not available), the method reads the accessible aisles for the given resource:

.
If the HU is neither on a communication point, nor on a resource, we determine the aisles which are accessible for the source storage bin (~ HU is sitting on a bin which is not a MFS communication point > for example in case we execute a rearrangement within an aisle) . For this purpose, EWM standard reads table /scwm/mfsrsrcais again (while ignoring the resource field):

.
Having a set of possible destination aisles, we now try to filter them based on specific criteria:

.
SAP delivers a nice overview of the steps here right at the beginning of the method:

.
We will not look into detail for all steps but I would like to mention some of the important ones:
Main purpose of (1) and (2) is to fill the inter