Previsión de demanda en Business Central: la de Microsoft es un total, tú necesitas una por ubicación.

Qué hace en previsión de demanda en business central.

¿Qué previsión de demanda trae Business Central de serie?

Business Central trae dos formas de prever la demanda: la página Previsión de la demanda, que se rellena a mano, y la extensión Previsión de ventas e inventario, que calcula con Azure AI a partir del historial de ventas. Las dos conviven y sirven para cosas distintas, y conviene tener claro cuál es cuál antes de decidir si falta algo.

La página Previsión de la demanda es la que alimenta la planificación. Según Microsoft, una previsión representa la demanda esperada antes de que las ventas y los pedidos de producción generen demanda real, y está formada por registros que llevan un número de producto, una fecha de previsión y una cantidad prevista. Se pueden tener varias previsiones, distinguidas por nombre y tipo, pero solo una se usa para planificar. El tipo puede ser Producto venta, Componente o Ambos, y la matriz se rellena escribiendo una cantidad en la celda de cada producto y periodo.

La extensión Previsión de ventas e inventario hace otro trabajo: predice ventas potenciales con datos históricos y da una vista clara de la falta de stock prevista. En la página Productos, al seleccionar uno, la ficha Previsión del producto muestra sus ventas futuras estimadas, y la propia extensión puede sugerir qué reponer cuando creas un pedido de compra a un proveedor. Es una herramienta de consulta rápida más que de planificación.

• Previsión de la demanda (página): manual, por producto, fecha y cantidad. Alimenta el plan.
• Previsión de ventas e inventario (extensión): automática con Azure AI. Informa y sugiere.
• Las dos requieren que alguien las mire: ninguna cambia por sí sola el punto de pedido de nadie.

¿Cómo funciona la extensión Previsión de ventas e inventario?

La extensión toma los movimientos de producto de la página Movs. productos, solo los de tipo de entrada Venta, y de ellos usa tres campos: Fecha de registro, N.º producto y Cantidad. La ventana de historial la marcan los campos Periodos históricos y Tipo de periodo de la página Configuración de previsión de ventas e inventario. Antes de enviarlos al servicio, Business Central comprime las transacciones por número de producto y fecha de registro según el tipo de periodo.

La previsión se puede configurar con otro tipo de periodo, por ejemplo trimestral en lugar de mensual, y con el número de periodos que se quieren calcular. Microsoft sugiere previsión mensual con un horizonte de 12 meses. Los servicios web de predicción no tienen estado: usan los datos solo para calcular bajo demanda y no los almacenan. En Business Central en línea el modelo lo publica Microsoft, y en otras implantaciones se puede conectar uno propio rellenando la URL de API y la clave de API de esa misma página de configuración.

La documentación es honesta con el límite del método: cuantos más datos se den, más precisas serán las predicciones, las grandes variaciones entre periodos afectan al resultado y, si el servicio no encuentra suficientes datos o los datos varían mucho, no hace ninguna predicción. Para un catálogo con productos de venta salteada, eso significa huecos: justamente los productos que más cuesta planificar.

¿Por qué una previsión agregada no basta si repones a varias ubicaciones?

Porque lo que se decide en un almacén es cuánto mandar a cada sitio, no cuánto se vende en total. Microsoft lo dice en su documentación: la extensión genera una previsión agregada para todas las ubicaciones y variantes, y si tienes varios almacenes que representan distintas tiendas, no puedes obtener la previsión de cada uno; después debes distribuir los importes. Tampoco admite filtrado, así que no se pueden separar los productos en secciones.

Un ejemplo con una distribuidora de recambios de climatización. El total de condensadores de arranque para el mes que viene sale en 310 unidades. Pero Valencia vende en abril el triple que Vigo, Sevilla depende de dos instaladores grandes que compran por lotes y Bilbao casi no tiene temporada. Repartir 310 en partes iguales, o en el porcentaje del año pasado, manda de más a un sitio y de menos a otro, y la rotura aparece en el que menos stock tenía de más.

El reparto no es una operación menor. Es la decisión que mueve el stock entre ubicaciones, y hacerla en una hoja de cálculo cada mes, a ojo, es lo que se quiere evitar. Por eso la previsión que sirve para reponer tiene que nacer por ubicación y sumarse después, no al revés.

