La consulta nativa trae todos los datos en un objeto visual tabular cuando se aplica la conversión de moneda.

[Syndicate_Admin]

Hola

Me pregunto si alguien se ha enfrentado a este problema antes.

Tengo un SDM en el que tengo una tabla de hechos que contiene datos a nivel de fecha.
La tabla de hechos se une a la tabla de calendario en Fecha (combinación interna).
La tabla de datos se une a la tabla de tipos de cambio mensuales en la fecha del tipo de cambio (es decir, el día 1 de cada mes). -- unión de varios a muchos.

La dimensión A se une a la tabla de hechos en el identificador de dimensión (combinación interna).
La tabla Tipo de cambio se une a la tabla Código de To_Currency (contiene el código de moneda al que se realiza la conversión).

Mi requisito de presentación de informes es:
Segmentaciones de usuario - segmentación de fecha (de la tabla de calendario), dimensión A y código To_Currency.

El informe contiene una tabla con 15+ atributos de la tabla de hechos y la lógica de conversión de moneda para la medida.

Lo que he visto con las pruebas -

En el caso de una segmentación de fechas de 2 meses, para un atributo determinado de la dimensión A y sin ninguna lógica de conversión de moneda aplicada,
La tabla muestra los datos hasta el nivel más bajo de granularidad.
Así, por ejemplo, si el filtro de fecha es 1/1/2025 - 2/28/2025, la tabla muestra 2 registros de datos basados en el filtro de dimensión A.

Ahora, si aplico la lógica de conversión de moneda, el objeto visual de la tabla arroja un error que indica que devuelve 1 millón de registros.

Al investigar más a fondo, veo que hay toneladas de consultas nativas generadas en la base de datos (estamos usando Databricks).
Una de las consultas generadas extrae todos los registros de la tabla de hechos, y creo que este es el problema.

Además, cuando elimino el nivel más bajo de granularidad de la tabla (que es la columna ID), la métrica de conversión de moneda funciona bien.

Medida convertida =
VAR ConversionStartDate = MIN('Calendar'[Date]) -- Fecha de inicio desde el slicer
VAR ConversionEndDate = MAX('Calendar'[Date]) -- Fecha de finalización del segmentador
VAR TargetCurrencyCode = SELECTEDVALUE('To_Currency'[Código de moneda]) -- Moneda de destino de la segmentación
VAR SourceCurrency = SELECTEDVALUE('Fact Table'[Currency Code]) -- El código fuente está en USD

-- Si la moneda de destino es USD, devuelva la medida total sin conversión
DEVOLUCIÓN
SI(
TargetCurrencyCode = "USD",
SUM('Tabla de hechos'[Medida1]),
Tarifas filtradas por el VAR =
FILTRO(
'monthly_average_exchange_rate',
'monthly_average_exchange_rate'[De Moneda] = FuenteMoneda &&
'monthly_average_exchange_rate'[A la moneda] = TargetCurrencyCode &&
'monthly_average_exchange_rate'[Fecha de tasa] >= EOMONTH(ConversionStartDate, -1) + 1 &&
'monthly_average_exchange_rate'[Rate Date] <= EOMONTH(ConversionEndDate,-1)+1
)

VAR ConversionRate = MAXX(FilteredRates, 'monthly_average_exchange_rate'[Rate])
DEVOLUCIÓN
SI(
NOT ISBLANK(Tasa de conversión),
SUM('Tabla de hechos'[Medida1]) * Tasa de conversión,
EN BLANCO()
)
)

Captura de pantalla del SDM

Si elimino el nivel más bajo de granularidad, la lógica de conversión funciona. Si lo agrego, la lógica de conversión arroja un error de registros de 1M +.

Si se supone que solo hay 2 registros para la segmentación de fechas dada, la lógica de conversión de moneda debe funcionar de manera que los datos de los dos registros solo se calculen o conviertan.
En este caso, está extrayendo todos los registros como se ve en la consulta nativa generada.

Cualquier idea sobre cómo vencer esto ayudará.

[Syndicate_Admin]

@Rdarshana,

También me gustaría tomarme un momento para agradecer a @grazitti_sapna, @vojtechsima por participar activamente en el foro de la comunidad y por las soluciones que han estado compartiendo en el foro de la comunidad. Sus contribuciones marcan una diferencia real.

Quería comprobar si ha tenido la oportunidad de revisar la información proporcionada. No dude en ponerse en contacto con nosotros si tiene más preguntas. Si la respuesta ha abordado su consulta, acéptela como una solución para que otros miembros de la comunidad puedan encontrarla fácilmente.

Gracias

Harshitha.

[Syndicate_Admin]

@Rdarshana,

¿Solo quería verificar si tuvo la oportunidad de revisar la sugerencia proporcionada?

Si la respuesta ha abordado su consulta, acéptela como una solución y dé un 'Felicitaciones' para que otros miembros puedan encontrarla fácilmente.

Gracias.

Harshitha.

[Syndicate_Admin]

Todavía probándolo,

[Syndicate_Admin]

Hola @Rdarshana,
Gracias por la actualización.

