Dos consultores heredan el mismo almacén. Uno mantiene el mínimo/máximo con religiosidad en /SCWM/MAT1, el maestro de producto. El otro lo mantiene con el mismo cuidado en /SCWM/BINMAT, en la propia ubicación fija. Los dos números son correctos. Los dos están al día. Ninguno de los dos está equivocado.
Solo uno de ellos se lee jamás.
Cuál de los dos depende de un único campo que no vive en ninguna de las dos pantallas — vive en el propio storage type, en una sección a la que casi nadie llega haciendo scroll. Confúndelo y te pasas la tarde mirando un maestro de producto que, técnicamente, es perfectamente correcto.
En qué se apoya este post
Capturas reales del sistema — Almacén 1710, storage type Y021 — contrastadas contra la ayuda F1 de cada campo, no contra un resumen de ella. Dos de los ejemplos de abajo son trazas de movimientos que ocurrieron de verdad, no ilustraciones construidas.
El campo que decide qué pantalla es la real
Replenishment Level vive en el propio storage type — Define Storage Type, en la sección Replenishment al final de la pantalla, junto a dos campos a los que llegaremos enseguida. Su propia ayuda es directa sobre lo que hace:
F1 — Replenishment Level
«Specifies whether the replenishment in this storage type is requested at storage bin level (fixed bin storage only) or at storage type level.» Uso: «In fixed bin storage areas in which you want to request replenishment for each fixed bin, use the replenishment level ‘Fixed Bin’. In fixed bin storage areas in which you want to view the entire stock across all fixed bins, or in storage types without fixed bins, use the replenishment level ‘Storage Type’.»
Esa última frase es fácil de pasar por alto en una primera lectura: «Storage Type level» no es solo para storage types sin ubicación fija — puedes elegirlo deliberadamente dentro de un área de bin fija también, cuando lo que quieres es la foto agregada de todas las ubicaciones en vez de un disparador por ubicación individual. Es una decisión de diseño, no un valor por defecto.
Nada de esto es un orden de prioridad, y nada reconcilia los dos. El ajuste que no está activo no es un respaldo, ni una fuente secundaria, ni se consulta si el principal está vacío. Simplemente no se lee. Dos números correctos, y el sistema mira exactamente uno de ellos.
Dónde se queman los equipos
El mínimo/máximo de un producto en /SCWM/MAT1 se actualiza tras una revisión de demanda. El comportamiento de la reposición no cambia. A nadie se le ocurre revisar Repl. Level, porque el campo que se acaba de editar parecía el correcto. Si ese storage type funciona a nivel Fixed Bin, la actualización fue real, correcta y completamente inerte — los números que de verdad gobiernan la reposición son los que siguen intactos en la ubicación.
Y el fallo inverso es todavía más silencioso: a nivel Fixed Bin, si un producto no tiene ninguna ubicación fija asignada en /SCWM/BINMAT, no hay nada que reponer y nada que te avise de ello. El maestro de producto puede estar impecable y no va a importar.
Una traza: Automatic Replenishment entrando en negativo
Storage type Y021, Repl. Level = Fixed Bin. El mínimo de la ubicación es 0, el máximo 48, y el storage type permite stock negativo. Esto es lo que pasó de verdad, confirmado paso a paso.
1. La ubicación tiene 10 piezas. Se confirma una WT de picking de 10 — el stock queda en 0. Cero no es menor que el mínimo de cero, así que todavía no dispara nada.
2. Otro pedido necesita 5 más. Como se permite stock negativo, el sistema la confirma igualmente — el stock pasa a −5.
3. Automatic Replenishment se dispara inmediatamente después de esa confirmación — su disparador es la confirmación en sí, no el picking físico. −5 está por debajo del mínimo de 0, así que se dispara.
La fórmula es la ya establecida para este método:
Cantidad = Máximo − Stock actual = 48 − (−5) = 53Restar un negativo hace exactamente lo que parece: suma el déficit encima del máximo. La tarea de reposición no solo rellena la ubicación — antes salda el descubierto.
El redondeo que cambia el número final
Si hay una Minimum Replenishment Quantity de 10 mantenida, el 53 calculado no sobrevive tal cual: Automatic y Planned redondean la cantidad de reposición a la baja a un múltiplo de ese valor. 53 redondea a 50 — y la ubicación termina el ciclo en 45, cinco por debajo de su propio máximo, hasta que el siguiente disparo cierre el hueco.
Una traza: Order-Related Replenishment excediendo el máximo
Misma mecánica, pregunta distinta. Order-related no pregunta «¿está la ubicación por debajo de su mínimo?» — pregunta «¿se pueden cubrir los warehouse requests abiertos con lo que hay aquí ahora mismo?»
Pick face con 20 piezas. Los warehouse requests abiertos necesitan 40. Mínimo de la ubicación 10, máximo 30 — un pallet completo, a 30 piezas por pallet.
Faltante: 40 requeridas − 20 disponibles = 20 piezas que faltan.
Redondeo: Order-related redondea al alza, a una unidad de manejo completa donde haya una definida. 20 redondea a un pallet completo — 30 piezas — no a las 20 que realmente faltaban.
Resultado: la ubicación recibe 30. Stock inicial 20 + 30 = 50 — veinte piezas por encima de un máximo de 30.
Automatic y Planned nunca producirían ese número; los dos se paran en seco en el máximo. Order-related tiene permiso para pasarse, a propósito, porque la alternativa —pararse exactamente en el máximo y dejar el pedido a medio cubrir, o mover un pallet roto para cubrir la diferencia— es peor que una ubicación temporalmente por encima de su capacidad.
Esto no es una regla nueva — el post de Order-Based ya estableció que el máximo se puede exceder aquí. Lo que añade esta traza es el mecanismo: es el redondeo a unidad completa lo que empuja el resultado más allá del techo, no el cálculo del faltante en sí, que aterrizó exactamente en las 20 que faltaban.
Tolerance y Tolerance WT: unidades completas frente a la cantidad exacta
Dos campos más viven en esa misma sección de Replenishment del storage type, y responden a una pregunta que ninguna de las dos trazas anteriores toca: ¿qué pasa cuando la cantidad de reposición no divide exactamente en lo que sea que la reserva está sirviendo?
F1 — Check Tolerance Replenishment Quantity During WT Creation
«If you select this checkbox, the system ends warehouse task creation when the warehouse task (WT) quantity reaches the tolerance level, so no more WTs are created for a partial quantity of a handling unit. You can use this to prevent the system from creating further replenishment WTs after a sufficient quantity has been reached… This is useful if it is more important to you that replenishment reaches a whole handling unit and does not create partial quantities in the reserve area, than that the original planned replenishment quantity is maintained.» Dependencia: «If you select this checkbox, you must also enter a value in the Tolerance field.»
Lee más allá del nombre de la casilla, porque no hace lo que suena que hace. Esto no va de aceptar una reposición que se quedó corta. Es una declaración de compromiso: ¿prefieres llegar exactamente a la cantidad planificada, o parar una unidad de manejo antes y no abrir nunca una en la zona de reserva? Con Tolerance WT activo, en cuanto la cantidad acumulada de la tarea alcanza el nivel de tolerancia, el sistema se para — aunque eso deje la ubicación por debajo de lo que Planned o Automatic habían calculado originalmente.
Sin él, la reposición sigue creando tareas hasta cumplir exactamente la cantidad planificada, lo que puede significar que la última tarea saque una fracción de un pallet o una caja de la zona de reserva — cómodo para la ubicación de picking, incómodo para quien gestiona la reserva después.
La trampa en el nombre del campo
Un borrador de trabajo anterior de este material leyó Tolerance WT como el cierre de la replenishment request al llegar a un porcentaje — razonable de suponer solo por el nombre del campo, y equivocado. La F1 es específica: va de unidades de manejo completas en la zona de origen, y el compromiso está planteado como deliberado. Merece la pena recordar el patrón de antes en esta serie: el nombre de un campo es una pista, no una especificación.
Dónde mirar, en orden
Cuando una cantidad de reposición no coincide con lo que dice el maestro de producto:
1. Lee Repl. Level en el storage type primero. Si es Fixed Bin, el maestro de producto no es de donde salieron los números — ve a /SCWM/BINMAT.
2. Si la ubicación está por encima de su máximo, comprueba si el último disparo fue Order-related antes de asumir un problema de datos.
3. Si una corrida de reposición se quedó corta de la cantidad planificada sin ningún error por ningún sitio, revisa Tolerance WT antes de revisar nada del cálculo de demanda.
Ninguno de los tres es un parte de fallo. Los tres son el sistema haciendo exactamente lo que se le dijo, en un campo que no era el que nadie estaba mirando.
Reflexión final
La serie hasta ahora ha ido de los cuatro métodos y qué decide entre ellos — cuándo usar protección planificada, urgencia dirigida por pedido, reacción automática, o una persona en la ubicación. Este post está por debajo de los cuatro: nada de esa elección importa si el storage type está leyendo, en silencio, de una pantalla que nadie actualiza.
Dos fuentes de datos correctas y un interruptor silencioso entre ellas no es un defecto. Es la forma normal de un storage type que se configuró una vez, correctamente, por alguien que entendía exactamente qué hacía Repl. Level — y nunca lo dejó escrito en ningún sitio donde la siguiente persona pudiera encontrarlo.
Parte de la serie Replenishment · la extra
Inicio de la serie
Deja un comentario