Ihr Bericht ist fertig und die Zahlen stimmen, aber in den Kalenderbeschriftungen werden nur technische Schlüssel angezeigt, das Feld „Kalenderwoche“ bleibt leer, und Ihre Geschäftsanwender sind verwirrt, welchen Zeitraum sie gerade betrachten. Das Problem liegt in den Standard-Zeitdimensionen in SAP Datasphere, aber es gibt eine einfache Lösung.

Was sind Zeitdimensionen und warum sind sie wichtig?

Jeder Bericht, der Datumsangaben enthält, stützt sich auf eine Zeitdimension. Sie ist der zentrale Bestandteil zeitbasierter Analysen und teilt Ihrem Berichtstool mit, was „letzter Monat“ bedeutet, wie Daten nach Kalenderwochen gruppiert werden sollen und wie eine lesbare Bezeichnung wie „Januar 2026“ anstelle einer reinen Zahlenangabe wie „202601“ angezeigt werden soll.

SAP Datasphere verfügt über eine integrierte Zeitdimension namens SAP.TIME.*. Diese ist von SAP umfassend dokumentiert und deckt die grundlegenden Granularitäten ab: Tage, Monate, Quartale, Jahre. Für viele Standardanwendungsfälle ist dies ein solider Ausgangspunkt.

In der Praxis zeigt sich jedoch, dass die Standardversion oft zu wünschen übrig lässt, das konnten wir bereits in zahlreichen Projekten beobachten und oft fällt das nicht immer sofort ins Auge. In Berichten werden z.B. technische Schlüssel anstelle von lesbaren Bezeichnungen angezeigt, Kalenderzeiträume sind nicht mit lesbaren Texten versehen. Geschäftsanwender sehen die Datumsangabe „20“ und müssen selbst erraten, um welchen Monat und welches Jahr es sich handelt.

Das Kernproblem: Die Standard-Zeitdimension von SAP wurde auf breite Kompatibilität ausgelegt und nicht auf die spezifische, konsistente Berichtslogik, die anspruchsvolle Geschäftsumgebungen erfordern.

Wo versagt die Standardversion?

Wir haben drei entscheidende Lücken identifiziert, die in Kundenprojekten immer wieder auftreten:

1. Fehlende Text-Assoziationen: Die Standard-Zeitdimension enthält keine Assoziationen für Felder wie Kalenderwoche oder Monat. Ohne diese Zuordnungen werden in Berichten anstelle von lesbaren Periodennamen reine technische Schlüssel angezeigt – beispielsweise „202551“ statt „KW 51 2025“. Da Sie den Standard-Views von SAP keine Zuordnungen hinzufügen können, gibt es hierfür auch keinen Workaround.

2. Rohdaten statt lesbarer Beschriftungen: Anstelle von „Januar 2026“ sehen Geschäftsanwender „202601“ oder „Januar“, da das Jahr nicht berücksichtigt wird. Anstelle von „Q1 2026“ sehen sie „20261“. Dabei handelt es sich nicht nur um kosmetische Probleme, sondern um die Art und Weise, wie Geschäftsanwender ihre Daten durchsuchen, überprüfen und darüber kommunizieren. Technische Schlüssel oder nicht aussagekräftiger Text untergraben das Vertrauen in Berichte.

3. Keine Anpassungsmöglichkeiten: Die Standard-Views von SAP sind gesperrt. Sie können sie nicht ändern, um fehlende Attribute, eigene Textlogik oder zusätzliche Assoziationen hinzuzufügen. Jede Erweiterung muss an anderer Stelle implementiert werden und genau hier setzt unser Ansatz an.

Der folgende Screenshot zeigt genau, wie das in der Praxis aussieht:

• In der Spalte „Date“ wird das Datum mit einer einfachen Zahl für den Tag angezeigt.

• In der Spalte „Calendar Quarter“ werden Zahlen wie „20262“ oder „20264“ anstelle von „Q2 2026“ oder „Q4 2026“ angezeigt.

• In der Spalte „Calendar Week“ werden Rohwerte wie „202617“ oder „202642“ angezeigt, nicht jedoch lesbare Kalenderwochenbezeichnungen.

• Die Spalte „Calendar Month“ zeigt den Text ohne Angabe des Jahres an, sodass sie für sich allein genommen nicht aussagekräftig ist.

Die Daten sind korrekt, aber völlig unlesbar.

Abbildung 1: Falsche Anzeige bei der Standard-Zeitdimension

Und das Schlimmste daran? Berichtstools wie SAP Analytics Cloud (SAC) würden gerne den korrekten Text für Felder wie das Datum anzeigen und dabei die Benutzereinstellungen für die Datumsanzeige berücksichtigen, aber die Metadaten von Datasphere überschreiben diese, wie auf diesem Screenshot zu sehen ist:

Abbildung 2: Datumsformat in SAC. In den Metadaten ist der korrekte Text vorhanden

