⚖️​Es decir, que se cumpla el principio de partida doble (si nos ponemos técnicos), o “las gallinas que entran por las que salen” si hablamos en lenguaje coloquial 😉

Los programas de contabilidad o ERPs suelen tener avisos que nos protegen ante errores al introducir asientos descuadrados.

En la siguiente imagen, muestro un mensaje que proporciona SAGE 200 Advanced cuando pretendo introducir un asiento descuadrado:          

NOTA: Los pasos e imágenes que veremos en el post están basados en SAGE 200 Advanced.

No obstante, si el usuario pulsa sobre el botón “Sí”, el asiento se graba en la base de datos tan tranquilamente…🤔

Incluso hay muchos asientos que no les introduce ningún usuario manualmente, sino que se generan automáticamente desde algún proceso que tengamos configurado bien desde la versión estándar del programa, o alguna personalización que hayamos implementado (contabilización automática de facturas de venta/compra, control de riesgos por descuento de efectos, recepción de albaranes de compra…)

En esos casos también corremos el riesgo de que algún asiento automático entre al programa con algún descuadre por alguna incidencia que se haya saltado los controles…

Los programas suelen incluir también una opción para sacar un listado con los asientos descuadrados que se han introducido en el sistema.

En SAGE 200 Advanced la pantalla sería la siguiente (si tenemos la contabilidad de varias empresas en la interfaz de SAGE debemos ir cambiando de empresa para ir consultando la pantalla empresa por empresa, mientras que en Power BI podremos consultar todas las empresas al mismo tiempo):

Vemos que en el asiento 15.314, del 15/04/2025, hay un descuadre de 201,25 €, ya que hay más gallinas que han entrado por el Debe de las que han salido por el Haber 😉.

Podemos comprobarlo entrando al asiento:

En el post de hoy vamos a ver cómo generar un proceso que nos compruebe periódicamente si hay algún asiento descuadrado y, en caso afirmativo, nos envíe un email avisándonos de la incidencia para poder corregirla.

Lo primero que vamos a hacer es entrar en Power BI y, a través del conector de SQL Server de Power Query, conectarnos a la base de datos del ERP, concretamente a la tabla “Movimientos”, que es donde se almacena la información de los apuntes contables:

Nos quedamos únicamente con las siguientes columnas:

Me voy a quedar a continuación únicamente con los asientos que sean del ejercicio actual o del anterior (de forma dinámica), porque entendemos que los periodos anteriores ya deberían estar cerrados y con la contabilidad revisada y bloqueada.  Lo hacemos mediante el siguiente código M:

A partir de las columnas “CodigoEmpresa”, “Ejercicio” y “Asiento” (las selecciono en ese mismo orden con el “Control” pulsado) nos construimos el identificador único del asiento; ya que el campo “Asiento” se puede repetir para distintos ejercicios y códigos de empresa (resalto en amarillo en la imagen anterior que tenemos asientos de distintas empresas).

Lo hacemos a través de la opción “Transformar” => “Combinar columnas” y usamos el separador que queramos (yo suelo usar un guión bajo) y el nombre de la nueva columna (en mi caso “idAsiento”):

Quedaría así la información:

Como vemos, SAGE nos da el importe del apunte en la columna “ImporteAsiento” y en la columna “CargoAbono” nos indica si ese importe va al Debe o al Haber.

En el caso de otros ERPs nos aparecen los importes directamente separados en columnas de Debe y Haber.

Vamos a hacer esa separación a través de agregar nuevas columnas condicionales que nos den los importes de debe y haber por separado.

Muestro a continuación cómo sería la creación de la columna “Debe” y seguiríamos el mismo patrón para crear la del “Haber”:

Con esos pasos ya tendría creadas las nuevas columnas:

Ahora simplemente voy a darle formato Número Decimal Fijo a estas nuevas 2 columnas y voy a eliminar las columnas “ImporteAsiento” y “CargoAbono”, ya que ya no las voy a necesitar.

Llegaríamos a la siguiente situación:

Lo siguiente que voy a hacer es agrupar los datos por el campo “idAsiento” para obtener el total de importe al Debe y total importe al Haber de cada uno de los asientos, ya que mi único objetivo es saber si están descuadrados (los datos vienen a granularidad de apunte contable y cada asiento contable puede tener N apuntes):

Ahora voy a hacer una nueva columna calculada a la que voy a llamar “Saldo” y que calcularé como la resta de las columnas “Total_Debe” y “Total_Haber”. Tendré que seleccionar las 2 columnas con el Control en el orden indicado (primero Total_Debe y luego Total_Haber), y posteriormente seguir los pasos de la siguiente pantalla:

En la siguiente pantalla vemos los resultados de la nueva columna. Resalto en amarillo algunos valores que debería ser cero pero cuyo resultado no es exactamente cero. Como se aprecia en el valor marcado en azul, del origen nos vienen valores que no están correctamente redondeados, lo cual es el motivo de esos valores resaltados en amarillo:

Vamos a modificar el nombre de la columna “Resta” por el de “Saldo” y modificamos el tipo de dato a la columna para ponerlo como “Numero decimal fijo” para resolver ese problema de los redondeos. Vemos en la siguiente pantalla que los mismos registros que en la pantalla anterior no aparecían con valor cero ahora sí que lo hacen gracias al cambio de tipo de dato:

Si filtramos los valores de la columna “Saldo” por los que sean distintos a cero, veremos cómo pasamos a tener un único registro en la tabla, que es precisamente el que nos marcaba la interfaz del ERP, el asiento nº 15314 del ejercicio 2025 de la empresa 1:

