Introducción a los parámetros de campo

Los superhéroes de UI/UX

Empezamos con una reflexión y mi humilde opinión.

Siento que el concepto de informe está en plena evolución constante. Tradicionalmente, un informe era poco más que una hoja con una o varias tablas. Sin embargo, en los últimos años, el concepto de “report” ha cambiado: ahora hablamos de paneles y dashboards más visuales, y analíticos. Esta evolución va un paso más allá con la aparición de informes que se comportan casi como aplicaciones, permitiendo no solo explorar datos, sino también interactuar con ellos de formas cada vez más complejas. ¿El futuro? Ya podemos empezar a vislumbrarlo: informes que permiten desencadenar acciones directamente desde la interfaz con Power automate. Nuevas funcionalidades de Fabric como el write back entre otras.

Los parámetros de campo es una funcionalidad que ayuda mucho en este aspecto de la interacción del usuario y el informe.

Muchas veces se quiere explotar una misma métrica por cada «dimensión» que tenemos a mano. Imaginemos que queremos ver un informe de las puntuaciones de calidad de nuestra empresa. Las querremos ver por periodos, por trabajadores, por clientes y de maneras diferentes, por periodos, anualidades…

Hoy os traigo un ejemplo de tres maneras diferentes de explotar esta funcionalidad.

Agrupar medidas

Muchas veces tenemos el espacio justo para poner una grafica y una medida. Pero es una pena tener que cambiar de pagina para poder evaluar otra métrica dentro del contexto de la misma pagina. En este caso, del informe de calidad, hay veces en el que me interesa ver el recuento de valoraciones, la puntuación promedio de estas, o simplemente cuantas valoraciones tienen menos de un 5 puntuado.

El código DAX para estas métricas es relativamente sencillo:

Valoraciones = COUNTROWS('Valoraciones tecnicos')

Puntuacion AVG = AVERAGE('Valoraciones tecnicos'[Puntuacion])

Valoraciones < 5 = CALCULATE( [Valoraciones] , 'Valoraciones tecnicos'[Puntuacion] < 5 )

% PT < 5 = DIVIDE( [Valoraciones < 5] , [Valoraciones] )

Ahora viene la debacle. Le comunicas al cliente que tienes la métricas y te contesta que quiere verlo todo, o almenos poder verlo cuando le apetezca.

En mis inicios en Power BI yo habria echo 3 visuales, una encima de otra con bookmarks y crear una navegación por marcadores condicionando la visibilidad de cada visual.

Mi yo de ahora seguramente reaccionaria de esta manera:

A ver, hacía lo que podía en ese entonces, sin embargo, los parametros de campo en esta situación brillan.

Seleccionando en la pestaña de Modeling > New Parameter > Field se abrirá un asistente para definir un nuevo parámetro. Dándole nombre y seleccionando los campos que queramos, en este caso las medidas creadas por DAX.

Esto nos generara una nueva ¿Tabla calculada? Bueno, así es como Power BI juega con los parámetro de campo. Si queremos editar los valores de este, tendremos que pelearnos con DAX. Yo por ejemplo, seleccionando esas 3 métricas se me ha generado lo siguiente:

Metricas valoraciones = {
    ("Puntuaciones", NAMEOF('Valoraciones tecnicos'[Puntuacion AVG]), 0),
    ("Valoraciones", NAMEOF('Valoraciones tecnicos'[Valoraciones]), 1),
    ("Valoraciones < 5", NAMEOF('Valoraciones tecnicos'[Valoraciones < 5]), 2)
}

¿Sencillo no? Un pequeño detalle bastante chulo, es que los parámetros de campo permiten redefinir los nombres. Si os fijáis la medida de puntuaciones se llamaba Puntuación AVG, en el parámetro de campo lo he llamado Puntuaciones. NAMEOF() es la función de DAX que referencia a los campos. Finalmente el 0,1,2 es el orden que se usa para ordenar las filas.

Añadir medidas o campos aquí es tan fácil como poner una coma al final, y el siguiente fragmento:

