LuckyTemplates Matrix | Hur man fixar matrissummor i LuckyTemplates

För den här handledningen kommer jag att visa dig hur du fixar LuckyTemplates matristotaler, särskilt att fixa totaler och delsummor om de åtgärder du skapar inte ger rätt resultat ursprungligen. Du kan se hela videon av denna handledning längst ner på den här bloggen.

Det finns två anledningar till att jag ville ta itu med det här problemet. En är att det förekommer ganska ofta. Det är något som kommer upp mycket i. Vi ser denna fråga upprepas om och om igen i olika former. Det andra skälet är att när du tar upp det i en matris, är det förmodligen det svåraste av de brutna totalproblemen.

Om du lär dig hur du tar itu med det i matrisen, vet du vad du behöver göra för att fixa dina summor i kort, i tabeller och i andra bilder där totaler kan gå sönder. Jag ska gå igenom en systematisk process för att fixa LuckyTemplates matrissummor som är trasiga och verkligen dela upp det efter komponenter.

I det här exemplet var måttet tillräckligt komplext att det bröt totalsummorna på ett ganska spektakulärt sätt. Jag ville börja med riktigt brutna totaler för att visa dig hur du åtgärdar även de värsta problemen med brutna totaler.

Innehållsförteckning

• Felaktiga summor i LuckyTemplates Matrix
• Fixa LuckyTemplates matrissummor med SWITCH TRUE Logic
• Felsökning med Tabular Editor 3
• Slutsats

Felaktiga summor i LuckyTemplates Matrix

Låt oss titta på sammanhanget för åtgärderna i detta exempel. För det första har vi ett mått som heter Spread Revenue , som är grenen av Total Opportunity Revenue and Lookup Scaling Factor .

Total Opportunity Intäkt är bara en enkelmäta, medan Lookup Scaling Factor är en mer komplicerad, typ av en multi-kriterium Lookup som vi baserar på en serie filtervillkor.

Detta är bara ett exempel på ett sätt som totaler kan gå sönder. Om vi ​​nu tar den spridda intäkterna och släpper den i fältet för matrisen, är detta vad som händer (se nedan).

Som du kan se, beräknar basraderna korrekt, men det totala antalet rader beräknar det inte. I många fall, när du har summor, delsummor och totalsummor, tar LuckyTemplates åtminstone en gissning. Och ofta är den gissningen fel, och du måste fixa summan.

Men i det här fallet ger LuckyTemplates bara motsvarande axelryckning. Den har ingen aning om vad dessa summor ska vara. Det har inte ens en gissning. Det märker bara dem som tomma. För att lösa detta måste vi bygga lite extra logik här som talar om för LuckyTemplates vad de ska göra i radsummorna, kolumnsummorna och totalsummorna.

I många fall, där du tittar på flera villkor, kan du göra detta som en kapsladpåstående. Men vi har en bättre konstruktion i LuckyTemplates som gör det mycket lättare att se logiken, vilket är påstående.

Fixa LuckyTemplates matrissummor med SWITCH TRUE Logic

Vi har ett SWITCH TRUE-uttalande som är byggt från det allmänna till det specifika, och jag vill visa dig varför detta inte fungerar. Vad SWITCH TRUE-satsen gör är att den går igenom vart och ett av villkoren. Det går ut ur den första, det är sant.

Och så, i det här fallet, går vi från det allmänna. Det står, "om djurets klass är i monotremes, pungdjur och placenta, då får det etiketten däggdjur". I det här exemplet är dessa de enda tre klasserna av däggdjur. Om det är ett däggdjur, kommer det att vara en av dessa tre typer.

Om vi ​​tittar på vad som händer kommer data in och vi går till SWITCH TRUE. Och om det är en av dessa klasser blir det "däggdjur". Detta betyder att det aldrig kommer att komma ner till detta kriterium här av pungdjur eller det vi vill ha, som är känguru eftersom dessa alla är däggdjur. Och så, om detta påstående är sant, kommer det att gå ut.

