Algunos “trucos” de planificación …

¿Qué escenarios son aquellos en la que la “Flexibilidad de Planificación” se modifica a Ninguna automáticamente?

Estoy seguro que lo sabéis pero, por recalcar el campo “Flexibilidad Planificación” modifica la disponibilidad del aprovisionamiento para que la lógica de planificación pueda realizar cambios (p.ej. mover fechas). Esta Flexibilidad Planificación es un campo disponible en las líneas de pedido de compra, transferencia, producción, … El usuario puede utilizar este campo para evitar cambios de última hora (p.ej. tenemos una acuerdo con el proveedor y ya es tarde para modificar el aprovisionamiento). Ahora, y está es la pregunta, ¿existe alguna otra circunstancia en la que este campo de modifique en la lógica? La respuesta es sí. La lógica de planificación, cuando calculamos el plan, modifica este campo en determinados escenarios:

-         Cuando la orden de producción se considera que ha comenzado. En este caso, la lógica determina si existen consumos realizados, o salidas de fábrica o, incluso, capacidades (o tiempos de máquina) registrados. En estos casos, la lógica considera que la producción ya ha comenzado y no puede modificarse la producción. NOTA: como curiosidad, podéis investigar la función TransProdOrderToProfile en la CU99000854.

-         Cuando el pedido de compra ya tiene cantidad recibida. En este caso, la lógica considera que el pedido ya ha sido enviado y, aunque sea una recepción parcial solamente, NAV considera que el resto de la cantidad a
recibir está en tránsito y, por tanto, tarde para modificar la compra. NOTA: como curiosidad, podéis investigar la función TransPurchLineToProfile en la CU99000854.

-         Cuando un pedido de ensamblaje ya tiene cantidad finalizada. Aquí, el razonamiento es el mismo que para la orden de producción. NOTA: como curiosidad, podéis investigar la función TransAsmHeaderToProfile en la CU99000854.

-         Cuando un pedido de transferencia ya tenga cantidad registrada (ya sea solamente el envío desde origen o envío y recepción en destino). En este caso, como para la compra, NAV asume que el pedido está en marcha y no se puede cambiar. En este caso, si además tenemos actividades de  almacén, tampoco dejará modificarlo. NOTA: como curiosidad, podéis investigar la función TransRcptTransLineToProfile en la CU99000854.

Hasta aquí, todo correcto. Puede ser más o menos discutible para todos los clientes pero, desde un punto de vista de funcionalidad estándar, pudiera ser razonable. Pero existe un escenario más, en el cual la planificación de NAV también modifica la lógica para marcar la Flexibilidad Planificación a Ninguna: cuando un aprovisionamiento tiene seguimiento de producto. En este caso, NAV tampoco deja modificarlo. La razón es que nuestro diseño asumo que, desde el momento en el que el usuario define un seguimiento de producto es cuando un aprovisionamiento es “formal”. Es decir, marcar un seguimiento de producto no es solamente asignar una etiqueta si no que es un proceso “crítico” que no debe hacerse más que en aquellos casos en los que tengamos certeza de dicho aprovisionamiento. Además, siendo una actividad del usuario el marcar el seguimiento, la planificación no puede eliminarlo (p.ej. cancelando el aprovisionamiento). Nosotros siempre decimos que el seguimiento de producto debe marcarse al final del proceso de negocio de aprovisionamiento. NOTA: como curiosidad, podéis investigar la función UnfoldItemTracking en la CU99000854.

¿Por qué calculamos el nivel de sobrepasamiento durante la planificación?

Antes de empezar, este nivel de sobrepasamiento aplica, solamente, a políticas con punto pedido: Cantidad fija a reaprovisionar y Cantidad Máxima. La respuesta a por qué utilizamos este nivel de stock, llamado de sobrepasamiento, está en el histórico de cambios que hemos realizado en la planificación:

-         Hasta la 5.0, NAV ha realizado re-planificaciones de aprovisionamientos existentes en función de los niveles de stock. Aquí no utilizábamos el nivel de sobrepasamiento.

-         En NAV 5.0 SP1, se realizó un cambio en el diseño: el aprovisionamiento que se haya creado no será modificado por la planificación. El razonamiento era que, si se ha creado manualmente, alguna razón habrá y, además, siendo una política contra stock, siempre se hará uso de este stock.
Sobre este diseño, estaría de acuerdo en vuestro comentario en que si incrementamos niveles de stock no es un razonamiento óptimo. De alguna forma, habría que saber cuál es un nivel óptimo de stock para saber si ese aprovisionamiento no hace sobrepasarlo o no para, de esta forma, sugerir cambios.

-         En NAV 2009 se introduce, solamente en la lógica, el Nivel de sobrepasamiento que, buscando una optimización, intenta determina cuál es el nivel de stock sobre el cual un aprovisionamiento debe ser cancelado. Por ejemplo, asumamos cantidad máxima. En este caso, el inventario máximo
representa el nivel de stock que, como máximo (lo siendo por la redundancia) podemos tener en nuestro almacén. Dicho nivel máximo puede ser una cuestión de espacio (si nuestro almacén es limitado) o económica (si este producto es caro y no queremos tener demasiado “parado”). Por ello, si tenemos un aprovisionamiento que nos hace llevar nuestro nivel de stock por encima de este inventario máximo podemos considerarlo como innecesario y dicho aprovisionamiento debe cancelarse o reducirse para no pasar de ese nivel de inventario máximo. Y, por ello, el nivel de sobrepasamiento que se utiliza en la lógica para Cantidad Máxima es el inventario máximo. Todo inventario proyectado por encima de este inventario máximo debe ser cancelado o reducido. Para Cantidad Fija Aprov. el nivel de sobrepasamiento se calcula en función de Punto Pedido + Cantidad a reaprov.

-         En NAV 2013 se introduce el nivel de sobrepasamiento como campo. De esta forma, el usuario (un planificador) puede poner lo que se considera como nivel de sobrepasamiento en función de la lógica por defecto.

Como comentaba en la primera frase, esto solamente aplica para políticas punto pedido. Una política contra pedido (Lote-a-lote o Pedido) no necesita un nivel de sobrepasamiento por dos razones: no crea stock, es la demanda la que corrige la necesidad del aprovisionamiento o no.

Sigfredo Beerman