Discover SAP EWM MFS – Deep-dive Layout-oriented Storage Control

Discover SAP EWM MFS

Deep-dive Layout-oriented Storage Control

This blog is part of the series ‘SAP EWM meets Automation – Discover EWM MFS’ and ventures to deep-dive into the usage of the layout-oriented storage control (LOSC) in the context of MFS processes. We will assume that we are in a MFS-environment, moving a HU across MFS-relevant storage bins (~ communication points). To be more specific, we will look at an HU moving across a conveyor:
SAP EWM MFS Layout-oriented storage control_01
Some parts of the logic we look at is not relevant for non-MFS movements but this deep dive will still cover everything which is also relevant for non-MFS relevant usage of the LOSC (one could also say that non-MFS LOSC logic is a subset of the MFS LOSC logic here). Note that I will not explain the basic concept of the LOSC here again. In case you are not familiar with the general approach I would suggest having a look at this blog post / speed dating washington dc here upfront. As with all posts of this series, the content provided here has been created in cooperation with the SAP EWM team at Swisslog. Feel free to visit their dating after 50 in dallas in case you want to learn more about the services offered by @ Swisslog or to browse open positions within their EWM team! Now let us jump into the technical details right away! Technically, the LOSC is invoked during the warehouse task creation. In the context of the HU WT creation (visible in the stack shown below), EWM calls function module /SCWM/ROUTING_LAYOUT_CHECK which calls FM /SCWM/TROUTL_DET after having collected some necessary data:
SAP EWM MFS Layout-oriented storage control_02

FM /SCWM/TROUTL_DET is the most important one in this context here. So let us have a look at it step-by-step!

1. Read the LOSC customizing

Right at the beginning we read the routing records from the customizing:

SAP EWM MFS Layout-oriented storage control_04.2
SAP EWM MFS Layout-oriented storage control_04.1
SAP EWM MFS Layout-oriented storage control_03

2. Fire selects onto the customizing table in order to find a valid record

We have a hard-coded access sequence here (unlike e.g. queue determination or STSS where we have an option to customize the access sequence). This is very important in order to understand which record is selected for routing (keeping a screenshot of this access table is a life hack for every EWM consultant ):

SAP EWM MFS Layout-oriented storage control_05
Having that many combinations we end up with almost 500 lines of code, trying to find one or more valid records. Yes – it can be multiple ones as EWM included a sequence number in the key of the table and a Do-statement in the code makes sure to select all valid ones: 
SAP EWM MFS Layout-oriented storage control_06

.Note that EWM standard will always apply the matching record on sequence number #1. We will come back to the usage of the other records later, when we look at options for enhancements (Prio BAdi).

3. Capacity check

Note: Have a look at this blog post in case you want to make yourself familiar with important MFS objects (like the communication point).

SAP EWM MFS Layout-oriented storage control_07
Right at the beginning we read the customizing and application data of the segment and the communication point. Of course this is only needed in case we are in a MFS environment which we assume for this blog post (mentioned above already):
SAP EWM MFS Layout-oriented storage control_08
SAP EWM MFS Layout-oriented storage control_09

EWM checks whether any kind of exceptions are set on the source communication point or on the communication point which had been determined as intermediate destination here. We do not want to dive deeper into those exception scenarios here.

The next important step is the validation against the capacity which had been determined before. Note that it is not mandatory to define and check the capacity for each communication point using EWM MFS.

SAP EWM MFS Layout-oriented storage control_10
The capacity calculation here depends on the capacity mode of the given destination communication point (e.g. consideration of HUs with open tasks):.
SAP EWM MFS Layout-oriented storage control_11
SAP EWM MFS Layout-oriented storage control_12
We finalize the logic for the capacity checks here by calling BAdi /SCWM/EX_CORE_LSC_CAPA where you can include a custom logic for evaluating the capacity of the proposed destination:
SAP EWM MFS Layout-oriented storage control_13
We are back at function module /SCWM/TROUTL_DET now and call BAdi /SCWM/EX_CORE_LSC_PRIO. This BAdi is importing the table of possible records which had been read from the customizing before (remember there could be multiple valid ones with different sequence numbers):
SAP EWM MFS Layout-oriented storage control_14
SAP EWM MFS Layout-oriented storage control_15
This BAdi imports a table of valid options and returns one of those options (table in – structure out):
SAP EWM MFS Layout-oriented storage control_16

