LuckyTemplates-matrix | Matrixtotalen in LuckyTemplates corrigeren

Voor deze zelfstudie laat ik u zien hoe u LuckyTemplates-matrixtotalen kunt corrigeren, met name het corrigeren van totalen en subtotalen als de metingen die u maakt oorspronkelijk niet de juiste resultaten opleveren. Je kunt de volledige video van deze tutorial onderaan deze blog bekijken.

Er zijn twee redenen waarom ik dit probleem wilde aanpakken. Een daarvan is dat het vrij vaak voorkomt. Het is iets dat veel voorkomt op het . We zien deze vraag keer op keer herhaald worden in verschillende vormen. De tweede reden is dat wanneer je het behandelt in de context van een matrix, het waarschijnlijk de moeilijkste van de gebroken totalen-problemen is.

Als u leert hoe u dit in de matrix moet adresseren, weet u wat u moet doen om uw totalen in kaarten, tabellen en andere visuele elementen vast te leggen waar totalen kunnen breken. Ik ga een systematisch proces doorlopen om LuckyTemplates-matrixtotalen op te lossen die zijn gebroken en die echt opsplitsen in componenten.

In dit voorbeeld was de meting complex genoeg om de totalen op een behoorlijk spectaculaire manier te breken. Ik wilde beginnen met echt gebroken totalen om je te laten zien hoe je zelfs de ergste problemen met gebroken totalen kunt oplossen.

Inhoudsopgave

• Onjuiste totalen in LuckyTemplates-matrix
• LuckyTemplates-matrixtotalen corrigeren met SWITCH TRUE Logic
• Debuggen met behulp van de Tabular Editor 3
• Conclusie

Onjuiste totalen in LuckyTemplates-matrix

Laten we eens kijken naar de context van de maatregelen in dit voorbeeld. Ten eerste hebben we een meting genaamd Spread Revenue , wat de tak is van Total Opportunity Revenue en Lookup Scaling Factor .

De Total Opportunity Revenue is slechts een simpele maatstaf, terwijl de Lookup Scaling Factor een meer gecompliceerde, soort multi-criteria Lookup is die we baseren op een reeks filtervoorwaarden.

Dit is slechts een voorbeeld van een manier waarop totalen kunnen breken. Als we nu die gespreide opbrengst nemen en deze in het veld voor de matrix plaatsen, gebeurt er het volgende (zie hieronder).

Zoals u kunt zien, berekenen de basisrijen correct, maar de totaalrijen berekenen het niet. In veel gevallen, wanneer u totalen, subtotalen en eindtotalen heeft, zal LuckyTemplates op zijn minst een gokje wagen. En vaak is die gok verkeerd, en moet je de totalen corrigeren.

Maar in dit geval geeft LuckyTemplates gewoon het equivalent van schouderophalen. Het heeft geen idee wat die totalen zouden moeten zijn. Het heeft niet eens een vermoeden. Het labelt die gewoon als blanco. Om dit op te lossen, moeten we hier wat aanvullende logica bouwen die LuckyTemplates vertelt wat er moet gebeuren in de rijtotalen, de kolomtotalen en de eindtotalen.

In veel gevallen, wanneer u naar meerdere voorwaarden kijkt, kunt u dit doen als een geneste -instructie. Maar we hebben een betere constructie in LuckyTemplates die het een stuk eenvoudiger maakt om de logica te zien, namelijk de instructie.

LuckyTemplates-matrixtotalen corrigeren met SWITCH TRUE Logic

We hebben een SWITCH TRUE-statement dat is opgebouwd uit het algemene naar het specifieke, en ik wil je laten zien waarom dit niet werkt. Wat de SWITCH TRUE-instructie doet, is dat deze elk van de voorwaarden doorloopt. Het komt uit de eerste die waar is.

En dus gaan we in dit geval uit van de generaal. Er staat: "als de klasse van het dier bestaat uit monotremes, buideldieren en placenta, dan krijgt het het label zoogdier". In dit voorbeeld zijn dit de enige drie klassen zoogdieren. Als het een zoogdier is, wordt het een van deze drie typen.

Als we kijken naar wat er gebeurt, komen de gegevens binnen en gaan we naar SWITCH TRUE. En als het een van deze klassen is, wordt het "zoogdier". Dit betekent dat het hier nooit zal komen tot dit criterium van buideldier of degene die we willen, en dat is kangoeroe omdat dit allemaal zoogdieren zijn. En dus, als deze bewering waar is, gaat het eruit.

