Datenmodell Archive | THE SELF-SERVICE-BI BLOG Wir lieben Microsoft Power BI Mon, 14 Apr 2025 07:35:03 +0000 de hourly 1 https://wordpress.org/?v=6.8 https://ssbi-blog.de/wp-content/uploads/2019/10/Favicon-150x150.png Datenmodell Archive | THE SELF-SERVICE-BI BLOG 32 32 Ein vom Kalenderjahr abweichendes Geschäftsjahr mit Power BI abbilden, Teil2 https://ssbi-blog.de/blog/business-topics/ein-vom-kalenderjahr-abweichendes-geschaeftsjahr-mit-power-bi-abbilden-teil2/ Sun, 08 Apr 2018 20:00:47 +0000 http://ssbi-blog.de/?p=3275 In meinem letzten Post habe ich gezeigt, wie man mit der TOTALYTD()-Funktion in Power BI ein vom Kalenderjahr abweichendes Geschäftsjahr berücksichtigt. Dies führt in 11 von 12 Monaten zum korrekte Ergebnis. Doch wie muss ich vorgehen, wenn der Monat, in dem mein Geschäftsjahr endet, gerade der Februar ist. Oder anders: Wie berücksichtige ich Schaltjahre bei […]

Der Beitrag Ein vom Kalenderjahr abweichendes Geschäftsjahr mit Power BI abbilden, Teil2 erschien zuerst auf THE SELF-SERVICE-BI BLOG.

]]>
In meinem letzten Post habe ich gezeigt, wie man mit der TOTALYTD()-Funktion in Power BI ein vom Kalenderjahr abweichendes Geschäftsjahr berücksichtigt. Dies führt in 11 von 12 Monaten zum korrekte Ergebnis. Doch wie muss ich vorgehen, wenn der Monat, in dem mein Geschäftsjahr endet, gerade der Februar ist. Oder anders: Wie berücksichtige ich Schaltjahre bei dieser Kalkulation? Dieser Fage gehe ich im aktuellen Beitrag nach.

Als Abonnent meines Newsletters erhältst Du die Beispieldateien zu den Beiträgen dazu. Hier geht’s zum Abonnement des Newsletters!

Die Ausgangssituation

Die Basis für diese Lösung ist, wie auch im vorangegangenen Beitrag, das folgende Datenmodell:

Die Basis: Das Datenmodell, Power Pivot, Excel-Datenmodell, Power BI Desktop
Die Basis: Das Datenmodell

Da sich Beginn und Ende des Geschäftsjahres verändert haben, muss ich eine kleine Anpassung des Datenmodells vornehmen.

Anpassung der Geschäftsjahresspalte mittels Power Query

Wie schon im letzten Post, muss die Spalte Geschäftsjahr jeden Kalendermonat dem entsprechenden Geschäftsjahr zuordnen. Um dies anzupassen, gehe ich in Power Query in die Abfrage Datum und ändere die Berechnung der Spalte Geschäftsjahr, wie im folgenden Screenshot zu sehen ist:

Power Query: Das Geschäftsjahr soll im März beginnen, Power Query, Power BI Desktop
Power Query: Das Geschäftsjahr soll im März beginnen

Basierend auf diesem Datenmodell gilt es nun, ein entsprechendes DAX-Measure zu schreiben, das dem Schaltjahr Rechung trägt.

Die Lösung: Ein DAX-Measure, das dem Schaltjahr Rechnung trägt

Um ein DAX-Measure zu schreiben, das auch bei Schaltjahren den korrekten Year-to-date-Wert kalkuliert, greife ich auf eine Lösung zurück, welche die Kollegen von SQLBI auf ihrer Website DAXPatterns.com als Vorlage erstellt haben. Der folgende DAX-Code kalkuliert den Year-to-date-Wert auch dann richtig, wenn das Geschäftsjahr im Februar endet:

