Autor: Isa

Schon mal ins kalte Wasser geworfen worden? Bestimmt … ich bin auf jeden Fall mehrmals ins kalte Wasser geworfen worden. Gerade als Junior SAP-Berater wird immer wieder in Projekte gesteckt, in denen man entweder sich schnell freischwimmt oder untergeht. Man fühlt sich überfordert und denkt „… wie soll das funktionieren, wie soll ich mich hier unter den vielen alten Hasen jemals etablieren …“ – doch keine Sorgen: Meist klappt es sehr gut. So ein „ins kalte Wasser geschmissen werden“ hatte ich zuletzt 2005 erlebt. Ich fing in einem Projekt zum LES-Transportmanagement mit intensiver IDoc-Anbindung an. Doch ich hatte bis dato nie etwas mit IDocs zu tun gehabt. In dieser Situation war ein Tipp eines erfahrenen Kollegen Goldwert – er sagte mir einfach: „Schau dir die WEDI an!“

WEDI ist das Bereichsmenü der SAP für IDocs und EDI und kann einfach durch Eingabe von WEDI in Transaktionsleiste gestartet werden – wichtig: Vor Eingabe eines Bereichsmenüs, musst du dich im Startmenü des SAP-Systems befinden … et voila – alle wichtigen IDOC-Transaktionen werden dir in einem strukturierten Menü dargestellt:

 

Oder du willst dir mal anschauen was SAP zum Thema Bestandsführung bietet, dann starte einfach das Bereichsmenü MB00 – Bestandsführung:

 

Überblick SAP-Bereichsmenüs

Im folgenden habe ich mal eine Reihe von Bereichsmenüs aufgelistet, um einen Eindruck zu geben:

BM00 – Chargenverwaltung

C000 – Controlling Informationssystem

CC00 – Änderungsdienst

CF00 – Fertigungshilfsmittel

CK00 – Produktkostenplanung

CL00 – Klassensystem

CO00 – Fertigungssteuerung

CS00 – Stücklisten

CU00 – Variantenkonfiguration

F000 – Buchhaltung Informationssystem

HR00 – Personal

MB00 – Bestandsführung

MD00 – Bedarfsplanung Fremdbeschaffung

ME00 – Einkauf

MM00 – Materialstamm

MR00 – Rechnung

PA00 – Personaladministration

PB00 – Personalbeschaffung

PS00 – Projektsystem

S001 – ABAP Workbench

TV00 – Reisemanagement

VA00 – Verkauf

VF00 – Fakturierung

VL00 – Versand

VS00 – Stammdaten Vertrieb

VT00 – Transport

VX00 – Außenhandel / Zoll

 

Das SAP ERP-System bietet weit über tausende Bereichsmenüs. Einen Überblick aller Bereichsmenüs kann man sich einfach mit der Transaktion SE43N verschaffen:

# Transaktion SE43N aufrufen

# Im Feld „Bereichsmenü“ auf die Wertehilfe klicken (F4)

# Feld „Maximale Trefferanzahl“ löschen und Enter

# Jetzt werden dir alle Bereichsmenüs dargestellt, die verfügbar sind

# Die Liste kannst du dir auch einfach in Excel ziehen: Klicken auf die Spaltenüberschriften, um alle Einträge zu markieren, alles per STRG+C kopieren und anschließend einfach in Excel einfügen.

 

Übrigens mit der SE43N kann man auch eigene Bereichsmenüs anlegen … probier’s einfach mal – ist wirklich sehr einfach.

 

SAP-Bereichsmenüs per Tabellen suchen und ermitteln

Bereichsmenüs sind auf DB-Tabellenebene in folgenden 3 Tabellen abgelegt:

#1 TMENU01 – hier sind alles Knoten zu den Bereichsmenüs abgelegt; das Feld TREE_ID enthält die Bereichsmenü Transaktion