Potential use cases –
– Manipulate the routing based on the HU type (examine the HU header data which is also imported to the BAdi)
– Equally distribute HUs across areas of the conveyor (while considering the destination of the last WT from the given communication point)

5. Exception handling in case of capacity issues

It is possible that we determined one or multiple valid destinations but they did not pass the capacity check.

In this case we call the Prio-BAdi a 2nd time for those routes where the capacity check failed. If the BAdi does not clear all of those options, we decide based on the exception code determined before whether
– we create a WT for the HU but simply not sent it to the PLC via telegram (this is the default approach > telegram will be sent once capacity is available)
– we create a WT for the HU to move to the clarification bin of the communication point
– we do not create a task at all

SAP EWM MFS Layout-oriented storage control_17

6. Finalization

Finally – if an intermediate step had been determined – the data for the task to be created is collected in the local variables (1).
In case we did not determine an intermediate step (not with and not without capacity), EWM checks whether the destination of the initial/imported WT is customized to be an End-point CP or clarification CP.
If this is the case, no intermediate step is required and the waiting WT can be activated (2):

SAP EWM MFS Layout-oriented storage control_18
SAP EWM MFS Layout-oriented storage control_19
SAP EWM MFS Layout-oriented storage control_20
The same is true in case we are coming from a non-MFS bin and move towards an I-point/infeed:
SAP EWM MFS Layout-oriented storage control_21
SAP EWM MFS Layout-oriented storage control_22
Again, with examples based on our layout:
SAP EWM MFS Layout-oriented storage control_23
SAP EWM MFS Layout-oriented storage control_24
Or in case we are already at a communication point which is customized to be an End-point (outfeed CP) and we are pointing towards a non-MFS bin as a destination (e.g. the HU is about to leave the conveyor):
SAP EWM MFS Layout-oriented storage control_25
SAP EWM MFS Layout-oriented storage control_26
SAP EWM MFS Layout-oriented storage control_27

Only if none of these cases is true, EWM throws an error and holds the waiting WT in inactive status (~ that also means it is mandatory for all other MFS-related movements to provide a record in the LOSC customizing).

So to sum it up again –
EWM will return an error and keep the waiting WT as inactive in case we
– could not find data for an intermediate step (with or without capacity > remember that even without capacity at the destination we might create the task but do not send it to the subsystem yet)
– are not moving towards an End- or clarification point
– are not coming from non-MFS bin pointing towards an I-point/infeed
– are not at an End-point, pointing towards a non-MFS destination bin

7. Change Everything!

The last step after EWM standard has prepared everything to complete the step is the call of FM /SCWM/BADI_STORAGE_CTRL_LAYOUT which calls a potential implementation of BAdi /SCWM/EX_CORE_LSC_LAYOUT. As you can see at the interface, this BAdi imports lots of local data and allows you to change almost everything (~ implement a comprehensive custom routing):

SAP EWM MFS Layout-oriented storage control_28

.This could for instance be used to handle customer/project specific exceptions or integrate routing for more complex automation equipment (e.g. special requirements for AGVs, monorail, robots etc.).

Done!

FM /SCWM/TROUTL_DET is completed and returned the routing decision!

Appendix:
It is important to note that EWM sets an exception code to the HU header in case the determination of the next destination failed (~ a situation where no intermediate destination found and not allowed to activate the waiting task). This exception code stays in the field MFSERROR of table /SCWM/HUHDR and will be evaluated and used for the next routing steps, once the HU arrives at the next communication point (based on this the HU can now route itself step-by-step towards the clarification point).

SAP EWM MFS Layout-oriented storage control_29
SAP EWM MFS Layout-oriented storage control_30

Summary of possibilities for enhancements –

Enhancement spot /SCWM/ES_CORE_LSC holds the three different BAdis which I mentioned during our deep-dive above:

SAP EWM MFS Layout-oriented storage control_31

That is all for this month’s post! I hope you have a good understanding of the layout-oriented storage control now. I you feel overwhelmed I would recommend watching my introduction video about the LOSC in order to tighten your basic understanding of the concept!

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!