Nein, nein, nein, … das soll man nie machen – nie. Aber doch tut man es regelmäßig: Direkte Änderungen der Werte einer Datenbanktabellen. Auch wenn es als „Todsünde“ gilt, gibt es doch immer wieder Situationen, in denen Daten auf der DB modifiziert werden müssen. Vorallem im Testsystem kann es legitim sein diese Möglichkeit zu nutzen, um zügig verschiedene Varianten durch zu testen. Aber ich habe auch Projekte erlebt, wo auf dem Produktivsystem Daten angepasst wurden. Dabei wurde dieser Schritt damit begründet, dass im System ein so krasser Fehler auftrat, dass die Belege nicht mehr zu retten waren. Als erfahrener Berater sollte man die Gefahren und die Möglichkeiten der Datenbankanpassungen kennen – übrigens alle im folgenden beschriebenen Möglichkeiten können durch die SAP-Basis trotzt SAP_ALL-Berechtigung abgeknipst werden.

Zunächst einmal will ich auf die Gefahren eingehen, die damit verbunden sind, direkt Daten auf der DB zu verändern.

# An oberster Stelle kommt der rechtliche Aspekt: Jeder, der Daten in einem produktiven SAP-System verändert, macht sich wahrscheinlich strafbar. Im Detail bedeutet dieser Schritt ja, dass man die „Bücher“ eines Unternehmens manipuliert.

# Letztlich ist eine Veränderung von Daten auch systemtechnisch sehr kritisch; vielfach kann man nicht absehen, welche Auswirkungen dieser Eingriff verursacht –> System Stillstand?!

# Auch wenn man sich nur darauf beschränkt Werte im Testsystem zu verändern, besteht die Gefahr, dass man im Testsystem ein Schiefstand erzeugt, der sich unbemerkt auf alle weiteren Tests auswirkt.

So, auch wenn ihr wahrscheinlich keine Lust habt die Daten in SAP zu verändern, will ich kurz darstellen, wie es funktioniert.

Der einfache Weg – SE16N

Der einfachste Weg zum Verändern von Daten auf der DB ist die Nutzung der SE16N; dabei sieht das Vorgehen wie folgt aus:

#1 Transaktion SE16N aufrufen

#2 Die Tabelle eingeben (links oben), deren Daten man anpassen will und Enter

#3 Jetzt ins Transaktionsfeld &SAP_EDIT eingeben und Enter

#4 Jetzt über die Selektionsfelder die Daten Sätze selektieren, die modifiziert werden sollen, und Ausführen (F8)

#5 Im folgenden Screen (Darstellung der Selektionsergebnisse) können die Daten einfach in der ALV-Liste überschrieben und gesichert werden.

Übrigens: Wenn du nach dem Schritt #3 in die Transaktionsleiste „&sap_no_check“ eingibst und Enter drückst, dann werden auf die Werteprüfungen beim Editieren unterdrückt.

Protokollierung der Änderung per SE16N

Änderung von Tabellenwerten per SE16N werden protokolliert; damit kann man nachvollziehen welcher User, wann, welche Daten, wie verändert hat. Die Protokollierung erfolgt in den Tabellen:

# SE16N_CD_DATA

# SE16N_CD_KEY

Der umständlichere Weg – SE16

Etwas umständlicher kann man die Daten in einer Tabelle auch per SE16 verändern:

#1 Transaktion SE16 starten

#2 Die Tabelle eingeben, deren Daten man anpassen will, und Enter

#3 Anschließend im Selektionsfeld die relevanten Daten selektieren und Ausführen (F8)

#4 In der folgenden Liste der Ergebnisse den Satz markieren, der zu verändern ist, und links oben auf das Brillen-Icon (Anzeigen – F7) klicken.

#5 In dieser Detailansicht muss man nun in den Debugger-Modus aktivieren: In der Transaktionsleiste „/h“ eingeben.

#6 Jetzt mit der Maus in irgendein Feld klicken und Enter

#7 Ab hier solltest du ins Coding gesprungen sein: Hier Doppelklick auf die Variable „CODE“ und den Wert von „CODE“ von „SHOW“ auf „EDIT“ verändern. Verändern kann man den „CODE“ mit dem Stift-Icon.

#8 Jetzt den Code weiter laufen lassen – F8

#9 Ab jetzt sollten die Werte des Tabelleneintrags editierbar sein; nach Veränderung der Daten einfach sichern (STRG+S).

Unterschiede der beiden Varianten SE16 und SE16N

# Mit der SE16N kann man mehrere Datensätze in einem Schritt verändern; diese Möglichkeit besteht mit der SE16-Methode nicht. Hier kann man immer nur einen Datensatz verändern.

# Die Veränderungen mit der SE16-Methode werden nicht in einer Tabelle protokolliert; hier erfolgt die Protokollierung im System-Log.

# Letztlich ist bei einigen SAP-Systemen (bspw. SCM) die Transaktion SE16N nicht verfügbar; hier muss man auf die SE16-Methode zurückgreifen.

 

 

Ist dir schon mal aufgefallen, dass es in SAP-Projekten vielfach um Prüfen, Testen, Qualitätssicherung oder Monitoring geht? Wenn man sich einen klassischen Projektzyklus anschaut, treten immer wieder folgende Prüfpunkte auf, die durchlaufen werden:

# Prüfung: Ein Konzept muss vom Fachbereich abgenommen werden.

# Qualitätssicherung. Ein Konzept muss durch die QS.

# Funktionstest: Ein Entwicklung oder Customizing muss zunächst durch einen Funktionstest.

# Integrationstest: An den Funktionstest reiht sich der Integrationstest an.

# Code-Prüfung: Bevor eine Entwicklung freigegeben wird, wird sie auf die Codequalität geprüft.

# Proaktives Monitoring: Direkt nach dem Go-Live eines Projektes erfolgt ein proaktives Monitoring, um Fehler frühzeitig zu ermitteln.

# Monitoring: Letztlich wird das Projekt an den Support übergeben, wo regelmäßig bestimmte Daten geprüft werden.

Vor allem der letzte Punkt, das regelmäßige Monitoring der Prozesse / Anwendungen, kann schnell in der täglichen Routine – nach dem Motto „die letzten 1000-Male ist ja auch nichts passiert“ – vernachlässigt werden. Hier gibt es eine einfache Möglichkeit das Monitoring zu automatisieren und bei Fehlern eine+ Mail aus dem System zu erhalten. Im Grunde funktioniert dieses Feature immer nach dem gleichen Prinzip:

#1 Man legt ein Query / QuickView an, die die zu prüfenden Daten ermittelt.

#2 Anschließend ermittelt man den zu gehörigen Report zum Query und legt zu diesem Report eine Variante an.

#3 Dann muss man einfach einen Job (mit Report und Variante) einplanen, der in regelmäßigen Abständen läuft.

#4 Wichtig: Bei der Jobdefinition muss man im Bereich „Allgemeine Daten“ unter Spolllisten-Empfänger eine E-Mail-Adresse / VL eintragen, wohin das Ergebnis (Spool) des Jobs versandt wird.

#5 Nun bekommt der Mail-Empfänger immer eine Mail, wenn der Job gelaufen ist und ein Ergebnis ermitteln konnte.

Mit diesem einfachen Vorgehen kann man bspw. folgende Punkte einfach und automatisiert prüfen:

# Auftragsmenge zu hoch – Einfach ein QuickView auf die Tabelle VBAP mit der Selektion Variante KWMENG >10.000 und die Variante als stündlich laufenden Job einplanen

# Lieferungen immer noch nicht WA-gebucht – Ein QuickView auf die Tabelle SHP_IDX_GDSI legen mit Variante Lieferdatum älter als 7 Tage

# Gutschriften noch nicht fakturiert – Query mit den Tabelle-Join VBAK-VBUK bauen und Job mit Variante Gutschrift angelegt älter als 7 Tage und Fakturastatus <> C

Probiert es mal das Feature einfach mal für eine kleine Prüfung – ich denke, ihr werdet begeistert sein.

 

Eigentlich hatte sich Pierre für heute Abend zum Fußballspiel mit den Kollegen verabredet, als er die Mail seines Teamleiters las. „Musste das kurz vor Feierabend passieren“, dachte sich Pierre ärgerlich. Es war jetzt 17:17 Uhr und der EDI-Dienstleister hatte sich gemeldet. Seit 12:35 Uhr waren die ORDERS-IDocs von verschiedenen Kunden falsch geroutet worden, wodurch Daten der IDocs fehlerhaft waren. Der Teamleiter bat Pierre alle Aufträge zu den 2.786 ORDERS-IDocs abzusagen, die im Anhang der Mail aufgelistet waren – 2.786 IDocs! Wenn Pierre eine Liste mit Aufträgen gehabt hätte, wäre es ein Klacks die Aufträge mit der Transaktion MASS abzusagen. Doch mit der IDoc-Liste müsste er per WE02 jedes IDoc aufrufen und über die Verlinkung (Dienste zum Objekt -> Verknüpfungen anzeigen) den Kundenauftrag ermitteln – Pierre hätte wirkliche eine lange Nacht vor dem Rechner gehabt, wenn er sich nicht an folgende Zusammenhänge erinnert hätte:

