«Es EWM, así que usa el Quality Inspection Engine.» Dilo en una sala con gente de embedded y de decentralized EWM a la vez, y la mitad asentirá y la otra mitad discrepará en silencio — porque embedded EWM no usa el Quality Inspection Engine en absoluto. Ni una versión limitada, ni un envoltorio alrededor de él. Habla directamente con el quality management propio de S/4HANA, y el motor del que depende decentralized EWM para cada inspección que ejecuta está simplemente ausente.
Ese único hecho es la razón por la que «quality management en EWM» son en realidad dos historias técnicas distintas con el mismo nombre, y por la que el mapa del primer post de esta serie tuvo que marcar, caja por caja, a qué arquitectura pertenece de verdad cada mecanismo.
Qué Es Realmente el Quality Inspection Engine
Decentralized EWM ejecuta sus inspecciones a través de un componente llamado Quality Inspection Engine (QIE) — un framework orientado a servicios construido para que distintos objetos de EWM (entregas, stock, handling units) disparen inspecciones a través de un mecanismo común, capturen resultados y disparen acciones de seguimiento, delegando opcionalmente el registro detallado de resultados a un sistema de calidad externo.
Dos tablas lo sostienen. Los inspection object types — las categorías sobre las que gira toda esta serie — viven en QIE_IOBTYP. Las inspection rules, que deciden el comportamiento real para un object type dado (qué muestras se sacan, cuáles son los findings posibles, dónde ocurre la inspección), viven en QIE_IRULE.
El detalle que pilla a la gente desprevenida
Los inspection object types no vienen listos para usar. Hay que generarlos por sistema, y generar uno es destructivo con lo que había antes: cambia la definición de un inspection object type y cada documento de inspección ya creado bajo él pasa a ser de solo lectura. El Quality Inspection Engine trata la nueva definición como un object type genuinamente distinto — por eso existen las versiones. Los documentos antiguos siguen siendo visibles; simplemente dejan de poder procesarse.
Ocho Inspection Object Types, Dos Arquitecturas
No los ocho existen para ti, y cuáles sí dependen por completo de si estás en embedded o en decentralized EWM.
Tres bajas definen lo que embedded EWM perdió frente al QIE. IOT1 — un chequeo de aceptar/rechazar a alto nivel sobre toda una entrega entrante, confirmado automáticamente por cualquier contabilización logística y que solo necesita acción manual para rechazar — desaparece, porque el quality management propio de S/4HANA ya hace ese control a nivel de entrega sin necesitarlo. IOT2, conteo puro sin efecto sobre los atributos de stock más allá de una corrección de cantidad, desaparece igual. IOT6, inspección preliminar de handling unit, también desaparece — merece su propio apartado más abajo, porque es el que tiene una transacción RF real detrás.
IOT7, defect processing, no es la incorporación exclusiva de embedded que a veces se cuenta. Empezó ahí — S/4HANA 2020 — convirtiendo un defecto hallado en planta en una quality notification en vez de solo una contabilización de stock. Decentralized EWM lo incorporó tres años después, en S/4HANA 2023, pero con una restricción que sigue vigente hoy: solo embedded EWM puede pasar un defecto a una quality notification. Decentralized se queda con las tres acciones de seguimiento directas de la propia app de defectos — contabilizar a blocked stock, a unrestricted stock, o hacer scrap a un centro de coste — y ahí se para.
IOT8 — Q-Inspection Outbound — es la excepción de esta tabla: el único de los ocho que corre idéntico en ambas arquitecturas, porque lo que dispara de verdad es SD-QM del lado ERP, no el QIE. Solo existe desde S/4HANA 2025 FPS1, y el mapa que abrió esta serie cubre exactamente cómo funciona y por qué casi ningún sistema en producción hoy lo tiene todavía.
Preliminary Inspection HU — el que se construyó entero para RF
IOT6 es un tipo de inspección distinto de los otros siete: no hay una fase de planificación que se cierre con una decisión, como en una inspección de producto. Es un chequeo del estado del paquete, ejecutado antes de la recepción de mercancía, sobre cada handling unit de una entrega entrante — bueno o malo, nada intermedio en esta etapa.
Existe únicamente como transacción RF. No hay equivalente de escritorio al que recurrir: cada handling unit se escanea y se marca como bueno o malo, y solo cuando todas las HU de la entrega han sido escaneadas el sistema crea un único documento de inspección que las cubre todas, con un ítem por handling unit que lleva su resultado escaneado. La recepción de mercancía se contabiliza entonces para cada handling unit según ese resultado — el contenido de cualquier HU marcada como mala acaba en blocked stock automáticamente, sin paso de decisión aparte.
RF — Preliminary HU Inspection
El paso de escaneo está implementado en el function module /SCWM/QHU_INSPECTION, que recibe dos listas de handling units — buenas y malas — y construye el documento de inspección directamente a partir de ellas. Es uno de los pocos puntos de toda la serie donde el «RF» no es un front end alternativo a un proceso de escritorio: es el único front end que existe. Si estás en embedded EWM, este mecanismo entero está estructuralmente ausente en tu sistema.
El Esquema de Numeración Que Dice de Dónde Vino Una Inspección
El quality management propio de S/4HANA usa sus propios inspection types — 01, 04, 08, 09 y otros — para las inspecciones que origina él mismo. EWM no reutiliza esos números directamente. En su lugar, para cada inspección que dispara EWM, el quality management de S/4HANA recibe un tipo reflejado con el mismo número base y el prefijo 17 añadido.
El prefijo 17 no es decoración — es la marca de que este lote de inspección no se originó dentro del quality management de S/4HANA. Vino de un sistema externo, y en este contexto «externo» significa EWM, cualquiera que sea la arquitectura que lo esté ejecutando. El mismo esquema de prefijo aplica tanto a embedded como a decentralized EWM, porque en los dos casos es EWM quien le pide a quality management que abra un lote de inspección, no al revés.
Un Hábito Arquitectónico Que Merece la Pena Aprender: El Sufijo S4
El código de inspección de calidad de EWM está construido sobre un service adapter framework: una superclase lleva el comportamiento compartido entre ambas arquitecturas, y una subclase por arquitectura — una «adapter class» — implementa las partes que difieren. La convención de nombres es lo bastante consistente como para ser genuinamente útil cuando estás mirando un stack trace y necesitas saber en qué mundo estás.
Las clases construidas para embedded EWM llevan el sufijo _S4 casi sin excepción. Es un detalle pequeño, pero significa que cuando estás depurando un problema de calidad y ves un nombre de clase terminado en _S4, ya sabes que estás mirando código que habla directamente con el quality management de S/4HANA — no con el Quality Inspection Engine — antes de haber leído una sola línea de su lógica.
Práctica: Montar un Inspection Object Type Desde Cero
Esta es la secuencia para decentralized EWM, porque es la arquitectura donde los inspection object types y las reglas son todo el juego. IOT4 (inspección de recepción de mercancía) es el que merece la pena practicar, porque cada post posterior de esta serie que toque Customizing asume que ya has hecho esto una vez.
1. Define y activa el IOT dependiente de almacén. SCM Extended Warehouse Management → Extended Warehouse Management → Cross-Process Settings → Quality Management → Basics and Integration → Define and Activate Warehouse-Dependent IOTs. Escribe 4 en el campo Insp. Obj. Type para tu número de almacén y activa los ajustes que necesite tu proceso.
2. Genera una versión. Mismo menú, → Generate Inspection Object Types Version. Selecciona la línea de IOT4 y genera una versión nueva — este es el paso que es destructivo con todo lo generado antes, así que hazlo cuando estés seguro de los ajustes dependientes de almacén.
3. Activa la versión. → Maintain Inspection Object Types Version. Selecciona la versión que acabas de generar y marca Activ. IOT. Nada se crea contra una versión inactiva.
4. Construye la inspection rule. SAP Easy Access → Logistics → SCM Extended Warehouse Management → Master Data → Quality Management → Maintain Inspection Rule — o directamente la transacción /SCWM/QRSETUP. Crea una regla para IOT4, en vista Form, y añade los atributos de determinación que necesite tu proceso (tipo de documento, producto, lo que exponga tu Customizing). Sin una regla, el object type está activo pero nada le hace match nunca, y nunca se crea ningún documento de inspección.
5. Confirma que dispara de verdad. La transacción /SCWM/QRSIM simula la determinación de inspection rules contra un conjunto de atributos antes de tocar una entrega real — úsala antes de confiar en la regla contra stock en vivo.
Antes de generar una versión en un sistema en producción
Generar una nueva versión de inspection object type no es reversible en la práctica — cada documento de inspección creado bajo la versión anterior pasa a ser de solo lectura para procesamiento en el momento en que la nueva versión entra en vigor. Los documentos existentes se pueden seguir mostrando, nunca procesar. Trata este paso como tratarías una migración de esquema, no como un ajuste de Customizing.
Lo Que Viene Después
El mapa nombró ocho mecanismos y dónde vive cada uno. Este post nombró el motor detrás de seis de ellos, el quality management de S/4HANA detrás de los otros dos, y el que — IOT6 — solo existe como escaneo RF. Los próximos cuatro posts van uno a uno: un conteo que se ve igual desde el suelo y no lo es, un muestreo que puede parar un camión junto a otro que no puede, un campo que dejó de ser tuyo para editar, y una fecha que nadie escribió a mano.
Parte de la serie de Quality Management
Anterior ←
Dos Etapas, No Tres (Hasta 2025 FPS1)
Siguiente →
Deja un comentario