LuckyTemplates Matrix | Slik fikser du matrisetotaler i LuckyTemplates

For denne opplæringen skal jeg vise deg hvordan du fikser LuckyTemplates matrisetotaler, spesielt å fikse totaler og deltotaler hvis målene du oppretter ikke gir de riktige resultatene opprinnelig. Du kan se hele videoen av denne opplæringen nederst på denne bloggen.

Det er to grunner til at jeg ønsket å løse dette problemet. Den ene er at det forekommer ganske ofte. Det er noe som kommer opp mye i. Vi ser dette spørsmålet gjentatt om og om igjen i forskjellige former. Den andre grunnen er at når du adresserer det i sammenheng med en matrise, er det sannsynligvis det vanskeligste av de brutte totalproblemene.

Hvis du lærer hvordan du adresserer det i matrisen, vil du vite hva du må gjøre for å fikse summene dine i kort, i tabeller og i andre visuelle elementer der totaler kan gå i stykker. Jeg skal gå gjennom en systematisk prosess for å fikse LuckyTemplates matrisetotaler som er brutt og virkelig bryte det ned etter komponenter.

I dette eksemplet var tiltaket komplekst nok til at det brøt summene på en ganske spektakulær måte. Jeg ønsket å starte med virkelig brutte totaler for å vise deg hvordan du kan fikse selv de verste problemene med brutte totaler.

Innholdsfortegnelse

• Feil totalsum i LuckyTemplates-matrisen
• Fikse LuckyTemplates matrisetotaler med SWITCH TRUE Logic
• Feilsøking ved hjelp av tabellredigering 3
• Konklusjon

Feil totalsum i LuckyTemplates-matrisen

La oss se på konteksten til tiltakene i dette eksemplet. For det første har vi et mål kalt Spread Revenue , som er grenen av Total Opportunity Revenue and Lookup Scaling Factor .

Den totale mulighetsinntekten er bare en enkelmåle, mens Lookup Scaling Factor er et mer komplisert, slags multikriteria-oppslag som vi baserer på en rekke filterforhold.

Dette er bare et eksempel på en måte som totaler kan bryte. Hvis vi nå tar den Spread Revenue og slipper den inn i feltet for matrisen, er dette hva som skjer (se nedenfor).

Som du kan se, beregner basisradene riktig, men de totale radene beregner det ikke. I mange tilfeller, når du har totalsummer, delsummer og totalsummer, vil LuckyTemplates i det minste ta en gjetning. Og ofte er den gjetning feil, og du må fikse totalsummene.

Men i dette tilfellet gir LuckyTemplates bare det tilsvarende skuldertrekket. Den har ingen anelse om hva disse summene skal være. Det har ikke engang en gjetning. Den merker bare de som tomme. For å løse dette, må vi bygge litt ekstra logikk her som forteller LuckyTemplates hva de skal gjøre i radtotalene, kolonnetotalene og totalsummene.

I mange tilfeller, der du ser på flere forhold, kan du gjøre dette som en nestetuttalelse. Men vi har en bedre konstruksjon i LuckyTemplates som gjør det mye lettere å se logikken, som er uttalelse.

Fikse LuckyTemplates matrisetotaler med SWITCH TRUE Logic

Vi har et SWITCH TRUE-uttalelse som er bygget fra det generelle til det spesifikke, og jeg vil vise deg hvorfor dette ikke fungerer. Det SWITCH TRUE-utsagnet gjør er at det går gjennom hver av betingelsene. Det går ut av den første, det er sant.

Og så, i dette tilfellet, går vi fra det generelle. Det står, "hvis dyrets klasse er i monotremes, pungdyr og placenta, så får det etiketten pattedyr". I dette eksemplet er dette de eneste tre klassene av pattedyr. Hvis det er et pattedyr, kommer det til å være en av disse tre typene.

Hvis vi ser på hva som skjer, kommer dataene inn og vi går til SWITCH TRUE. Og hvis det er en av disse klassene, blir det "pattedyr". Dette betyr at det aldri kommer til å komme ned til dette kriteriet her av pungdyr eller det vi vil ha, som er kenguru fordi disse alle er pattedyr. Og så, hvis denne uttalelsen er sann, kommer den til å gå ut.

