Wer hat den SD-Auftrag gelöscht – dieser kleine Trick bringt dich auf die Spur.

Im Gegensatz zu vielen anderen Objekten können Kundenaufträge und Lieferungen komplett gelöscht werden, wenn sie noch keine Folgebelege haben. Dabei werden die Belege richtig aus der Datenbank entfernt, so dass sie auch in den Belegtabellen VBAK oder LIKP nicht mehr zu ermitteln sind. Das Löschen an sich funktioniert dabei recht unspektakulär:

# Kundenauftrag: Auftrags mit VA02 aufrufen -> Über die Menüleiste: Verkaufsbeleg -> Löschen

# Lieferung: Beleg per VL02N aufrufen -> Über die Menüleiste: Auslieferung -> Löschen

In meiner täglichen Arbeit habe ich immer wieder erlebt, dass eine bestimmte Lieferung oder ein Auftrag gelöscht wurde und man sich die Fragen stellt: Warum, durch wen und wann wurde der Beleg gelöscht. Die Frage „Warum der Beleg gelöscht wurde“ kann man im System nicht mehr nachvollziehen, aber die Fragen „wann und von wem“ kann man durch folgenden kleinen Trick ermitteln.

Wie auch bei allen anderen Objekten im SAP, kann man auch zu Lieferung und Kundenaufträge ermitteln welche Änderungen am Beleg durchgeführt wurden:

# Kundenauftrag: Einen Auftrag per VA02 aufrufen -> über die Menüleiste: Umfeld -> Änderungen -> Ausführen (F8)

# Auslieferung: Lieferung per VL02N aufrufen -> Menüleiste: Umfeld -> Änderungen -> Ausführen (F8)

Wenn man an dieser Stelle vor dem Ausführen (F8) die Belegnummer eingibt, die gelöscht wurde, wird die Löschung des Belegs mit folgenden Informationen angezeigt: Wann und von wem gelöscht.

 

 

 

 

* Auf Patricks Kommentar hin, hier eine kleine Erweiterung: Der Trick besteht darin, dass man mit der VL02N oder VA02 einen (irgendeinen) nicht gelöschten Beleg aufruft, und anschließend in den Änderungslog wechselt. Hier gibt man die Belegnummer an (siehe Screenshot), die gelöscht wurde, und ruft die Änderungsbelege auf.

 

 

cu, Isa.

 

Das interessiert SAP-Berater – Top10 Beiträge bei thinkdoforward.com

Immer wenn ich einen neuen Beitrag poste, hoffe ich natürlich, dass der Beitrag hilfreich ist und dass er von möglichst Vielen gelesen wird. Seit ich über SAP schreibe und hier veröffentliche, bin ich überrascht, welche Themen ankommen und welche nicht. Um einen Eindruck zu vermitteln, welche Themen Interesse wecken und die meisten Aufrufe haben, hier die Liste der Top10 Beiträge bei thinkdoForward.com der letzten 30 Tage:

 

TOP10 Beiträge bei thinkdoforward.com:

 

#10 WLF_IDOC: Die Zauber-IDoc-Transaktion, die die WE02, WE09 und BD87 altaussehen lässt.

 

#09 Versandstellenfindung SAP-SD – einfach und übersichtlich erklärt

 

#08 102 MM-Tabellen – die Übersicht für SAP-Cracks

 

#07 Vergiss SE16 / SE16N … es lebe die SE16H

 

#06 SAP Parameter-IDs – Geheime SAP-Funktionen aktiveren und mehr Zeit fürs Wesentliche.

 

#05 SD-Transaktionen: Diese Liste kennen erfolgreiche SD-Berater.

 

#04 Der ultimative SD-Überblick anhand von 23 Funktionen

 

#03 12 IDoc-Tricks, mit denen du einen bleibenden Eindruck beim Kunden hinterlässt.

 

#02 29 SAP-GUI Features, die SAP-Berater kennen müssen!

 

#01 65 wichtige SD-Tabelle, die rocken.

 

cu, Isa.

SAP-Tabellen finden – eine minimalistische Anleitung

Die Datenbank bildet neben der Programmlogik (ABAP) und dem GUI das Rückgrat eines SAP-Systems. Und die Datenbank besteht aus einer Massen an unterschiedlichen Tabellen, in denen jeder Beleg, jedes Stammdatum, jede Aktion akribisch abgespeichert wird. Die Kenntnis der einzelnen Tabellen und deren Zusammenhänge gehört zu den technischen Kern-Skills eines SAP-Beraters – und um es auf den Punkt zu bringen: Wenn ich ehrlich bin, ist wohl der Tabellen-Browser (SE16 oder SE16N oder SE16H) meine meist genutzte Transaktion im SAP.

Natürlich kennt man mit den Jahren eine Unmenge an gängigen und nicht so gängigen SAP-Tabellen. Die Grunddaten zum Materialstamm sind natürlich in der Tabelle MARA zu finden, die Positionsdaten zum Kundenauftrag sind in der VBAP oder die Änderungsprotokolle kann man aus den Tabellen CDHDR / CDPOS ermitteln. Doch trotz dessen sieht man in einer Transaktion, einer Liste oder einer Auswertung einen Wert, ein Feld und fragt sich, in welcher Tabelle ist dieser abgelegt. Zur Ermittlung einer konkreten Tabelle gibt es folgende drei Ansätze:

 

#1 Tabelle über technische Infos ermitteln

Dieser Ansatz ist die einfachste und gängigste Methode eine Tabelle zu ermitteln und funktioniert im Detail wie folgt: Beispielsweise willst du ermitteln, in welcher Tabelle die Versandbedingungen zum Kundenauftrag abgelegt sind:

# Öffne mit der Transaktion VA03 irgendeinen Kundenauftrag

# Springe über die Menüleiste in den Kopf-Versandbereich: Springen -> Kopf -> Versand

# Leg nun den Mausfokus auf das Feld Versandbedingung (einmal rein klicken)

# Jetzt einfach auf F1 drücken und anschließend auf den Button „Technische Info“ klicken

# Im nächsten Screen sieht man im Feld Tabellenname: VBAK, Tabellenart: Transparente Tabelle und darunter Feldname: VSBED, d.h. die Versandbedingungen zum Kundenauftrag sind in der Tabelle VBAK und hier im Feld VSBED zu finden.

 

#2 Tabelle über Verwendungsnachweis ermitteln

Bei einigen Feldern im GUI funktioniert der oben beschriebene Ansatz nicht, da hier vor der Ausgabe die Feldinhalte aus der konkreten DB-Tabelle in eine interne, temporäre Struktur gepackt werden. Ein gutes Beispiel ist hier das Feld Warenempfänger (oben im Einstiegsbild eines Kundenauftrags – VA03).
Wenn man auf dieses Feld die oben beschriebenen Schritte anwendet, dann erhält man als Tabellennamen: KUWEV und Tabellenart: Struktur und Feldname: KUNNR. Die Tabellenart Struktur kennzeichnet, dass man sich die Daten KUWEV nicht per Tabellen-Browser anschauen kann. Hier kann man aber wie folgt vorgehen, um die gesuchte Tabelle zu ermitteln:

# Aus den „Technischen Infos“ in das Feld Datenelement doppelklicken: In unserem Beispiel: KUNWE

# Hier gelangt man in die Detailansicht des Datenelements KUNWE

# Von hier aus muss man mit dem Button Verwendungsnachweis nach den Tabellen suchen, in denen das Feld/Datenelement KUNWE abgelegt ist -> also hier auf den Button mit den Pfeilen klicken (das fünfte Button in der Navigationsleiste.

# Im nächsten Screen „Verwendungsnachweis Datenelement“ nur die Auswahl „Tabellenfeldern“ aktiveren und Enter

# Jetzt bekommt man eine Liste an Tabellen angezeigt, in denen der Warenempfänger zum Kundenauftrag abgelegt ist. Als versierter SD-Berater wird man wissen, dass die Belegtabellen zum Kundenauftrag mit VB beginnen. Damit kann man sich gezielt diese Tabellen ansehen.

 

#3 Tabelle über SQL-Trace ermitteln

Ein anderer Ansatz um eine bestimmte Tabelle zu ermitteln ist es den SQL-Trace (Tx. ST05) zu nutzen.

 

Anwendungsfall: Mit der Transaktion MASS kann man für eine Reihe von Objekten (Kostenstelle, Kundenauftrag, etc.) Massenänderungen durchführen. Wenn man die Transaktionen MASS startet, kann man über das Feld Objekttyp das Objekt auswählen (F4), dass man ändern will. Ich will nun mit Hilfe des SQL-Trace die Tabelle ermitteln, in der die Texte zu den BUS-Objekte zur Massenpflege-Transaktion abgelegt sind.

#1 Zunächst musst du eine 2 SAP-GUI-Modi öffnen. Im ersten Modus startest du die Transaktion ST05 und im zweiten Modus die Transaktion MASS

#2 Jetzt startest du im ersten Modus den Trace gemäß der oberen Selektion, in dem du auf den Button „Trace einschalten“ klickst (links oben)

#3 Im nächsten Schritt gehst du in den zweiten Modus (Tx. MASS) und öffnest im Feld Objekttyp die Eingabehilfe (Matchcode – F4)

#4 Nun wieder in den ersten Modus (ST05) springen und auf den „Trace ausschalten“ Button klicken.

#5 Anschließend auf den „Trace anzeigen“ Button klicken und den nächsten Screen einfach per F8 ausführen.

#6 Jetzt kommt die Musik: Hier sind nun alle SQL-Anweisungen aufgelistet, die während des Traces aufgezeichnet wurden.

##6.1 In der Spalte Objektname sind die Tabellen aufgelistet, die durchlaufen wurden

##6.2 In der Spalte Anweisung ist die Select-Anweisung dargestellt, die genutzt wurde; durch Doppelklick ins Feld gelangt man in die Details

#7 By the way – unsere gesuchte Tabelle – Texte zu den BUS-Objekten – ist hier in der Liste die Tabelle MASSNAME

 

Unternehmen müssen in Zukunft viel mehr in SAP-Weiterbildung investieren – Andreas Unkelbach im Interview