"Nombre", NAMEOF('Tabla'[Campo] // o [Medida] ), Orden) 

Una vez creado el parámetro, Power BI, por la cara, nos crea en medio del informe un segmentador con los parámetros de campo. Imagino que ya vais oliendo por donde va el tiro. Si este segmentador lo formateamos como que solo pueda tener un valor único, y este mismo parámetro lo ponemos en uno de los ejes de una visual, esto hace que el usuario pueda cambiar la métrica en función lo que quiera ver en ese momento. Vamos, que ya podemos dejar atrás la broma de los bookmarks, esto es mil veces mas sencillo, sin mantenimiento apenas y rápido. Siempre y cuando nos valga el mismo tipo de grafico.

En mi informe de calidad veréis que lo he hecho con el primer gráfico, jugando con el título y el divisor, puedo complementar con un slicer a la derecha dando la sensación de que la visual en si es toda una.

Seleccionar dimensiones

Otra de las cosas que suele pasar, es querer ver unas métricas, por una dimensión o otra de las que rodean nuestra tabla de echos. Siguiendo el mismo proceso que para las métricas (Modeling > New Parameter > Field), seleccionando ahora campos de nuestro modelo, se puede crear un parámetro para seleccionar dimensiones como el Cliente, o el Técnico. Igual que antes, poniendo este parámetro en las filas de una tabla podemos hablitar que el usuario pueda cambiar entre la representación que mas le apetezca.

A continuación del grafico podéis ver esta implementación.

Seleccionar dimensiones 2.0

Se puede explotar esta funcionalidad de muchísimas maneras, juntando las dos anteriores, podéis hacer que un usuario pueda montarse sus gráficos/tablas seleccionando dos parámetros a la vez. En base a las selecciones echas, poner subtítulos dinámicos, mil viguerías vamos.

Para poner la guinda al pastel. Os explicaré una aplicación real de un cliente, que gracias a la ayuda del grupo de PUG Barcelona, saqué adelante con parámetros de campo.

Os pongo en situación.

Mira, a mi me vienen a hacer auditorias de calidad aleatoriamente durante el año. A veces es enero, otras abril, junio, octubre… Y claro, necesito implementar unos periodos fiscales dinámicos para sacar las métricas. Es decir, si vienen en octubre, necesito las métricas de setiembre-octubre de todos los años para poder mostrar las comparativas al periodo actual.

Mi cabeza en ese momento empezó a echar humo, porque si, puedes hacer un calendario con una fiscalidad alternativa a lo natural (enero-diciembre), por Power Query/DAX. Pero que el propio usuario final, elija las fechas y que todo se «recalcule» me pareció una barbaridad.

Empecé a valorar opciones, por ejemplo: un parámetro por PowerQuery, que cambiándolo en Power BI Service, al actualizar el modelo cambiase la tabla calendario.

Pero no, tenia que ser en la propia interfaz del informe.

Fua, pensé

Oscar exasperado

Aqui Bernat Duran tuvo una idea brillante.

– Oye si quieres todas las posibles fiscalidades, pon las 12 en la tabla calendario.

Mi cabeza ahí se iluminó: -déjate de tonterías de cálculos dinámicos de parámetros… Ponlas ahí todas a cascoporro, y con un parámetro de campo que el cliente se seleccione la que quiera.

Bien, pues con la idea en mente, sabia lo que tenia que hacer, 12 columnas, identificando los periodos por fiscalidades posibles. Si lo pensamos con un ejemplo es más fácil de digerir.

Supongamos un listado de fechas que va del 01-01-2024 al 31-12-2024. Si nuestro periodo fiscal empieza en abril (01-04-2024), las fechas del 01-01-2024 al 30-03-2024 pertenecen al año fiscal 2023-2024 y el resto al 2024-2025.

Primero hice pruebas a lo bruto y luego lo empaqueté todo bonito y automático en una función de Power Query llamada fxPeriodoFiscal:

(date as date, mesInicio as number) as text =>
let
    año = Date.Year(date),
    mes = Date.Month(date),
    inicioAño = if mes >= mesInicio then año else año - 1,
    finAño = inicioAño + 1,
    periodo = if mesInicio = 1 then Text.From(año) else Text.From(inicioAño) & "-" & Text.From(finAño)
in
    periodo

Entrada: La función recibe dos parámetros:

• date: una fecha.
• mesInicio: un número que representa el mes en que empieza el año fiscal o período (por ejemplo, 4 si el año comienza en abril).

Extrae el año de la fecha recibida (año = Date.Year(date)).

Extrae el mes de la fecha (mes = Date.Month(date)).

Determina el año de inicio del período:

• Si el mes actual (mes) es mayor o igual al mes de inicio (mesInicio), el año de inicio es el mismo que el año de la fecha.
• Si no, el año de inicio es el año anterior.

Calcula el año de fin del período sumando 1 al año de inicio.

Devuelve el texto del período:

• Si el año empieza en enero (mesInicio = 1), solo devuelve el año ("2025"), es la nomenclatura natural que tenemos.
• Si no, devuelve un rango con el año de inicio y fin, por ejemplo: "2024-2025".

A continuación simplemente definí en mi script de Power Query, la lista de periodos y aplique la función fxPeriodoFiscal:

    // 19. Definir lista de periodos fiscales.
    ListaPeriodos = {
        {1,  "Año natural"},
        {2,  "feb-ene"},
        {3,  "mar-feb"},
        {4,  "abr-mar"},
        {5,  "may-abr"},
        {6,  "jun-may"},
        {7,  "jul-jun"},
        {8,  "ago-jul"},
        {9,  "sep-ago"},
        {10, "oct-sep"},
        {11, "nov-oct"},
        {12, "dic-nov"}
    },

    // 20. Añadir columnas usando la función fxPeriodoFiscal.
    AñadirPeriodosFiscales = List.Accumulate(
        ListaPeriodos,
        AñadirAñoISO,
        (estado, elemento) =>
            let
                mesInicio = elemento{0},
                nombreColumna = elemento{1},
                nuevaTabla = Table.AddColumn(
                    estado,
                    nombreColumna,
                    each fxPeriodoFiscal([Fecha], mesInicio),
                    type text
                )
            in
                nuevaTabla
    )
in
    AñadirPeriodosFiscales

Perfecto, estaba cada vez más cerca de lograr lo que me proponía. Cuando cargué el calendario con mis 12 columnas, cree el parámetro de campo, y Power BI me troleo. Había puesto mi segmentador de periodos, una tabla con el periodo seleccionado, y para mi sorpresa todo funcionó correctamente. Demasiado bien, estaba viendo en las filas el periodo seleccionado, no sus valores.

El programa decidió tomarme el pelo. Se suponía que esto no iba a pasar, sino que me iba a mostrar los valores de mi selección. Anteriormente lo hice con clientes y técnicos, y me puso los valores de cada campo. ¿Por qué aquí se comportaba diferente?

No lo sé, pero por suerte hay solución para todo. Haciendo click derecho en el valor del campo, en el panel de creación de visuales. Hay una opción, bien escondida, llamada show values of the selected field, o show the selected field. Dependiendo del modo en el que Power BI haya decidido mostrarte esto puede hacerlo en un modo u otro. Finalmente, conseguimos lo que buscábamos. Seleccionar en la cabecera del informe el periodo fiscal y dinamizar los cálculos por estos periodos.

Bonus track: la ordenación de estos periodos

Por si fuera dramática esta odisea, apareció un regalo de última hora.

Si mi periodo fiscal empieza en abril, el primer mes que me debería salir listado es abril, no enero (del siguiente año).

Ahí si que me pillaron pero bien. Empecé a montar mis cábalas buscando por internet dynamic column sorting y cosas esotéricas de Power BI. Pero la verdad, desde un principio tenia pocas expectativas. La ordenación de una columna en un modelo no puede depender de un parámetro de campo, y en ese momento valoré que el montaje para conseguirlo (si fuera posible) se escapaba a mis recursos, conocimientos y tiempo, pues el proyecto se estimaba como 10h max y estabamos en el tiempo de descuento. Para este rompecabezas se propusieron dos soluciones bastante elegantes.

Jerarquia Periodo-Año-Mes

La primera propuesta fué la más directa. Los periodos son multianuales. Tiene sentido jerarquizar el año dentro del periodo para una segmentación más clara. Esto, en un grafico de barras queda muy bien representado.

Usando la columna de inicio de mes

Estas columnas son superútiles. Te permiten mantener un formato de eje continuo porque internamente son columnas con el formato de fecha. Diferentes fechas como: 06/04/2025, 12/04/2025, 28/04/2025 se agrupan en el 01/04/2025. No continuaré, porque este tema se va muy allá del propósito de este post… Algun día hablaré de ello.

Al ser columnas de fecha las formatee de la siguiente manera: yyyy-mm, como 2025-04. El downside de esto es que no es del todo dinámico. El gráfico, al cambiar de fiscalidad, se colapsa un nivel a la granularidad del periodo. En cambio, en el método anterior no. Estas fechas, al ordenarse por si mismas, siempre seguirán el orden natural del tiempo.

Bueno, hasta aquí llega este post. Espero que os haya gustado. Si no usabais esta funcionalidad, podéis trastear un poco el informe de calidad y probar todo lo que os he explicado.