Control de stock en Business Central con IA: el punto de pedido, recalculado cada semana.

Qué hace en con business central.

¿Cómo repone Business Central de serie?

Business Central repone con su sistema de planificación: tiene en cuenta toda la oferta (inventario, compras, transferencias de entrada, órdenes de producción) y toda la demanda (pedidos de venta, transferencias de salida, componentes, previsión), cuadra las dos y propone acciones concretas. Esas propuestas se llaman mensajes de acción y aparecen en la hoja de planificación o en la hoja de demanda: crear un pedido, cambiar su cantidad, reprogramarlo o cancelarlo. Quien planifica las revisa y ejecuta los mensajes de acción.

Lo que decide cuándo y cuánto reponer son los parámetros de planificación de cada producto, o de cada unidad de mantenimiento de existencias (SKU) si llevas el producto en varias ubicaciones. El principal es la directiva de reaprovisionamiento. Hay cuatro: Cdad. fija reaprov., Cdad. máxima, Pedido y Lote a lote. Las dos primeras trabajan con un punto de pedido; las otras dos reaccionan a la demanda concreta.

El campo Sistema de reposición de cada SKU dice además si se repone por compra, por transferencia desde otra ubicación o por producción. Con eso Business Central sabe si tiene que proponer un pedido de compra o un pedido de transferencia.

• Cdad. fija reaprov.: al bajar del punto de pedido, pide siempre la misma cantidad a pedir.
• Cdad. máxima: al bajar del punto de pedido, pide lo que falta hasta el stock máximo.
• Pedido: compra o fabrica para una demanda concreta, sin stock propio.
• Lote a lote: agrupa la demanda real y prevista dentro del periodo de acumulación de lotes y pide eso.
• Modificadores: cantidad mínima de pedido, cantidad máxima de pedido y múltiplos de pedido.

¿Qué es el punto de pedido en Business Central y por qué se queda viejo?

En la documentación de Microsoft, el punto de pedido representa la demanda durante un plazo de entrega: cuando el inventario proyectado baja de ese nivel, ha llegado el momento de pedir más. Es la definición clásica, y está bien. El problema es de dónde sale el número: alguien lo teclea en la ficha del producto o en la SKU, normalmente al migrar desde Navision o desde otro programa, y desde entonces no se toca.

Mientras tanto cambian tres cosas. Las ventas, que tienen temporada y tendencia. El plazo del proveedor, que pasa de 7 a 15 días sin que nadie actualice el campo. Y el surtido, con productos nuevos que heredan el punto de pedido de uno parecido. En una empresa con 1.500 productos y cuatro ubicaciones son 6.000 SKU. Nadie las repasa una a una, así que Compras corrige de memoria las que conoce y el resto se queda como está.

Microsoft advierte de otro detalle: con Cdad. fija reaprov. no se debe usar previsión, porque la demanda prevista ya está expresada en el punto de pedido. Dicho de otra manera, si el punto de pedido está mal, no hay previsión que lo arregle. Por eso tiene sentido recalcularlo.

¿Qué hace la extensión de previsión de ventas e inventario?

Es una extensión de Microsoft que usa Azure AI para predecir las ventas futuras con el historial de ventas. Toma los movimientos de productos de tipo venta (fecha de registro, número de producto y cantidad), los agrupa por el tipo de periodo que configures y devuelve una previsión. Microsoft sugiere usar previsión mensual con un horizonte de 12 meses. En la ficha del producto aparece el panel Previsión del producto, y al hacer un pedido de compra la extensión puede sugerir reponer otros productos del mismo proveedor que se van a agotar.

Para ver de un vistazo qué se va a acabar está bien. Pero la propia documentación marca sus límites. Genera una previsión agregada para todas las ubicaciones y variantes: si cada almacén es una tienda o una delegación, no da la previsión de cada uno y el reparto lo haces tú. No admite filtros, así que no se puede dividir el catálogo en partes. Microsoft estima que procesa unos 50.000 productos en 12 horas. Y si no encuentra datos suficientes o los datos varían mucho, no hace predicción.

Tampoco convierte la previsión en parámetros. El punto de pedido y el stock máximo siguen siendo los que había. Esa es la pieza que falta entre prever y reponer.

Lo que lee el programa de Business Central y lo que escribe de vuelta.

Se conecta por la API de Business Central, la v2.0 que publica Microsoft para que otros programas lean y escriban datos por REST. En la versión en línea las API vienen activas de serie; en una instalación local hay que activarlas. El acceso se da con permisos acotados: lectura de productos, movimientos, inventario y pedidos pendientes, y escritura solo en lo que se acuerde.

Lo que lee: los movimientos de productos de tipo venta por ubicación, con fecha de registro; el inventario por ubicación; los pedidos de compra y de transferencia pendientes de recibir; el plazo de entrega de cada producto o SKU; y los parámetros de planificación actuales, para compararlos con los propuestos. Con los movimientos y el inventario de hoy se reconstruye el stock de cada día hacia atrás, y así el programa sabe qué días no se vendió un producto porque no había.

Lo que escribe, en la forma que elijas: el punto de pedido, el stock de seguridad y el stock máximo de cada SKU, para que Business Central planifique con ellos; o líneas en la hoja de demanda con la propuesta de la semana. Microsoft indica que la API estándar no se puede ampliar con campos nuevos y que, si hace falta uno, se crea una página de API propia. Si es el caso, es una pieza pequeña, separada y revisable por tu partner.