Andreas Unkelbach, Buchautor und SAP-CO Inhouse-Berater im TDF-Interview

 

TDF: Hallo Herr Unkelbach, vielen Dank, dass Sie sich die Zeit für Interview genommen haben. Über ihre Internetseite (www.andreas-unkelbach.de) und über ihr Xing-Profil kann man erfahren, dass ihr SAP-Fokus auf den Bereich Controlling liegt. Wie sind Sie an das Thema Controlling gekommen, wie war ihr Einstieg in dieses Thema?

Andreas Unkelbach: Durch meine Studienschwerpunkte Wirtschaftsrecht und Wirtschaftsinformatik hatte ich meinen ersten Kontakt mit SAP über die Vorlesungen „Standardsoftware – Rechnungswesen/ Controlling, Logistik und HR“. Im Laufe meines weiteren Studiums stellte sich für mich die Frage, wo mache ich mein berufspraktisches Semester. Zunächst war meine erste Idee für ein juristisches Internetportal zu arbeiten. Doch letztlich habe ich mich für eine Stelle direkt an der Hochschule entschieden, woraus sich die Möglichkeit für die Diplomarbeit ergab und anschließend meine erste Anstellung im Bereich Controlling in der Haushaltabteilung.

 

Tdf: Damit haben Sie direkt schon während ihres Studiums mit dem Thema SAP-Controlling angefangen?

Andreas Unkelbach: Nee, nicht ganz … zunächst war mein erster richtiger Kontakt in der aktiven Arbeit mit SAP meine Diplomarbeit. Hier lag der Fokus auf dem Berechtigungswesen, und genau beim Thema Berechtigung bekommt man einen umfassenden Blick auf viele Module. In meiner weiteren Entwicklung hat sich dann für mich herauskristallisiert, dass mein persönlicher Fokus auf dem Controlling und dem Berichtswesen liegen, wobei letzteres eine echte Herzensangelegenheit von mir ist.

TDF: Damit hatten Sie ja einen recht stringenten und quasi bruchlosen Übergang vom Studium ins SAP-Berufsleben. Wie bewerten Sie persönlich ihren Werdegang; hätten sie rückblickend etwas anders gemacht?

Andreas Unkelbach: Nach dem Studium hatte ich kurz mit dem Gedanken gespielt in die Beratung zu gehen, doch letztlich habe ich mich dagegen entschieden und habe die Stelle als Inhouse-Berater angetreten. Rückblickend war das genau die richtige Entscheidung, da ich als Inhouse-Berater immer eine große Vielfalt an Themen habe, an denen ich arbeiten kann – als externer Berater ist man hier mehr auf Spezialthemen fokussiert.

 

TDF: Hätten Sie hierzu ein Beispiel, wie die Themenvielfalt aussieht.

Andreas Unkelbach: Ja … das Paradebeispiel ist hier, dass ich an der Hochschule die Möglichkeit habe übergreifend in mehreren Bereichen zu arbeiten oder in Arbeitsgruppen des Competence Center Hessische Hochschulen. Das Competence Center arbeitet fokussiert nur in einem Modul, aber dann wieder übergreifend über alle Hochschulen des Landes Hessen.

 

TDF: Das Thema, dass alle Hochschulen in diesem Bereich so eng vernetzt sind, hört sehr interessant an – hier ergeben sich doch sicherlich Synergien, die sich auf alle Hochschulen positiv auswirken?

Andreas Unkelbach: Natürlich ergeben sich Synergien – hier würde ich aber besonders hervorheben, dass man sich durch die Arbeit mit anderen Hochschulen ein recht großes Netzwerk aufbaut, auf das man jederzeit zurückgreifen kann.

 

TDF: Als ich mir ihre Vita genauer anschaute, erkennt man doch den fachlichen roten Faden, dass Sie viel im Bereich Controlling und Berichtswesen unterwegs sind. Woher stammt ihre Begeisterung für die Themen?

Andreas Unkelbach: Ganz einfach … für mich ist es einer der kreativsten Tätigkeiten, an denen man im SAP arbeiten kann; und zusätzlich kommt hinzu, dass man mit Controlling sehr breit ausgestellt ist. Man greift im Controlling sowohl auf Logistik-, FI- als auch HCM-Daten zurück und hat die Aufgabe zu lösen, den Anwendern oder dem Management aussagekräftige Daten zur Verfügung zu stellen.

 

TDF: Können Sie uns hier ein Beispiel nennen, wo ihre Kreativität gefordert wird?

Andreas Unkelbach: Momentan arbeite ich an der Aufgabe Finanzdaten aufzubereiten und den Usern zur Verfügung zu stellen. Hier stellen sich konkret die Fragen, welche Daten können den Anwendern helfen, und wie können wir die Daten aus verschiedenen SAP-Modulen möglichst per Knopfdruck bereitstellen. Wir haben hierzu mit mehreren Kollegen zunächst an einem Konzept gearbeitet und im Anschluss an einer möglichst kreativen Umsetzung des Konzeptes.

 

TDF: Das bedeutet, ihr Fokus liegt hier in der Umsetzung des Konzeptes – dafür „brennen“ Sie?

Andreas Unkelbach: Richtig, das ist das, was mich am meisten fasziniert … wie bekomme ich am geschicktesten hin, die Daten so zu kombinieren, obwohl sie im Grunde nicht zusammenhängen.

 

TDF: Welche konkreten Tools setzen Sie ein, um die Anforderungen umzusetzen?

Andreas Unkelbach: Im Grunde greife ich auf folgende 3 Tools zurück: Reportwriter, Rechercheberichte und SAP Query. Diese Themen haben mich dabei so sehr gefesselt, dass meine zweite Publikation genau dem Thema Berichtwesen gewidmet ist.

TDF: Ihr Buch zum Thema Berichtswesen ist ja mittlerweile ihre zweite Publikation; wie sind Sie dazu gekommen, Bücher zum Thema SAP-Controlling zu veröffentlichen?

Andreas Unkelbach: Das Projekt ist durch mein eigenes Blog ins Rollen gekommen. Über diesen ist der Verlag auf mich aufmerksam geworden und hat bei mir angefragt, ob ich Interesse an einer Veröffentlichung hätte. Mein erster Gedanke war: Ohhh … großes Thema. Aber ich wusste durch meine Frau, wie positiv sich so eine Veröffentlichung machen kann. Also habe ich mir gedacht, probieren wir es einfach mal. Daraufhin hat mir der Verlag eine Vorlage für ein Buchkonzept mit der Themenvorgabe für ein Einsteigerbuch in CO zu geschickt. Ich habe hierauf dem Verlag meine inhaltlichen Vorstellungen mitgeteilt. Dieser wollte aber im Buch weitere Themen (u.a. Produktkosten-Controlling) behandelt haben. Hier musste ich aber passen, da ich mich in der gegebenen Zeit nicht in die Themen einarbeiten konnte. Hier kam mein Co-Autor Martin Munzel ins Spiel, der vom Verlag vorgeschlagen wurde. Damit haben wir uns das Buch aufgeteilt; Herr Munzel hat die Teile CO-PC und CO-PA übernommen und von mir kam der Anteil CO-OM und das Konzept des Buches.

 

TDF: Was waren Höhen, Tiefen bzw. die Herausforderung beim Schreiben ihres Buches?

Andreas Unkelbach: Primär empfand ich es als die größte Herausforderung den vorgegebenen Zeitplan einzuhalten, was eine ungemeine Disziplin erforderte. Dieser war auf 1 Jahr angesetzt, und ich konnte damals nicht abschätzen, was dieses Jahr bedeutet. Fragen, die mir durch den Kopf gingen, waren: Wie lange werden die einzelnen Phasen dauern, wo kann man sich verheddern, wie lange werden einzelne Kapitel dauern. Als zusätzliche Herausforderung kam hinzu, dass ich neben dem Schreiben auch das Customizing für das System durchführen musste. Ein IDES-System stand uns zur Verfügung, aber trotz dessen, musste ich ein Grund-Customizing aufbauen, dass als Grundlage für das Buch diente.

 

TDF: Und wie ist es in der Praxis ausgegangen; konnten Sie sich an den Zeitplan halten?

Andreas Unkelbach: Hier habe ich mir im Kalender tatsächliche feste Termine gesetzt und versucht diese einzuhalten. Natürlich gab es Passagen, wo ich für zwei bis drei Seiten 4-6 Stunden geschrieben habe, aber letztlich ist doch alles gut ausgegangen.

 

TDF: Wie war das Feedback zum Buch, nachdem es dann veröffentlich wurde?

Andreas Unkelbach: Zu meinem Buch habe ich durchgängig positive Resonanzen erhalten. Das Buch war in 2 Amazon-Kategorien (SAP und Controlling) Bestseller. Auch in meiner täglichen Arbeit ist es gut angekommen. Letztlich habe ich jetzt mit dem Satz „… wie ich schon in einem Buch ausgeführt habe …“ ein unschlagbares Argument in der Tasche, das ich tatsächlich einmal eingesetzt habe (lacht). Natürlich steigert eine Publikation die Bekanntheit ungemein – vor allem in Fachforen (bspw. FICO-Forum in Köln). Aber auch ein kleiner, recht umstrittener Aspekt meines Buches, hat zur Bekanntheit beigetragen: Das Cover mit den Erbsen – nach dem Motto: Controller die Erbsenzähler. Das Cover wurde zunächst kontrovers diskutiert, aber letztlich assoziieren viel Leute mich direkt mit dem Cover.

TDF: Aus ihrer Perspektive und Expertise heraus betrachtet, was sind die Trendthemen in den nächsten fünf bis zehn Jahren in Bereich SAP-Controlling?