# Die IDoc-Verlinkung zu den zugehörigen Belegen ist in den Tabellen SRRELROLES und IDOCREL abgelegt.

Wie oben erwähnt, kann man zu einem IDoc oder einer Liste von IDocs (normalerweise) die zugehörigen Belege über die Tabellen SRRELROLES und IDOCREL ermitteln.

# Liste ORDERS-IDocs –> Liste Aufträge
# Liste DESADV-IDocs –> Liste Lieferungen
# Liste INVOIC-IDocs –> Liste Fakturen

Die Zusammenhänge sind in den folgenden Abbildungen dargestellt.

 

Entscheidend ist hierbei, dass für Eingangs-IDocs (bspw. ORDERS) und Ausgangs-IDocs (bspw. INVOIC) der Zugriff auf die IDOCREL-Tabelle unterschiedlich ist. Im folgenden zunächst die Beschreibung für Eingangs-IDocs:

Eingangs-IDocs

# Dir liegt eine Liste von Eingangs-IDoc-Nummern vor (bspw. ORDERS) – wichtig ist, dass die IDoc-Nummern 16-stellig mit führenden Nullen aufgefüllt sein müssen.

# Ruf die Tabelle SRRELROLES auf (SE16) und gib die Nummern der IDocs in das Feld OBJKEY ein -> Ausführen (F8)

# Aus dem Selektionsergebnis kopierst du nun alle Einträge der Spalte ROLEID

# Nun öffnest du am besten in einem neuen Modus die Tabelle IDOCREL (SE16)

# Hier gibst du die kopierten Daten (ROLEID) aus der ersten Tabelle in das Selektionsfeld ROLE_A ein -> Ausführen (F8)

# Nun musst du aus der Ergebnis-Liste die Werte der Spalte ROLE_B herauskopieren.

# Jetzt öffnest du erneut die Tabelle SRRELROLES (SE16) und gibst die kopierten Werte (ROLE_B) aus der Tabelle IDOCREL in das Selektionsfeld ROLEID ein -> Ausführen (F8)

# Nun kannst du einfach aus dem Feld OBJKEY die Beleg (bspw. Aufträge) ermitteln bzw. herauskopieren.

# Da im letzten Schritt neben dem konkreten Belegen noch weitere Verlinkungsdaten ermittelt werden, kann man per Filter auf die Spalte OBJTYPE die Ergebnisse auf die Belege beschränken – für Aufträge gilt der OBJTYPE = BUS2032

Ausgangs-IDocs

Die Ermittlung der Belege für Ausgangs-IDocs unterscheidet sich in zwei entscheidenden Punkten gegenüber der oben aufgeführten Beschreibung (dieser Unterschied ist in den Abbildung dargestellt).

# Bei Ausgangs-IDoc steigt man mit den Ergebnissen aus der SRRELROLES-Tabelle in die IDOCREL-Tabelle im Feld ROLE_B ein.

# Anschließend kopiert man die Ergebnisse aus der Spalte ROLE_A steigt damit in die Tabelle SRRELROLES ein.

Übrigens mit diesen Erkenntnissen hat es Pierre keine 5 Minuten gekostet, die Aufträge zu der Liste der IDocs zu ermitteln und anschließend abzusagen …  damit konnte er sich auf das anstehende Fussballspiel freuen 😉

Wie immer: Es wäre toll, wenn du ein kleines Feedback hinterlassen könntest, Isa.

Muss man einen Schraubenzieher haben, um ein Auto fahren zu können? Muss man fliegen können, um in Richtung Australien abzuheben? Muss man programmieren können, um Excel nutzen zu können? Auf alle Fragen ist die Antwort ein klares Nein. Doch der Mechaniker deines Vertrauens sollte schon ein Schraubenzieher benutzen können, der Pilot, der dich nach Australien fliegt, sollte auch sein Handwerkszeug beherrschen und letztlich bietet Excel vielen Funktionen, ohne dass man VBA beherrscht.

Im SAP-Bereich verhält sich genauso mit Datenbanktabellen; der User, der tagtäglich seine Arbeit im System erledigt, muss keine einzige Tabelle kennen. Aber als versierter Berater ist es unumgänglich die Tabellen zu kennen, in denen das SAP-System die Daten vorhält.

Im Folgenden habe ich eine Reihe von SD-Tabellen zusammengestellt, die ein SD-Berater kennen sollte. Im Detail wurden die Tabellen in 3 Blöcke gegliedert:

# Bewegungsdaten-Tabellen

# Stammdaten-Tabellen

# Customizingdaten-Tabellen

 

Im Bereich der Bewegungsdaten gibt es noch folgenden Sondertabellen:

# Statische Indextabelle

# Dynamische Indextabelle

 

Statische Indextabellen sind von SAP vorgesehen, um performant bestimmte Daten zu ermitteln – bspw. die Tabelle VAKPA: Basierend auf dieser Tabelle kann man zügig Aufträge zu einem bestimmten Kunden ermitteln. Ich nenne diese Tabellen statisch, da sich die Anzahl der Einträge in der Tabelle mit dem Prozessfortschritt nicht verändert. Unten in der Liste wurden statische Indextabellen mit einem SI gekennzeichnet.

 

Dynamische Indextabellen sind im Grunde auch dafür vorgesehen, um performant auf Daten zuzugreifen. Doch im Gegensatz zu statischen Indextabellen werden die Einträge in diesen Tabellen mit dem Prozessfortschritt aktualisiert. Bspw. die Tabelle VEPVG: In dieser Index-Tabelle sind Aufträge enthalten, die noch zu beliefern sind. Doch sobald sie beliefert wurden, werden die Aufträge aus dieser Tabelle automatisch entfernt. In der Liste habe ich diese Tabellen mit einem DI gekennzeichnet.

 

SD-Tabellen zu Bewegungsdaten

#1 VBAK – Verkaufsbeleg: Kopfdaten

Die VBAK ist die zentrale Tabelle für Kundenaufträge; sie enthält die Kopfdaten des Kundenauftrags, wie Auftragsnummer, Kunde, Auftragsart, Kalkulationsschema oder Versandbedingung.

#2 VBAP – Verkaufsbeleg: Positionsdaten

Die Tabelle VBAP enthält die Positionsdaten eines Kundenauftrags; bspw. Auftrags- / Positionsnummer, Material, Menge, Auslieferwerk oder Versandstelle.

#3 VBEP – Verkaufsbeleg: Einteilungsdaten

In der VBEP sind die Einteilungen einer Kundenauftragsposition enthalten. In dieser Tabelle sind zu den Einteilungen die detaillierten Terminierungsdaten (Lieferdatum, …) enthalten.

#4 VBKD – Verkaufsbeleg: Kaufmännische Daten

In dieser Tabelle sind die Kaufmännischen Daten (Incoterm, Zahlungsbedingungen, …) zu einem Kundenauftrag enthalten. In dieser Tabelle werden sowohl die Kopf- als auch die Positionsdaten abgelegt.

#5 VAKPA – Vertriebsindex: Aufträge zu Partnerrollen (SI)

Die Tabelle ist eine Index-Tabelle und ist für die schnelle Suche nach Kundenaufträgen nach ausgewählten Feldern des Kundenauftragskopfs vorgesehen; wenn du bspw. Kundenaufträge zu einem bestimmten Kunden suchst, ist diese Tabelle top.

#6 VAPMA – Vertriebsindex: Auftragspositionen zu Material (SI)

Mit dieser Index-Tabelle kann man optimierte Kundenaufträge für Positionsdaten suchen; bspw. „gib mir alle Aufträge zu einem bestimmten Material“ – Ruckzuck hat man ein Ergebnis.

#7 VEPVG – Versandfälligkeitsindex (DI)

Die VEPVG ist eine dynamische Indextabelle und alle Kundenaufträge, die noch beliefert werden müssen. Sobald der Auftrag beliefert wurde, wird er aus dieser Tabelle gelöscht.

#8 KONV – Konditionen (Vorgangsdaten)

In dieser Tabelle werden alle Konditionsdetails (Preise) zu einem Kundenauftrag abgelegt. Die Verbindung (Join) zwischen der VBAK und der KONV erfolgt über das Feld KNUMV.

#9 VBBE – Vertriebsbedarfseinzelsätze (DI)

In dieser Tabelle sind, wenn die Verfügbarkeitsprüfung aktiviert ist, die Kundenauftragsbedarfe pro Einzelsatz (positionsweise) abgelegt.

#10 VBBS – Vertriebsbedarfssummensatz (DI)

In der VBBS sind, wenn die Verfügbarkeitsprüfung aktiviert ist, die Kundenauftragsbedarfe als Summensatz abgelegt.

#11 LIKP – Vertriebsbeleg: Lieferung: Kopfdaten