Als de bewering niet waar is, zullen de twee beweringen niet waar zijn. Het gaat naar de standaardinstelling, wat geen zoogdier is. Dus in plaats van uit te bouwen van het algemene naar het specifieke, moet je je SWITCH TRUE-statement opbouwen van het specifieke naar het algemene , en dan de catch-all aan het einde.

Als we dit terugnemen naar het voorbeeld van het vastleggen van matrixtotalen, is het eigenlijk hetzelfde. De A hier is de details, wat de eerste verklaring zal zijn in onze SWITCH TRUE. En dan hebben we D als verzamelpunt. In het midden hebben we deze twee B- en C-voorwaarden. B heeft context voor de kolom, maar niet voor de rij, terwijl C context heeft voor de rij, maar niet voor de kolom.

Laten we nu eens kijken naar de Tabular Editor 3 (TE3), wat nu echt mijn favoriete manier is om metingen te debuggen en te begrijpen.

Debuggen met behulp van de Tabular Editor 3

Ik noem deze maatregel (hieronder) Spread Revenue with Fixed Totals. Het is vrij lang en ziet eruit als gecompliceerde DAX, maar ik ga dit per component opsplitsen.

van onze korte maand en onze periode oppikken , en dat gaat de context bepalen. Dan hebben we een virtuele tabel, die in feite een virtuele versie van de matrix is ​​via deze en constructie.

Als we dit in een DAX-query bekijken, kunt u zien dat deze in feite elke mogelijke combinatie van Periode en Korte Maand creëert, wat de matrix doet.

Binnen de Tabular Editor 3 is er een andere manier om dit te visualiseren, de Pivot Grid. Het produceert een visual die gelijk is aan die matrixvisual in LuckyTemplates.

Terugkomend op onze meting in de Uitdrukkingseditor, moeten we de logica bouwen die de totalenvelden maakt. En dus hebben we deze SWITCH TRUE-instructie met , waarin we testen of er al dan niet een context is in elk van de twee velden waarin we context nodig hebben.

De eerste voorwaarde, die van meest specifiek naar minst specifiek is, is die voorwaarde A, de basisrijen. Dus als we context hebben voor Periode en we hebben context voor Korte maand, dan gebruiken we gewoon de Spread Revenue-maatstaf omdat dat de juiste resultaten opleverde in die gegevensrijen.

Nu moeten we de logica voor B bouwen, waar we de context in de kolom hebben. We hebben dus HASONEVALUE voor Korte maand, maar niet voor Periode. Nu willen we de logica forceren, de virtuele matrix nemen, onze Spread Revenue-maatstaf nemen en deze vervolgens optellen over alle waarden van Periode.

Het volgende dat we hebben is de keerzijde, waar we HASONEVALUE hebben in Periode, maar niet in Short Month. We nemen nu de van de virtuele tabel (Spread Revenue-meting) en tellen deze op voor alle van Short Month.

En tot slot hebben we de allesomvattende maatstaf, die inhoudt dat als we geen context hebben in een van de twee, we gewoon de totale som van de virtuele tafel nemen.

Als we nu onze meting Gespreide omzet met vaste totalen naar de velden brengen en deze in de waarden laten vallen, krijgen we de juiste totalen voor de rijtotalen, de kolomtotalen en de eindtotalen. De SWITCH TRUE-logica gaat door en legt alle logica op die we nodig hebben om de juiste totalen te krijgen.

Unieke subtotalen maken in LuckyTemplates-tabellen
Onjuiste totalen corrigeren DAX-metingen gebruiken in LuckyTemplates
Geavanceerde logica gebruiken in LuckyTemplates om uw totalen te corrigeren

Conclusie

In deze blog heb ik je laten zien hoe je onjuiste totalen in de LuckyTemplates-matrix kunt corrigeren. Dit is een constructie die je op een tafel of op een kaart kunt leggen, waar je de virtuele logica voor de basisrijen bouwt, die normaal gesproken zal werken als je een juiste maat hebt. En leg dan gewoon de logica op die je nodig hebt om het juiste totaal te forceren.

Het ziet er ingewikkeld uit, maar is zeker nuttig. Ik hoop dat dit allemaal duidelijk is. Je kunt de volledige video-tutorial hieronder bekijken en de links bekijken voor meer gerelateerde inhoud.

Al het beste!