Andreas Unkelbach: Es wird in den nächsten Jahren zu einer verstärkten Integration der Systeme kommen. Das sieht man jetzt schon an den Themen Universal Ledger und S/4HANA. Sehr konkret zeichnet sich diese Entwicklung mit der neuen Tabelle ACDOCA ab, die mit S/4HANA nicht nur im Bereich Controlling zum Einsatz kommt. Mit der ACDOCA werden die Informationen aller Hauptbücher und Nebenbücher in einer Tabelle gehalten. Das bringt natürlich Vorteile, aber auch Herausforderungen – in Zukunft müssen sich Controller intensiv Gedanken machen, wie sie ihr Berichtswesen mit diesen Möglichkeiten gestalten. Als weiteres Thema sehe ich das neue Semantic Tagging, mit dem man gewisse Kennzahlen übergreifend definieren kann. Auch hier wird man eine positive Entwicklung im Reporting erleben, sofern man sich damit beschäftigt. Letztlich hat das Thema maschinelles Lernen im Kombination mit der Prognose ein enormes Entwicklungspotential. Hier werden wohl betriebswirtschaftliche Standardsoftanbieter nicht hintenanstehen wollen und ihre Entwicklungen entsprechend vorantreiben.

 

TDF: Sehen Sie neben diesen Themen weitere Entwicklung, die unser direktes Arbeitsumfeld beeinflussen?

Andreas Unkelbach: Ein sehr wichtiger Trend wird sein, dass die Mitarbeiter in Zukunft viel intensiver geschult und weiterentwickelt werden müssen. Gerad mit den anstehenden technischen Veränderungen im SAP-Umfeld müssen die User auch in die Lager versetzt werden, die neuen Möglichkeiten auszuschöpfen – hier werden Unternehmen um das Thema Schulung nicht herumkommen. Natürlich müssen auch die Mitarbeiter vermehrt die Bereitschaft mitbringen sich weiterzubilden.

TDF: Vielen Dank für das Interview.

 


Andreas Unkelbach, Buchautor und Inhouse SAP CO-Berater (www.andreas-unkelbach.de)

 

S/4HANA konkret … das ändert sich fürs SD-Modul.

Kennst du den Unterschied zwischen einer Revolution und einer Evolution? Beide Punkte haben folgendes gemeinsam: Es geht um Veränderung / Anpassung des Status Quo an veränderte Rahmenbedingungen. Die Revolution passiert abrupt, mit einem Knall, explosionsartig und fordert vielfach kollateralen Schäden. Die Evolution hingegen geschieht langsam und angepasst. Sie ist kaum spürbar, aber trotzdem zielgerichtet. Nun zur großen Frage: Ist S/4HANA eine Revolution oder eine Evolution? Wenn ich mich für eine Antwort entscheiden müsste, würde ich S/4HANA eine Revolution nennen. Denn S/4HANA ändert mit einem Knall die komplette Systemgrundlage, steigert die Systemperformance von einem Tag auf den anderen und bringt aber auch kollateral Schäden mit sich, mit denen umgegangen werden muss. Was sich nun mit S/4HANA tatsächlich ändert, habe ich mir mal im Detail für das SD-Modul angeschaut und im Folgenden kurz zusammengefasst:

 

Veränderungen des SD-Moduls mit S/4HANA

#1 Die Rolle „Sales Assist“ steht nicht mehr zur Verfügung

Die Rolle „Sales Assist“ mit seinen zugehörigen Funktionen und Transaktion ist SAP ERP zugeschnitten für die Mitarbeiter, die eng mit Außen-Vertriebsmitarbeitern zusammenarbeiten. Diese Rolle und damit auch die Transaktionen VPW1 und VPWL fallen mit S/4HANA weg. Stattdessen soll an dieser die FIORI Rolle SAP_BR_INTERNAL_SALES_REP genutzt werden (weitere Details kann man in der SAP Note 2223838 nachlesen).

 

#2 WebShop und Internet Sales werden mit S/4HANA ersetzt

Wer mit dem SAP ERP den WebShop und weitere E-Commerce-Lösungen nutzt, die auf Internet Sales basieren, wird sich umstellen müssen. Auch diese Funktionen sind in S/4HANA nicht enthalten. Hier empfiehlt SAP auf Hybris-Lösung zu schwenken.

 

#3 SAP Commodity Management wird deaktiviert

Mit dem Commodity Management bietet SAP im Rahmen seines ERP-System eine Komponente, um die Prozesse rund um das Geschäft mit Rohstoffen (Holz, Weizen, Öl, Kohle, …) abzuwickeln. Die Vertriebskomponente des Commodity Management wird mit S/4HANA weitestgehend technisch deaktiviert. Aktuell wurde von der SAP hier auch keine Alternative angekündigt.

 

#4 SD-CAS geht in SAP CRM on-premise auf

Wenn ihr bis jetzt die Vertriebsunterstützungsfunktion von SAP ERP (ERP-CRM) genutzt habt, müsst ihr komplett umschwenken. Diese Funktionen werden für S4/HANA nicht mehr zur Verfügung stehen; damit fallen auch die bspw. folgenden Transaktionen weg: VC/1, VC/2, VC_2, etc. Als Alternative bietet SAP ihre neue CRM-Lösung SAP CRM on-premise an, die auch als Cloud-Variante genutzt werden kann.

 

#5 Neue Funktion BRF+ für die Nachrichtenfindung

Mit S4/HANA pusht SAP ihre neue „eierlegende Wollmilchsau“ BRF+; das Kürzel steht für Business Rule Framework plus und soll neben der Nachrichtenfindung, die bis jetzt mittels Konditionstechnik gesteuert wurde, auch viele User-Exit obsolet machen. Doch gerade beim Thema Nachrichtenfindung mit S/4HANA macht SAP mit der aktuellen S/4HANA-Version 1709 einen Schritt zurück. Wo es in vorherigen Versionen noch hieß, dass mit S4/HANA die Nachrichtenfindung für neue Fakturaarten ausschließlich per BRF+ eingestellt werden sollte, ist dies nun mit 1709 wieder offen, d.h. man kann sich per Customizing-Einstellung entscheiden, ob man BRF+ oder die Konditionstechnik nutzt. Ein entscheidender Nachteil der Nachrichtenfindung per BRF+ ist, dass ausschließlich „tatsächliche“ Ausgaben unterstützt werden. Damit fallen mit BRF+ die Sendemedien 8-Sonderfunktionen / 9-Events / A-ALE / T-Aufgaben weg. Ich kann mir gut vorstellen, dass SAP hier den Schritt zurück gemacht hat, gerade weil diese Sendemedien weggefallen sind und damit einhergehend nicht unerheblicher Widerstand von den Kunden entstanden ist.

 

#6 SD-Bonusabwicklung fällt weg

