CiAgICA8IS0tIExpbmtlZEluIC0tPgogICAgPHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPgogICAgICAgIF9saW5rZWRpbl9wYXJ0bmVyX2lkID0gIjEyMzUwNzMiOwogICAgICAgIHdpbmRvdy5fbGlua2VkaW5fZGF0YV9wYXJ0bmVyX2lkcyA9IHdpbmRvdy5fbGlua2VkaW5fZGF0YV9wYXJ0bmVyX2lkcyB8fCBbXTsKICAgICAgICB3aW5kb3cuX2xpbmtlZGluX2RhdGFfcGFydG5lcl9pZHMucHVzaChfbGlua2VkaW5fcGFydG5lcl9pZCk7CiAgICA8L3NjcmlwdD48c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCI+CiAgICAgICAgKGZ1bmN0aW9uKCl7dmFyIHMgPSBkb2N1bWVudC5nZXRFbGVtZW50c0J5VGFnTmFtZSgic2NyaXB0IilbMF07CiAgICAgICAgICAgIHZhciBiID0gZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7CiAgICAgICAgICAgIGIudHlwZSA9ICJ0ZXh0L2phdmFzY3JpcHQiO2IuYXN5bmMgPSB0cnVlOwogICAgICAgICAgICBiLnNyYyA9ICJodHRwczovL3NuYXAubGljZG4uY29tL2xpLmxtcy1hbmFseXRpY3MvaW5zaWdodC5taW4uanMiOwogICAgICAgICAgICBzLnBhcmVudE5vZGUuaW5zZXJ0QmVmb3JlKGIsIHMpO30pKCk7CiAgICA8L3NjcmlwdD4KICAgIDxub3NjcmlwdD4KICAgICAgICA8aW1nIGhlaWdodD0iMSIgd2lkdGg9IjEiIHN0eWxlPSJkaXNwbGF5Om5vbmU7IiBhbHQ9IiIgc3JjPSJodHRwczovL3B4LmFkcy5saW5rZWRpbi5jb20vY29sbGVjdC8/cGlkPTEyMzUwNzMmZm10PWdpZiIgLz4KICAgIDwvbm9zY3JpcHQ+CiAgICA8IS0tIEVuZCBMaW5rZWRJbiAtLT4KICAgIA==
Generic filters
Exact matches only
Search in title
Search in excerpt
Search in content

In 10 Tagen einmal um die SAP-ERP-Welt - Tag 2

Dieser Blogbeitrag bietet einen Überblick über die jeweiligen Hierarchien des SAP-ERP-Systems und legt dar, welche Tabellen bei Bedarf mindestens einzubeziehen sind.

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.

Die Hierarchien des SAP-ERP-Systems lassen sich gleichermaßen ordentlich strukturieren wie die Bewegungs- und Stammdaten, welche in den vorherigen Artikeln ansatzweise beschrieben wurden. Hinsichtlich der Hierarchien ist aber zu beachten, dass diese in unterschiedlicher Art und Weise definiert werden.

Zum Beispiel können die erforderlichen Tabellen für die Hierarchien des SAP-ERP-Systems folgendermaßen fürs Erste hinreichend gegliedert werden:

Modul Tabelle Beschreibung
SET SETCLS Setklassen
SETHEADER Setkopf und Setverzeichnis
SETNODE Untergeordnete Sets in Sets
SETLEAF Werte in Sets
TKCH TKCHV SAP-EIS: Hierarchievarianten
TKCHH SAP-EIS: Hierarchie-Header
TKCHN SAP-EIS: Hierarchieknoten
TKCHW SAP-EIS: Hierarchiedaten
T011 T011 Bilanz/GuV-Strukturen
FAGL_011PC Bil/GuV-Struktur: Positionen der Bil/GuV-Struktur
FAGL_011SC Bil/GuV-Struktur: Zuordnung Bil/GuV-Pos. – Setname
FAGL_011ZC Bil/GuV-Struktur: Zuordnung Bil/GuV-Pos. Hauptbuchkonten
FAGL_011FC Bil/GuV-Struktur: Zuordnung Bil/GuV-Pos. – Funktionsbereiche
FAGL_011VC Bil/GuV-Struktur: Saldowechselpositionen
STPO STKO Stücklistenkopf
STPO Stücklistenposition
MAST Verbindung Material – Stückliste
T179 T179 Materialien: Produkthierarchien
KNVH KNVH Kundenhierarchien
LFMH LFMH Lieferantenhierarchie
PRHI PRHI Projektstrukturplan, Kanten (Hierarchieanzeiger)

Innerhalb der SET-Tabellen werden unter anderem Gruppierungen für folgende Stammdaten definiert:

  • Kostenstellen (SETCLASS = 0101)
  • Kostenarten (SETCLASS = 0102)
  • Innenaufträge (SETCLASS = 0103)
  • Statistische Kennzahlen (SETCLASS = 0104)
  • Leistungsarten (SETCLASS = 0105)
  • Profitcenter (SETCLASS = 0106)
  • Kostenträger (SETCLASS = 0108)
  • Sachkonten (SETCLASS = 0109)
  • Funktionsbereiche (SETCLASS = 0112)
  • Konsolidierungseinheiten (SETCLASS = 0301)
  • Konsolidierungspositionen (SETCLASS = 0302)
  • Konsolidierungsunterpositionen (SETCLASS = 0303)

