LuckyTemplates Urenregistratie & Lonen DAX Oplossingen

In deze blog staat een LuckyTemplates urenstaat en de daarbij behorende loonkosten centraal. Ik ga je laten zien hoe je tijdgegevens en loontype kunt berekenen met behulp van DAX. Ik ga een DAX-oplossing demonstreren met behulp van metingen en een andere met berekende kolommen. Je kunt de volledige video van deze tutorial onderaan deze blog bekijken.

Dit voorbeeld kwam uit een , die we uitvoeren in LuckyTemplates. Dit is een real-life scenario dat we vaak tegenkomen in organisaties en bedrijven, en LuckyTemplates is precies de juiste tool om het werk gemakkelijker en sneller te maken.

Laten we er dus naar toe gaan.

Inhoudsopgave

• LuckyTemplates urenstaat en lonen: oplossing met berekende kolommen
• LuckyTemplates Urenstaat & Lonen: DAX-oplossing met behulp van maatregelen
• Herstel onjuist totalenpatroon
• Conclusie

LuckyTemplates urenstaat en lonen: oplossing met berekende kolommen

Voor de berekende DAX-oplossing met behulp van berekende kolommen, ga ik naar de tijdtabel en maak ik een meting, die ik CC-reguliere uren noem , om de reguliere uren te berekenen.

In deze formule haal ik de uren uit de tabel en zet ze in een variabele ( ). Vervolgens bereken ik het een feestdag, weekend of een gewone dag is. Met de functie maak ik gebruik van het datamodel om dat te bepalen, en vervolgens gebruik ik de twee variabelen (_IsHolidayDay en _IsWeekendDay ) om de derde te bepalen ( _IsRegularDay ).

Ten slotte gebruik ik een instructie waarbij ik controleer op de reguliere uren. De andere twee (vakanties en weekends) zullen zijn . En als het een gewone dag is, wil ik de uren terugbrengen tot acht uur, en dan gebruik ik de RETURN Result -constructie.

Ik zal ongeveer hetzelfde doen voor de formule voor overuren ( CC-Overtime Hours ) – ik zal alleen de SWITCH TRUE-verklaring wijzigen. Hiermee worden de uren voor een weekenddag geretourneerd. Als het een gewone dag is, worden de uren boven de acht uur geretourneerd.

Voor de vakantie-uren worden alle uren geretourneerd als het een vakantiedag is, en blanco's als het een weekenddag of een gewone dag is.

Laten we nu verder gaan met de lonen. Voor de loonformule voor reguliere uren gebruik ik de berekende kolom die ik zojuist heb gemaakt voor reguliere uren. Ik ga het juiste loon bepalen door het WageType , Straight Time, te gebruiken .

Ik haal het uurloon van de werknemers uit het gegevensmodel en vervolgens gebruik ik een om de vermenigvuldiger uit de losgekoppelde loonsoortentabel te krijgen die moet worden toegepast. En tot slot bereken ik de variabele Resultaat , en dan heb ik het RETURN Resultaat aan het eind.

Voor overuren verander ik gewoon de loonsoort in Anderhalf uur .

Ik doe iets soortgelijks voor vakantiegeld, maar ik verander de loonsoort in Dubbele Tijd .

Ten slotte doe ik een eenvoudige som om de totale waarde voor mij beschikbaar te maken.

Wanneer ik deze kolommen naar het rapport sleep, kunnen we de resultaten zien.

LuckyTemplates Urenstaat & Lonen: DAX-oplossing met behulp van maatregelen

Ik ga vrijwel hetzelfde doen als voor berekende kolommen, maar deze keer ga ik een kleine wijziging aanbrengen.

Ik heb geen directe toegang tot de tijdwaarde uit de tabel, dus ik ga hier een gebruiken om de uren te krijgen die zijn gekoppeld aan de specifieke tijdsinvoer die in de visual wordt weergegeven. Verder is de code dezelfde als voor de versie met berekende kolommen.

