Reposición automática en Business Central: el programa propone, pero con el punto de pedido que alguien tecleó.

Qué hace en reposición automática en business central.

¿Cómo repone Business Central de forma automática?

Business Central repone con el sistema de planificación: toma toda la demanda (pedidos de venta, transferencias de salida, componentes, previsión) y todo el suministro (inventario, compras, transferencias de entrada, órdenes de producción), los equilibra y propone acciones. Esas propuestas son los mensajes de acción, y se ven en la hoja de planificación o en la hoja de demanda.

El método habitual es Calcular planificación regenerativa en la hoja de planificación, que abre la página Calcular plan. Allí se fijan la fecha inicial y la fecha final del horizonte, la previsión de la demanda que se usa y los filtros por producto o ubicación. Según Microsoft, si el horizonte es demasiado corto los productos con plazo largo no se piden a tiempo, y si es demasiado largo se pierde tiempo revisando información que cambiará. Hay también un cálculo de cambio neto, que solo reprocesa lo que ha cambiado, y la recomendación de Microsoft es lanzar el regenerativo semanalmente y el de cambio neto a diario.

Cada línea que sale lleva un mensaje de acción. Nuevo sugiere un pedido nuevo. Cambiar cantidad modifica uno existente. Reprogramar mueve su fecha. Reprogramar y cambiar cantidad hace las dos cosas. Cancelar propone anularlo. Después de revisarlas se marca Aceptar mensaje acción y se lanza Ejecutar mensajes de acción, que crea los pedidos de compra y de transferencia, con o sin imprimir, o los copia a una hoja de demanda para procesarlos después.

• Hoja de planificación: plan regenerativo o de cambio neto, con todos los tipos de reposición.
• Hoja de demanda: reposición por compra y transferencia, útil si Compras es otro equipo.
• Ejecutar mensajes de acción: convierte las propuestas aceptadas en pedidos.

¿Qué decide cuánto se repone: las directivas y los parámetros?

Cada producto, o cada SKU si lo llevas por ubicación, tiene una directiva de reaprovisionamiento. Microsoft documenta cuatro: Cdad. fija reaprov., Cdad. máxima, Pedido y Lote a lote. Con Cdad. fija reaprov., al cruzar el punto de pedido se pide siempre la misma cantidad. Con Cdad. máxima se pide lo que falta hasta el stock máximo, así que la cantidad cambia en cada pedido. Con Lote a lote se reacciona solo a la demanda real y prevista, agrupada en los periodos de acumulación que se definan. Con Pedido se compra o fabrica contra una demanda concreta.

A eso se suman los parámetros de la SKU: Punto pedido, Stock máximo, Cantidad a pedir, Cantidad de stock de seguridad, Tiempo de margen de seguridad, Ciclo, Periodo de acumulación de lotes y Periodo de replanificación. Y los modificadores de pedido: Cantidad mínima pedido, Cantidad máxima pedido y Múltiplos de pedido. El campo Sistema de reposición de la SKU dice si se repone por Compra, por Transferencia desde otra ubicación o por producción.

También hay un detalle de configuración por ubicación que importa en las empresas con muchas: el campo Directiva de planeación de SKU que falta, en la Tarjeta de ubicación, decide qué pasa si la demanda llega a una ubicación donde no existe SKU: mantener el comportamiento mínimo, usar los parámetros de la ficha del producto, o no planificar. En una red con delegaciones nuevas, es la diferencia entre que Business Central proponga o se calle.

¿Por qué el punto de pedido fijo deja de servir?

Microsoft define el punto de pedido como la demanda durante un plazo de entrega: cuando el inventario proyectado baja de ese nivel, toca pedir. Es una definición correcta, y precisamente por eso el número depende de dos cosas que cambian: lo que se vende por semana y lo que tarda el proveedor. Si alguno se mueve, el punto de pedido correcto es otro y el campo sigue diciendo lo de hace dos años.

La propia documentación lo trata como una señal. La advertencia de excepción aparece cuando el inventario disponible previsto cae por debajo del stock de seguridad, y Microsoft indica que infringirlo se considera una excepción porque no debería ocurrir si el punto de pedido está bien configurado. Cuando esa advertencia sale cada semana en las mismas SKU, lo que falla no es el cálculo, es el parámetro.

En la práctica, Compras corrige a mano: adelanta un pedido, sube una cantidad, ignora una sugerencia que ya sabe que sobra. Cada corrección es información que el programa no recoge. Y la advertencia de emergencia, que sugiere un pedido por la cantidad exacta que falta sin respetar mínimos ni múltiplos, suele ser la forma en que se entera de que el parámetro llegó tarde.

Un ejemplo con cifras: un grifo monomando en Sevilla.

La mayorista de fontanería del ejemplo tiene el grifo monomando con Cdad. máxima en la SKU de Sevilla: punto de pedido 20, stock de seguridad 6 y stock máximo 60, teclados hace año y medio, cuando se vendían 9 a la semana y el proveedor servía en 7 días. Hoy se venden 18 a la semana y el proveedor tarda 12 días.

La demanda durante el plazo es 18 por 12 entre 7, que son unas 31 unidades. El punto de pedido de 20 ya queda por debajo de ese nivel: cuando Business Central avisa, el producto no llega a tiempo, y la advertencia de excepción por stock de seguridad aparece sistemáticamente. El sistema recalcula con la banda de la previsión: punto de pedido 40, stock de seguridad 9 y stock máximo 72 para cubrir el ciclo semanal y el pedido mínimo del proveedor.

