Los seis atributos del wave template del Post 1 no se configuran solos sobre una posición de warehouse request. Algo tiene que decidir, para cada posición, qué template aplica — y esa decisión pasa por una cadena real de Customizing, no por una sola casilla. Aquí está la cadena completa, con los nombres de campo exactos y los paths de IMG, no la versión simplificada.
El Interruptor que Activa Esto
La asignación automática de waves no es un ajuste global. Es una casilla que vive dentro de la propia configuración del Warehouse Process Type, en el mismo bloque de ajustes que controla el mapeo de tipo de documento, los availability groups, y el comportamiento de RF putaway para ese process type. El campo se llama literalmente Automatic Wave Creation: si está marcado, el sistema crea waves automáticamente para toda posición de warehouse request que lleve ese process type. Si no está marcado, nada de lo que sigue en este post pasa automáticamente — las posiciones se quedan ahí hasta que alguien crea una wave manualmente.
Por eso dos warehouse process types pueden comportarse de forma completamente distinta en el momento de la wave aunque todo lo demás se vea parecido — uno tiene la casilla marcada, el otro no. Si has leído nuestra serie de WPT, esto te sonará familiar: es el mismo patrón que en el resto de EWM. El process type no es solo «qué tipo de movimiento es esto» — es el interruptor maestro de una docena de comportamientos, y la asignación de waves es uno más.
Dos Cosas que Necesitas, No Una
Marcar esa casilla es necesario pero no suficiente. Para que la asignación automática realmente elija un wave template, el sistema necesita que existan dos cosas: wave templates (los datos maestros del Post 1) y condition records — los datos que le dicen al sistema qué template aplica en qué situación. Si faltan los condition records, la casilla no hace nada. La única excepción documentada es programar el report en background, que cubrimos más abajo — ese camino se salta los condition records por completo.
Configurar la Condition Technique, Paso a Paso
La determinación del wave template usa la misma condition technique que corre las packaging specifications y el Post Processing Framework (PPF) en el resto de EWM. La mecánica es idéntica en todas partes donde se usa — lo único que cambia entre aplicaciones es cómo se asigna la determination procedure al final. Aquí está la secuencia completa:
| Paso | Qué Configuras | Qué Hace Realmente |
|---|---|---|
| 1 | Condition Table | Define qué campos usa el sistema para decidir si aplica un wave template — por ejemplo número de almacén y process type. Qué campos están disponibles lo controla el Field Catalog de wave management. |
| 2 | Access Sequence | Asigna la condition table a una secuencia de búsqueda. Puedes marcar campos individuales como «field in free key part», lo cual importa cuando necesitas varios campos de condición usables en distintas combinaciones en vez de una tabla rígida. |
| 3 | Condition Type | El access sequence se asigna a un condition type, ligado a una Application y un Usage específicos — valores predefinidos por SAP que le indican a EWM en qué contexto se usa esta instancia de condition technique. |
| 4 | Condition Determination Procedure | El condition type se asigna a una determination procedure, ligada a la misma application y usage. Este es el paso que realmente difiere entre wave management y otras aplicaciones de condition technique en EWM. |
| 5 | Condition Maintenance Group | Crea uno nuevo o reutiliza uno existente, y asígnale la application, usage, condition table y condition type. Esto es lo que genera las pantallas de mantenimiento reales para introducir condition records después. |
| 6 | Maintenance Context | El maintenance group se asigna a un maintenance context. EWM trae uno predefinido que cubre todas las aplicaciones de condition technique del sistema — incluida wave management. |
| 7 | Asignar la Determination Procedure | Para wave management específicamente, esto combina el resultado deseado con número de almacén, categoría de documento y tipo de documento. |
Una vez que existe la configuración, el último paso es introducir los condition records reales — los valores de datos reales (qué almacén, qué process type, qué combinación) contra los que el sistema compara en tiempo real. Ese mantenimiento se hace en transacciones específicas de cada aplicación, aunque el mecanismo subyacente te deja cambiar de aplicación dentro de la mayoría de ellas si necesitas revisar cómo está configurada otra área.
El path genérico de IMG para todo esto es:
SPRO → SCM Extended Warehouse Management → Extended Warehouse Management → Cross-Process Settings → Condition Technique
El Atajo que se Salta Todo Esto
Si la configuración de la condition technique parece más maquinaria de la que tu proceso necesita, hay un camino genuinamente más simple: programar el report /SCWM/R_WAVE_PLAN_BACKGROUND con variantes predefinidas. Este es el único caso documentado donde la creación automática de waves funciona sin ningún condition record — el report gestiona la lógica de selección directamente a través de su propia configuración de variantes.
Hay una segunda alternativa que merece la pena conocer: puedes crear waves manual o automáticamente con referencia a una transportation unit específica, lo que agrupa en una misma wave los elementos que salen en el mismo camión, sin importar con qué los hubiera emparejado la condition technique. Útil cuando la restricción real del negocio es «esto tiene que salir en ese vehículo», no «esto encaja en una regla abstracta».
Release Method: Elegir Automatic, Immediate o Manual
Este es uno de los seis atributos del wave template del Post 1, y merece más que una definición de una línea, porque elegir el equivocado es un error común y evitable:
- Manual — una persona decide cuándo se libera la wave. Correcto para procesos donde un supervisor realmente necesita revisar la carga de trabajo o el timing antes de comprometerse — envíos de alto valor, periodos con capacidad limitada, cualquier cosa donde «lo más tarde posible» necesite un criterio humano.
- Immediate — la wave se libera en el momento en que se crea, sin esperar. Correcto para procesos donde el sentido de agrupar era organizativo, no de timing — sigues queriendo la estructura de la wave (capacity profile, wave type para monitorización) pero no el retraso.
- Automatic — el sistema libera la wave por sí solo cuando la lógica de tiempo de finalización del template dice que es el momento, usando los campos de fecha/hora del template. Esto es lo que implementa de verdad «tan pronto como sea necesario, tan tarde como sea posible» sin que nadie esté mirando un reloj.
Equivocarse en cualquiera de las dos direcciones tiene un coste real: Manual cuando necesitabas Automatic significa que alguien tiene que acordarse de liberar waves todo el día. Automatic cuando necesitabas Manual significa que un supervisor pierde la oportunidad de detectar un problema antes de que se creen cientos de tareas de almacén a partir de él.
El Segundo Trabajo de Wave Category
El Post 1 mencionó que wave category puede filtrar Warehouse Order Creation Rules. Aquí está el mecanismo exacto: cuando EWM evalúa si una tarea de almacén puede ser procesada por una WOCR determinada, comprueba un item filter — y ese filtro se puede acotar por warehouse process type, ruta, motivo de movimiento, y wave category, junto con límites mínimos/máximos de volumen, peso y procesamiento. Si una tarea de almacén no pasa el filtro, EWM pasa a la siguiente regla de la secuencia en vez de forzar una coincidencia.
Estos filtros se configuran en:
SPRO → SCM Extended Warehouse Management → Extended Warehouse Management → Cross-Process Settings → Warehouse Order → Define Filters for Warehouse Order Creation Rules
En la práctica, esto significa que la wave category que elijas no es solo una etiqueta para el Monitor — es una palanca que puedes usar para asegurarte de que ciertas waves alimenten WOCRs específicas y no otras, algo que importa si has construido warehouse order creation rules que deben comportarse distinto para distintos tipos de trabajo.
Lo siguiente en esta serie: el caso clásico, de principio a fin — construir una wave de entregas salientes desde el momento en que las posiciones se vuelven elegibles hasta que existe el warehouse order.
Related Reading
- Warehouse Process Type: El Motor Invisible — por qué el process type es el interruptor maestro también detrás de la asignación de waves
- Anatomía de una Warehouse Order Creation Rule — dónde reaparece wave category, como filtro
Deja un comentario