@Applicable88 y @TheoC, advertiría CONTRA la dirección del filtro cruzado establecida en ambos a menos que esté seguro de que lo necesita.
https://www.sqlbi.com/articles/bidirectional-relationships-and-ambiguity-in-dax/
No lo necesita en este escenario, solo necesita un poco de magia DAX para obtener el contexto correcto. SUMX hará el truco muy bien.
Puede que esta no sea la medida más eficiente para esto, pero hace el truco:
ACTUALIZADO: Lección IMPORTANTE: NO use SUM o funciones agregadas en columnas calculadas (que incluyen columnas calculadas virtuales como en el SUMX), ¡eso es lo que obtengo por responder a altas horas de la noche! He actualizado las siguientes medidas para que sean correctas ahora, ya que usan el CALCULATE para permitir el uso de agregar dentro de una columna.
@Applicable88,@TheoC a pesar de que @AllisonKennedy le dio una solución, la he ideado de una manera diferente y de la estructura actual, que no infla el tamaño del modelo (definitivamente lo haría en una situación, a menos que no lo necesite en absoluto).
En el modelo de datos actual, FILTERTbl filtra los filtros FactTbl y FILTERTbl ManufacturingTbl.
Está trayendo su eje de FactTbl en la Viz para este propósito y realizando la agregación en ManufacturingTbl.
Con la estructura actual, Fact no tiene forma de llegar a Manufacturing.
Sin necesidad de activar el filtrado bidireccional que introduce mucha ambigüedad en el modelo, el requisito mínimo para crear una relación indirecta entre Fact y Manufacturing (n:n) donde Fact Filters Manufacturing.
Una vez que tenga eso, debe escribir las siguientes medidas para alcanzar su objetivo.
_time1Manufacturing =
VAR _currentlyViisibleMaterialFromFact =
MAX ( FactTbl[Material] )
VAR _sumManufacturing =
CALCULATE (
SUM ( ManufacturingTbl[Time1] ),
TREATAS (
{ ( { _currentlyViisibleMaterialFromFact }, 20 ) },
ManufacturingTbl[Material],
ManufacturingTbl[ProcessCode]
),
USERELATIONSHIP ( FactTbl[Material], ManufacturingTbl[Material] )
)
RETURN
_sumManufacturing
_time2Manufacturing =
VAR _currentlyViisibleMaterialFromFact =
MAX ( FactTbl[Material] )
VAR _sumManufacturing =
CALCULATE (
SUM ( ManufacturingTbl[Time2] ),
TREATAS ( { _currentlyViisibleMaterialFromFact }, ManufacturingTbl[Material] ),
USERELATIONSHIP ( FactTbl[Material], ManufacturingTbl[Material] )
)
RETURN
_sumManufacturing
Además, si necesita esto en el nivel subtotal también. Hay dos versiones de subtotal y no estoy seguro de cuál necesitaría
_t1Subtotal1 =
SUMX (
ManufacturingTbl,
VAR _currentlyViisibleMaterialFromFact =
CALCULATE ( MAX ( FactTbl[Material] ) )
VAR _sumManufacturing =
CALCULATE (
SUM ( ManufacturingTbl[Time1] ),
TREATAS (
{ ( { _currentlyViisibleMaterialFromFact }, 20 ) },
ManufacturingTbl[Material],
ManufacturingTbl[ProcessCode]
),
USERELATIONSHIP ( FactTbl[Material], ManufacturingTbl[Material] )
)
RETURN
_sumManufacturing
)
_t2Subtotal1 =
SUMX (
ManufacturingTbl,
VAR _currentlyViisibleMaterialFromFact =
CALCULATE ( MAX ( FactTbl[Material] ) )
VAR _sumManufacturing =
CALCULATE (
SUM ( ManufacturingTbl[Time2] ),
TREATAS ( { _currentlyViisibleMaterialFromFact }, ManufacturingTbl[Material] ),
USERELATIONSHIP ( FactTbl[Material], ManufacturingTbl[Material] )
)
RETURN
_sumManufacturing
)
_t1Subtotal2 =
VAR _subTotalLevel =
SUMX (
ManufacturingTbl,
VAR _currentlyViisibleMaterialFromFact =
CALCULATE ( MAX ( FactTbl[Material] ) )
VAR _sumManufacturing1 =
CALCULATE (
SUM ( ManufacturingTbl[Time1] ),
TREATAS (
{ ( { _currentlyViisibleMaterialFromFact }, 20 ) },
ManufacturingTbl[Material],
ManufacturingTbl[ProcessCode]
),
USERELATIONSHIP ( FactTbl[Material], ManufacturingTbl[Material] )
)
VAR _sumManufacturing2 =
CALCULATE (
SUM ( ManufacturingTbl[Time1] ),
FILTER (
ManufacturingTbl,
ManufacturingTbl[Material] = _currentlyViisibleMaterialFromFact
&& ManufacturingTbl[ProcessCode] = 20
),
USERELATIONSHIP ( FactTbl[Material], ManufacturingTbl[Material] )
)
RETURN
IF ( HASONEVALUE ( FactTbl[Material] ), _sumManufacturing1, _sumManufacturing2 )
)
RETURN
_subTotalLevel
_t2Subtotal2 =
VAR _subTotalLevel =
SUMX (
ManufacturingTbl,
VAR _currentlyViisibleMaterialFromFact =
CALCULATE ( MAX ( FactTbl[Material] ) )
VAR _sumManufacturing1 =
CALCULATE (
SUM ( ManufacturingTbl[Time2] ),
TREATAS ( { _currentlyViisibleMaterialFromFact }, ManufacturingTbl[Material] ),
USERELATIONSHIP ( FactTbl[Material], ManufacturingTbl[Material] )
)
VAR _sumManufacturing2 =
CALCULATE (
SUM ( ManufacturingTbl[Time2] ),
FILTER (
ManufacturingTbl,
ManufacturingTbl[Material] = _currentlyViisibleMaterialFromFact
),
USERELATIONSHIP ( FactTbl[Material], ManufacturingTbl[Material] )
)
RETURN
IF ( HASONEVALUE ( FactTbl[Material] ), _sumManufacturing1, _sumManufacturing2 )
)
RETURN
_subTotalLevel
pbix se adjunta aquí
https://1drv.ms/u/s!AkrysYUHaNRvhcV23WX0LZIKtlCfpQ?e=xNzPcb
@Applicable88 y @TheoC, advertiría CONTRA la dirección del filtro cruzado establecida en ambos a menos que esté seguro de que lo necesita.
https://www.sqlbi.com/articles/bidirectional-relationships-and-ambiguity-in-dax/
No lo necesita en este escenario, solo necesita un poco de magia DAX para obtener el contexto correcto. SUMX hará el truco muy bien.
Puede que esta no sea la medida más eficiente para esto, pero hace el truco:
ACTUALIZADO: Lección IMPORTANTE: NO use SUM o funciones agregadas en columnas calculadas (que incluyen columnas calculadas virtuales como en el SUMX), ¡eso es lo que obtengo por responder a altas horas de la noche! He actualizado las siguientes medidas para que sean correctas ahora, ya que usan el CALCULATE para permitir el uso de agregar dentro de una columna.
@TheoC Sus números son completamente diferentes a mi solución, no estoy tratando de pisar sus dedos de los ojos, solo tenía una interpretación diferente del problema y mientras estuve aquí, como siempre lo hago, traté de explicar POR QUÉ he hecho algo. Quería tener especial cuidado en explicar por qué mi solución era diferente a la ya proporcionada, ya que normalmente no publico en un hilo que ya tiene una respuesta. Sin embargo, había comenzado con esto antes y me lo quitaron, y desde entonces ha proporcionado una posible solución.
Su solución solo devuelve el valor firstnonblank y, como ha mencionado usted mismo en la publicación, no tiene en cuenta el código de proceso. Tiene razón: esta información no está en la FactTable. @Applicable88 especificó cómo necesitaban que esto se calculara.
Usando la captura de pantalla que tan útilmente proporcionó (arriba), en comparación con mis resultados (abajo), he resaltado los números de pedido correspondientes para ver las diferencias en nuestros cálculos:
Me olvidé de agregar Order ID a mis imágenes, así que lo he hecho ahora para ayudar a mostrar las diferencias en nuestras dos soluciones propuestas. Solo tendremos que esperar a que @Applicable88 nos haga saber si alguno de nosotros ha podido ayudar.
Una vez más, mis medidas funcionarán bien en su modelo tal como está, simplemente no puedo en buena conciencia proporcionar solo la mitad de una solución, lo que significa que si estoy proporcionando una medida a un modelo de datos que sé que podría causar problemas más abajo, diré algo.
Como he mencionado, no es mi opinión o una buena práctica para la bidireccional a muchas relaciones, causa ambigüedad en tu modelo y debes mantenerte alejado de él: https://www.sqlbi.com/articles/bidirectional-relationships-and-ambiguity-in-dax/
La tabla Dim era solo una ventaja, ver la última versión de adjunto que como fusionó las dos tablas dim en 1, deshaciéndose de la relación 1: 1 (aún podría funcionar con la tabla de filtro existente, pero eso hace que la vida sea más difícil de informar sobre los Materiales no presentes en esa tabla).
Aquí hay una captura de pantalla más grande de las diferencias entre sus capturas de pantalla y las mías:
PD, ¡me encanta la discusión!
Wow @AllisonKennedy Muchas gracias por su esfuerzo y explicación exhaustiva. Sabía que con ese modelo de datos sería más controvertido. Al igual que con muchas cosas en el "mundo real", muy a menudo no hay una estructura de datos perfecta ni un modelo de datos perfecto para una cosa determinada. Incluso si no hubiera FilteringTable, la tabla ManufacturingTime nunca se puede agrupar por, debido al diferente uso de Time1 y Time2 para diferentes procesos de fabricación de diferentes materiales. Y eso significa que terminaría de todos modos teniendo una relación m:n entre facttable y manufacturingTime table.
He descargado el archivo hace un momento. ¡Es tan interesante! Nunca vi tres sumx en sucesión, aquí solía filtrar el ProcessCode 20. Nunca se me ocurrió que se puede construir así.
Pero ya me encuentro con un problema con el que me enfrenté antes, pero esta vez de otra manera:
@AllisonKennedy Veo que en una selección no material no tenemos los "Totales" correctos:
solo después de la selección de UN material obtengo los totales correctos:
Después de agregar solo un material más, obtengo los totales equivocados:
lo mismo ocurre con la selección de todos los materiales:
Vi algunos tutoriales sobre "arreglar los totales", pero no creo que aborden el mismo problema. ¿Hay alguna manera de resolver esto también?
Muchas gracias hasta ahora. Aprendí mucho de eso.
Definitivamente de acuerdo. La única razón por la que agregué la relación interdireccional fue para imitar la presentada por @Applicable88. Las salidas de mi solución siguen siendo las mismas sin necesidad de crear tablas adicionales, etc.
Hola @AllisonKennedy,mientras creaba un conjunto de datos más realista para @TheoC según mi caso, acabo de probar su medida con la función de dos sumx. Como dijiste, también debería funcionar sin crear una nueva tabla.
https://drive.google.com/file/d/1MM8V_eBiD3GAAM3yswQQUKmle0WpAhQ6/view?usp=sharing
¡Curiosamente ahora los totales también son correctos! Antes y después del filtrado.
Por ejemplo, esa es de nuevo la tabla ManufacturingTime:
En este ejemplo quiero tener 4 Medidas diferentes:
1. Mostrar la suma de todo el tiempo de preparación de un material
2. Mostrar la suma de todo el ManuTime de un Material
3. Mostrar la suma del tiempo de preparación, pero solo de ProcessCode40
4. Mostrar la suma de Manutime, pero solo de ProcessCode30
Y, por supuesto, cada vez que los totales deben mostrar el valor sumado correcto.
Facttable sin Materialnumber seleccionado:
El primer PrepTime y ManuTime son las opciones básicas de suma de un campo entero.
PreptimeSum y ManutimeSum son Medidas a la suma (Preptime) y sum (ManuTime).
Como era de esperar, debido a la relación N:1:N, las primeras cuatro columnas de agregaciones no muestran el total correctamente, porque el modelo de datos no puede utilizar la función Related()-function ni nada. Y los tiempos se ubican "detrás" del otro lado de la relación 1:N.
Las dos últimas medidas son las interesantes:
Más Materialnumber seleccionado:
Los totales son absolutamente correctos en este momento, antes y después de filtrar los materiales.
@AllisonKennedy, ¿puede decirme qué está sucediendo realmente en la medida en la que sumx está envuelto en otro sumx, que puede encontrar el contexto de filtro correcto, mientras que las otras medidas solo lograron sumar los tiempos para cada materialmero una vez?
Y por qué esto, por ejemplo, no funcionará:
Helpful resources
Power BI Monthly Update - April 2024
Check out the April 2024 Power BI update to learn about new features.
Fabric Community Update - April 2024
Find out what's new and trending in the Fabric Community.
