{"id":2236,"date":"2026-02-03T08:39:00","date_gmt":"2026-02-03T07:39:00","guid":{"rendered":"https:\/\/bicontrolling.com\/?p=2236"},"modified":"2026-03-03T09:23:32","modified_gmt":"2026-03-03T08:23:32","slug":"las-tablas-padre-hijo-y-el-reporting-economico-financiero","status":"publish","type":"post","link":"https:\/\/bicontrolling.com\/index.php\/2026\/02\/03\/las-tablas-padre-hijo-y-el-reporting-economico-financiero\/","title":{"rendered":"Las tablas padre-hijo y el reporting econ\u00f3mico-financiero en Power BI"},"content":{"rendered":"\n

Introducci\u00f3n<\/h2>\n\n\n\n

En el \u00e1mbito del reporting econ\u00f3mico-financiero hay algo incuestionable: las estructuras nunca son definitivas<\/strong>. Las organizaciones evolucionan, cambian los criterios de an\u00e1lisis y aparecen nuevas necesidades de informaci\u00f3n que obligan a revisar continuamente la forma en que se presentan los estados financieros.<\/p>\n\n\n\n

Esta situaci\u00f3n se hace especialmente evidente en la gesti\u00f3n de las estructuras jer\u00e1rquicas que soportan estados financieros anal\u00edticos<\/strong>, como la Cuenta de Resultados Anal\u00edtica. Ep\u00edgrafes, subep\u00edgrafes y centros de responsabilidad forman jerarqu\u00edas complejas que deben ser coherentes y f\u00e1ciles de mantener y evolucionar<\/strong>. Cuando estos cambios requieren intervenci\u00f3n t\u00e9cnica o ajustes costosos (en tiempo y dinero), el reporting deja de acompa\u00f1ar al negocio y se convierte en una limitaci\u00f3n.<\/p>\n\n\n\n

Antes de continuar, cuando en este art\u00edculo 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<\/strong> que no tiene por qu\u00e9 estar definida formalmente y que en la pr\u00e1ctica corresponden a las combinaciones que existen entre las cuentas contables y las dimensiones anal\u00edticas definidas en una organizaci\u00f3n, como pueden ser el departamento, el \u00e1rea, el equipo etc\u2026<\/p>\n\n\n\n

En este contexto de las estructuras de los estados financieros, las tablas padre-hijo<\/strong> ofrecen un enfoque especialmente adecuado. Permiten almacenar y gestionar jerarqu\u00edas de profundidad variable sin alterar la estructura f\u00edsica de los datos<\/strong>, facilitando una gesti\u00f3n flexible y escalable de las estructuras de reporting financiero.<\/p>\n\n\n\n

A lo largo de este art\u00edculo veremos qu\u00e9 son las tablas padre-hijo, por qu\u00e9 encajan de forma natural con el reporting econ\u00f3mico-financiero y c\u00f3mo, combinadas con Dataverse y una model-driven Power App (o cualquier otro sistema en el que podamos crear la aplicaci\u00f3n), permiten trasladar al usuario de negocio la responsabilidad y la autonom\u00eda<\/strong> para mantener y adaptar estas estructuras. Porque en los departamentos de finanzas y controlling, el cambio no es la excepci\u00f3n, sino la norma<\/strong>.<\/p>\n\n\n\n\n\n\n\n

\u00bfQu\u00e9 es una tabla padre-hijo?<\/h2>\n\n\n\n

Una tabla padre-hijo es un tipo de estructura de datos especialmente \u00fatil cuando trabajamos con informaci\u00f3n que se organiza de forma natural en jerarqu\u00edas<\/strong>. Es decir, cuando los datos no responden a una relaci\u00f3n plana, sino a un esquema en forma de \u00e1rbol, donde cada elemento puede depender de otro y, a su vez, tener elementos dependientes.<\/p>\n\n\n\n

Este tipo de estructuras es muy habitual en sistemas transaccionales. Algunos ejemplos cl\u00e1sicos son los organigramas empresariales<\/strong>, donde cada empleado tiene un supervisor, o las clasificaciones de productos<\/strong>, organizadas en categor\u00edas, subcategor\u00edas, familias, etc. En todos estos casos, un mismo nodo puede actuar simult\u00e1neamente como hijo de un nivel superior y como padre de otros niveles inferiores:<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

Desde el punto de vista de la arquitectura, una tabla padre-hijo se caracteriza por tener una referencia a s\u00ed misma<\/strong>. Cada registro dispone de un identificador propio y de un campo adicional que almacena el identificador de su \u201cpadre\u201d, es decir, del nodo inmediatamente superior dentro de la jerarqu\u00eda. Los registros que no tienen padre constituyen la ra\u00edz, o ra\u00edces, del \u00e1rbol.<\/p>\n\n\n\n

Este enfoque permite representar jerarqu\u00edas de cualquier profundidad con una estructura de tabla muy simple y estable. No es necesario definir de antemano cu\u00e1ntos niveles va a tener la jerarqu\u00eda, ni crear una columna por cada uno de ellos. La relaci\u00f3n entre los nodos es la que define la estructura<\/strong>, no el n\u00famero de campos de la tabla.<\/p>\n\n\n\n

En la siguiente imagen se muestra la misma jerarqu\u00eda representada de dos formas distintas<\/strong>. A la izquierda, en formato padre-hijo<\/strong>, cada registro almacena \u00fanicamente su identificador y la referencia a su nodo padre, siendo la relaci\u00f3n entre los elementos la que define la estructura jer\u00e1rquica. A la derecha, la misma informaci\u00f3n aparece en formato plano<\/strong>, desplegada en columnas que representan expl\u00edcitamente cada uno de los niveles de la jerarqu\u00eda.<\/p>\n\n\n\n

Ambos enfoques describen exactamente la misma realidad desde el punto de vista del negocio, pero lo hacen con implicaciones muy diferentes en t\u00e9rminos de flexibilidad, mantenimiento y escalabilidad<\/strong>, especialmente cuando estas estructuras est\u00e1n sujetas a cambios frecuentes:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Ventajas del formato padre-hijo<\/h2>\n\n\n\n

Mantener la estructura de una Cuenta de Resultados Anal\u00edtica (y de otros estados financieros) no es un ejercicio puntual, sino un proceso continuo<\/strong>. Nuevos ep\u00edgrafes y centros de responsabilidad, reclasificaciones, reorganizaciones y otros ajustes hacen que estas jerarqu\u00edas est\u00e9n en constante evoluci\u00f3n. En este contexto, gestionar estas estructuras mediante una tabla en formato padre-hijo ofrece una serie de ventajas clave<\/strong> frente a las estructuras aplanadas con las que posteriormente tenemos que trabajar en Power BI.<\/p>\n\n\n\n

Flexibilidad en la profundidad de la jerarqu\u00eda
<\/h4>\n\n\n\n

Una de las principales ventajas del formato padre-hijo es la flexibilidad total en cuanto a la profundidad de la jerarqu\u00eda<\/strong>. El n\u00famero de niveles no est\u00e1 definido por la estructura de la tabla, sino por la relaci\u00f3n entre los registros.<\/p>\n\n\n\n

Esto significa que la jerarqu\u00eda puede crecer o modificarse sin necesidad de alterar el esquema de la tabla. Si es necesario a\u00f1adir un nuevo nivel, por ejemplo, un subep\u00edgrafe adicional dentro de Gastos de Personal<\/em>, basta con crear un nuevo registro y asignarle como padre el nodo correspondiente. No hay que a\u00f1adir columnas, ni redise\u00f1ar el modelo<\/strong>, lo que convierte este enfoque en una soluci\u00f3n naturalmente escalable.<\/p>\n\n\n\n

En cambio, cuando se trabaja con estructuras aplanadas, cualquier cambio en el n\u00famero de niveles implica modificar la estructura de la tabla, con el impacto que esto conlleva en procesos posteriores de carga, transformaci\u00f3n y consumo del dato.<\/p>\n\n\n\n

Almacenamiento m\u00e1s eficiente<\/h4>\n\n\n\n

El formato padre-hijo permite almacenar la informaci\u00f3n jer\u00e1rquica de forma mucho m\u00e1s eficiente<\/strong>. Cada elemento se guarda una \u00fanica vez, junto con la referencia a su padre, sin necesidad de repetir valores de niveles superiores en m\u00faltiples columnas.<\/p>\n\n\n\n

Este enfoque elimina redundancias y simplifica la capa de almacenamiento y gesti\u00f3n<\/strong>, ya que lo \u00fanico que se almacena es la relaci\u00f3n entre los nodos del \u00e1rbol. Adem\u00e1s de reducir el volumen de datos, esto aporta una mayor claridad conceptual: la estructura jer\u00e1rquica est\u00e1 impl\u00edcita en los datos, no forzada por un dise\u00f1o tabular r\u00edgido.<\/p>\n\n\n\n

Facilidad de actualizaci\u00f3n y mantenimiento<\/h4>\n\n\n\n

Sin duda, la ventaja m\u00e1s relevante del formato padre-hijo en entornos de reporting econ\u00f3mico-financiero es la simplicidad en la actualizaci\u00f3n y el mantenimiento<\/strong> de la estructura.<\/p>\n\n\n\n

En una jerarqu\u00eda padre-hijo, cambiar el padre de un nodo es suficiente para mover toda una rama completa del \u00e1rbol<\/strong>. Esto incluye no solo el elemento en cuesti\u00f3n, sino todos los registros que dependen de \u00e9l. En t\u00e9rminos pr\u00e1cticos, reclasificar un centro de responsabilidad \u2014o un conjunto completo de ellos\u2014 de un ep\u00edgrafe a otro se convierte en una operaci\u00f3n sencilla, controlada y con un impacto perfectamente definido.<\/p>\n\n\n\n

Por el contrario, cuando se trabaja con estructuras aplanadas, este mismo cambio suele obligar a revisar y actualizar m\u00faltiples niveles de la jerarqu\u00eda, propagando modificaciones hacia atr\u00e1s hasta la ra\u00edz. En estructuras complejas, con muchos niveles, este proceso puede convertirse f\u00e1cilmente en una fuente de errores y en un importante coste de mantenimiento.<\/strong><\/p>\n\n\n\n

Por todo ello, el formato padre-hijo resulta especialmente adecuado para gestionar estructuras jer\u00e1rquicas de reporting anal\u00edtico sujetas a cambios frecuentes<\/strong>, donde la agilidad y la facilidad de mantenimiento son tan importantes como la correcta representaci\u00f3n de la informaci\u00f3n.<\/p>\n\n\n\n

La reestructuraci\u00f3n de los estados financieros en manos del negocio<\/h2>\n\n\n\n

Una vez que la estructura de un estado econ\u00f3mico-financiero se almacena en formato padre-hijo, el verdadero cambio no est\u00e1 solo en c\u00f3mo se representa la jerarqu\u00eda, sino en qui\u00e9n controla los ep\u00edgrafes y la asignaci\u00f3n de cuentas contables (o centros de responsabilidad)<\/strong>.<\/p>\n\n\n\n

En el caso de los estados financieros oficiales, basta con indicar los primeros d\u00edgitos por los que comienzan las cuentas contables<\/strong> que deben incluirse en cada nodo final de la jerarqu\u00eda, como podemos ver en la siguiente imagen. De este modo, todas las cuentas cuyo c\u00f3digo comienza por esos d\u00edgitos quedan autom\u00e1ticamente asignadas al ep\u00edgrafe correspondiente, lo que nos permite clasificar las cuentas de forma masiva:<\/p>\n\n\n\n

\"\"<\/a>
Pulsar en la imagen para agrandar<\/em><\/figcaption><\/figure>\n\n\n\n
<\/div>\n\n\n\n

En los estados financieros oficiales, como el Balance de Situaci\u00f3n 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).<\/p>\n\n\n\n

Donde brillan realmente este tipo de tablas es en las Cuentas de Resultados An\u00e1liticas y en otros estados financieros que se dise\u00f1an de forma personalizada para una empresa en concreto, y en los cuales las reclasificaciones son muy habituales.<\/strong> Por ejemplo, en aquellas empresas donde las clasificaciones de una Cuenta de Resultados Anal\u00edtica se realizan a nivel no solo de cuenta contable sino tambi\u00e9n 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\u00eda ser: si el departamento es MKT<\/em>, la unidad es \u00abcualquiera<\/em>\u00bb y la cuenta empieza por 627<\/em>, su ep\u00edgrafe correspondiente ser\u00e1 X.<\/p>\n\n\n\n

Este planteamiento reduce dr\u00e1sticamente el esfuerzo de mantenimiento<\/strong>, ya que la incorporaci\u00f3n de nuevas centros de coste\/beneficio dentro de un rango existente no requiere de ning\u00fan ajuste adicional. De esta forma, la gesti\u00f3n y reestructuraci\u00f3n de la Cuenta de Resultados pasa a ser una tarea puramente de negocio<\/strong>, alineada con la l\u00f3gica contable y financiera de la organizaci\u00f3n. Los equipos de controlling pueden adaptar la estructura a nuevas necesidades de an\u00e1lisis de manera aut\u00f3noma, mientras el modelo de reporting permanece estable y desacoplado de estos cambios.<\/p>\n\n\n\n

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

Del formato padre-hijo al formato plano: por qu\u00e9 necesitamos aplanar la jerarqu\u00eda en Power BI<\/h2>\n\n\n\n

Hasta ahora hemos visto por qu\u00e9 tiene sentido almacenar y gestionar la estructura de una Cuenta de Resultados Anal\u00edtica (o cualquier otro estado financiero) en formato padre-hijo<\/strong>. Es flexible, escalable y, sobre todo, permite que el negocio gobierne la jerarqu\u00eda<\/strong> sin depender del equipo de IT.<\/p>\n\n\n\n

Sin embargo, cuando llegamos a Power BI<\/strong>, nos encontramos con una limitaci\u00f3n importante: el motor tabular no trabaja de forma nativa con estructuras padre-hijo<\/strong>.<\/p>\n\n\n\n

El modelo necesita jerarqu\u00edas expl\u00edcitas<\/strong>, es decir, una columna por cada nivel<\/strong>. Para que el usuario pueda expandir y contraer ep\u00edgrafes en una visualizaci\u00f3n, la estructura debe estar en formato plano. En otras palabras, debemos transformar el \u00e1rbol en una tabla donde cada registro incluya no solo su nodo actual, sino tambi\u00e9n todos sus niveles superiores hasta la ra\u00edz. Este proceso es lo que conocemos como aplanar la jerarqu\u00eda<\/strong>.<\/p>\n\n\n\n

Dos formatos, dos prop\u00f3sitos<\/h3>\n\n\n\n

La clave es entender que no gestionamos y no consumimos la jerarqu\u00eda en el mismo formato<\/strong>.<\/p>\n\n\n\n

    \n
  • El formato padre-hijo<\/strong> es \u00f3ptimo para mantenimiento y evoluci\u00f3n<\/strong>.<\/li>\n\n\n\n
  • El formato plano<\/strong> es necesario para el an\u00e1lisis en Power BI<\/strong>.<\/li>\n<\/ul>\n\n\n\n

    No son formatos excluyentes, sino representaciones distintas de la misma realidad, cada una optimizada para su prop\u00f3sito.<\/p>\n\n\n\n

    Por eso, el enfoque correcto consiste en mantener la estructura en formato padre-hijo en la capa de gesti\u00f3n<\/strong>, y aplanarla en el proceso de carga hacia Power BI<\/strong>. De este modo, conseguimos lo mejor de ambos mundos: flexibilidad para el negocio<\/strong> y estabilidad para el modelo sem\u00e1ntico<\/strong>.<\/p>\n\n\n\n

    \u00bfY c\u00f3mo aplanamos la jerarqu\u00eda?<\/h3>\n\n\n\n

    Siempre que sea posible, lo m\u00e1s recomendable es realizar esta transformaci\u00f3n en el origen de datos<\/strong> o en una capa previa a la del modelo sem\u00e1ntico. Ahora bien, no siempre tenemos acceso al origen o capacidad para modificarlo. En esos casos, podemos aplanar la jerarqu\u00eda dentro del propio entorno de Power BI mediante uno de los siguientes enfoques:<\/p>\n\n\n\n

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

        En cualquiera de los casos, el prop\u00f3sito es el mismo: disponer de una jerarqu\u00eda aplanada, estructurada por niveles y optimizada para el an\u00e1lisis en Power BI<\/strong>, con el objetivo de poder presentar al usuario los estados financieros a cualquier nivel de granularidad:<\/p>\n\n\n\n

        \"\"<\/figure>\n\n\n\n

        Conclusi\u00f3n<\/h2>\n\n\n\n

        Las estructuras jer\u00e1rquicas en el reporting econ\u00f3mico-financiero<\/strong> no son est\u00e1ticas. Cambian porque cambian los criterios de an\u00e1lisis, cambia la organizaci\u00f3n y cambia la forma en la que la direcci\u00f3n necesita analizar la informaci\u00f3n, y cada vez a mayor velocidad.<\/p>\n\n\n\n

        Intentar gestionar esa realidad din\u00e1mica con estructuras r\u00edgidas termina generando fricci\u00f3n: m\u00e1s dependencias t\u00e9cnicas, m\u00e1s mantenimiento y menos agilidad para el negocio.<\/p>\n\n\n\n

        El uso de tablas padre-hijo<\/strong> en la capa de almacenamiento y gesti\u00f3n nos permite desacoplar la evoluci\u00f3n de estas estructuras del modelo anal\u00edtico. El negocio puede crear nuevos centros de responsabilidad, reorganizar, reclasificar o crear nuevos ep\u00edgrafes sin comprometer la estabilidad del modelo en Power BI. Y, cuando llega el momento del an\u00e1lisis, simplemente proyectamos esa misma realidad en un formato plano adaptado al motor tabular.<\/p>\n\n\n\n

        No se trata de una cuesti\u00f3n t\u00e9cnica aislada. Es una decisi\u00f3n consciente sobre d\u00f3nde gestionar la complejidad y c\u00f3mo repartir responsabilidades<\/strong> entre negocio y tecnolog\u00eda. Que la jerarqu\u00eda se gobierne en el formato en el que debe gobernarse y se consuma en el formato en el que debe consumirse.<\/p>\n\n\n\n

        Porque, al final, no se trata solo de generar modelos e informes, sino de dise\u00f1ar una arquitectura que permita que el modelo evolucione al mismo ritmo que el negocio.<\/strong>
        <\/p>\n","protected":false},"excerpt":{"rendered":"

        Introducci\u00f3n En el \u00e1mbito del reporting econ\u00f3mico-financiero hay algo incuestionable: las estructuras nunca son definitivas. Las organizaciones evolucionan, cambian los criterios de an\u00e1lisis y aparecen nuevas necesidades de informaci\u00f3n que obligan a revisar continuamente la forma en que se presentan los estados financieros. Esta situaci\u00f3n se hace especialmente evidente en la gesti\u00f3n de las estructuras […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[2,3,4,6],"tags":[27,72,9,10,29,11,12,31,71,14,18],"post_series":[],"class_list":["post-2236","post","type-post","status-publish","format-standard","hentry","category-arquitectura-de-datos","category-controlling-dir-financiera","category-dax-power-pivot","category-m-power-query","tag-bi","tag-dataverse","tag-dax","tag-editor-de-consultas","tag-etl","tag-inteligencia-de-negocios","tag-m","tag-modelado-de-datos","tag-power-apps","tag-power-bi","tag-power-query"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t