#2 TMENU01R – hier sind die Details zu den einzelnen Knoten aus der ersten Tabelle enthalten; vor allem findet man hier im Feld REF_OBJECT (REF_TYPE = TCOD) die zum Bereichsmenü zugeordneten Transaktionen

#3 TMENU01T – in dieser Tabelle sind die Text zu den einzelnen Knoten der Bereichsmenüs abgelegt

 

Diese Tabellen sind alle miteinander über das Feld (Fremdschlüsse) NODE_ID verbunden:

#1 TMENU01

## TMENU01-NODE_ID = TMENU01R-NODE_ID

#2 TMENU01R

## TMENU01R-NODE_ID = TMENU01T-NODE_ID

#3 TMENU01T

 

Mal über den Tellerrand schauen …

Mit den Tabellenzusammenhängen kann man nun einfach nachschauen, in welchen Bereichsmenüs eine Transaktionen zugeordnet ist und so ermitteln, welche anderen Transaktionen SAP in diesem Themenbereich anordnet.

Bspw. willst du dir Materialbestände anschauen und kennst die Transaktion MMBE. Basierend auf der MMBE kannst du dir alle Bereichsmenüs ermitteln, in denen diese Transaktion vorkommt. Jetzt kannst du diese Bereichsmenüs durchschauen und dir einen Überblick verschaffen, welche weiteren Transaktionen zum Thema Bestandabfrage vorgesehen sind. Im Detail würde das für die MMBE wie folgt funktionieren:

# Per SE16H die Tabelle TMENU01R aufrufen

# Im Selektionsfeld Ref.Objekt (REF_OBJECT) „MMBE“ eingeben und ausführen (F8)

# Alle Einträge aus der Spalte Unique-ID (NODE_ID) kopieren

# Im neuen Modus per SE16H die Tabelle TMENU01 aufrufen

# Die vorher kopierten Einträgen in den Selektionsfeld NODE_ID eingeben (Mehrfach Selektion)

# Im Selektionsscreen nur für das Feld TREE_ID die Anzeige und die Gruppierung aktivieren und ausführen (F8)

# Jetzt werden alle Bereichsmenüs aufgelistet, in denen die Transaktion MMBE vorkommt

 

Hoffe, ich konnte euch einen Einblick in SAP-Bereichsmenüs geben. Wie immer wäre es toll, wenn ihr ein Feedback hinterlässt, Isa.

Ich bin SAP-Berater. Meine Aufgabe ist es, Anforderungen aufzunehmen, Prozesse zu analysieren, das Customizing durchzuführen. Und letztlich muss man auch Prozesse monitoren, auftretende Fehler analysieren und beheben. Mit ABAP-Entwicklung und der SAP-Basis kenne ich mich nicht aus.

Doch nichtsdestotrotz ist es auch für SAP-Berater sinnvoll, wenn man sich in Entwicklungs- und Basis-Themen auskennt. Vorallem während der Testphase und bei der Fehleranalyse ist es hilfreich, in diesen Bereichen bewandert zu sein.

Im Folgenden habe ich eine Liste von Systemtransaktionen (S-Transaktionen) zusammengestellt, die sich über die Jahre angesammelt haben. Hoffe, dass die Liste dem einen oder anderen weiterhilft .

 

Allgemeine Informationen ermitteln

SB01 – Anwendungskomponenten

Darstellung aller SAP-ERP Module und der Modul-Komponenten

SCDO – Anzeige Änderungsbelegobjekte

Liste der Änderungsbelegobjekte; hilfreich bei der Analyse per CDHDR

SCMP – View/Tabellen-Vergleich

Systemübergreifender Tabelleninhaltsvergleich; RFC-Verbindung nötig

SM02 – System-Nachrichten

System-Nachricht bei der Anmeldung zu schnell weggedrückt; mit SM02 kann sie wieder nachlesen.

 

Transaktionen zur Systemanalyse

SAT – ABAP Trace