=
CALCULATE (
    SUM ( Umsaetze[Wert] );
    FILTER (
        ALL ( Datum );
        AND (
Datum[Datum] <= MAX ( Datum[Datum] );
Datum[Geschäftsjahr] = MAX ( Datum[Geschäftsjahr] )
        )
    )
)

DAX Formatter by SQLBI

Auf diese Weise umgehe ich das Problem, dass bei der TOTALYTD()-Funktion im letzten Parameter ein einzelner Wert, als Jahresendwert angegeben werden muss. Dies führt im Falle des Februar zu Problemen, da dieser am 28.02., oder am 29.02. enden kann.

Der Code mag auf den ersten Blick verwirren. So ging es mir zumindest, als ich ihn vor Jahren das erste Mal gesehen habe. Daher widme ich den restlichen Beitrag der Funktionsweise dieses Measures, um ein grundlegendes Verständnis dafür zu erzeugen. Falls Du also „nur“ an einer Lösung Deines Problems interessiert bist und Dich ein tieferes Verständnis dieser Lösung nicht interessiert, dann kannst Du an dieser Stelle aufhören weiterzulesen. Nimm Dir den oben stehenden Code, passe ihn an Dein Datenmodell an und fertig. Falls Du verstehen möchtest, was dieser Code tut, dann schnall Dich jetzt besser an. Es gibt viel zu betrachten.

Die Funktionsweise des Measures verstehen

Meiner Ansicht nach besteht die beste Möglichkeit, dieses Measure zu verstehen darin, es gemeinsam zu entwickeln. Genau dies werde ich jetzt mit Dir machen.

Bei DAX dreht sich alles um Filter

Jedes DAX-Measure wird im Rahmen eines bestimmten, sog. Evaluierungskontextes berechnet. Ein Bestandteil dieses Evaluierungskontextes, ist der sog. Filterkontext. Was darunter zu verstehen ist, kann zumindest oberflächlich einfach beantwortet werden. Schau Dir folgende Pivottabelle an:

Der Filterkontext in DAX, am Beispiel einer Pivottabelle, Power Pivot, Power BI Desktop, Excel Datenmodell
Der Filterkontext in DAX, am Beispiel einer Pivottabelle

Filter in DAX werden immer durch Tabellen definiert. Betrachte ich den rot umrahmten Wert 1.827,00 €, so ist der Filter, der diesen Wert definiert, über drei Spalten im Datenmodell definiert:

  • Datum[Geschaeftsjahr] = 2017
  • Datum[MonatImKalender] = Mai 2017
  • Verkaufsstellen[Verkaufsstelle] = VK01

Diese drei Filterkriterien filtern die Datensätze in den Tabellen Datum und Verkaufstellen ein. Über die im Datenmodell befindlichen Beziehungen wirken sich diese Filter von den beiden Tabellen Datum und Verkaufsstellen auf die Tabelle Umsaetze aus und grenzen damit auch die dort befindlichen Datensätze ein. Visuell kann man sich das wie folgt vorstellen:

Die in den Dimensionstabellen wirkenden Filter, wirken sich über die bestehenden Beziehungen auf die Tabelle Umsaetze aus, Power Pivot, Excel-Datenmodell
Die in den Dimensionstabellen wirkenden Filter, wirken sich über die bestehenden Beziehungen auf die Tabelle Umsaetze aus

Auf diese Art und Weise werden diejenigen Datensätze selektiert, die dann den Wert 1.827,00 € ergeben. Mein Ziel ist jedoch, den durch die Pivottabelle gesetzten Filter auf der Datumstabelle zu verändern. Schließlich soll der entsprechende Wert nicht die Werte des angezeigten Monats (hier Mai) wiedergeben, sondern alle Werte von März bis zum angezeigten Monat. Im aktuellen Fall soll der Filter also wie folgt aussehen:

  • Datum[Geschaeftsjahr] = 2017
  • Datum[MonatImKalender] = März oder April oder Mai 2017
  • Verkaufsstellen[Verkaufsstelle] = VK01