Por favor, tómese su tiempo con las pruebas. Si tiene algún problema o necesita más aclaraciones, no dude en ponerse en contacto con nosotros.

Saludos
Harshitha.

[Syndicate_Admin]

@Rdarshana,

Quería comprobar si ha tenido la oportunidad de revisar la información proporcionada. No dude en ponerse en contacto con nosotros si tiene más preguntas. Si mi respuesta ha abordado su consulta, acéptela como una solución para que otros miembros de la comunidad puedan encontrarla fácilmente.

Gracias.

[Syndicate_Admin]

@Rdarshana,

El problema es con la lógica de conversión de moneda:

Tarifas filtradas por el VAR =
FILTRO(
'monthly_average_exchange_rate',
...
)
Tasa de conversión del VAR =
MAXX(FilteredRates, 'monthly_average_exchange_rate'[Tasa])

no se evalúa por fila de fecha , sino que se vuelve a evaluar por fila en el objeto visual y, dado que ha agregado el campo ID, esa evaluación se multiplica drásticamente.

Peor aún, su modelo implica:

• A De varios a varios relationship (between Fact and exchange rate table on Exchange Rate Date)

• Filtering using SELECTEDVALUE() on potentially non-unique combinations (To_Currency, From_Currency, Rate Date)

• A complex, dynamic filter (>=, <=) for each record

Esto fuerza la conversión de contexto de fila → de filtro de contexto por fila de la tabla, lo que genera consultas nativas de gran tamaño.

Puede probar los siguientes métodos:

Refactor the conversion logic using TREATAS, which lets you push filters from calculated values more cleanly:

Medida convertida =
VAR ConversionStartDate = MIN('Calendar'[Date])
VAR ConversionEndDate = MAX('Calendar'[Date])
VAR TargetCurrencyCode = SELECTEDVALUE('To_Currency'[Código de moneda])
VAR SourceCurrency = SELECTEDVALUE('Tabla de hechos'[Código de moneda])
Tasa VARVátiles =
ADDCOLUMNS(
CALENDARIO(
EOMONTH(ConversionStartDate, -1) + 1,
EOMONTH(ConversionEndDate, -1) + 1
),
"FromCurrency", SourceCurrency,
"ToCurrency", TargetCurrencyCode
)

Tarifas filtradas por el VAR =
CALCULATETABLE(
'monthly_average_exchange_rate',
TREATAS(RateDates,
'monthly_average_exchange_rate' [Fecha de la tarifa],
'monthly_average_exchange_rate' [de la moneda],
'monthly_average_exchange_rate' [A la moneda]
)
)

VAR ConversionRate = MAXX(FilteredRates, 'monthly_average_exchange_rate'[Rate])

DEVOLUCIÓN
SI(
TargetCurrencyCode = "USD",
SUM('Tabla de hechos'[Medida1]),
SI(
NOT ISBLANK(Tasa de conversión),
SUM('Tabla de hechos'[Medida1]) * Tasa de conversión,
EN BLANCO()
)
)

Esto garantiza que el filtrado de tasas se realice de forma masiva, no fila por fila.

También puedes probar a continuación,

En lugar de aplicar el tipo de cambio por registro, intente:

• Medida de agregación previa por mes

• A continuación, se realiza la conversión utilizando un tipo de cambio medio mensual

Esto reduce drásticamente el contexto de cálculo:

Medida convertida (mensual) =
SUMX(
VALUES('Calendar'[MonthYear]), -- o RateDate
VAR MensualTotal =
CALCULATE(SUM('Tabla de hechos'[Medida1]))
Tasa de VAR =
CALCULAR(
MAX('monthly_average_exchange_rate'[Tasa]),
FILTRO('monthly_average_exchange_rate', ...)
)
RETORNO MensualTotal * Tarifa
)

🌟 ¡Espero que esta solución te ayude a desbloquear tu potencial de Power BI! Si le resultó útil, haga clic en "Marcar como solución" para guiar a otros hacia las respuestas que necesitan.
💡 ¿Te gusta el esfuerzo? ¡Deja caer las felicitaciones! Su agradecimiento alimenta el espíritu comunitario y la innovación.
🎖 Como orgullosos superusuarios y socios de Microsoft, estamos aquí para potenciar su recorrido de datos y a la comunidad de Power BI en general.
🔗 ¿Tienes curiosidad por explorar más? [Descúbrelo aquí].
¡Sigamos construyendo juntos soluciones más inteligentes!

[Syndicate_Admin]

@grazitti_sapna
Probé las dos medidas. La lógica de conversión de moneda funciona como tal.
Pero, cuando agrego un identificador (nivel más bajo de granularidad de la tabla), veo que Power BI envía el mismo error en el objeto visual de la tabla:
Error al capturar datos para este objeto visual. El conjunto de resultados de una consulta a un conjunto de datos externo ha superado el tamaño máximo permitido de 1 millón de filas.

Entonces, ahora mi pregunta es:
Si mantenemos la lógica de conversión mensual tal cual, ¿cree que tendría sentido romper la unión de varios a varios entre la tabla de hechos y la tabla de tipos de cambio mensuales?

