LuckyTemplates Mått totalt är felaktigt: Hur man åtgärdar det

Du kan stöta på problem med åtgärder i LuckyTemplates tabellvisualiseringar med en total rad. Det vanliga klagomålet är att raden "Totalt" är "felaktig" för måttet. Vanligtvis är den totala raden korrekt för måttet, det är bara inte vad de flesta förväntar sig. I den här handledningen ska jag ta oss igenom det här vanliga problemet med LuckyTemplates mått totalt och hur man löser det. Du kan se hela videon av denna handledning längst ner på den här bloggen.

LuckyTemplates mått totalt har varit ett problem så länge som LuckyTemplates har funnits. Så för att lösa det här problemet var det första jag gjorde att jag gick in och skapade en . Om du aldrig har sett ett dumpfilter mäta, ser det mycket ut som det nedan.

Dumpfiltermåttet avgör vilka filter som används från de olika tabellerna och kolumnerna i datamodellen. Det är väldigt enkelt att skapa i DAX Studio. Du kan starta DAX Studio, klicka på valfri tabell och säga, Definiera filterdumpningsmått (alla tabeller), och det genererar all kod åt dig.

Allt du behöver göra för att få in det i LuckyTemplates är att ta det från de här filtren och kopiera all den koden och sedan bara klistra in den i ett nytt mått, vilket är vad jag gjorde. Det var därifrån denna åtgärd för dumpningsfilter kom.

Jag skapade också en kortvisualisering och satte dumpningsfiltermåttet i den kortvisualiseringen. Detta gör att vi kan se eller .

För att aktivera verktygstips kan du klicka på en bild på din matris eller ditt bord. I det här exemplet har jag en matris och en tabell här som båda visar samma problem med måtttotal. Du kan gå till Allmänt och bara växla på verktygstips. Om du vill kan du ange att det är en rapportsida.

Om jag håller muspekaren över denna 290 kan jag se att den har ett filter på tabellkategorin är lika med kategori ett. Den här är kategori två, där vi har en underkategori lika med blått, grönt och rött. Allt detta kommer från en mycket enkel datafråga där jag har sex rader.

Det sista steget är att skapa ett mått som kommer att visa upp måtttotalens problem. Och om du tittar noga kan du redan se att summan inte stämmer.

När det gäller DAX är det korrekt, men varje normal människa som tittar på detta skulle tycka att detta är helt fel. Jag måste faktiskt tro att detta förmodligen är en ledande orsak till varför folk tror att det är ett stort hinder för antagandet av LuckyTemplates.

Det är det enkla faktum att mätsummor är fel ute ur porten. Tabellvisualiseringarna och matrisvisualiseringarna uppvisar faktiskt inte korrekt beteende.

Innehållsförteckning

• Använder ett surrogatmått
• Åtgärda felaktiga LuckyTemplates Measure Total
• Slutsats

Använder ett surrogatmått

Jag har den här tabellen här med mina måttbelopp. Allt jag har gjort är en snabboch subtraherad 10. Detta är ett surrogat för alla rimligt komplicerade åtgärder. Om du kan visa problemet med måtttotal med något så enkelt som detta, kommer det att dyka upp i många av dina mått.

Filterkontexten för denna totalrad är annorlunda, så det verkar som att DAX bara körs i sammanhanget för alla. Om jag klickar på till exempel Kategori 1 så stämmer det.

Så det tar uppenbarligen filterkontexten för Kategori = Kategori 1.

Den har inte denna extra filterkontext av denna kategori utan extern påverkan. Om jag svävar över här kan du se att det är tomt. Det finns inget som filtrerar detta just nu. Dessa rader har ett filter på kategorin, men det tar inte hänsyn till det alls.

Så hur fixar vi det? Låt oss ta en titt på måttet jag skapade.

Åtgärda felaktiga LuckyTemplates Measure Total

Jag kallade den här Mått Totals Category , och det står omtabellkategori, och sedan bara returnera mitt mått som är korrekt på en rad för rad.

Annars gör jag detden tabellen efter kategori, och sedan ska jag beräkna mitt mått för varje rad. Sedan ska jag summera värdena.

I grund och botten återskapar jag den här tabellvisualiseringen, sedan summerar jag de resulterande värdena från det måttet på de raderna, och det fixar det.

Nu är allt bra och bra. Det är en ganska enkel fix, men det är verkligen skadligt för självbetjäningsvisualisering, enligt min mening.

Om du har ett ganska komplext mått och du marknadsför självbetjäningsvisualisering tillbaka till dina slutanvändare, så är det bra att du inte har någon aning om hur de kommer att använda det måttet och hur de kommer att bli arbetar med det.

Till exempel kan du se problemet här. Jag har rätta kategorierna Måttsummor, men de är felaktiga här nere. Den returnerar till och med fel rad för rad.

Anledningen till detta är att kategorier aldrig är i omfattning. Så enligt vårt mått returnerar tabellkategorin ISINSCOPE mätsummorna.

Nåväl, så är det aldrig. Det är alltid att göra en sammanfattning efter kategori och sedan efter värde, vilket är helt fel.

Så nu måste vi skapa ett annat mått, Measure Total Subcategory , som om ISINSCOPE underkategori returnerar raden på den raden. Annars summerar du efter underkategori totalt värdena, vilket ger oss rätt svar.

Slutsats

Det är därför det är skadligt för självbetjäningsvisualisering eftersom du inte har någon aning om hur slutanvändarna kommer att använda den och vad de kommer att lägga i en tabell. Du måste skriva ett mått för varje möjlig kombination, vilket är galet.

Jag hoppas att du har lärt dig något av den här handledningen. Om du har stött på problem som detta, berätta för oss hur du har hanterat dem.

Med vänliga hälsningar!

Greg