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.

¿Qué es una tabla padre-hijo?

Una tabla padre-hijo es un tipo de estructura de datos especialmente útil cuando trabajamos con información que se organiza de forma natural en jerarquías. Es decir, cuando los datos no responden a una relación plana, sino a un esquema en forma de árbol, donde cada elemento puede depender de otro y, a su vez, tener elementos dependientes.

Este tipo de estructuras es muy habitual en sistemas transaccionales. Algunos ejemplos clásicos son los organigramas empresariales, donde cada empleado tiene un supervisor, o las clasificaciones de productos, organizadas en categorías, subcategorías, familias, etc. En todos estos casos, un mismo nodo puede actuar simultáneamente como hijo de un nivel superior y como padre de otros niveles inferiores:

Desde el punto de vista de la arquitectura, una tabla padre-hijo se caracteriza por tener una referencia a sí misma. Cada registro dispone de un identificador propio y de un campo adicional que almacena el identificador de su “padre”, es decir, del nodo inmediatamente superior dentro de la jerarquía. Los registros que no tienen padre constituyen la raíz, o raíces, del árbol.

Este enfoque permite representar jerarquías de cualquier profundidad con una estructura de tabla muy simple y estable. No es necesario definir de antemano cuántos niveles va a tener la jerarquía, ni crear una columna por cada uno de ellos. La relación entre los nodos es la que define la estructura, no el número de campos de la tabla.

En la siguiente imagen se muestra la misma jerarquía representada de dos formas distintas. A la izquierda, en formato padre-hijo, cada registro almacena únicamente su identificador y la referencia a su nodo padre, siendo la relación entre los elementos la que define la estructura jerárquica. A la derecha, la misma información aparece en formato plano, desplegada en columnas que representan explícitamente cada uno de los niveles de la jerarquía.

Ambos enfoques describen exactamente la misma realidad desde el punto de vista del negocio, pero lo hacen con implicaciones muy diferentes en términos de flexibilidad, mantenimiento y escalabilidad, especialmente cuando estas estructuras están sujetas a cambios frecuentes:

Ventajas del formato padre-hijo

Mantener la estructura de una Cuenta de Resultados Analítica (y de otros estados financieros) no es un ejercicio puntual, sino un proceso continuo. Nuevos epígrafes y centros de responsabilidad, reclasificaciones, reorganizaciones y otros ajustes hacen que estas jerarquías estén en constante evolución. En este contexto, gestionar estas estructuras mediante una tabla en formato padre-hijo ofrece una serie de ventajas clave frente a las estructuras aplanadas con las que posteriormente tenemos que trabajar en Power BI.

Flexibilidad en la profundidad de la jerarquía

Una de las principales ventajas del formato padre-hijo es la flexibilidad total en cuanto a la profundidad de la jerarquía. El número de niveles no está definido por la estructura de la tabla, sino por la relación entre los registros.

Esto significa que la jerarquía puede crecer o modificarse sin necesidad de alterar el esquema de la tabla. Si es necesario añadir un nuevo nivel, por ejemplo, un subepígrafe adicional dentro de Gastos de Personal, basta con crear un nuevo registro y asignarle como padre el nodo correspondiente. No hay que añadir columnas, ni rediseñar el modelo, lo que convierte este enfoque en una solución naturalmente escalable.

En cambio, cuando se trabaja con estructuras aplanadas, cualquier cambio en el número de niveles implica modificar la estructura de la tabla, con el impacto que esto conlleva en procesos posteriores de carga, transformación y consumo del dato.

Almacenamiento más eficiente

El formato padre-hijo permite almacenar la información jerárquica de forma mucho más eficiente. Cada elemento se guarda una única vez, junto con la referencia a su padre, sin necesidad de repetir valores de niveles superiores en múltiples columnas.

Este enfoque elimina redundancias y simplifica la capa de almacenamiento y gestión, ya que lo único que se almacena es la relación entre los nodos del árbol. Además de reducir el volumen de datos, esto aporta una mayor claridad conceptual: la estructura jerárquica está implícita en los datos, no forzada por un diseño tabular rígido.