Ik heb iets soortgelijks gedaan voor de overuren en de vakantie-uren. Het zijn dezelfde regels als voor berekende kolommen.

Wat de lonen betreft, deze worden grotendeels op dezelfde manier berekend. Het enige verschil met de berekende kolommen is de variabele voor uren. Ik gebruik de meetwaarde die ik heb berekend. Hetzelfde doe ik ook voor het overwerkloon en hetzelfde voor het vakantieloon.

Vervolgens schrijf ik een eenvoudige sommaat voor het totale loon.

En nu voeg ik deze maatregelen toe aan de tabel, zodat we de resultaten kunnen zien. Merk op dat geen van de metingen totalen toont. Om de totale waarden voor de metingen hier te zien, ga ik het patroon voor onjuiste totalen corrigeren gebruiken . Om dit te doen, moet ik metingen maken die virtuele tabellen gebruiken om de fysieke tabel na te bootsen die ik hier heb.

Herstel onjuist totalenpatroon

Om dit op te lossen, moet ik metingen maken die virtuele tabellen gebruiken om de fysieke tabel na te bootsen die ik hier heb. Dus voor het totale aantal uren heb ik constructie gebruikt om een ​​virtuele tabel te maken met een tijd-ID en de uren. En dan gebruik ik over de virtuele tafel om de waarde te berekenen.

Ik sleep dat naar de onderstaande tabel, en nu kunnen we het totale aantal uren zien.

Ik ga hetzelfde doen voor de lonen, waar ik en SUMMARIZE zal gebruiken . gebruiken voor de meting die ik al heb gemaakt en SUMX voor de virtuele tabel.

Ik voeg dat dan toe aan de tabel hier, en we kunnen zien dat we nu het totale loon hebben.

Een ander ding is dat wanneer ik mijn totale loonmaat in een eenvoudig staafdiagram met afdelingen en loonsoorten plaats, je zult zien dat ik hier geen waarden krijg.

Dit maakt deel uit van het opgeloste probleem met onjuiste totalen. En een van de beste manieren die ik heb gevonden om dit op te lossen, is door de virtuele tabel te gebruiken en de maat te wijzigen.

Dus ik haal degene zonder de virtuele tafel eruit en ik voeg degene met de virtuele tafel toe.

LuckyTemplates berekende kolom versus meting: een vergelijking
berekende kolommen LuckyTemplates: tips en best practices
Meet vertakking: LuckyTemplates-ontwikkelingsstrategie

Conclusie

Beide DAX-oplossingen zijn geweldig voor deze LuckyTemplates-uitdaging voor urenregistratie en lonen. Ze hebben echter ook hun voor- en nadelen.

De voordelen van het gebruik van maatregelen zijn dat ze best practice zijn. Ze worden niet berekend wanneer het model wordt vernieuwd, maar alleen wanneer de meting daadwerkelijk wordt gebruikt in een visual. Het nadeel voor hen is dat er een klein beetje extra DAX-code nodig is wanneer we met virtuele tabellen werken om dingen weer te geven om ze correct te laten berekenen. Maar het is helemaal niet erg.

Wat berekende kolommen betreft, vind ik dat ze gemakkelijker te leren en te visualiseren zijn. Ze zijn een zeer vertrouwde startplaats voor degenen die uit Excel komen. Een van de beperkingen van berekende kolommen is echter dat ze daadwerkelijk fysiek in het gegevensmodel worden gemaakt en dat ze de omvang van uw model vergroten, waardoor de prestaties van uw rapport afnemen.

En de algemene regel is dat u geen berekende kolommen op feitentabellen moet maken. Als u een berekende kolom moet maken, probeer dit dan op dimensietabellen te doen.

Ik gebruik persoonlijk berekende kolommen om categorisatie toe te voegen aan sommige dimensietabellen, waar veel dimensies moesten worden weergegeven.

Ik hoop dat je deze leuk vond en veel hebt geleerd. Je kunt de volledige video van deze tutorial hieronder bekijken.

Proost!

Greg