Die LIKP enthält die Kopfdaten der Auslieferung  – im Detail sind es bspw. folgende Daten:  Liefernummer, Lieferart, Versandstelle, Kunde, etc.

#12 LIPS – Vertriebsbeleg: Lieferung: Positionsdaten

In der LIPS sind die Positionsdaten zu einer Auslieferung enthalten; bspw. Lieferung, Positionsnummer, Material, Liefermenge, Charge, …

#13 VLKPA – Vertriebsindex: Lieferungen zu Partnerrollen (SI)

Die Tabelle ist eine Index-Tabelle für Kopfdaten der Lieferung. Mit ihr kann man per SE16 zügig Lieferung bspw. zu einem Kunden ermitteln.

#14 VLPMA – Vertriebsindex: Lieferungspositionen zu Material (SI)

Die Index-Tabelle VLPMA bietet einen performanten Zugriff auf ausgewählte Positionsdaten einer Lieferung; bspw. kann man über alle Lieferungen ermitteln in welchen Lieferungen ein bestimmtes Material enthalten ist.

#15 SHP_IDX_GDSI – Auslieferungen: noch nicht Warenausgang gebucht (DI)

Die SHP_IDX_GDSI ist eine dynamische Indextabelle in der alle Lieferungen enthalten sind, die noch nicht WA gebucht wurde.

#16 SHP_IDX_PICK – Auslieferungen: noch nicht kommissioniert (DI)

In der dynamischen Indextabelle SHP_IDX_PICK sind alle Lieferungen enthalten, die noch zu kommissionieren sind.

#17 VBRK – Faktura: Kopfdaten

Die VBRK ist die zentrale Tabelle für die Fakturen im SD-Modul. Sie enthält die Kopfdaten der Faktura: Fakturanummer, Zahlungsbedingung, Regulierer, Fakturaart, …

#18 VBRP – Faktura: Positionsdaten

In der VBRP sind die Positionsdaten zu einer Lieferung enthalten: Fakturanummer, Positionsnummer, Material, Fakturamenge, …

#19 VRKPA – Vertriebsindex: Fakturen zu Partnerrollen (SI)

Mittels dieser Index-Tabelle können Fakturen basierend auf Kopfdaten performant selektiert werden.

#20 VRPMA – Vertriebsindex: Fakturapositionen zu Material (SI)

Als Pendant zur vorherigen Tabelle bietet die VRPMA die Möglichkeit schnell Fakturen per Material zu suchen.

#21 VTTK – Transportkopf

Die Tabelle VTTK enthält die Kopfdaten des LES-Transportbeleges; sie enthält unter anderem folgende Daten: Transportnummer, Transportart, Transportdispostelle, …

#22 VTTP – Transportposition

In dieser Tabelle sind die Auslieferungen enthalten, die zu einem Transportbeleg zugeordnet sind; damit bilden die Lieferungen die Positionen eines Transportbeleges.

#23 VTTS – Transportabschnitt

In dieser Tabelle sind die einzelnen Abschnitte eines Transports abgelegt. Die Abschnitt sind bspw.: Startpunkt, einzelne Haltepunkte (Kunden) und der Endpunkt.

#24 VTRDI – Transportdispositionsindex (DI)

Die VTRDI ist eine Index-Tabelle, mit der performant ermittelt werden kann, wie der Transportdispo-Status der Lieferungen ist.

#25 VEKP – Handling Unit Kopftabelle

Diese Tabelle ist die Kopftabelle für Hus (Handling Units). Sie enthält unter anderem folgende Daten: HU-Nummer, SSCC-Nummer, Anlagedatum, HU-Typ, Zuordnung der HU (Auslieferung, …), etc.

#26 VEPO – Verpacken: Handling Unit Position (Inhalt)

Die VEPO enthält die Positionsdaten einer HU – konkret bedeutet dies: Welche Materialien und in welcher Menge ist in der HU enthalten.

#27 VEVW – Verwendungsnachweis für Handling Units

In dieser Tabelle ist abgelegt, zu welchem Objekt (Auslieferung, Anlieferung, Transport, …) die HU zugeordnet ist.

#28 VBPA – Vertriebsbeleg: Partner

In der VBPA sind die verschiedenen Partner zu einem Vertriebsbeleg abgelegt. Bspw. wird in dieser Tabelle der Auftraggeber (AG), Warenempfänger (WE), Rechnungsempfänger (RE) und der Regulierer (RG) zu einem Kundenauftrag gespeichert.

#29 NAST – Nachrichtenstatus

In der Tabelle NAST werden alle Nachrichten, die aus SAP-Belegen erzeugt wurden, gespeichert. Bspw. sind hier alle Rechnungsnachrichten zu Fakturen abgelegt: Zu welcher Faktura, wann angelegt, wann prozessiert, …

#30 VETVG – Versandfälligkeitsindex für Umlagerung

In dieser dynamischen Index-Tabelle sind alle Umlagerungsbestellungen abgelegt, die noch zu beliefern sind.

#31 EDIDC – Kontrollsatz (IDoc)

Die EDIDC ist die Kopf-Tabelle für IDocs. Hier sind unter anderem folgende Daten abgelegt: IDoc-Nummer, Anlagedatum, Änderungsdatum, Nachrichtentyp, Verarbeitungsstatus.

#32 EDIDS – Statussatz (IDoc)

Die EDIDS enthält die Statussätze der IDocs; hierbei wird zu jedem Status ein detaillierter Status (verarbeitet, wartet, fehlerhaft, angelegt, …) in diese Tabelle geschrieben.

#33 EDID4 – IDoc-Datensätze

Die Tabelle EDID4 enthält alle Inhalte der IDocs. Hierbei ist zu beachten, dass die Daten nicht strukturiert in einzelne Felder gespeichert sind, sondern alle Daten eines Segments hintereinander in einem 1000-Zeichen großen String abgelegt sind.

 

SD-Tabellen zu Stammdaten

#34 KNA1 – Kundenstamm (allgemeiner Teil)

Die KNA1 ist zentrale Kundenstamm-Tabelle. Hier sind pro Kunde bspw. folgende Daten abgelegt: Kundennummer; Kundenname, Adressdaten, Umsatzsteuer-Identifikationsnummer, …

#35 KNVV – Kundenstamm Vertriebsdaten

Die Tabelle KNVV enthält vertriebsspezifische Daten zum Kunden; bspw.: Zuordnung zum Vertriebsbereich (VKOrg, VTWeg, Sparte), Vorschlagsversandbedingung, Vorschlagsauslieferwerk, …

#36 KNVP – Kundenstamm Partnerrollen

In der Tabelle KNVP sind die unterschiedlichen Partnerrollen je Vertriebsbereich abgelegt, die dem Kunden zugeordnet sind.

#37 MARA – Allgemeine Materialdaten

Die MARA ist die zentrale Materialstammdaten-Tabelle; in dieser Tabelle sind unter anderem folgende Daten enthalten: Materialnummer, Materialart, Pflegestatus, Positionstypengruppe, …

#38 MARC – Betriebsdaten zum Material

Die Tabelle MARC enthält zu den Materialien die werksspezifischen Daten; damit enthält die Tabelle pro Werk, für das es gepflegt wurde, genau einen Eintrag mit folgenden Daten: Bspw.: Dispomerkmal, Einkäufergruppe, Ladegruppe, …

#39 MVKE – Verkaufsdaten zum Material

In der MVKE sind die vertriebsspezifischen Daten zu einem Material abgelegt, bspw. zugeordneter Vertriebsbereich, Preismaterial, Verkaufsmengeneinheit, …

#40 MARD – Lagerortdaten zum Material

Die MARD enthält die Lagerortdaten zu einem Material; damit wird für jede Kombination an Material-Werk-Lagerort ein Eintrag in diese Tabelle angelegt.

#41 MAKT – Materialkurztexte

Die MAKT enthält die Texte zu den Materialien; hier wird pro Material und Sprache ein Satz in diese Tabelle abgelegt.

 

SD-Tabellen zu Customizingdaten

#42 TVAK – Auftragsarten

In der TVAK werden die Customizingeinstellungen pro Auftragsart abgelegt; bspw.: Nummernkreis, Partnerschema, Textschema, Nachrichtenschema, …

#43 TVAU – Auftragsgründe

In der Tabelle TVAU werden die möglichen Auftragsgründe abgelegt, die zu einem Auftrag erfasst werden können.

#44 TVAKZ – Zuordnung Vertriebsbereich zu Auftragsarten

In dieser Tabelle werden die Auftragsarten zu Vertriebsbereichen zugeordnet. Wenn in dieser Tabelle keine Zuordnung vorhanden ist, sind alle Auftragsarten für alle Vertriebsbereiche gültig.

#45 TVAP – Auftragspositionstypen definieren

In der TVAP sind die Customizingeinstellungen für die Positionstypen eines Kundenauftrags abgelegt. Unter anderem steuert die Tabelle die Fakturarelevanz, das Unvollständigkeitsschema, …

#46 T184 – Positionstypenfindung Auftrag