Vergleichbar zum Commodity Management, fällt mit S/4HANA die komplette Bonusabwicklung weg – d.h. Transaktionen wie VBO1 oder VB(D stehen nicht mehr zur Verfügung. Doch im Gegensatz zum Commodity Management bietet hier SAP die Möglichkeit die Funktionen der Bonusabwicklung per Settlement Management abzuwickeln.

Übrigens: Kann man per SE16 recht einfach im System ermitteln, ob die Bonusabwicklung eingesetzt wird oder nicht: Wenn in der Tabelle KONA Einträge mit ABTYP=A vorhanden sind, dann wird die Bonusabwicklung genutzt.

 

#7 Verschiedene kleinere Änderungen im Bereich SD

Mit S/4HANA „räumt“ SAP auch im Bereich SD-Reports, SD-FuBas und SD-Transaktionen auf. Die komplette Liste der Änderungen kann man in SAP-Hinweis 2228098 nachlesen (keine Angst – so viele Änderungen sind es nicht: In Summe 31 Änderungen). Hier ein kleiner Überblick der Änderungen:

# Funktionsbaustein

## BAPI_BILLINGDOC_CANCEL wird ersetzt

## BAPI_BILLINGDOC_IS_CANCELLED fällt weg

#Reports

## RV130001 wird ersetzt

## SDVBKADL fällt weg

# Transaktion

## VA05N fällt weg; stattdessen soll VA05 genutzt werden

## VA45N fällt weg; stattdessen soll VA45 genutzt werden

 

#8 WCMP_PROCESSING geht komplett in CMP_PROCESSING auf

Mit S/4HANA geht SAP auch beim Thema Reklamationsabwicklung den konsequenten Weg der Vereinheitlichung und ersetzt die Industrie-Spezifische Reklamationsabwicklung WCMP_PROCESSING wird durch die CMP_PROCESSING; damit fallen konkret folgende Transaktionen weg: WCMP_PROCESSING / WCMP_MASS / WCMP_RESULT

 

#9 Änderung an der SD-Datenstruktur (Tabellen)

Neben Änderungen an konkreten Funktionen und Transaktionen bringt S/4HANA auch eine Reihe von Änderungen an den bekannt SD-Tabellen mit sich; dabei fallen vielfach Tabellen weg bzw. die Struktur ändert sich – im Konkreten:

# Folgende SD-Tabellen fallen weg:

## VAKPA, VAPMA, VLKPA, VLPMA, VRKPA, VRPMA – wegen performanter HANA-DB, keine Index-Tabellen mehr nötig.

## VBUK, VBUP – Die Status Informationen werden in S/4HANA direkt in die jeweiligen Belegtabellen geschrieben: VBAK, VBAP, LIKP, LIPS, VBRK

## Weitere Tabellen, die wegfallen: VBOX, S066, S067

# Folgende Tabellenstruktur wird geändert

## Die Struktur der Belegflusstabelle VBFA ändert sich; bspw. wird das Feld VBTYP (Char1) durch das Feld VBTYPL (Char4) ersetzt.

## In vorhergehenden S/4HANA-Versionen wurden in der Belegfluss-Tabelle VBFA nur direkte Belegbeziehungen gespeichert; ab S/4HANA Version 1709 werden auch indirekte Belegbeziehungen gespeichert. Hierzu wurde die Tabelle VBFA um das neue Feld STUFE erweitert.

# Änderungen am Datenmodell der Preisfindung

## Der Beleg Konditionswert-Tabelle KONV, in dem die Ergebnisse der Kondition sowohl für Bestellungen als auch Kundenaufträge abgelegt sind, wird durch die Tabelle PRCD_ELEMENTS ersetzt. Im Rahmen der Migration auf S/4HANA sollen die Inhalte der KONV automatisch auf die PRCD_ELEMENTS überführt werden.

## Die möglichen Zugriffe innerhalb einer Zugriffsfolge wurde von 99 auf 999 erweitert.

## Die Schlüsselgröße für Konditionstabellen (A-Tabellen) wurde von 100 auf 255 erhöht

## Weitere Änderungen am Datenmodell der Preisfindung können im SAP-Hinweis 2267308 nachgelesen werden.

 

#10 Beim Thema SD-Außenhandelsabwicklung muss man mit S/4HANA auf GTS setzen

Auch beim Thema SD-Außenhandelsabwicklung geht SAP eine recht konsequenten Weg und schaltet mit S/4AHANA weitestgehend (bis auf die Intrastat-Lösung) und verweist seine Kunden mit der Einführung von S/4HANA hier SAP GTS zu nutzen.

 

#11 Statt Kreditmanagement FSCM SAP Credit Management

Unternehmen, die bis jetzt das klassische Kreditmanagement einsetzen (funktionell zwischen FI und SD platziert), werden sich mit dem Wechsel auf S/4HANA umstellen müssen. Diese Funktion wird mit S/4HANA nicht mehr zur Verfügung stehen und durch das SAP Credit Management (Bestandsteil des SAP Financial Supply Chain Management innerhalb von S/4HANA) ersetzt. Hier empfiehlt es sich, sich frühzeitig mit den neuen Funktionen auseinander zu setzen, wenn man bis jetzt das klassische Kreditmanagement genutzt hat. Mit dem Wegfall des Kreditmanagements stehen auch bspw. folgende Transaktionen und Reports in S/4HANA nicht mehr zur Verfügung: F.28 / F.31 / F.32 / VKM2 / VKM3 / VKM5 / RFARI020 / RFARI030.

 

#12 Keine SD-Erlösrealisierung mehr: SAP Revenue Accounting and Reporting

Auch beim Thema Erlösrealisierung ist SAP mit S/4HANA sehr konsequent und deaktiviert alle Funktionen in diesem Bereich (bspw. deaktivierte Tx. VF42, VF43, …). Stattdessen soll an dieser Stelle diese neue Funktionen SAP Revenue Accounting and Reporting eingesetzt werden. Hierbei ist zu beachten, dass man vor der Migration auf S/4HANA die Migration der SD-Erlösrealisierung auf SAP Revenue Accounting and Reporting im SAP ERP System durchführen muss.

 

#13 Die Komponente „Erweiterte Auftragsbearbeitung und Fakturierung“ fällt mit S/4HANA weg

Die SD-Komponente „Erweiterte Auftragsbearbeitung und Fakturierung“ wird im SAP ERP vielfach im Bereich Public Sector genutzt und dient für Auftragnehmer zur optimierten Auftragsabwicklung und Fakturierung. Diese Komponente fällt mit S/4HANA komplett weg, und es ist aktuell von der SAP auch kein Ersatz geplant.

 

#Übrigens: Welche Vorteile die HANA-DB bietet, hatte ich in diesem Beitrag dargestellt:

## SAP HANA Wissen, das deine Kunden in den Bann zieht.

 

cu, Isa.

102 MM-Tabellen – die Übersicht für SAP-Cracks

 

#A MM-Tabellen zum Materialstamm

#A.1 Allgemeine MM-Tabellen Materialstamm

# MARA – Allgemeine Materialdaten

# MARC – Werksdaten zum Material

# MARD – Lagerortdaten zum Material

# MVKE – Verkaufsdaten zum Material

# MARM – Mengeneinheiten zum Material

# MAKT – Materialkurztexte

# MAPE – Materialstamm: Exportkontroll-Datei

# MAST – Verbindung Material – Stückliste

# MBEW – Materialbewertung

# MLGN – Materialdaten pro Lagernummer

# MLGT – Materialdaten pro Lagertyp

# MDIP – Material: Dispositionsprofile (Feldinhalte)

# MVER – Materialverbräuche

# MLAN – Steuerklassifikation zum Material

 

#A.2 Status-Tabellen zum Materialstamm

# MSTA – Materialstammstatus

# MOFF – noch offene Materialstämme

 

#A.3 Chargen-Tabellen

# MCHA – Chargen

# MCHB – Chargenbestaende

# MCH1 – Chargen (falls Chargenverwaltung werksübergreifend)

# CHVW – Tabelle CHVW für Chargenverwendungsnachweis

 

#A.4 Tabellen zu Dispodaten

# MDMA – Dispobereich zum Material

# DBVM – Planungsvormerkung Dispobereich

# DVER – Materialverbräuche zum Dispositionsbereich

# MAPR – Materialindex für Prognose

 

#A.5 MM-Materialtabellen zu historischen Daten

# MARCH – Materialstamm-C-Segment – Historie

# MARDH – Materialstamm-Lagerortsegment – Historie

# MBEWH – Materialbewertung – Historie

# MCHBH – Chargenbestaende – Historie

# MKOLH – Sonderbestände vom Lieferanten – Historie

# MSCAH – Kundenauftragsbestand beim Lieferanten – Historie

# MSKAH – Kundenauftragsbestand – Historie

# MSKUH – Sonderbestände beim Kunden – Historie

# MSLBH – Sonderbestände beim Lieferanten – Historie

# MSPRH – Projektbestand – Historie

# MSSAH – Summe Kundenauftragsbestände – Historie

# MSSQH – Summe Projektbestände – Historie

 

#B MM-Tabellen zum Lieferantenstamm

#B.1 Allgemeine Tabellen zum Lieferantenstamm

# LFA1 – Lieferantenstamm (allgemeiner Teil)

# LFB1 – Lieferantenstamm (Buchungskreis)

# LFM1 – Lieferantenstamm Einkaufsorganisationsdaten

# LFM2 – Lieferantenstamm: Einkaufsdaten

# LFMH – Lieferantenhierarchie

 

#C MM-Tabellen zur Einkaufsabwicklung

#C.1 BANF-Tabellen

# EBAN – Bestellanforderung

# EBKN – Bestellanforderungs-Kontierung

 

#C.2 MM-Tabellen zu Bestellungen

# EKKO – Einkaufsbelegkopf

# EKPO – Einkaufsbelegposition

# EKET – Lieferplaneinteilungen

# EKES – Bestellbestätigungen

# EKAN – Lieferantenanschrift Einkaufsbeleg

# EKKN – Kontierung im Einkaufsbeleg

# EKBE – Historie zum Einkaufsbeleg

# EKBZ – Historie zum Einkaufsbeleg – Bezugsnebenkosten

# EKPB – Beistellposition im Einkaufsbeleg

# EORD – Einkaufs-Orderbuch

# EKUB – Index für Umlagerungsbestellungen zum Material

 

#C.3 Tabellen zum Einkaufsinfosatz

# EINA – Einkaufsinfosatz – allgemeine Daten

# EINE – Einkaufsinfosatz – Einkaufsorganisationsdaten

# EIPA – Bestellpreisentwicklung Infosatz

 

#C.4 Tabellen zur Dienstleistungsabwicklung

# ESLH – Leistungspaket Kopfdaten

# ESLL – Zeilen des Leistungspakets

# ESSR – Leistungerfassungsblatt Kopfdaten

# ESKN – Kontierung im Leistungspaket

# ESKL – Kontierungszuordnung Leistungszeile

# ESUC – Dienstleistungsabw. Ungeplante Limits auf Kontraktpos.

# ESUH – Dienstleistungsabw. unpeplante Leistungslimits Kopfdaten

# ESUP – Dienstleistungsabw. ungeplante Limits auf Leistungspakete

# ESUS – Dienstleistungsabw. Ungeplante Limits auf Leistungsbereiche

 

#D MM-Tabellen zur Bestandsführung

#D.1 Tabellen zum Materialbeleg

# MKPF – Belegkopf Materialbeleg

# MSEG – Belegsegment Material

# MARI – Kurzbeleg Materialbewegung

#D.2 MM-Tabellen zur Inventur

# IKPF – Belegkopf Inventurbeleg

# ISEG – Positionen des Inventurbeleges

 

#D.3 MM-Tabellen zur Reservierung

# RKPF – Belegkopf Reservierung

# RESB – Reservierung/Sekundärbedarf

 

#E MM-Tabellen zur Rechnungsprüfung

#E.1 MM-Tabellen zur Rechnung

# RBKP – Belegkopf Eingangsrechnung

# RBKPB – Rechnungsbelegkopf (Batch-Rechnungsprüfung)

# RSEG – Belegposition Eingangsrechnung

# RBCO – Belegposition Eingangsrechnung Kontierung

# RBDIFFKO – Rechnungsprüfung – Konditionen

# RBWS – Quellensteuerdaten Eingangsrechnung

# RBTX – Steuern Eingangsrechnung

# RBWT – Quellensteuerdaten Eingangsrechnung

# RBDIFFME – Reprü-Batch – Mengen-Differenzen

# RBDRSEG – Reprü-Batch – Rechnungsbelegpositionen

# RBKP_BLOCKED – Logistik-Rechnungsprüfung: Gesperrte Rechnungen

# RBEX – Persistente Kennzahlen Kopf und Position

 

#E.2 MM-Tabellen zur Rechnung – Verdichtet

# RBVD – Rechnungsbeleg – Verdichtungsdaten

# RBVDMAT – Rechnungsprüfung – Verdichtungsdaten Material

 

#F Sonstige MM-Tabellen

# MDLV – Customizing Dispobereich

# MDLG – Customizing Dispobereich Lagerorte

# MDLW – Customizing Dispobereich Werke

# MDLL – Customizing Dispobereich Lohnbearbeiter

# T023 – Warengruppen

# T024 – Einkaufsgruppen

# T030 – Fixkontentabelle

# T156 – Bewegungsart

# T156W – Buchungsstring Werte

# T156M – Buchungsstring Menge

# T156T – Bewegungsart Text

# T156SY – Bewegungsart Mengen/Wertbuchung: Systemtabelle; ab Rel. 4.6A

# T157H – Hilfetexte zur Bewegungsart

# T161 – Einkaufsbelegarten

# T161T – Texte zu Einkaufsbelegarten

 

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

Brauchen wir in 5 Jahren noch SAP-Berater – Uwe Grensing im Interview

Uwe Grensing, Geschäftsführer der Grensing Business Technology Consulting GmbH, im TDF-Interwiew

 

TDF: Hallo Herr Grensing, vielen Dank, dass Sie sich die Zeit für unser Interview genommen haben. Wie sind Sie eigentlich zur SAP-Beratung gekommen?

Uwe Grensing: Als Schüler/Student bin ich über die Themen PC-Verkauf, Netzwerkaufbau und Softwareentwicklung erstmals mit IT und Betriebswirtschaft in der IT in Kontakt gekommen. Damals lernte ich die Grundlagen (Auftrag schreiben, Lieferschein erstellen, …) meiner aktuellen Tätigkeit kennen. Später im Studium hatte die Uni Marburg die Idee ein eigenes SAP aufzubauen. Auf diese Stelle habe ich mich als HiWi beworben und wurde eingestellt. Also machte ich mich an die Arbeit und hatte das Ziel die Prozesse einer „Frittenbude“ in SAP einzurichten – das war schon herausfordernd, zumal damals kein IDES-System zur Verfügung stand. Zum Abschluss meines Studiums hatte ich dann die Möglichkeit meine Diplomarbeit bei einem Unternehmen durchzuführen, das SAP einführte. Dann kam eines zum anderen und ich machte mich selbstständig und seitdem arbeite ich als SAP-Berater.

 

TDF: Was war ihre Rolle im Rahmen ihrer Diplomarbeit – haben Sie als Junior-Consultant gearbeitet?

Uwe Grensing: Das ist eine interessante Frage … das Unternehmen hatte zunächst die klassischen Modul FI / CO eingeführt. Nach Projektende fing der CIO des Unternehmens an nachzurechnen, ob sich die sie SAP-Einführung gelohnt hatte. An dieser Stelle kam meine Arbeit zum Tragen, in dem ich die Frage untersuchte: „Wie kann man nachweisen kann, dass sich die SAP-Einführung gelohnt hat?“ In dieser Zeit entwickelte ich das theoretische Leitbild des „Gestaltungsorienterten ITManagements“.


TDF: Könnte man ihren Ansatz des Gestaltungsorientierten IT-Managements so verstehen, dass man zunächst eine IT-Strategie entwickelt und anschließend SAP einführt?

Uwe Grensing: Ich fasse das Thema weiter – man muss Unternehmensstrategie, Organisation, Personal und Technologie vor dem Hintergrund der Unternehmensumwelt und Unternehmensgeschichte unter einen Hut bringen. Die SAP-Einführung ist dann ein Werkzeug, dies entsprechend umzusetzen. Legt man beispielsweise Wert auf schlanke und kostengünstige Prozesse, wird man vielleicht nicht jeden Produktionsschritt mit einer im System festgehaltenen Qualitätsprüfung dokumentieren. Oder andersherum: Wenn die Erfüllung regulatorischer Anforderungen grundlegend ist, müssen eben entsprechende SAP-Module wie z.B. QM eingeführt werden.

 

TDF: Das erinnert mich an eine Szene in einem Projekt, wo der IT-Leiter sich vehement wehrte eine IT-Strategie aufzustellen, mit der Begründung: Er sehe keine klare Unternehmensstrategie.

Uwe Grensing: Ja, genau … ein vergleichbare Szene habe ich auch in einem Projekt erlebt. Aus der IT hieß es: „Wir wollen alle Prozesse global einheitlich halten.“ Gleichzeitig erwartet die Produktion, dass weltweit jedes Werk seine eigenen Gestaltungsräume hat, so dass es vor Ort am sinnvollsten ist. Und natürlich passt das nicht zusammen.

 

TDF: Auch diese Szene erinnert mich an eine Management-Aussage: „Man kann ja das eine tun, ohne das andere zu lassen“

Uwe Grensing (schmunzelnd): Das ist Denk-Faulheit: man drückt sich vor Entscheidungen, die dann vor Ort gefällt werden und wundert sich hinterher über die hohen Kosten.

 

TDF: Wie sieht ihr aktuelles Projektleben aus; was sind aktuelle Höhepunkte?

Uwe Grensing: Meine Projekte hatten in der letzten Zeit mit umfangreichen Zusatzentwicklungen zu tun, die meiner Arbeitsweise entgegen kamen. Natürlich ist jeder Go-Live etwas Besonderes, aber Höhepunkte suche ich nicht – hier bin ich eher auf Konstanz bedacht.

 

TDF: Entwickeln Sie selber in Ihren Projekten?

Uwe Grensing: Ich bin prinzipiell in der Lage das zu tun, aber vielfach fehlt mir die Zeit und es ist auch nicht meine Aufgabe. Meine Rolle ist an dieser Stelle eher so zu verstehen, dass ich größere Entwicklerteams anleite und die Detail-Spezifikation erstelle, die Entwickler auch umsetzen können.

 

TDF: In einem Nebensatz haben Sie erwähnt: „… in meiner Arbeitsweise …“ – was zeichnet ihre Arbeitsweise aus?

Uwe Grensing: Gegenüber vielen anderen Funktionalen-Beratern zeichnet meine Arbeitsweise aus, dass ich davon ausgehe, dass es bzgl. SAP-Standardfunktionalität nur eine Wahrheit gibt und das ist der Quellcode; und mit diesem arbeite ich sehr viel. D.h. Ich versuche möglichst detailliert zu verstehen, in wie weit die Anforderung des Kunden im Standard umsetzbar ist. Und dazu muss ich in den Quellcode; ich muss einen Prozess in Debugger durchspielen und muss begreifen, wie funktioniert ein Prozess technisch.

 

TDF: Vertrauen Sie der Dokumentation des SAP-Customizing nicht?

Uwe Grensing: Ich vertraue dem Quellcode, den ich für viele SAP-Module inzwischen recht gut kenne. Habe ich eine neue Anforderung, versuche ich mit dem Debugger zu verstehen: Was ist das Design des Moduls, was hat sich SAP gedacht, was sind die Möglichkeiten, Prinzipien. Und wenn man das verstanden hat, dann  kann man recht schnell sagen, was man im Standard machen kann, und welche Entwicklung, an welcher Stelle schnell gemacht sind. Ich erlebe hier vielfach, dass der Standard nicht verstanden wird und dadurch schnell alles nachgebaut wird.

 

TDF: Hätten sie hier ein Beispiel für Ihre Arbeitsweise?

Uwe Grensing: Ja, ein schönes Beispiel ist das Modul LO-AB (Logistic Agency Business), dass kaum ein Mensch kennt. Dieses Modul habe ich in einem Konzern benutzt, um eine Konzerntransferpreislösung zu bauen. Das ist im Standard des LO-AB so nicht vorgesehen; hier mussten wir eine kleine Lösung entwickeln – das war nur ein 10 Zeiler. Die Alternative wäre eine riesen Entwicklung in SD / MM gewesen– und mit dieser Lösung haben wir uns das gespart. Jetzt ist Kunde hoch zufrieden, dass er seine Anforderung effektiv und nahe am Standard umsetzen konnte.

 

TDF: Ihr Ansatz erinnert mich an meine Erfahrung: In SAP-Projekten fragt man sich ja vielfach, warum eine bestimmte Funktion entwickelt wurde, obwohl es sie im Standard gibt.

Uwe Grensing: Ja, hier muss sich unser Berufszweig etwas an der eigenen Nase fassen. Viele Berater wurden in den 90er ausgebildet und sind teilweise in den Release 4.5 / 4.6 stehen geblieben. Hier muss man natürlich einen Schritt weitergehen und schauen, was bietet SAP mit den neuen Releases.

 

TDF: Ja die Erfahrung kenne ich auch – es ist immer mit Aufwand verbunden, sich abends nochmal hinzusetzen und die neuesten Releasenotes durchzulesen.

Uwe Grensing: Ja, es ist ein Aufwand, aber wenn man sich damit beschäftigt, bietet es auch den Vorteil, dass man aktuelle Projekte für zukünftige Releases ausrichten kann. Bspw. wenn man in einem Projekt arbeitet, wo S4/HANA noch kein Thema ist, und das Thema „Separat disponierte Lagerorte“ aufkommt. Dann kann man schon mal sagen: „Das bekommt ihr nicht, da es diese Funktion mit S4/HANA nicht mehr gibt.“

 

TDF: Auch wenn wir etwas abgeschweift sind: Welche Aspekte machen aus Ihrer Sicht erfolgreiche Projekte aus?

Uwe Grensing: Es ist im Grunde ganz einfach: Es müssen die richtigen Leute zusammensitzen.

 

TDF (lachend): Diese Aussage kann man wohl auf das ganze Leben anwenden.

Uwe Grensing: SAP-Projekte sind People-Business; Dreh- und Angelpunkt des Projekterfolges ist es, die richtigen Leute auszuwählen – und das ist verdammt schwierig. Und viele Unternehmen haben gerad in den letzten Jahren mit dem Glauben „Das geht doch viel günstiger“ extrem viel falsch gemacht, und extrem viel Lehrgeld bezahlt. 200 Inder herholen und alles wird viel günstiger – das funktioniert nicht. Es geht nicht darum, wo die Leute herkommen, sondern man muss sich jeden einzeln anschauen. Wenn das passt, dann habe ich schon gewonnen. Anschließend kann man über die Methodik, die Organisation und das Vorgehen Gedanken machen – aber das ist alles nicht so wichtig. Entscheidend sind kompetente und erfahrene Berater.

 

TDF: Wie kann man das konkretisieren, wie würde so ein erfolgreicher Auswahlprozess aussehen?

Uwe Grensing: Ich brauche im Grunde ein Kernteam. Für jedes Modul oder Teilprojekt brauche ich einen Architekten, einen Chefkoch. Dieser sollte inhaltlich und thematisch in der Lage sein, den Bauplan / das Design zu übersehen, zu gestalten und zu steuern. Diese Architekten müssten als Team zusammenarbeiten und sicherstellen, dass am Ende die Integration klappt – wenn die Architekten gesetzt sind und eng zusammen arbeiten, ist das andere nicht mehr schwierig. Lediglich eine fachfremde, moderierende Projektleitung: das funktioniert in komplexen SAP-Projekten nicht. Effektives Projektmanagement plus ein kompetentes Architektenteam, das sich zusammen findet, dann ist der Erfolg garantiert.

 

TDF: Wie definieren Sie in diesem Zusammenhang die Rollen Teilprojektleiter versus Architekt; sollte das ein und dieselbe Person übernehmen.

Uwe Grensing: Meine Erfahrung ist, dass es hier sinnvoll ist diese beiden Themen auseinanderzuhalten. Es haut in großen Projekten einfach zeitlich nicht hin, wenn man beide Rollen vermischt. Zusätzlich kommt noch dazu, dass hier unterschiedliche Skills gefordert werden. Und es ist nicht zwangsläufig, dass ein guter Architekt auch ein guter Projektleiter ist und umgekehrt. Hier habe ich schon erlebt, dass ein guter Berater als Projektleiter einen schlechten Job abgeliefert hat und das ist Schade – die Leute sollten entsprechend ihrer Stärken eingesetzt werden.

 

TDF: Was sind die wichtigen SAP-Trends in den nächsten 5 bis 10 Jahren, wie wird sich das Beratungsgeschäft entwickeln? Auf was müssen sich SAP-Berater in den nächsten Jahren einrichten?

Uwe Grensing: Gerade wenn man als SAP-Berater in den Standard Brot und Butter Modulen unterwegs ist, muss man sich ernsthaft überlegen, ob es die eigene Arbeit in 5 Jahren in Europa noch geben wird. In vielen Unternehmen hat SAP mittlerweile Legacy Status und ist eine ziemlich etablierte Sache. Und die Unternehmen fragen sich, ob man tatsächlich noch teure Berater braucht, um das System am Leben zu halten. Es ist ja vielfach jetzt schon so, dass die AMS-Tätigkeit (Application Maintenance und Support) nicht in Deutschland erfolgt. Und auch klassische Beratertätigkeiten (Preisfindung, Kopiersteuerung, …) werden jetzt schon nicht mehr durch teure Berater übernommen, die aus Deutschland kommen, sondern von Osteuropäischen bzw. Indischen Beratern. Diese Berater sind günstiger und was die Skills betrifft vielfach gleichwertig. Damit muss sich jeder SAP-Berater fragen, welchen Mehrwert biete ich Kunden, den er woanders nicht günstiger erwerben kann.

 

TDF: Das ist natürlich eine sehr provokante These – was ist Ihr Ansatz hier, welche Mehrwert könnten SAP-Berater bieten?

Uwe Grensing: Eine Entwicklung ist es, dass viele Unternehmen in den Standard wollen. Aber wenn Unternehmen erkennen, dass der SAP-Standard an bestimmten Stellen keine zufriedenstellenden Lösungen liefert, sind Unternehmen heutzutage viel aggressiver, wenn sie spezifische Kunden-Anforderungen umsetzen wollen. Und genau an dieser Stelle wird ein Berater, der ein vernünftiges und integriertes Design abliefern kann, nicht leicht zu ersetzen sein.

TDF: Wäre es an dieser Stelle ein erster Schritt in die richtige Richtung, wenn sich Berater zukünftig mehr darauf fokussieren, eine vernünftige Spezifikation zu erstellen?

Uwe Grensing: Ja natürlich … hier wird man zukünftig einfach vielmehr technisches Knowhow haben müssen, um diese Hürden zu meistern. Ein Beispiel hierzu ist ein Projekt, das mittlerweile 10 Jahre zurückliegt. Da ging es darum, verschiedene externe Logistikdienstleister an SAP anzubinden. Für diesen global tätigen Kunden habe ich damals auf der Basis der Auslieferprozesse einen XML-Standard definiert, der die verschiedenen tatsächlich implementierten Prozesse einfach und nachvollziehbar abgebildet hat. Die gleiche Spezifikation konnte in verschiedenen Szenarien mit verschiedenen Dienstleistern immer wieder verwendet werden, da der Prozessgedanke eben nicht nur als ARIS-Diagramm, sondern auch als implementierbare Schnittstellendefinition vorlag.

TDF: Vielen Dank für das Interview.


Uwe Grensing, Geschäftsführer der Grensing Business Technology Consulting GmbH

 

 

SAP SQVI – diese Tipps solltest du dir nicht entgehen lassen.

Ich liebe die SQVI. Gerade wenn man schnell eine kleine Auswertung braucht oder ein Muster bei fehlerhaften Belegen oder Stammdaten ermitteln will, ist die SQVI für mich die erste Wahl. Natürlich kann man SAP Querys(SQ01/SQ02) bzw. einen kleinen ABAP Report nutzen, aber beide Ansätze bieten nicht den Vorteil der SQVI: Einfach, schnell und unkompliziert.

 

Wofür braucht man die SQVI?

Mit der SQVI können basierend auf SAP-Tabellen schnell und effektiv Reports generiert werden. Im Folgenden ein kleines Beispiel:

# Du brauchst eine Liste von Positionstypengruppe der Materialien aller Retouren-Aufträge in einem bestimmten Zeitraum. Also im Einzelnen:

## Auftragsdatum – VBAK-AUDAT mit Selektionsdatum

## Retourenauftrag – VBAK-VBELN mit AUART=RE

## Material zum Auftrag – VABP-MATNR

## Positionstypengruppe – MARA-MTPOS_MARA

 

# Etwas technischer dargestellt sieht das dann so aus:

## VBAK-AUDAT: Ausgabe und Selektion

## VBAK-AUART: Ausgabe und Selektion

## VBAK-VBELN: Ausgabe

## VBAP-MATNR: Ausgabe

## MARA-MARA_MTPOS: Ausgabe

Basierend auf diesen Überlegungen kannst du jetzt den Quickview erstellen:

 

#1 Transaktion SQVI aufrufen, QuickView Name eingeben (bspw. RET_POS_GR) und auf den Button Anlegen klicken.

 

#2 Im nächsten Screen Titel („Retourenaufträge mit Positionstypengruppe“) und Datenquelle (Tabellen-Join) eingeben und mit Enter bestätigen:

#3 Jetzt die Datenquellen für den Quickview auswählen; in unserem Fall die Tabelle VBAK, VBAP und MARA und diese per Join verbinden. Hierzu auf das Icon „Tabelle einfügen klicken“ (2. Von links in der Icon-Leiste) und die Tabellennamen eingeben – diesen Schritt für die 3 Tabellen wiederholen

## Die Join-Verbindung werden normalerweise vom System automatische generiert. Wenn nötig, kann diese gelöscht (rechte Maustaste auf Verbindungslinie und löschen) und manuell per Drag&Drop neuangelegt werden.

 

 

 

## Anschließend mit dem Zurück-Pfeil (F3) in der Navigationsleiste zum Feldauswahl-Screen springen.

 

#4 In diesem Schritt zunächst das linke Fenster Datenfelder groß ziehen, damit man bequem arbeiten kann. Hier die Selektions- und Anzeigefelder gemäß den Vorüberlegungen (s.o.) zusammenstellen. Hierzu das Feld, das ausgegeben werden soll, in der Spalte Listenfelder markieren. Und Felder, die selektiert werden, in der Spalte Selektionsfelder markieren.

 

 

#5 Jetzt den Quickview speichern und ausführen

## Selektion:

## Ergebnis:

 

3 Tipps zur Arbeit mit Quickviews

Wie oben dargestellt kann man SAP-Quickviews einfach aufbauen und schnell Ergebnisse erzielen. Im Folgenden ein paar hilfreiche Tipps zu Quickviews:

 

#1 Left-Outer-Join – auch leere Daten anzeigen

Ein Join wird immer aus mind. 2 Tabellen aufgebaut (na klar!) – die erste Tabelle ist Basis-Tabelle und die 2. Tabelle die Folge-Tabelle. Egal wie groß dein Join ist, d.h. über wie viele Tabellen er sich erstreckt, steht jede einzelne Verknüpfungsstelle (Join) aus einer Basis-Tabelle (links) und einer Folge-Tabelle (rechts). Jetzt kann es passieren, dass gemäß Selektion die Basis-Tabelle ein Ergebnis liefert, aber der Quickview trotzdem nichts anzeigt. Das ist immer dann der Fall, wenn die Folge-Tabelle gemäß Joinbedingung kein Ergebnis bietet.

Ein einfaches Beispiel: Du hast ein Join zwischen MARA und MARD aufgebaut. Jetzt selektierst du per MARA-MATNR 10 Materialien, aber es werden nur 7 Materialien angezeigt. D.h. für die fehlenden 3 Materialien gibt es keinen MARD-Eintrag.

Dieses Verhalten kann man einfach umgehen, indem man in der Join-Definition auf die Verknüpfung mit der rechten Maus klickt und die Option „Left-Outer-Join“ wählt. Jetzt werden bezogen auf unser MARA / MARD Beispiel auch die MARA-Sätze angezeigt zu denen es kein MARD-Eintrag gibt. Diese Option ist auch gut geeignet um fehlende Datensätze zu ermitteln.

 

#2 Alias Tabellen – Tabellen doppelt nutzen

Beim Aufbau von Join-Bedingungen kann man eine Tabelle nur einmal nutzen. Wenn man bspw. den Join MARA-MATNR*-*MVKE-PMATN*-*MARA-MATNR aufbauen will, um MARA-Daten zwischen Material und seinem Preismaterial zu vergleichen (bspw. Pflegestatus) funktioniert dies zunächst nicht.

Diese Beschränkung kann man umgehen, indem man zunächst eine Alias-Tabelle definiert (Icon-Leiste in der Join-Definition: Viertes Icon von links) und die Alias-Tabelle, wie eine „normale“ Tabelle einfügt.

 

#3 Per SE38 und SE93 – Quickview für Kollegen nutzbar machen

Ein Nachteil von Quickview gegenüber SAP Querys (SQ01) ist, dass Quickviews anderen Nutzer nicht zur Verfügung stehen. Mit folgenden 2 Tricks können auch Kollegen deine Quickviews benutzen:

#A. Aufruf per SE38:

## Ruf Tx. SQVI auf und markiere den Quickview, den du teilen willst.

## Jetzt über die Menüleiste: Quickview -> Weitere Funktionen -> Reportname anzeigen.

## Hier wird dir ein relativ kryptischer Reportname angezeigt; diesen kopieren und an die Kollegen geben.

## Diese können mit den Reportname per SE38 / SA38 den Quickview auch ausführen.

 

#B. Eine Transaktion anlegen:

Wenn du die Berechtigung hast, kannst du basierend auf den Report des Quickviews direkt einen Transaktion anlegen.

## Hierzu SE93 aufrufen, eine Transaktion vorgeben (bspw. ZZZ_MARA) und auf anlegen klicken.

## Jetzt einen Kurztext für die Transaktion vorgeben und die Option „Programm und Selektionsbild“ auswählen und Enter.

## Im nächsten Bild ins Feld Programm den Report des Quickviews eingeben und Selektionsbild 1000 auswählen und sichern.

 

SD-Transaktionen: Diese Liste kennen erfolgreiche SD-Berater.

 

Weisst du wie viele Transaktionen SAP im SD-Modul zur Verfügung stellt? Wenn man nur die Anwendungstransaktionen betrachtet und das Customizing außen vorlässt, dann sind es knapp 2000. Natürlich wird man nicht alle brauchen, geschweige denn kennen. Doch über die Jahre als SD-Berater habe ich die Erfahrung gemacht, dass bestimmte Transaktionen immer wieder benötigt werden und hilfreich sind. Im folgenden habe ich 140 SD-Transaktionen zusammengestellt, die in eine Liste „Best of SAP SD“ gehören:

 

1. SD-Transaktionen – Bereichsmenüs

2. SD-Transaktionen – Kundenauftrag

3. SD-Transaktionen – Auslieferung

4. SD-Transaktionen – Faktura

5. SD-Transaktionen – Handling Unit (HU)

6. SD-Transaktionen – LE-Transport

7. SD-Transaktionen – Kunde

8. SD-Transaktionen – Material

9. SD-Transaktionen – Stücklisten

10. SD-Transaktionen – Preiskonditionen

11. SD-Transaktionen – Nachrichten

12. SD-Transaktionen – Produktvorschlag

13. SD-Transaktionen – Materialfindung

14. SD-Transaktionen – Kunden-Material-Info

15. SD-Transaktionen – Routen

16. SD-Transaktionen – Bestandsführung / Verfügbarkeit

17. SD-Transaktionen – Sonstige Transaktionen

 

* Diesen Beitrag sehe ich an Erweiterung des Beitrags „Der ultimative SD-Überblick anhand von 23 Funktionen

 

1. SD-Transaktionen – Bereichsmenüs

Die wichtigsten Bereichsmenüs für das Vertriebsmodul (SD) von SAP ERP; mit diesen Transaktionen können eine Vielzahl von Transaktionen zu den einzelnen Bereichen dargestellt werden:

VA00 – Auftrag

VC00 – Vertriebsunterstützung

VF00 – Faktura

VI00 – Frachtkosten

VL00 – Versand

VS00 – Stammdaten (Vertrieb)

VT00 – Transport

VX00 – Exportkontrolle

 

2. SD-Transaktionen – Kundenauftrag

Im folgenden alle wichtigen SD-Transaktionen zum SD-Kundenauftrag:

VA01 / VA02 / VA03 – Kundenauftrag anlegen / ändern / anzeigen

VA05 – Liste Aufträge

VA05N – Liste Aufträge

SDO1 – Aufträge im Zeitraum

VA06 – Kundenauftragsmonitor

VA14L – Zur Lieferung gesp. Verkaufsbelege

V.02 – Liste unvollständige Aufträge

SDD1 – Doppelte Verkaufsbelege im Zeitraum

V.15 – Anzeigen rückständige Aufträge

V.26 – Aufträge nach Objektstatus

MASS – Massenänderung (BUS2032 ist auszuwählen)

 

3. SD-Transaktionen – Aus- / Anlieferung

 

VL01N / VL02N / VL03N – Auslieferung zum Kd.auftrag anlegen / ändern / anzeigem

VL06 – Lieferungsmonitor

VL06O – Auslieferungsmonitor

VL06I – Anlieferungsmonitor

VL09 – Storno Warenausgang zum Lieferschein

VL10A – Versandfällige Kundenaufträge

VL10B – Versandfällige Bestellungen

VL22N – Änderungsbelege Lieferung anzeigen

VL31N / VL32N / VL33N – Anlieferung anlegen / ändern / anzeigem

VL34 – Arbeitsvorrat Anlieferungen

VLPOD – LEB – Auslieferung ändern (LEB = Lieferempfangsbestätigung)

VLPODA – LEB – Auslieferung anzeigen

VLSP – Nachträglicher Auslieferungssplit

VL_COMPLETE – Abschließen von Lieferungen (Relevant für verteilte Lieferungen)

VL71 – Nachrichten aus Auslieferungen

V_UC – Unvollständige Vertriebsbelege (Auslieferung)

 

4. SD-Transaktionen – Faktura

 

VF01 / VF02 / VF03 – Anlegen / Ändern / Anzeigen Faktura

VF04 – Fakturavorrat bearbeiten

VF05 – Liste Fakturen

VF07 – Anzeigen Faktura aus Archiv

VF11 – Stornieren Faktura

VF21 – Anlegen Rechnungsliste

VF22 – Ändern Rechnungsliste

VF23 – Anzeigen Rechnungsliste

VF24 – Rechnungslistenvorrat bearbeiten

VF25 – Liste Rechnungslisten

VF26 – Stornieren Rechnungsliste

VF27 – Anzeigen Rechnungsliste aus Archiv

VFX2 – Anzeigen gesperrte Fakturen

VFX3 – Liste gesperrte Fakturen

VF_VPRS – Verrechnungspreise aktualisieren

VF31 – Nachrichten aus Fakturen

 

5. SD-Transaktionen – Handling Unit (HU)

 

HUMO – HU-Monitor

HU02 – Anlegen und Ändern Handling Units

VL74 – Nachrichten aus Handling Units

HUOBD – Anzeigen von HUs zur Auslieferung

HUTRA – Anzeigen von HUs zum Transport

HUIBD – Handling Units zur Anlieferung

 

6. SD-Transaktionen – LE-Transport

 

VT01N / VT02N / VT03N – Anlegen / Ändern / Anzeigen Transport

VT04 –  Transport im Sammellauf anlegen

VT07 – Sammellauf Batch

VT06 – Transporte selektieren: Disposition

VT20 – Overall Shipment Process Monitor

VT19 – Shipment Tendering Status Monitor

VT70 – Nachrichten zu Transport

 

7. SD-Transaktionen – Kunde

 

VD01 / VD02 / VD03 – Anlegen / Ändern / Anzeigen Debitor (Vertrieb)

XD01 / XD02 / XD03 – Anlegen / Ändern / Anzeigen Debitor (Zentral, d.h. inkl. BuKr-Daten)

VD05 – Sperren Debitor (Vertrieb)

VD06 – Löschvormerk. Debitor (Vertrieb)

VD04 – Änderungen Debitor (Vertrieb)

XD04 – Änderungen Debitor (Zentral)

OV51 – Änderungsanzeige Debitor

XD99 – Massenpflege Kundenstamm

 

8. SD-Transaktionen – Material

 

MM01 / MM02 / MM03 – Material anlegen / ändern / anzeigen

MM04 – Änderungsbelege Material anzeigen

MM06 – Material zum Löschen vormerken

MM17 – Massenpflege Materialstamm

 

Die korrespondierenden IS-Retailtransaktionen sind:

MM41 / MM42 / MM43  – Artikel anlegen / ändern / anzeigen

MM44 – Änderungsbelege  anzeigen

MM46 – Massenpflege Artikelstamm Retail

 

9. SD-Transaktionen – Stücklisten

 

CS01 / CS02 / CS03 – Anlegen / Ändern / Anzeigen Materialstückliste

 

10. SD-Transaktionen – Preiskonditionen

 

VK11 / VK12 / VK13 – Anlegen / Ändern / Anzeigen Kondition

 

11. SD-Transaktionen – Nachrichten

 

VV11 / VV12 / VV13 – Anlegen / Ändern / Anzeigen Nachricht: Kundenauftrag

VV21 / VV22 / VV23 – Anlegen / Ändern / Anzeigen Nachricht: Lieferung

VV61 / VV62 / VV63 – Anlegen / Ändern / Anzeigen Nachricht: Handling Units

VV71 / VV72 / VV73 – Anlegen / Ändern / Anzeigen Nachricht: Transport

VV31 / VV32 / VV33 – Anlegen / Ändern / Anzeigen Nachricht: Faktura

 

12. SD-Transaktionen – Produktvorschlag

 

VA51 / VA52 / VA53 – Positionsvorschlag anlegen / ändern / anzeigen

VA55 – Liste Positionsvorschläge

SDPV – Produktvorschlag generieren

 

13. SD-Transaktionen – Materialfindung

 

VB11 / VB12 / VB13 – Anlegen / Ändern / Anzeigen  Materialsubstitution

 

14. SD-Transaktionen – Kunden-Material-Info

 

VD51 / VD52 / VD53 – Anlage / Pflege / Anzeigen Kunden-Material-Info

VD59 – Liste Kunden-Material-Info

 

15. SD-Transaktionen – Routen

 

0VTC – Routendefinition

0VRF – Definition Routenfindung

VL51 / VL52 / VL53 – Routenfahrplan anlegen / ändern / anzeigen

 

16. SD-Transaktionen – Bestandsführung / Verfügbarkeit

 

MB51 – Materialbelegliste

MBSM – Stornierte Materialbelege anzeigen

MMBE – Bestandsübersicht

MB52 – Lagerbestandsliste

MB5B – Bestände zum Buchungsdatum

MD04 – Anzeigen Bestands-/Bedarfssituation

CO09 – Verfügbarkeitsübersicht

 

17. SD-Transaktionen – Sonstige Transaktionen

 

VOFM – Konfiguration Bedingungen, Formeln

NACE – Übergreifende Nachrichtensteuerung

OBB8 – Pflege Zahlungsbedingungen

OVSG – Pflege Incoterms

OVLH – Routen

 

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

SAP Parameter-IDs – Geheime SAP-Funktionen aktiveren und mehr Zeit fürs Wesentliche.

2014 lernte ich während des Seminars „Mitarbeiterentwicklung“ (Referentin Nadja Lins – www.nadjalins.de) folgende Metapher kennen: „Wann willst du endlich eine Pipeline bauen, statt weiterhin Eimer zu schleppen.“ Diese Metapher blieb mir nachhaltig im Gedächtnis, weil sie eingängig den Gedanken Systeme zu vereinfachen, Prozesse zu optimieren oder Aufgaben zu vereinheitlichen auf den Punkt brachte. Gemäß dem Motto: „Jeden Tag einen Schritt einfacher …“ sollte man sich diese Metapher von Fr. Lins immer wieder vergegenwärtigen und sich in der täglichen Arbeit hinterfragen, ob man seine tägliche Routine nicht optimieren kann.

Im Rahmen der Arbeit mit SAP bemerkt man ziemlich schnell, dass teilweise sehr viele Klicks und Eingaben erforderlich sind, um Informationen zu ermitteln oder Daten zu erfassen/auszuwerten. Die Anzahl der Klicks wird von den Usern vielfach als Bewertungskriterium für eine Anwendung herangezogen. An dieser Stelle können Parameter-IDs Goldwert sein.

A. Aufgaben von Paramater-IDs

B. Wie kann man Parameter-IDs ermitteln und setzen?

C. Warum werden Wertvorgaben per Parameter-IDs nicht gezogen?

D. Was machen andere User? – schau dir einfach deren Parameter-IDs an

E. Liste aller Parameter-IDs

F. Ein paar hilfreiche Parameter-IDs

G. Bitte unbedingt bei zukünftigen Z-Programmen daran denken

 

A. Aufgaben von Paramater-IDs

Mit Parameter-IDs können pro User folgende Einstellungen durchgeführt werden:

# Automatisches Setzen von Festwerten bei Start einer Transaktion

## Bsp.: Verkaufsorganisation = 1000 bei Start der Transaktion VA01 – Kundenauftrag anlegen

## Parameter-ID: VKO = 1000

# Aktivierung von bestimmten Funktionen

## Bsp. Aktivierung des Buttons „Dienste zum Objekt“ für Kundenaufträge (VA02/VA03), um Anhänge zum Auftrag zu hinterlegen, IDoc-Verlinkung zu ermitteln oder über Auftragsänderungen per Mail informiert zu werden.

## Parameter-ID: SD_SWU_ACTIVE = X

# Beeinflussung von Default-maximal-Werten

## Bsp.: Warnschwelle für SP01 – Spoolliste setzen

## Parameter-ID: SP01_WARN = 500

 

B. Wie kann man Parameter-IDs ermitteln und setzen

Die oben beschriebenen Beispiele werden pro User gesetzt; damit kann jeder User seine eigenen Parameter bestimmen. Bspw. willst du erreichen, dass beim Aufruf der Tx. VL01N (Auslieferung anlegen) immer das Feld Lieferart mit LF vorbelegt ist:

# Transaktion VL01n aufrufen

# In das Feld Lieferart klicken und F1 drücken

# Hier auf das Feld „Technische Info“(rechts unten) klicken

# Jetzt einfach die Parameter-ID ermitteln: Feld-Daten -> Parameter-ID -> ALT

# Transaktion SU3 aufrufen

# Auf den Reiter „Parameter“ klicken

# Den gewünschten Parameter und den Parameterwert eingeben (ALT und LF)

# Eingaben sichern

# Damit wird immer beim Aufruf der VL01n für deinen User die Lieferart LF gesetzt.

 

C. Warum werden Wertvorgaben per Parameter-IDs nicht gezogen?

Wenn man nun das obere Prozedere für Auftragsart in der Transaktion „VA01 – Kundenauftrag anlegen“ durchführt, wird die Auftragsart (bspw. AAT = TA) beim Aufruf der Transaktion nicht gesetzt. Damit die Parameter-ID für ein Feld gezogen wird, müssen folgende 2 technische Voraussetzungen erfüllt sein:

#1 Für das Feld im Screen, für das Parameter-IDs genutzt werden sollen, muss der SET- / GET-Parameter aktiviert sein.

#2 Die Verwendung der Parameter-ID muss im Coding (Ablauflogik zum Dynpro) abgefragt werden -> ABAP-Entwicklung

 

Diese 2 Voraussetzungen kann man wie folgt prüfen, wenn man die Berechtigung für die Tx. SE51 hat:

# Zunächst zum Feld (bspw. Auftragsart in der VA01) folgende Daten ermitteln (Tx. VA01 aufrufen, Feld Auftragsart anklicken, F1 drücken und „Technische Info“ öffnen):

## Dynpro-Daten: Programmname (hier SAPMV45A) und Bildnummer (hier 0101)

## Feldbezeichnung für Batch-Input: Dynprofeld (hier VBAK-AUART)

# Jetzt die Tx. SE51 aufrufen und vorher ermittelten Programmnamen und Bildnummer eingeben

# Im Bereich Teilobjekte „Eigenschaften“ anklicken und auf Anzeigen gehen

# Folgende Reiter aufrufen: „Elementliste“ -> „Spez. Attrib.“

# Hier nun die erste Voraussetzung prüfen: Sind zum zu prüfenden Feld (hier VBAK-AUART) die SET- / GET-Parameter aktiviert – die jeweiligen Spalten müssen angehakt sein.

## Wenn diese Option nicht aktiviert sind, dann wird’s leider nichts mit der Parameter-ID

# Zweite Voraussetzung prüfen: Von hier aus auf den Reiter „Ablauflogik“ klicken

## Die Ablauflogik ist in ABAP codiert; hier muss man im Bereich „PROCESS BEFORE OUTPUT“ ermitteln, ob die Parameter-ID zum jeweiligen Feld gesetzt wird -> ABAP lesen!

Hinweis: Diesen ganzen Aufwand kann man sich natürlich sparen: Einfach Parameter-ID setzen; wenn es funktioniert gut, wenn nicht wird einer der Voraussetzungen nicht erfüllt sein 😉

 

D. Was machen andere User – schau dir einfach deren Parameter-IDs an

Ein sehr einfacher und effektiver Ansatz, um nützliche Parameter-IDs zu finden ist es, einfach zu schauen, welche Parameter-IDs andere User nutzen. Hierzu kann man seine Kollegen fragen, oder man schaut einfach im System nach:

# Transaktion SE16H aufrufen

# Tabelle USR05 eingeben

# „Ausgabe“ und „Gruppieren“ nur für die Felder Parameter-ID und Parameterwert aktiveren und ausführen (F8)

# Jetzt werden alle im System verwendeten Paramater-IDs mit den jeweiligen genutzten Parameterwerten übersichtlich aufgelistet

 

E. Liste aller Parameter-IDs

Im SAP ERP gibt es mehrere Tausend Parameter-IDs; leider habe ich noch keine umfassende Dokumentation zu den Parameter-IDs gefunden. Wer sowas hat, sollte mich unbedingt kontaktieren. Alle Parameter-IDs kann man sich mit der Tabelle TPARA anzeigen lassen.

 

F. Ein paar hilfreiche Parameter-IDs

RWLFIDOC_NEW_EXPERT

# Wert: RWLFIDOC_NEW_EXPERT=X

#Funktion: Aktiviert die IDoc-Änderungen für Tx. WLF_IDOC (>> Details)

SD_SWU_ACTIVE

# Wert: SD_SWU_ACTIVE=X

# Funktion: Aktivierung der Funktion „Dienste zum Objekt“ SD-Kundenaufträge (VA02 / VA03)

 SD_OLD_LIST_LAYOUT

# Wert: SD_OLD_LIST_LAYOUT=X

# Funktion: Aktiviert für die Anzeige der Selektionsergebnisse der VA05 (Liste Kundenaufträge) die alte Anzeige

 SE16N_SORTFIELD

# Wert: SE16N_SORTFIELD=X

# Funktion: Aktiviert zu den Selektionsergebnissen der SE16N ein zusätzliches Sortierfeld.

 LE_VL10_USER_VARIANT

# Wert: LE_VL10_USER_VARIANT=Selektionsvariante; diese muss innerhalb der VL10 vorher angelegt sein

# Funktion: Die gesetzte Variante wird als Standardvariante gezogen

# Bemerkung: Weitere Varianten zum Thema VL10 oder LE können in der Tabelle TPARA ermittelt werden.

SE16N_MAXLINES

# Wert: SE16N_MAXLINES=Ganzzahl (bspw. 1000)

# Funktion: Setzt die Voreinstellung für maximale Treffer der SE16N

# Bemerkung: Weitere Parameter für die SE16N können in der Tabelle TPARA ermitteln werden

MMBE_ME

# Wert: MMBE_ME=“Mengeneinheit“ (bspw. ST)

# Funktion: Setzt die Anzeigemengeneinheit für die Tx. MMBE

WE19_IDOCTYP

# Wert: WE19_IDOCTYP=IDoc-Basistyp (bspw. DELVRY07)

# Funktion: Vorbelegung des Basistyp zur Transaktion WE19

SP01_WARN

# Wert: SP01_WARN=Ganzzahl (bspw. 1000)

# Funktion: Vorbelegung des maximal Werts für Warnmeldung der SP01

# Bemerkung: Weitere Parameter-IDs zur SP01 können in der Tabelle TPARA ermittelt werden

VKO

# Wert: VKO=Verkaufsorganisation (bspw. 1000)

# Funktion: Vorbelegung der Verkaufsorganisation für die Transaktion VA01 – Kundenauftrag anlegen

ART

# Wert: ART=Lieferart (bspw. LF)

# Funktion: Vorbelegung der Lieferart für die Transaktion VL01N – Lieferung anlegen

 

G. Bitte unbedingt bei zukünftigen Z-Programmen daran denken

Abschließend noch ein wichtiger Hinweis: Falls du zukünftig ein Z-Programm entwickelst oder einen Entwicklungsantrag schreibst, denk daran, dass du evtl. Parameter-IDs berücksichtigst. Damit könntest du für die Usability des Programms bspw. mit folgenden Features steigern:

# Vorbelegung einzelner Felder in der Selektion

# Vorbelegung von Standardselektionsvarianten

# Vorbelegung der Anzeigevariante

 

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