Laufzeit einer bestimmten Transaktion / Programm für einen bestimmten User messen.

ST01 – System-Trace

System-Trace aktivieren

ST03 – Systemlast u. Perform. Statistik

Statistik zur Systemlast (RFC, ALE, Dialog, …)

ST04 – DB-Performance-Monitor

Lastanalyse der Datenbank

ST06 – Operating System Monitor

Lastanalyse der CPUs

ST10 – Statistik zum Tabellenaufruf

Diese Analyse beantwortet die Frage, wie oft wurde, welche Tabelle aufgerufen.

ST22 – ABAP Dumpanalyse

Programmabbruch, Kurzdump: Was ist passiert.

ST22L – ABAP Dumpanalyse

Wenn sogar die ST22 nicht mehr aufrufbar ist: Abgespeckte Version zur ST22

STAD – Systemübergreif. Statistiksatzanzeig

Unter anderem kann man hier sehen, wie oft welche Tranaktion aufgerufen wurde.

 

Monitoring-Transaktionen

SLG1 – Anwendungs-Log: Protokolle anzeigen

Hier werden Fehler/Warnmeldungen protokolliert, die während der Anwendung auftraten.

SM04 – Benutzerliste

Welche User sind aktuell auf dem System angemeldet und welche Transaktion nutzen sie.

SM12 – Sperren anzeigen und löschen

Welche Sperreinträge sind aktuell von wem auf was gesetzt; hier können Sperren auch gelöscht werden – aber bitte vorsicht.

SM13 – Verbuchungssätze administrieren

Wenn Verbuchungen abgebrochen wurden, kann man hier nachschauen, was der Fehler war und evtl. nachverbuchen.

SM20 – Auswertung des Security Auditlog

Mit dieser Transaktion können Security Auditlog analysiert werden.

SM21 – Systemprotokoll

Welche Systemlog wurden geschrieben, und welche Fehler sind auftreten.

SM50 – Workprozess-Übersicht

Welche Prozesse laufen auf dem aktuellen Server, und wieviele Workporzesse sind frei – um alle Server zu sehen auf das dritteIcon von links klicken.

SM51 – Server-Liste

Liste der verfügbaren Server; durch Doppelklick auf einen Server kommt man in die Workprozess-Übersicht (SM50) zu diesem Server.

SMQ1 – qRFC-Monitor (Ausgangsqueue)

Übersicht der RFC-Ausgangsqueue

SMQ2 – qRFC-Monitor (Eingangsqueue)

Übersicht der RFC-Eingangsqueue

SOST – SAPconnect Sendeaufträge

Ist die Mail rausgegangen: Übersicht der Fax-, Mail-, etc. Sendeaufträge

 

Systemtransaktionen für DB-Tabellen

SCU3 – Tabellenhistorie

Zentrale Transaktion um sich die Änderungshistorie zu Tabellenwerten anzeigen zu lassen.

SE11 – ABAP Dictionary Pflege

Definition von Tabellen, Strukturen, Sperrobjekten, …

SE16 – Data Browser

Tabellenbrowser, um sich Inhalte der Tabellen anzeigen zulassen.

SE16N – Allgemeine Tabellenanzeige

Weiterentwicklung der SE16; übersichtlichere Selektion und Darstellung der Ergbnisse.

SE16H – Allgemeine Tabellenanzeige

Weiterentwicklung der SE16H; unteranderem bietet sie eine Gruppierungsfunktion vergleichbar zu Excel-Pivot-Tabellen.

SE17 – Allgemeine Tabellenanzeige

Einfacher Tabellenbrowser

SM30 – Aufruf View-Pflege

Mit dieser Transaktion können Tabellen gepflegt werden, sofern dies für die jeweilige Tabelle vorgesehen ist.

 

User-Verwaltung

SU01 – Benutzerpflege

Pflege von Benutzerdaten

SU01D – Benutzeranzeige

Anzeige von Benutzerdaten