Facilidad de actualización y mantenimiento

Sin duda, la ventaja más relevante del formato padre-hijo en entornos de reporting económico-financiero es la simplicidad en la actualización y el mantenimiento de la estructura.

En una jerarquía padre-hijo, cambiar el padre de un nodo es suficiente para mover toda una rama completa del árbol. Esto incluye no solo el elemento en cuestión, sino todos los registros que dependen de él. En términos prácticos, reclasificar un centro de responsabilidad —o un conjunto completo de ellos— de un epígrafe a otro se convierte en una operación sencilla, controlada y con un impacto perfectamente definido.

Por el contrario, cuando se trabaja con estructuras aplanadas, este mismo cambio suele obligar a revisar y actualizar múltiples niveles de la jerarquía, propagando modificaciones hacia atrás hasta la raíz. En estructuras complejas, con muchos niveles, este proceso puede convertirse fácilmente en una fuente de errores y en un importante coste de mantenimiento.

Por todo ello, el formato padre-hijo resulta especialmente adecuado para gestionar estructuras jerárquicas de reporting analítico sujetas a cambios frecuentes, donde la agilidad y la facilidad de mantenimiento son tan importantes como la correcta representación de la información.

La reestructuración de los estados financieros en manos del negocio

Una vez que la estructura de un estado económico-financiero se almacena en formato padre-hijo, el verdadero cambio no está solo en cómo se representa la jerarquía, sino en quién controla los epígrafes y la asignación de cuentas contables (o centros de responsabilidad).

En el caso de los estados financieros oficiales, basta con indicar los primeros dígitos por los que comienzan las cuentas contables que deben incluirse en cada nodo final de la jerarquía, como podemos ver en la siguiente imagen. De este modo, todas las cuentas cuyo código comienza por esos dígitos quedan automáticamente asignadas al epígrafe correspondiente, lo que nos permite clasificar las cuentas de forma masiva:

Pulsar en la imagen para agrandar

En los estados financieros oficiales, como el Balance de Situación y la Cuenta de Resultados tradicional, las reestructuraciones son poco comunes (al fin y al cabo llevamos con el mismo Plan General Contable desde 2008).

Donde brillan realmente este tipo de tablas es en las Cuentas de Resultados Análiticas y en otros estados financieros que se diseñan de forma personalizada para una empresa en concreto, y en los cuales las reclasificaciones son muy habituales. Por ejemplo, en aquellas empresas donde las clasificaciones de una Cuenta de Resultados Analítica se realizan a nivel no solo de cuenta contable sino también del resto de dimensiones financieras (departamento, unidad etc…), igualmente podemos definir reglas que nos permitan clasificar masivamente los centros de responsabilidad en cada nodo. Un ejemplo de regla podría ser: si el departamento es MKT, la unidad es «cualquiera» y la cuenta empieza por 627, su epígrafe correspondiente será X.

Este planteamiento reduce drásticamente el esfuerzo de mantenimiento, ya que la incorporación de nuevas centros de coste/beneficio dentro de un rango existente no requiere de ningún ajuste adicional. De esta forma, la gestión y reestructuración de la Cuenta de Resultados pasa a ser una tarea puramente de negocio, alineada con la lógica contable y financiera de la organización. Los equipos de controlling pueden adaptar la estructura a nuevas necesidades de análisis de manera autónoma, mientras el modelo de reporting permanece estable y desacoplado de estos cambios.

Aunque en este artículo se muestra una implementación concreta en la que se utiliza Dataverse como capa de almacenamiento y una Model Driven App para la gestión, lo importante es el concepto: una jerarquía flexible, gobernada por el negocio, donde la asignación de cuentas o centros de responsabilidad contable se define por reglas de negocio, que puede ser mantenida directamente por los usuarios responsables de estas estructuras.

Del formato padre-hijo al formato plano: por qué necesitamos aplanar la jerarquía en Power BI