In dieser Tabelle ist die Positionstypenfindung für den Kundenauftrag abgelegt, d.h. die Einstellungen dieser Tabelle bestimmen, welcher Positionstyp abhängig von verschiedenen Kriterien ermittelt wird.

#47 TVCPA – Kopiersteuerung Auftrag

In der Tabelle TVCPA sind die Details der Kopiersteuerung für Aufträge abgelegt; im Detail: Kopierroutinen, Datenübernahmeroutinen, …

#48 TVAG – Absagegründe

In der TVAG sind die möglichen Absagegründe für Kundenaufträge abgelegt.

#49 TVEP – Einteilungstypen definieren

In der TVEP sind die Einstellungen pro Einteilungstyp abgelegt – unter anderem ist in dieser Tabelle die Bewegungsart abgelegt, mit der Warenausgang gebucht wird.

#50 TVEPZ – Einteilungstypen zuordnen

In der TVEPZ  wird die Einteilungstypenzuordnung pro Positionstyp und Dispomerkmal des Materials abgelegt.

#51 TVCPL – Kopiersteuerung Lieferung

Die TVCPL enthält die Details zur Kopiersteuerung von Auslieferungen.

#52 TVLK – Lieferarten

Die TVLK enthält die Customizingeinstellungen der Lieferarten im System; im Detail sind folgende Daten in der Tabelle vorgesehen: Nummernkreis, Bildfolgegruppe, Nachrichtenschema, …

#53 TVLP – Positionstypen Lieferung

In der Tabelle TVLP sind die Detaileinstellungen zur Steuerung der Lieferpositionstypen abgelegt.

#54 T184L – Positionstypenfindung Lieferung

Die Tabelle T184L ist das Pendant zur Auftragstabelle T184 und steuert die Positionstypenfindung in der Lieferung.

#55 TVFK – Fakturaarten

In der TVFK sind die Einstellungen für die Fakturaarten abgelegt. Im Detail sind folgende Daten in dieser Tabelle enthalten: Fakturaart, Nummernkreis, Kalkulationsschema, Nachrichtenschema, …

#56 TVCPF – Kopiersteuerung Faktura

Die TVCPF enthält die Steuerung der Kopiersteuerung für Fakturen.

#57 TVTY – Definition Packmittelarten

In der TVTY sind die Einstellungen für Packmittelarten (HU) abgelegt.

#58 T685B – Definition Nachrichtenarten

In der T685B sind die Einstellungen für die Nachrichtenarten abgelegt; unter anderem sind hier Daten wie Versandzeitpunkt und Sendemedium abgelegt.

#59 TNAPR – Zuordnung Verarbeitungsprogramme zu Nachrichtenarten

In der Tabelle TNAPR sind für Nachrichtenarten abhängig vom Sendemedium die unterschiedlichen Verarbeitungsprogramme zugeordnet.

#60 TVKO – Verkaufsorganisation definieren

In der TVKO werden die Verkaufsorganisationen definiert. Die Verkaufsorganisation ist das nach dem Buchungkreis das wichtigste Organisatorische Einheit im SD.

#61 TVSB – Versandbedingungen

In der TVSB sind die Versandbedingungen definiert. Die Versandbedingungen werden je Auftragsart oder Kunde zugeordnet und beeinflussen neben der Versandstellenfindung auch die Routenfindung im Auftrag.

#62 TVST – Versandstelle

In dieser Tabelle sind die Versandstellen definiert.

#63 TVSTZ – Versandstellenfindung

Die TVSTZ ist die Zuordnung der Versandstellen und wird für die Versandstellenfindung im Kundenauftrag genutzt.

#64 TVRO – Routendefinition

In der TVRO sind die Definitionen der Routen (Transitdauer, Kalender Spediteur, …) abgelegt.

#65 TROLZ – Routen: Ermittlung in Lieferungen

Die Tabelle TROLZ wird zur Ermittlung der Route herangezogen.

 

…Übrigens findet ihr alle Beiträge im Buch „SAP Helden“ kompakt zusammengefasst.

In Excel gibt es genau 2 Funktionen, die dir in der täglichen Arbeit enorm helfen: Zum einen ist dies der SVERWEIS und als zweites Pivot-Tabellen. Das Thema SVERWEIS hatte ich schon in diesem Beitrag vorgestellt. Nun würde ich Pivot-Tabellen in Excel vorstellen.

Pivot-Tabellen sind im Grunde ganz einfach: Die Daten in einer Excel-Tabelle werden in Pivot-Tabellen gruppiert und verdichtet dargestellt; das ist es – nicht mehr und nicht weniger. Am folgenden Bespiel will ich die Gruppierung kurz darstellen. Stell dir vor, es liegt eine Menge von unterschiedlichen Elementen vor, die mit einer bestimmten Kennzahl ausgestattet sind.

# Im konkreten Beispiel sind Päckchen in Wolken-, Stern- und Kreisformen mit dem jeweiligen Gewicht dargestellt:

Die Päckchen kann man nun sehr schön nach ihrer Form gruppieren und die Kennzahl Gewicht innerhalb einer Gruppe nach verschiedenen Aspekten aggregieren:

# Päckchen in Wolkenform

## Anzahl: 4
## Mittleres Gewicht: 9,4 kg
## Gesamtgewicht aller Wolkenformen: 56 kg
## Das schwerste wolkenförmige Päckchen: 25 kg
## Das leichteste wolkenförmige Päckchen: 2 kg

# Päckchen in Kreisform

## Anzahl: 5
## Mittleres Gewicht: 7 kg
## Gesamtgewicht aller Kreisformen: 35 kg
## Das schwerste kreisförmige Päckchen: 13 kg
## Das leichteste kreisförmige Päckchen: 1 kg

# Päckchen in Sternform

## Anzahl: 4
## Mittleres Gewicht: 6,25 kg
## Gesamtgewicht aller Sternformen: 25 kg
## Das schwerste sternförmige Päckchen: 14 kg
## Das leichteste sternförmige Päckchen: 1 kg

Und genau diese Gruppierung und Aggregieren kann man mittels Pivot-Tabellen in Excel mit nur ein paar Klicks darstellen …

Zunächst hier die oberen Päckchendaten in einer Excel-Tabelle:

Aus dieser Tabelle kann man nun eine Pivot-Tabelle erzeugen, in dem man den Mausfokus auf irgendeine Datenzelle legt, auf den Button „Pivot-Tabelle einfügen“ klickt und das folgende Pop-Up-Fenster mit OK bestätigt:

Anschließend bekommt man in einem neuen Tabellen-Blatt die leere Pivot-Tabelle dargestellt:

An dieser leeren Pivot-Tabelle erkennt man oben rechts die beiden Spalten „Element“ und „Gewicht“ der ursprünglichen Tabellen. Mit diesen Spalten kann man nun die Pivot-Tabelle mit Leben füllen. Bspw. kann man den Spaltennamen (oben rechts) mit der Maus in den Bereich „Zeilenüberschriften“ (rechts unten) ziehen und die Spalte „Gewicht“ in den Bereich „Werte“ (recht unten) ziehen – und siehe da die Pivot-Tabelle sieht dann so aus.

Diese Pivot-Tabelle stellt nun die Elemente gruppiert mit der Aggregation des Gesamtgewichts dar. Wenn man hier statt des Gesamtgewichts die Anzahl der unterschiedlichen Element sehen will, muss einfach im Bereich „Werte“ (rechts unten) auf das Feld „Summe von Gewicht“ klicken, den untersten Punkt „Wertfeldeinstellungen“ anklicken, statt „Summe“ den Punkt „Anzahl“ auswählen und mit OK bestätigen – und siehe da; jetzt werden die Anzahl der einzelnen Elemente dargestellt.

Hier ist es auch möglich die Gewichte der einzelnen Elementgruppen nach unterschiedlichen Aggregationen (Gesamtgewicht, Anzahl, Mittelwert, …) darzustellen. Hierzu muss einfach das „Gewicht“ von oben mehrfach in das Feld „Werte“ gezogen werden. Anschließend muss man pro Darstellung des Gewichts die gewünschte Aggregation – wie oben beschrieben – auswählen:

Mit ein paar Klicks haben wir nun aus einer chaotischen Liste eine schöne aggregierte Tabelle erstellt, die ein paar kurze und knackige Aussagen enthält.

So jetzt wissen wir, wie Pivot-Tabellen funktionieren. Der nächste Schritt ist es, aus SAP-Daten mit Hilfe von Pivot-Tabellen aussagekräftige Darstellungen zu zaubern – hierzu folgende Szenarien:

#1 Umlagerungsbestellungen: Um die Frachtkosten zu optimieren, stellt die Logistik-Abteilung die Frage, wie viele Umlagerungen von einem Werk zu einem anderen Werk erfolgen.

#2 Palettengewicht: Die Intra-Logistik will moderne und leichte Stapler anschaffen, dafür muss sie ermitteln wie viel Paletten im Lager maximal, minimal und im Durchschnitt wiegen, die im Lager bewegt werden.