SU1 – Eigene Benutzeradresse pflegen

Eigene Benutzeradresse pflegen

SU2 – Eigene Benutzerparameter pflegen

Eigene Benutzerparamater pflegen

SU3 – Benutzer eigene Daten pflegen

Eigene Benutzerdaten pflegen.

 

Entwicklungstransaktionen

SAAB – Aktivierbare Checkpoints

Mit dieser Transaktion können Checkpoint aktiviert werden, um das Anspringen von Breakpoints zu steuern – dient zur Programmanalyse.

SDBE – SQL-Anweisung erklären

Mit dieser Transaktion können SQL-Statement bezogen auf ihre Performance analysiert werden.

SE24 – Class Builder

Anzeige von Klassen / Methoden und deren Coding.

SE37 – ABAP Funktionsbausteine

Anzeige und Test von Funktionsbausteinen -> Testeingaben können gespeichert und später erneut verwendet werden.

SE38 – ABAP Editor

ABAP-Programm-Editor; man kann von hier aus auch das Programm starten.

SA38 – ABAP/4 Reporting

Im Gegensatz zur SE38 kann man sich mit dieser Transaktion das Coding nicht anzeigen/bearbeiten, aber das Programm starten.

SE39 – Split-Screen-Editor (neu)

Editor, um sich 2 Programm parallel im einem Split-Screen darzustellen bzw. zu bearbeiten (auch systemübergreifend)

SE71 – SAPscript Formular

SAPScript-Editor.

SE80 – Object Navigator

Zentrale Entwicklungsumgebung, womit man unterschiedliche Entwicklungsobjekte darstellen und bearbeiten kann.

SE91 – Nachrichtenpflege

Liste aller SAP-Nachrichten; sehr nützlich, um zu suchen an welcher Stelle eine Fehlermeldung aufgetreten ist (Verwendungsnachweis)

SMARTFORMS – SAP Smart Forms

SMARTFORMS-Formularentwicklung

SMOD – SAP-Erweiterungsverwaltung

Suche nach Kundenerweiterungen.

STYLE_GUIDE – Styleguide-Transaktion

Schöne Tipps und Tricks zum Transaktionsdesign (in Englisch).

 

Systemstransaktionen zum Transportwesen

SE01 – Transport Organizer (Erw. Sicht)

Erweiterte Transportsuche

SE03 – Transport Organizer Tools

Transportaufträge nach verschiedenen Kriterien suchen.

SE10 – Transport Organizer

Transporte zu einem User

STMS – Transport Management System

Gefährlich – mit dieser Transport findet der eigentliche Transportanstoss statt.

 

Systemtransaktion zur Transaktionsverwaltung

SM01 – Sperren Transaktionen

Mit der SM01 können Transaktionen ge- / entsperrt werden.

SE43N – Pflege der Bereichsmenüs

Pflege und Darstellung von Bereichsmenüs

SE93 – Pflege Transaktionscodes

Pflege und Suche von Transaktionen

 

Job-Transaktionen

SM36 – Batch-Anforderung

Job-Definition

SM37 – Übersicht über Jobauswahl

Job-Übersicht und -Analyse.

 

Transaktion zu Nummerkreisen

SNRO – Nummernkreisobjekte

Liste der Nummerkreisobjekte

SNUM – Nummernkreistreiber

Intervall und aktueller Stand der Nummernkreise

 

SAP-Büro Transaktionen

S00 – Kurznachricht

Kurznachrichten an einen anderen User senden.

SBWP – SAP Business Workplace

Persönlicher SAP-basierter Post Ein-/Ausgang

 

Spool-Transaktionen

SP01 – Ausgabesteuerung

Spool-Liste; welche Dokumente wurden gedruckt.

SPAD – Spool-Administration

Definition von Druckern; hier können auch Drucker gesucht werden.

 

Transaktionen zu SAP-Queries

SQ01 – SAP Query: Queries pflegen

