Die Month-to-Date Berechnung mit den DAX-Funktionen TOTALMTD()- oder DATESMTD() ist wirklich sehr einfach zu nutzen. Interessant wird es aber, wenn diese Kumulationsberechnung in eine Tabelle mit Einzelbuchungen eingesetzt wird. In diesem Fall führt der angewendete Filter Context zu einem für viele Anwender unerwartetem Berechnungsergebnis.

In Teil 1 dieser Blogserie beleuchten wir die Fragestellung und zeigen, warum die normale MTD-Berechnung nicht zum gewünschten Ergebnis führen kann. In Teil 2 zeigen wir dann einen Lösungsansatz für die Berechnung einer monatlich fortlaufenden Summe in einer Detailtabelle.

Ausgangssituation

Wir verwenden einen Auszug der "Adventure Works" Demodatenbank (von Microsoft) mit der Faktentabelle "Reseller Sales" in einem klassischen Star Schema:

Die Datumsdimension wurde also solche im Datenmodell deklariert, um in weiterer Folge die DAX Time Intelligence Funktionen nutzen zu können. Aufbauend auf das Datenmodell wird das folgende Measure zur Berechnung der Quantities erstellt ...

Quantity = SUM('Fact Sales'[Order Quantity])

... und damit folgender sehr einfache Report erstellt:

DAX-Funktionen TOTALMTD() und DATESMTD()

Die DAX-Funktion TOTATLMTD() bewerkstelligt die Berechnung der Month-to-Date Werte des Basismeasures Quantity ...

Quantity MTD = 
    TOTALMTD(
        [Quantity];
        'Dim Dates'[Date]
    )

... und ist eine Syntaxvariante ("Syntax Sugar") für die Filterfunktion DATESYTD():

Quantity MTD (Syntax Variante) = 
    CALCULATE(
        [Quantity];
        DATESMTD('Dim Dates'[Date])
    )

Beide Syntaxvarianten liefern das gleiche Ergebnis, nämlich den Month-to-Date Wert. Dabei wird - sinnvollerweise - für jeden Tag bis zum Monatsletzten der jeweils kumulierte Monatswert berechnet (also auch für die Tage ohne Verkäufe):

Anwendung im Einzelnachweis

Wird das neue MTD-Measure in die Tabelle mit dem Einzelnachweis eingefügt, passiert etwas für viele Anwender (zugegeben: auch für mich) Unerwartetes: die Kumulation scheint in der Tabelle nicht zu funktionieren!

Bei genauerer Betrachtung ist es aber einfach der Filter Context, der für die Berechnung jedes Measures angewendet wird, der die Berechnung für unsere Zwecke scheitern lässt. Und die Fortschreibung auf alle Folgetage nach dem Verkaufstag bis zum Monatsultimo lässt erzeugt sehr viele für uns unnötige (und damit störende) Einträge.

Wird die Detailliste bspw. auf Tage und Countries reduziert, dann ist gut zu sehen, wie das MTD-Measure berechnet wird: die Kumulation wird pro Land berechnet und dann bis zum Monatsultimo auf jeden Tag fortgeschrieben.

D.h. je mehr Felder in die Detailtabelle gezogen werden, umso "kleinteiliger" wird der angewendete Filter Context und umso weniger wird de-facto kumuliert. Befindet sich die Order Number oder ein eindeutige ID in der Detailliste, bringt die MTD-Berechnung definitiv nur noch den ursprünglichen Quantity-Wert als Ergebnis.

Zwischenfazit

Die MTD-Berechnung funktioniert absolut richtig und sinvoll, lediglich ist die Darstellung der Ergebnisse in einer Detailliste häufig unerwartet und erfüllt nicht den Zweck einer fortlaufenden Summe. Im Teil 2 dieser Blogserie sehen wir uns an, wie eine Lösung für die fortlaufende Summe in einer Detailtabelle aussehen kann.