La funcionalidad de moneda mediante "Grupos de cálculo" no funciona en la medida de la segunda tabla de hechos

[marcstoffels]

¿Quién puede ayudarme a implementar esta implementación de moneda con éxito, utilizando "Grupos de cálculo"?

En un cubo tabular "Analysis Services" (modelo 1500) he implementado la funcionalidad de moneda mediante "Grupos de cálculo", como se explica en:
https://www.sqlbi.com/articles/currency-conversion-in-power-bi-reports/#

Esto funciona bien para las medidas del cuadro de 1 hecho, pero no en un segundo cuadro de hechos, que tiene medidas sobre las medidas del primer cuadro de hechos.

He reproducido este problema en un informe de Power BI con un origen de datos de Excel.

El modelo, que tiene 2 tablas de hechos:

A través del Editor tabular, agregué el grupo de cálculo:

La expresión de 'Moneda del informe':

Nombrede Medida del VAR (VAR MeasureName)

SELECTEDMEASURENAME ()

VAR SkipConversion ?

NO ISCROSSFILTERED ( 'Currency' ) -- TODO: implementar las condiciones para las que NO se debe aplicar el cálculo

|| (

BUSCAR ( "LandedPrice", MeasureName, 1, 0 ) - 0

&& BUSCAR ( "LP-pc", MeasureName, 1, 0 ) - 0

&& BUSCAR ( "Marc-pc", MeasureName, 1, 0 ) - 0

)

devolución

SI (

SkipConversion,

SELECTEDMEASURE (),

VAR SelectedCurrency (VAR SelectedCurrency)

SELECTEDVALUE ( 'Moneda'[Código] )

Resultado de VAR (VAR)

SI (

SelectedCurrency á "EUR",

SELECTEDMEASURE (),

SI (

BUSCAR ( "LandedPrice", MeasureName, 1, 0 ) > 0,

AVERAGEX ( ExchangeRate, SELECTEDMEASURE () * 'ExchangeRate'[Rate] ),

SUMX ( ExchangeRate, SELECTEDMEASURE () * 'ExchangeRate'[Rate] )

)

)

devolución

Resultado

)

El primer objeto visual mostrará la medida en la primera tabla de hechos (Partes):

PartsCosts_LP-pc14 á SUMX(Parts, [PartCount] * [LandedPrice-col])

en la moneda EUR:

Cuando cambie a USD (tenga en cuenta que la tasa de cambio es igual a 2, porque tuve un problema con los decimales en el conjunto de datos de origen):

Así que el grupo de cálculo, utiliza el tipo de cambio para multiplicar: 2,787,82 * 2 x 5,575.64 -> esto es correcto !!
Tenga en cuenta que puede ocultar la columna "Cálculo de conversión", utilizándola en un filtro y ocultar ese filtro.

En el segundo objeto visual he creado una nueva medida en la segunda tabla de hechos (Configuraciones):

Marc-pc24a ?

DIVIDE(

Piezas[PartsCosts_LP-pc14],

SUM(Configurations[IsActive])

)

En EUR será: 2.787,82 / 645 a 4,32 EUR

Al cambiar la segmentación de datos a 'USD', el cálculo se ejecuta, pero solo hace la parte Parts[PartsCosts_LP-pc14].
Por lo tanto, el cálculo de moneda devuelve el resultado del primer parámetro de la operación DIVIDE, pero no ejecuta la operación DIVIDE:
DIVIDE(

Piezas[PartsCosts_LP-pc14],

SUM(Configurations[IsActive])

)

¿Cómo podemos explicar este comportamiento?

Inspirado en este enlace:

http://reader.epubee.com/books/mobile/03/03d876188bcd39b0b307ecb6ebb63aee/text00016.html

No hay nada mágico en los grupos de cálculo: son tablas y, como tal, se pueden filtrar por CALCULATE como cualquier otra tabla. Cuando CALCULATE aplica un filtro a un elemento de cálculo, DAX utiliza la definición del elemento de cálculo para volver a escribir la expresión antes de evaluarla.

Por lo tanto, he creado una nueva medida, en la que he definido implícitamente, que la conversión de moneda debe ser ejecutada, pero luego en el nivel "más alto", por lo que dentro de la segunda medida de tabla de hechos y luego después de la DIVIDE:

Marc-24b ?

CALCULATE(

DIVIDE(

Piezas[PartsCosts_LP-pc14],

SUM(Configurations[IsActive]) --[DIFS-c0.07]

),

'Conversión de moneda'[Cálculo de conversión] - "Moneda del informe"

)

Esto ejecuta la conversión en el nivel "más alto", y muestra el valor correcto: 8.64 USD

Pero esto entonces necesita implementar esto en cada medida...
Así que no hay solución, pero esto es lo que queremos relacionado con la secuencia de ejecución.

Además, no se ejecuta la expresión de formato de moneda.

Tenga en cuenta que tengo la expresión de formato implementada dentro del grupo de cálculo de la siguiente manera:

¿Quién tiene experiencia con una implementación de simular?

[daxer-almighty]

Hola @marcstoffels

Lo que no sabe acerca de los grupos de cálculo, sin embargo, es que solo afectan a las medidas, no a las expresiones. Por lo tanto, esto funcionaría como cabría esperar: calcular( [medida], CalcGroup[CalcItem] - "CalcItem" ) pero esto no: calcular( suma( T[Col] ), CalcGroup[CalcItem] á "CalcItem" ). La regla difícil e irrompible es que el filtrado con grupos de cálculo solo debe aplicarse a medidas individuales y no debería haber ninguna excepción si desea permanecer en el lado seguro y saber lo que está calculando. Además de eso, los grupos de caclulación tienen prioridades que deben establecerse de una manera correcta (que a veces puede ser difícil). Y una última cosa... La aplicación de los grupos de cálculo (es decir, la reescritura de una medida) y la ejecución del código están en orden inverso. Vaya a www.sqlbi.com y busque el artículo de varias partes sobre los grupos de cálculo. Aprenderás mucho sobre cómo funcionan y te permitirá evitar los escollos comunes.

[marcstoffels]

Hola

Gracias por su respuesta.

Sé que sólo funciona en medidas, como por diseño: https://github.com/otykier/TabularEditor/issues/636
Pero supongo que en mi situación el problema es que combino dos medidas de dos tablas de hechos diferentes.

Así que cuando defino una nueva medida dentro de sólo la primera tabla de hechos (Partes), entonces el DIVIDE se ejecutará.

Como prueba mi medida, que divide los costos de las piezas por el número de piezas, por lo que esto mostrará el precio de nuevo:

Marc-pc99 ?

DIVIDE(

[PartsCosts_LP-pc14],

SUM([PartCount])

)



saludos
Marc.

[DataZoe]

@marcstoffels ¿Ha intentado hacer de SUM(Configurations[IsActive]) una medida explícita y, a continuación, usarlo en su división?

DIVIDE(

Piezas[PartsCosts_LP-pc14],

Piezas[IsActiveSum]

)

Eso puede haber sido lo que hizo con el --[DIFS-c0.07] pero no estaba seguro.

Otro pensamiento sería mover la instrucción IF en el grupo de cálculo a un VAR y devolver ese VAR, o intentar quitar los VAR en él, haciendo un DAX largo.

Estas son las cosas que intentaría, pero esta es una solución compleja.

[marcstoffels]

Hola DataZoe,

Gracias por su respuesta a mi problema.
De hecho, intenté tener la SUMA de configuraciones primero en una medida separada (DIFS-c.007), o tenerlo como un VAR en el propio mensaje, pero esto no lo resolvió.

saludos
Marc.