Definition von Querys, die auf Info-Sets basieren.

SQ02 – SAP Query: InfoSet pflegen

Definition von Info-Sets

SQ03 – SAP Query: Benutzergruppenpflege

Definition von Benutzergruppen

SQVI – QuickViewer

Queries schnell ohne Info-Sets erstellen

 

Batch Input Transaktionen

SHDB – Transaktionsrecorder (Batch-Input)

Eine Transaktion als Batch-Input aufzeichnen.

SM35 – Batch-Input Monitoring

Monitoren für das Abspielen von Batch-Input-Mappen.

 

SAP-Wörterbuch-Transaktionen

SAPTERM – SAPterm: SAP Wörterbuch

SAP-Wörterbuch mit integriertem Übersetzungstool.

STERM – Pflege Terminologie

Volltextsuche innerhalb des SAP-Wörterbuchs

 

Sonstige Systemtransaktionen

SCAL – Logistikkalender mit CUA-Oberfläche

Zentrale Pflege Transaktion für Kalender

SM59 – RFC-Destinations (Anzeige u. Pflege)

Einrichten und prüfen von RFC-Verbindungen – Möglichkeit von Verbindungstests.

SPRO – Customizing – Projektbearbeitung

Einstieg ins Customizing des SAP-Systems.

SU53 – Auswertung der Berechtigungspüfung

Berechtigungsanalyse: Was wurde geprüft bzw. welche Berechtigungen fehlen.

 

*Wie immer es toll, wenn ihr ein kurzes Feedback hinterlassen könnt, Isa.

 

Kennst du den Aha-Effekt, wenn man eine kleinen Schatz, ein Kleinod oder eine Rarität unvermittelt entdeckst und dich fragst, warum habe ich es die ganze Zeit übersehen? Das kann ein kleines Café sein, das immer um die Ecke in einer Seitenstraße lag, das man aber nie betreten hat. Wenn man sich dann doch mal dahin verirrt und mit Erstaunen entdeckt, dass man noch nie so ein leckeren Cappuccino genossen hat. Oder wenn man zufällig ein fast verstaubendes Buch im hintersten Regal der Bibliothek zur Hand nimmt, und es nicht mehr zurücklegen kann. Oder eine Mango isst, die man zufällig beim freundlichen Inder um die Ecke erworben hat, und dabei denkt, wow, so schmeckt also eine echte Mango.

Genau diesen Aha-Effekt hatte ich, als ich die Transaktion SE16H entdeckte. Ich hatte schon vorher von dieser Transaktion gelesen, dachte mir aber, dass sie nur in Verbindung mit einem S4/HANA-System zu Verfügung steht. Doch dem ist nicht so – die Transaktion kann auch auf einen ERP 6.0 System genutzt werden.

Übrigens: Der Titel ist natürlich nicht ernst gemeint … es wird noch ausreichend SAP-Berater geben, die weiterhin die SE16 bzw. SE16N nutzen.

Die neue Transaktion SE16H ist im Grunde eine Weiterentwicklung der SE16N und dient primär als DB-Browser, d.h. man kann sich mit dieser Transaktion die Inhalte der Tabellen anzeigen lassen. Doch gegenüber der SE16N bietet die SE16H unter anderem folgende Features, die durchaus hilfreich sein können:

# Gruppierte Darstellung der Ergebnisse

# Aggregation der Ergebnisse

# Outer-Join-Definition, um Daten aus anderen Tabellen zu lesen

# Selektion nach Sets und Gruppen

Gruppierte Darstellung der Ergebnisse

Mit der Gruppieren-Funktion kannst du dir die Einträge einer Tabelle gruppiert nach bestimmten Feldern der Tabelle anzeigen lassen. Im folgenden Beispiel werden die Lieferungen aus dem Dezember 2017, mit der Lieferart LF gruppiert nach der Versandstelle dargestellt.

# Transaktion SE16H aufrufen

