La tabla de fechas es la pieza más repetida de cualquier modelo de Power BI y también la que más informes rompe cuando falta. Sin ella no funcionan los acumulados del año, ni las comparaciones con el mes anterior, ni las medias móviles. Esta guía explica qué requisitos tiene que cumplir, cómo generarla, qué columnas añadirle y qué medidas de tiempo salen después.
Está escrita en dos niveles. Si usted lee informes, los apartados de requisitos y de errores frecuentes explican por qué a veces una comparación entre meses sale en blanco. En cambio, si construye el modelo, encontrará el código completo del calendario, las funciones de inteligencia de tiempo y el caso del año fiscal que no empieza en enero.
La serie y el caso común
Tercera de seis guías sobre el mismo conjunto de datos: 1.240 tickets de una mesa de servicio con cuatro sedes, entre julio y septiembre de 2026.
- Esquema estrella: hechos, dimensiones y claves.
- CALCULATE: contexto de filtro y modificadores.
- Tabla de fechas y cálculos de tiempo (esta guía).
- Visualizaciones: qué gráfico usar en cada caso.
- Áreas de trabajo, aplicaciones y actualización.
- Licencias: Free, Pro, PPU y capacidad.
Los tickets se reparten por mes de esta forma, y son las cifras que van a aparecer en todas las medidas:
| Mes | Días | Tickets | Horas | Tickets por día |
|---|---|---|---|---|
| Julio | 31 | 431 | 735,0 | 13,9 |
| Agosto | 31 | 396 | 661,5 | 12,8 |
| Septiembre | 30 | 413 | 712,0 | 13,8 |
| Trimestre | 92 | 1.240 | 2.108,5 | 13,5 |
Por qué hace falta una tabla de fechas
La razón inmediata es que las funciones de inteligencia de tiempo de DAX la exigen. Microsoft lo dice sin rodeos en su guía de diseño: para usarlas, el modelo debe tener al menos una.
Pero hay una razón anterior y más práctica. La columna de fecha que trae la tabla de hechos solo contiene los días en que ocurrió algo. Si en el caso no hubo ningún ticket el 3 de agosto, ese día simplemente no existe, y por lo tanto ningún gráfico lo dibujará. Una tabla de fechas propia tiene los 365 días de 2026, hubiera o no actividad.
Además, es la dimensión que permite agrupar por trimestre, por semana, por día laborable o por año fiscal sin tocar el hecho. Es decir, es el mismo argumento del esquema estrella aplicado al eje que más se usa.
Los cinco requisitos de una tabla de fechas
No vale cualquier lista de días. Para que Power BI la acepte tiene que cumplir estas condiciones:
| Requisito | Qué significa | En el caso |
|---|---|---|
| Columna de tipo fecha | Fecha o fecha y hora | Calendario[Fecha] |
| Valores únicos | Un día no puede repetirse | 365 valores distintos |
| Sin celdas en blanco | Ninguna fila vacía | 0 en blanco |
| Sin huecos | Todos los días consecutivos | Del 1 de enero al 31 de diciembre |
| Años completos | El año puede no ser natural | 2026 entero |
El quinto sorprende a mucha gente. Aunque el caso solo analice un trimestre, la tabla tiene que abarcar el año completo: si se cargaran únicamente los 92 días de julio a septiembre, los acumulados anuales y las comparaciones fallarían. Por eso son 365 filas y no 92.
Conviene aclarar que «año completo» no obliga a ir de enero a diciembre. Si la empresa cierra su ejercicio en junio, el año completo va de julio a junio; lo importante es que no esté partido.
La fecha y hora automática, y por qué se desactiva
Power BI trae una opción llamada Fecha y hora automática que crea, de forma invisible, una tabla de calendario por cada columna de fecha del modelo. Es cómoda para una exploración rápida y para perfilar datos, y para eso está bien.
Sin embargo, tiene un límite serio: esas tablas ocultas no pueden propagar filtros a varias tablas, así que no sirven para un modelo con dos hechos como el del caso. Además ocupan espacio. Con dos columnas de fecha en Tickets y una en Consumo son tres calendarios invisibles que nadie usa.
La recomendación es sencilla: mantenerla activada solo para modelos ad hoc y desactivarla en cuanto el informe vaya a publicarse. Se encuentra en las opciones del archivo, dentro de la carga de datos.
Las cinco formas de conseguir la tabla de fechas
| Técnica | Cuándo conviene |
|---|---|
| Fecha y hora automática | Exploración rápida, modelos desechables |
| Conectar a una tabla del origen | Si ya existe un almacén con dimensión de fecha |
| Generarla con Power Query | Si se quiere publicar como flujo de datos reutilizable |
| Generarla con DAX | Lo más rápido dentro de un solo archivo |
| Clonarla con DAX | Cuando hace falta una segunda por dimensión de rol |
De las cinco, la segunda es la mejor si existe: un almacén de datos ya tiene su dimensión de fecha y usarla garantiza que toda la organización comparta la misma definición de trimestre. Cuando no existe, Microsoft sugiere publicar la tabla como flujo de datos para que todos los modeladores se conecten a la misma.
Para un archivo suelto, en cambio, generarla con DAX es lo más directo. Es lo que hace el caso de esta serie.
Generar la tabla de fechas con DAX
Hay dos funciones para ello, y la diferencia importa. CALENDAR recibe una fecha de inicio y otra de fin. CALENDARAUTO, en cambio, recorre todas las columnas de fecha del modelo y devuelve años completos que las cubren.
La segunda tiene dos ventajas notables: garantiza por sí sola el requisito de años completos y se extiende sola al actualizar, cuando llegan datos de un año nuevo. Esta es la tabla del caso:
Calendario =
ADDCOLUMNS (
CALENDARAUTO (),
"Año", YEAR ( [Date] ),
"Número de mes", MONTH ( [Date] ),
"Mes", FORMAT ( [Date], "mmmm" ),
"Año-mes", FORMAT ( [Date], "yyyy-MM" ),
"Trimestre", "T" & QUARTER ( [Date] ),
"Día de la semana", FORMAT ( [Date], "dddd" ),
"Es laborable", IF ( WEEKDAY ( [Date], 2 ) <= 5, "Sí", "No" )
)Con los datos del caso devuelve 365 filas, todo 2026. Si mañana llegan tickets de enero de 2027, la misma expresión pasará a 730 sin que nadie la toque.
Dos columnas que casi siempre faltan
La columna Mes con el nombre en texto se ordena alfabéticamente, así que en un gráfico saldría abril, agosto, diciembre. Para arreglarlo hay que decirle a Power BI que la ordene por Número de mes, desde la opción de ordenar por columna.
La segunda es Es laborable. En una mesa de servicio, dividir los tickets entre los días del mes engaña, porque los fines de semana casi no hay actividad. Con esa columna se puede calcular la media sobre días hábiles, que es la cifra que de verdad sirve para dimensionar el equipo.
Marcar la tabla como tabla de fechas
Queda un paso que se olvida a menudo. En la inteligencia de tiempo clásica hay que marcar explícitamente la tabla, con la opción «Marcar como tabla de fechas», señalando cuál es la columna de fecha. Con la inteligencia de tiempo basada en calendario que Microsoft recomienda ahora no es obligatorio, salvo en casos concretos.
Marcarla no cuesta nada y evita resultados inesperados, así que conviene hacerlo siempre. Al marcarla, Power BI además retira los calendarios automáticos asociados a esa tabla.
Los acumulados del año
Con el calendario listo y relacionado con Tickets[FechaApertura], la primera medida de tiempo es el acumulado:
Tickets acumulados = TOTALYTD ( [Tickets], Calendario[Fecha] )
Horas acumuladas = TOTALYTD ( [Horas], Calendario[Fecha] )| Mes | Tickets | Tickets acumulados | Horas acumuladas |
|---|---|---|---|
| Julio | 431 | 431 | 735,0 |
| Agosto | 396 | 827 | 1.396,5 |
| Septiembre | 413 | 1.240 | 2.108,5 |
El acumulado de septiembre coincide con el total del trimestre porque el modelo no tiene datos anteriores a julio. En un año completo, en cambio, arrastraría también los seis primeros meses.
Comparar con el periodo anterior
Es la comparación que pide toda dirección, y se resuelve con DATEADD dentro de la función que modifica el contexto de filtro:
Tickets del mes anterior =
CALCULATE ( [Tickets], DATEADD ( Calendario[Fecha], -1, MONTH ) )
Variación mensual =
DIVIDE (
[Tickets] - [Tickets del mes anterior],
[Tickets del mes anterior]
)| Mes | Tickets | Mes anterior | Variación |
|---|---|---|---|
| Julio | 431 | (en blanco) | (en blanco) |
| Agosto | 396 | 431 | −8,1 % |
| Septiembre | 413 | 396 | +4,3 % |
Julio sale en blanco, y está bien que salga: no hay junio en el modelo. Inventar un cero ahí produciría una caída falsa del cien por cien, que es justo el tipo de cifra que destruye la confianza en un tablero.
Ahora bien, la lectura de esa tabla tiene truco. Septiembre parece recuperarse un 4,3 %, pero tiene un día menos que agosto. Mirando tickets por día, julio hizo 13,9 y septiembre 13,8: prácticamente lo mismo. Agosto, con 12,8, fue el mes realmente flojo. Esa es la diferencia entre comparar totales y comparar ritmos.
La media móvil de treinta días
Para suavizar el ruido diario se usa una ventana móvil. DATESINPERIOD la construye contando hacia atrás desde la última fecha del contexto:
Tickets últimos 30 días =
CALCULATE (
[Tickets],
DATESINPERIOD ( Calendario[Fecha], MAX ( Calendario[Fecha] ), -30, DAY )
)
Media diaria móvil = DIVIDE ( [Tickets últimos 30 días], 30 )Al 30 de septiembre, la ventana cubre el mes entero: 413 tickets, es decir, 13,8 diarios. Conviene usar MAX y no LASTDATE del hecho, porque así la ventana sigue existiendo aunque el último día no tenga actividad.
Contar por fecha de cierre
El caso tiene dos fechas por ticket y, como Power BI solo admite una relación activa, la de cierre quedó inactiva. Para usarla hay que activarla dentro de la medida:
Tickets cerrados =
CALCULATE (
[Tickets],
USERELATIONSHIP ( Calendario[Fecha], Tickets[FechaCierre] )
)Ahora el mismo informe puede mostrar en un gráfico los tickets abiertos por mes y en otro los cerrados por mes. La diferencia entre ambas series es la cola de trabajo que se arrastra, y suele explicar por qué un equipo se siente desbordado aunque la entrada no haya subido.
Cuando el año fiscal no empieza en enero
CALENDARAUTO admite un parámetro opcional: el mes en que termina el ejercicio. Si la empresa cierra en junio, la llamada correcta es CALENDARAUTO ( 6 ), y entonces los años generados irán de julio a junio.
Ese detalle cambia por completo los acumulados. Con ejercicio natural, el acumulado de septiembre del caso arrastra desde enero; con cierre en junio, arrastra desde julio y vale exactamente 1.240. Conviene fijarlo antes de publicar, porque corregirlo después obliga a reexplicar todos los números ya distribuidos.
Errores frecuentes
| Error | Síntoma | Corrección |
|---|---|---|
| Cargar solo el rango con datos | Los acumulados fallan | Años completos |
| Usar la fecha del hecho como eje | Faltan los días sin actividad | Poner el eje en la tabla de fechas |
| Dejar la fecha y hora automática | Calendarios ocultos y modelo pesado | Desactivarla |
| No ordenar el mes por su número | Abril, agosto, diciembre… | Ordenar por columna |
| Rellenar con ceros el periodo sin datos | Caídas falsas del 100 % | Dejar el valor en blanco |
| Dos relaciones activas a la misma tabla | Power BI no lo permite | USERELATIONSHIP o dimensión duplicada |
El segundo es el más común y el más difícil de ver, porque el gráfico se dibuja igual de bien. Solo cuando alguien busca un día concreto y no aparece, se descubre que el eje estaba puesto sobre el hecho.
En resumen: la tabla de fechas en cuatro reglas
Una tabla de fechas correcta tiene años completos, días consecutivos y valores únicos; se genera mejor con CALENDARAUTO; se marca como tal; y lleva al menos las columnas de mes ordenado y día laborable. Con eso, los acumulados, las variaciones y las medias móviles del caso salen en cuatro medidas cortas.
El modelo ya calcula. Falta mostrarlo sin que nadie lo malinterprete, que es el asunto de la cuarta guía: qué gráfico elegir para cada pregunta y cómo formatearlo. Para el trabajo previo de limpieza, la referencia sigue siendo la guía de Power Query.
Y si lo que necesita es que alguien administre las licencias, los usuarios y los accesos de Microsoft 365 sobre los que corre todo esto, esa es la conversación de nuestro servicio de gestión de plataformas.
