Admin | Business Intelligence Controlling

Autor: Admin Página 1 de 3

Introducción

Hace ya unos años que Microsoft incorporó a DAX una nueva familia de funciones tabulares muy especiales: las funciones WINDOW. Se trata de funciones conceptualmente muy similares a las funciones homónimas de SQL, diseñadas para operar sobre conjuntos de datos previamente ordenados y, si es necesario, particionados.

Hasta ese momento, resolver cálculos dependientes de posiciones relativas; el primer cliente, el anterior pedido, el siguiente valor en un ranking, implicaba recurrir a funciones como TOPN o RANKX, y a iteraciones anidadas.

Estas funciones no amplían realmente la capacidad expresiva de DAX, todo lo que hoy hacemos con estas funciones ya podía hacerse antes, pero sí transforman la forma en que lo escribimos. Simplifican el código, lo hacen más mantenible y, en muchos casos, más eficiente. Además, introducen un concepto nuevo y fundamental en el lenguaje: apply semantics, al que seguramente dedicaremos otro artículo más adelante, que permite que dichas funciones interactúen simultáneamente con el contexto de fila y el contexto de filtro.

En este artículo vamos a aplicar estas funciones a un caso de negocio muy habitual: la identificación de clientes nuevos, perdidos y recuperados. Un problema clásico en análisis comercial que, gracias a estas funciones puede resolverse hoy con un rendimiento, claridad y precisión muy superiores a los patrones tradicionales.

Aunque el foco estará en clientes, el patrón que construiremos es completamente generalizable. La misma lógica puede aplicarse para detectar productos que dejan de venderse, productos reactivados, tiendas que inician o cesan actividad, comerciales que recuperan cartera…

En los siguientes apartados veremos cómo funcionan estas funciones y cómo utilizarlas correctamente para construir un patrón sólido, reutilizable y eficiente.

Las tablas padre-hijo y el reporting económico-financiero en Power BI

por Admin

en 3 febrero, 2026

en Arquitectura de datos, Controlling / Dir. Financiera, DAX, M (Power Query)

Introducción

En el ámbito del reporting económico-financiero hay algo incuestionable: las estructuras nunca son definitivas. Las organizaciones evolucionan, cambian los criterios de análisis y aparecen nuevas necesidades de información que obligan a revisar continuamente la forma en que se presentan los estados financieros.

Esta situación se hace especialmente evidente en la gestión de las estructuras jerárquicas que soportan estados financieros analíticos, como la Cuenta de Resultados Analítica. Epígrafes, subepígrafes y centros de responsabilidad forman jerarquías complejas que deben ser coherentes y fáciles de mantener y evolucionar. Cuando estos cambios requieren intervención técnica o ajustes costosos (en tiempo y dinero), el reporting deja de acompañar al negocio y se convierte en una limitación.

Antes de continuar, cuando en este artículo hablemos de centros de responsabilidad (coste o beneficio), a lo que me refiero es a centros de responsabilidad contables, es decir, centros virtuales que agrupan ingresos/costes relacionados con una actividad que no tiene por qué estar definida formalmente y que en la práctica corresponden a las combinaciones que existen entre las cuentas contables y las dimensiones analíticas definidas en una organización, como pueden ser el departamento, el área, el equipo etc…

En este contexto de las estructuras de los estados financieros, las tablas padre-hijo ofrecen un enfoque especialmente adecuado. Permiten almacenar y gestionar jerarquías de profundidad variable sin alterar la estructura física de los datos, facilitando una gestión flexible y escalable de las estructuras de reporting financiero.

A lo largo de este artículo veremos qué son las tablas padre-hijo, por qué encajan de forma natural con el reporting económico-financiero y cómo, combinadas con Dataverse y una model-driven Power App (o cualquier otro sistema en el que podamos crear la aplicación), permiten trasladar al usuario de negocio la responsabilidad y la autonomía para mantener y adaptar estas estructuras. Porque en los departamentos de finanzas y controlling, el cambio no es la excepción, sino la norma.

Centralizando accesos a Lakehouses y otros artefactos en Microsoft Fabric

por Admin

en 26 enero, 2026

en Arquitectura de datos, Fabric

