¿Contabilizar el gasto de compra de aprovisionamientos al recepcionar el material o al contabilizar la factura de compra?

He trabajado con empresas que optan por caminos distintos…

En esta ocasión vamos a profundizar en la primera opción, que es la que yo prefiero: contabilizar el gasto con la recepción del material (al meter el albarán de compra en el sistema), llevando como contrapartida en el asiento una cuenta 4009 de proveedores, facturas pendientes de recibir.

De esa forma, conseguimos llevar una correlación entre el gasto, que entra en PyG por la compra, y el ingreso, producido en la cuenta de variación de existencias por el aumento de stock (entra nueva mercancía en el almacén).

Con lo que el efecto en PyG por la recepción de la mercancía es cero. El gasto entrará más adelante, en el momento en el que se produzca la entrega de la mercancía al cliente y se produzca la disminución de stock vía variación de existencias negativa.

Y cuando llega la factura del proveedor y la contabilizamos, lo hacemos contra la cuenta 4009, cancelando el saldo generado con la recepción del material.

Por tanto, por cada albarán de compra recibido en el sistema, se genera el siguiente asiento:

————————————————————x——————————————————————————————-

60000000 Compra de mercaderías     a    Proveedores, facturas pendientes de recibir 4009XXXX

————————————————————-x——————————————————————————————-

Y al regularizar las existencias, se generaría este otro asiento:

———————————————x——————————————————————————————

30000000 Mercaderías         a     Variación de existencias de mercaderías     61000000

———————————————-x—————————————————————————————–

Efecto en PyG:  0

En el momento en que contabilicemos la factura del proveedor, el asiento quedaría así:

——————————————————————————————x———————————————–

4009XXXX Proveedores facturas pendientes de recibir    a     Proveedores     4000XXXX

47200000  IVA Soportado

——————————————————————————————–x———————————————

Donde hay que tener precaución con este sistema es en chequear en los cierres la mercancía que aún no ha llegado a tu almacén pero tu proveedor ya te ha facturado.

Este tipo de situaciones es más habitual de lo que parece, especialmente cuando trabajamos con proveedores internacionales o con plazos de transporte largos.

Imagina un material que sale del almacén de tu proveedor el 29 de diciembre y tu proveedor te envía la factura con la salida del material.  Contabilizas la factura con fecha 29/12 contra la 4009, pero el material no llega hasta el 4 de enero, de manera que la cuenta 4009 queda a cierre de ejercicio con un saldo deudor, algo poco coherente… (estaríamos reflejando un saldo en “proveedores, facturas pendientes de recibir” que se genera por una factura que ya he recibido…).

¿Qué ajuste realizo en los cierres contables?.

Obtengo el listado de albaranes de compra facturados en el ejercicio N y recepcionados en el ejercicio N+1, con el detalle por proveedor,  y contabilizo ese importe como existencias de mercaderías en tránsito, disminuyendo como contrapartida el saldo de las cuentas 4009 correspondientes a cada proveedor:

————————————————————-x——————————————————————————————

3000000X Mercaderías en tránsito       a     Proveedores, facturas pendientes de recibir 4009XXXX

————————————————————–x—————————————————————————————–

Así, ese importe queda reflejado como lo que realmente es, un activo que aparece en existencias por la mercancía que está camino de mis almacenes; y no como un saldo deudor en facturas pendientes de recibir, que minoraría el pasivo en la partida de acreedores comerciales.

Este tipo de situaciones es difícil de detectar manualmente cuando el volumen de compras es elevado.

Utilizando Power BI podemos identificar fácilmente los albaranes “problemáticos”, obteniendo un listado que sirve de base para realizar los ajustes de cierre.

Detallo a continuación el paso a paso de cómo realizarlo, tomando como referencia el ERP SAGE 200 (tendrías que adaptarlo al ERP que utilices).

• 1.- Lo primero que vamos a generar es un parámetro, que nos servirá como fecha de corte de nuestro cierre contable.

Para ello, vamos al menú de Power Query “Administrar parámetros” y elegimos la opción “Crear parámetro nuevo”, configurándolo de la siguiente forma:

• 2.- Nos conectamos a la base de datos de SQL del ERP y elegimos la tabla de las cabeceras de los albaranes de compra:

• 3.- Una vez que tenemos la tabla en Power Query, filtramos por la/s empresa/s que queramos chequear y nos quedamos con los siguientes campos:

• 4.- Ahora, nos quedaría filtrar los albaranes que son posteriores a la fecha de cierre y cuya fecha de factura es anterior a la fecha de cierre.

Desde el campo “FechaAlbaran” vamos al menú de filtrado, a través de la flecha que está al lado del nombre del campo, y elegimos la siguiente opción:

• 5.- En el menú que nos sale, realizamos la siguiente configuración desde la opción de “Uso avanzado”, vinculando los valores de filtrado al parámetro que creamos en el primer paso:

• 6.-  Con eso, nos quedaría el listado de los albaranes “problemáticos”, pudiendo ya desde Power BI sacar un listado de importes por proveedor y hacer los asientos de ajustes correspondientes:

En un próximo post hablaremos de la otra alternativa, contabilizar el gasto con la contabilización de la factura, y de qué ajustes habría que hacer si seguimos ese método para no falsear nuestros resultados. Como no, también veremos cómo calcular esos ajustes con Power BI.

La entrada Mercancía en tránsito en el cierre contable: cómo detectarla y ajustarla con Power BI se publicó primero en reportingfinanciero.es.

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.

Una pega que le veía, hasta hace bien poco, es que no conseguía incorporar formato condicional a medidas que tenía incluidas en un parámetro de campo.

Pues bien, recientemente aprendí gracias al maestro Ricardo Rincón cómo lograrlo.

Y, como me ha resultado tan útil….no puedo dejar de compartirlo con la comunidad por si a alguien más le resulta de utilidad.

Os pongo en contexto….

Os muestro a continuación una imagen de un modelo financiero, en la página en la que mostramos una cuenta de pérdidas y ganancias, y vemos como a la medida “Var.PyG” (que muestra la diferencia entre el resultado del ejercicio actual y el ejercicio anterior) le hemos añadido un formato condicional de barras de datos con tono azul para los valores positivos y grises para los negativos:

Eso lo conseguimos seleccionando la matriz en la que tenemos las medidas y dando click derecho sobre la medida a la que queremos añadir el formato condicional. Seleccionamos las opciones de “Formato condicional”  →  “Barras de datos”:

La cuestión es que cuando queremos añadir formato condicional a una medida que está incluida en un parámetro de campo no tenemos habilitada esa opción.

En la siguiente imagen, vemos una serie de medidas que podemos elegir a través de un selector (marcado con un 1 en la imagen). Esas medidas están incluidas en un parámetro de campo, que es el que hemos incluido en el apartado de valores de la matriz (marcado con un 2 en la imagen):

Si ahora queremos dar el mismo formato condicional a la medida “Var.PyG”, no tenemos opción de hacerlo desde el botón derecho como antes, donde teníamos todas las medidas incluidas en la matriz. En la siguiente imagen vemos que no nos aparece esa opción:

¿Cómo podemos entonces darle ese formato condicional?.

Pues de una forma realmente sencilla pero que yo, sinceramente, no había caído en probar…

Simplemente arrastramos a la parte de valores la medida a la que queremos aplicar el formato condicional (Var.PyG), y le aplicamos formato condicional a esa medida con la opción del botón derecho:

Le aplicamos el formato deseado y pulsamos sobre “Aceptar”:

Vemos a continuación cómo se muestra el formato condicional tanto en la medida suelta (la última columna de la matriz) como en la medida incluida en el parámetro de campo:

Ahora ya, simplemente, quitamos de la matriz la medida suelta a la que hemos aplicado el formato condicional y se nos mantendrá ese formato en esa misma medida que está incluida en el parámetro de campo:

Indicar además que ese formato se respeta aunque se filtren medidas en el selector del parámetro de campo, con lo que queda totalmente funcional:

Súper sencillo, ¿verdad?.

Pues sí…muy fácil una vez que te lo cuentan…. (gracias Ricardo ☺️​ )

Espero que te sea de utilidad.

Seguimos!!! 👊

La entrada Cómo añadir formato condicional en los parámetros de campo. 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 reto era conseguir que, en un filtro de fecha, al abrir el informe salga seleccionada por defecto siempre la última fecha de un campo de una tabla, pudiendo el usuario modificar la fecha en el filtro si así lo necesita.

La técnica que vamos a utilizar se la vi por primera vez al maestro Francisco Mullor en una duda que resolvió en el grupo de Telegram de Power BI Español, y me vino de perlas para resolver este reto. Gracias, Fran 😉

Vamos a simular que estamos ante un informe de ventas y queremos que nos aparezca filtrada por defecto la fecha de la última venta.

Para ello, partimos de una sencilla tabla de hechos en la que tenemos una columna con la fecha de la venta, y otra con el importe:

Por otro lado, vamos a tener una dimensión calendario simple, en la que tendremos únicamente creada una lista de fechas desde el 01/01/2023 al 31/12/2024 y añadiremos las columnas Año, Mes y Día:

Lo que haremos a continuación, será crear una consulta nueva en la que registrar el valor de la fecha máxima en la que ha habido ventas.

Para ello, vamos en Power Query a Nuevo Origen => Consulta en blanco , y pegamos en la barra de fórmulas la siguiente instrucción:

= List.Max(factVentas[Fecha Venta])

Nos devuelve el valor buscado, que en nuestro ejemplo sería el 10/11/2024:

Llamamos a esta consulta “FechaMax”.

El siguiente paso va a ser crear en nuestra tabla calendario una nueva columna personalizada en la que vamos a indicar que si la columna “Fecha” de nuestra tabla calendario es igual a la fecha calculada en la consulta “FechaMax”, indique el texto “Fecha Máxima” y, de lo contrario, nos indique el valor del campo “Fecha”.

El código M quedaría así:

= Table.AddColumn(DíaInsertado, “FechaFiltro“, each if [Fecha] = FechaMax then “Fecha Máxima“ else [Fecha])

Como puede observarse, la nueva columna a la que hemos llamado “FechaFiltro” nos muestra el valor “Fecha Máxima” para el día 10/11/2024, que es el valor de la última fecha en la que hay ventas, y para el resto de días nos refleja el valor de la fecha.

A esta columna le daremos tipo de dato texto.

A continuación, vamos a crear una nueva columna personalizada en nuestra dimensión calendario que tendrá el objetivo de poder ordenar la columna de tipo texto del paso anterior.

Para ello, generaremos el siguiente código M:

= Table.AddColumn(#“Tipo cambiado“, “idFecha“, each [Año]*10000+[Mes]*100+[Día])

A este nuevo campo le damos formato número entero.

Ya habríamos hecho todos los preparativos en Power Query y podríamos darle a “Cerrar y aplicar” para pasar a Power BI.

El siguiente paso va a ser ordenar la columna “FechaFiltro” por la columna “idFecha” para que la ordenación del campo que es texto sea por el orden natural del calendario:

Por último, generaremos una medida que nos calcule las ventas (un simple SUM de la columna Importe de la tabla de hechos): 

Ventas = SUM(factVentas[Importe])

A continuación, creamos dos visuales en nuestro lienzo:

1.- Una tabla con el campo “Fecha” de la dimensión calendario y la medida Ventas que acabamos de crear.

2.- Un filtro con el campo “FechaFiltro” de nuestra dimensión calendario (el que es de tipo texto).

Si en el segmentador de FechaFiltro vamos a buscar la fecha de la venta máxima (10/11/2024) vemos que nos aparece el texto “Fecha Máxima”:

Y si lo seleccionamos, vemos como nos filtra correctamente la fecha del 10/11/2024 en el visual de tabla:

Lo bueno de esto es que, en futuras actualizaciones, el filtro de “Fecha Máxima” se irá moviendo en función de la última venta que haya en nuestra tabla de hechos, y nos aparecerá filtrada por defecto esa nueva fecha.

Otro requisito habitual es tener filtrado por defecto el día actual (el día de hoy en modo dinámico). 

Para ello, la técnica es la misma, solo que en el paso donde creábamos la consulta “FechaMax” para quedarnos con el valor de la fecha máxima en la que había habido venta, ahora buscaríamos conseguir el valor de la fecha de “hoy” de forma dinámica, lo que conseguiríamos con el siguiente código M en la barra de fórmulas de la consulta:

= Date.From(DateTime.LocalNow())

El resto de pasos serían idénticos a lo ya explicado anteriormente.

Cada vez que se actualizase el informe, se recalcularía la fecha actual y se modificaría el filtro seleccionado.

Te dejo en el siguiente enlace de descarga el pbix para que puedas revisar el paso a paso:

Espero que te haya resultado útil y puedas rescatarlo si se te plantea este requisito en el futuro!!!

La entrada Filtro de fecha dinámico se publicó primero en reportingfinanciero.es.

Cuando luego me da por querer formatear las medidas, hasta ahora tiraba de la web www.daxformatter.com y las iba “arreglando” una a una…

Si te pasa lo mismo, hoy te vengo con un truco que aprendí el pasado 25 de octubre en los Power BI Days de Santiago de Compostela dentro del fabuloso workshop de optimización de DAX que impartió el maestro José Manuel Pomares 👨🏻‍💻​.

Voy a explicarte paso a paso cómo utilizar la vista de consultas DAX de Power BI para formatear de golpe todas las medidas que tengas en tu modelo.

1.- Partimos de un modelo con una serie de medidas y, como ves, están escritas sin respetar ningún tipo de formato, a texto corrido:

Con el resto de medidas ocurre exactamente lo mismo.

2.- Nos vamos a la vista de consultas DAX, después pulsamos click derecho sobre cualquiera de nuestras medidas, pulsamos sobre “Consultas rápidas” y, por último, sobre “Definir todas las medidas de este modelo”:

3.- Nos aparecerá la siguiente pantalla en la que veremos cómo al principio de la expresión nos aparecen tras el “DEFINE” todas las medidas de nuestro modelo escritas tal y como las teníamos, con texto corrido:

4.- Para formatear todas las medidas, pulsamos sobre el botón “Dar formato a la consulta” de la parte superior:

5.- Una vez pulsado el botón, vemos cómo las medidas que lo necesitan nos aparecen perfectamente formateadas:

6.- Una vez comprobado, pulsamos sobre el botón “Actualizar modelo con cambios”, pulsamos sobre “Actualizar modelo” en el mensaje de advertencia que nos sale posteriormente y automáticamente se hace la magia… 🧙‍♂️:

Si volvemos a la vista de informe y pulsamos sobre cualquiera de nuestras medidas ya la tendremos perfectamente formateada:

Realmente útil, ¿verdad?…. 😉​

La entrada Cómo formatear de golpe todas las medidas DAX de tu modelo 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.