#1 Analyse Umlagerungsbestellung per Tabelle LIPS und Pivot-Tabellen:

Zu Umlagerungsbestellungen werden sog. Nachschublieferungen im System angelegt. Diese Lieferungen enthalten auf Kopfebene unter anderem die Daten: Liefernummer, Datum, Versandstelle (woher kommt die Umlagerung), Kunde (wohin geht die Umlagerung), Bruttogewicht. Diese Daten kann man aus dem SAP-System basierend auf der Tabelle LIKP (SE16) ermitteln. Hier ein Auszug der Daten; in konkretem Fall wurden die Daten (2.976 Sätze) zwischen 02. Februar 2017 und 14. Februar 2017 ermittelt:

Basierend auf dieser Tabelle kann man nun (wie oben beschrieben) eine Pivot-Tabelle einfügen und die Spalten – wie unten dargestellt – anordnen:

Nun sieht man übersichtlich eine Transportmatrix der Umlagerung im analysierten Zeitraum. Bspw. sind 48 Umlagerungen zwischen der Versandstelle 2000 und dem Werk 1000 erfolgt. Oder man sieht, dass zwischen 1000 und 3000 keinerlei Umlagerungen stattfanden. Nach Bedarf kann man hier die noch mit dem Datum oder dem Bruttogewicht experimentieren, um andere Aussagen zu erhalte.

#2 Analyse der Paletten-Gewichte

Das HU-Management in SAP wird eingesetzt, um die Verpackungen in der Lagerabwicklung abzubilden. Hierbei können Verpackungen Container, Paletten, Kisten und vieles andere sein. Ein gängiger Einsatz von HUs sind unterschiedliche Paletten auf denen die Ware zum Kunden versandt wird. In unserem Beispiel setzen wir drei unterschiedliche Paletten-Typen ein: Euro-Palette, Düsseldorfer Paletten und Chep-Paletten. Die Frage, die wir mit Hilfe von Pivot-Tabellen beantworten wollen, ist:

Wie schwer sind die unterschiedlichen Paletten-Typen maximal, minimal und im Durchschnitt?

Hierzu liegen die Inhalte der Tabelle VEKP aus der letzten Woche vor, die wir aus dem SAP-System per SE16 ermittelt haben:

Diese wurden anschließend per Pivot-Tabelle wie folgt ausbereitet:

In dieser Pivot sieht man in einer Matrix die Maximal-, Minimal- und die Durchschnittsgewichte der unterschiedlichen Paletten-Typen.

Ich hoffe, ich konnte euch einen kurzen Einblick in Pivot-Tabellen geben, Isa.

 

Kommunikation, Kommunikation, Kommunikation … man kann es nicht oft genug wiederholen – Kommunikation ist das wichtigste Thema im Berufsleben eines SAP-Beraters. Egal ob man sich mit dem Kunden oder einem Kollegen über eine Fehlersituation unterhält, ein hunderte Seiten langes Konzept zur Preisfindung verfasst oder einen neuen Prozess vor der GF vorstellt, auf jeder erdenklichen Ebene findet Kommunikation statt. Und wenn man die Grundzüge der unterschiedlichen Kommunikationskanäle nicht beherrscht, wird man es … um es auf den Punkt zu bringen … als SAP-Berater nicht weit bringen .

Im Rahmen der schriftlichen Kommunikation ist für SAP-Berater das E-Mail das wichtigste Kommunikationsmedium. Es nimmt in der täglichen Arbeit einen nicht unerheblichen Stellenwert ein, und dem entsprechend sollte man sich als SAP-Berater über die Grundzüge des effektiven E-Mail-Schreibens klar sein.

Seit dem vor ca. 30 Jahren das E-Mail seinen Siegeszug im Berufsleben angetreten hat, sind schon Unmengen an guten oder weniger guten Tipps, Ratgebern und Büchern zu diesem Thema erschienen – wenn man in Google nach „Tipps zum Mail schreiben“ sucht, bekommt man über 8 Mio. Treffer, und eine Suche in Amazon-Bücher bringt immerhin über 120 Treffer.

Neben Grundlagen des E-Mail-Schreibens, wie kurze Sätze, Rechtschreibung, wenig Fremdwörter, etc. sind aus meiner Erfahrung zwei Punkte sehr wichtig, um effektive E-Mails zu schreiben:

# Gliederung / Formatierung
# Betreffzeile mit Aktionshinweis

Gliederung und Formatierung beim E-Mail schreiben

Vielfach bekommt man Mails, die aus monolithischen Textblöcken bestehen, wenig strukturiert sind und optisch wie dahin geknallt aussehen – und man denkt sich „… um was geht es hier?“ Hier wäre ein strukturierter Text optisch ansprechender und damit für den Empfänger viel besser zu lesen. Im Folgenden will ich das Thema mal anhand eines konkreten Beispiels darstellen.

Der monolithische Text

---

---

Immer wieder erhalte ich solche Mails, wo Unmengen Text zusammenhängend in einem Schwall zusammen geschrieben wurde. Der Text an sich mag gut formuliert und leicht zu lesen sein, doch der erste Eindruck schreckt meistens sofort ab. So viel Text und man weiß nicht, wo es beginnt und wo es enden will – bitte nicht solche Mails schreiben.

Der Text mit Absätzen

---

---

Dieser Text ist schon viel besser; es sind mehrere Absätze enthalten, die den Text in logische Blöcke teilen und den User führen – bitte wenigstens Absätze nutzen.

Der gegliederte Text

---

---

In dieser Mail sind nun die einzelnen Absätze nochmal in einzelne kleine Blöcke unterteilt, so dass der Leser sofort sieht, welche einzelnen Punkte angesprochen sind – aber das ist noch nicht die optimale Mail.

Der strukturierte Text

---

---

So … diese Mail unterscheidet sich im Text nicht wesentlich von der vorherigen bzw. der ersten Version, aber durch die Verwendung von Formatierungsfunktionen, wie Aufzählungspunkte, Einschübe, Fette und unterstrichene Überschriften, ist die Mail optimal gegliedert und strukturiert. Im Vergleich zur ersten Version der Mail gibt es himmelweite Unterschiede und vor allem wird der Leser die Informationen, die man vermitteln will, sehr einfach aufnehmen.

Betreffzeile mit Aktionshinweis

Die Betreffzeile ist meistens das wichtigste Element einer Mail. Sie ist der erste Eindruck, den der Leser bekommt. Wie sonst im Leben ist, ist auch bei einer Mail der erste Eindruck nun mal sehr wichtig. Aber ich will an dieser Stelle nicht darauf eingehen, wie man beeindruckende Betreffzeilen schreibt, sondern nur auf folgenden Umstand hinweisen: Schreibt in die Betreffzeile immer auch einen Aktionshinweis; das wird dir helfen, schneller Feedback auf deine Mails zu bekommen. D.h. wenn du direkt reinschreibst, dass du eine Antwort brauchst, oder dass du eine Bestätigung erwartest, dann wirst du die Antwort um den Faktor 2-3 schneller bekommen – im Folgenden einige Beispiele:

#Statt: „Protokoll der Logistik-Sitzung von KW34“

#Besser: „Protokoll der Logistik-Sitzung von KW34 – bitte Kommentare und Korrekturen bis 01. Sep. 2017 melden“

---

#Statt: „Hier der neue Support-Plan für den Standort Lüdenscheid“

#Besser: „Zur Info: Hier der neue Support-Plan für den Standort Lüdenscheid“

---

#Statt: „Die aktualisierte To-Do-Liste liegt auf dem Projektserver“

#Besser: „Die aktualisierte To-Do-Liste liegt auf dem Projektserver – neue offene Punkte direkt in diese Liste erfassen“

---

#Statt: „Bestellung 4500023231 vom 23.09.2017“

#Besser: „Bestellung 4500023231 vom 23.09.2017 – bitte Nachrichtenfindung im Beleg kontrollieren.“

---

#Statt: „Fehlerhafte Aufträge von Kunden Wortmann“

#Besser: „Fehler in den Wortmann-Aufträgen analysieren und Ursache an den Vertrieb melden“

 

Wie immer wäre es super, wenn ihr ein kleines Feedback hinterlassen könntet, Isa.

Leider hatte ich bis jetzt nicht die Gelegenheit in einem Projekt mitzuwirken, in dem die neue SAP HANA Datenbank zum Einsatz kam – was noch nicht ist, kann ja noch werden. Aber durch Fachbeiträge und eine Vertriebspräsentation der SAP konnte ich einiges zum Thema erfahren. Vor allem während der Präsentation sind mir 2 Punkte hängen geblieben, die kennzeichnend für die SAP HANA DB sind:

#1 SAP HANA basiert auf In-Memory-Technologie
#2 HANA verwaltet / speichert die Daten spaltenbasiert