Die einzige DAX-Funktion, die es bewerkstelligen kann, den bestehenden Filterkontext zu überwinden, ist die Funktion CALCULATE(). Ihre Schwesterfunktion CALCULATETABLE() ist hierzu auch in der Lage, soll an dieser Stelle jedoch vernachlässigt werden.

Mit CALCULATE() den Filterkontext überwinden

Damit wäre erklärt, dass CALCULATE() der Schlüssel zum Erfolg ist. Mein erster Ansatz für ein Measure sieht also wie folgt aus:

=
CALCULATE ( SUM ( Umsaetze[Wert] ) )
DAX Formatter by SQLBI

Setze ich nun dieses Measure in meine Pivottabelle ein, dann sieht das Ergebnis so aus:

Noch überwindet CALCULATE den Filterkontext nicht, Power Pivot, Excel-Datenmodell, Power BI Desktop
Noch überwindet CALCULATE den Filterkontext nicht

Wie Du sehen kannst, ist das Ergebnis immer noch das gleiche. Somit hat diese DAX-Formel (noch) nicht den gewünschten Effekt gebracht. Schauen wir uns doch mal die Syntax von CALCULATE() an:

CALCULATE(<Ausdruck>;<Filter1>;<Filter2>…)

CALCULATE() nimmt einen Ausdruck auf (in meinem Beispiel SUM ( Umsaetze[Wert] ) ) und ermittelt diesen unter Zuhilfenahme diverser optionaler Filterkriterien. Diese Filterkriterien sind der Schlüssel zum Erfolg.

Die Filterkriterien von CALCULATE definieren

Was ich nun erreichen möchte ist das korrekte Definieren der Filterkriterien für die CALCULATE()-Funktion. Die Ausgangssituation hierfür sieht also wie folgt aus:

=
CALCULATE ( SUM ( Umsaetze[Wert] )Filterkriterien )
DAX Formatter by SQLBI

Da in meinem Datenmodell zwischen den Tabellen Datum und Umsaetze eine 1:n-Beziehung herrscht (die Linien, die die Tabellen im Datenmodell miteinander verbinden symbolisieren dies) wirkt sich ein Filter auf der Tabellen Datum automatisch auf die Tabelle Umsaetze aus. Meine DAX-Formel muss jetzt folgendes schaffen: Obwohl der Filterkontext (durch die Pivotüberschrift) auf Monat Mai eingrenzt, muss der Filterkontext in meinem Measure MärzApril und Mai beinhalten.

Den Filterkontext der Pivot überwinden, Power Pivot, Excel-Datenmodell, Power BI Desktop, DAX
Den Filterkontext der Pivot überwinden

Um einen entsprechenden Filter in meiner CALCULATE()-Funktion zu erzeugen, nutze ich die Funktion FILTER().

Die Nutzung der Funktion FILTER(), um die Filter in CALCULATE() zu definieren

Die DAX-Funktion FILTER() hat folgende Syntax:

FILTER(<Tabelle>;<Filter>)
Dieser Funktion muss eine Tabelle übergeben werden, die dann entsprechend gefiltert wird.

FILTER() verbindet zwei nützliche Eigenschaften:

  1. Es handelt sich um eine Tabellenfunktion. Diese Funktion gibt also eine Tabelle zurück, die dann als Filterkriterum in CALCULATE genutzt werden kann.
  2. FILTER() ist zugleich ein sog. Iterator und ist daher in der Lage, auf der Tabelle (erster Parameter) zeilenweise Filteroperationen auszuführen.

Mit der Kenntnis um die Funktion FILTER() und dem Wissen, dass ich auf Basis der Tabelle Datum filtern muss, kann ich meine bisheriges Measure wie folgt erweitern:

=
CALCULATE ( SUM ( Umsaetze[Wert] )FILTER ( Datum; FILTERKRITERIEN ) )
DAX Formatter by SQLBI