Hvis påstanden ikke er sann, vil ikke de to påstandene være sanne. Det kommer til å gå til standard, som ikke er et pattedyr. Så i stedet for å bygge ut fra det generelle til det spesifikke, må du bygge SWITCH TRUE-utsagnet ditt fra det spesifikke til det generelle , og deretter oppsamlingen på slutten.

Hvis vi tar dette tilbake til eksemplet med å fikse matrisetotaler, er det egentlig det samme. A-en her er detaljene, som kommer til å være det første utsagnet i vår SWITCH TRUE. Og så har vi D som catch-all. I midten har vi disse to B- og C-forholdene. B har kontekst for kolonnen, men ikke raden, mens C har kontekst for raden, men ikke kolonnen.

La oss nå hoppe inn i Tabular Editor 3 (TE3), som egentlig er min favorittmåte nå for å feilsøke og forstå tiltak.

Feilsøking ved hjelp av tabellredigering 3

Jeg kaller dette målet (nedenfor) Spredningsinntekt med faste totaler. Den er ganske lang og ser ut som komplisert DAX, men jeg skal dele dette opp etter komponent.

Vi har her bare to variabler som i utgangspunktet fanger oppav vår korte måned og vår periode, og det kommer til å bestemme konteksten. Deretter har vi en virtuell tabell, som i utgangspunktet er en virtuell versjon av matrisen gjennom detteogkonstruere.

Hvis vi ser på dette inne i en DAX-spørring, kan du se at den i utgangspunktet skaper alle mulige kombinasjoner av Periode og Short Month, som er det matrisen gjør.

Innenfor Tabular Editor 3 er det en annen måte å visualisere dette på, kalt Pivot Grid. Den produserer en visualisering som er lik den matrisevisualen i LuckyTemplates.

Går tilbake til målet vårt i Expression Editor, må vi bygge logikken som lager totalfeltene. Og så, vi har denne SWITCH TRUE-uttalelsen med, der vi tester for å se om det er en kontekst i hvert av de to feltene vi trenger kontekst i.

Den første betingelsen, som er fra den mest spesifikke til den minst spesifikke, er den betingelsen A, grunnradene. Så hvis vi har kontekst for Periode og vi har kontekst for Kort måned, bruker vi bare Spread Revenue-målet fordi det ga de riktige resultatene i disse dataradene.

Nå må vi bygge logikken for B, som er der vi har kontekst i kolonnen. Så vi har HASONEVALUE for kort måned, men ikke for periode. Nå ønsker vi å fremtvinge logikken, ta den virtuelle matrisen og ta vårt mål for spredningsinntekter, og deretter summere det på tvers av alle verdiene til Periode.

Det neste vi har er baksiden, der vi har HASONEVALUE i Periode, men ikke i Short Month. Vi tar nåav den virtuelle tabellen (Spread Revenue-mål), og vi summerer det over alleav kort måned.

Og så til slutt, vi har catch-all-målet, som er at hvis vi ikke har kontekst i noen av de to, så tar vi bare den totale summen av den virtuelle tabellen.

Hvis vi nå tar vårt mål for spredningsinntekter med faste totaler til feltene og slipper det inn i verdiene, får vi de riktige totalsummene for radtotalene, kolonnetotalene og totalsummene. SWITCH TRUE-logikken går gjennom og påtvinger all logikken vi trenger for å få de riktige totalene.

Konklusjon

I denne bloggen har jeg vist deg hvordan du fikser feil totalsum i LuckyTemplates-matrisen. Dette er en konstruksjon som du kan pålegge et bord eller på et kort, der du bygger den virtuelle logikken for basisradene, som vanligvis vil fungere hvis du har et riktig mål. Og så er det bare å pålegge logikken du trenger for å tvinge frem den riktige totalen.

Det ser komplekst ut, men definitivt nyttig. Jeg håper alt er klart. Du kan se hele videoopplæringen nedenfor og sjekk ut lenkene for mer relatert innhold.

Beste ønsker!