Hasta ahora hemos visto por qué tiene sentido almacenar y gestionar la estructura de una Cuenta de Resultados Analítica (o cualquier otro estado financiero) en formato padre-hijo. Es flexible, escalable y, sobre todo, permite que el negocio gobierne la jerarquía sin depender del equipo de IT.

Sin embargo, cuando llegamos a Power BI, nos encontramos con una limitación importante: el motor tabular no trabaja de forma nativa con estructuras padre-hijo.

El modelo necesita jerarquías explícitas, es decir, una columna por cada nivel. Para que el usuario pueda expandir y contraer epígrafes en una visualización, la estructura debe estar en formato plano. En otras palabras, debemos transformar el árbol en una tabla donde cada registro incluya no solo su nodo actual, sino también todos sus niveles superiores hasta la raíz. Este proceso es lo que conocemos como aplanar la jerarquía.

Dos formatos, dos propósitos

La clave es entender que no gestionamos y no consumimos la jerarquía en el mismo formato.

  • El formato padre-hijo es óptimo para mantenimiento y evolución.
  • El formato plano es necesario para el análisis en Power BI.

No son formatos excluyentes, sino representaciones distintas de la misma realidad, cada una optimizada para su propósito.

Por eso, el enfoque correcto consiste en mantener la estructura en formato padre-hijo en la capa de gestión, y aplanarla en el proceso de carga hacia Power BI. De este modo, conseguimos lo mejor de ambos mundos: flexibilidad para el negocio y estabilidad para el modelo semántico.

¿Y cómo aplanamos la jerarquía?

Siempre que sea posible, lo más recomendable es realizar esta transformación en el origen de datos o en una capa previa a la del modelo semántico. Ahora bien, no siempre tenemos acceso al origen o capacidad para modificarlo. En esos casos, podemos aplanar la jerarquía dentro del propio entorno de Power BI mediante uno de los siguientes enfoques:

  • En Power Query, utilizando el lenguaje M. Podemos encontrar funciones reutilizables e incluso scripts en C# para Tabular Editor que permiten recorrer estructuras padre-hijo y generar dinámicamente las columnas correspondientes a cada nivel, incluso cuando la profundidad de la jerarquía es variable.
  • En DAX, utilizando las funciones de la familia PATH (PATH, PATHITEM, PATHCONTAINS, etc.). Estas funciones permiten reconstruir la cadena jerárquica a partir de la relación entre los nodos y extraer cada nivel en columnas calculadas. Es una solución válida y muy flexible, especialmente cuando necesitamos trabajar directamente dentro del modelo.

En cualquiera de los casos, el propósito es el mismo: disponer de una jerarquía aplanada, estructurada por niveles y optimizada para el análisis en Power BI, con el objetivo de poder presentar al usuario los estados financieros a cualquier nivel de granularidad:

Conclusión

Las estructuras jerárquicas en el reporting económico-financiero no son estáticas. Cambian porque cambian los criterios de análisis, cambia la organización y cambia la forma en la que la dirección necesita analizar la información, y cada vez a mayor velocidad.

Intentar gestionar esa realidad dinámica con estructuras rígidas termina generando fricción: más dependencias técnicas, más mantenimiento y menos agilidad para el negocio.

El uso de tablas padre-hijo en la capa de almacenamiento y gestión nos permite desacoplar la evolución de estas estructuras del modelo analítico. El negocio puede crear nuevos centros de responsabilidad, reorganizar, reclasificar o crear nuevos epígrafes sin comprometer la estabilidad del modelo en Power BI. Y, cuando llega el momento del análisis, simplemente proyectamos esa misma realidad en un formato plano adaptado al motor tabular.

No se trata de una cuestión técnica aislada. Es una decisión consciente sobre dónde gestionar la complejidad y cómo repartir responsabilidades entre negocio y tecnología. Que la jerarquía se gobierne en el formato en el que debe gobernarse y se consuma en el formato en el que debe consumirse.

Porque, al final, no se trata solo de generar modelos e informes, sino de diseñar una arquitectura que permita que el modelo evolucione al mismo ritmo que el negocio.