Una de las principales funciones que solemos desempeñar desde los departamentos financieros y de control de gestión es preservar el correcto tratamiento de los datos que se introducen en el ERP y detectar lo antes posible cualquier tipo de error que vaya a influir en el análisis de la información que llega a nuestros sistemas de reporting 🔎.
¡¡¡Quién no ha estado horas buscando el por qué de algún dato que le olía a chamusquina y al final ha acabado detectando que alguien había metido un gazapo en toda regla al introducir algún dato en el sistema!!!…😩
Recientemente me ha surgido la necesidad de controlar errores que se estaban cometiendo al crear nuevos clientes en el ERP.
Cuando un usuario da de alta al cliente, además del “Código cliente” debe informar también el “Código contable”. De acuerdo a nuestros procesos internos, esos códigos deberían ser iguales pero, en ocasiones, se informan con valores diferentes por error humano.
Ello implica que las facturas que se emitan al cliente 43009998 puedan ser contabilizadas en la cuenta contable 43009997, como pasaría si se rellenan los datos como en la siguiente imagen:
Incluso el problema podría ir más allá. Si el usuario comete el error al teclear los primeros dígitos e informar como código contable 13009998, el saldo de ese cliente irá representado en el balance en el subgrupo 130 dentro del patrimonio neto (subvenciones) en lugar de en el activo corriente (deudores comerciales).
Para tener controlados estor errores y corregirlos antes de que lleguen a provocar problemas mayores, realicé un informe en Power BI que me arrojaba el detalle de los casos en los que se cometía algún error.
El trabajo en PBI es realmente sencillo. Simplemente importo los campos «CodigoEmpresa», «CodigoCliente» y «CodigoContable» de la tabla de clientes de la BBDD del ERP (me traigo el campo código empresa porque hay varias empresas activas y necesito concatenar los códigos de empresa con los campos de código de cliente y código contable), y acabo generando 2 columnas “Cod.Cliente” y “Cod.Contable” (con el código de empresa como prefijo combinando las columnas, ya que el cliente 43000002 puede existir en N empresas diferentes).
Posteriormente agrego una columna personalizada que devuelve un Check True/False para la comprobación de si los códigos son coincidentes:
Y, por último, filtro los valores del campo “Check” por “FALSE”, quedando como único registro el caso que exponíamos como ejemplo:
Tras esto, cerramos y aplicamos en Power Query y pasamos a Power BI, donde construimos como visuales simplemente una tabla con los campos Cod.Cliente y Cod.Contable, y una tarjeta con la medida del número de casos a revisar, que será un conteo de las filas de nuestra tabla elaborada en Power Query:
Publicamos en el servicio de Power BI este modelo semántico + informe y le programamos una actualización diaria, en mi caso a las 01:00 a.m., a través del gateway previamente instalado.
Con ello conseguimos que todas las noches se actualice de forma automática y compruebe en la BBDD posibles errores que hayan cometido los usuarios a la hora de crear nuevos clientes (o modificaciones incorrectas de clientes que ya estuviesen creados previamente).
Mi primera idea para controlar este proceso fue crear una alerta en el servicio de Power BI anclando el visual de tarjeta que indica el nº de casos a revisar en un panel y configurando una alerta que me avise cuando esa medida sea mayor a cero.
Realizando pruebas, detecté que en la primera actualización la alerta me llegó correctamente:
Entré con el enlace al informe y……bingo: allí estaba el detalle del cliente con el error cometido.
El problema que encontré al sistema de alertas es que seguí haciendo pruebas y me topé con un funcionamiento que no me permitía seguir haciendo el control por esta vía.
La limitación es que el aviso de las alertas te llega únicamente si cambian los datos del visual, como se resalta en la siguiente imagen:
Por lo tanto, en nuestro ejemplo, solo llegará nueva alerta en la siguiente actualización si la medida está por encima de cero (el umbral que he marcado en la alerta) y no es 1 (ya que es el valor que tenía en la última actualización).
Realicé pruebas y, en efecto, puede haber un caso como el que expongo a continuación en el que las alertas del servicio de Power BI no nos avisen del error:
• El lunes un usuario crea un cliente con error.
• La noche del lunes al martes nos salta la alerta en el servicio de Power BI con el valor de 1 en la medida.
• El martes a primera hora, al ver la alerta, corregimos en el ERP el error (con lo que en ese momento volvemos a tener cero errores en la BBDD del ERP).
• El mismo martes, otro usuario comete un nuevo error al crear otro cliente.
• En la actualización de la noche del martes al miércoles, la medida vuelve a tener valor de 1 pero, en esta ocasión, no nos salta alerta porque los datos en el servicio no han cambiado entre ambas actualizaciones (tanto el lunes por la noche como el martes por la noche había 1 error en la BBDD).
Al no haber usado demasiado el sistema de alertas no estaba seguro de si había alguna opción de configurarlo de otro modo, pero pregunté en el grupo de Telegram de Power BI Español y el gran Ricardo Rincón salió a mi rescate indicándome que el comportamiento de las alertas era el que yo había experimentado, y que al no haber cambio no recibía una nueva alerta.
Por ello, tal como me comentaba también Ricardo, tuve que pasar al plan B que tenía previsto: utilizar Power Automate y la DAX Query del visual de PBI para que me llegasen avisos con las actualizaciones siempre que el valor de la medida sea mayor que 0 (independientemente del valor que tuviese anteriormente).
Para ello, seguí un proceso muy similar al explicado por Sara Alonso en sus artículos con el paso a paso del flujo de Automate que usamos en nuestra ponencia de los PBI Days Bilbao el pasado mes de Junio “Estrategias avanzadas de inventario y compras con Power BI y Power Automate”. (os dejo los enlaces por si queréis ver más en detalle alguno de los pasos que yo resumiré):
La DAX Query de mi visual de tarjeta es la siguiente (obtenida tal y como explica Sara en sus artículos):
Voy a Power Automate y me creo un nuevo flujo de nube programado:
Lo configuro a las 03:00 a.m. porque al actualizarse el informe de PBI a las 01:00 y no haber actividad nocturna en la empresa, me llegará notificación siempre que la medida sea superior a cero, independientemente del valor que tuviese en la anterior actualización.
A continuación, añadimos un nuevo paso y elegimos la opción de ejecutar una consulta de PBI contra un conjunto de datos. Seleccionamos el Workspace, el Dataset y pegamos la DAX Query que lanza el objeto visual:
El siguiente paso de nuestro flujo va a ser seleccionar el contenido dinámico del query DAX con el paso de “Seleccionar” operación de datos y la opción de primeras filas:
A continuación, inserto un paso de Compose (Redactar operación de datos) y en la expresión indico lo siguiente (debo reconocer que me echó una mano chat-gpt porque mis conocimientos de Automate son bastante básicos… 😅):
first(body(‘Select’))[‘#Casos’][0][‘[v__Casos_a_revisar]’]
Siendo “Select” el nombre del paso anterior:
Este paso me devuelve el valor de la tarjeta de Power BI con el número de casos de clientes a revisar por tener el código contable distinto al código de cliente.
Ya solo me queda capturar ese valor y meterle una condición para que, si es mayor que cero, me envíe un email para avisarme de que debo revisar mi informe y ver los clientes en los que se ha cometido algún error:
Os muestro un ejemplo de email recibido puntualmente a las 03:00 🕒:
De esta forma, conseguimos pasar de un sistema de control en el que nosotros tengamos que perseguir los errores a un sistema en el que nuestros flujos de trabajo (nuestros detectives nocturnos como yo les llamo… 🕵🏻♂️🤖🌙) nos notifican cuando detectan cualquier error.
Al email que nos llega también podríamos añadirle una tabla html con los valores de los clientes a revisar, a través del Query DAX de la visualización de tabla de nuestro informe de Power BI, pero no he querido extender demasiado la construcción del flujo.
Otros casos de uso para estas notificaciones que combinan Power BI y Automate podrían ser:
- Clientes que sobrepasen X € de riesgo.
- Asientos contables que estén descuadrados.
- Albaranes de venta que se facturan con una fecha de factura anterior a la fecha del albarán.
- Cambios de tarifa en artículos que sobrepasen X % de variación respecto al precio anterior.
Quizás algún día me anime a presentar alguna sesión en algún evento sobre este tipo de chequeos “robotizados” 🤔
Espero que te haya parecido útil y puedas utilizarlo para casos similares que encuentres en tu día a día.
Seguimos!!! 👊