Quality inspection in SAP EWM using RFUI

rafael_brustolin1 · ‎2024 Nov 29

Imagine the following scenario: an end-user is performing stock removals using RF gun with SAP EWM, and notice a possible damaged stock in some near storage bin. The user wants to continue the picking for operational performance reasons, following the determined picking route, but also needs to somehow register the situation and trigger a quality inspection process.

In this blog post, I will explain a standard business process to satisfy this requirement, triggering a QM process for a possibly damaged stock, making it unavailable for picking Warehouse Task creation until a usage decision is made.

Additionally, I will also cover specific Decentral EWM Quality Management inspection processes which differentiate very significantly from Embedded EWM capabilities from RFUI perspective.

1. Introduction

Both Embedded and Decentral deployments of SAP EWM offer the possibility of using ERP QM engine for inspections, but Decentral option also offers the possibility of using EWM QIE (Quality Inspection Engine) alone, which may run independently from SAP ERP. EWM QIE offers different capabilities when compared to S/4HANA QM.

The focus of this blog is the quality inspection process using RFUI, and not the QM configuration itself. I recommend reading the reference documentation at the end of this blog for an explanation of Quality Management within SAP EWM.

The biggest difference from RF perspective is that Embedded EWM only allows the creation of the inspection document from RF (either product or HU), while Decentral EWM allows the recording of inspection decisions directly in RF. This is explained in the SAP Note 2861813 - "Quality Management (QM) in embedded EWM S/4HANA system".

2. Required Configuration

If you are running Decentral EWM in SAP S/4HANA 2021 or higher, before you start any configuration, make sure that the manual steps of the SAP Note 3282994 - "Adjust visibility of RF-QM transactions" are followed. The visibility of the logical transactions QMCOUM, QMCOUN, QMDHAS, QMDHHU, QMDHTU, QMDHVE, QMHUAS, QMHUCL, QMHUDV, QMHUHU, QMHUTU, QMHUVE, QMLOGN, QMPD**, QMPDHU, QMPDID, QMPDPR, QMPDSB and QMPDSD must be set to 'F' as per screenshot below:

As explained above, the focus of this blog is not QM configuration, but the usage of RFUI transaction to run QM processes (e.g. start of an inspection process using Radio Frequency). To begin with, we need to activate the required logical transactions using transaction /SCWM/RFMENU for our presentation and personalization profiles:

Note that it is not recommended to change the standard presentation and personalization profiles.

The menu that contains our target logical transactions is QMMAIN. By using drag and drop functionality we can easily add this menu to our profile:

The next step is to ensure that we are accessing the RFUI with those profiles. The presentation profile is assigned to a warehouse in SPRO path SCM Extended Warehouse Management -> Extended Warehouse Management -> Mobile Data Entry -> Radio Frequency (RF) Framework -> Define Steps in Logical Transactions -> Assign Presentation Profile to Warehouse:

The personalization profile is assigned to a user in /SCWM/USER transaction:

Upon doing that, we can see that /SCWM/RFUI already shows QM related menus and logical transactions:

Configure and activate Exception Code CRID for the target warehouse in SPRO path SCM Extended Warehouse Management -> Extended Warehouse Management-> Cross-Process Settings -> Exception Handling -> Define Exception Codes:

Beyond the configuration described above, all QM configuration is required for the each target Inspection of Type (IOT), which is not covered in this blog post.

For a deep dive into the required configuration for decentral EWM, refer to How to Guide | How To Configure Quality Management Processes for Decentralized EWM Based On SAP S/4H.... For Embedded EWM, refer to the How to Guide | How To Configure Quality Management Processes for Extended Warehouse Management Embed....

3. QM in Embedded EWM vs Decentral EWM - Demo

While Embedded EWM has IOTs 3*, 4 and 5 available for usage, Decentral EWM support the following list:

IOT 2: Counting Inbound Delivery
IOT 3: Q-Inspection Returns Delivery
IOT 4: Q-Inspection Product/Batch Inbound Del.
IOT 5: Q-Inspection Product/Batch Whse-Internal
IOT 6: Preliminary Inspection Handling Unit

*integrated to the Advanced Return Management (ARM) - See SAP Note 2783648 - Returns inspection process in embedded EWM in SAP S/4HANA.

IOT 1 (Preliminary inspection inbound delivery) is not supported in EWM on S/4HANA (Neither Embedded nor Decentralized).

