Reto:

El objetivo era construir un cuadro de mando financiero para un cliente, para lo que tenía que capturar de la base de datos SQL Server de su ERP los datos de los movimientos del libro diario.

El cliente quería ver los datos de los últimos 5 años y en la base de datos se generaba una tabla distinta para cada empresa y ejercicio.

Al ser un modelo financiero multiempresa (había que mostrar la información de las 3 empresas del grupo), había que conectarse a 15 tablas distintas para conseguir toda la información contable necesaria (3 empresas * 5 ejercicios).

La nomenclatura de las tablas seguía el siguiente patrón:  DATDIXXYY , donde XX refleja el código de la empresa (podía tener los valores 21, 22 o 24) e YY refleja los 2 últimos dígitos del ejercicio (22 para 2022, 23 para 2023 …).

Por tanto, y a modo de ejemplo, DATDI2122 sería la tabla que recoge los apuntes contables de la empresa 21 del ejercicio 2022.

Mi primer acercamiento fue hacer una consulta distinta para cada empresa y ejercicio (15 consultas distintas) y después anexarlas en Power Query.

Conseguía tener toda la información pero tenía un principal problema a resolver:

Cada cambio de ejercicio tenía que modificar el origen de las consultas. Por ejemplo, con la entrada del año 2026, tenía que añadir las tablas DATDIXX26 y eliminar las tablas DATDIXX21 (quiero tener únicamente 5 ejercicios).

Voy a explicar a continuación cómo poder hacer esa búsqueda de las tablas a cargar al modelo de forma dinámica y, además, anexar las 15 tablas dentro del mismo script de Power Query para evitarnos tener que hacer 15 consultas separadas y después anexarlas.

Solución:

A efectos de poder simplificar la explicación lo máximo posible, voy a indicar la solución paso a paso apoyándome de un fichero Excel en el que tengo creadas 15 tablas que simulan cada una de las tablas a las que nos conectaríamos a SQL.

NOTA: Te dejaré enlace de descarga al final del post con el fichero Excel donde están las tablas, un txt con el script del código M empleado, y el fichero pbix con el reto resuelto. Con una pequeña modificación del paso de Origen que te explicaré más adelante obtendrás el mismo resultado cuando cambies el origen a tablas de una BBDD de SQL Server.

Muestro en la siguiente imagen la primera de las tablas, la de la empresa 21 del ejercicio 2022, es decir, DATDI2122:

Vemos como en el nombre de la tabla hemos indicado “DATDI2122” y, para hacer la comprobación en la carga de los datos, tanto en el importe del Debe (celda B2) como en el concepto (celda D2) he hecho referencia al nombre de la tabla (2122).

NOTA: He incluido en cada tabla un único apunte contable y unas pocas columnas para visualizar mejor la información una vez que anexemos todas las tablas. En el SQL real tendremos obviamente todos los apuntes contables de la empresa y ejercicio seleccionado, además de todas las columnas que se almacenen en la base de datos.

Explicado esto, vamos a ir a Power Query para ver cómo realizamos la conexión a la información:

Pinchamos en Nuevo Origen → Libro de Excel ; y seleccionamos en nuestro equipo el fichero donde tenemos la información.

Una vez cargado nos aparecen en el navegador todas las posibles conexiones (todas las tablas y hojas).

Como se muestra en la siguiente imagen, en lugar de hacer check en las distintas tablas, hacemos click derecho sobre la parte que tiene el icono de carpeta y el nombre del fichero Excel, y pulsamos sobre “Transformar datos”:

Nos aparecen entonces todas las posibles conexiones pero dentro de una consulta de Power Query:

Si vamos al editor avanzado de Power Query, veremos que tenemos únicamente el paso de Origen:

Vamos a pegar ahora en el editor avanzado el script que te dejo en el material de descarga y después lo vamos a explicar paso a paso.

NOTA: Debes adaptar en el paso de origen del script la ruta de tu equipo donde guardes el fichero y el nombre que le des al fichero.

Quedaría el editor avanzado como muestro en la siguiente imagen:

Y si pinchamos en “Listo”, veremos cómo obtenemos el resultado deseado: traernos en una única consulta la información de los apuntes contables de las 3 empresas de los 5 años (vemos en la columna “Debe” como los importes hacen referencia a los códigos de empresa y ejercicios requeridos (XXYY que indicábamos anteriormente):

Explicación del código M:

Una vez conseguido el reto, vamos ahora a explicar cada uno de los pasos aplicados en Power Query:

Paso 1.- Origen:

Ya explicado anteriormente. En la segunda imagen del post vemos en detalle cómo llegar, y el resultado sería el de la tercera imagen.

Paso 2.- ListaEmpresas:

Creamos una lista con las empresas que queremos incorporar a nuestro modelo multiempresa (en nuestro caso las empresas 21, 22 y 24):

Paso 3.- Anio:

Nos quedamos con los 2 últimos dígitos del año actual (dinámico con el DateTime.LocalNow), que será el último que queremos incorporar a nuestro modelo. Serían las YY del nombre de las tablas a importar:

Paso 4.- ListaAnios:

Creamos una lista que va hasta el año calculado en el paso anterior (que sería el último ejercicio) y empieza 4 años antes (para traernos los últimos 5 ejercicios requeridos); y los pasamos a formato texto:

Paso 5.- FiltrarTablas:

El código completo de este paso no se ve en la siguiente imagen y es por lo que lo pego en texto a continuación:

Lo que hacemos es seleccionar los registros que nos quedamos del primer paso (Origen), filtrando porque el nombre de la columna “Item” empiece por “DATDI” y cualquiera de los códigos de empresa de la ListaEmpresas del paso 2 (es decir, DATDI21, DATDI22 o DATDI24).

Además, el nombre de la columna “Item” debe acabar por cualquiera de los ejercicios indicados en la lista “ListaAnios” del paso 4 (22 a 26, es decir, de los ejercicios 2022 al 2026).

De forma adicional, la columna “Kind” del paso de Origen tiene que ser del tipo “Table”.

Obtenemos como resultado lo siguiente:

Paso 6.- TablasConEmpresa:

Detallamos nuevamente el código M de este paso:

Lo que hacemos es añadir una nueva columna a los datos que vienen en la columna “Data”.  Al ser un modelo multiempresa, necesitamos añadir a los datos que nos vienen en los apuntes el código de la empresa (en mi caso esta información no venía del origen, si en tu caso ya te viene el código de la empresa en las tablas de los apuntes contables te ahorrarías este paso)..

La consulta que estamos construyendo será nuestra tabla de hechos de los movimientos contables, y esta columna del código de empresa será la que relacionaremos con la dimensión empresas para poder filtrar de qué empresa/s queremos mostrar la información.

El código de la empresa lo cogemos de la columna “Item”, con Text.Middle, empezando por la posición 5 y cogiendo 2 caracteres.  Por ejemplo, en DATDI2122 nos quedamos con 21.

Además, le damos formato número entero.

Toda la información que venía en las tablas originales, más la nueva columna con el código de la empresa, quedan en la nueva columna “DataConEmpresa”:

Paso 7.- ListaTablas:

Creamos una lista con las tablas de la columna “DataConEmpresa” (posteriormente combinaremos las tablas incluidas en esta lista):

Paso 8.- TablasReducidas:

Nos quedamos únicamente con las columnas que queramos llevar a nuestra consulta definitiva.

Al conectarnos al ERP, nos pueden llegar multitud de columnas y en este paso elegiríamos las columnas que necesitemos:

Paso 9.- CombinarTodo:

Combinamos todas las tablas de la lista anterior y obtendríamos las columnas que hayamos seleccionado para todos los apuntes contables de las 15 tablas que hemos indicado.

En nuestro caso nos salen solo 15 registros porque en el Excel había únicamente 1 apunte por cada tabla, pero cuando llevemos este código a producción nos aparecerán todos los apuntes contables de las 3 empresas de los últimos 5 años, en una única consulta:

En un último paso daríamos a cada columna su tipo de dato y ya tendríamos toda la información lista para incorporar a nuestro modelo.

Origen SQL:

Si queremos cambiar el código para que nos sirva para capturar los datos de una base de datos de SQL, únicamente tendremos que modificar el código del primer paso, el de Origen, indicando lo siguiente:

    Origen = Sql.Database(Servidor, BBDD),

Fin:

Y con eso ya lo tendríamos!!!

Espero que te haya resultado útil.

Este proyecto ha sido el primero en el que he usado esta técnica y la verdad es que me ha arreglado la papeleta… 

Agradecer al gran Ricardo Rincón que me ayudó a encontrar esta solución. Entre su gran soporte, un poco de ChatGPT y adaptando todo a los requisitos del proyecto, llegué a esta solución que funcionó de maravilla.

Seguramente haya otras formas de llegar al objetivo o de simplificar/optimizar esta solución, pero aquí tenéis una propuesta que podéis usar en vuestros futuros proyectos 😉

Te dejo por aquí el material para que puedas replicar el paso a paso y adaptarlo a tus propias necesidades (en el código M adapta la ruta de tu equipo en el primer paso de Origen):

La entrada Anexando datos cuando el ERP almacena la información de cada año en una tabla distinta. se publicó primero en reportingfinanciero.es.

¿En qué escenarios nos puede ser útil?.

Por ejemplo, si tenemos un grupo de empresas y queremos montar un informe de ventas para algunas de ellas. O si tenemos varios almacenes y queremos realizar un informe de rotaciones, ventas o compras para ciertos almacenes (y que podamos cambiar el filtro de manera dinámica en una sola consulta).

Tendremos en Power Query una lista con las empresas/almacenes objeto del análisis y, si modificamos esa lista, se modificarán los filtros que se aplicarán en nuestras consultas.

Veámoslo con un ejemplo.

Supongamos que estamos elaborando un informe de ventas para nuestro grupo empresarial.

En primer lugar, nos conectamos a la base de datos del ERP, concretamente a la tabla que contiene el maestro de empresas, y filtramos las empresas de las que queremos hacer el informe (en nuestro ejemplo, las empresas 1 y 4):

Posteriormente, para ya dejar preparada nuestra dimensión empresas en el modelo, nos quedamos únicamente con los campos CodigoEmpresa y Empresa (que contiene el nombre de la sociedad):

A continuación, vamos a hacer referencia a esta consulta dimEmpresas para generar una nueva consulta con la que vamos a generar la lista que nos va a servir para filtrar todos los datos del resto de consultas.

En la nueva consulta, nos vamos a quedar únicamente con la columna “CodigoEmpresa” y, desde el menú “Transformar” vamos a elegir la opción “Convertir en lista”:

Cambiamos el nombre de la consulta a “Lista empresas” y la consulta quedaría de la siguiente forma (vemos que el icono de la consulta ha cambiado de un icono de tabla a un icono de lista):

Ahora, para construir el modelo de ventas, vamos a imaginar que vamos a necesitar conectarnos, entre otras, a estas 6 tablas: CabeceraOfertaClientes, LineasOfertaClientes, CabeceraPedidoClientes, LineasPedidoClientes, CabeceraAlabaranClientes y LineasAlbaranClientes.

En cada una de las consultas, tendremos que filtrar los datos por el campo CodigoEmpresa, seleccionando únicamente las empresas 1 y 4.

Lo que vamos a conseguir con la técnica explicada en este post, es dejar vinculado ese filtro a nuestra consulta “Lista empresas”, de manera que si cambiamos el filtro de las empresas elegidas en la consulta “dimEmpresas”, como la consulta “Lista empresas” está referenciada a “dimEmpresas”, automáticamente cambien las empresas que se filtran en las 6 tablas relacionadas con las ventas.

Vamos a ver el ejemplo con la tabla “CabeceraOfertaCliente”.

Nos conectamos a la tabla y nos aparece su información:

Ahora, si como planteábamos anteriormente, nuestro informe queremos que incluya únicamente a las empresas 1 y 4, iríamos al campo “CodigoEmpresa” y filtraríamos por los valores 1 y 4 como mostramos en la siguiente imagen:

El código que nos genera este paso de filtrado es el siguiente:

= Table.SelectRows(dbo_CabeceraOfertaCliente, each ([CodigoEmpresa] = 1 or [CodigoEmpresa] = 4))

Lo que pasa es que el filtro se nos queda fijado de forma estática a las empresas 1 y 4.

Si quisiésemos más adelante cambiar las empresas filtradas, tendríamos que venir a este paso y modificarlo (en cada una de las consultas).

Lo que vamos a hacer, es que este filtro de los códigos de empresa dependa de la lista que hemos creado previamente, para que nos quede filtrado de forma dinámica por la lista creada: “Lista empresas”.

Para ello, tocaremos el código M de este paso de filas filtradas, y pondremos el siguiente código:

= Table.SelectRows(dbo_CabeceraOfertaCliente, each List.Contains(#”Lista empresas”, [CodigoEmpresa]))

Lo que estamos haciendo en el código, es indicar que el campo “CodigoEmpresa” se filtre por los valores que estén contenidos en la lista “Lista empresas”.

Si volvemos ahora al campo “CodigoEmpresa” y desplegamos la flecha del filtro, vemos que están únicamente disponibles las empresas de la lista, la 1 y la 4:

Esta técnica de filtrado la usaríamos con el resto de tablas a incorporar al modelo de ventas: LineasOfertaClientes, CabeceraPedidoClientes, LineasPedidoClientes, CabeceraAlabaranClientes y LineasAlbaranClientes….

De esta forma, modificando la selección de las empresas a incorporar en el informe únicamente en la consulta “dimEmpresas”, conseguiremos modificar los códigos de empresa que están incluidos en la lista “Lista empresas” y, con ello, las empresas que se filtran en el resto de consultas que dependen de esa lista.

Espero que te sirva para tus futuros proyectos!!!

Seguimos 👊​

La entrada Cómo filtrar datos a través de una lista en Power Query. se publicó primero en reportingfinanciero.es.

En el ejemplo que vamos a ver, tenemos creadas 2 comprobaciones sobre nuestros datos contables:

1️⃣ Un control que indique si hay algún asiento descuadrado.  En contabilidad es absolutamente esencial que se cumpla el principio de partida doble, es decir, que los importes que van al debe sean los mismos que los que van al haber.  Haremos por tanto un chequeo de que todos los asientos cumplan esta regla.

2️⃣ Que todas las cuentas contables a 4 dígitos que usamos en nuestros apuntes contables las tengamos correctamente clasificadas en nuestro maestro de cuentas. 

Como sabréis, el plan general contable (PGC) español, recoge únicamente determinadas cuentas a 4 dígitos.

Muestro a continuación una imagen de las cuentas registradas en el PGC para el subgrupo 10:

En mis modelos financieros, tengo clasificadas en mis dimensiones Balance y Cash Flow absolutamente todas las cuentas a 4 dígitos recogidas en el PGC (y en mi dimensión de Pérdidas y Ganancias únicamente las de los grupos 6 y 7 de gastos o ingresos).

Por ello, en el grupo 1, según la imagen anterior, tengo creados los siguientes registros de cuentas a 4 dígitos: 1000, 1010, 1020, 1030, 1034, 1040, 1044, 1080 y 1090.

No obstante, el PGC es una guía no estrictamente obligatoria, con lo que hay empresas que pueden usar cuentas a 4 dígitos que no estén reflejadas en el PGC.  En ese caso, tendré que asegurarme de recoger esas cuentas a 4 dígitos que está utilizando la empresa por fuera del PGC y buscar un sistema para que mis tablas dimensionales clasifiquen correctamente esas cuentas.

Por ello, hago un chequeo de que si se utiliza en un apunte contable una nueva cuenta a 4 dígitos que yo no tenga mapeada, me genere un registro en una tabla que llamo “CuentasSinClasificar” (esto lo hago en la fase de ETL con Power Query normalmente).

Contado esto, os voy a enseñar cómo quedaría una hoja de check list en la que controlo las cuentas a 4 dígitos sin clasificar y los asientos descuadrados:

Como se puede apreciar, actualmente no habría nada fuera de control…. 🕵🏻‍♂️​

En la tabla “Cuentas a 4D sin clasificar” únicamente tengo incluido el campo “Cuenta4D” que viene de la tabla que indiqué que trabajaba en Power Query para quedarme con cuentas a 4 dígitos utilizadas en los apuntes contables que no tenía clasificadas para representar en mis informes de PyG, balance y cash flow.

En la tabla “Asientos descuadrados” llevo el identificador de cada asiento y las medidas “Debe” (que suma los importes del debe de los apuntes), “Haber” (que suma los importes del haber de los apuntes) y “Saldo” (que realiza la diferencia entre las medidas “Debe” y “Haber”).

Por otro lado, os voy a enseñar una imagen de portada estándar, con unos KPIs y unos iconos en el margen izquierdo para navegar entre las distintas páginas del informe:

El primero de los iconos, es a través del cual navegaríamos a la anterior página de check list:

Lo que voy a explicar en este post, es cómo realizar una medida DAX con la que dar formato condicional al borde de esa imagen, de manera que si hay algo que resaltar en mi página de check list, me salga un borde rojo alrededor de ese icono a modo de alerta; y aparezca de esta forma:

Lo primero que vamos a hacer es construir una medida que me indique el número de cuentas sin clasificar a 4 dígitos.  Como habíamos dicho que teníamos construida una tabla en fase de ETL que ya me daba esos registros, simplemente será contar las filas de esa tabla:

#CuentasSinClasificar = COUNTROWS(CuentasSinClasificar)

A continuación, haremos una nueva medida DAX con la que obtener el número de asientos descuadrados. Esta nueva medida no es tan básica como la anterior, pero vamos a explicarla paso a paso para entenderla.

La medida sería la siguiente:

NOTA:  Si tenemos el dato del idAsiento únicamente en una dimensión degenerada de apuntes (en lugar de en la tabla de hechos del libro diario), tendremos que hacer el SUMMARIZE de esa tabla dimApuntes.

Y ahora vamos a explicarla (de adentro hacia afuera):

Lo que estamos haciendo es una tabla virtual que nos devuelve los valores únicos del campo idAsiento, con la función SUMMARIZE, y añadimos a esa tabla virtual el saldo de cada asiento con la función ADDCOLUMNS.

Con ello, obtenemos una tabla con las columnas idAsiento y Saldo.

Nos quedaría una tabla similar a esta:

A continuación, con la función FILTER, filtramos la tabla por los registros que tengan el saldo distinto de cero ,es decir, los asientos que estén descuadrados.

En el siguiente paso, con la función COUNTROWS, contamos el número de registros que han quedado en nuestra tabla virtual ya filtrada.

Por último, hacemos una modificación del contexto de evaluación con CALCULATE y la función ALL() para eliminar el efecto de los segmentadores de año, mes y empresa que tenemos en la parte superior de la hoja de Inicio (ver imagen anterior).

Este paso es necesario porque queremos que se nos resalte en rojo cuando haya cualquier registro fuera de lo normal, independientemente de los filtros aplicados. Es decir, si hay un asiento descuadrado que es del año 2022 pero yo tengo filtrado el año 2023, si no incluyo el CALCULATE(…….ALL()) no se me resaltará el borde del icono en rojo como un error ese asiento descuadrado; ya que identificaría que para el año filtrado 2023 todo está correcto.

En caso de que esté todo OK (todos los asientos cuadrados) esta medida debería devolver un resultado de cero.

Por último, vamos a hacer la medida DAX con la que vamos a dar el formato condicional al borde de nuestra imagen:

En caso de que haya algún caso problemático, nos devolverá el borde en rojo, y en caso contrario en blanco (como el fondo que tiene la imagen).

Ahora lo que nos toca es ir al formato de la imagen que tiene nuestro icono de check list y configurar el formato condicional del borde de la siguiente manera:

Al estar todos los datos comprobados en el check list correctos no notamos ninguna diferencia, pero vamos a ver  lo que pasa si fuerzo a que un asiento esté descuadrado…

Voy a modificar el asiento 50 de la empresa 1 del ejercicio 2022 (en el modelo se correspondería con el identificador de asiento 1_2022_50):

Y mirad el efecto que tiene sobre el icono del check list cuando actualizamos los datos:

Nuestro icono se ha resaltado con un borde rojo.

Y si pincho sobre el icono para realizar la navegación entre páginas y que vaya a la página de check list, encontramos el detalle de lo que está generando la alerta:

Nos aparece el asiento 1_2022_50 descuadrado, con lo que tendremos que corregirlo en el ERP (o en el origen que corresponda) para que los informes vuelvan a salir correctos.

Es una técnica que estoy incorporando en todos mis informes financieros y que los usuarios finales agradecen mucho para no tener que estar pendientes de entrar a la hoja de check list, ya que en la propia página de inicio ya tienen el chivato si hay algún error en los datos 😁​

Seguimos!!! 👊​

La entrada Cómo generar un icono de alerta en nuestra portada de un modelo financiero. se publicó primero en reportingfinanciero.es.

⚖️​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.

Vamos a tomar como base de nuestro ejemplo el cálculo de la rentabilidad económica, también conocida como ROA (Return On Assets).

Este ratio se enfoca en la eficiencia de la empresa en el uso de sus activos para generar ganancias, y se calcula como el cociente entre el beneficio antes de intereses e impuestos y los activos totales medios.

La fórmula DAX quedaría de la siguiente forma:

ROA = DIVIDE(

            [BAII],

            [AT Medio]

        )

Y ahora viene la pregunta: ¿cómo calculamos en Power BI el activo total medio?.

Si somos un agente externo a la empresa, únicamente tendremos disponible la información de las cuentas anuales publicadas en el registro mercantil, con lo que tendremos que conformarnos con calcular el AT Medio como la media entre el activo del cierre de ejercicio N y el del cierre del ejercicio N-1:

AT Medio = (AT + AT PY)/2

*AT PY => Activo Total previous year.

Sin embargo, si tenemos acceso a la contabilidad de la empresa, ya seamos parte de su equipo financiero o consultores externos, tenemos la opción de montar en Power BI un informe financiero conectado al libro diario.

En ese caso, podemos calcular el Total Activo a cada una de las fechas de nuestro modelo.

Por tanto, podríamos optar por sacar un saldo medio del activo a través de una tabla virtual con DAX, que nos refleje el saldo para cada una de las fechas de nuestro calendario:

AT Medio = AVERAGEX(

            ADDCOLUMNS(

                VALUES(dimCalendario[Fecha]),

                «@TA», [Total Activo]

            ),

            [@TA]

        )

En esta fórmula, la parte que va dentro del ADDCOLUMNS nos creará la tabla virtual con el saldo para cada fecha:

El AVERAGEX calculará la media sobre los valores de la columna de la tabla virtual que tiene los valores del total activo (@TA).

Con ello, obtendremos un dato mucho más representativo que si cogemos únicamente los 2 valores de los cierres de ejercicio N y N-1.

Opción 2: También podríamos optar por calcular la media de los valores del activo únicamente de los saldos de cada cierre mensual (y no de todos los días como en la propuesta anterior), ya que quizás solo queremos fiarnos de los datos de cierres mensuales revisados, una vez incluidas amortizaciones, regularización de existencias, asientos de nóminas, periodificaciones….

En ese caso, la fórmula debe crear una tabla virtual con los valores del total activo a cierre de cada uno de los meses:

AT Medio 2 = AVERAGEX(

            ADDCOLUMNS(

                VALUES(dimCalendario[Año-Mes]),

                «@TA», [Total Activo]

            ),

            [@TA]

        )

Obtendríamos la siguiente tabla virtual sobre la que calcular el AVERAGEX:

Una vez calculado el AT Medio con alguna de las 2 opciones anteriores, la fórmula del ROA quedaría de la siguiente forma:

ROA = DIVIDE(

            [BAII],

            [AT Medio]

        )

Debemos tener en cuenta que el ROA es calculado comúnmente al cierre de los ejercicios, con lo que el numerador de la función, el BAII, hace referencia al resultado del ejercicio completo.

Por ello, si ponemos nuestros cálculos en una tabla a nivel de año, los cálculos van a ser los esperados:

Sin embargo, si en lugar de poner nuestra tabla a nivel de año, la ponemos a nivel de año-mes, vamos a tener nuestro activo total medio con los saldos medios de cada mes, mientras que el BAII va a ser el resultado de ese mes únicamente, con lo que el ROA va a salir con cifras mucho más bajas de las mostradas para el mismo ratio en la tabla a nivel anual:

Por ello, debemos tener cuidado del contexto temporal en el que evaluamos nuestra medida y, en caso de que no vaya a evaluarse a nivel anual, debemos darle una vuelta a nuestros cálculos…

Podríamos optar por calcular un rolling year sobre el BAII (en este post de mi blog explicaba cómo calcular el rolling year: Link ) , o un year to date ponderado por el número de días que han transcurrido desde el inicio de ejercicio (pudiendo hacer también un year to date del cálculo del activo medio).

También debemos considerar que si optamos por el rolling year para el cálculo del BAII, los cálculos de los primeros 11 meses de nuestros datos (en nuestro ejemplo desde 2022-01 hasta 2022-11) no van a ser representativos, ya que el rolling year no va a poder acumular el BAII de un año completo al no haber datos para los meses del ejercicio 2021.

Conclusión: Quizás prefiramos no complicar los cálculos y quedarnos con la evaluación de nuestro ratio únicamente a nivel anual, pero si queremos ver una evolución mensual debemos valorar alguna de estas otras opciones comentadas.

Si estas otras opciones generan interés igual me anime más adelante a grabar un pequeño vídeo sobre el tema, ya que sería demasiado extenso para un post…

Espero que te haya resultado interesante y puedas ponerlo en práctica en tus proyectos.

PD: Si quieres aprender cómo crear modelos financieros en Power BI conectados al libro diario de las empresas y más técnicas como ésta, no dejes pasar la oportunidad de adquirir el curso que he preparado para la academia Namasdata. Te dejo el enlace por aquí : Link

Seguimos!!! 👊​

La entrada Cálculo de saldos medios en modelos financieros se publicó primero en reportingfinanciero.es.

El resultado sería similar al de la siguiente imagen:

🖊️ ​En el post de hoy vengo a contarte el detalle de cómo conseguirlo, así que si te mueves en el mundo de las finanzas empresariales y el tema te parece interesante….allá vamos:

Antes de nada, sobra comentar que para aplicar esta solución tendremos que tener montado un modelo financiero en el que elaboremos nuestras medidas.

En nuestro modelo teníamos 2 tablas de hechos, una con los libros diarios de la contabilidad real de las empresas, y otra con los presupuestos.

Tendremos que incorporar a nuestro modelo la fecha del cierre contable que tenemos revisado, que será nuestra fecha de corte para pintar la contabilidad real hasta esa fecha y el presupuesto a partir de la misma.

En el taller, incorporé una consulta desde la opción de “Especificar datos” de Power Query, pero tú puedes incorporarlo desde la fuente que consideres.  Lo que sí es importante es que sea una fuente que pueda modificar únicamente el controller, el director financiero o la persona que sea la encargada de dar el OK definitivo a la revisión de los cierres contables.

La consulta tiene simplemente una columna con un único registro, que es la fecha de cierre revisado. A la columna le asigno el tipo de dato “Fecha”.

A la consulta le doy el nombre de “Revision Cierre” y a la columna “Ultima Revision”.

Dentro de mi informe, tendré que tener calculadas unas medidas para calcular el resultado de PyG de la contabilidad real (a la que llamaré [PyG] ) y de Presupuesto (a la que llamaré [Presupuesto]).

Posteriormente, realizaré la siguiente medida para calcular la fecha de cierre revisado:

Fecha Cierre Revisado = MAX(‘Revision Cierre'[Ultima Revision])

Mi medida DAX para calcular la PyG Proyectada será la siguiente (Nos basamos en la medida [PyG] para calcular el resultado cuando la fecha sea menor o igual a la fecha de cierre revisado y en la medida [Presupuesto] para calcular el resultado cuando la fecha sea mayor a la fecha de cierre revisado):

PyG Proyectada =

CALCULATE (

    [PyG],

    FILTER ( dimCalendario, dimCalendario[Fecha] <= [Fecha Cierre Revisado] )

)

    + CALCULATE (

        [Presupuesto],

        FILTER ( dimCalendario, dimCalendario[Fecha] > [Fecha Cierre Revisado] )

    )

Si metemos esa medida en un gráfico de líneas, y filtramos por el año 2023, tendremos el siguiente resultado:

Refleja el resultado real hasta el mes de octubre (la fecha de cierre revisado es el 31/10/2023) y el valor presupuestado para los meses de noviembre y diciembre.

Sin embargo, nos aparece toda la línea continua y no distinguimos en la propia línea hasta dónde llega el dato real y dónde empieza el presupuestado.

Para conseguir ese efecto, vamos a realizar dos nuevas medidas DAX para pintar cada uno de los 2 tramos que queremos conseguir:

Medida 1:

PyG Proyectada Real =

IF (

    MAX ( dimCalendario[Fecha] ) <= [Fecha Cierre Revisado],

    [PyG]

)

Esta medida nos reflejará el resultado de PyG únicamente cuando el valor de las fechas sea menor o igual a la fecha de cierre revisado.

Si la llevamos a un gráfico de líneas quedaría así:

Como puede observarse, a pesar de tener filtrado todo el ejercicio 2023, únicamente se representan valores hasta el mes de Octubre, que es donde llega la fecha de cierre revisado.

Medida2:

PyG Proyectada Presupuesto =

SWITCH (

    TRUE (),

    MAX ( dimCalendario[Fecha] ) = [Fecha Cierre Revisado], [PyG],

    MAX ( dimCalendario[Fecha] ) > [Fecha Cierre Revisado], [PyG Proyectada],

    BLANK ()

)

Se nos mostraría de la siguiente forma en un gráfico de líneas:

Ahora vemos cómo teniendo filtrado todo el ejercicio 2023 se nos representan valores únicamente desde la fecha de cierre. Destacar que para el valor de Octubre, el dato es el real del PyG de la contabilidad, según indicamos en la primera salida del TRUE().

Esto lo hacemos así para que no haya un salto entre las líneas de real y presupuesto cuando juntemos ambas en un mismo gráfico de líneas.  Al final del post os mostraré lo que ocurriría si obviamos esa primera salida del TRUE y dejamos únicamente valores para las fechas que sean superiores a la fecha de cierre revisado.

Ahora que ya tenemos las 2 medidas preparadas, vamos a juntarlas en un mismo gráfico de líneas para ver el resultado:

Como vemos, a partir de Octubre cambia el color de la línea, al pasar de representar el dato real de la contabilidad al dato del presupuesto.

Ahora, para que destaque más, simplemente vamos a dar formato discontinuo a la línea de la medida “PyG Proyectada Presupuesto” para que nos muestre el resultado que estábamos buscando:

Una vez conseguido el resultado y, como lo prometido es deuda, simplemente quiero mostrarte lo que pasaría si en la medida 2 “PyG Proyectada Presupuesto” quitásemos la primera salida del TRUE y dejásemos la medida de la siguiente forma:

PyG Proyectada Presupuesto =

SWITCH (

    TRUE (),

    MAX ( dimCalendario[Fecha] ) > [Fecha Cierre Revisado], [PyG Proyectada],

    BLANK ()

)

El gráfico quedaría así:

Como puedes observar, al no darle ningún valor a la medida para el caso en que la fecha sea igual a la fecha de cierre revisado, no conseguimos que la línea del presupuesto parta desde el cierre del mes de Octubre, con lo que nos quedaría un salto entre ambas líneas que evitamos gracias a la primera salida del TRUE que incorporamos a la medida (revisar la Medida 2), y que está basada en la contabilidad real con la medida [PyG].

Espero que te haya parecido interesante la entrada y que puedas aplicar esta técnica en tus próximos proyectos 😉​

Seguimos!!! 👊

La entrada Cómo representar en un gráfico de líneas una proyección de cuenta de resultados. 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.

Solemos llegar a soluciones parciales, pero no conseguimos llegar al resultado que nos ofrece cualquier ERP de mostrarnos correctamente el saldo acumulado que tiene la cuenta contable después de cada uno de los apuntes, tal y como se muestra en la siguiente imagen:

Obviamente, la fórmula DAX a emplear dependerá de cómo tengas montado tu modelo de datos.

Para el ejemplo de este post el modelo de datos sería el siguiente:

Una tabla de hechos con los movimientos del libro diario, y las distintas dimensiones para filtrar la información.

La fórmula DAX que yo estaba usando para calcular el saldo acumulado del libro mayor era la siguiente:

Saldo Ac. Mayor =

IF (

    [Saldo],

    CALCULATE (

        [Saldo],

        ALLSELECTED ( dimApuntes ),

        FILTER ( ALL ( dimFecha[Fecha] ), dimFecha[Fecha] <= MAX ( dimFecha[Fecha] ) )

    ),

    BLANK ()

)

Esta fórmula es una adaptación de una aportación que hizo hace ya un par de años ( o algo más 😅​) Leonardo Bergua dentro de la comunidad de Power Platform University.

Te muestro cómo queda en una hoja de detalle de un libro mayor:

Esta medida va acumulando correctamente el saldo acumulado pero tiene un principal inconveniente: si hay varios asientos en la misma fecha (como se destaca en los recuadros rojos y azules de la anterior imagen), la medida muestra el mismo valor para todos los registros de esa fecha (cuando lo esperado sería que diese a cada registro su saldo acumulado y no a todos el saldo resultante al final del día del contexto).

Cuando vi el siguiente vídeo del gran David Uyarra sobre la nueva funcionalidad de cálculos visuales aplicada a calcular saldos contables, enseguida pensé en probarlo para adaptar mi informe financiero y evitar el inconveniente citado anteriormente:

https://www.youtube.com/watch?v=kM0_sqF-fR4

Sin embargo, la funcionalidad del vídeo anterior se ejecuta correctamente cuando no filtramos fechas o, si filtramos fechas, necesitamos que el filtro no deje fuera del contexto el saldo de apertura para que los saldos se arrastren correctamente desde el movimiento de apertura.

Como en mis modelos yo me quedo únicamente con el saldo de apertura del año inicial, esta restricción era un gran escollo, ya que me serviría únicamente si no filtro ninguna fecha y tengo la totalidad de apuntes que afectan al libro mayor.

En una conversación que tuve con Diego Duque en el reciente evento de Power BI Days Bilbao, estuvimos hablando sobre esta problemática que él también estaba afrontando. Se nos fueron ocurriendo varias opciones que se iban cayendo porque no llegaban a resolver el problema😥​

Pero una de las opciones, que combinaba cálculos DAX con los nuevos cálculos visuales, parecía que podía llegar a solucionar el requisito…estas conversaciones en comunidad sin duda que son lo mejor para desatascar problemas 😊

Hasta ahora no había sacado tiempo de ponerme a cacharrear. He podido probar la alternativa y me ha funcionado correctamente, así que voy a desarrollar a continuación los pasos seguidos por si a alguien más le es de utilidad:

1.- Partimos del saldo inicial de la cuenta contable reflejada en el libro mayor. Ese saldo inicial sería el saldo acumulado de la cuenta contable en el día justamente anterior al contexto seleccionado. Esa medida es la que se muestra en el recuadro sombreado en amarillo en la imagen 1 (19.808,05 €).

Esa medida de “Saldo Inicial” en mi modelo tiene el siguiente código DAX:

Saldo Inicial Libro Mayor =

IF ([Saldo],

        //Para que solo pinte saldo inicial en caso de que esté en un asiento con saldo para el contexto filtrado

        IF (

            LEFT ( SELECTEDVALUE ( dimCuentasContables[Subcuenta contable] ), 1 )

               IN { “6”, “7” },

            //Si está en una cuenta de gasto o ingreso no quiero que suma al saldo inicial los saldos anteriores a la fecha mínima (si son cuentas de balance sí), sino que quiero que el saldo inicial sea cero y el saldo que pinte el libro mayor vaya sumando únicamente los importes del periodo seleccionado en el contexto.

            0,

CALCULATE (

[Saldo],

FILTER (ALL ( dimFecha[Fecha] ), dimFecha[Fecha] < MIN ( dimFecha[Fecha] ) )

)),

BLANK ()

)

2.- Necesito construir una medida que repita ese valor en todas las filas del visual de tabla del libro mayor (imagen 1) y que pueda usar posteriormente en los cálculos visuales de esa tabla.

La medida que construyo es la siguiente:

//Calculo la fecha mínima del contexto seleccionado en los filtros externos a la tabla:

VAR FechaMinima =

    CALCULATE ( MIN ( dimFecha[Fecha] ), ALLSELECTED ( dimFecha ) )

//Calculo el saldo inicial acumulando el saldo de las fechas que sean anteriores a la anterior variable:

VAR SaldoInicial =

    IF (

        [Saldo],

        //Para que solo pinte saldo inicial en caso de que esté en un asiento con saldo para el contexto filtrado

        IF (

            LEFT ( SELECTEDVALUE ( dimCuentasContables[Subcuenta contable] ), 1 )

               IN { “6”, “7” },

            //Si está en una cuenta de gasto o ingreso no quiero que sume al saldo los saldos anteriores a la fecha mínima (si son cuentas de balance sí), sino que quiero que el saldo inicial sea cero y el saldo que pinte el libro mayor vaya sumando únicamente los importes del periodo seleccionado en el contexto.

            0,

            CALCULATE (

                [Saldo],

                ALLSELECTED ( dimApuntes ),

                ALLSELECTED ( dimFecha ),

                dimFecha[Fecha] < FechaMinima

            )

        ),

        BLANK ()

    )

RETURN

    SaldoInicial

Vemos cómo queda esa medida con el saldo inicial de 19.808,05 € repetido en cada una de las filas de la tabla:

3.- A continuación, hago un cálculo visual con el saldo acumulado, que hace un RUNNINGSUM de la medida “Saldo”, tal y como se explicaba en el vídeo de David Uyarra.

Recuerda que tienes que tener activada la opción de Cálculos visuales en las características de versión preliminar de las opciones de configuración de Power BI Desktop.

Te recomiendo revisar el vídeo de David Uyarra que mencioné anteriormente si tienes algún problema a la hora de crear este cálculo visual.

4.- Por último, hago un nuevo cálculo visual dentro del visual de tabla para sumar la medida “Saldo Inicial Libro Mayor Cálculo Visual” explicada en el punto 2 y el cálculo visual “SaldoAcumulado1” explicado en el punto 3:

Esta última medida sí que muestra correctamente el saldo del libro mayor para cada uno de los registros sin tener el inconveniente de que se repita el saldo en los apuntes de la misma fecha.

Ahora ya solo queda jugar con los formatos y dejar visibles únicamente las columnas que necesitemos mostrar para llegar a un resultado similar al que obtendríamos desde un ERP.

En la siguiente imagen muestro cómo quedaría para una cuenta de balance (arrastra el saldo anterior al periodo seleccionado en el contexto):

Y en esta otra imagen vemos cómo quedaría para una cuenta de PyG, donde no queremos que arrastre el saldo anterior sino que muestre el saldo para el periodo filtrado:

Espero que te pueda ser de utilidad a la hora de elaborar tus modelos financieros.

Cualquier aporte o mejora son bienvenidos, así que no dudes en contactarme!!!

PD: Gracias a Montse Collantes por su revisión del post, ya que en la primera versión que publiqué únicamente daba solución a las cuentas de balance. Con esta actual versión ya damos solución tanto a cuentas de balance como de PyG.

La entrada ¿Cómo representar el saldo acumulado en la ficha de mayor de una cuenta contable con Power BI? se publicó primero en reportingfinanciero.es.

Es habitual que, desde el área comercial, nos envíen los presupuestos de ventas mensualizados para que desde el departamento financiero metamos los datos en la coctelera con la que elaboramos el presupuesto global de la compañía.

A nivel de cierres financieros, con tener las ventas con esa granularidad mensual es suficiente, ya que los cierres contables los realizamos, a lo sumo, con periodicidad mensual.

El problema viene cuando queremos utilizar el presupuesto de ventas para nuestras reuniones periódicas de seguimiento de la evolución de las ventas.

Lo habitual en estas reuniones es hacer una comparativa de nuestras ventas tanto contra periodos anteriores como contra el presupuesto.  Y ese seguimiento, en la práctica, se hace ya no solo a nivel semanal, sino que la parte comercial y la gerencia suelen revisar estos datos a nivel diario (incluso varias veces al día si me apuras 😜).

Por ello, para crear esos reportes de seguimiento de ventas, necesitamos trabajar el presupuesto mensualizado que nos llega desde el área comercial y repartir ese presupuesto a granularidad diaria.

Vamos a ver a continuación cómo Power Query nos puede facilitar la vida para hacer ese trabajo de reparto:

Partimos de una tabla en la que nos envían el presupuesto de ventas de 2024 para cada una de los departamentos de la empresa (Directas, postventa y distribución) y para cada uno de los meses (la fecha indicada es el último día de cada uno de los 12 meses). Por tanto, tenemos una tabla de presupuesto con 36 registros (12 meses * 3 departamentos):

El objetivo es repartir esos importes mensuales entre cada uno de los días para que cuando hagamos los seguimientos de ventas a cada fecha, podamos comparar contra presupuesto sin tener que esperar a final de mes.

Para ello, vamos a utilizar nuestra tabla de calendario, a la que habremos incorporado una columna con el número de horas laborables de cada uno de los días.    Yo utilizo este sistema de indicar el número de horas porque hay negocios en los que no todos los días se trabajan el mismo número de horas. En este ejemplo, los días de Nochebuena y Nochevieja se trabaja únicamente media jornada, por lo que esos días en lugar de indicar 8 horas indico 4 horas. Los días de cierre (festivos y fines de semana en este ejemplo) indicamos 0 horas:

En esta tabla de calendario de 2024 tendríamos 366 filas (es año bisiesto), indicado las horas laborables de cada uno de los días.

Lo siguiente que vamos a hacer es duplicar nuestra consulta de Calendario y llamamos a la nueva consulta “Calendario mensual”.

A cada una de las 3 consultas que tenemos (Presupuesto, Calendario y Calendario mensual) las agregamos una nueva columna con el número de mes, el cual nos servirá posteriormente para combinar las consultas.  Para ello, seleccionamos la columna de Fecha en una consulta, vamos al menú de Agregar columna => Fecha => Mes => Mes (como vemos en la siguiente imagen). Esta operación la repetimos en las demás consultas.

A continuación, en la consulta de Calendario mensual, agrupamos los datos por la columna Mes para sumar las horas laborables de cada uno de los meses.

Tenemos que pulsar sobre “Agrupar por” y configurar el menú de la siguiente forma:

Obtendremos una tabla con 12 registros que refleja el total de horas laborables de cada uno de los meses:

Tras esto, combinamos la consulta del presupuesto con la del calendario mensual por el campo del mes y nos traemos las horas laborables mensuales a cada fila del presupuesto:

El resultado sería el siguiente:

Ahora combinamos la consulta del presupuesto con la del calendario (el calendario normal, no el mensual) por el campo del número de mes y expandimos los campos de la fecha y las horas laborables diarias.  (nuestra tabla de presupuesto pasará de 36 filas a 1098 => 366 días * 3 departamentos).

El resultado sería el siguiente:

Ahora ya tenemos en nuestra tabla de presupuesto, para cada combinación de fecha y departamento, el presupuesto mensual del departamento, las horas laborables mensuales y las horas laborables diarias.

Por ejemplo, en la fila 2 de la anterior imagen observamos que el día 02/01/2024 (columna FECHA.1) tiene 8 horas laborables de un total de 176 horas laborables del mes de enero; y que el presupuesto mensual del departamento DIRECTAS era de 11.591.186 €.

Con todos estos datos, ya podemos calcular la parte proporcional de presupuesto que le toca a cada combinación de departamento-fecha.

Para ello, vamos a crear una columna personalizada que llamaremos “Presupuesto diario”. Será el resultado de multiplicar el valor del presupuesto mensual por las horas laborables diarias y dividirlo entre las horas laborables mensuales:

Ponemos a la nueva columna formato número decimal fijo y el resultado sería el siguiente:

Por último, dentro de la consulta de presupuesto nos quedaríamos únicamente con las columnas “Departamento”, “FECHA.1” (a la que renombraremos posteriormente como “Fecha”) y “Presupuesto diario”.

El resultado sería el siguiente:

Por tanto, gracias a estas transformaciones realizadas en Power Query, ya habríamos conseguido nuestro objetivo de distribuir un presupuesto que nos habían entregado a granularidad mensual y dejarlo distribuido a granularidad diaria.

Espero que te haya resultado útil y puedas utilizarlo cuando te toque elaborar el presupuesto de 2025 😜

Seguimos!!! 👊​

PD: Te dejo preparado un pbix con los datos de este ejercicio para que puedas practicar el paso a paso.

El enlace de descarga es el siguiente:  

La entrada Reparto presupuesto mensual a nivel diario se publicó primero en reportingfinanciero.es.

📝 Me he animado a detallar la ruta de aprendizaje que, en base a mi experiencia y a la formación que conozco, seguiría si tuviese que empezar nuevamente mi camino desde cero (enfocada a usuarios de negocio como yo).

1.- Primer mandamiento 😜. Empezaría por una primera lectura del libro “Fundamentos de Modelado en Estrella” de Toni Jurado. Un imprescindible para comprender los conceptos clave de modelado, la parte fundamental de todo proyecto de BI. Y digo primera lectura porque seguro que, con el tiempo, querrás volver a repasar los conceptos detallados en el libro.

Después, me pasaría a formación en vídeo, ya que es la que más me gusta. Procuro buscar formación que sea en vídeo bajo demanda para poder adaptarlo a mis horarios; o formación en streaming que permita visualizar los vídeos fuera del horario de la formación.

Me gusta mucho este formato porque sigue una estructura que hace que no me disperse y puedo ir repasando conceptos y tomando anotaciones a mi ritmo.

2.- Realizaría una formación en la plataforma NamasData.  Bien el “Curso Power BI de 0 a 100”, o el específico de PL-300 (si está entre tus objetivos el certificarte). Me parece una opción ideal para iniciarse y conseguir una visión global de toda la plataforma de Power BI, de la mano de un gran instructor como Alex Ayala , MVP de Microsoft y muy activo en la comunidad.

3.- Si, como en mi caso, tienes un perfil financiero o de controlling, sin duda te recomendaría seguir tu ruta por Club Power Platform for Controlling, una plataforma especializada en este tipo de perfiles. Yo llevo formándome con ellos desde hace unos 4 años, cuando realicé una formación que incluía tutorías para implantar un modelo financiero en mi empresa y que cambió mi forma de trabajar. De hecho, la metodología que aprendí e implanté entonces en mi empresa es la que me ha servido para plantar las bases de mis proyectos de consultoría y formación de reporting financiero.  Además, sus formaciones abarcan más tecnologías de Power Platform como Power Apps, Power Automate o Dataverse.  Estoy seguro de que conseguirás mejorar tus actuales procesos y dar un impulso a tu carrera profesional de la mano de grandes instructores como Daniel Martínez o Juan Luis Rodríguez Pardo , dos de los profesionales de los que más he aprendido.

4.- Me leería estos libros centrados en Power Query y DAX:

• “Power BI Dataflows”, de Francisco Mullor Cabrera (una persona a la que siempre estaré agradecido porque no he parado de aprender de él desde que empecé con Power BI). Francisco tiene un blog con entradas muy interesantes: powerbisp. Entre el material, hay una dimensión calendario espectacular, que es la que uso en mis proyectos y que también viene detallada en su libro.
• “Tratamiento de datos con Power Query”, de Ana María Bisbé York, publicado recientemente. No he podido aún leerlo completo, pero lo que he podido leer hasta ahora me parece muy instructivo.
• “DAX Para todos Vol 1”, de Didier Atehortúa Morales y Christian Tamayo. Leer este libro me ayudó mucho para profundizar en el mundo DAX y comprender conceptos que hasta entonces no dominaba, como las tablas virtuales o las variables.

También recomendaría leer el libro “Curso de Power BI”, también de Ana Bisbé, que da un repaso por toda la plataforma.

Y si te mueves en el mundo financiero, me parece muy interesante el libro “Control de gestión con Excel y Power Query”, de José Manuel Pomares – Power BI MVP – Excel y Clara Vega Caballero , con casos prácticos que podrás aplicar en Power BI para dar solución a problemáticas concretas de negocio.

5.- Si quieres profundizar en Power Query y lenguaje M, echa un vistazo a las formaciones de dataXbi , de Diana Aguilera Reyna y Nelson Lopez Centeno. He podido estar en varias ponencias suyas y son dos grandes expertos en la materia.

6.- Para mejorar tus habilidades DAX o profundizar en técnicas para optimizar tus modelos, Ricardo Rincón es mi referente.  Síguelo en Linkedin y en su canal de Youtube “Bitodata” para aprender sobre Dax Studio y Tabular Editor. Periódicamente lanza formaciones en streaming que están en mi lista de pendientes.

7.- Si quieres mejorar en la visualización de datos, revisa las formaciones de Consultora HACHE. , con Carlos Bérgamo Scarso . También en mi lista de futuribles.

8.- En cuanto a canales de YouTube, mis preferidos son los siguientes:

• Miguel Egea. Hay contenido de auténtico lujo en su canal. Recuerdo un escenario de negocio que resolví gracias a uno de sus vídeos. (Gracias de nuevo, Miguel Egea Gómez 😉).
• Sandielly Ortega Polanco. Tiene gran contenido con muy buena edición de vídeo y explicado de lujo.
• Women For Technical Talks (W4TT) y @PowerBIEspanolentelegram donde encontrarás multitud de sesiones súper interesantes.
• Antonio Sánchez De Boeck y DATAEDU IDN . Me gustan porque suelen tocar temas financieros y porque profundizan en el uso de visualizaciones Zebra. Gracias a ellos he empezado a usar estas visualizaciones en alguno de mis proyectos .

Eso sí, te recomiendo llegar a YouTube después de haber hecho alguna formación estructurada o para buscar cómo resolver alguna duda concreta, porque si no el riesgo de dispersión es altísimo….😅

9.- También me suscribiría al canal de Telegram de Power BI Español: t.me/powerbiespanol

Es una fuente inagotable de conocimiento. Los usuarios podemos lanzar dudas y siempre hay alguien dispuesto a ayudar. Te advierto de que tiene un volumen muy alto de actividad y reconozco que no suelo poder seguir todas las conversaciones, pero en cuanto tengo un rato muerto procuro ver qué dudas se han resuelto. He aprendido un montón a base de ver problemas con los que se han enfrentado otros compañeros. Destacar aquí la impagable labor de Francisco Mullor Cabrera , Ricardo Rincón y Francisco Aracil Alarcón , entre otros, ya que suelen ser los más activos resolviendo dudas.

10.- Acudiría a eventos de comunidad donde se comparte mucho conocimiento y conoces a mucha gente con tus mismas inquietudes. Es una pasada el gran ambiente que hay en estos eventos!!!  Busca si tienes alguna comunidad cerca de tu residencia y anímate a asistir a sus eventos.

Hay otras opciones (de las que yo solo he probado algunas) que también te recomiendo visitar para ver si lo que ofrecen se adapta mejor a lo que estás buscando: cursospowerbi.es , Sentido Analítica , Temixa Consulting , elfuturodelosdatos.com , Acadevor , EXCEL Y FINANZAS , Grow Up Data Analytics o LinkedIn Learning.

Seguro que me dejo muchas opciones súper útiles, pero dejo aquí mi selección….

🚀 Disfruta de tu aprendizaje!!!!

#powerbi  #aprendizaje  #cursos  #libros  #Youtube

La entrada Ruta de aprendizaje de Power BI. se publicó primero en reportingfinanciero.es.