Die Filterfunktion wird die Tabelle Datum also zeilenweise durchlaufen und nach bestimmten Filterkriterien filtern, die ich bisher noch nicht definiert habe. Diese definiere ich jetzt.

Die Filterkriterien für die Funktion FILTER() definieren

Damit die Funktion FILTER() eine korrekt eingeschränkte Tabelle zurückliefern kann, die für die CALCULATE()-Funktion als Filter dient, müssen nun die Filterkriterien in der FILTER()-Funktion definiert werden. Ich beschreibe zunächst in Worten, wie dies inhaltlich aussehen soll, bevor ich es als Formel definiere:

=
FILTER (

führe alle nachfolgend definierten Filteroperationen zeilenweise auf der gesamten Tabelle Datum aus;
           Monat in der entsprechenden Zeile in Tabelle Datum <= Monat in der Überschrift der Pivot UND
           Geschäftsjahr in der entsprechenden Zeile in Tabelle Datum = Geschäftsjahr (ausgewählt über den Datenschnitt in der Pivot)
)

Verformelt sieht das ganze dann wie folgt aus:

=
FILTER (
    Datum;
    AND (
Datum[MonatImJahr] <= MAX ( Datum[MonatImJahr] );
Datum[Geschäftsjahr] = MAX ( Datum[Geschäftsjahr] )
    )
)

Was an dieser Formel wohl am schwierigsten zu verstehen ist, sind die folgenden zwei Sachverhalte:

  1. Der Ausdruck MAX ( Datum[Geschäftsjahr] ) ermittelt den über den Datenschnitt erzeugten Filter auf der Spalte Datum[Geschaeftsjahr], in meinem Beispiel 2017
  2. Der bisher genutzte Beispielwert 1.827,00 € hat bzgl. der Datumstabelle den Filterkontext Datum[MonatImKalender] = „Mai 2017“, denn die Spalte Datum[MonatImKalender] wird als Spaltenüberschrift für die Pivot benutzt und hat beim Wert 1.827,00 € den Wert Mai 2017. Dadurch ist die Datumstabelle bereits auf Zeilen eingeschränkt, die zum Mai 2017 gehören. Der Ausdruck MAX ( Datum[MonatImJahr] ) ermittelt jetzt auf Basis dieser gefilterten Datumstabelle den maximalen Wert der Spalte Datum[MonatImJahr], der für das genannte Beispiel 5 ergibt.

Der folgende Screenshot veranschaulicht dies noch einmal:

 

Zeilenweises Arbeiten der FILTER()-Funktion in DAX, Power Pivot, Excel Datenmodell, Power BI Desktop
Zeilenweises Arbeiten der FILTER()-Funktion in DAX

Basierend auf den nun erstellten Filterkriterien, sieht das Measure wie folgt aus:

=
CALCULATE (
    SUM ( Umsaetze[Wert] );
    FILTER (
        Datum;
        AND (
Datum[MonatImJahr] <= MAX ( Datum[MonatImJahr] );
Datum[Geschäftsjahr] = MAX ( Datum[Geschäftsjahr] )
        )
    )
)

DAX Formatter by SQLBI

Lass uns auf das Ergebnis schauen:

Der Filterkontext der Pivot konnte immer noch nicht überwunden werden, Power Pivot, Excel Datenmodell, Power BI Desktop
Der Filterkontext der Pivot konnte immer noch nicht überwunden werden

Ja, Du siehst richtig: Wir haben immer noch nicht das gewünschte Ergebnis erzielt. Genaugenommen ist das Ergebnis (zumindest der Zahlenwert) identisch. Aber glaube mir, wir sind kurz davor. Zunächst eine Frage an Dich: Hast Du eine Idee, wieso der Wert immer noch unverändert ist, obwohl wir doch den Filter auf der Tabelle Datum so ausführlich definiert haben? Da muss doch jetzt der April mit in das Ergebnis einfließen!

