Dieser Blogbeitrag bietet einen Überblick über die Fixierung von Ansatzpunkten und beschreibt vor allen Dingen die grundlegenden Aspekte, welche bei der Einrichtung von MS-SQL/OLAP-Datenbanken für SAP-ERP-Systeme notwendig sind.
In zwei Tagen zum Data Warehouse in der Jackentasche
Die Bissantz ERP Solutions zeigen, was mit KI-basierter Data-Warehouse-Modellierung inzwischen möglich ist. So standardisiert wie möglich, so individuell wie nötig entsteht in kürzester Zeit ein komplett fertig paketiertes Business-Intelligence-System – mit allen notwendigen Verarbeitungsschritten, vom Laden der Daten aus SAP ERP bis zur automatischen Datenversorgung mobiler Endgeräte.
Innerhalb eines umfangreichen und integrierten SAP-ERP-Systems finden die Online-Bearbeitung der Transaktionen und die Abwicklung der einzelnen Buchungsschritte statt. Die originäre Speicherung der Geschäftsdaten erfolgt gemäß der prozessspezifischen Strukturen. Diese operativen Spezifikatoren erlauben aber nicht immer einen übergreifenden Blick auf das Unternehmen.
Im Rahmen eines Data Warehouses werden alle unternehmensrelevanten Daten inhaltlich strukturiert und umfassend vereinheitlicht. Dass hierbei Daten durchaus mehrfach gespeichert werden, ist gewollt und dient der Effizienz.
In diesem Zusammenhang ist die Bereitstellung von erforderlichen SAP-ERP-Tabellen im MS-SQL-Server prinzipiell keine komplizierte Angelegenheit. Für die zutreffende Identifizierung der benötigten SAP-ERP-Tabellen gibt es ausreichende Anhaltspunkte.
Die wesentlichen Fakten des SAP-ERP-Systems lassen sich zum Beispiel anhand der hauptsächlichen Bewegungsdaten-Tabellen (TRAN) fürs Erste hinreichend gliedern:
| Modul | Tabelle | Beschreibung |
| MM | EKKO | Einkaufsbelegkopf |
| EKPO | Einkaufsbelegposition | |
| MKPF | Belegkopf Materialbeleg | |
| MSEG | Belegsegment Material | |
| KEKO | Erzeugniskalkulation Kopfinformation | |
| CKIS | Einzelkalkulation Positionen | |
| SD | KONH | Belegkopf Kundenkondition |
| KONV | Belegposition Kundenkondition | |
| VBRK | Faktura: Kopfdaten | |
| VBRP | Faktura: Positionsdaten | |
| LIKP | Lieferung: Kopfdaten | |
| LIPS | Lieferung: Positionsdaten | |
| VBAK | Verkaufsbeleg: Kopfdaten | |
| VBAP | Verkaufsbeleg: Positionsdaten | |
| VBUK | Vertriebsbeleg: Kopfstatus und Verwaltungsdaten | |
| VBUP | Vertriebsbeleg: Positionsstatus | |
| COPA | CE1* | Marktsegmentrechnung: Einzelposten Ist |
| CE2* | Marktsegmentrechnung: Einzelposten Plan | |
| COOM | COBK | CO-Objekt: Belegkopf |
| COEP | CO-Objekt: Einzelposten periodenbezogen | |
| COSL | CO-Objekt: Summen Leistungsarten | |
| COSP | CO-Objekt: Summen Kosten – externe Buchungen | |
| COSR | CO-Objekt: Statistische Kennzahlen | |
| COSS | CO-Objekt: Summen Kosten – interne Buchungen | |
| COST | CO-Objekt: Summen Tarife | |
| ECPC | GLPCA | Profit-Center-Rechnung: IST-Einzelposten |
| GLPCP | Profit-Center-Rechnung: Plan-Rechnung | |
| GLPCT | Profit-Center-Rechnung: Summen | |
| FIGL | BKPF | Belegkopf für Buchhaltung |
| BSEG | Belegsegment Buchhaltung | |
| FAGLFLEXA | Hauptbuch: IST-Einzelposten | |
| FAGLFLEXP | Hauptbuch: Plan-Einzelposten | |
| FAGLFLEXT | Hauptbuch: Summen | |
| GLFUNCT | Summentabelle für Umsatzkostenverfahren | |
| GLT0 | Sachkontenstamm Verkehrszahlen | |
| FISL | ANLC | Anlagen Wertfelder |
| ANLP | Anlagen Periodenwerte | |
| KNC1 | Kundenstamm Verkehrszahlen | |
| KNC3 | Kundenstamm Verkehrszahlen Sonderhauptbuchvorgänge | |
| LFC1 | Lieferantenstamm Verkehrszahlen | |
| LFC3 | Lieferantenstamm Verkehrszahlen Sonderhauptbuchvorgänge | |
| MBEW | Materialbewertung | |
| MBEWH | Materialbewertung – Historie | |
| ECCS | ECMCA | SAP-Konsolidierung: Einzelpostentabelle Ist |
| ECMCT | SAP-Konsolidierung: Summentabelle |
Die initiale Archivierung der Bewegungsdaten und anschließende Delta-Verfahren können beispielsweise wie folgt eingerichtet werden:
| Modul | Tabelle | Spalte für Periode | Spalte für Zeitstempel |
| SD | KONH | ERDAT | ERDAT |
| KONV | KDATU | KDATU | |
| VBRK | FKDAT | ERDAT + AEDAT | |
| VBRP | ERDAT | ERDAT | |
| VBAK | AUDAT | ERDAT + AEDAT | |
| VBAP | ERDAT | ERDAT + AEDAT | |
| COPA | CE1* | PERIO | HZDAT, TIMESTMP |
| CE2* | PERBL | HZDAT, TIMESTMP | |
| COOM | COBK | GJAHR | TIMESTMP |
| COEP | GJAHR+PERIO | TIMESTMP | |
| FIGL | FAGLFLEXA | RYEAR | TIMESTAMP |
Der SAP-Zeitstempel als Zahl wird folgendermaßen in ein Datumsformat umgewandelt:
SELECT DATEADD(S,(10000/10000),'1990-01-01') ergibt 1990-01-01 00:00:01.000 SELECT DATEADD(S,(TIMESTMP/10000),'1990-01-01') ergibt das aktuelle Datum.
Neben den Fakten lassen sich die Hauptmerkmale und die hinterlegten Prüftabellen des SAP-ERP-Systems ebenfalls ordentlich strukturieren. Der nächste Artikel wird darlegen, welche Stammdaten (ATTR), Hierarchiedefinitionen (HIER), Texttabellen (TEXT) und Systemdaten (DOMA) mindestens einzubeziehen sind.
An dieser Stelle möchten wir auch auf die Gegebenheit hinweisen, dass der Datensatzaufbau der genannten Tabellen in jedem SAP-ERP-System im Kern identisch ist.
Es ist lediglich zu beachten, dass unternehmensseitig zusätzliche Spalten hinzugefügt werden können.
Als nächstes stellt sich die Frage nach der weiteren Vorgehensweise. Vorweg ist zu sagen, dass eine achtbare Umsetzung des Vorhabens, die modularen Inhalte des SAP-ERP-Systems mit Hilfe von MS-SQL/OLAP-Datenbanken in einem Zeitraum von 10 Tagen darzulegen, eine Herausforderung ist. Vieles kann standardisiert umgesetzt werden. Einige Sachverhalte müssen aber auch detailliert erörtert und fallweise eingerichtet werden.
Das Ziel ist die Erstellung eines guten Datenmodells, das auf einer Kombination von vorkonfigurierten Komponenten mit maßkonfektionierten Elementen basiert.
Die typischen Aufgabengebiete sind:
- Bereitstellung der transparenten SAP-Tabellen im MS-SQL-Server durch XtractIS (Theobald-Software)
- Transformation und Fortschreibung der importierten SAP-Tabellen durch vorgefertigte SQL-Skripte
- Semantische Schicht für allgemeine und feststehende Geschäftsbegriffe
- Skalierung der Struktur des Datenmodells
- DeltaMaster-Startsitzung mit ersten Berichten für die Sichtung der Daten
Auf die Ausgestaltung der einzelnen Aufgabengebiete werde ich in weiteren Artikeln eingehen.
Zum Schluss dieses Artikels möchte ich noch den Punkt kurz ansprechen, ob der skizzierte Weg auch SAP-konform ist. Ich finde schon, obwohl dieser Pfad für Personen im SAP-Umfeld ungewohnt ist. Nach meiner Auffassung werden die sachlogischen Zusammenhänge eines SAP-BW-Systems ebenfalls richtig abgebildet. Und andersherum wird eben auch ein guter „Schuh“ daraus. Dieses glaubhaft zu machen, ist aber nicht immer eine leichte Aufgabe.