Understanting this feature difference is important for the next steps of this blog post, as here the main difference between Embedded and Decentral EWM capabilities in regards to mobile QM inspection appear. While in Decentral EWM there is wider range of logical transactions available, including the execution of the inspection process istelf with usage decisions, in Embedded EWM only the creation of the ad hoc inspection document is possible from RFUI, then the inspection execution happens in SAP GUI transactions (e.g. QA02) and Fiori Apps (e.g. Manage Usage Decisions).

The following Quality Management RFUI menus are available for Embedded EWM:

This menu is used to trigger the creation of an ad hoc inspection document, which may immediatelly post the stock to quality stock type depending on the configuration.

The difference between product and HU inspection lies in the object used to search for stock in a given product/batch. By using storage bin inspection, for example, you may inspect a product/batch in a storage bin regardless of the HUs packaging the stock - the entire stock for that material and batch in the entered storage bin is subject for quality inspection process. In the other hand, HU inspection looks only for stock quantities for the product/batch within the informed HU. See next an example for the storage bin option.

Enter Storage bin:

Enter Product/Batch and specify exception code CRID (Create Inspection Document):

See the Inspection document created:

In this example, the stock is automatically moved to quality stock type and can't be used for picking, for example, until a usage decision is made:

In Embedded EWM, there is no way of performing usage decision directly in RFUI. Instead, you need to use either SAP GUI transaction or standard FIORI apps for the mobile execution.

The following Quality Management RFUI menus are available for Decentralized EWM:

As you can see here, beyond "Product Inspection" menu, which is already explained above, we have 3 additional menus available, which only can be seen in a Decentral EWM installation:

HU Inspection with GR Posting

This menu splits in the following options:

This is the menu for Preliminary HU Inspection. The idea here is to search by HUs from inbound process using different objects (ASN, Delivery, HU, TU or Vehicle). When the object is inserted, the system looks for all the deliveries and respective HUs contained on it. Then, it's required to inform all "good" and "bad" HUs as per the following screenshots:

"Bad" HU scanning:

"Good" HU scanning:

F1 button switches from "good" to "bad" HU scanning and vice versa. Attention: It may be required to change screen to adjust "No.Sat.HUs" text as this represent satisfactory HUs in reality (Sat.HUs.).

Upon scanning all HUs, the system posts GR and creates the inspection document only for the satisfactory HUs. The unsatisfactory HUs are not received and therefore are not subject to inspection. This is the benefit of the preliminary inspection - no time is lost receiving, inspecting and eventually reversing GR for HUs that are clearly out of quality standards.

See next the outcome of this process. Received HUs:

Inspection document created:

Product Inspection Decision

Here we have the capability to record decisions for the different IOTs by logging to a work center. For example, we may record the decision for a Quality Inspection document using "Decision by Inspection Document":

Attention: Recording decisions as described above only works if the QIE is not integrated to ERP QM, otherwise the usage decision must be done in SAP ERP side.

QM Counting

This menu is used for QM counting process (IOT 2), which ensures the quality of inbound deliveries by verifying that quantities entered in the system match the physical quantities. It serves as a quality assurance step in the goods receipt process.
Upon changing or activating an inbound delivery notification, the system checks if counting is required by evaluating the inspection object type and rule. If valid, the system creates an inspection document and marks the delivery item for counting. The counting can be done in 2 ways:

Explicit counting: Enter count results manually at the counting station, applicable to handling units.
Implicit counting: The warehouse task data triggers counting. If differences are detected, the task must be confirmed with an exception code, applicable to unpacked products.

4. Final Considerations

The decision between Embedded vs Decentralized EWM needs to consider all the known differences between the deployment options, such as business fit (that's it, available functionalities in each deployment version), volume and performance, downtime planning, operation risk and long-term IT costs. Quality Management is part of the business fit evaluation criteria. Many other functionallities may be priorital for the decision over QM, but this certainly depends on the business segment and requirements. For example, pharmaceutical industries with high transactional volume would choose Decentral EWM, and may also benefit from the QM advantages of this deployment option.

While Embedded EWM offers simplified QM model by integrating S/4HANA QM engine directly, Decentral EWM offers a wider range of capabilities which come from QIE that exists since old SCM versions of EWM - including the possibility of performing inspection process apart from SAP ERP.

Mobile usage decisions using RFUI may be an advantage over Embedded EWM, but with the evolution of the FIORI apps in QM area, over the time this advantage becomes less expressive. In the other hand, the IOTs available only in Decentralized EWM may be a key factor for the final decision.