Discover SAP EWM MFS

The Identification-Point

This blog is part of the series ‘SAP EWM meets Automation – Discover EWM MFS’ and also tackles the hardware but mainly the software side of this thing that we call ‘I-Point’ (Identification-Point) in the area of EWM MFS.
Note that I will not explain every MFS object again here. In case you are not familiar with EWM MFS already, I would recomment reading the EWM-PLC integration blog post at first.

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 https://wmexperts.online/dating-a-florist/ in case you want to learn more about the services offered by @ Swisslog or to browse open positions within their EWM team!

Agenda

– Overview process flow at the I-Point
– The hardware of the I-Point
– The EWM part of the story

As an introduction, let us have a quick look at a high-level overview about the process/context we are talking about within this blog post. To have a practical context again, we assume that we are looking at a pallet which is moving on a conveyor, passing an I-Point. Physically, it could look like this:

The following things will happen now: – The HU/pallet arrives at the I-Point and is detected by the sensors – The sensors trigger the activation of other sensors, scales, scanners etc. – The subsystem (PLC) collects all relevant data (e.g. results of the weighing and scanning events) and processes it based on the logic sitting in its memory. As a result we have a string of data which is transmitted to EWM as a telegram – EWM receives & processes the telegram and in turn sends another telegram in order to initiate the follow-up process (e.g. creates a task to move the pallet to its next destination and sends the telegram for this task to the PLC) – The PLC receives the telegram, processes it and e.g. decides to start the motor unit for the conveyor moving the pallet away from the I-point:

Note that this process will be slightly different in a fast moving case conveyor environment but for the sake of understanding the I-Point concept in general, we will ignore this for now. Having a rough understanding of the process we are talking about, let us now have a quick look at the hardware of a typical I-Point. Being used for identification, an essential part of an I-Point is a device which reads data from the object/HU passing by. This could be a barcode scanner reading a label or a RFID scanner reading a tag or any other kind of identification method. In addition to this we have plenty of optional checks/devices installed at an I-Point. Examples are sensors for profile checks (e.g. length, width, height), scales for weighing or tunnel/roller checks to validate the quality of a pallet.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.

On the other side – and a bit more interesting for us – we have the software. Here we are mainly talking about the creation and processing of telegrams by the PLC/WMS (here SAP EWM):

Starting with the creation of the telegram by the PLC, we can separate the high-level steps on EWM side into the following ones: – Receive a telegram in the inbound buffer – Find a MFS action function module to process the data – Execute this FM – Close the FM with the creation of a follow-up action / task

Step 1 can be subdivided into the following steps: – The data is received via ABAP Push Channel or a TCP/IP-RFC converter like PlantConnectivity, from where FM /SCWM/MFS_RECEIVE2 is being called – The FM writes the data into inbound buffer table /SCWM/MFSTELEQ – FM /SCWM/MFS_PROCESS_TELE_Q picks up the data from here and processes it > The processing of the telegram starts in our flow-chart at Step 2

.We will now look into this Step 2 in detail:

At the beginning, EWM reads the telegram data from the buffer table via FM /SCWM/MFS_PROCESS_TELE_Q calling /SCWM/MFS_TELE_Q_READ_UPTO:

EWM is then searching for a function module which should be used to process the given telegram. Function group /SCWM/MFS_ACT is holding all standard function modules for telegram processing:

But how does EWM now decide which one to use?

The answer to this question is sitting in FM /SCWM/MFS_DET_ACTIONFM which reads the action determination customizing:

The customizing is pretty simple here. You define actions and assign function modules for processing.

. In the 2nd step you maintain the determination of those actions based on warehouse number, communication point type (taken from the communication point customizing), resource type (in case a resource like a crane is involved in the process) and telegram type:

In the screenshot above you see the enhanced version of the I-point telegram processing which is used by the Swisslog team. EWM standard instead calls FM /SCWM/MFSACT_SP here:

This is true at least for slow moving pallet environments. We will keep focusing on this for now and come back to case environments later again. Note: Have a look at this slow jams love dating site in case you are struggling to understand terms like ‘communication point’ and want to get familiar with the MFS basics at first! Having determined the function module for telegram processing, we can now start to actually process the telegram:

That means, within the following paragraphs I will answer the question about what actually happens within FM /SCWM/MFSACT_SP (not every detail but the most important steps). And again – yes there is a different FM for case conveyors but they do not differ that much and we keep focusing on the pallets here in order to gain a basic understanding!

Step 3.1: Validate the HU
EWM tries to figure out whether the HU does actually exist. If not, a dummy HU is created (dummy packaging material assigned to a dummy number range) and the HU is later sent towards clearing:

Step 3.2: Adjust the location In this step EWM posts the HU to the storage bin which is assigned to the i-point / communication point (table /SCWM/MFSOBJMAP). This is done via FM /SCWM/MFS_HU_ADJ_LOC which validates lots of different scenarios like shown in the 2nd screenshot below (based on the customizing of the i-point, the source/destination of the HU and potential waiting/active WTs) and calls BAdi /SCWM/EX_MFS_HU_AT_CP where you can also implement a custom logic for the acceptance/decline of a location adjustment (e.g. include a check for doublets):

Step 3.3: Call BAdi /SCWM/EX_MFS_ACT_SP

This BAdi can be used to change HU data (e.g. adjust the HU type based on the height measured by the I-point sensors), execute additional checks (e.g. compare subsystem with EWM data) and/or provide a destination bin (as part of the last step below EWM will create a follow-up WT and this BAdi can be used to set the destination of this WT):

Step 3.4: Update HU data

Based on the data that we received from the subsystem or determined within the previous steps, EWM now updates the HU header data via FM /SCWM/HUHDR_ATTR_CHANGE:

Final step (Step 4) –

Although the creation of the follow-up action (WT creation) technically also happens within FM /SCWM/MFSACT_SP, I decided to show this as a separate step in our flow-chart. Makes sense from my point of view logically and also makes it easier to keep an overview.

No matter whether we are going to reject the HU towards clearing or whether we want to push it towards a final putaway bin, we need to create/activate a HU warehouse task. This is done at the end of our action FM by calling FM /SCWM/TO_CREATE_MOVE_HU.
As mentioned above, the destination might have been determined by a Z-logic in BAdi /SCWM/EX_MFS_ACT_SP already and filled into structure ls_create_hu. The warehouse process type to create the task is taken from the communication point customizing (so in case you do not determine a destination in the BAdi mentioned above, EWM will simply read the STSS and putaway rules based on the combination of this WPT and the standard customizing):

.Summary of the things happening within the action function module /SCWM/MFSACT_SP

– Validate HU (check whether HU number is filled and exists in EWM)
– Call FM /SCWM/MFS_HU_ADJ_LOC (+ Badi) to post the HU to the CP of the I-point (or reject it)
– Call Badi /SCWM/EX_MFS_ACT_SP in order to set the destination or change the HU type
– Update HU weight, dimensions and/or other header data via FM /SCWM/HUHDR_ATTR_CHANGE
– Create a WT in order to move the HU away from the I-point (/SCWM/TO_CREATE_MOVE_HU)

Appendix
As promised above, some final words about the differences in handling/processing between pallet (~ slow moving) and case (~ fast moving) environments. Note that I am only touching the surface with these comments. There is complex coding involved with lots of differences compared to the pallet environment, which are not in scope of this article.
In general though, the role of the I-point is similar to the one in a pallet environment (EWM provides FM /SCWM/MFSACT_CASE_SP for processing and a couple of other BAdis). In addition to this we have –
– ‚Rough‘ decisions in order to enable fast routings without interruption (so a slightly different way of Layout-oriented routing)
– Rough bin determination (with temporary records in /SCWM/MFSHUMOVE and planned routings based on AAs)
– ‚Planned routing‘ telegrams (PLC knows upfront > ATF (‘After The Fact’) posting in EWM based on the decision of the PLC)
…as I said – enough keywords to create separate posts about this topic but everything not essential in order to understand the setups, concepts and processes at & around Identification-Points!

Closure
For more technical details about the process of receiving telegrams in EWM MFS, make sure you read this wonderful how do you know you are dating the right man written by Tobias & Jörg!

That is all for this month’s post! I hope you are familiar with the concept of the I-point now.

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!