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 internal table carrying the possible aisles with the status of the corresponding resource. The objective is to identify those aisles where the resources (e.g. the crane in a HBW) have an exception (~ not up and running > e.g. in failure mode or currently out of service) or the communication channel to the responsible PLC is not running:

The main purpose of point (3) and (4) is to identify the pick-up point for each aisle (~ the communication point where the resource (e.g. crane) picks up the HU which is to be putaway) and determine the max capacity of this CP as well as a potential exception (e.g. aisle is set to ‘outfeed only’ mode, which is saved as an exception on the pick-up communication point). The results are also written into our internal aisle table:

.
Point (5) deletes aisles without any resource assignment and point (6) finally flags aisles to be excluded based on the results of steps (1)-(4):

Point (8)

1. determines the number of HUs travelling towards / sitting on the pick-up point
2. calculates the free capacity based on the max capacity and the result of the previous bullet point
3. flags the aisle in order to exclude it from the selection in case the max capa is exceeded

Finally the method filter_aisles returns an internal table with all relevant aisles, carrying the data determined above and potentially being flagged for exclusion:

As part of the next step we fill variable lv_psv, which is holding the putaway strategy variant:

The possible variants based on the standard coding are

1. prepicked HU (first HU item has a reference to an ODO)
2. single product HU (HU does only have one material/batch combination)
3. none of the two = undefined

Those variants can be used to call different approaches for empty bin determination within the next step. We will not go into detail here as the standard has not implemented significant differences here.  

As part of the last step we do now try to find a destination bin. Important here as an input:

• lt_aisle_level: the table of possible aisles that we filled at the beginning of the main method
• lt_penalty_srt: this table is being imported into the Badi. As mentioned before, we are looping over a sequence of combinations for destinations storage types, sections and bin types (defined in standard customizing)

.
Here the standard first deletes non-relevant aisles based on the exclusion-flag filled before. Then the loop through the remaining aisles starts:

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:

.
Apart from the main select on table /SCWM/LAGPN, the MFS-specific logic which is worth it to mention is
– the consideration of the required bin depth of the HU type (multidepth storage)

.the consideration of the rough bin determination (check against table MFSHUMOVE > we ignore the bin in case another HU is already on the way towards it)

.Finally, we handover a list of possible empty destination bins to the caller:

.At the end we sort the table for cross-line stock putaway (this way it is possible to achieve an equal utilization of bin capacity usage across the aisles):

.The final step is kind of funny:
1. if we found a bin we do not run the non-MFS strategy (makes sense because we already found something)
2. if we did not find a bin we also do not run the non-MFS strategy (also makes sense because we want to putaway into a MFS storage type)

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.