[Syndicate_Admin]

Actualización: rompí la unión de muchos a muchos entre la tasa de exchnage mensual y la tabla de hechos al incluir dos tablas puente. Así que ahora las uniones son todas de uno a varios.

Pero a pesar de realizar este cambio y agregar la lógica de conversión para la agregación mensual, todavía veo el problema de 1 millón de registros con el objeto visual de tabla cuando se incluye la columna ID.

[Syndicate_Admin]

@RDARSHANA,

Límite de consultas de conjuntos de datos externos de Power BI = 1 millón de filas

Cuando se usa DirectQuery e se incluye el identificador (granularidad más baja) en el objeto visual, Power BI genera una consulta que devuelve una fila por identificador por fecha (o por medida). Esto puede superar fácilmente 1 millón de filas, especialmente si:

• Tiene muchos ID (por ejemplo, transacciones, líneas de factura, etc.)

• Esto se combina con las dimensiones de fecha o moneda

• Even if you're aggregating monthly, including ID in the visual Deshabilita la agregación previa optimization

A continuación se presentan algunas sugerencias

1. Avoid Using ID in Visuals Unless Necessary

• La raíz del desbordamiento de filas de 1 millón ya no está en la lógica de medición, sino en el objeto visual que intenta recuperar demasiadas filas.

• Try to Resumir los datos before adding ID to the visual.

• If you mosto show ID, implement Paginación, filtros o obtención de detalles.

2. Usar tablas agregadas

Si el modelo lo permite, materialice tablas agregadas previamente (por ejemplo, totales mensuales por divisa, por ID o producto) y, a continuación, use esas tablas en objetos visuales:

• Cree una nueva tabla agregada en Power BI mediante DAX o en la base de datos de origen:

HechoAgregado =
RESUMIR(
'Tabla de hechos',
'Tabla de hechos'[ID],
'Calendario' [mes],
'Tabla de hechos' [código de moneda],
"TotalMeasure", SUM('Tabla de hechos'[Medida1])
)

• A continuación, aplique la conversión de moneda sobre esta tabla agregada previamente.

3. Utilice la obtención de detalles en lugar de una tabla grande

En lugar de permitir una tabla plana con granularidad completa, diseñe el informe de la siguiente manera:

• Página de resumen: resumen por mes o producto

• Drill-through page: show ID-level detail only when context is selected

[Syndicate_Admin]

Hola @grazitti_sapna
El objeto visual tabular forma parte de una página de obtención de detalles.
Tenemos una segmentación de fechas y una segmentación de divisas en la página principal. DimensionA actúa como un atributo para obtener detalles de la tabla de niveles detallada.

Por lo tanto, cuando el informe de obtención de detalles muestra solo 2 registros para una segmentación de fechas determinada y un atributo de dimensión A determinado, lo ideal es que la lógica de conversión de moneda solo convierta los datos de los dos registros. Por lo tanto, es confuso cuando Power BI muestra un problema de datos de registros de 1M+.

Si nos fijamos en el modelo de datos y en las uniones de varios a varios, incluso después de convertir las uniones de varios a varios en de uno a varios (combinaciones internas), veremos el mismo problema.
Por lo tanto, si la consulta original extrae solo un identificador en el objeto visual tabular, lo ideal es que la lógica de conversión funcione en este caso.

¿Hay algo más que falte en la prueba?

[Syndicate_Admin]

Hello, @Rdarshana ,

No me gusta el Muchos a Muchos, especialmente si está configurado para ambos (dirección),

Consideraría cambiar la tabla de tarifas y generar alguna clave sustituta (SK), para que pueda unir su tabla de hechos con One To Many (exchance -> fatct).

Quizás a partir del rango de fechas, puede crear una fila para cada fecha y agregarle una moneda válida y crear el SK a partir de ella, de la misma manera que en su tabla de hechos. Tal vez eso pueda ayudar.

[Syndicate_Admin]

@vojtechsima

Creé dos tablas puente entre la tabla de tipos de cambio mensuales y la tabla de hechos.
1. Tabla DistinctRateDates (unida a la tabla de tipo de cambio: unión de uno a varios en la fecha de tasa)

DistinctRateDates =

DISTINTO(SELECTCOLUMNS('monthly_average_exchange_rate', "Fecha de la tarifa", 'monthly_average_exchange_rate'[Fecha de calificación]))
2. DateBridgeTable (unido a la tabla DistinctRateDates - muchos a uno; Adjunto a la tabla de hechos - uno a muchos)

DateToRateBridge =

SELECTCOLUMNS (

'Calendario de gastos',

"Fecha", 'Calendario de gastos'[Fecha],

"Fecha de la tarifa", FECHA(AÑO('Calendario de gastos'[Fecha]), MES('Calendario de gastos'[Fecha]), 1)

)

Después de esto, apliqué el cálculo mensual para la conversión de moneda. La lógica funciona, pero en el momento en que agrego el campo ID, simplemente explota con el mensaje de error de 1 millón de registros.
El campo Id. es imprescindible para el objeto visual tabular.
¿Hay algo más que se pueda investigar?