Dieses Problem betrifft unmittelbar Geschäftsanwender und Berichtsnutzer - also alle, die bei ihrer täglichen Arbeit auf Datumsfilter, kalenderbasierte Vergleiche oder Zeitreihendarstellungen angewiesen sind.

Und da es sich hierbei um eine so grundlegende Kernkomponente Ihrer Berichterstellung handelt, wird jeder Geschäftsbereich von einer guten Lösung profitieren.

Sehen Sie sich die Aufzeichnung unseres Webinars an: 
"SAP Datasphere and the Databricks Lakehouse Approach"

So lösen wir es: Wir kapseln den Standard in eigene Views

Der entscheidende Punkt hierbei ist, dass wir die Standard-Zeitdimension von SAP nicht verwerfen. Da die Standard-Views von SAP gesperrt sind, können wir sie zwar nicht ändern, aber wir können darauf aufbauen. Der View SAP.TIME.VIEW_DIMENSION_DAY enthält bereits die benötigten Daten. Es fehlen lediglich die richtigen Assoziationen, die technische Schlüssel in lesbare Bezeichnungen übersetzen.

Unser Ansatz ist also ganz einfach: Wir erstellen unsere eigenen Views, die SAP.TIME.VIEW_DIMENSION_DAY als Datenquelle verwenden und fügen die fehlenden Assoziationen in unserer hinzu. Mit diesem Ansatz können wir beliebige Attribute, Assoziationen oder Textlogiken hinzufügen, ohne die ursprünglichen Ansichten von SAP verändern zu müssen.

Das Ergebnis ist eine View auf Tagesebene, die auf der Standardansicht aufbaut, diese erweitert und jedem verknüpften Bericht einen stabilen, übersichtlichen und vollständig anpassbaren Zeitbezug bietet. Dieser Ansatz lässt sich auch auf andere Zeiträume wie Monate, Quartale und Jahre anwenden.

Die Architektur in vier Schritten

Erstellen einer eigenen View auf Basis von SAP.TIME
Wir erstellen eine neue View, die Daten aus SAP.TIME.VIEW_DIMENSION_DAY liest und alle deren Datumsattribute mit den korrekten semantischen Typen bereitstellt.

Erstellen von Text-Views für jede Zeiteinheit
Wir erstellen separate Text-Views für Kalendermonate, Kalenderquartale und Kalenderwochen. Jede View generiert eine lesbare Bezeichnung, zum Beispiel „Januar 2026“ für den Monat, „Q1 2026“ für das Quartal und „KW 01 2026“ für die Woche, und zwar in allen erforderlichen Sprachen. Diese Textansichten beziehen ihre Datumsschlüssel ebenfalls aus den SAP.TIME-Standardtabellen.

Der zentralen View eigene Assoziationen hinzufügen
Wir verknüpfen jede Text-View über explizite Zuordnungen mit unserer eigenen Tagesdimension. Sobald diese Zuordnungen eingerichtet sind, kann jedes verbundene Berichtstool, dass diese Metadaten unterstützt, technische Schlüssel automatisch in lesbare Bezeichnungen umwandeln.

Verwenden Sie die eigene View als Zeitdimension in Berichtsmodellen
Alle Berichte, die zeitbasierte Bezeichnungen benötigen, verweisen nun auf unsere eigene Dimension statt auf die gesperrte SAP Standard-Zeitdimension. Die zugrunde liegenden Daten stammen weiterhin aus SAP.TIME, wir steuern lediglich die Zuordnungen und den Text darüber.

Der folgende Screenshot zeigt die Definition der Zeitdimension, wie sie bei einem unserer Kunden implementiert wurde. Beachten Sie, dass wir die Assoziation für das Feld “Date” leer lassen, da unser Berichtstool (SAC) dies automatisch auf Basis des Datums übernimmt, wie in unserem vorherigen Screenshot gezeigt.

Abbildung 3: Die eigene Zeitdimension auf Tagesebene in Datasphere mit korrekten Assoziationen

Hinter den Kulissen: Erstellung lesbarer Textbeschriftungen
Für jede Zeiteinheit schreiben wir eine kleine SQLScript View, die eindeutige Periodenschlüssel aus der Tabelle SAP.TIME.VIEW_DIMENSION_DAY ausliest und für jeden Schlüssel eine lesbare Bezeichnung in allen gewünschten Sprachen generiert. Die Monatsanzeige wandelt beispielsweise „202601“ für englischsprachige Benutzer in „January 2026“ und für deutschsprachige Benutzer in „Januar 2026“ um.

Das allgemeine Muster ist dabei immer dasselbe:

1. Eindeutige Schlüssel aus der Quelle „SAP.TIME“ lesen

2. Eine Cross-join mit den Sprachcodes (z.B. DE und EN) durchführen

3. Jedem Schlüssel mithilfe eines CASE-Ausdrucks eine lesbare Zeichenfolge zuordnen

4. Das Ergebnis als Text-View speichern

5. Diese View unserer eigenen Zeitdimension zuordnen

Für alle, die sich für die konkrete Umsetzung interessieren, zeigen wir im Folgenden den vollständigen SQL-Code für die Text-View des Kalendermonats. Die gleiche Logik gilt auch für Quartale und Wochen.