¿Cómo usa Business Central la previsión al planificar?

La planificación trata la previsión como una demanda más. Según Microsoft, para una previsión de tipo Producto venta, los pedidos de venta reducen la previsión: la cantidad prevista se consume con la demanda real. Esto evita contar dos veces lo mismo, y es lo que hace que la previsión sirva para anticipar compras sin inflarlas cuando entran los pedidos.

En la página Configuración de inventario se puede elegir si se respetan las ubicaciones de las entradas de previsión con el interruptor Usar previsiones en ubicaciones. Microsoft pone este ejemplo: dos ubicaciones, ESTE y OESTE, con política lote a lote, una previsión de 10 piezas para ESTE y 4 para OESTE, y un pedido de cliente de 12 en OESTE. Con el interruptor activado, el sistema sugiere reponer 10 para ESTE por la previsión y 12 para OESTE por el pedido, porque las 4 previstas se consumen del todo. Con el interruptor apagado, ignora las ubicaciones y agrega la previsión en una ubicación vacía, con un resultado distinto: 12 para OESTE y 2 para la ubicación en blanco.

Hay una indicación más que condiciona cómo usar la previsión. Microsoft señala que con la directiva Cdad. fija reaprov. no hace falta incluir previsión, porque la demanda prevista ya está expresada en el punto de pedido, y que si se quiere basar el plan en una previsión hay que usar Lote a lote. Es decir, la previsión sirve de verdad con Lote a lote, y con las directivas de punto de pedido hay que trasladarla al propio punto de pedido, que es lo que cuenta la página de reposición automática.

¿Qué calcula el sistema por encima de Business Central?

Para cada producto y cada ubicación, el sistema calcula la venta prevista de cada semana con tres ingredientes. El primero es el historial de esa ubicación, con su ritmo y sus semanas altas. El segundo es la temporada que se ve en los productos parecidos de todas las ubicaciones, que ayuda a los productos con poco historial. El tercero es el estado del stock: una semana en la que el producto se agotó el martes no mide demanda de semana completa, y se corrige para no aprender un ritmo falso.

Los productos de venta salteada, que en un catálogo de recambios o de material técnico son muchos, no se prevén con una media. Se usan métodos de demanda intermitente, como el método de Croston, que estima por separado cada cuánto se vende y cuánto se vende cuando se vende. El resultado es una probabilidad de pedido por semana, mucho más útil para decidir cuántas unidades tener que una media de 0,6 al mes.

Cada previsión viene con su banda, que es la que alimenta el stock de seguridad. Un producto estable tiene una banda estrecha y necesita poco colchón. Uno irregular tiene una banda ancha, y el sistema lo dice en la propuesta en lugar de esconderlo en una media.

Un ejemplo con cifras: condensadores en tres delegaciones.

Tomemos un mismo producto en tres delegaciones, con ventas inventadas pero realistas de las últimas ocho semanas. En Valencia: 8, 9, 11, 12, 10, 14, 15, 17 unidades por semana, con una subida clara por el calor. En Vigo: 4, 3, 5, 4, 4, 5, 4, 5. En Sevilla: 0, 20, 0, 0, 18, 0, 0, 24, porque compran dos instaladores por lotes.

Un total agregado de las tres daría unas 24 unidades semanales de media, y repartido en tercios saldrían 8 a cada una. En Valencia faltarían, porque va a 17 y subiendo, y sobrarían en Vigo, que vende 4. En Sevilla la media de 8 por semana no describe nada: casi todas las semanas vende cero y de vez en cuando 20. Con previsión por ubicación, Valencia sale con unas 19 para la semana próxima y banda ancha hacia arriba, Vigo con 4 y banda estrecha, y Sevilla con una probabilidad alta de cero y una probabilidad de un pedido de 20 a 24 cada dos o tres semanas.

Para Compras la diferencia es concreta. A Valencia se le manda más y antes. A Vigo se le mantiene lo que tiene. En Sevilla no se llena el almacén de condensadores esperando un pedido que llegará cuando llegue: se guarda stock en el central y se prepara el envío cuando el instalador avisa. Los números de este ejemplo son ilustrativos; los de tu negocio salen del diagnóstico.

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

