El operario camina hasta el fondo del pasillo, coge una línea, vuelve pasando por delante de seis ubicaciones a las que tendrá que regresar en veinte minutos, y sigue.
Revisas la configuración. La ordenación de ubicaciones está bien. La regla de ordenación está bien. El activity area está bien. Todo lo que preguntaría una checklist está bien — y el recorrido sigue siendo malo.
Es malo porque el orden en que salen esas tareas se decidió cuatro veces, en cuatro objetos distintos, y solo dos de ellos viven dentro de la creation rule. Configuras uno y los otros tres te sobrescriben en silencio.
Este post desmonta los cuatro, en el orden en que se ejecutan de verdad.
El que pilla a todo el mundo
Una warehouse order creation rule no lleva un ajuste de ordenación. Lleva dos — y hacen trabajos completamente distintos. Uno decide qué tareas acaban viajando juntas. El otro decide en qué orden se visitan una vez que ya viajan juntas. Casi todos los equipos configuran el segundo y dan por hecho que hizo el trabajo del primero.
Cuatro decisiones, un recorrido
Antes de ninguna pantalla, la secuencia. Cada una se ejecuta antes que la siguiente, y cada una condiciona lo que la siguiente puede hacer.
Léelo como un embudo. Para cuando se ejecuta cualquier cosa llamada regla de ordenación, las ubicaciones ya están elegidas — y para cuando el operario ve una lista, la decisión de quién viaja con quién ya está tomada.
Decisión 1 — La regla de extracción ya eligió las ubicaciones
Esta no es un ajuste de ordenación en absoluto, y justo por eso se queda fuera de las conversaciones sobre recorrido. Pero va primera, y es decisiva.
La regla de extracción ordena el stock disponible y coge lo primero de esa lista. Dispone de todos los atributos que describen el quant, se puede ordenar por más de un campo, y las reglas se aplican por storage type o grupo de storage types. Fecha de entrada ascendente y luego cantidad descendente es de las más comunes, y es una política FIFO — no una política de recorrido.
Goods Issue Process → Strategies → Specify Stock Removal Rule
Por qué esto entra en un post sobre caminar
Una regla de extracción optimizada solo para rotación mandará encantada al operario al palet más viejo del edificio para una línea, y al otro extremo para la siguiente. Nada aguas abajo puede reparar eso: ordenar solo puede recolocar las ubicaciones que te dieron, nunca elegir otras. Si el recorrido es malo y la ordenación parece correcta, aquí es donde hay que ir — y es en parte una conversación de política, porque el intercambio es rotación contra desplazamiento. Solo en parte, eso sí: la regla también puede enterarse de lo que ya está pasando en el almacén. Incluye PICK_ITM o PICK_QT entre los campos de ordenación y, cuando varias ubicaciones fijas tienen el mismo producto, el sistema dirige la siguiente tarea hacia una que no tenga ya una tarea abierta — para no mandar a dos personas a la misma estantería.
Decisión 2 — La secuencia almacenada en la que se ordenó el almacén
Las ubicaciones no tienen un orden intrínseco. El orden en que se acceden se crea ordenándolas dentro de un activity area, por actividad, y el resultado se almacena.
La ordenación la controla la sort sequence asignada al activity area y a la actividad — ojo con el nombre, porque la documentación también la llama perfil y el perfil de la creation rule es otra cosa. Las ubicaciones se describen por sus atributos estructurales — pasillo, pila, nivel, subdivisión, profundidad. Una secuencia puede ser pila, luego nivel, luego subdivisión.
Master Data → Activity Areas → Define Sort Sequence for Activity Areas/SCWM/SBST — Sort Storage Bins
La caducidad de una ordenación de ubicaciones
Esta es la que se pudre. Hay que volver a ejecutarla cada vez que se añaden, cambian o borran datos maestros de ubicación o los activity areas relacionados. No se recalcula según se mueve el stock — esa creencia es habitual y falsa. Un almacén que ha añadido ubicaciones desde el arranque y nunca la ha relanzado tiene una secuencia de recorrido correcta para un almacén que ya no existe.
Antes de generar nada, ejecuta la simulación y mira la secuencia resultante por actividad. Leerla una vez te dice más de tu propio almacén que cualquier cantidad de teoría sobre recorridos de picking.
Decisión 3 — Inbound Sorting: quién viaja junto
Aquí está el ajuste del que casi nadie habla, y el motivo de que una regla técnicamente correcta produzca paquetes de trabajo sin sentido.
Una creation rule lleva una entrada de Inbound Sorting, elegida entre las reglas de ordenación que hayas definido. EWM la aplica al principio de la creación de la warehouse order — antes de que las tareas se hayan empaquetado en órdenes, aunque para entonces ya estén repartidas por área de actividad, que es lo que decide qué regla hará el empaquetado.
Ese momento es todo el asunto. La creación de warehouse orders recorre la lista ordenada de tareas y va llenando una orden hasta alcanzar un límite, y entonces empieza la siguiente. Así que la ordenación aplicada antes de agrupar decide qué tareas caen en la misma orden. Cámbiala y no has reordenado el trabajo: has redibujado las fronteras entre paquetes de trabajo.
Cross-Process Settings → Warehouse Order → Define Creation Rule for Warehouse Orders
Ordenación y límite son una sola decisión, no dos
El inbound sorting solo importa porque existe un límite. Ordena por ubicación y limita a diez tareas, y cada orden son diez ubicaciones vecinas — un recorrido apretado. Ordena por producto y limita a diez, y cada orden son diez líneas del mismo producto repartidas por todo el almacén — un recorrido pésimo que, según la lógica de la propia configuración, es del todo correcto. El límite traza la raya; el inbound sorting decide por dónde corta esa raya.
Decisión 4 — WO Sorting: el orden dentro de la orden
La segunda entrada de ordenación de la misma regla es WO Sorting, y se aplica a ordenar dentro de una warehouse order — la secuencia en que se presentan las tareas una vez formado el paquete.
Esta es la que la gente tiene en mente cuando dice «el ajuste del pick path». Es real, va la última, y solo puede recolocar lo que le entregaron las tres decisiones anteriores.
Las dos entradas beben del mismo depósito:
Cross-Process Settings → Warehouse Order → Define Sort Rules for Warehouse Tasks
Qué contiene realmente un perfil de ordenación
Un perfil puede especificar hasta quince campos. Para cada uno:
La casilla que recorre el pasillo al revés
Sort Des. es un clic y es invisible desde cualquier pantalla que no sea el propio perfil. Una ordenación de ubicaciones perfectamente generada, leída en descendente por un campo, produce un recorrido que empieza por el fondo. La ordenación de ubicaciones no está mal. La regla de ordenación no está mal. La combinación sí. Es la causa más habitual de «la secuencia sale justo al revés», y comprobarlo lleva diez segundos.
Y el ajuste que declara la intención
Un campo de la creation rule declara qué clase de paquete estás intentando construir: la categoría de creación. Entre las opciones están grupo de consolidación, pick path, pick-pack-pass y carga y descarga.
Merece la pena leer tus reglas solo por ese campo. Una regla cuya categoría es grupo de consolidación optimiza qué acaba embalado junto; una cuya categoría es pick path optimiza el desplazamiento. Esos dos objetivos tiran en direcciones opuestas, y una regla que declara uno mientras está ordenada para el otro no hará bien ninguno de los dos.
El Post 2 desmontó los cinco perfiles de uno en uno; esa es la referencia si necesitas el resto del objeto. Este post va solo de los que tocan el recorrido.
La quinta cosa, que solo funciona si ordenaste antes
En el mismo perfil de límites hay un campo que parece resolver cualquier requisito de tamaño y que casi nunca hace lo que la gente espera: Fld to Limit WO Size.
Especificas un campo de la warehouse task, y el sistema lo usa para limitar el tamaño de la orden. Suena a acumulador. No lo es.
Corta cuando el valor cambia, no cuando se alcanza un total
En cuanto el valor del campo indicado cambia mientras se procesan las tareas, el sistema deja de añadir tareas a esa warehouse order y crea una nueva. No suma nada hasta un tope: vigila un valor y corta en cuanto es distinto. Cualquier requisito del tipo «acumula hasta X» está en el sitio equivocado si usa este campo.
El ejemplo documentado es el uso honesto: limitar por ubicación de origen (VLPLA), de modo que en cuanto cambia la ubicación de origen de las tareas procesadas se crea una orden nueva. Una orden por ubicación, sin contar nada.
Y aquí está el enlace con todo lo anterior
La propia ayuda del campo recomienda definir una inbound sort rule en tu creation rule cuando lo uses. La razón es la que lleva sosteniendo este post desde el principio: si cortas cuando un valor cambia, el resultado depende por completo del orden en que lleguen las tareas. Sin ordenar primero por ese mismo campo, el valor va y viene, y obtienes una orden nueva cada vez que alterna. El límite no funciona solo — funciona encima de una ordenación.
También puedes limitar por un campo propio, rellenándolo en las warehouse tasks con /SCWM/EX_CORE_CR_INT_CR o /SCWM/EX_WHO_DSTGRP. Pero la dependencia no cambia: sigues necesitando que las tareas lleguen ordenadas por ese campo.
Los cuatro, en paralelo
Cuatro objetos. Dos viven en la misma regla y están a un campo de distancia en la misma pantalla. Los otros dos no están ni cerca del Customizing de warehouse orders.
Diagnosticar un recorrido malo, en orden
La queja siempre es «el pick path está mal». Recórrelo así y se resuelve antes del paso cuatro.
1. Mira las ubicaciones, no la secuencia. ¿Eran esas las ubicaciones correctas a visitar? Si la regla de extracción te manda cruzar el edificio por motivos de rotación, lo demás da igual.
2. ¿Cuándo se ejecutó por última vez la ordenación de ubicaciones? Si han cambiado ubicaciones o áreas desde entonces, para aquí y relánzala.
3. ¿La secuencia está simplemente invertida? Mira Sort Des. en los campos del perfil que aplique. Un recorrido invertido casi nunca es un problema complejo.
4. ¿Se agrupan las tareas equivocadas? Eso es inbound sorting y el valor límite, no WO sorting. Otro síntoma, otro campo.
5. Y solo ahora, mira el WO sorting — el que todo el mundo abre primero.
El patrón es el mismo con el que esta serie no para de toparse: el ajuste que lleva el nombre del síntoma rara vez es el que lo provoca.
Un ejemplo trabajado, de la entrega a los palets
Todo lo anterior es mecanismo. Aquí va una entrega atravesándolo entero, con los números a la vista en cada paso, porque lo interesante no es ninguna decisión suelta: es lo que se hacen unas a otras.
El requisito. Cada warehouse order tiene que ser exactamente un palet, y en un palet caben cincuenta piezas. Se pueden mezclar productos.
La entrega. Tres ítems: 100, 60 y 80 piezas. El stock está repartido en quince ubicaciones de cuatro áreas de actividad, con distintas fechas de entrada. La extracción es FIFO por fecha; cuando dos ubicaciones comparten fecha, decide la secuencia de ordenación.
Primero: el requisito no tiene campo
Lo evidente es poner un máximo de cincuenta en el perfil de límites. No hace lo que parece: ese campo restringe el número de tareas de la orden, no el de piezas. Cincuenta ahí son cincuenta warehouse tasks, que en esta entrega podrían ser desde unos cientos de piezas hasta unos miles.
No hay techo de piezas en el perfil. Así que traduces el requisito a un atributo que sí está y que se comporta de forma uniforme para estos productos. Aquí cada pieza son 0,1 m³:
Maximum Volume = 50 piezas × 0,1 m³ = 5,0 m³Pon Maximum Volume a 5, deja el máximo de posiciones a cero y añade Max. No. of HUs = 1 para que una orden solo pueda convertirse en un palet físico. El corte ocurre cuando el acumulado supera el techo, así que la pieza cincuenta cae justo en 5,0 m³ y entra; la cincuenta y uno llegaría a 5,1 y abre orden nueva.
Por qué no el peso
El peso también está en el perfil y también acumula. Es la elección equivocada aquí porque no es uniforme: estos tres ítems pesan distinto por pieza, así que un techo de peso cortaría en un número de piezas diferente en cada palet. El atributo que elijas tiene que ser el que de verdad se mantenga constante entre todo lo que permitas mezclar.
La Decisión 1 se ejecuta, y dispersa el trabajo
FIFO recorre ahora cada ítem por fechas. Todavía no existe ninguna warehouse order.
Mira dónde viven esas ubicaciones y el desenlace ya está decidido. A FIFO nadie le pidió respetar áreas de actividad, y no lo hizo: cruzó las cuatro, porque el stock más antiguo estaba repartido.
Las áreas trocean el trabajo antes de consultar ningún techo
La creation rule que aplica se obtiene del área de actividad, y el límite vive dentro de esa regla. Así que el límite solo puede actuar sobre las tareas de un área cada vez — el corte ya ocurrió.
Fíjate en las dos últimas filas antes de seguir. AA4 se queda con veinte piezas y AA2 con treinta. Nadie diseñó eso. Es lo que sobra cuando FIFO entra en un área a por un lote pequeño y se va.
Lo que el techo puede ver realmente
Falta una cosa por decir antes de que corra el límite, porque es lo que hace que las cuentas salgan como salen. El techo no ve piezas. Ve warehouse tasks, y una tarea es atómica: entra entera en una orden o abre la siguiente. Estas son las tareas de cada área:
AA1 es la interesante, porque seis tareas que suman 140 se pueden empaquetar de más de una manera bajo un techo de 50 piezas, y cuál te toca depende enteramente del orden en que lleguen.
Ese orden no es FIFO. FIFO construyó las tareas; no las presenta. Quien las presenta es la inbound sort rule de la creation rule — la Decisión 3 — y en esta configuración las intercala en vez de mantener cada ítem junto, así que AA1 llega como:
30 → 20 → 30 → 20 → 20 → 20Y solo ahora se aplica el techo
Seis palets para 240 piezas. Un empaquetado perfecto habrían sido cinco. El palet de más no es un error de configuración: cada ajuste hizo exactamente lo que se le dijo. Es la aritmética de un corte que ocurrió cuatro pasos antes, en un objeto cuyo nombre no tiene nada que ver con las warehouse orders.
Cambia solo la ordenación
Quita esa inbound sort y deja que las tareas lleguen en el orden en que FIFO las construyó —ítem 1 entero, luego ítem 2, luego ítem 3— y AA1 entra como 30, 30, 20, 20, 20, 20. Las dos primeras tareas ya suman 60, así que la primera orden cierra con una sola tarea de 30. AA1 produce entonces 30, 50, 40, 20 — cuatro órdenes en vez de tres, y la entrega sale en siete palets en vez de seis. Misma entrega, misma regla, mismo techo de 5,0 m³, mismo stock. Un palet más, siempre, por un campo de ordenación.
Qué cambió aquí la ordenación de ubicaciones
Dos de aquellas extracciones FIFO fueron empates: bin 7 contra bin 13 para las últimas diez piezas del ítem 1, y bin 5 contra bin 11 para las últimas veinte del ítem 2. Misma fecha, misma cantidad — los desempató la secuencia de ordenación de ubicaciones. Desempátalos al revés y la misma entrega vuelve a dar siete palets. Un desempate que nadie considera parte del diseño de órdenes cambió el número de palets del turno.
Ese es el argumento de este post en una entrega. El límite es el ajuste que todo el mundo edita, y fue lo último en ejecutarse y lo menos libre. Lo que podía hacer ya estaba acotado por una secuencia generada hace meses, una regla de extracción escrita por otro motivo, y un empate entre dos ubicaciones idénticas en cualquier pantalla que se te ocurra abrir.
Reflexión final
«Pick path» suena a funcionalidad. No lo es. Es un resultado — el efecto visible de cuatro decisiones independientes, tomadas en secuencia por cuatro objetos diseñados cada uno para optimizar otra cosa.
La regla de extracción protege la rotación del stock. La ordenación de ubicaciones describe geografía física. El inbound sorting traza las fronteras de los paquetes de trabajo. Solo el WO sorting hace algo que se parezca a guiar a una persona por un edificio, y es el último y el más débil de los cuatro, porque solo puede recolocar lo que le entregaron.
Por eso la pregunta útil nunca es «cuál es el ajuste del pick path». Es «cuál de los cuatro me ha dado esto, y era eso lo que le pedí que optimizara?»
Y con esto se cierra la serie. Cinco posts que empezaron preguntando por qué existen los warehouse orders, desmontaron una creation rule en sus perfiles, averiguaron qué regla se ejecuta de verdad, pusieron una a enrutar tareas hacia quien puede alcanzarlas, y terminan aquí — con las cuatro decisiones que dan forma a un recorrido, de las cuales solo dos están cerca de la regla que abrirías primero.
Si de los cinco sobrevive una costumbre, que sea esta: cuando una warehouse order sale mal, la creation rule es donde miras el último, no el primero. Para cuando se ejecuta, casi toda la respuesta ya se decidió en otro sitio.
Lecturas relacionadas
- Nada impide que el sistema mande a un operario a pie al nivel nueve — la cadena en la que se inserta este post, de la ubicación al grupo de recursos.
- Warehouse Process Type: el motor invisible — el objeto que decide a qué área de actividad pertenece una tarea y, por tanto, qué creation rule llega siquiera a consultarse.
- Automatic y Planned Replenishment en SAP EWM — de donde sale buena parte de las tareas que este post secuencia.
¿Mirando un recorrido que no tiene sentido?
Pregunta en lenguaje normal y obtén la transacción, la ruta de Customizing y el artículo del que sale — respondido como lo respondería un arquitecto de almacén.
Pregunta al asistente de EWM →
Cuenta gratuita · 20 preguntas al día · sin tarjeta
Parte de la serie Warehouse Orders
Inicio de la serie
Deja un comentario