/**
 * Builds CALMONTH texts (DE/EN) from SAP.TIME Dimension
 * Source: SAP.TIME.VIEW_DIMENSION_DAY
 */

lt_months =
    SELECT DISTINCT
        CAST("CALMONTH" AS NVARCHAR(6)) AS "IDENTIFIER"
    FROM "SAP.TIME.VIEW_DIMENSION_DAY"
    WHERE "CALMONTH" IS NOT NULL;


/**
* Can be anything, just need a single row result
*/
lt_dummy = SELECT DISTINCT MIN("YEAR") FROM "SAP.TIME.VIEW_DIMENSION_YEAR";

lt_langs =
      SELECT 'DE' AS "LANGUAGE_KEY" FROM :lt_dummy
UNION SELECT 'EN' AS "LANGUAGE_KEY" FROM :lt_dummy;

return
SELECT
    m."IDENTIFIER",
    l."LANGUAGE_KEY",
    CAST(
        (
            CASE l."LANGUAGE_KEY"
                WHEN 'EN' THEN
                    CASE SUBSTRING(m."IDENTIFIER", 5, 2)
                        WHEN '01' THEN 'January'   WHEN '02' THEN 'February'
                        WHEN '03' THEN 'March'     WHEN '04' THEN 'April'
                        WHEN '05' THEN 'May'       WHEN '06' THEN 'June'
                        WHEN '07' THEN 'July'      WHEN '08' THEN 'August'
                        WHEN '09' THEN 'September' WHEN '10' THEN 'October'
                        WHEN '11' THEN 'November'  WHEN '12' THEN 'December'
                    END
                WHEN 'DE' THEN
                    CASE SUBSTRING(m."IDENTIFIER", 5, 2)
                        WHEN '01' THEN 'Januar'    WHEN '02' THEN 'Februar'
                        WHEN '03' THEN 'März'      WHEN '04' THEN 'April'
                        WHEN '05' THEN 'Mai'       WHEN '06' THEN 'Juni'
                        WHEN '07' THEN 'Juli'      WHEN '08' THEN 'August'
                        WHEN '09' THEN 'September' WHEN '10' THEN 'Oktober'
                        WHEN '11' THEN 'November'  WHEN '12' THEN 'Dezember'
                    END
            END
            || ' ' || SUBSTRING(m."IDENTIFIER", 1, 4)
        ) AS NVARCHAR(30)
    ) AS "CALMONTH_NAME"
FROM :lt_months m
CROSS JOIN :lt_langs l;

Der Vorteil der Lösung

Der letzte Screenshot unten zeigt denselben Datensatz, nun unter Verwendung der eigenen Zeitdimension, erneut im Vergleich zu unserem ursprünglichen Datensatz. „April 2026“ statt „202604“. „Q2 2026“ statt „20262“. „CW17 2026“ statt einer reinen Zahl. Jede Spalte ist gut lesbar und jede Beschriftung ist in allen Berichten einheitlich.

Abbildung 4: Der gleiche Datensatz im direkten Vergleich

Mit dieser Lösung erhalten Sie eine einheitliche Zeitdimension für alle Bereiche. Wenn ein neues Attribut benötigt wird, z. B. ein Fiskaljahr, ein eigener Zeitraum oder eine zusätzliche Sprache, fügen wir es einmalig in unserer eigenen View hinzu.
Jeder verknüpfte Bericht übernimmt die Änderung automatisch.

Geschäftsanwender hören auf die Daten in Frage zu stellen und konzentrieren sich stattdessen wieder auf das Wesentliche, die Geschäftszahlen.

Eigene Zeitdimensionen in SAP Datasphere: Ist das  skalierbar? Unser Fazit

Durch die einheitliche Zeitdimension erhalten Geschäftsanwender die übersichtlichen Bezeichnungen, die sie benötigen. Diese Investition in die Qualität der Berichterstattung spiegelt eine grundlegende Erkenntnis wider: Geschäftsteams müssen direkt auf der Unternehmensdatenplattform mit ihren Daten arbeiten können - selbstbewusst und eigenständig.

Genau dafür wurde NextTables entwickelt. Als Business-First-Lösung für die Datenpflege auf Plattformen wie SAP Datasphere und Databricks ermöglicht NextTables Geschäftsteams, Referenzdaten, Klassifizierungen, Zuordnungen und Hierarchien direkt dort zu aktualisieren, wo die Daten gespeichert sind. Jeder Eintrag wird bei der Eingabe anhand der Unternehmensstammdaten validiert. Der Zugriff wird bis auf die Zeitebene hin kontrolliert. Änderungen erscheinen sofort in jedem verbundenen Bericht und Dashboard.

Wenn Ihr Team bereits in die optimale Nutzung von Datasphere investiert, ist der nächste logische Schritt, den Geschäftsanwendern eine sichere und vertraute Möglichkeit zu geben, die Daten hinter diesen Berichten zu pflegen.