Por último, eliminaría las columnas Total_Debe y Total_Haber, dado que ya no las necesito, y pulso sobre cerrar y aplicar para llevarme los datos desde Power Query a Power BI.

Vemos a continuación los datos desde la vista de tabla de Power BI Desktop:

Tras esto, haremos una sencilla medida DAX que lo que hará será contar el número de filas de nuestra tabla y que nos dará como el resultado el número de asientos que tenemos descuadrados en nuestra contabilidad. Vemos a continuación el resultado sobre un visual de tarjeta:

Ahora lo que vamos a hacer es obtener la consulta DAX que genera el objeto visual para después poder pasársela a Power Automate.

Para ello, vamos el menú “Ver” => “Analizador de rendimiento”. Pulsamos sobre “Actualizar objetos visuales” y copiamos la consulta con el botón “Copiar consulta”:

El texto que se nos copia en el portapapeles es el siguiente:

// DAX Query

EVALUATE

               ROW(

               «v__Asientos_Descuadrados», ‘Movimientos'[# Asientos Descuadrados]

)

Ahora lo que vamos a hacer es publicar nuestro informe en el servicio de Power BI desde el botón “Publicar”, y seleccionar el área de trabajo donde queramos publicarlo.

Una vez publicado, configuraremos la sincronización con la puerta de enlace al servidor donde esté la base de datos del ERP; y estableceremos las actualizaciones programadas que consideremos (en nuestro caso una actualización diaria a las 01:00 a.m.).

A continuación, nos vamos a Power Automate y creamos un flujo de nube programado que se ejecute todos los días a las 02:00 a.m. (como hemos indicado en el servicio de Power BI que el informe se actualice a las 01:00 a.m., a las 02:00 a.m. ya nos aseguremos que el informe esté actualizado y que podamos “pillar” a los nuevos asientos descuadrados):

A continuación, añadimos una nueva acción al flujo y elegimos la acción de ejecutar una consulta contra un conjunto de datos de Power BI.

Debemos seleccionar el área de trabajo y el modelo semántico y, posteriormente, pegar en el “Texto de la consulta” la consulta DAX que copiamos en el portapapeles cuando seguimos los pasos de ver el analizador de rendimiento de Power BI Desktop:

Tras ello, añadimos una nueva acción y elegimos la acción “Seleccionar”. 

En el apartado “Desde” pulsamos sobre el icono de un rayo que nos permite obtener datos del paso anterior:

Elegimos la opción “Primeras filas de la tabla”:

Dejamos configurados los campos de la opción “Mapa” de la siguiente forma:

A continuación, añadimos un nuevo paso con la acción “Redactar” e introducimos la siguiente expresión desde el botón con las iniciales “fx”:

first(first(body(‘Seleccionar’))[‘#Asientos’])[‘[v__Asientos_Descuadrados]’]

‘Seleccionar’ hace referencia al nombre del paso anterior del flujo de Power Automate.

‘#Asientos’ es el nombre que hemos dado al parámetro en la sección “Mapa” de la imagen del paso anterior.

‘[v__Asientos_Descuadrados]’ nos viene establecido desde la consulta DAX del objeto visual de tarjeta.

Este último paso ya nos devuelve como Output el valor de la tarjeta, en nuestro caso, la salida es el valor “1”. Lo podemos comprobar si ejecutamos el flujo manualmente y comprobamos los resultados:

A continuación, añadimos un nuevo paso de condición con el objetivo de que si el valor de salida del paso anterior (que es el valor de la tarjeta de Power BI) es mayor que cero, nos envíe un email de alerta para que sepamos que hay algún asiento descuadrado:

Posteriormente, indicamos en si se cumple la condición, envíe un email al destinatario que indiquemos y en el cuerpo del email añadimos el nº de asientos descuadrados a través de la salida del paso “Redactar”:

Ya lo tendríamos todo preparado….

Falta ver que todo funcione y a continuación os muestro la prueba de que puntualmente a las 02:00, tenía un email en mi buzón de entrada:

Podríamos adaptar el proceso si queremos incluir en el aviso las cuentas contables que intervienen en los apuntes de cada asiento, o incluso los conceptos, y enviar por email una tabla que represente el asiento tal y como lo vemos en el ERP.

Por simplificarlo lo hemos dejado en una notificación que nos indique que hay algún asiento descuadrado y ya con ese aviso iremos nosotros a ver la pantalla de descuadres al ERP y modificaremos los errores que detectemos.

También podemos incorporar a Power BI una sencilla tabla con los asientos de Power BI y comprobarlos desde nuestro informe en Power BI:

Sencillo y realmente útil, ¿no crees?.

La verdad es que esta combinación de Power Automate y Power BI es realmente potente y es uno de los desafíos en los que quiero centrarme en el corto plazo.

Veremos a dónde nos lleva y, como siempre, os iré compartiendo nuevos retos y funcionalidades.

Seguimos!!! 👊

La entrada Automatizando el control de asientos descuadrados se publicó primero en reportingfinanciero.es.

¡¡¡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é):

https://medium.com/@salonsobernardo/automatiza-pedidos-de-compra-a-proveedores-con-power-bi-power-automate-parte-i-745e1c773d5f

https://medium.com/@salonsobernardo/automatiza-pedidos-de-compra-a-proveedores-con-power-bi-power-automate-parte-ii-554350b3381c

https://medium.com/@salonsobernardo/automatiza-pedidos-de-compra-a-proveedores-con-power-bi-power-automate-parte-iii-2b358a57b247

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!!!  👊​

La entrada Automatizar procesos de control con PBI y Automate se publicó primero en reportingfinanciero.es.