SAP Formulare – Einsatz der Hierarchie für eindeutige Benennung
Im Lauf der Jahre sammeln sich viele Formulare in Ihrem System. Hierbei die Übersicht zu behalten, gestaltet sich schwierig. Das Einzige, was bei Ihren Formularen einheitlich ist, ist die Benennung im Kundennamensraum bzw. im Z-Namensraum.
Meine Erfahrung ist, dass Sie durch eine eindeutige Benennung der Komponenten in der Lage sind, den Verwendungszweck abzuleiten. Somit fällt es Ihnen leichter, die Formulare einzuordnen.
Vorarbeit: Verwendung ermitteln
Sie starten mit der Ermittlung, wie oft Sie manche Komponenten verwenden. Hierzu empfehle ich Ihnen, dass Werkzeug einer Hierarchie. Es fällt damit leichter, den Überblick darüber zu gewinnen, welche Komponenten für alle Formulare verwendet werden.
Im nächsten Schritt gehen Sie eine Ebene tiefer. Sie prüfen, ob sich bestimmte Komponenten nur in einer Formulargruppe wiederholen. Mit einem gemeinsamen Präfix definieren Sie alle Komponenten innerhalb der gleichen Gruppe.
Anschließend gehen Sie noch eine Ebene tiefer. Eine Formulargruppe besteht aus mehreren Formularen, die thematisch oder vom Aufbau her zusammenpassen. Auch innerhalb dieser Gruppe gibt es Unterschiede zwischen den Formularen. Es gibt auch Komponenten, die nur von einem Formular genutzt werden. Diese erhalten ebenfalls einen eigenen Präfix.
Ich prüfe zuerst, welche Dinge ich generalisieren kann. Wo bilden sich schon auf den ersten Blick logische Gruppen? Wo habe ich bei Änderungen Gemeinsamkeiten entdeckt? Häufiges auftreten von READ_TEXT sind für mich direkt ein Indiz für globale Texte als Kategorie.
Hierarchie für Formulare aufbauen – Vorgehensmodell
Schritt 1: Hierarchie aufbauen mit Hilfe der Pyramide
Als Werkzeug nutze ich dafür die Pyramidenstruktur. Sie hilft mir von Allgemeingültig bis zu formularspezifisch alle Elemente einzuordnen. Als Startpunkt definieren ich ausschließlich meine globalen Variablen, die in allen Formularen genutzt werden. Im klassischen ABAP sind das Meist Includes.
Moderne Form der Includes sind im ABAP OO die Interfaces. Da gibt es meist ein Constanten-Interface, welches genutzt wird.
Schritt 2: Globale Texte
Ich ordne die weiteren Komponenten in die Pyramide ein. Die Geschäftsbedingungen sind ein Klassiker, denn sie gehören zu der Kategorie Global gültige Texte.
Diese sind für jedes Formular, das vom Unternehmen ausgegeben wird, gültig und werden in jedem Formular verwendet. Ändern sich die AGB, wird nur ein Text geändert. Die Änderungen wirken sich auf alle Formulare aus, die auf diesen Text zugreifen.
Weitere Texte sind die Kopftexte im Beleg oder auch auf den Positionen, sofern Sie Formularübergreifend sind. Grußformel am Abschluss eines Dokumentes sind dabei sehr gerne genommen.
Unter den globalen Variablen stehen die Formulargruppen, welche ich meist nach Kategorien gruppiere.
Schritt 3: Kategorien der Formulare
Praxis-Bespiel: Alle Rechnungen kommen in die Kategorie “Rechnungen”. Sei es Mahnungen, Proforma oder Rückrechnung.
Nun bilde ich eine zweite Kategorie mit “Lieferscheinen”.Probieren Sie es doch eben aus. Welche Kategorien ergeben Sich bei Ihnen?
Fachlich zusammenhängenden Formularen bilden eine weitere Kategorie. Oft gibt es eine Kategorie nach Geschäftsvorgängen.
Alle Formulare, die im Vertrieb verwendet werden, gehören beispielsweise der gleichen Gruppe an. Eine andere Gruppe hingegen besteht aus Formularen, der Materialwirtschaft.
Es gibt viele Möglichkeiten, Formulare sinnvoll zu gruppieren. Wichtig ist hierbei, Komponenten der gleichen Gruppe mit einem gemeinsamen Präfix zu versehen.
Schritt 4: Nächste Ebene – Formularspezifische Komponenten
In der nächsttieferen Hierarchie sind die Komponenten zu finden, die nur formularspezifisch verwendet werden. Das sind Komponenten, die nicht erneut in
anderen Formularen verwendet werden.
Beispiel für eindeutige Benennung
Sie haben Ihre Formulare und dazugehörige Komponenten sortiert und in eine Pyramidenhierarchie gebracht? Nun benennen Sie diese entsprechend sauber.
Hier ein Vorschlag aus meinen Projekten:
- ZAL_*: Komponente, welche bereichsunabhängig verwendet wird (AL = all)
- ZSD_*: Komponente, die ausschließlich im SD-Modul verwendet wird (SD = Sales and Distribution)
- ZPM_*: Komponente, die ausschließlich im PM-Modul verwendet wird (PM = Plant Maintenance)
- ZTM_INV_*: Komponente, die ausschließlich bei Rechnungen im TM-Modul verwendet wird (INV = Invoice, TM = Transportation Management)
Mithilfe einer sauberen Benennung sorgen Sie dafür, dass Sie direkt wissen, wofür die Komponente bei Ihnen verwendet wird. Durch diese hierarchische Benennung von Formularkomponenten, sind Sie in der Lage auch bei Parametern, DDIC-Elementen oder Klassen den Präfix einzusetzten.
Wo hilft mir die eindeutige Benennung?
Mithilfe einer sauberen Benennung ist es für Sie einfacher, den Verwendungszweck einzelner Komponenten nachzuvollziehen. Sie können schon anhand des Namens ermitteln, wo die gewählte Komponente zum Einsatz kommt. Wenn Sie neue Formulare anlegen, tun Sie sich deutlich leichter bei der(Wieder-)Verwendung von Formularen.
Welche Erfahrungen haben Sie bei der hierarchischen Benennung von Formularkomponenten gesammelt? Arbeiten Sie auch schon mit einer hierarchischen Benennung? Ich freue mich auf Ihre Fragen und Erfahrungswerte.