Die Antwort ist folgende: März und April fehlen in unserem Ergebnis deshalb, weil noch bevor die FILTER()-Funktion dazu kommt, über die Tabelle Datum zu iterieren und nach bestimmten Kriterien zu filtern, der Filterkontext der Pivot bereits gegriffen hat. Das bedeutet, dass noch bevor FILTER() über die Datumstabelle iteriert, diese bereits auf den Monat Mai eingeschränkt ist, weil dieser zum Filterkontext der Pivot gehört. Verwirrend, oder?! Daran gewöhnt man sich mit der Zeit 😉 Die FILTER()-Funktion ist also nie über alle Zeilen der Datumstabelle iteriert, sondern immer nur über diejenigen, die zum Monat Mai 2017 gehören. Es gibt eine weitere (und für dieses Beispiel letzte) DAX-Funktion, die die Rettung bringt: ALL().

Die Rettung durch ALL()

Um die korrekten Werte zu erhalten, muss ich abschließend dafür sorgen, dass die genutzte FILTER()-Funktion auf der gesamten Datumstabelle filtern kann und nicht auf der, die bereits durch den Filterkontext der Pivot eingeschränkt wurde. Wirf einen Blick auf die abschließende Lösung, die Du bereits vom Anfang des Beitrags kennst:

=
CALCULATE (
    SUM ( Umsaetze[Wert] );
    FILTER (
        ALL ( Datum );
        AND (
Datum[MonatImJahr] <= MAX ( Datum[MonatImJahr] );
Datum[Geschäftsjahr] = MAX ( Datum[Geschäftsjahr] )
        )
    )
)

DAX Formatter by SQLBI

Die ALL()-Funktion ignoriert den bestehenden Filterkontext durch die Datumstabelle. ALL( Datum ) liefert die gesamte (nicht gefilterte) Datumstabelle an die FILTER()-Funktion zurück, so dass diese auf Basis der gesamten Datumstabelle filtern kann. Auf diese Weise ist es möglich den durch die Pivot auf Mai 2017 gesetzten Filter zu überschreiben und auf März, April und Mai 2017 zu erweitern. Dadurch ist die CALCULATE()-Funktion in der Lage, die gewünschten Year-to-date-Werte zu kalkulieren und das folgende Ergebnis zu erzeugen:

Korrekte Year-to-date-Werte mit CALCULATE, Power Pivot, Power BI Desktop, Excel-Datenmodell
Korrekte Year-to-date-Werte, trotz Geschäftsjahresende im Februar, mit CALCULATE

Fazit

Ich weiß: Das war lang und nicht trivial. Ich habe dieses Measure in dieser Ausführlichkeit beschrieben, weil es viele DAX-Konzepte beinhaltet, die Dir in Deinem Umgang mit DAX regelmäßig begegnen werden. Ich hoffe, ich habe damit ein wenig zum besseren Verständnis dieser Sprache beitragen können 🙂

Bis zum nächsten Mal und denk dran: Sharing is caring. Wenn Dir der Beitrag gefallen hat, dann teile ihn gerne. Falls Du Anmerkungen hast, schreibe gerne einen Kommentar, oder schicke mir eine Mail an lars@ssbi-blog.de

Viele Grüße aus Hamburg,

Lars

Ich schreibe meine Beiträge für Dich, den Leser. Bitte schenke mir eine Minute Deiner Zeit und bewerte die folgenden Kategorien, um mir zu helfen meine Beiträge so gut wie möglich zu schreiben. Danke 🙂