Der Vorteil des ersten Punktes ist schnell erklärt: Seit dem ich meinen ersten Computer mit 12 Jahren bekommen hatte (Commodore 64) konnte ich am eigenen Leib erfahren, dass der Arbeitsspeicher eines Rechners viel schneller arbeitet, als die Festplatte – damals die ratternde Datasette. Und genau diesen Geschwindigkeitsvorteil nutzt die SAP HANA DB und hält die Daten nicht mehr auf der Festplatte, sondern alle Daten liegen direkt im Arbeitsspeicher – BIG SPEEDY BRAIN! Damit ist HANA in Bezug auf Geschwindigkeit unschlagbar verglichen mit konventionellen DBs, die die Daten auf der Festplatte speichern. Aber dieser Vorteil wird mit höheren Kosten erkauft, denn auch dies ist Allgemeinwissen: Arbeitsspeicher ist teuer als Festplattenspeicher.

Das zweite Charakteristikum der SAP HANA DB ist, dass die Daten spaltenorientiert verwaltet bzw. gespeichert werden. „… Und was bedeutet das?“ Während des Vertriebsvortrags durch die SAP-Mitarbeiter stellte ich genau diese Frage, doch ich bekam damals keine zufriedenstellende Antwort. Also habe ich zu diesem Thema etwas recherchiert und die Antworten, die ich fand und im Folgenden mit euch teilen will, waren wirklich interessant.

# Was bedeutet spaltenorientiert Datenverwaltung / -speicherung?

Im oberen Bild ist eine kleine Tabelle mit 5 Autos dargestellt, die anhand 6 unterschiedlicher Kriterien beschrieben sind:

# Nr.
# Hersteller
# Modell
# Leistung in PS
# Verbrauch
# Einheit Verbrauch

Normalerweise, also bei der zeilenorientierten DB, wird die Tabelle wie folgt gespeichert:

1,Audi,A3, 140,6.7,l/100km;
2,Audi,A4, 140,6.9,l/100km;
3,VW,Polo,90,5.5,l/100km;
4,VW,Golf,110,5.7,l/100km;
5,Mazda,CX-3,110,7.2,l/100km;

Wenn man sich vorstellt, wie die Daten tatsächlich physisch gespeichert werden, sieht es ungefähr so aus:

1,Audi,A3,140,6.7,l/100km;2,Audi,A4,140,6.9,l/100km;3,VW,Polo,90,5.5,l/100km;4,VW,Golf,110,5.7,l/100km;5,Mazda,CX-3,110,7.2,l/100km;

Wenn die Daten aber – wie bei der SAP HANA DB – spaltenorientiert gespeichert werden, sieht das so aus, d.h. jeder Satz ist ein Spalte, Spalte-Nr., Spalte-Hersteller, …:

1,2,3,4,5;
Audi,Audi,VW,VW,Mazda;
A3,A4,Polo,Golf,CX-3;
140,140,90,110,110
6.7,6.9,5.4,5.7,7.2;
l/100km, l/100km, l/100km, l/100km, l/100km;

Vor- und Nachteile einer Spaltenorientierten DB

Das spaltenorientierte Speichern und Verwalten von Daten sieht zunächst gewöhnungsbedürftig aus, hat aber auch seine Vorteile. Im Folgenden will ich anhand von drei Fragenstellungen die Vorzüge der SAP HANA DB darstellen:

Wie viel VW-Fahrzeuge sind in der Liste?
Bei der zeilenorientierten DB müsste mal alle Zeilen auslesen und hieraus selektieren, welche Sätze Hersteller = VW sind; d.h. man muss zwingend alle Sätze durchgehen. Im Gegensatz dazu würde HANA „nur“ in den einen Satz für die Hersteller-Spalte schauen und die VW-Fahrzeuge aus diesem einen Satz ermitteln, d.h. statt 5 Zugriffe ein einziger Zugriff.

Wie viele Autos gibt es mit über 120 PS?
Auch hier müsste man nur in den Satz für „Leistung in PS“ schauen, und die Anzahl der Werte mit größer 120 ermitteln.

Wie viel verbrauchen die Fahrzeuge im Schnitt?
Wieder müsste man nur den Satz für die Spalte „Verbrauch“ lesen und den Mittelwert ermitteln. Im Gegensatz dazu müssten bei einer konventionellen DB alle Sätze gelesen werden.

Also wenn es um Analyse von Daten geht, ist HANA durch das Design unschlagbar gegenüber konventioneller DBs. Natürlich hat das HANA-Design nicht nur Vorteile. Stell dir vor, du willst in die Tabelle ein neues Fahrzeug aufnehmen. Dann muss jeder Satz aktualisiert werden, d.h. der Satz für die erste Spalte, die zweite Spalte, die dritte Spalte … muss aktualisiert werden. Auch bei Änderung oder Anzeige eines Fahrzeugs müssten, statt eines Satz, viele sogar alle Sätze gelesen werden.

So bis jetzt kann man also fest halten:

# Wenn Daten analysiert werden sollen, dann ist HANA durch das zusammenhängende Speichern von Kennzahlen (Spalten) in einem Satz unschlagbar schnell.

# Doch wenn Daten erfasst, geändert und angezeigt werden sollen, ist HANA nicht die optimale Lösung, da hier unter Umständen auf unterschiedliche Sätze zugegriffen werden muss.

Doch das spaltenbasierte Design der SAP HANA DB bietet einen zusätzlichen Vorteil, der Im-Memory-Technologie in die Hände spielt. Wenn man sich die Fahrzeugdaten in der HANA-Version nochmal genauer anschaut, fällt vor allem in der letzten Zeile, die Spalte, die „Einheit Verbrauch“ darstellt, etwas Wichtiges auf:

1,2,3,4,5;
Audi,Audi,VW,VW,Mazda;
A3,A4,Polo,Golf,CX-3;
140,140,90,110,110
6.7,6.9,5.4,5.7,7.2;
l/100km, l/100km, l/100km, l/100km, l/100km;

Habt ihr erkannt, was auffällig ist? Ja genau, die Werte wiederholen sich. Diesen Umstand nutzt HANA, um die Daten zu komprimieren, d.h. sich wiederholende Werte innerhalb eines Satzes werden einfach zusammengefasst. Das sieht dann etwa so aus:

1,2,3,4,5;
2:Audi,2:VW,Mazda;
A3,A4,Polo,Golf,CX-3;
2:140,90,2:110
6.7,6.9,5.4,5.7,7.2;
5:l/100km;

Die Komprimierung ist in Grunde sehr einfach: Wenn sich innerhalb einer Zeile ein Wert wiederholt, wird die Anzahl der Wiederholungen mit einem Doppelpunkt vor dem Wert dargestellt. Damit sind alle Daten immer noch verfügbar, aber der Speicherbedarf der DB ist viel kleiner. Hier habe ich mal von einem Faktor von 4-10 gelesen, den die Komprimierung einspart. D.h. für die In-Memory-Technologie von SAP HANA werden bspw. statt 10 TB nur 1 – 2,5 TB benötigt. Und das ist ein zusätzlicher Boost für die In-Memory-Technologie bezogen auf den Preis und die Geschwindigkeit.

Hoffe, ich konnte euch essentielle Aspekte der SAP HANA DB nahe bringen … wie immer wäre es toll, wenn du ein kleines Feedback hinterlassen könntest, Isa.

 

Der SD-Auftragsart ist für User wesentlich, wenn ein Auftrag im SAP ERP System angelegt werden soll. Normalerweise wird eine SD-Auftrag mit dem Transaktionscode VA01 angelegt, und das erste was das System innerhalb dieser Transaktion erwartet ist die Auftragsart. Hier muss der User entscheiden, ob ein normaler Terminauftrag (TA), ein Retourenauftrag (RE), eine Gutschrift (G2) oder eine Lastschrift (L2) angelegt werden soll. Mit Eingabe der Auftragsart wird bei der Auftragserfassung eine Reihe von Funktionen gesteuert, die je Auftragsart unterschiedlich sein können.

Im Folgenden habe ich 12 Punkte aufgeführt, die von der Auftragsart gesteuert werden. Natürlich sind das nicht alle Aspekte, die die Auftragsart beinhaltet, aber nach meiner Erfahrung sind diese Punkte, die Features der Auftragsart, die am meisten zum Einsatz kommen.

#1 Nummernkreis

Jeder Auftrag hat eine konkrete Nummer – bspw. 20003090. Diese Nummer wird beim Anlegen des Auftrags generiert und kann aus bis zu 10 alphanumerischen Zeichen besteht. Pro Auftragsart wird festgelegt, in welchem Nummernkreis die zu vergebende Nummer liegen soll. Bspw. können Terminaufträge im Nummernkreis 20000000 – 29999999 liegen und Retouren Aufträge im Nummernkreis 600000 – 699999.

#2 Sofortbelieferung

