Årsagen bag dette er, fordi de tilgængelige for brugerdefinerede kalendere giver brugerne mulighed for ganske nemt og effektivt at skrive en formel og opnå de resultater, de ønsker. Desværre med ikke-standardkalendere, for eksempel en 445-kalender, skal du faktisk skrive noget ekstra logik for at kunne opnå mest mulig tidsintelligens eller tidssammenligningstypeanalyse.
I denne tutorial vil jeg demonstrere nogle rene tidssammenligninger. Jeg vil tage dig igennem, hvordan du kan sammenligne en periode med en anden baseret på en uge eller et tal og ikke en bestemt dato.
Som følge heraf kan og vil du være i stand til at bruge det, du lærer på tværs af forskellige tidshorisonter. Derudover vil jeg gå et skridt videre og virkelig dykke ned i, hvordan vi kan analysere fra den ene uge til den anden på tværs af enhver tidsperiode. For eksempel kan det være en uge i en tidligere måned eller en uge til samme måned sidste år.
Så først vil jeg vise dig, hvad der sker, når du bruger tidsintelligensberegningen (DATEADD), og hvorfor det ikke virker. Vi er nødt til at bruge noget tilpasset logik for rent faktisk at få det til at fungere.
Det er nemt at lave en tidssammenligning med tidsintelligensfunktioner. I vores formel for Sales LY har vi for eksempel DATEADD- funktionen, som stort set gør det hele tiden i sammenligning. Vi kan lave en beregning for en dag, måned, kvartal og år. I dette tilfælde viser vi årstal.
Denne formel fungerer godt til en standardkalender. Som vi kan se af vores tabel, regner den korrekt samme dag i det næste år.
Men når vi bruger den samme formel til en brugerdefineret kalender, hvor vi har sagt kun et år og kun en uge at arbejde med, fungerer det ikke korrekt.
Vi kan se dette i den allerførste uge af 2015. Husk, at dette ikke stemmer overens med nogen kalenderuge, da vi laver en tilpasset kalender, så den første i denne måned i dette regnskabsår stemmer faktisk ikke over den første uge.
I teorien skulle man tro, at dette beløb vil være det samme som for den første uge i 2014, men det er ikke på grund af fejljusteringen og overlejringen af datoerne på dette økonomiske ugenummer, så vi har brug for noget tilpasset logik i her for at få dette til at fungere.
Tidssammenligningsanalyse for brugerdefinerede kalendere
Lad os nu gennemgå logikken, der kunne løse dette problem. Dette vil være gældende for enhver tilpasset kalendertabel. Teknikken er bare den samme. Når du først har forstået, hvordan det gøres, kan du nemt anvende det på din egen model og LuckyTemplates-rapporter.
I denne beregning for vores Sales LY – Custom bruger vi Variables ( VAR ), da det forenkler tingene meget. Derefter bruger vi SELECTEDVALUE til at bringe vores uge og år. Og så skriver vi vores formel, hvor vi stadig bruger BEREGN Total Salg, og sætter så logikken ind.
Vi bruger FILTER ALLE datoer ( kalender dagligt ), hele tabellen her. Derefter skriver vi vores logik og regner ud, om vores økonomiske ugenummer er lig med den aktuelle finansuge. Sådan sammenligner vi en økonomisk uge et år med året før. Og så isolerer vi også året ved at få vores VAR for år (CurrentFinYear) fratrukket med 1 .
Denne teknik giver os mulighed for at springe tilbage fra 2015 til 2014 for at få den pågældende uges tal og bringe det ind i den aktuelle kontekst af vores resultater. Vi placerer det derefter inde i denne tabel, og vi vil nu se, at antallet eller beløbet er korrekt.
Hvis vi hopper tilbage til den første uge, ser vi nøjagtig samme beløb.
Denne logik har opnået det, vi ønskede at opnå. Og så herfra kan vi forgrene os for at få mere indsigt.
Dette eksempel gælder for enhver brugerdefineret tabel. Alt du måske behøver er at erstatte variablerne, afhængigt af hvilken tidssammenligning du vil have, men det vil altid være ens logik.
Der er mange forskellige måder, hvorpå du i sidste ende kan bruge denne teknik. Det er afgørende at virkelig prøve og lære det godt. For sandheden er, at ved at kombinere alle disse, kan du faktisk opnå en masse ting, ikke kun denne særlige indsigt, men også mange andre.