Om påståendet inte är sant, kommer de två påståendena inte att vara sanna. Det kommer att gå till standard, som inte är ett däggdjur. Så istället för att bygga ut från det allmänna till det specifika, måste du bygga ditt SWITCH TRUE-uttalande från det specifika till det allmänna och sedan catch-all i slutet.

Om vi ​​tar tillbaka detta till exemplet med att fixa matristotaler, är det egentligen samma sak. A här är detaljerna, vilket kommer att bli det första uttalandet i vår SWITCH TRUE. Och då har vi D som catch-all. I mitten har vi dessa två B- och C-villkor. B har kontext för kolumnen, men inte raden, medan C har kontext för raden, men inte kolumnen.

Låt oss nu hoppa in i Tabular Editor 3 (TE3), som verkligen är mitt favoritsätt nu för att felsöka och förstå åtgärder.

Felsökning med Tabular Editor 3

Jag kallar detta mått (nedan) Sprid intäkter med fasta summor. Den är ganska lång och ser ut som komplicerad DAX, men jag ska dela upp det här efter komponent.

Vi har här bara två variabler som i princip tar uppav vår korta månad och vår period, och det kommer att avgöra sammanhanget. Sedan har vi en virtuell tabell, som i grunden är en virtuell version av matrisen genom dettaochkonstruera.

Om vi ​​tittar på detta i en DAX-fråga kan du se att det i princip skapar alla möjliga kombinationer av period och kort månad, vilket är vad matrisen gör.

Inom Tabular Editor 3 finns det ett annat sätt att visualisera detta som kallas Pivot Grid. Den producerar en visualisering som är lika med den matrisvisualen i LuckyTemplates.

Om vi ​​går tillbaka till vårt mått i Expression Editor, måste vi bygga logiken som skapar totalsfälten. Och så, vi har detta SWITCH TRUE uttalande med, där vi testar för att se om det finns ett sammanhang i vart och ett av de två fälten som vi behöver sammanhang i.

Det första villkoret, som är från det mest specifika till det minst specifika, är det villkoret A, basraderna. Så, om vi har kontext för period och vi har kontext för kort månad, så använder vi bara måttet Spread Revenue eftersom det gav rätt resultat i dessa datarader.

Nu måste vi bygga logiken för B, det är där vi har sammanhang i kolumnen. Så vi har HASONEVALUE för kort månad, men inte för period. Nu vill vi tvinga fram logiken, ta den virtuella matrisen och ta vårt spridningsmått och sedan summera det över alla värden för Period.

Nästa sak vi har är baksidan, där vi har HASONEVALUE i Period, men inte i Short Month. Vi tar nuav den virtuella tabellen (måttet Spread Revenue), och vi summerar det över allakort månad.

Och så har vi slutligen ett catch-all-mått, vilket är om vi inte har sammanhang i någon av de två, så tar vi bara den totala summan av den virtuella tabellen.

Om vi ​​nu tar vårt mått för spridning av intäkter med fasta totaler till fälten och släpper det i värdena, får vi rätt totalsummor för radsummorna, kolumnsummorna och totalsummorna. SWITCH TRUE logiken går igenom och påtvingar all logik vi behöver för att få de korrekta totalerna.

Slutsats

I den här bloggen har jag visat dig hur du fixar felaktiga summor i LuckyTemplates-matrisen. Detta är en konstruktion som du kan lägga på ett bord eller på ett kort, där du bygger den virtuella logiken för basraderna, som vanligtvis kommer att fungera om du har ett korrekt mått. Och sedan, påtvinga bara den logik som du behöver för att tvinga fram den korrekta summan.

Det ser komplicerat ut men definitivt användbart. Jag hoppas att allt är klart. Du kan titta på hela videohandledningen nedan och kolla in länkarna för mer relaterat innehåll.

Med vänliga hälsningar!