Im Rahmen einer SQL-Datenbank lohnt sich meistens der Einsatz einer übergeordneten Archiv-Tabelle für Hierarchien, welche die einzelnen Hierarchiedefinitionen einheitlich und kompakt zusammenführt.
Als Beispiel dient folgender Datensatzaufbau:

CREATE TABLE [dbo].[T_ARCHIVE_HIERARCHY](
    [Client] [nvarchar](3) NOT NULL,
    [HierarchyType] [nvarchar](4) NOT NULL,
    [HierarchyDomain] [nvarchar](12) NOT NULL,
    [HierarchyName] [nvarchar](50) NOT NULL,
    [ParentLevel] [nvarchar](2) NOT NULL,
    [ParentName] [nvarchar](50) NOT NULL,
    [ParentType] [nvarchar](1) NOT NULL,
    [ParentLine] [nvarchar](10) NOT NULL,
    [ChildName] [nvarchar](50) NOT NULL,
    [ChildType] [nvarchar](4) NOT NULL,
    [ChildOrder] [nvarchar](5) NOT NULL,
    [LevelOrder] [nvarchar](100) NULL,
    [Level00] [nvarchar](50) NULL,
    [Level01] [nvarchar](50) NULL,
    [Level02] [nvarchar](50) NULL,
    [Level03] [nvarchar](50) NULL,
    [Level04] [nvarchar](50) NULL,
    [Level05] [nvarchar](50) NULL,
    [Level06] [nvarchar](50) NULL,
    [Level07] [nvarchar](50) NULL,
    [Level08] [nvarchar](50) NULL,
    [Level09] [nvarchar](50) NULL,
    [Level10] [nvarchar](50) NULL,
    [Level11] [nvarchar](50) NULL,
    [Level12] [nvarchar](50) NULL,
    [Level13] [nvarchar](50) NULL,
    [Level14] [nvarchar](50) NULL,
    [Level15] [nvarchar](50) NULL,
    [Level16] [nvarchar](50) NULL,
    [Level17] [nvarchar](50) NULL,
    [Level18] [nvarchar](50) NULL,
    [Level19] [nvarchar](50) NULL,
 CONSTRAINT [PK_T_ARCHIVE_HIERARCHY] PRIMARY KEY CLUSTERED
(
    [Client] ASC,
    [HierarchyType] ASC,
    [HierarchyDomain] ASC,
    [HierarchyName] ASC,
    [ParentLevel] ASC,
    [ParentName] ASC,
    [ParentType] ASC,
    [ParentLine] ASC,
    [ChildName] ASC,
    [ChildType] ASC,
    [ChildOrder] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

Innerhalb dieser SQL-Tabelle können die Hierarchiedefinitionen gleichzeitig in zweifacher Form gespeichert werden:

  • zeilenweise mit Parent-Child-Beziehungen und
  • spaltenweise mit festen Ebenenzuordnungen.

Über den ChildType kann hierbei differenziert werden nach

  • Stammdateneinträgen sowie
  • End- und Zwischenknoten.

Die dazugehörigen Texte der Hierarchieelemente sollten ebenfalls zentral aus den jeweiligen Text- bzw. Stammtabellen gespeichert werden. Als Beispiel dient folgender Datensatzaufbau:

CREATE TABLE [dbo].[T_ARCHIVE_HIERARCHY_TEXT](
    [Client] [nvarchar](3) NOT NULL,
    [HierarchyType] [nvarchar](4) NOT NULL,
    [HierarchyDomain] [nvarchar](12) NOT NULL,
    [MemberName] [nvarchar](50) NOT NULL,
    [MemberType] [nvarchar](4) NULL,
    [MemberTextDE] [nvarchar](50) NULL,
    [MemberTextEN] [nvarchar](50) NULL,
    [MemberTextES] [nvarchar](50) NULL,
    [MemberTextFR] [nvarchar](50) NULL,
    [MemberTextIT] [nvarchar](50) NULL,
 CONSTRAINT [PK_T_ARCHIVE_HIERARCHY_TEXT] PRIMARY KEY CLUSTERED
(
    [Client] ASC,
    [HierarchyType] ASC,
    [HierarchyDomain] ASC,
    [MemberName] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

Für die Befüllung dieser beiden Archiv-Tabellen gibt es grundlegende SQL-Prozeduren.

Fazit

Wenn die definierten Hierarchien in dieser gespeicherten Form vorliegen, können diese genauso leicht wie die Texttabellen mit den entsprechenden Stammdaten verknüpft werden. Und es gilt die Anmerkung: ohne eine strukturierte Zusammenführung der einzelnen Hierarchiedefinitionen ist eine richtige Verknüpfung mit den jeweiligen Stammdaten in vielen Fällen nur äußerst mühselig möglich.

Wir hoffen, dass die formulierten Ansatzpunkte als Hilfestellung dienen und etwas Licht in das Dickicht der SAP-Tabellen bringen.

Der nächste Artikel wird ein mehrstufiges Schichten-Modell für den SAP-Datenfluss innerhalb von MS-SQL/AS-Datenbanken thematisieren und allgemeingültige Begriffe darlegen, welche in der SAP-Welt eine zentrale Bedeutung haben.

Wie immer wünschen wir viel Spaß bei der Arbeit und frohes Gelingen.