El post anterior te dejó con un wave template que funciona. Las condiciones están mantenidas, el Warehouse Process Type tiene activado el indicador de Automatic Wave Creation, y el método de liberación está elegido.
Nada de eso mueve un solo palé.
Entre “la plantilla existe” y “hay un operario con una pistola RF en la mano” hay una cadena de decisiones que casi nadie mira — y cuando una wave libera tres horas tarde, o se niega a aceptar un ítem que obviamente le corresponde, la respuesta casi siempre está en algún punto de esa cadena.
Este post sigue una entrega de salida desde que se vuelve elegible hasta que existe una warehouse order.
No pasa nada hasta que se dispara una acción PPF
Lo primero que conviene corregir: la determinación de wave no es un job en segundo plano que barre el almacén buscando trabajo.
Después de que tú o EWM creéis o modifiquéis un warehouse request, EWM crea una acción del Post Processing Framework — y esa acción PPF es la que arranca la determinación de wave.
Esto importa por un motivo práctico. Si las waves no se están asignando en absoluto, antes de tocar los registros de condición comprueba si la acción PPF se está disparando. Una tabla de condiciones perfectamente configurada no sirve de nada si nadie la llama.
Y fíjate en la redacción: creado o modificado. Un cambio en un warehouse request existente vuelve a disparar la determinación. Por eso un ítem puede acabar discretamente en una wave distinta de la que viste ayer.
Tres tiempos lo deciden todo
Una vez arranca la determinación, EWM intenta encontrar un wave template válido para cada ítem o split item. Después calcula tres tiempos — y de esos tres tiempos sale la mayor parte del comportamiento real de las waves.
1. Planned completion time (del ítem del warehouse request). Para salidas de stock, EWM usa la fecha y hora planificadas de salida del yard. Si no están disponibles, recurre a las fechas de inicio de la salida de mercancías de las entregas de salida. Para transferencias internas o entregas de cambio de stock, usa la categoría de fecha/hora Warehouse Activities End.
Lee otra vez esa primera frase, porque es la respuesta honesta a “cómo sabe el sistema que este pedido va en el camión de las seis”: no agrupa por camión. Deriva la fecha límite del ítem de cuándo está planificado que el vehículo salga del yard.
2. Wave completion. La regla es una restricción, no un cálculo: el wave completion time de la opción utilizada no puede ser posterior al planned completion time del ítem. Una wave que termina después de que la mercancía tenga que salir no es una wave, es un camión perdido.
3. Lock time. El lock time es el momento hasta el que todavía puedes añadir ítems a la wave. EWM calcula fecha y hora de bloqueo, y fecha y hora de liberación, hacia atrás desde el wave completion.
Y entonces llega el detalle que explica muchísimas incidencias confusas:
Si cualquiera de esos tiempos calculados ya está en el pasado, la opción del wave template es inválida.
No “la wave libera inmediatamente”. No “la wave libera tarde”. La opción simplemente no se puede usar, y EWM sigue adelante.
El problema del día anterior
Este es el comportamiento que sorprende a la gente la primera vez que se lo encuentra.
Un ítem tiene un planned completion time de las 13:00 del día 2. La opción del wave template especifica un wave completion de las 15:00 del día 2.
Las 15:00 son posteriores a las 13:00, así que la restricción anterior se incumple. EWM no se rinde y tampoco desplaza el ítem. Programa la wave con una fecha de wave completion del día anterior a la fecha de planned completion del ítem — es decir, las 15:00 del día 1.
El ítem que tenía que salir el día 2 a las 13:00 se prepara en una wave que termina la tarde anterior.
No es un fallo. Es el principio as early as necessary, as late as possible del Post 1 haciendo exactamente lo que prometía — solo que no lo parece cuando estás mirando una wave que aparentemente se ha adelantado un día.
Cuando la opción no encaja, EWM prueba la siguiente
Un wave template puede llevar más de una opción, y las opciones son atributos dependientes del tiempo: cutoff time, release time, hora de inicio y fin de picking, y hora de finalización del empaquetado. El sistema compara los requisitos del warehouse request con los atributos temporales de cada opción y elige una.
Lo que pasa cuando la opción elegida no se puede usar es una pequeña cascada que conviene saberse de memoria:
- La wave ya existe → EWM asigna el ítem a esa wave.
- Ocurre una excepción — por ejemplo, la wave excede su capacidad → esa opción es inválida, y EWM intenta crear una wave con la siguiente opción de la plantilla.
- La wave correspondiente existe pero ya ha sido liberada → EWM intenta la siguiente opción y asigna el ítem a una wave creada a partir de ella.
Este último caso tiene una excepción configurable, y es uno de los indicadores más útiles de wave management: Wave Assignment Also Possible After Wave Release. Actívalo y podrás añadir un ítem a una wave que ya ha salido.
Úsalo a conciencia. Resuelve el problema de “acaba de entrar un pedido más”, y también rompe silenciosamente la suposición de que una wave liberada es un conjunto de trabajo cerrado.
La capacidad son cinco límites, no uno
El wave capacity profile limita cuánto se puede asignar a una opción de wave template, y lo hace sobre cinco dimensiones distintas:
- Número máximo de ítems
- Peso máximo
- Volumen máximo
- Capacidad máxima
- Número de waves
SPRO → Extended Warehouse Management → Goods Issue Process → Wave Management → General Settings → Maintain Wave Capacity Profiles
Cualquiera de ellos puede invalidar una opción y empujar la determinación a la siguiente. Cuando una wave “no acepta” un ítem que evidentemente le corresponde, el perfil es el primer sitio donde mirar — y en concreto, merece la pena comprobar cuál de los cinco límites ha saltado, no solo si hay un perfil asignado.
Dónde vive realmente la agrupación por ruta
Las waves no tienen una casilla de “agrupar por ruta”. Lo que existe es más flexible y menos evidente: la técnica de condiciones determina qué plantilla aplica, y las plantillas se modelan por situación de negocio.
Una plantilla real de una configuración en producción se llama “Domestic Route 01” — plantilla 104, wave type Y214, categoría Y1, liberación manual, con gestión de excepciones configurada para dejar el ítem en la wave en caso de rechazo de ubicación.
Así se construyen en la práctica las waves por ruta. No con una función dedicada, sino con disciplina de nomenclatura y de registros de condición sobre el mecanismo del Post 2.
El ensayo: simular una liberación
Antes de que la liberación sea definitiva, puedes simularla.
La simulación de wave ejecuta el proceso de liberación sin confirmarlo. Dos situaciones justifican el paso extra: cuando la liberación va a crear y asignar un número importante de warehouse orders a los operarios, y cuando estás diagnosticando problemas de creación de warehouse orders que solo aparecen en el momento de liberar.
Se lanza manualmente desde el warehouse management monitor. También tiene su actividad de Customizing — Define Wave Simulation Settings, bajo el mismo nodo de General Settings que los perfiles de capacidad.
Es el paso que más equipos se saltan y que después lamentan haberse saltado. Una liberación de wave no se deshace con facilidad; una simulación te cuesta un minuto.
Liberación: donde nacen realmente las tareas
La liberación es el momento en que la wave deja de ser un plan. Las waves se usan para crear warehouse tasks y warehouse orders.
Tres métodos, cubiertos en el Post 2 y que merece la pena replantear en términos de ejecución:
- Automático — EWM crea un job que libera las waves el día y a la hora de liberación, ambos calculados hacia atrás desde el wave completion.
- Inmediato — se libera en cuanto se crea.
- Manual — alguien la libera, normalmente desde el monitor.
Los tiempos que gobiernan el caso automático no se introducen directamente. Se derivan, y por eso cambiar el completion time de una opción de plantilla puede mover una liberación que dabas por fija.
La warehouse order no es lo mismo que la tarea
La liberación crea warehouse tasks. Pero no se queda ahí: esas tareas se agrupan después en warehouse orders, y en esa agrupación toman el mando las Warehouse Order Creation Rules.
Dos categorías de creación muestran qué optimiza realmente esa agrupación:
- Consolidation group — todas las warehouse tasks de un mismo grupo de consolidación se preparan juntas, de modo que todo lo que va al mismo cliente se mantiene y empaqueta junto desde el principio. El recorrido de picking se alarga un poco; a cambio puedes ahorrarte un reempaquetado.
- Pick path — las tareas se ordenan por recorrido de picking y se agrupan para cubrir los caminos más cortos.
Y aquí es donde la wave category del Post 2 vuelve como filtro de qué WOCRs se evalúan. El círculo se cierra: la categoría que elegiste al construir la plantilla decide qué reglas de agrupación se consideran siquiera en la liberación.
Fusionar waves, y el detalle que tienes que verificar tú mismo
Los planes cambian. Dos waves que deberían haber sido una se pueden fusionar — con condiciones:
- Las waves no deben haber sido liberadas — estado I (initial, wave creada) o H (hold, wave bloqueada).
- Todas las waves seleccionadas deben compartir el mismo estado: o todas I, o todas H.
Y ahora la parte interesante. ¿Qué wave sobrevive? Circulan dos reglas distintas, y no son equivalentes:
| Regla | En qué wave acaban los ítems |
|---|---|
| La primera seleccionada | La primera wave seleccionada — EWM siempre usa el nombre de la fila superior. Las waves 123, 456 y 789 se fusionan en la 123. |
| La de número más bajo | La wave con el número de documento más bajo. |
En el ejemplo al que todo el mundo recurre, ambas reglas dan el mismo resultado — que es probablemente por lo que la contradicción pasa desapercibida. Pero no son la misma regla. Si ordenas la selección de otra forma, o si la wave que has pulsado primero no es la de número más bajo, las dos descripciones divergen.
La conclusión práctica no es “fíate de esta”. Es: verifica en tu propio sistema qué número de wave sobrevive antes de apoyarte en ello en una instrucción de trabajo, porque tus operarios apuntarán el número que vean, y un número de documento que desaparece a media jornada es un tipo de confusión caro.
Si necesitas ir más allá del Customizing
Para quien construya alrededor de las waves y no solo las configure, EWM expone el ciclo de vida a través de módulos de función del grupo /SCWM/WAVE_MGMT_EXT:
/SCWM/WAVE_SELECT_EXT— más de 30 criterios de selección de waves e ítems/SCWM/WAVE_RELEASE_EXT— dispara una liberación/SCWM/WAVE_MERGE_EXTy/SCWM/WAVE_SPLIT_EXT— fusionar y dividir
Son los módulos que hay detrás de los métodos que ves en el nodo Wave del warehouse management monitor. La guía de arquitectura es explícita en que encajan bien en desarrollos independientes —informes propios, por ejemplo— más que llamados desde modificaciones del flujo estándar.
Qué demuestra realmente este recorrido
Sigue una entrega de principio a fin y aparece el mismo patrón en cada paso: la wave no decide nada por sí sola. Una acción PPF la arranca, tres tiempos calculados la restringen, los límites de capacidad pueden invalidarla, la técnica de condiciones eligió su plantilla, y la WOCR decide en qué se convierten las tareas liberadas.
La wave es el contenedor. Todo lo interesante ocurre en lo que la llena y en lo que la vacía.
Siguiente en esta serie: el caso que casi nadie documenta — waves para suministro a producción, donde el método de staging decide si una wave es siquiera posible.
Lecturas relacionadas
- Qué Alimenta Realmente una Wave — los tres tipos de documento que puede agrupar una wave, y la anatomía de la plantilla
- Construir un Wave Template, Paso a Paso — el Customizing detrás de todo lo que este post ejecuta
- Anatomía de una Warehouse Order Creation Rule — qué les pasa a las tareas que crea la liberación de una wave
- Warehouse Process Type: el motor invisible — el interruptor que inicia la asignación automática
Deja un comentario