Introducción

En entornos reales de Microsoft Fabric no trabajamos con un único Lakehouse ni con un solo workspace. Lo habitual es convivir con múltiples workspaces, lakehouses, warehouses y bases de datos SQL, que van creciendo con el tiempo y se reutilizan desde distintos notebooks.

El problema aparece cuando ese crecimiento no va acompañado de una forma ordenada de acceder a los artefactos. Muy rápidamente los notebooks empiezan a llenarse de:

rutas abfss://... hardcodeadas
IDs de workspaces y lakehouses copiados a mano
dependencias implícitas que solo entiende quien escribió el código

Todo funciona… hasta que el mantenimiento y la evolución del entorno se vuelven una pesadilla.

Este artículo muestra cómo centralizar el acceso a los artefactos de Microsoft Fabric desde un único notebook, utilizando la API de Fabric para descubrir dinámicamente:

los workspaces disponibles,
sus lakehouses,
warehouses
y bases de datos SQL

y exponer esa información como variables globales reutilizables y como un catálogo en memoria accesible desde otros notebooks.

El objetivo no es gestionar permisos ni seguridad, ni abstraer Fabric detrás de una capa compleja. El objetivo es mucho más práctico:

Dejar de repetir rutas, IDs y nombres en cada notebook y disponer de un único punto de referencia para acceder a los artefactos de Fabric.

A lo largo del artículo construiremos este notebook paso a paso, empezando por una versión básica y evolucionándolo hasta una solución robusta que tenga en cuenta las limitaciones reales de la API de Microsoft Fabric.

La concepción financiera del EBITDA

por Admin

en 23 enero, 2025

en Controlling / Dir. Financiera

Introducción

En el mundo del análisis y reporting económico-financiero pocos indicadores vamos a encontrar más famosos y que generen más controversia en torno a su calidad y fiabilidad que el EBITDA. Este indicador mide el margen de un negocio independientemente de como se financia (intereses), su domicilio y gestión fiscales (impuestos) y su política de propiedad de los activos afectos al negocio (amortizaciones).

Al contrario de lo que se suele pensar, el EBITDA no es un indicador definido formalmente ni está reconocido por los GAAP (Generally Accepted Accounting Principles). A pesar de esto, su uso es casi universal en análisis financiero y de inversiones, lo que le convierte en un estándar implícito en el mundo empresarial. Esta falta de «oficialidad» es lo que hace que nos encontremos con ajustes y alguna variación en la forma de calcularlo.

Teniendo esto en cuenta, mucho antes que entrar a evaluar si se trata de un buen indicador o no, tenemos que entender bien lo que intenta representar, de manera que podamos interpretar su valor y sus variaciones correctamente. Partiendo de la base de que el EBITDA no es la caja generada por las operaciones, sino que se trata de un margen contable, vamos a analizar los componentes de este indicador y veremos qué lo separa de la caja real u operativa, para finalmente llegar al apartado 5 del Estado de Flujos de Efectivo del PGC: Los Flujos de efectivo de las actividades de explotación, identificando por el camino los 5 usos financieros que el EBITDA debe cumplir en la empresa.

Tablas de intervalos de fechas y relaciones virtuales

por Admin

en 13 noviembre, 2023

en Arquitectura de datos, Controlling / Dir. Financiera, DAX

En el último artículo utilizamos DAX para analizar las ventas de una empresa a partir de una tabla en la que disponíamos de los precios para un determinado cliente, artículo y rango de fechas.

En este artículo vamos a complicar un poco más el requisito de negocio y veremos cómo podemos utilizar la función TREATAS para establecer relaciones virtuales en el caso de que existan registros de precios que no dependan de las columnas de relación, en el ejemplo del artículo anterior, el IdCliente y el IdArticulo, sino que utilicen otros atributos dimensionales para la asignación del importe.

En este ejemplo vamos a trabajar con precios de coste en lugar de con precios de venta. Supongamos que la tabla con la que tenemos que operar ahora es la siguiente:

Trabajando con tablas ‘desde-hasta’ o de rango de fechas en Power BI

por Admin

en 26 octubre, 2023