• Lee: movimientos de productos, inventario por ubicación, pedidos pendientes, plazos, parámetros actuales.
• Escribe: punto de pedido, stock de seguridad y stock máximo por SKU, o líneas en la hoja de demanda.
• No toca: contabilidad, precios, clientes ni pedidos ya lanzados.

Varias ubicaciones, SKU y pedidos de transferencia.

Muchas empresas en Business Central tienen un almacén central y varias delegaciones, o una ubicación por tienda. Cada una con su SKU y su punto de pedido. El programa mira cada ubicación con sus propias ventas y su propio plazo (el del proveedor para el central, el del camión interno para las delegaciones) y después todas juntas.

Antes de proponer una compra para Bilbao, comprueba si el producto sobra en Sevilla. Si compensa, propone un pedido de transferencia, con lo que cuesta mover frente a lo que cuesta pedir, y Business Central lo trata como cualquier otra transferencia. Si usáis la previsión de la demanda por ubicación (la opción Usar previsiones en ubicaciones de la configuración de inventario), la previsión que cargamos va también por ubicación.

Previsión de la demanda y MPS: dejar de teclear la matriz.

Si fabricas o montas, probablemente usas la página Previsión de la demanda para el plan maestro de producción. Microsoft lo describe así: las previsiones se crean manualmente, cada registro tiene número de producto, fecha y cantidad, y el tipo de previsión es Producto venta, Componente o Ambos. Solo se puede usar una previsión para planificar. Con trescientos productos y doce meses son 3.600 casillas que alguien rellena y nadie revisa.

El programa calcula esa previsión con las ventas, la deja en la matriz con el tipo que uséis y la actualiza cada mes o cada semana. Business Central planifica con ella igual que con la tecleada. Para esos productos, la directiva que encaja es Lote a lote, que es la que Microsoft recomienda cuando el plan se basa en una previsión.

Lo que no hace.

No sustituye a Business Central ni a su sistema de planificación. No lanza pedidos sin que nadie los mire: la propuesta vuelve como parámetros o como líneas en la hoja de demanda, y la persona de Compras decide. No toca la contabilidad, ni los precios, ni los pedidos ya lanzados. Y no garantiza que no haya roturas: reduce el riesgo y te dice cuál es, producto a producto.

Tampoco hace falta para todos. Si tienes una ubicación, un centenar de productos y proveedores que sirven en dos días, unos parámetros de planificación bien puestos y repasados cada trimestre te bastan, y te lo diremos en el diagnóstico.

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

Primero, con tus meses pasados. El programa vuelve a decidir cada semana solo con lo que se sabía esa semana, desde el stock que había en cada ubicación, y se compara con lo que hizo Business Central con vuestros parámetros: demanda atendida, roturas, pedidos, unidades y dinero parado. Las medidas se fijan antes de ver el resultado. Si no mejora lo que hacéis, se dice ahí.

Después, uno o dos meses en modo sombra: el programa propone cada semana con datos frescos y vosotros seguís con vuestros parámetros. Al final se mide qué habría pasado. Solo entonces se le da permiso de escritura. Si quieres saber antes si esto es para ti, el análisis gratuito parte de un export de movimientos de productos y de inventario por ubicación, y te devuelve un informe corto con lo que cambiaríamos primero.

¿Te suena alguno de estos casos?

• Si migrasteis de Navision o de otro ERP y los puntos de pedido vinieron copiados Es lo más habitual. Los parámetros de planificación pasaron tal cual y desde entonces han cambiado ventas, proveedores y plazos. El programa los recalcula cada semana con lo que vende hoy cada producto en cada ubicación.
• Si sois distribuidor con varias ubicaciones y SKU por almacén y los traslados entre delegaciones se deciden por teléfono. Cada ubicación se mira con sus ventas y sus plazos, y los pedidos de transferencia se proponen antes que la compra.
• Si probasteis la extensión de previsión y no os servía por almacén La extensión prevé el total y tienes que repartirlo. Aquí la previsión sale por ubicación y por semana, con el riesgo de rotura de cada una.
• Si rellenáis la previsión de la demanda a mano para el MPS La matriz de previsión de la demanda se teclea producto a producto. El programa la calcula con las ventas y la deja lista para cargar, con el tipo de previsión que uséis.
• Si tu partner de Business Central no quiere desarrollos dentro El programa vive fuera y habla con Business Central por la API. Si hace falta una página de API propia, es una pieza pequeña y aislada que tu partner revisa.
• Si tu producto tiene temporada y el punto de pedido es el mismo todo el año Climatización, jardín, material escolar, bebidas. El punto de pedido de invierno no vale en verano. Aquí cambia cada semana con la temporada aprendida de tus propios datos.

Business Central sigue planificando. Cambian los números que usa.

No sustituye la hoja de planificación ni el cálculo de MRP, y no es otro programa donde volver a teclear lo que ya está en Business Central. Es un motor que lee de Business Central, calcula fuera y devuelve la decisión a los campos que el sistema de planificación ya usa: el punto de pedido, el stock máximo y el stock de seguridad de cada SKU, o líneas en la hoja de demanda. Se prueba con tu histórico antes de escribir nada, y el código queda a tu nombre.

• Previsión por producto y ubicación, no un total que hay que repartir.
• La decisión vuelve como parámetros de planificación o como líneas en la hoja de demanda. Tú eliges.
• Cada propuesta lleva su porqué: venta prevista, plazo, stock a mano y en camino, riesgo.
• Primero la prueba con tus meses pasados, con cifras, y después uno o dos meses en modo sombra.