# In das Feld Tabelle LIKP eingeben und Enter

 

# Nun die Selektion wie im oberen Screenshot ausfüllen; wichtig: Haken für „Gruppieren“ bei Versandstelle nicht vergessen

# Ausführen (F8)

# Et Voila: Jetzt sind die Ergebnisse der Selektion gruppiert nach der Versandstelle (mit Anzahl Lieferungen pro Versandstelle) dargestellt.

Aggregation der Ergebnisse

Mit der Aggregationsfunktion ist es möglich für numerische Felder folgende Aggregationen zu ermitteln: Durchschnitt (AVG) / Maximum (MAX) / Minimum (MIN).

Im Folgenden habe ich die gleiche Selektion wie oben genutzt und zusätzlich im Selektionsbild beim Feld Gesamtgewicht in der Spalte Aggregieren „AVG – Durchschnitt“ ausgewählt. Nun sieht das Ergebnis wie folgt aus:

Jetzt wird neben der Anzahl der Lieferungen pro Versandstelle das durchschnittliche Gesamtgewicht der Lieferungen dargestellt:

 

Outer-Join-Definition, um Daten aus zusätzlichen Tabellen zu lesen

Das dritte Feature, das ich hier vorstellen will, sind Outer-Joins innerhalb der SE16H. Mit dieser Funktion kann man sich mit einem einfachen Tabellen-Join zusätzliche Daten aus einer separaten Tabelle ermitteln und darstellen. Im Folgenden ruf ich die Tabelle LIKP (Lieferkopf) mit der SE16H auf und will dazu aus der LIPS (Lieferpositionen) die Positionsnummer, den Artikel und das Werk dazu ermitteln.

# Starte Transaktion SE16H

# In das Feld Tabelle LIKP eingeben (im linken oberen Bereich) – Enter

# Zu den Feldern „Lieferung“, „Angelegt am“ und „Versandstelle“ die Ausgabe aktivieren – alle anderen Felder sollen nicht ausgegeben werden

# Jetzt das Ketten-Icon neben dem Feld „Outer-Join-Definition“ anklicken (oben rechts)

# Im nächsten Screen zunächst oben den Namen und die Bezeichnung des Joins sinnvoll vergeben (bspw. LIKP_LIPS_J)

# Im mittleren Bereich „Definition der Sekundärtabelle“ unten auf das Weiße-Blatt-Icon klicken, in der Spalte Sekundär-Tabell LIPS eingeben und auf das Pfeil-Icon in der Spalte Ausgabe klicken.

# Hier die Felder POSNR, MATNR und WERKS auswählen und Enter -> sicherheitshalber jetzt Sichern

# Nun auf die eingegebene Sek.tab. „LIPS“ doppelklicken -> damit wandert die Tabelle LIPS als ausgewählte Tabelle in den unteren Bereich

# Im unteren Bereich nun auf das Weiße-Blatt-Icon klicken (links unten) und wie folgt ausfüllen: Tab.feld = VBELN / Methode = Referenz / Referenzfeld = VBELN / Aus Tabelle = LIKP

# Deine Join-Bedingung sollte wie folgt aussehen:

 

 

# Nach dem du alles gesichert hast, gelangt man wieder zurück zum Selektionsscreen der SE16H für die Tabelle LIKP – hier einfach ausführen (F8)

 

Jetzt werden zu den LIKP-Daten (Lieferung, Versandstelle) die LIPS-Daten (Material, Werks, …) mit dargestellt.

Die neue Transaktion SE16H bietet neben den hier vorgestellten Features weiter neue Funktionen; diese könnt ihr euch im OSS Hinweis 1636416 nachlesen.

Ich hoffe, ich konnte euch einen ersten Eindruck vom neuen Tabellen-Browser SE16H geben, Isa.