en Arquitectura de datos, Controlling / Dir. Financiera, DAX

Introducción

Uno de los tipos de tabla que nos encontramos frecuentemente a la hora de crear un modelo de datos analítico corresponde a las tablas «desde-hasta» o de intervalo de fechas. Estas son un tipo de estructura muy versátil que utilizan las bases de datos para representar y gestionar información relacionada con valores aplicables entre determinados periodos de tiempo.

Sus usos son muy variados, ya que este tipo de estructura proporciona un almacenamiento y procesamiento altamente eficientes en un sistema transaccional. Almacenar de esta forma los datos minimiza la redundancia y optimiza el almacenamiento al eliminar la necesidad de duplicar registros para cada instancia de tiempo. Algunos de los escenarios en los que nos encontraremos con este tipo de tablas son:

Sistemas de reservas y programación de eventos
Gestión de RRHH
Planificación de campañas de Marketing
Gestión de contratos
Listados de tarifas
Gestión de casos e incidencias

En este artículo vamos a explorar las distintas formas de modelar y analizar este tipo de tablas, teniendo en consideración aspectos relacionados con el rendimiento de las consultas y el tamaño de los datos almacenados.

La rentabilidad en un modelo de datos financiero

por Admin

en 19 septiembre, 2023

en Arquitectura de datos, Controlling / Dir. Financiera, DAX, Inteligencia de tiempo

Introducción

En este artículo vamos a tratar una de las cuestiones clave para diagnosticar la salud de una empresa: la rentabilidad. Este indicador, que como veremos más adelante puede hacer referencia a métricas totalmente distintas entre si, depende de forma considerable de las decisiones tomadas por los directivos de la organización.

Podríamos pensar que nos acercamos a la rentabilidad mediante la comparación interanual de los beneficios empresariales. Sin embargo, dicha comparación puede albergar actuaciones empresariales que distorsionen la calidad del resultado. Por ejemplo, si el incremento de las ventas proviene de una pobre negociación con los clientes, que ha dado como resultado una ampliación del periodo medio de cobro; o si está acompañado de una estrategia de enfoque conservador en las operaciones, con grandes incrementos en los saldos de existencias para evitar roturas de stock, ese aumento de ventas y de beneficios conllevará también un incremento indeseado de los activos en el balance (en este caso, de las necesidades operativas de fondos) y, por lo tanto, exigirá igualmente un aumento de los recursos para financiarlos. Del mismo modo, un incremento en la cifra de ventas conseguido mediante un aumento desproporcionado en los costes incurridos para obtener aquellas tampoco mejorará la rentabilidad.

Integridad referencial y miembros desconocidos en Power BI

por Admin

en 31 agosto, 2023

en Arquitectura de datos, M (Power Query)

Introducción

En este artículo vamos a explorar como se comporta Power BI cuando en un modelo de datos existen violaciones de la integridad referencial, y como podemos identificar y solventar este problema, a la vez que agrupamos los miembros desconocidos dotándolos de significado y garantizando la integridad de nuestro modelo.

La integridad referencial es un conjunto de reglas que utilizan las bases de datos relacionales para asegurarse de que no existen valores en una clave foránea que no estén en la clave primaria de la tabla relacionada. Veámoslo con una imagen:

Las funciones ALL* como modificadores de CALCULATE

por Admin

en 20 julio, 2023

en Arquitectura de datos, DAX

INTRODUCCIÓN

La función ALL (y sus compañeras de familia: ALLEXCEPT, ALLNOBLANKROW, ALLCROSSFILTERED y ALLSELECTED) son unas de las funciones tabulares de DAX más utilizadas, principalmente con el propósito de expandir el número de registros a considerar en la realización de un determinado cálculo, eliminando filtros que se encuentran activos en el contexto actual.

Como función tabular, ALL devuelve todas las filas de una tabla o todos los valores únicos de una o más columnas dependiendo del parámetro utilizado.

Cuando usamos una de estas funciones como la función de primer nivel en un argumento de filtro de CALCULATE, su comportamiento cambia y en lugar de funcionar como una función de tabla actúa como un modificador de CALCULATE, eliminando un filtro existente en el contexto en lugar de crear uno nuevo.