Der Beitrag Ein vom Kalenderjahr abweichendes Geschäftsjahr mit Power BI abbilden, Teil2 erschien zuerst auf THE SELF-SERVICE-BI BLOG.

]]>
Ein vom Kalenderjahr abweichendes Geschäftsjahr mit Power BI abbilden, Teil1 https://ssbi-blog.de/blog/business-topics/ein-vom-kalenderjahr-abweichendes-geschaeftsjahr-mit-power-bi-abbilden-teil1/ Mon, 12 Mar 2018 10:00:55 +0000 http://ssbi-blog.de/?p=3183 Power BI liefert eine Vielzahl an Möglichkeiten, intelligent mit der Dimension Zeit zu kalkulieren. Dies erfolgt in der Programmiersprache DAX mittels sog. Time Intelligence-Funktionen. Diese ermöglichen es beispielsweise, eine kumulierten Jahreswert (oder auch Year-to-date-Wert (YTD)) sehr einfach zu ermitteln. Doch wie muss ich vorgehen, wenn mein Geschäftsjahr vom Kalenderjahr abweicht? Dieser Frage gehe ich in […]

Der Beitrag Ein vom Kalenderjahr abweichendes Geschäftsjahr mit Power BI abbilden, Teil1 erschien zuerst auf THE SELF-SERVICE-BI BLOG.

]]>
Power BI liefert eine Vielzahl an Möglichkeiten, intelligent mit der Dimension Zeit zu kalkulieren. Dies erfolgt in der Programmiersprache DAX mittels sog. Time Intelligence-Funktionen. Diese ermöglichen es beispielsweise, eine kumulierten Jahreswert (oder auch Year-to-date-Wert (YTD)) sehr einfach zu ermitteln. Doch wie muss ich vorgehen, wenn mein Geschäftsjahr vom Kalenderjahr abweicht? Dieser Frage gehe ich in diesem Beitrag nach.

Als Abonnent meines Newsletters erhältst Du die Beispieldateien zu den Beiträgen dazu. Hier geht’s zum Abonnement des Newsletters!

Die Problematik

Was bedeutet es, wenn das Geschäftsjahr eines Unternehmens vom Kalenderjahr abweicht? Ich nehme den Fall, dass ein Geschäftsjahr nicht wie das Kalenderjahr am 31.12. endet, sondern erst am 31.3. des Folgejahres. Die folgende Abbildung veranschaulicht dies:

Das Geschäftsjahr weicht vom Kalenderjahr ab, Power Pivot, Power BI Desktop
Das Geschäftsjahr weicht vom Kalenderjahr ab

Unter der Annahme, dass das erste Datum in Zelle A2 steht, kann das Geschäftsjahr in Excel also mit folgender Formel berechnet werden: =WENN(MONAT(A2)<4;JAHR(A2)-1;JAHR(A2)).

Ziel

Das Ziel, das ich für die Gestaltung meines Berichts verfolge, besteht aus zwei Teilen.

  1. Ich möchte einen bestimmten Einfluss auf den Aufbau der Pivottabelle nehmen. Diese Lösung kann natürlich auch auf alle anderen Visualisierungen übertragen werden, die man in Power BI Desktop nutzen kann.
  2. Die Berechnung eines entsprechenden Year-to-Date-Wertes soll nicht mit dem Januar beginnen, sondern sich an meinen spezifischen Geschäftsjahresanfang orientieren.

Für das bessere Verständnis zeige ich jetzt die gewünschten Resultate.

Teilziel 1 – Die Beeinflussung des Pivotaufbaus

Das Ziel ist, dass bei der Auswahl des Geschäftsjahres 2017 über den oben befindlichen Datenschnitt, die Pivottabelle automatisch mit dem April 2017 beginnt und mit dem März 2018 endet. Der folgende Screenshot zeigt dies:

Der Pivotaufbau berücksichtigt das Geschäftsjahr, Power Pivot, Power BI Desktop
Der Pivotaufbau berücksichtigt das Geschäftsjahr

Teilziel 2 – Die Berechnung eines Year-to-Date-Wertes, bezogen auf das Geschäftsjahr

