Suchen...
Generic filters
Exact matches only
Search in title
Search in excerpt
Search in content

In 10 Tagen einmal um die SAP-ERP-Welt – Tag 0

Dieser Artikel 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.

Agiles Business Intelligence mit SAP-Daten


In zwei Tagen zum Data Warehouse in der Jackentasche

Die Bissantz ERP Solutions zeigen, was mit KI-basierter Data-Warehouse-Modellierung in­zwischen 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 not­wendigen Ver­arbeitungs­schritten, vom Laden der Daten aus SAP ERP bis zur auto­matischen Daten­versorgung 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.