„Oh Mann, das gibt es doch nicht!“, dachte sich Jean erregt, als Pascal anrief. Es war der sechste Anruf, den er heute enthielt. Gefühlt wurde er jede Minute gestört und kam eigentlich gar nicht mehr zu seiner eigentlichen Arbeit – wenn er ehrlich sein sollte, wusste Jean nicht mal, was er vorhatte.

Was hast du eigentlich heute zu tun, oder besser gesagt, was hast du heute vor? Wie sieht dein Arbeitstag aus, welche Aufgaben stehen an? Welche Aufgaben gehst du zu erst an, welche können warten? Wer bestimmt deinen Tagesablauf, deine Prioritäten – du oder jemand anderes?

Jeder SAP-Berater (aber natürlich viele Andere auch) wird sich vielfach in solchen Situationen wie Jean wiederfinden. Ich will an dieser Stelle keine Abhandlung über Zeit- bzw. Arbeitsorganisation verfassen. Aber für mich gibt es drei kleine Methoden, die ich jeden Tag anwende, um in der „Spur“ zu bleiben – probiert die einfach mal aus:

# Die To-Do-Liste
# Das Countdown-Verfahren
# Die „Beste Zeiten“-Methode

Die To-Do-Liste

Ich beginne im Grunde keinen Arbeitstag ohne To-Do-Liste. Jeden Morgen – nach dem ich meinen Rechner hochgefahren habe und die Mails überflogen habe – nehme ich mir einen Stift und schreibe die heutige To-Do-Liste in mein Notizbuch. Dabei gibt es für mich folgende Punkte zu beachten:

# Die Liste ist zunächst komplett ungeordnet – alles was mir einfällt kommt auf die Liste

# Die Liste enthält konkrete To-Dos (Verben): Also nicht „Preisfindungskonzept“, sondern „Preisfindungskonzept korrigieren“

# Wenn ich eine erste Version der Liste für den Tag fertig habe, vergebe ich eine Reihenfolge: Zu erst, als zweites, drittes, etc.

# Bei der Reihenfolge orientiere ich mich immer nach dem Grundsatz: Dass was schnell erledigt werden kann, zu erst -> so sieht man schnell Erfolge 😉

# Die Liste kann jederzeit erweitert werden, d.h. sie ist für den kompletten Tag geöffnet

# Jede neue Aufgabe, die über den Tag reinflattert, kommt zunächst auf die Liste – Aufgabe, die nicht auf meiner To-Do-Liste, werden nicht bearbeitet!

# Und zuletzt: Bestimmt Punkte tauchen in meiner Liste nicht auf: Meeting, Besprechungen mit den Kollegen, …

Das Countdown-Verfahren

Leidet ihr manchmal auch an Aufverschieberitis und kennt ihr folgende Szenen:

# Eigentlich müsste ich endlich die Anforderung schreiben, aber es könnte noch einen Tag warten.

# Den umfangreichen Testfall muss ich jetzt wirklich mal abschließen

# Das Meeting mit der Fachabteilung könnte ich auch nächste Woche organisieren.

Aufgaben, die man nicht gerne macht, die anstregend sind, die einen langen Anlauf benötigen oder wo der Druck nicht so hoch ist, schiebt man gerne vor sich hin – dabei geht es mir nicht anders, als vielen anderen.

Über die Jahre setze ich bei akuter „Aufverschieberitis“ folgende Methode sehr erfolgreich ein:

Ich schnapp mir einfach mein Smartphone und starte den Countdownzähler. Diesen stelle ich auf 15, 35 oder 45 Minuten ein und lasse ihn laufen. In dieser Zeit, arbeite ich nur an einer konkreten Aufgabe:

# Nimm dir eine konkrete Aufgabe für die Zeit vor

# Arbeite nur an diesem Thema

# Lass dich in dieser Zeit nicht ablenken: Geh nicht ans Telefon, sag Kollegen, dass du jetzt nicht kannst, …

# Starte zunächst nur mit kurzen Zeiten: 15 Minuten.

# Wende diese Methode nie länger als 45 Minuten an