Ein Year-to-Date-Wert gibt einen kumulierten Jahreswert zurück, der standardmäßig alle Werte vom 1.1. des Jahres bis zum gewünschten Berichtstag widergibt. In meinem Falle startet das Jahr jedoch am 1. April:

Der kumulierte Jahreswert (YTD-Wert) beginnt im April und endet im März des Folgejahres, Power Pivot, Power BI Desktop
Der kumulierte Jahreswert (YTD-Wert) beginnt im April und endet im März des Folgejahres

Diese beiden Ziele gilt es umzusetzen, um ein korrektes Reporting zu gewährleisten. Bevor ich jedoch auf die Lösung eingehe, erkläre ich kurz die Augangssituation.

Die Ausgangssituation

Die Basis für meine Lösung ist das folgende, sehr einfache Datenmodell. Gegeben ist eine Faktentabelle (Umsaetze) mit den Umsätzen. Hinzu kommen zwei Dimensionstabellen Datum und Verkaufsstellen, die mit der Faktentabelle in Beziehung stehen.

Das Datenmodell, Power Pivot, Power BI Desktop
Das Datenmodell

Mit diesem Wissen, mache ich mich nun an die Beeinflussung der Pivotstruktur, indem ich das Datenmodell entsprechend anpasse.

Den Aufbau der Pivot beeinflussen: Das Datenmodell anpassen

Ich hatte bereits beim Erläutern der Problematik gezeigt, wie sich das Geschäftsjahr als Formel in Excel ergibt. Da ich meine Daten über Power Query ins Datenmodell in Excel geladen habe, ist eine valide Lösung genau diese Excelformel in Power Query über eine neue berechnete Spalte hinzuzufügen. Dies gestaltet sich wie folgt:

  • Ich gehe in Power Query in die Abfrage meiner Datumstabelle
  • Dort füge ich eine neue Spalte hinzu und nutze hierfür die folgende Formel:
Power Query: eine neue Spalte für das Geschäftsjahr hinzufügen, Power Pivot, Power BI Desktop
Power Query: eine neue Spalte für das Geschäftsjahr hinzufügen

Dies führt zu der neuen Spalte Geschäftsjahr in meiner Dimensionstabelle Datum. Ich speichere meine Abfrage und verlasse Power Query. Ein Blick auf die Pivottabelle zeigt folgendes:

Die korrekten Monate, in alphabetischer Sortierung, Power Pivot, Power BI Desktop
Die korrekten Monate, in alphabetischer Sortierung

In dieser Lösung sind nun die Monate April 2017 bis März 2018 enthalten – so wie es sein soll. Allerdings ist die Sortierung der Monate in alphabetischer Reihenfolge erfolgt. Dies ist für den Nutzer kaum hilfreich. Deshalb sorge ich jetzt dafür, dass die Sortierung der Monate in chronologischer Reihenfolge erfolgt. Hierfür gehe ich zurück ins Datenmodell. Nun gehe ich wie folgt vor:

  • Ich markiere in der Tabelle Datum diejenige Spalte, die in meiner Pivottabelle den Monat beinhaltet (Spalte MonatImKalenderjahr).
  • Dann klicke ich auf die Schaltfläche Startseite → Nach Spalte sortieren.
  • Hier wähle ich aus, dass die als Text formatierte Spalte MonatImKalender, die in der Pivottabelle bisher alphabetisch sortiert wird, nach der numerischen Spalte JahrMonat sortiert werden soll.

Der folgende Screenshot zeigt die Vorgehensweise bildlich:

Die korrekte Sortierung der Monate in der Pivot herbeiführen, Power Pivot, Power BI Desktop
Die korrekte Sortierung der Monate in der Pivot herbeiführen

Das Ergebnis sieht daraufhin wie gewünscht aus:

Monate in korrekter Reihenfolge, Power Pivot, Power BI Desktop
Monate in korrekter Reihenfolge

Bevor ich mich der Kalkulation der YTD-Kennzahl widme, definiere ich zunächst im Datenmodell, auf Basis welcher Spalte die datumsbezogenen Kalkulationen stattfinden können.

