Discover SAP EWM MFS
The MFS node in the Warehouse Monitor? (Part #2)
This blog is part of the series ‘SAP EWM meets Automation – Discover EWM MFS’. I will unwrap the MFS warehouse monitor node for you and explain
- what kind of data you can access with each sub-node
- what you can do with the methods given for each sub-node in EWM standard
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!
Before I start with my part I have to mention that some high-level information about the standard MFS nodes is provided here already by SAP:
However, I promise to dig deeper, provide lots of insights that are not given by SAP. Technical details as well as practical examples which will make it easier for you to understand everything.
Having said that, for some of the details that I explain I do expect a base knowledge about the objects used in EWM MFS. If you are a beginner in this area, it is helpful for sure in case you study the following blog posts before you consume this one here:
Within this second part of my blog post about the MFS node in the warehouse monitor I will cover the nodes ‘Handling Unit Move’ until the ‘Telegram Buffer’. If you have missed the first part of this blog post you can find it here.
Handling Unit Move
This node shows ‘rough destination bins’ for HU movements (those are not warehouse tasks!) which are used for routing decisions in case conveyor environments (the concept will not be explained in detail within this blog post).
Only two methods are available here for the user:
Delete HU Move Entries: FM /SCWM/MFS_HU_MOVE_DEL_MON calls FM /SCWM/MFS_HUMOVE_DEL in order to delete records from table /SCWM/MFSHUMOVE for the selected HUs
Create Warehouse Task: Uses FM /SCWM/HU_CREATE_WT_MON in order to open transaction /SCWM/ADHU, pre-filled with data for the selected HU
Conveyor Segment Group
This sub-node does nothing else than showing the conveyor segment groups along with their assigned segments which had been created via customizing. It adds potential exceptions which had been assigned to the segment groups:
Set Exception: Exceptions can be set via the only method here and will make sure that the affected segments are no longer considered for upcoming routing decisions (segments can be assigned to LOSC records):
Technically this is done via FM /SCWM/MFS_CSGR_SET_EXCC_MON, which calls FM /SCWM/MFS_CSGR_SET_STAT to update table /SCWM/MFSCSGR (which holds the conveyor segment group customizing & status) and call the exception handling for the given exception code plus the update of the status for all assigned segments via FM /SCWM/MFS_CS_SET_STAT (~ setting an exception to a segment group will set an exception to all assigned segments).
This sub-node does nothing else than showing the conveyor segments which had been created via customizing. It adds potential exceptions which had been assigned to the segments:
Exceptions can be set via the only method here and will make sure that the affected segments are no longer considered for upcoming routing decisions (segments can be assigned to LOSC records):
Technically this is done via FM /SCWM/MFS_CS_SET_EXCC_MON, which calls FM /SCWM/MFS_CS_SET_STAT to update table /SCWM/MFSCS (which holds the conveyor segment customizing & status) and call the exception handling for the given exception code.
This node shows all MFS resources which have been created via customizing:
Set Exception: FM /SCWM/MFS_RSRC_SET_EXCC_MON updates the exception on the resource via FM /SCWM/MFS_RSRC_SET_STAT which calls FM /SCWM/MFS_EXCCODE_SET for MFS exception handling. The latter triggers the standard exception code processing (incl. follow-up actions, workflow & alert processing etc.). In case this function is used in order remove an existing exception code, EWM calls FM /SCWM/MFS_WT_DET right away in order to potentially find a WT in the queue for the given resource which can be processed (~ telegram can be created and sent to the PLC).
Recalculate WTs: Table /SCWM/RSRC always holds the actual number of open MFS tasks for a given resource in field MFSACCTEL. This information is used e.g. in order to decide whether telegrams for additional tasks can be sent to the resource or not. With this method, FM /SCWM/MFS_RSRC_SET_COUNTER_MON calls FM /SCWM/RSRC_WT_RECALCULATE in order to calculate the number of tasks which are being processed by the resource right now (tasks which are assigned to the resource but not confirmed yet + tasks for the PLC of the given queue which are pending in the outbound buffer (table /SCWM/MFSDELAY) but not acknowledged yet). The FM updates the field /SCWM/RSRC-MFSACTTEL based on the result.
Send Status Request: This method allows the user to send a status request telegram to the PLC. It calls FM /SCWM/MFS_RSRC_QRY_STAT_MON which prepares everything in order to send a telegram via FM /SCWM/MFS_SEND (check this blog post in order to learn what happens within FM /SCWM/MFS_SEND). The result could look like shown in the screenshot below (CRQ is the status request from EWM to the PLC and CSR is the status telegram with the answer from the PLC to EWM > note that the telegram type will differ depending on the subsystem vendor):
Trigger Telegram Processing: User FM /SCWM/MFS_RSRC_WT_DET_MON in order to call FM /SCWM/MFS_WT_DET_PREP to check explicitly for the queue of the given resource whether there is a telegram for any of the WTs in the queue can be sent to the subsystem
Telegram Buffer – Incoming Telegram
This node shows the content of the inbound telegram buffer (~ content of table /SCWM/MFSTELEQ):
The method button gives us the option to
Edit: Opens a pop-up which gives the option to modify the waiting record in table /SCWM/MFSTELEQ
Delete: Remove the record from the buffer table via /SCWM/MFS_MFSTELEQ_DEL_MON
Process Telegram: Trigger processing for the incoming telegram via FM /SCWM/MFS_PROCESS_TELE_Q
Check this post in case you want to learn more about telegram processing in EWM and the usage of the telegram buffer for incoming telegrams.
Telegram Buffer – Outgoing Telegram
This node shows the content of the inbound telegram buffer (~ content of table /SCWM/MFSDELAY):
The method button gives us the option to
Edit: Opens a pop-up which gives the option to modify the waiting record in table /SCWM/MFSDELAY
Delete: Remove the record from the buffer table via /SCWM/MFS_MFSDELAY_DEL_MON
Process Telegram: Trigger telegram processing via /SCWM/MFS_SEND
Check this post in case you want to learn more about telegram processing in EWM and the usage of the telegram buffer for outgoing telegrams.
…and this node closes my 2nd blog post about the MFS nodes in the EWM Warehouse Monitor.