Alertas de stock en Power BI: avisan de una cifra, no de cada producto.

Qué hace en alertas de stock en power bi.

¿Qué son las alertas de datos de Power BI?

Son avisos que el servicio de Power BI envía cuando un número de un mosaico de un panel supera o baja de un umbral que has puesto. Se configuran desde el mosaico, en Gestionar alertas, con un título, una condición y una frecuencia. Cuando los datos se actualizan y la cifra cruza el umbral, Power BI deja un mensaje en el centro de notificaciones y, si lo has marcado, manda un correo con un enlace al mosaico.

Es una herramienta sencilla y útil para lo que es: una cifra de cabecera que quieres vigilar sin abrir el informe cada día. Para un cuadro de stock sirve para avisos como el número de productos a cero o el valor del stock parado. Lo que no sabe es cuáles son esos productos.

¿Qué dice la documentación sobre sus límites?

La documentación de Microsoft es clara. Las alertas se ponen en mosaicos fijados desde visuales de informe, y solo en medidores, KPI y tarjetas. Funcionan con datos numéricos y no se admiten en tarjetas con fechas u horas. Solo avisan con datos actualizados, no con datos estáticos, y no repiten el aviso si el valor no cambia. Cada alerta puede enviarse como mucho una vez por hora o una vez cada 24 horas, según la opción elegida.

Hay límites que pesan en una empresa. Puedes crear hasta 250 alertas en todos tus modelos. Solo tú ves las que creas, aunque compartas el panel. No se pueden poner en Power BI Desktop. Y no admiten copropiedad: si la persona que las creó se va, quien llega tiene que crearlas de nuevo, y recrear también el flujo de Power Automate, si lo hay. Para informes, y no solo paneles, Microsoft remite a las alertas de Fabric Activator.

Un ejemplo con números: el umbral de 7 días llega tarde.

Un distribuidor de conservas sirve a 40 supermercados. Para las latas de tomate frito, el proveedor tarda 12 días en servir desde que se hace el pedido, y los pedidos se hacen una vez por semana. Alguien pone una alerta en una tarjeta: avisar cuando la cobertura media baje de 7 días. Parece prudente.

Un supermercado tiene 15 días de cobertura. Como el pedido tarda 12 días y no se revisa hasta dentro de una semana, el siguiente pedido llegaría 19 días después del hoy (7 hasta la revisión más 12 de plazo). 15 es menos que 19: ya hay riesgo, y esa tienda se quedará sin latas unos 4 días. La alerta de 7 días no salta hasta que le queden 7, momento en el que, aunque se pida de inmediato, el pedido llega 12 días después. Son 5 días sin producto que el aviso no podía evitar.

El aviso útil es el que dice, con 15 días de cobertura, que este producto en este supermercado se va a quedar sin existencias antes de que llegue el siguiente pedido, y que conviene pedir hoy tantas unidades. Eso solo se puede decir si se conocen el plazo del proveedor, la frecuencia de pedidos y la previsión de ventas de ese producto en ese sitio.

¿Cómo avisa el sistema antes de la rotura?

El sistema calcula, producto a producto y sitio a sitio, la probabilidad de llegar a cero antes de que pueda llegar el siguiente pedido. Usa la previsión de ventas con su abanico, el stock de hoy, lo que está en camino y el plazo real de cada proveedor, sacado de las fechas de pedido y de recepción. Cuando esa probabilidad supera el nivel que fijas (un 5 % en temporada baja, un 2 % en campaña, por ejemplo), el producto entra en la lista de avisos.

La lista se ordena por lo que se pierde si no se actúa. Cada línea dice el producto, el sitio, los días de margen, la cantidad propuesta y el porqué en una frase. Quien la recibe no tiene que abrir ningún informe para entender qué hacer. El aviso llega por correo a quien compra y, si es urgente, por WhatsApp. Lo que no es urgente va a la lista del lunes.

Power BI no hace pedidos ni predice roturas: el sistema calcula, Power BI enseña y la persona aprueba. El pedido se hace en tu ERP.

¿Cómo se usa Power Automate con las alertas?

Microsoft documenta cómo enlazar una alerta de datos con un flujo de Power Automate. Hay una plantilla que envía un correo a cualquier destinatario cuando salta una alerta, y se puede crear un flujo desde cero con el desencadenador de Power BI cuando se activa una alerta controlada por datos, y un paso posterior, como crear un evento en Outlook. El flujo recibe datos del aviso, como el valor del mosaico y su dirección.

Es una buena manera de llevar el aviso de una cifra a quien tiene que verlo: Compras, un responsable de zona o un buzón común. Tiene el mismo límite que la alerta de la que parte: informa de un número, no de la lista de productos. Por eso lo usamos para la cifra de cabecera y dejamos que el aviso por producto lo mande el sistema directamente.

Hay un detalle práctico que Microsoft señala: las alertas no admiten copropiedad, y si se traspasa la propiedad hay que recrear la alerta y el flujo. Para algo que debe durar años, conviene que no dependa de la cuenta de una persona.