Die Datumstabelle markieren

Die sog. Time Intelligence-Funktionen, wie beispielsweise die TOTALYTD()-Funktion, müssen definiert bekommen, welche Tabelle im Datenmodell die Kalendertabelle ist. Dies macht eine korrekte Kalkulation erst möglich. Ich markiere die Tabelle Datum wie folgt als Datumstabelle:

Das Markieren einer Datumstabelle in Power Pivot
Das Markieren einer Datumstabelle in Power Pivot

Nachdem die Datumstabelle nun markiert ist, kann mit der Kalkulation des YTD-Measures begonnen werden.

Die Kalkulation der Kennzahl beeinflussen: DAX – TOTALYTD()

Um einen YTD-Wert zu kalkulieren, bietet es sich in der Regel an, die DAX-Funktion TOTALYTD() zu nutzen. Diese hat die folgende Syntax:

TOTALYTD(<Ausdruck>,<Datumswerte>[,<Filter>][,<Jahresenddatum>])
Hier eine kurze Erläuterung der einzelnen Parameter:

  • Ausdruck: Der Wert, aus dem der YTD-Wert gebildet werden soll. In meinem Beispiel die Spalte Umsaetze[Wert].
  • Datumswerte: Eine Spalte mit Datumswerten, anhand derer der YTD-Zeitraum kalkuliert werden kann. In meinem Beispiel die Spalte Datum[Datum].
  • Filter: Ein optionaler Parameter, der zum gegenwärtigen Kontext, unter dem die Formel evaluiert wird, einen weiteren Filter ergänzt. Dies ist für mein Beispiel nicht notwendig und wird vernachlässigt.
  • Jahresenddatum: Ein optionaler Parameter, der das (Geschäfts-) Jahresende als Text übergibt. Hierbei sollte die US-amerikanische Reihenfolge „Monat/Tag“ eingehalten werden. Varianten wie „6/30“, „6-30“ und „Jun 30“ sind möglich.

Die folgende Formel bildet den korrekten YTD-Wert für mein Beispiel in DAX ab:

=
TOTALYTD ( SUM ( Umsaetze[Wert] ); Datum[Datum]; „3/31“ )

DAX Formatter by SQLBI

Ziehe ich dieses neue Measure nun mit in meine Pivottabelle, so entspricht das Ergebnis meiner Zielstellung:

Die erfüllte Zielstellung, Power Pivot, Power BI Desktop
Die erfüllte Zielstellung

Diese Lösung funktioniert hervorragend in 11 von 12 Fällen. Falls das Geschäftsjahr jedoch im Februar endet, stehe ich vor einem Problem, denn ich müßte meiner TOTALYTD()-Funktion mitgeben, dass mein Geschäftsjahr am 28.02. oder am 29.2. enden kann, je nachdem, ob es sich um ein Schaltjahr handelt, oder nicht. Dies ist mit der TOTALYTD()-Funktion jedoch nicht möglich. Wie dieses Problem dennoch zu lösen ist, erkläre ich im nächsten Post.

Bis zum nächsten Mal und denk dran: Sharing is caring. Wenn Dir der Beitrag gefallen hat, dann teile ihn gerne. Falls Du Anmerkungen hast, schreibe gerne einen Kommentar, oder schicke mir eine Mail an lars@ssbi-blog.de

Viele Grüße aus Hamburg,

Lars

Ich schreibe meine Beiträge für Dich, den Leser. Bitte schenke mir eine Minute Deiner Zeit und bewerte die folgenden Kategorien, um mir zu helfen meine Beiträge so gut wie möglich zu schreiben. Danke 🙂

Der Beitrag Ein vom Kalenderjahr abweichendes Geschäftsjahr mit Power BI abbilden, Teil1 erschien zuerst auf THE SELF-SERVICE-BI BLOG.

]]>