Quality Inspection Engine

You use quality management to check whether delivered products satisfy

your quality criteria. QM uses the Quality Inspection Engine (QIE) to
map these inspection processes in SAP Extended Warehouse
Management.
When you receive goods into your warehouse, you might want to examine
the products in order to confirm if the vendor has sent you the right
quantity and quality.
Depending on your decision of the inspection, you might putaway the
products as planned or return them to the vendor.

In the QIE architecture, the term QIE

consumer is used to refer to an
application that makes use of the
QIE functionality. The QIE consumer
is generally an independent system
that is linked to the QIE via a qRFC
and/or XI interface.
But it can be a part of the consumer
system, such as SCM 7.0 (EWM).
QIE is independent, however, from
the ERP system. It can be connected
to an external ERP system for a
complete QM process.
The development platform for the
QIE is the Web Application Server
(WAS).
QIE is an engine technically
designed as an Add-On. EWM is the
first consumer system and uses QIE
as a required Add-On.

QIE is technically designed as an add-on for use in a heterogeneous

system landscape.
When the QIE was introduced to the SCM environment, execution of
inspections within SCM could be supported.
The QIE consumer as an independent system is linked to the QIE via a
qRFC or PI interface and makes use of the QIE functionality. The QIE can
also be part of the consumer system, as is the case for EWM. QIE is
independent from the ERP system, but ERP can be linked to QIE via qRFC.
The development platform for the QIE is the Web Application Server
(WAS).

Inbound Process with Inspection

Quality checks can be performed at different stages: the first pre-check is
executed when the transportation unit arrives at the door. Does the
delivered handling units look intact? If the transportation unit is unloaded,
the palette can be checked and moved to a work place where it can be
unpacked. From there the palette is routed to an inspection work place
where the delivered material is checked or it is putted away to the final
storage bin or sent back to the vendor.
What inspections are being done is controlled by the inspection object
type. The inspection object type defines in which software component, in
which process and for which object the inspection documents can be
created in the QIE. The Inspection object types for EWM are pre-created by
SAP. In Customizing they are activated per warehouse number. Only then
inspections are possible.
While preliminary inspections happen on the truck or after unloading in the
goods receipt area, other inspections happen on a work center and require
process oriented storage control.
Another requirement for inspections are inspection rules. An inspection
rule describes more detailed for what an inspection shall be done (for
example for a material, delivery types, or deliveries from a specific vendor)

If you want to check products, packaging, or transports, you can perform

the following inspections:

A
A
A
A
A
A

preliminary inspection of an inbound delivery

preliminary inspection of a handling unit
counting of inbound delivery items
quality inspection of products from an inbound delivery
quality inspection of products from a returns delivery
quality inspection of products that are in the warehouse

This different inspections are controlled by inspection object types

(IOT). Inspection documents, which describe the inspection object, can be
created automatically or manually. If the inspection object type is active,
the system looks for an inspection rule.
It can only generate inspection documents if you have created an
inspection rule. If the system finds an inspection rule, it creates the
inspection document.

Inspection Object Types

Inspection object types (IOT) define the software component, process,
and object in which you can create inspection documents in the Quality
Inspection Engine. In the case of an active IOT, the system looks for an
inspection rule.

IOT Preliminary Inspection Inbound Delivery

If you activate an inbound delivery notification, the system automatically
generates an inspection document for checking complete deliveries.
The system requires an inspection rule for the current version of the
inspection object type and warehouse number.
The inspection document is automatically released when being created,
so that it is already available when the goods physically arrive.
The document cannot contain samples or items and is stored as a
reference document for
the delivery header in the delivery.

IOT Preliminary Inspection Handling Unit

Inspection documents for HUs cannot be scheduled in advance. You can
only create them manually for the HU inspection using RF.
For each delivery of a complete commercial truck (with multiple
deliveries), you can classify all HUs as good or bad. When you have
classified all the HUs, the system automatically creates the HU
inspection document.
In doing this, it generates one inspection document for each delivery
and one item for each HU in this inspection document. You can also
decide this directly for the good HUs. You then manually process the
bad HUs in an additional process in the inspection document.
Since you always create this inspection document manually, it makes
sense to create only one inspection rule for the warehouse number and
version of the inspection object.

IOT Counting Inbound Delivery

The system creates this inspection document automatically, depending
on Customizing for the inspection document creation within inbound
delivery processing.
The system releases it when it creates it. Counting is always a 100%
inspection, since counting samples is irrational.
IOT Q-Inspection Returns Delivery
Providing you have not already defined the usage of returns in SAP
Customer Relationship Management (SAP CRM), the system calls the
inspection at the defined point in time, determines an inspection rule,
and checks the dynamic modification rules.
The inspection document is automatically generated but released with
the first goods receipt posting. The inspection quantity is determined
from the deliver quantity. If the inspection rule contains a sample-drawing
instruction, the system generates corresponding samples for the
inspection document.