Business Central sigue planificando como siempre, pero con 40 en vez de 20: el pedido sale cuando toca. La propuesta, en la hoja de demanda o en los parámetros, lleva su frase: «Sevilla vende 18 a la semana, el proveedor tarda 12 días: el punto de pedido de 20 cubre solo 8 días». Las cifras son ilustrativas; las tuyas salen del diagnóstico.

¿Cómo repone el sistema encima de Business Central?

Cada semana lee las ventas, el inventario por ubicación y los pedidos pendientes, y calcula para cada SKU la venta prevista hasta que pueda llegar el siguiente pedido, con una banda. De ahí salen los parámetros que corresponden a la directiva de cada producto: punto de pedido y stock máximo para Cdad. máxima, punto de pedido y cantidad a pedir para Cdad. fija reaprov., y la previsión para los que van con Lote a lote.

Antes de proponer comprar, mira las demás ubicaciones. Si Sevilla va justa y Madrid tiene stock de sobra, la propuesta es un pedido de transferencia, y para una SKU con Sistema de reposición en Transferencia ya es lo que Business Central esperaría. Solo lo que falta en el conjunto pasa a compra, agrupado por proveedor, con los modificadores de pedido aplicados: mínimo, máximo y múltiplos.

La propuesta puede llegar de dos maneras. Parámetros: el sistema actualiza los campos de la SKU y Business Central planifica con ellos al ejecutar Calcular plan. Hoja de demanda: el sistema deja líneas listas para revisar, y se ejecutan como cualquier otra línea. Se puede empezar por la segunda para tener visibilidad completa y pasar a la primera cuando el modo sombra haya convencido.

Lo que lee, lo que escribe y lo que no toca.

Lee por la API v2.0 de Business Central con un usuario de aplicación acotado: productos y SKU con sus parámetros de planificación actuales, movimientos de venta por ubicación, inventario, pedidos de compra y transferencia pendientes, y plazos de entrega. Con los pedidos recibidos calcula también el plazo real de cada proveedor.

Escribe, con permiso y tras el modo sombra, los parámetros de planificación de la SKU o las líneas de la hoja de demanda. Si la API estándar no tiene el campo, Microsoft indica que se crea una página de API propia, y así se hace: una pieza pequeña, separada, que tu partner puede revisar. Todo lo que cambia queda en un registro con el valor anterior y el nuevo.

• Lee: parámetros de planificación, ventas, inventario, pedidos pendientes, recepciones.
• Escribe, con permiso: punto de pedido, stock de seguridad y stock máximo, o líneas en la hoja de demanda.
• No toca: contabilidad, precios, pedidos ya lanzados ni listas de materiales.

Lo que no hace.

No lanza pedidos por su cuenta: la propuesta se aprueba y los mensajes de acción los ejecuta una persona. No sustituye el MRP de Business Central, ni se ocupa de productos fabricados con listas de materiales y rutas. No resuelve la capacidad de un proveedor ni evita que un camión llegue tarde. Y no hace falta en todas las empresas: con una ubicación, pocos productos y proveedores que sirven en dos días, unos parámetros bien puestos y revisados cada trimestre bastan.

Cómo se comprueba y cómo se empieza.

La comprobación es con tu pasado. El sistema repite semana a semana los últimos meses con lo que se sabía cada día y compara lo que habría propuesto con lo que Business Central pidió con tus parámetros: roturas, unidades en almacén, pedidos y dinero parado. Las medidas se fijan antes de ver el resultado. Después, uno o dos meses en modo sombra con datos frescos y, solo si convence, el permiso de escritura.

Para empezar basta un export de las SKU con sus parámetros, de los movimientos de venta y del inventario por ubicación. El análisis gratuito lo usa para devolverte un informe corto con las SKU cuyo parámetro está más desfasado.

¿Te suena alguno de estos casos?

• Si corres Calcular plan cada semana y Compras rehace a mano medio plan Es la señal de que los parámetros están viejos. El sistema reduce esa corrección manual recalculándolos con la venta de la semana.
• Si migraste de Navision y los puntos de pedido vinieron copiados Los parámetros pasaron tal cual y desde entonces han cambiado ventas, proveedores y plazos. Se revisan los miles de SKU en una pasada, con una lista de lo que más cambia.
• Si tienes el campo Sistema de reposición en Transferencia en muchas SKU Las delegaciones se reponen desde el central. El sistema mira primero si el central tiene el producto antes de proponer comprarlo.
• Si usas Cdad. máxima en unos productos y Lote a lote en otros Cada producto se queda con su directiva. El sistema propone la directiva que encaja con su ritmo de venta y deja que Compras decida.
• Si los proveedores tienen pedido mínimo o venden por múltiplos Cantidad mínima de pedido, cantidad máxima de pedido y múltiplos de pedido se respetan. La propuesta ya viene redondeada a cajas y palets.
• Si Compras ejecuta mensajes de acción sin saber por qué La hoja de planificación dice qué hacer, pero no por qué. Aquí cada línea lleva la explicación, y la persona que ejecuta sabe si el pedido es por subida de ventas o por un plazo más largo.

La planificación de Business Central se queda. Cambian sus entradas.

No sustituimos la hoja de planificación ni el cálculo de MRP. Dejamos de tener números viejos en sus campos. El sistema lee tus ventas y tus pedidos pendientes, calcula fuera y devuelve el resultado en los campos que el sistema de planificación ya usa, o en líneas de la hoja de demanda. Se prueba primero con tu histórico y se arranca en modo sombra, y el código queda a tu nombre.

• Punto de pedido, stock de seguridad y stock máximo recalculados cada semana por SKU.
• O propuesta en la hoja de demanda, agrupada por proveedor, con su porqué.
• Transferencia entre ubicaciones antes que compra nueva.
• Compras aprueba y ejecuta los mensajes de acción como siempre.