Discover SAP EWM MFS
Deep-dive Layout-oriented Storage Control (LOSC)
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:
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 / video 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 website 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:
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:
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 ):
.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).
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.
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
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):
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):
.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).
Summary of possibilities for enhancements –
Enhancement spot /SCWM/ES_CORE_LSC holds the three different BAdis which I mentioned during our deep-dive above:
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!
