Quality Management in SAP EWM: The Engine Embedded EWM Doesn’t Use

Leer este post en español →

«It’s EWM, so it uses the Quality Inspection Engine.» Say that in a room with both embedded and decentralized EWM people in it, and half the room will nod and half will quietly disagree — because embedded EWM does not use the Quality Inspection Engine at all. Not a limited version of it, not a wrapper around it. It talks directly to S/4HANA’s own quality management, and the engine that decentralized EWM leans on for every inspection it runs is simply absent.

That single fact is why «quality management in EWM» is really two different technical stories wearing the same name, and why the map from the first post in this series had to mark, box by box, which architecture each mechanism actually belongs to.

What the Quality Inspection Engine Actually Is

Decentralized EWM runs its inspections through a component called the Quality Inspection Engine (QIE) — a service-oriented framework built to let different EWM objects (deliveries, stock, handling units) trigger inspections through a common mechanism, capture results, and fire follow-up actions, optionally handing detailed result-recording off to an external quality system.

Two tables anchor it. Inspection object types — the categories this whole series is organized around — live in QIE_IOBTYP. Inspection rules, which decide the actual behavior for a given object type (what samples get drawn, what the possible findings are, where the inspection happens), live in QIE_IRULE.

Eight Inspection Object Types, Two Architectures

Not all eight exist for you, and which ones do depends entirely on whether you are running embedded or decentralized EWM.

Three deprecations define what embedded EWM gave up against the QIE. IOT1 — a high-level accept/reject check on a whole inbound delivery, confirmed automatically by any logistical posting and needing manual action only to reject — is gone, because S/4HANA’s own quality management already does delivery-level gating without it. IOT2, plain counting with no effect on stock attributes beyond a quantity correction, is gone the same way. IOT6, preliminary handling-unit inspection, is gone too — worth its own section below, because it is the one with a real RF transaction behind it.

IOT7, defect processing, is not the embedded-exclusive addition it is sometimes made out to be. It started there — S/4HANA 2020 — turning a defect found on the floor into a quality notification instead of only a stock posting. Decentralized EWM picked it up three years later, in S/4HANA 2023, but with one restriction that survives to this day: only embedded EWM can hand a defect off to a quality notification. Decentralized gets the three direct follow-up actions from the defect app itself — post to blocked stock, post to unrestricted stock, scrap to a cost center — and stops there.

IOT8 — Q-Inspection Outbound — is the outlier in this table: the only one of the eight that runs identically on both architectures, because what it actually triggers is ERP-side SD-QM, not the QIE. It only exists from S/4HANA 2025 FPS1 onward, and the map that opened this series covers exactly how it works and why almost no system running today has it yet.

Preliminary Inspection HU — the one built entirely for RF

IOT6 is a different kind of inspection from the other seven: there is no planning phase completed by a decision the way a product inspection works. It is a package-condition check, run before goods receipt, on every handling unit of an inbound delivery — good or bad, nothing in between at this stage.

It exists only as an RF transaction. There is no desktop equivalent to fall back on: each handling unit gets scanned and marked good or bad, and only once every HU in the delivery has been scanned does the system create a single inspection document covering all of them, with one item per handling unit carrying its scanned result. Goods receipt is then posted for every handling unit according to that result — the contents of anything scanned bad land in blocked stock automatically, no separate decision step required.

The Numbering Scheme That Tells You Where an Inspection Came From

SAP S/4HANA’s own quality management uses its own inspection types — 01, 04, 08, 09 and others — for inspections it originates itself. EWM does not reuse those numbers directly. Instead, for every inspection EWM triggers, S/4HANA quality management gets a mirrored type with the same base number and the prefix 17 attached.

The 17 prefix is not decoration — it is the marker that this inspection lot did not originate inside S/4HANA quality management itself. It came from an external system, and in this context «external» means EWM, whichever architecture is running it. The same prefix scheme applies to both embedded and decentralized EWM, because in both cases it is EWM asking quality management to open an inspection lot, not the other way around.

One Architectural Habit Worth Learning: The S4 Suffix

EWM’s quality inspection code is built on a service adapter framework: a superclass carries behavior shared across both architectures, and a subclass per architecture — an «adapter class» — implements the parts that differ. The naming convention is consistent enough to be genuinely useful when you are staring at a stack trace and need to know which world you are in.

Classes built for embedded EWM carry the _S4 suffix almost without exception. It is a small thing, but it means that when you are debugging a quality issue and you see a class name ending in _S4, you already know you are looking at code that talks to S/4HANA quality management directly — not the Quality Inspection Engine — before you have read a single line of its logic.

Hands-On: Standing Up an Inspection Object Type from Nothing

This is the sequence for decentralized EWM, since it is the architecture where inspection object types and rules are the whole game. IOT4 (goods receipt inspection) is the one worth practicing on, because every later post in this series that touches Customizing assumes you have done this once.

1. Define and activate the warehouse-dependent IOT. SCM Extended Warehouse Management → Extended Warehouse Management → Cross-Process Settings → Quality Management → Basics and Integration → Define and Activate Warehouse-Dependent IOTs. Enter 4 in the Insp. Obj. Type field for your warehouse number and switch on the settings your process needs.
2. Generate a version. Same menu, → Generate Inspection Object Types Version. Select the IOT4 line and generate a new version — this is the step that is destructive to anything generated before it, so do it once you are sure of the warehouse-dependent settings.
3. Activate the version. → Maintain Inspection Object Types Version. Select the version you just generated and check Activ. IOT. Nothing gets created against an inactive version.
4. Build the inspection rule. SAP Easy Access → Logistics → SCM Extended Warehouse Management → Master Data → Quality Management → Maintain Inspection Rule — or Transaction /SCWM/QRSETUP directly. Create a rule for IOT4, in Form view, and attach the determination attributes your process needs (document type, product, whatever your Customizing exposes). Without a rule the object type is active but nothing ever matches it, and no inspection document ever gets created.
5. Confirm it actually fires. Transaction /SCWM/QRSIM simulates inspection rule determination against a set of attributes before you touch a real delivery — use it before trusting the rule against live stock.

What Comes Next

The map named eight mechanisms and where each one lives. This post named the engine behind six of them, the S/4HANA quality management behind the other two, and the one — IOT6 — that only exists as an RF scan. The next four posts go one mechanism at a time: counting that looks the same from the floor but is not, sampling that can stop a truck next to sampling that cannot, a field that stopped being yours to edit, and a date nobody typed in by hand.

---