Se conecta por la API de Business Central, la v2.0 que publica Microsoft. Lee con un usuario de aplicación con permisos de lectura: movimientos de productos de tipo Venta con fecha de registro, producto, ubicación y cantidad, el inventario por ubicación, los pedidos de compra y de transferencia pendientes y los plazos de entrega. No necesita clientes ni importes para prever cantidades.

Lo que escribe, si se le deja, es la previsión en la matriz de la página Previsión de la demanda, por ubicación y con el tipo Producto venta. Si la API estándar no expone lo que hace falta escribir, se publica una página de API propia, pequeña y revisable por tu partner, que es la vía que indica Microsoft para ampliar. Mientras no haya permiso de escritura, la previsión se enseña en un panel y se compara con lo que ya usas.

El sistema calcula la previsión y propone. La decisión y la carga la apruebas tú, y cada cambio queda registrado con su porqué.

• Lee: movimientos de venta, inventario por ubicación, pedidos pendientes, plazos.
• Escribe, con permiso: la previsión de la demanda por ubicación. Nada más.
• No toca: contabilidad, precios, clientes, pedidos ya lanzados ni la configuración de la extensión de Microsoft.

Lo que no hace, y cómo se comprueba.

No promete acertar. Una previsión es una estimación con error, y la banda existe para decirlo. No sirve de mucho en productos nuevos sin parecidos en el catálogo, ni donde la demanda depende de hechos que no están en los datos, como una licitación o una promoción que nadie ha registrado: ahí hay que meter el dato a mano, y el sistema tiene un sitio para ello. Tampoco sustituye la revisión de Compras.

Se comprueba con tu pasado. El sistema vuelve a prever cada semana de los últimos meses usando solo lo que se sabía ese día y se mide el error contra lo vendido, producto por producto, frente a lo que habría dado la previsión que usas hoy. Si no mejora, el informe lo dice. Después vienen uno o dos meses en modo sombra y solo entonces, si convence, el permiso de escritura. Para empezar basta un export de movimientos de producto e inventario por ubicación: el análisis gratuito lo hace y devuelve un informe corto.

¿Te suena alguno de estos casos?

• Si usas la extensión de previsión y repartes el total a mano El total sale bien, pero cada delegación no vende una parte fija. El reparto por ubicación se aprende de las ventas de cada una, semana a semana.
• Si tienes la previsión de la demanda tecleada para el MPS Trescientos productos por doce meses son miles de celdas. El sistema la calcula y la deja lista para cargar, con el tipo de previsión que uses.
• Si la extensión no predice algunos productos Microsoft avisa de que, si Azure AI no encuentra suficientes datos o los datos varían mucho, no hace predicción. Los productos de venta salteada se calculan con métodos pensados para eso.
• Si vendes con temporada marcada Climatización, jardín, material escolar, bebidas. La temporada se aprende de todos los productos parecidos a la vez, para que un producto con poco historial no parta de cero.
• Si tienes un catálogo grande y variantes por todas partes La extensión no admite filtros y su capacidad indicada es de unos 50.000 productos en 12 horas. Aquí el cálculo corre fuera y no compite con los demás procesos de tu Business Central.
• Si tu partner no quiere más desarrollos dentro del programa El cálculo vive fuera. Lee por la API de Business Central y solo escribe lo que acuerdes, con una página de API propia, pequeña y revisable, si hace falta.

Business Central sigue siendo el sitio de la previsión. Cambia cómo se calcula.

No reemplazamos la extensión de Microsoft ni la página Previsión de la demanda. Calculamos fuera, por producto y ubicación, con un modelo que ve las roturas, la temporada y la venta salteada, y devolvemos el resultado donde Business Central ya lo consume. Antes de escribir nada se compara con tus meses pasados, con cifras, y se arranca en modo sombra. El código queda a tu nombre.

• Una previsión por producto y ubicación en lugar de un total que repartir.
• Una banda de riesgo en cada semana, no una cifra única.
• Las roturas del pasado no se cuentan como demanda cero.
• Se prueba con tus datos antes de tocar Business Central.