IOT Q-Inspection Product/Batch Inbound Delivery

Also here the inspection document is automatically generated but
released with the first goods receipt posting. The inspection quantity is
determined from the deliver quantity and if the inspection rule contains a
sample-drawing instruction, the system generates corresponding samples
for the inspection document.

IOT Q-Inspection Product/Batch Warehouse-Internal

Warehouse-internal inspection documents can only be created manually,
using either the RF environment or desktop transactions. You can create
inspection documents for all products in a work center or HU, or restrict
the inspection to a particular product.

Inspection Rules
Inspection rules are dependent on the inspection object type, warehouse
number, and version of the inspection object type.
Inspection rules contain the following parameters:
Check criteria, such as material being checked, quality inspection
group being checked, and supplier (in the properties section)
Type of inspection (sample inspection, 100% inspection, or no
inspection)
Possible decisions, findings, and follow-up actions

Decision codes
With decision codes you describe if a sample is being accepted, what
quality score is given, and what follow-up action is to be taken. The
decision codes are arranged in code groups, which are then assigned to
the inspection rules.
Findings
When you process an inspection document, you can record the results of
the inspection as characteristic values or findings. A defect is any
property of an object or process that does not fulfill the specifications of
an inspection characteristic.
You record the defects using predefined defect codes that you have
defined in Customizing. Whether findings are necessary depends on the
object being checked and
the inspection process
Follow-up actions
You can use logistical follow-up actions to trigger follow-up processes
such as putaway, scrapping, stock transfer, or return delivery. Logistical
follow-up actions are only available for the quality inspection of
products. Logistical follow-up actions generate warehouse documents
and warehouse tasks.

Inspection Decision
In the end you have to make a decision to accept or reject the object
being inspected. The inspection decision contains the results recording
and follow-up action recording, and the inspection completion.
For inspection documents of the inspection object type Preliminary
Inspection Inbound Delivery, the result is the acceptance or rejection of
the delivery.
For inspection documents for HUs, you decide whether the contents of
the HU are now to go through a standard goods receipt process, or
whether you post them to blocked stock.
For product inspection documents, the result can be acceptance, return
delivery, stock transfer, or scrapping.
You complete the inspection by making the usage decision.

Using ERP Quality Management

Working with ERP inspection plans you can use the QIE-QM-integration to
integrate the ERP quality inspection into EWM.
The QIE determines the relevance for a quality check and, based on the
Inspection Object Type and the inspection rule, an inspection document is
created and, depending on the inspection procedure, a sample. This
document is transferred to ERP-QM.
In ERP-QM the usage decision is made per item and transferred to QIE
where a follow-up action is triggered.

Quality Inspections in EWM Using an External QM System = ERP

If you require a more complex or full-blown quality management process,
the QIE can be connected to an external QM system, such as SAP ERP QM.
This way you can cover detailed analytical inspections with
characteristics.
The inspection process when the QIE is connected to ERP QM is as
following:
Within the activation of an inspection document in EWM, the QIE triggers
the creation of an inspection lot in ERP QM. The inspection process is
executed in the external system, that is, the ERP QM system. ERP QM
sends back
the usage
decision to the
after
is done.
Special
settings
and requirements
for QIE
using
ERPthe
QMinspection
as external
QM
system for the QIE are:
For checks that are triggered by an external system, SAP delivers the
inspection lot origin 17. Select this inspection lot origin. For samples that
are created externally, SAP delivers sample type 10.
The BADIs QPLEXT_COMM_TEC on ERP side and
QIE_EX_COMMUNICATION in the QIE have to be implemented according
your requirements.
Note: For details, see SAP Note 1278425 Connecting ERP QM to EWM.

nerate Inspection Object Types Version (Just check, do not make any changes)

Warehouse-Dependent Activation of Inspection Object

Type

Define Item Types (No changes should be done)

Define Finding Types

Define Decision Codes

Maintain Follow-Up Action

SCWM/QRSETUP - Maintain Inspection Rule

reate Inspection documents for Count and QI for couple of parts

Create POSC
Add process steps
Maintain Source and destination for count and QIS steps
Maintain Count and QIS Workcenters
Create a new WPT for count and QIS
Create Process type determination indicator
Determine WPT
Maintain STSS
Now test a scenario with count and a scenario with QIS

Thank You