Dibuja el almacén como una línea — entra mercancía, espera, sale — y la calidad debería aparecer tres veces sobre esa misma línea: comprobar en la entrada, comprobar mientras espera, comprobar en la salida.
Durante toda la vida de SAP EWM, no fue así.
Busca en el framework de inspección de calidad un mecanismo dedicado que se dispare en la salida — un inspection object type para salida, un chequeo ligado al picking o a una entrega a punto de salir — y en cualquier release anterior a S/4HANA 2025 FPS1 no vas a encontrar ninguno. No porque sea oscuro. Porque no estaba. Todos los inspection object types que EWM incluía se disparaban por algo que llegaba o por algo que ya estaba en un hueco. Nada se disparaba por algo que salía — hasta que SAP añadió un octavo, sin hacer ruido.
Cómo se comprobó esto
Dos preguntas distintas, comprobadas de forma distinta. Si la ausencia de calidad en salida es estructural por diseño se comprueba contra el material de curso, la referencia de arquitectura y la guía de integración que sostienen esta serie — nada de eso tiene versión, y todo coincide: ningún mecanismo dedicado de salida, nunca. Si eso sigue siendo cierto hoy es una pregunta de release, comprobada por separado contra la matriz de capacidades propia de SAP (Nota 3707210) y un deck de novedades de 2025 FPS1 con capturas reales de Customizing. Las dos respuestas ya no coinciden, y ese es exactamente el tema de este post.
Esa distancia entre «estructuralmente, por diseño» y «a día de esta release concreta» es el dato más útil de toda la serie, porque te dice exactamente qué comprobar antes de fiarte de ninguna de las dos respuestas. Este post es el mapa: dónde vive de verdad la calidad en el flujo, dónde estructuralmente nunca vivió, y dónde acaba de aterrizar un octavo mecanismo que la mayoría de sistemas en producción todavía no tiene.
Dos Etapas, No Tres — Hasta Hace Muy Poco
Todo lo que hacía el framework de calidad de EWM, en cualquier release anterior a S/4HANA 2025 FPS1, se agrupaba en dos momentos: algo nuevo que llega, o algo que ya está aquí y se vuelve a mirar. Nada se agrupaba en el punto de salida. Ese sigue siendo el mapa que importa para casi todos los sistemas en producción hoy.
Cada caja de ese diagrama es un Inspection Object Type (IOT) real — el objeto que define el componente de software, el proceso y el objeto para el que se crea un documento de inspección. Siete de ellos llevan años ahí, y esta serie dedicará un post a la mayoría. El octavo tiene solo unos meses a fecha de escribir esto, y casi nadie lo está usando todavía — por eso tiene su propio apartado más abajo en vez de colarse discretamente en el recuento.
Entrada — tres llegadas distintas, tres IOTs distintos
Una entrega de proveedor se comprueba con acceptance sampling (IOT4), que puede parar la recepción de mercancía directamente con un error si el resultado es malo — el tema del Post 3.
Tu propia producción llega por ese mismo IOT4, pero como su otro subtipo, pre-sampling — y no puede bloquear la recepción con un error, solo restringir dónde acaba el stock. Mismo inspection object type, dos subtipos con un poder realmente distinto, que es justo por lo que existe el Post 3.
Una devolución de cliente tiene su propio inspection object type entero, IOT3, casi siempre ejecutado a través de Advanced Returns Management — Post 6.
Debajo de las tres, el conteo (IOT2) es una actividad de entrada separada de la inspección de calidad propiamente dicha — comprueba cantidad, no condición, y se divide en dos mecanismos que desde el suelo se ven idénticos y no lo son, que es el Post 2.
Stock interno — no llega nada, y aun así se comprueba
El stock que ya está sentado en un hueco tiene dos formas de volver a entrar en una inspección. La inspección recurrente (IOT5) corre en un calendario que calcula el propio sistema, ligado a la próxima fecha de inspección de un lote — Post 5. Defect processing (IOT7) es la contraparte reactiva: alguien en planta encuentra algo mal en stock que nunca estuvo marcado para un chequeo programado, y lo registra directamente.
Salida — nada, y luego IOT8
En cualquier release anterior a S/4HANA 2025 FPS1, no hay IOT para esto. Ni uno más pequeño, ni uno simplificado — ninguno. Si un requisito de negocio necesitaba de verdad un chequeo antes de expedir, se construía reutilizando IOT5, programado para correr contra la zona de picking antes de que salga una ola. Eso es un workaround prestado del mecanismo de stock interno, no una capacidad nativa de salida, y en cualquier sistema anterior a 2025 FPS1 esa sigue siendo la respuesta honesta.
IOT8 — Q-Inspection Outbound cambia eso, pero no dándole a salida un mecanismo nativo propio como lo son IOT3 o IOT5. Se activa en la misma pantalla «Warehouse-Dependent IOT Settings» que cualquier otro IOT dependiente de almacén — pero lo que dispara es la inspección de expedición de SD-QM, que lleva décadas ahí (orígenes de lote de inspección 10, 11 y 12: entrega a cliente con pedido de ventas, sin él, y entrega general), configurada del lado ERP, no construida de cero en EWM. Lo genuinamente nuevo es el cableado: un indicador en el ítem del EWM Outbound Delivery Order — «Relevant for Q-Inspection in Outbound» — y un chequeo RFC síncrono en la contabilización de salida de mercancías que llama de vuelta a ERP QM y puede abortar la contabilización directamente si la inspección no está completa.
Antes de planificar sobre esto
IOT8 requiere S/4HANA 2025 FPS1 como release de backend tanto en EWM como en ERP — no es retrofiteable a sistemas más antiguos, y no es automático ni siquiera en FPS1: hay que activarlo como cualquier otro IOT dependiente de almacén, y el lado SD necesita su propio info-record configurado con uno de tres modos — bloquear la salida de mercancías hasta que termine la inspección, permitirla e inspeccionar después, o saltarse el lote de inspección por completo y confiar en el chequeo del propio cliente. En la mayoría de instalaciones en producción hoy, nada de esto existe todavía, y el mapa honesto sigue siendo el que tiene la caja de salida vacía.
La División Que Atraviesa Cada Post de Esta Serie
Hay que dejar clara una cosa más antes de que ninguno de los mecanismos individuales tenga sentido: embedded EWM no usa el Quality Inspection Engine en absoluto. Habla directamente con el quality management propio de S/4HANA. Decentralized EWM es el que corre a través del QIE.
Esto no es una nota a pie de página. Decide qué IOTs existen siquiera para ti:
Tres de los ocho simplemente no existen en embedded EWM. No están desactivados, no están escondidos detrás de un switch — están estructuralmente ausentes, porque se construyeron para el QIE y embedded EWM nunca habla con él. IOT8 es la excepción que merece nota aparte: a diferencia de los otros siete, corre idéntico en ambas arquitecturas, porque lo que dispara de verdad vive del lado ERP, no dentro del QIE. Cada post de esta serie que toque Customizing dirá a qué arquitectura aplica, porque «quality management en EWM» significa, sin avisar, dos sistemas distintos según cuál estés corriendo.
Dónde Encajan de Verdad «Materia Prima» y «Producto Terminado»
Ninguna de las cajas de arriba está etiquetada por tipo de material, y eso no es un olvido — EWM no modela materia prima frente a producto terminado como una categoría propia. Lo que modela es el documento que disparó la inspección. Todo lo demás es una lectura que tú aplicas encima.
En la práctica las dos cosas coinciden lo bastante a menudo como para sentirse estructurales: la materia prima suele aparecer por el lado de acceptance sampling de IOT4, porque suele llegar de un proveedor externo. El producto terminado suele aparecer por el lado de pre-sampling de IOT4, porque suele llegar de tu propia producción — o por IOT5 si lo que importa de verdad es un reloj de caducidad y no de dónde vino el stock.
La distinción que importa más que el tipo de material
Dos productos pueden ser ambos «producto terminado» y aun así seguir caminos completamente distintos por este framework — uno porque vino de tu propia línea (pre-sampling), otro porque vino de un subcontratista (acceptance sampling), cada uno con un comportamiento de bloqueo distinto. El tipo de material no te dice nada sobre qué reglas aplican. El documento que creó el movimiento sí.
El Reto Práctico de Esta Semana
Antes de que el próximo post se acerque a Customizing, averigua qué está haciendo de verdad tu propio sistema — la mayor parte de esto lleva menos de diez minutos y no necesita acceso de configuración.
1. Comprueba si estás en embedded o decentralized EWM. Si no lo sabes ya, la señal más rápida es si IOT2 (Counting Inbound Delivery) muestra algo de actividad — estructuralmente no puede existir en embedded.
2. Enumera cuáles de los siete IOTs están generando de verdad documentos de inspección en tu almacén hoy. La mayoría de sistemas usa dos o tres, no los siete.
3. Para el uso que tengas de IOT4, averigua qué subtipo es — acceptance sampling o pre-sampling. Si nadie en la sala puede responder al instante, vale la pena señalarlo ya: es exactamente la distinción sobre la que se construye el Post 3, y decide si un mal resultado puede de verdad parar un camión.
4. Comprueba tu release de backend. Si estás por debajo de S/4HANA 2025 FPS1, IOT8 no existe todavía en tu sistema y la caja de salida del mapa de arriba está genuinamente vacía para ti — eso no es un hueco de esta serie, es el estado actual de tu landscape.
Lo Que Cubre Esta Serie
Seis posts, cada uno un mecanismo del mapa de arriba, cada uno terminando en algo que configurar o ejecutar de verdad:
Post 1 — el Quality Inspection Engine, los siete IOTs completos, y por qué embedded EWM se construyó para no necesitarlo.
Post 2 — conteo implícito frente a explícito, dos mecanismos que desde el suelo se ven iguales.
Post 3 — acceptance sampling frente a pre-sampling, y cuál de los dos puede parar de verdad una entrega.
Post 4 — goods receipt control, y un campo que antes era tuyo para editar directamente y ya no lo es.
Post 5 — inspecciones recurrentes, y la fecha que nadie escribió a mano.
Post 6 — devoluciones de cliente a través de Advanced Returns Management, construido de principio a fin.
Empieza por el mapa, no por un mecanismo aislado. Cada uno de los próximos seis posts tiene más sentido en cuanto sabes a cuál de las dos etapas reales pertenece — y, igual de útil, a cuál no.
Parte de la serie de Quality Management
Primer post de la serie
Siguiente →
El Motor Que Embedded EWM No Usa (próximamente)
Deja un comentario