80% der Aufträge innerhalb des Vertriebsmoduls werden als Terminaufträge (TA) angelegt. Ein Terminauftrag zeichnet sich dadurch aus, dass basierend auf der Verfügbarkeit der Ware oder dem Wunsch des Kunden, der Liefertermin in der Zukunft liegt. Damit wird die Lieferung zum Auftrag erst dann angelegt, wenn das Liefererstellungsdatum erreicht wurde. Es gibt aber auch Prozesse (bspw. Tresengeschäfte), bei denen die Terminierung keine Rolle spielt und der Kunde die Ware sofort mitnehmen will. Hier ist es sinnvoll, dass die Lieferung zum Auftrag direkt erzeugt wird, damit die Ware sofort kommissioniert und an den Kunden übergeben werden kann. Für diese Arten von Aufträgen kann eingestellt werden, dass eine Sofortbelieferung erfolgen soll, d.h. mit dem Sichern des Auftrags wird sofort die Lieferung generiert.

#3 Bildaufbau / -folge

Prinzipiell sehen SD-Aufträge in ihrem Aufbau und der Struktur relativ identisch aus; doch im Detail kann pro Auftragsart ein unterschiedlicher Bildaufbau ausgesteuert werden. Bspw. haben Terminaufträge (TA) pro Position den Reiter „Einteilungen“, in dem die Terminierungsdaten dargestellt sind. Dieser Reiter ist für Lastschriftaufträge (L2) nicht vorgesehen, da bei diesen Aufträgen keine Warenbewegung und damit Terminierung vorgesehen ist.

#4 Unvollständigkeit

Auch das Thema Unvollständigkeitsprüfung für Kopfdaten wird pro Auftragsart ausgesteuert. Hier kann pro Auftragsart eingestellt werden, welche Felder im Unvollständigkeitsschema zu prüfen sind.

#5 Versandbedingung

Die Versandbedingung steuert im Auftrag unter anderem die Versandstellenfindung und Routenfindung. Pro Auftragsart kann eine Versandbedingung zugeordnet werden, die bei der Auftragsanlage als Vorschlagswert im Auftragskopf steht. Dieser Vorschlagswert kann durch den User überschrieben werden.

#6 Kalkulationsschema

Die Auftragsart steuert auch maßgeblich die Preisfindung des Auftrags. Konkret wird über die Auftragsart das Kalkulationsschema ermittelt, die die Details der Preisfindung vorgibt.

#7 Terminierung

Im Customizing kann pro Auftragsart eingestellt werden, ob für eine bestimmte Auftragsart die Versandterminierung aktiviert ist oder nicht. Weiterhin kann an dieser Stelle auch separat ausgesteuert werden, ob eine Transportterminierung durchgeführt werden soll.

#8 Nachrichtenschema

Über die Auftragsart wird auch die Ermittlung des Nachrichtenschemas gesteuert. Somit können unterschiedlichen Aufträgen verschiedene mögliche Nachrichten zugeordnet werden.

#9 Materialsubstitution

Die Materialsubstitution kann genutzt werden, wenn Material, die bei der Auftragserfassung eingegeben werden, durch ein anderes Material ersetzt werden sollen. Sinnvoll ist diese Funktion bspw. beim Abverkauf von Saisonware. Die Materialersetzung wird auch pro Auftragsart eingestellt.

#10 Produktvorschlag

Mit der Funktion Produktvorschlag erhält der User bei der Auftragserfassung eine Liste von Materialien vorgeschlagen, die für diesen Auftrag relevant sein könnten – nach dem Motto: „Auch diese Produkte könnten Sie interessieren.“ Diese Funktion wird unter anderem auch pro Auftragsart aktiviert.

#11 Kreditlimitprüfung

Per Kreditlimit kann bei der Auftragserfassung gesteuert werden, ob ein Auftrag wegen Kreditlimitprüfung (hat der Kunde schon wieder die letzte Rechnung nicht gezahlt?) gesperrt wird oder nicht. Auch diese Prüfung kann pro Auftragsart eingestellt werden.

#12 Kopiersteuerung

Last but not least, wird über die Auftragsart die komplette Kopiersteuerung der SAP-SD-Belegkette (Auftrag-Lieferung-Faktura) gesteuert. Die Kopiersteuerung legt fest, aus welchen Auftragsarten welche Lieferarten generiert werden können, oder ob basierend auf einem Auftrag eine Faktura erstellt werden kann.

 

Wäre super, wenn du ein kleines Feedback hinterlassen würdest, Isa.

 

Was hat SAP mit einem Big Mac gemeinsam? Auf den ersten Blick Nichts – weder kann man SAP essen, noch hat ein Big Mac irgendwas mit IT zu tun. Doch haben sie einen wichtigen Punkt gemeinsam: Für beide sind die 3 Schichten entscheidend. Ein Big Mac besteht immer aus 3 Schichten Burgerbrot und für SAP sind die 3 Schichten GUI, ABAP und DB entscheidend und essentiell.

Der SAP-GUI

Für den SAP-User ist die entscheidende Interaktion mit dem SAP-System der SAP-GUI. Hier kann man sich den Kundenstamm (VD03), eine Lieferung (VL03N) oder eine Rechnung (VF03) anzeigen lassen. Als SAP-Berater sollte man sich im SAP-GUI „wie im Schlaf“ innerhalb der einzelnen Transaktionen auskennen.
Den Aufbau des SAP-GUI kann man als Berater oder User kaum beeinflussen. Dieser Umstand klingt zunächst – in Zeiten des Personalisierungs-Hypes – etwas suspekt, hat aber den enormen Vorteil, dass die Auftragsanlage oder die Debitorenpflege in jedem Unternehmen auf der ganzen Welt identisch ist. D.h. sowohl der User als auch der Berater wird sich in jedem Unternehmen, das SAP nutzt, ohne viel Einarbeitung zu Recht finden.

ABAP

Die Verarbeitung der Daten, die im SAP-GUI oder auf anderem Wege erfasst werden, erfolgt über die Programmiersprache des SAP-Systems: ABAP. Natürlich muss man als SAP-Berater kein Entwickler sein. Aber trotzdem sollte es auch für einen SAP-Berater kein Hexenwerk sein ABAP-Code zu lesen, Programme zu debuggen oder einzelne Programmstellen wiederzufinden und zu analysieren. Also folgende Transaktionen und deren Bedienung dürfen keine böhmischen Dörfer sein: SE38, SA38, SE80, SE24, SE37

Datenbank

Die letzte Ebene des SAP-Systems bildet die Datenbank. Hier werden alle Daten ablegt, die bei der Erfassung anfallen oder benötigt werden. Diese können sowohl Bewegungs-, Vorgangs-, Stamm- oder Steuerdaten sein. Der Aufruf von einzelnen Tabellen, die Anzeige und Analyse der Daten sollte zum Know-How-Repertoire jedes Beraters gehören. Damit solltest du die Transaktionen SE16, SE16N und SE11 im Schlaf beherrschen und gängige Tabelle aus dem Bereich, in dem du arbeitest, auswendig kennen.

Hier ein kleines Beispiel, wie die 3 Ebene zusammenarbeiten: Du willst einen Kundenauftrag anlegen und startest die Transaktion VA01

 

# Mit dem Aufruf der Transaktion landest du in einer überschaubaren Eingabemaske, wo du die Auftragsart und weitere Daten erfassen kannst: Das ist ein kleiner Teil des SAP-GUI; auf dieser Ebene interagiert der User mit dem System.

# Zum Transaktionscode VA01 ist das ABAP-Programm SAPMV45A zugeordnet, dessen Code mal sich per SE38 anzeigen lassen kann. Dieses Programm wird gestartet, sobald man die VA01 aufgerufen wird –> das ist der Link zu ABAP.

# Wenn man nun in der Erfassungsmaske eine Auftragsart eingibt, prüft das System gegen die Liste der vorgesehenen Auftragsarten. Diese Auftragsarten sind in der Datenbank-Tabelle TVAK abgelegt, dessen Inhalte man sich per SE16 anzeigen lassen kann –> das ist der Link zur Datenbank-Ebene.

 

Wäre toll, wenn du einen kleinen Kommentar hinterlassen würdest, Isa.

 

 

Es war gegen Ende der 90er Jahre– ich stand kurz vor dem Abschluss des Studiums und besuchte eine Absolventen Messe. Mein Ziel war es, ein paar Kontakte zu knüpfen und mich umzuschauen, bei welchen Unternehmen ich mich als Maschinenbauer bewerben könnte. In einer Studentenzeitschrift hatte ich gelesen, dass Unternehmensberatungen immer ein guter Start ins Berufsleben waren. So gab ich meinen Lebenslauf unter anderem auch bei diesen Firmen ab. Nach ein paar Wochen erhielt ich einen Anruf von PwC. Sie sagten mir, dass sie an meinem Profil interessiert seien, und wir führten ein Telefoninterview durch, an dessen Ende ich zu einem 2 wöchigen Assessment Center eingeladen wurde. Letztlich ging die Geschichte so aus, dass ich bei PwC unterschrieb.

