Un pallet vuelve de un cliente. Antes de que pueda acercarse otra vez al stock de reserva, alguien tiene que moverlo de stock de libre utilización a inspección de calidad. Todavía no se mueve nada físicamente — la ubicación sigue siendo la misma. Solo cambia el estado del stock.
¿Dónde ocurre ese clic? ¿En SAP S/4HANA, o en EWM? La respuesta honesta es: depende de cómo esté desplegado EWM — y la diferencia no es cuestión de gustos, es un hecho arquitectónico real que se puede verificar en una tabla.
Qué es realmente un Posting Change
Un posting change es cómo cambias las características de un producto — su tipo de stock, su propietario, a veces su lote — sin necesariamente moverlo a otra ubicación. El stock de libre utilización pasa a ser stock en inspección de calidad. El stock propio pasa a ser stock en consignación de proveedor. El producto no sale del almacén; solo cambia lo que el sistema sabe sobre él.
Puede ser planeado — una recalificación programada, el fin de un acuerdo de subcontratación — o no planeado, disparado por un resultado de inspección de calidad que rechaza un lote sobre la marcha.
La tabla que responde de verdad a la pregunta
SAP EWM formaliza cada interacción de delivery processing como una categoría de documento con su propia transacción y — esta es la parte que importa aquí — su propia disponibilidad según el despliegue. Dos de esas categorías son en lo que se resume toda esta pregunta:
Léelo literalmente y la respuesta sale sola. En EWM embebido, la Posting Change Request (POR) simplemente no existe como categoría de documento — porque ERP y EWM son el mismo sistema compartiendo la misma base de datos. No hay nada que pedirse a uno mismo. Todo posting change pasa por SPC, y pasa de forma síncrona.
En EWM descentralizado, ambos existen. ERP puede mandar una solicitud formal (POR) pidiéndole a EWM que ejecute el cambio — es el caso clásico de un traspaso de stock en dos pasos iniciado en ERP con MIGO o MB1B usando el tipo de movimiento 313 o 315. O EWM puede ejecutar el cambio localmente, en la planta del almacén, y avisar a ERP vía SPC. Ambos caminos son igual de válidos — por eso mismo alguien tiene que decidir cuál es el que manda por defecto en un almacén, en vez de dejarlo a quien llegue primero.
La frase que vale la pena recordar
Si estás en EWM embebido, deja de debatir quién es dueño del posting change — no hay una solicitud aparte que poseer. Si estás en EWM descentralizado, el debate es real, y debería resolverse en Customizing, no por costumbre.
Por qué el EWM embebido se siente instantáneo
El EWM embebido no solo se salta el documento de solicitud — contabiliza de forma síncrona. En cuanto se confirma un posting change en EWM, la actualización de Inventory Management (IM) en S/4HANA ocurre en la misma transacción, no en una cola que se procesa después.
Esto importa más de lo que parece. Si IM rechaza la contabilización — por ejemplo, el tipo de stock destino no existe para esa ubicación de almacén — el error salta al instante en la pantalla de EWM, antes de que se confirme nada. Compáralo con una cola fallida que descubres horas después, cuando un informe ya ha asumido que el stock se movió.
Dos ajustes que deciden los detalles
Dos campos, ambos a nivel de warehouse process type, deciden la mecánica una vez que sabes quién dispara el cambio:
En EWM, todo esto corre a través de /SCWM/POST, la pantalla de posting change — puedes buscar por producto, HU, ubicación de almacén, recurso o unidad de transporte, y luego introducir directamente el nuevo tipo de stock, propietario, lote o uso.
Configurarlo: la ruta real de Customizing
Nada de lo anterior es automático. Son cinco nodos IMG, y uno de ellos solo importa si estás en EWM embebido.
El warehouse process type estándar para posting change es 4010, y el tipo de documento/posición estándar es TWPR — ambos usables tal cual o copiados a tu propia variante.
Entonces, ¿dónde deberías dispararlo tú?
Sáltate el debate filosófico. Recorre esto en su lugar:
1. ¿Estás en EWM embebido o descentralizado? Esto solo ya responde el 80% de la pregunta — en embebido, deja de buscar un POR que no existe.
2. ¿El cambio es planeado o reactivo? Una recalificación programada encaja con una solicitud disparada desde ERP; una inspección de calidad fallida en planta encaja con un cambio disparado desde EWM sobre la marcha.
3. ¿El Repl. Level del tipo de almacén o su ajuste de stock mixto ya dictan el comportamiento del bin? Revisa Post. Change in Bin antes de asumir que se creará o no una tarea de almacén.
4. En EWM embebido, ¿está realmente activo el goods movement síncrono? Si los errores no saltan al instante, esa activación IMG es lo primero que hay que revisar.
Lecturas relacionadas
- Warehouse Process Type: El Motor Invisible — el WPT 4010, el process type detrás de cada posting change
- Dentro de un Almacén SAP EWM — dónde encaja el posting change en el flujo end-to-end
Part of the serie EWM Common Topics
Deja un comentario