¿Y los avisos por WhatsApp?

Para el aviso urgente, quien repone no está delante de un informe. Está en el almacén, en la furgoneta o en una tienda. El aviso por WhatsApp llega al móvil de la persona adecuada con el producto, el sitio y la cantidad, y unos botones para contestar: visto, preparado, ha salido. Lo montamos con Bedel (bedel.es), nuestro socio, que ya resuelve incidencias por WhatsApp en residencias de estudiantes y en otros muchos sectores.

Es un añadido y no un requisito. Los avisos por correo y la página de avisos del informe funcionan sin él. En la página de WhatsApp del hub se explica cómo funciona con más detalle. Lo que importa aquí es que el aviso sale del mismo cálculo y de la misma lista que ves en Power BI, no de una segunda fuente de verdad.

¿Cómo se ve el resultado en Power BI?

Una página del informe, que llamamos avisos, con la lista de la semana: qué productos y sitios se avisaron, a quién, cuándo, qué se decidió y si la rotura llegó a producirse. Se filtra por zona, proveedor y familia, y con los mismos permisos que el resto del informe. Cada responsable ve los suyos.

Sirve para comprobar si el sistema acierta. Si se avisa de muchas roturas que no ocurren, el nivel está demasiado alto y hay ruido. Si hay roturas sin aviso previo, el nivel está bajo o falta algún dato, como un plazo mal registrado. Con esa página se ajusta con datos y no con impresiones, y Dirección puede ver cuántas roturas se han evitado.

La página se actualiza con tu actualización programada. Según Microsoft, son hasta ocho al día en capacidad compartida y hasta 48 en Premium, PPU o Fabric. Los avisos se calculan una vez por semana, o cada dos días en campaña, y no dependen de ese ritmo, porque los manda el sistema cuando los calcula.

¿Qué datos hacen falta y qué no hace?

Las ventas por producto, sitio y fecha, el stock actual, los pedidos pendientes y, si se puede, las fechas reales de pedido y de recepción para sacar el plazo de cada proveedor. Y una lista de quién recibe qué: por zona, por proveedor o por familia. Todo ello sale del ERP o de los Excel que ya usa tu Power BI, con un usuario de solo lectura.

No hace pedidos por sí solo, no escribe en tu ERP sin aprobación y no promete cuántas roturas va a evitar antes de ver tus datos. No sustituye a las alertas de Power BI para vigilar una cifra de cabecera: conviven. Y no arregla datos de origen mal llevados: si el stock del ERP no cuadra con el almacén, el aviso heredará el error, y el primer paso es corregirlo.

¿Cómo se comprueba y cómo se empieza?

Antes de activar ningún aviso se repiten fechas pasadas con lo que se sabía cada día. Se cuenta cuántos avisos habría habido por semana, cuántas roturas se habrían anticipado y cuántas habrían sido falsas alarmas. Con eso se elige el nivel. Después, uno o dos meses en modo sombra: los avisos llegan a quien compra, pero se sigue comprando como siempre, para comparar sin riesgo.

El arranque son entre tres y seis semanas. Se piden unos datos de solo lectura, se publica la tabla de avisos, se añade la página al informe y el código queda a tu nombre. Para ver si tu caso compensa, hay una demo de 30 minutos por videollamada o el análisis gratuito de tu stock.

¿Te suena alguno de estos casos?

• Si recibes cada día una alerta de Power BI de stock bajo y ya no la lees Una cifra que cruza un umbral no distingue lo urgente de lo que puede esperar. El aviso por riesgo ordena por lo que se pierde si no se actúa.
• Si los proveedores tardan semanas y el umbral fijo salta cuando ya es tarde. El aviso depende del plazo de cada proveedor, no de un número igual para todos.
• Si tienes un responsable por zona y cada uno debería recibir solo lo suyo. Los avisos se reparten con los mismos permisos que usas en el informe.
• Si reponéis con furgonetas o rutas fijas y hay que saber el miércoles lo que falta el viernes. Los avisos se calculan con antelación suficiente para llegar a la ruta.
• Si Dirección quiere saber si los avisos sirven La página de avisos del informe enseña cuántos hubo, cuántos se atendieron y cuántas roturas se evitaron o se produjeron igualmente.

Avisar de una cifra es fácil. Avisar de qué producto, dónde y por qué es lo que cuesta.

La alerta de Power BI hace bien lo suyo: vigilar un número y avisar. El sistema hace otra cosa: calcula el riesgo de cada producto en cada sitio y manda la lista. Power BI no hace pedidos ni predice roturas; el sistema calcula, Power BI enseña, la persona decide y el pedido se hace en tu ERP. Los avisos se comprueban con tu histórico antes de activarlos.

• Aviso por riesgo de rotura, con el plazo real de cada proveedor, no por umbral fijo.
• Lista de productos y sitios con el porqué, por correo, Power Automate o WhatsApp.
• Cada persona recibe lo suyo, con los permisos de tu informe.
• Página de avisos en el informe: qué se avisó y qué pasó después.