# Beende unbedingt die Arbeit nachdem der Countdown abgelaufen ist.

 

Die Beste-Zeit-Methode

Wann ist eure beste Zeit; die Zeit, in der ihr am meisten zur Ruhe kommt, eure Gedanken ohne Anstrengung ordnen könnt und das Gefühl habt Bäume ausreißen zu können? Diese Zeit kann früh morgens sein, mittags, wenn die Arbeit erledigt ist, oder spät abends, wenn alle schon im Bett liegen und die Ruhe sich über das Haus legt.

Jeder hat eine andere Beste Zeit; findet einfach eure Beste Zeit und nutzt diese, um die wichtigen Sachen zu erledigen. Diese Zeiten solltet ihr euch bewusst reservieren, um die Aufgaben anzugehen, die euch am Herzen liegen.

# Bei der Beste Zeit Methode solltet ihr beachten, dass es für jede Aufgabe eine andere Beste Zeit geben kann …

Für mich ist die Beste Zeit für das Schreiben früh morgens vor dem Sonnenaufgang; in dieser Zeit nehme ich mir täglich die halbe Stunde und schreibe an diesem Blog, Isa.

 

Als SAP-Berater, der im Bereich Vertriebslogistik tätig ist, bekommt man immer wieder folgende Frage gestellt: „Warum wurde das Material nicht ausgeliefert, obwohl ausreichend Bestand vorhanden ist?“ Unweigerlich erinnert mich diese Frage an folgende Alltagssituationen:

# Kann ich morgen mit Dir einen Termin vereinbaren? – Nein? – Warum nicht, du bist doch morgen da?

# Kann ich bitte diese Brötchen haben? – Nein.  Wieso nicht, die liegen doch in der Auslage?

# Haben Sie tatsächlich keine Mietwagen mehr, auf Ihren Parkplatz stehen doch mind. zehn Fahrzeuge?

Was haben diese 3 Situationsaussagen gemeinsam? Genau – wenn etwas da ist, muss es nicht unbedingt verfügbar sein. Im ersten Fall kann der Kollege morgen in einem ganztägigen Termin stecken, im zweiten Fall können die Brötchen von gestern sein und im dritten Fall sind wahrscheinlich alle Fahrzeuge schon reserviert sein.

Genau so verhält es sich mit der Verfügbarkeitsprüfung und Bestandsmenge in SAP. Du kannst dir zu einem Material den freiverwendbaren Bestand mit der Transaktion MMBE anschauen: Entweder siehst du, dass ausreichend Bestand vorhanden ist, oder du siehst, dass gar kein Bestand da ist. Und im ersten Fall wird der Auftrag nicht bestätigt (obwohl Bestand vorhanden sind), um zweiten Fall wird der Auftrag komplett bestätigt (obwohl gar kein Bestand auf Lager liegt). Wie kann das sein?

Die Verfügbarkeitsprüfung im SD-Modul bestätigt eine Auftragsposition nicht nur basierend auf der Bestandsmenge, sondern zusätzlich nach sog. Zu- und Abgangselemente, diese sind bspw. Kundenaufträge (Abgang), Bestellungen (Zugang) oder Fertigungsaufträge (Zugang) – dieser sog. Prüfumfang wird im SD-Customizing festgelegt und wird anschließend dem Materialstamm zugeordnet. Damit kann es vorkommen, dass eine Auftragsposition voll bestätigt wird, obwohl kein Bestand vorhanden ist. Dies tritt dann auf, wenn für die Zukunft Zugänge (Bestellung, Fertigung) erwartet werden, die den Bedarf decken werden.

Also die beste Antwort auf die Fragen „Warum ein Artikel nicht beliefert wurde, obwohl Bestand vorhanden ist“ lautet:

# Bestätigung hat nicht nur mit Bestand zu tun; wahrscheinlich waren die Bestände durch andere              Kundenaufträge „reserviert“.

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

 

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.