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 website 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:
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
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:
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.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 blog post 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!