An meinem ersten Arbeitstag fragte mich mein Boss, ob ich SAP machen wolle. SAP sagte mir damals rein gar nichts, also fragte ich einen Kollegen. Er sagte mir sofort, „Mach SAP, ist `ne Lebensversicherung.“ Also sagte ich meinem Boss zu und machte SAP – seit dem bin ich SAP-Berater. Auch wenn ich anfangs mit SAP haderte, bin ich mittlerweile ein begeisterter SAP-Berater, der über die Jahre viel gelernt hat.

Im Folgenden habe ich 20 Punkte zusammengestellt, warum du auch als SAP-Berater arbeiten solltest.

#01 Du arbeitest mit und für Menschen

Auch wenn SAP-Beratung viel mit Informatik, Programmierung und Technologie zu tun hat, solltest du nie vergessen, dass der zentrale Faktor der Mensch ist. Der Mensch stellt die Anforderungen und diese User werden zukünftig mit den Prozessen arbeiten, die du abstimmst, gestaltest und realisierst.

#02 Niemand wird je so viel und detailliert unterschiedlichste Unternehmen kennen lernen wie du

Ich bin immer wieder überrascht, wie viele Details ich zu einem Unternehmen während eines Projektes erfahre. Zu Ende eines Projektes weiß ich meistens sehr genau wie ein Auftrag abgewickelt wird, wie eine Retoure erfasst und von wem freigegeben wird oder wie, warum ein bestimmter Preis kalkuliert ist.

#03 Du wirst jeden Tag immer besser in deinen Analyse-Skills

Analyse bedeutet für mich im Detail verstehen. Analyse ist einen Sachverhalt aus verschiedenen Perspektiven auseinander zu nehmen und die relevanten Punkte und deren Zusammenspiel zu erfassen. Dabei kann dies sowohl Programmcode als auch ein abteilungsübergreifender Prozess sein. Und genau dies wirst und musst du als SAP-Berater immer wieder durchführen müssen; und vor allem wirst du dabei immer besser werden.

#04 Ich liebe es – ein Stück weißes Blattpapier zu nehmen und von Null auf ein Konzept zu erstellen

Ein schriftliches Konzept fasst im Grunde einfach alle Ergebnisse aus der Anforderungsanalyse und erarbeiteten Lösungs- bzw. Umsetzungswegen stimmig zusammen. Damit sollte es ein Kochbuch sein, wie der weitere Verlauf des Projektes aussehen wird. Wenn du auch – wie ich – ein begeisterter Konzeptersteller bist, dann hast du als SAP-Berater genau den richtigen Job.

#05 BoreOut wird dich höchstwahrscheinlich nicht treffen

Langeweile wird als SAP-Berater definitiv nicht aufkommen; meine Erfahrung ist, dass man mindestens eine 70 Stunde-Woche an unterschiedlichste Themen arbeiten kann. Dabei kann die Palette der Tätigkeiten zwischen Präsentation von Ergebnissen vor der Geschäftsführung bis zur Analyse von Fehlern im Debugger variieren. Bore-Out sollte für dich kein Thema sein.

#06 Du bist entweder Stürmer, Torwart oder in der Abwehr – aber du bist immer Teil von Elf.

Teamwork ist das A und O eines SAP-Beraters. Wenn du nicht der einsame Tüftler bist, der in seinem Elfenbeinturm die ausgefeiltesten Ideen entwickelt, sondern in einem Team von mehreren zehn oder hundert Personen aufblühst, dann bist du genau richtig in der SAP-Beratung.

#07 Auch wenn du nicht Michelangelo bist, Kreativität gehört zu deinem täglichen Brot

Wie oft habe ich folgende Szene als SAP-Berater erlebt: Du steht vor einem Problem, dass evtl. das komplette Projekt gefährdet und trotz intensiver Recherche oder Brainstorming lässt sich keine Lösung finden. In solchen Situation ist Kreativität gefragt; hier haben immer die Leute die Nase vorne, die um die Ecke denken (können) und den entscheidenden Hinweis liefern, um die Situation zu retten.

#08 Bewerbungsgespräche meistern

Wenn du mehr Erfahrungen mit Bewerbungsgesprächen machen willst und hier mehr Sicherheit erlangen willst, dann solltest du unbedingt SAP-Berater werden. Im Schnitt wechselt man alle ein bis zwei Jahre das Projekt und für jedes Projekt muss man sich erneut bewerben; gezwungener Maßen wird man mit der Zeit zum Meister für Bewerbungsgespräche, d.h. man weiß genau, wie man sich verkauft.

#09 Keines deiner Tage wird so sein, wie der andere!

Es muss nicht unbedingt von Vorteil sein, aber du kannst davon ausgehen, dass keines deiner Tage und keines deiner Projekte, wie das andere sein wird. Für SAP-Berater ist Abwechslung das Programm.

#10 Englisch ist Pflicht, aber auch Französisch und Spanisch sollten drin sein.

Wenn du dich fragen solltest, warum du Jahre lang Englisch, Französisch oder Spanisch in der Schule gelernt hast, dann wirst du diese Frage als SAP-Berater schnell beantworten können. Denn gerade in Projekten bei multinationalen Konzernen, wirst du deine Sprachkenntnisse endlich einsetzen können.

#11 Glaub mir, du wirst viele, sehr viele Leute kennenlernen.

Wenn du viele, unterschiedliche und interessante Menschen kennenlernen und peu-a-peu dein Netzwerk erweitern willst, dann solltest du unbedingt SAP-Berater werden.

#12 Faible für Zahlen? Dann bist du hier genau richtig.

Kennzahlen, Kennzahlen, Kennzahlen … dieses Stichwort zieht sich wie ein roter Faden durch die Tätigkeit eines SAP-Berater. Wenn du ein entsprechendes Faible für Zahlen hast, wirst du dich hier richtig schön austoben können.

#13 Du wirst schon merken, dass Kommunikation alles ist.

Wenn man mich fragen würde, was das die wichtigste Fähigkeit eine SAP-Berater ist, dann würde ich ohne zu zögern sagen: Kommunikation. Als SAP-Berater steht man immer zwischen verschiedenen Interessengruppen und muss sich mit unterschiedlichen Menschen auseinandersetzen. Und dabei ist Kommunikation essentiell. Also wenn du ein kommunikativer Typ bist, dann sollte dich nichts davon abhalten, dich als SAP-Berater zu bewerben. Du solltest aber Kommunikation nicht mit viel Quatschen verwechseln. Gute Kommunikation besteht aus 70 % Zuhören, 20 % die richtigen Fragen stellen und 10% dem Rest.

#14 Jeder Vertriebler wird dich beneiden

Wie viel Kundenkontakt wünscht sich ein Vertriebler? Wahrscheinlich würde ein Vertriebler gerne tagtäglich beim Kunden sitzen; und genau deswegen werden SAP-Berater so sehr von den Vertrieblern beneidet. Als SAP-Berater wirst du einen sehr intensiven Kundenkontakt haben – und das ist gut so.

#15 Du wirst nicht mit einem kleinen Obolus nach Hause gehen

Wenn du in der IT arbeiten und ein ordentliches Gehalt bekommen willst, dann bist du als SAP-Berater richtig positioniert. Gerade heute gab es in der Computerwoche einen Bericht, dass SAP-Berater in der IT die höchsten Gehälter erhalten.

#16 Spanier halten sich tatsächlich an ihre Siesta

Ein besonders interessanter Aspekt der Tätigkeit als SAP-Berater finde ich, dass man unterschiedliche Kulturen kennenlernt. Vielfach erfüllen Italiener, Spanier oder Japaner tatsächlich die Stereotypen, die man sich vorstellt. Aber noch öfter lernt man ganz neue Facetten kennen und denkt sich immer wieder: Wow, ja so kann man es auch machen.

#17 Barcelona, New York, Singapur …

Reist du gerne und lernst neue Städte und Länder kennen? Europa- bzw. weltweite Projekteinsätze für SAP-Berater sind keine Seltenheit. Gerade bei größeren Projekten ist Mobilität für SAP-Berater groß geschrieben.

#18 Ich bestimme, was ich heute mache

Selbstbestimmtes Arbeiten und den Arbeitstag eigenständig zu gestalten ist ein großer Vorteil für SAP-Berater. Auch wenn der große Rahmen durch den Projektplan gesteckt ist, hat man als SAP-Berater doch sehr große Freiräume in der eigenen Arbeitsplanung; nutze und genieße sie!

#19 Ein Gewerbeschein ist schnell angemeldet …

Ob mit Gewerbe oder als Freiberufler, für SAP-Berater sind die Hürden in die Selbstständigkeit ziemlich niedrig. Vor allem wird dieser Umstand durch folgende zwei Faktoren begünstigt: Es sind keinerlei Investitionen nötig und die Nachfrage nach guten Beratern ist seit Jahren höher als das Angebot auf dem Markt.

#20 hrs.de oder booking.com würden dich sofort mit Kusshand einstellen

Ob das nun ein Segen oder ein Fluch ist, muss jeder für sich bewerten; aber als SAP-Berater wirst du häufig unterwegs sein und dabei viele Hotels kennenlernen. Ich habe mich schon oft gefragt, ob ich nicht mal einen Hotelführer schreiben sollte.

 

*Wäre toll, wenn Du ein kurzes Feedback hinterlassen könntest, Isa.