No hubo error. No falló nada. Tu entrega simplemente nunca llegó.
Contabilizas la entrega de salida en S/4HANA. Éxito. Sin error, sin aviso, sin ningún mensaje en rojo.
El almacén la está esperando. No está. Abres /SCWM/PRDO y no hay nada que buscar — el documento no existe en EWM.
Y aquí está lo que hace este fallo distinto de todos los demás que vas a diagnosticar: no hay nada que investigar. No hay dump. No hay mensaje de error. No hay log fallido. Los dos sistemas se creen correctos, y los dos tienen razón: ERP hizo su trabajo, y EWM nunca recibió nada que hacer.
El documento está vivo, en tránsito, esperando en una cola que nadie mira. Hasta que alguien la mire, seguirá esperando — y el almacén seguirá parado sin saber por qué.
Este post recorre el camino completo: qué transacción abrir en cada salto, qué te dice la respuesta, y qué hacer con ella. El orden importa: cada paso descarta una capa, así no adivinas.
Paso 1 — Confirmar que la entrega salió de ERP
Abre la entrega en VL03N y mira el estado de distribución en la cabecera.
| Estado | Significado | Qué te dice |
|---|---|---|
| A | Relevante | La distribución es relevante pero aún no ha ocurrido. El problema está antes de la cola. |
| D | Planificada para distribución | En cola para distribuirse. Todavía del lado de ERP. |
| B | Distribuida | ERP da esto por terminado y no volverá a avisar. Si el documento no está en EWM, salió por la cola. |
Estado B sin documento en EWM es la firma de este problema. Y es también por lo que nadie lo detecta: desde ERP está todo completo. No existe una lista de trabajo de entregas distribuidas que nunca fueron confirmadas.
Paso 2 — Encontrar la cola
El transporte entre los dos sistemas es qRFC. SAP los usa precisamente porque son resistentes: conservan la secuencia y reintentan solos cuando otro proceso tiene bloqueado un objeto.
Esa resistencia es también lo que hace el fallo silencioso. Una cola que reintenta parece sana desde lejos.
SMQ2— colas entrantes. Es donde miras primero: SAP recomienda colas entrantes para EWM, y son el valor por defecto.SMQ1— colas salientes, si tu sistema se configuró para usarlas (Integration with Other SAP Components → Extended Warehouse Management → Basic Settings for EWM Linkage → Define Queue for Transfer to SAP EWM).
El nombre de la cola identifica el documento — algo como DLWSB7GCLNT5001000055701. Puedes cruzarlo con la entrega que estás persiguiendo.
Puede que no necesites acceso de Basis. La misma cola se ve desde el lado de EWM, en el nodo de colas del monitor de gestión de almacén (/SCWM/MON). Muchos consultores funcionales pasan años escalando a Basis sin saber que pueden verla ellos mismos.
Paso 3 — Leer lo que la cola te está diciendo de verdad
Una cola atascada aparece en uno de tres estados, y piden respuestas completamente distintas.
Un mensaje de error concreto
Haz doble clic. Si se abre una ventana, tienes el texto completo más la clase y el número de mensaje, que es lo que necesitas para buscar notas.
Si no se abre nada, busca el mensaje en la tabla T100: copia el texto, sustituye los números de documento por * y añade * al final. Eso te da el mensaje completo, su clase y su número.
«Error during follow-up action; See application log»
Ese texto genérico significa que el error real se escribió en otro sitio. Abre SLG1 y busca alrededor de la marca de tiempo de la cola, cruzando por número de documento, nombre de cola o userID.
Si SLG1 está vacío, eso es un hallazgo, no un callejón sin salida. Comprueba si el log está activado para ese almacén en /SCWM/ACTLOG. Un sistema que no registra seguirá ocultando la causa de todos los fallos futuros.
RETRY — el que engaña
El texto de estado dice «Command to tRFC/qRFC: Execute LUW again.» El sistema ha decidido que el problema podría ser temporal —normalmente un bloqueo— y que ejecutarlo más tarde lo resolverá.
A veces es cierto. Pero una cola también puede quedarse en RETRY por un error real que no se puede mostrar ni en SMQ2 ni en SLG1, y entonces hay que depurarla. RETRY no es un estado que puedas esperar indefinidamente: si lleva horas reintentando, trátala como atascada.
Paso 4 — El caso de autorizaciones que casi nadie revisa
Este merece sección propia, porque explica un síntoma que de otro modo no tiene sentido: la misma cola falla para un usuario y funciona para otro.
Las colas de SMQ2 se ejecutan con las autorizaciones del usuario que las contabilizó — no con las tuyas, ni con las de un usuario técnico de fondo.
Así que cuando hay muchas colas WMQF* atascadas para un userID concreto, la causa probable son las autorizaciones. La comprobación tiene un orden específico:
- En
SMQ2, localiza la cola atascada y anota el userID. - Ejecuta la cola con Execute LUW (F6). Se ejecuta bajo ese usuario, así que el sistema comprueba sus autorizaciones. Espera a que vuelva a fallar con el mismo error.
- Abre
SU53y cámbialo para mostrar la comprobación de autorización de ese userID, no del tuyo. - Lee la comprobación fallida y añade la autorización que falta al usuario que contabiliza las colas.
El paso 2 importa: SU53 muestra la comprobación fallida más reciente. Ejecutar antes el LUW es lo que hace que el fallo relevante sea el más reciente.
Paso 5 — Volver a poner el documento en marcha
Cuando ya sabes la causa, hay tres palancas, de menos a más fuerza. Usa la menos forzada que funcione.
Reejecutar la cola. Si has corregido la causa —customizing, datos maestros, una autorización— basta con volver a ejecutarla desde SMQ2.
Reiniciar el estado de distribución. Una entrega LE distribuida a EWM queda en estado B, y mientras esté en B no se le puede hacer ningún cambio. El módulo de funciones /SPE/DELV_RESET_DIST_STATUS (vía SE37) lo devuelve a A (Relevante) o D (Planificada para distribución) para poder redistribuirla. Se pasa la entrega en IT_DELIVERY_KEYS y el estado destino en IV_NEW_DISTSTAT.
Edición del contenido de la cola. SAP documenta una forma de editar la carga útil de las colas entrantes de ERP — y es inusualmente tajante sobre cuándo usarla:
«La edición de colas debe ser solo la última medida para resolver entradas de cola fallidas. Antes de plantearte editar una cola, comprueba si los fallos se pueden resolver por otros medios.» — SAP How-To Guide, Queue Content Editing
La misma guía enumera cuáles son normalmente esos otros medios, y sirve como lista de diagnóstico:
- Customizing ausente o incorrecto
- Autorizaciones que faltan
- Lógica de validación divergente entre ERP y EWM — comprobaciones de tolerancia, de caducidad o vida útil, validaciones de dirección
- Datos maestros que faltan
El tercero merece detenerse. Los dos sistemas pueden ser correctos por separado y aun así discrepar: ERP acepta una fecha que EWM rechaza, o una dirección que no pasa su validación. No hay nada roto en ninguno. La cola es simplemente el primer sitio donde la discrepancia se hace visible.
Fíjate también en el límite: la edición solo está disponible para colas entrantes de ERP, solo para funciones RFC entregadas por SAP, y no para funciones ampliadas con parámetros propios.
Paso 6 — Confirmar que el documento llegó de verdad
No cierres el ticket con una cola en verde. Ve a mirar:
/SCWM/PRDO— la outbound delivery order existe en EWM./SCWM/PRDI— el equivalente para entrada./SCWM/MON— el warehouse request es visible, y se han creado los documentos posteriores que esperabas.VL03N— el estado de distribución vuelve a B, esta vez con un documento al otro lado que le corresponda.
Una cola desatascada significa que el mensaje se entregó. No significa, por sí solo, que el documento se creara como querías.
La forma de este problema
La mayoría de los diagnósticos parten de un error. Este parte de una ausencia — y las ausencias son mucho más difíciles de notar, porque ningún monitor está diseñado para avisarte de un documento que nunca se creó.
Por eso importa más el hábito que el arreglo: cuando falte un documento en un lado, revisa la cola antes que ninguna otra cosa. Son dos clics, se ve desde cualquiera de los dos sistemas, y descarta una familia entera de causas en segundos.
En el próximo post de esta serie cogemos la otra mitad del problema: los fallos que sí se anuncian — dumps y mensajes de error — y cómo leer la línea de un short dump que te dice qué componente es el responsable, y por tanto si el problema es siquiera tuyo.
Lecturas relacionadas
- Tu stock cambió de estado y nadie contabilizó nada — el otro lado de la frontera ERP–EWM: qué le pasa al estado del stock una vez que el documento sí llega.
- Warehouse Process Type: el motor invisible — cuando la entrega ya está en EWM, esto es lo que decide cómo se comportan sus tareas.
Parte de la serie Troubleshooting
Primer post de la serie
Deja un comentario