Introducción
Después de la euforia inicial con la nueva inteligencia temporal basada en calendario, comencé a profundizar en la nueva función para ver qué significan estas nuevas posibilidades en el mundo real.
Encontrará varios enlaces al respecto en la sección Referencias al final de este artículo, incluido un artículo de SQLBI, que profundiza en el tema.
Recomiendo encarecidamente leer estos artículos para obtener una buena comprensión.
Pero con el tiempo, me di cuenta de que esta nueva y brillante característica tiene lados más oscuros.
Ahora les mostraré cuatro ejemplos, donde descubrí efectos interesantes.
Ofreceré soluciones alternativas a cada problema cuando sea posible.
Configuración de los calendarios
Para este artículo, utilicé dos informes de Power BI con dos tablas de fechas cada uno para evitar interferencias. Todas las tablas de fechas tienen la misma tabla fuente.
Aquí se describe una posible interferencia entre calendarios.
Para el calendario gregoriano, utilicé esta configuración:
Para el calendario semanal, utilicé esta configuración:
El calendario semanal incluye la columna YearOfWeek para la categoría de año.
Esta columna contiene el año alineado por semana, que es necesario para dicho calendario. Esta columna se basa en la definición de semana ISO. Cada año comienza el lunes de la semana 1.
Puede encontrar una explicación para la semana ISO aquí.
Ambos modelos de datos de Power BI usaron la misma configuración.
Meses anteriores y diferentes duraciones de meses
Bien, primero, veamos meses con diferentes duraciones.
Describo este caso para hacerles conscientes de las diferencias con la lógica clásica de la inteligencia del tiempo.
Creé dos medidas:
Ventas en línea (PM) = CALCULAR([Online Sales]
,FECHAADD(‘Fecha'[Date]-1, MES) )
Y este usa el calendario gregoriano:
Ventas en línea (PY Gregoriano) = CALCULAR([Online Sales]
,DATEADD(‘Calendario Gregoriano’, -1, AÑO) )
Agregué ambos a un objeto visual de tabla.
Ahora mire las diferencias entre estas dos medidas para marzo:
Si bien este resultado es muy interesante, mira este:
En ambos casos el resultado es muy diferente.
Mientras que la medida que utiliza inteligencia temporal clásica arroja el mismo valor para los últimos tres días de marzo, los resultados de febrero omiten los últimos días de enero.
La medida basada en Calendario funciona mucho mejor.
El punto crucial aquí es que las sumas de las filas sean iguales a la suma que se muestra en la fila Total.
Además, la función DATEADD() ahora tiene dos parámetros adicionales que afectan los resultados de meses con duraciones desiguales.
Si bien no es extraño, definitivamente es un comportamiento diferente de la función, que debes tener en cuenta. Esto se aplica en todas partes cuando los períodos no tienen la misma duración. Volveré sobre esto más tarde.
¿Qué pasa con el año anterior?
Ahora viene la primera situación extraña.
Observe la siguiente tabla usando una medida con una llamada DATEADD() usando el calendario gregoriano para PY:
Como puedes ver, todo parece estar bien.
Ahora mire los resultados, al comparar 2024 con 2025:
Como puede ver, los valores PY para marzo de 2025 se desplazan 1 día.
Esto no es correcto.
Peor aún, al comparar los valores totales de los meses, son iguales entre 2024 y la medida del año anual en 2025.
Este efecto es observable hasta diciembre, donde los resultados son estos:
Este es el mismo efecto que podemos observar en la medida del mes anterior que se mostró anteriormente, ya que estos dos años no tienen la misma duración.
Este efecto extraño se debe a cómo DAX calcula los resultados según la jerarquía del calendario.
El mecanismo se llama “Distancia desde el padre”.
Pero el Padre está definido por el tercer parámetro de DATEADD(): Año
Por lo tanto, DATEADD() calcula la distancia desde el comienzo del año y devuelve el resultado utilizando la misma distancia del año anterior.
Una solución a este problema es garantizar que todos los meses tengan la misma duración.
En mi primer artículo sobre esta nueva característica, vinculado en la sección Referencias a continuación, creé una tabla de fechas personalizada y un calendario con 31 días para todos los meses.
Al realizar la misma operación con ese calendario, el efecto desaparece:
Si bien este enfoque funciona perfectamente, requiere un calendario personalizado, lo que puede causar otros problemas o no cubrir requisitos específicos. Especialmente porque las columnas de fecha no contienen fechas reales y la columna date_real tiene espacios en blanco. Esto puede causar problemas al usarlo en cálculos personalizados.
Otra solución es calcular el PY retrocediendo 12 meses:
Ventas en línea (-12 M Gregoriano) = CALCULAR([Online Sales]
,DATEADD(‘Calendario Gregoriano’, -12, MES) )
Y estos son los resultados de la nueva medida:
En rojo, verá los mismos resultados que antes, desplazados un día.
En verde, verá los resultados de la medida con granularidad mensual.
Curiosamente, las sumas de los trimestres y los años también son correctas.
Por el momento, no veo ningún problema con el uso de este enfoque y lo usaré y probaré en el futuro.
Cálculos semanales – Rascarse la cabeza
Éste es muy extraño.
Mire la siguiente imagen con la misma tabla en diferentes estados, una al lado de la otra:
A la izquierda, verá que todas las filas para 2023 son idénticas cuando 2022 está contraído.
A la derecha, ve los valores correctos para 2023, pero se muestran solo cuando amplío al menos una semana de 2022 hasta la Fecha.
Pero los valores en 2022 volverán a ser los mismos.
Ya experimenté esto y lo mostré en mi primer artículo sobre la función de calendario (enlace a continuación).
En ese caso, lo resolví creando una tabla separada para el calendario semanal. Pero esta vez no funcionó.
Tuve que reconstruir el modelo de datos desde cero y funcionó de inmediato:
Como puede ver, los resultados son correctos.
Si observa detenidamente, los resultados de PY son correctos para obtener el valor de PY de la misma semana y día de la semana del año anterior.
No tengo idea de cuál es la diferencia entre estas dos configuraciones.
La tabla Fecha proviene de la misma fuente en ambos modelos de datos y el calendario se define utilizando las mismas columnas.
Pero estoy un poco ansioso por esto porque no entiendo el motivo y no tengo una solución. Incluso después de revisar el archivo TMDL de esa tabla, no encontré nada que indicara la causa.
Encontré tal efecto solo con cálculos semanales.
Mezclando lógica semanal con lógica mensual
Uno de mis clientes quiere ver un informe que muestre los resultados diarios del mes actual, en comparación con la misma semana y día laborable del año anterior.
Esta es una mezcla del Calendario mensual (gregoriano) con la lógica semanal.
Como mostraré con más detalle en el siguiente caso, la lógica semanal asigna correctamente las semanas y los días de la semana al año anterior. Por tanto, esto debería ser un problema.
Pero como las semanas no se alinean con los meses, no puedo agregar la categoría Mes. Recibiré un error al validar al intentar agregar la categoría Mes.
Por lo tanto, no puedo utilizar un cálculo MTD, ya que la función no encontrará la categoría necesaria:
No puedo agregar un calendario gregoriano a la misma tabla de fechas, ya que el motor espera la misma columna para la misma categoría para todos los calendarios de la misma tabla.
Consulte aquí la declaración de Microsoft al respecto.
Como uso la columna YearForWeek para la categoría Año, no funcionará con la categoría Mes porque no se alinean.
Como consecuencia, tuve que escribir una lógica personalizada para resolver todos los requisitos.
Cálculos semanales – ¡Eso es interesante!
Para terminar con una nota positiva, puedo mostrarles algo que funciona muy bien.
¿Recuerda el problema con los meses que no tienen la misma duración y cómo se cambiaron los valores PY?
Este efecto no aparece al realizar cálculos semanales.
Como puede ver, los resultados se calculan correctamente en función de la semana y los días de la semana correctos.
Como era de esperar, los valores no están asignados a las fechas del año anterior sino a los días de la semana.
Esto es lo que espero al observar los resultados por semana y por días laborables.
La razón es que cada semana tiene la misma duración y la tabla de fechas está diseñada para admitir dicho escenario.
Conclusión
Como puede ver, los resultados son mixtos.
Al observar los resultados de períodos anteriores de diferente duración (meses o años), los resultados cambian.
Cuando los períodos tienen la misma duración (semanas o el calendario personalizado), todo funciona como se esperaba.
Me quedé muy sorprendido y molesto cuando vi los resultados de los años bisiestos.
Pero, afortunadamente, esto se puede solucionar entendiendo cómo funciona la nueva lógica.
El otro problema con el que tengo un mal presentimiento es el funcionamiento inconsistente del calendario semanal y el cálculo del año anual.
Esto es preocupante, ya que no siempre es tan fácil reconstruir un modelo de datos.
Otro problema que tengo es que SQLBI informa problemas potenciales al usar varios calendarios en la misma tabla de fechas en su artículo. Le agregué un enlace a continuación.
Esto introducirá la necesidad de varias tablas de fechas en el mismo modelo de datos.
Algo que soy reacio a hacer.
Me imagino que esto afecta a varios elementos visuales de un informe, donde utilizan la lógica de diferentes calendarios pero con diferentes categorías.
Esto puede ser un desafío de resolver.
Pero veremos cómo evoluciona esta característica, ya que todavía estamos en Vista previa.
Referencias
El artículo de SQLBI que explica en detalle la función de inteligencia de tiempo basada en calendario:
https://www.sqlbi.com/articles/introduciendo-calendar-based-time-intelligence-in-dax
El artículo de SQLBI que explica DATEADD() con los nuevos parámetros:
https://www.sqlbi.com/articles/understanding-dateadd-parameters-with-calendar-based-time-intelligence
Documentación de Microsoft sobre la nueva característica (la URL puede cambiar con el tiempo):
https://learn.microsoft.com/en-us/power-bi/transform-model/desktop-time-intelligence#calendar-based-time-intelligence-preview
Mi artículo con tres casos de uso del mundo real con los nuevos calendarios:
Mi segundo artículo sobre inteligencia temporal basada en calendario y media móvil:
Una publicación de blog de Chris Webb sobre los efectos de la inteligencia del tiempo basada en el calendario:
Definición de la Semana ISO basada en el estándar ISO8601
https://www.calendarz.com/blog/iso-week-numbers-explained-week-1-week-53-and-year-boundaries
Como en mis artículos anteriores, utilizo el conjunto de datos de muestra de Contoso. Puede descargar el conjunto de datos ContosoRetailDW de forma gratuita desde Microsoft aquí.
Los datos de Contoso se pueden utilizar libremente bajo la licencia MIT, como se describe en este documento. Actualicé el conjunto de datos para cambiar los datos a fechas contemporáneas y eliminé todas las tablas que no eran necesarias para este ejemplo.