19,99 €
Die Aufgaben eines ABAP-Entwicklers sind facettenreich. Neben reinen Programmieraufgaben gilt es, konkrete Anforderungen aus der Praxis in Lösungsansätze zu überführen, mit denen der SAP-Anwender erfolgreich arbeiten kann. Dieses Praxishandbuch konzentriert sich auf die wesentlichen Fragestellungen in der tagtäglichen professionellen ABAP-Programmierung.
Der vorliegende erste von zwei Bänden hilft Ihnen, ein umfassendes Kundenprojekt zu realisieren. Im Mittelpunkt stehen in der Praxis sehr häufig benötigte Methoden der ABAP-Programmierung für die Dialog- und Hintergrundprogrammierung. Anhand eines Praxisfalls lernen Sie, eine Programmieranforderung zu strukturieren. Im ersten Schritt ist ein Datenmodell zu entwerfen. Fehlen Datenstrukturen im SAP-System, lassen sich kundeneigene Strukturen und Tabellen im SAP Data Dictionary definieren. Unumgänglich für fehlerfreie Eigenentwicklungen ist zudem der routinierte Umgang mit dem ABAP-Debugger.
Die 2. Auflage berücksichtigt aktuelle Tendenzen der SAP-Technologie, insbesondere das HANA-Datenbank-Managementsystem. Darüber hinaus wurden neuere Entwicklungstechnologien und ihr Einsatzbereich ergänzt.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 198
Veröffentlichungsjahr: 2023
Thomas Stutenbäumer
SAP®-Praxishandbuch ABAP®
Teil I: Konzeption, Entwicklung und Debugging2., erweiterte Auflage
Thomas StutenbäumerSAP®-Praxishandbuch ABAP® – Teil 1: Konzeption, Entwicklung und Debugging – 2., erweiterte Auflage
ISBN:978-3-96012-195-4 (E-Book)
Lektorat:Anja Achilles
Korrektorat:Stefan Marschner, Petra Schweitzer, Team Wallmow 65
Coverdesign:Philip Esch
Coverfoto:iStockphoto.com | bluebay2014 No. 500907477
Satz & Layout:Johann-Christian Hanke
2. Auflage 2023
© Espresso Tutorials GmbH, Gleichen 2023
URL:www.espresso-tutorials.de
Das vorliegende Werk ist in allen seinen Teilen urheberrechtlich geschützt. Alle Rechte sind vorbehalten, insbesondere das Recht der Übersetzung, des Vortrags, der Reproduktion und der Vervielfältigung. Espresso Tutorials GmbH, Bahnhofstr. 2, 37130 Gleichen, Deutschland.
Ungeachtet der Sorgfalt, die auf die Erstellung von Text und Abbildungen verwendet wurde, können weder der Verlag noch die Autoren oder Herausgeber für mögliche Fehler und deren Folgen eine juristische Verantwortung oder Haftung übernehmen.
Feedback:
Wir freuen uns über Fragen und Anmerkungen jeglicher Art. Bitte senden Sie diese an: [email protected].
Unser Ziel ist es, SAP-Wissen wie einen Espresso zu servieren: Auf das Wesentliche verdichtete Informationen anstelle langatmiger Kompendien – für ein effektives Lernen an konkreten Fallbeispielen. Viele unserer Bücher enthalten zusätzlich Videos, mit denen Sie Schritt für Schritt die vermittelten Inhalte nachvollziehen können. Besuchen Sie unseren YouTube-Kanal mit einer umfangreichen Auswahl frei zugänglicher Videos: https://www.youtube.com/user/EspressoTutorials.
Kennen Sie schon unser Forum? Hier erhalten Sie stets aktuelle Informationen zu Entwicklungen der SAP-Software, Hilfe zu Ihren Fragen und die Gelegenheit, mit anderen Anwendern zu diskutieren: http://www.fico-forum.de.
Eik Sunke:
Cloud-Entwicklung in SAP HANA
®
Viktor Laufer, Rüdiger Deppe:
ABAP-Programmierung unter SAP S/4HANA
®
Tobias Steckenborn:
Schnelleinstieg SAP
®
Business Technology Platform (BTP) – Services und Integration
Johannes Gerbershagen:
Praxishandbuch SAP
®
Gateway
Dr. Boris Rubarth:
Schnelleinstieg in SAP ABAP
®
– 2., erweiterte Auflage
Ulrich Bähr, Axel Treusch:
Praxisbuch SAP
®
Interactive Forms und Adobe LiveCycle Designer
– 2., erweiterte Auflage
Auf dem Markt gibt es eine Reihe von Veröffentlichungen zur SAP-Programmiersprache ABAP. Warum also ein weiteres Buch?
Die bestehende Literatur bzgl. ABAP beschäftigt sich oft sehr umfassend mit den Basics der ABAP-Entwicklung oder ist so speziell, dass nur ein Bruchteil daraus für die Praxis relevant ist. Auf der einen Seite wird der Leser mit Informationsfülle überfrachtet, auf der anderen Seite erhält er zu wenige Informationen.
Dieses Buch geht daher einen anderen Weg. Auf der Grundlage langjähriger Entwicklungserfahrung habe ich Methoden und Verfahren gesammelt, die tagtäglich für die Umsetzung von Kundenanforderungen benötigt werden. Dieser so entstandene Werkzeugkasten geht über das reine ABAP-Grundlagenwissen hinaus, das für das Verständnis dieses Buches vorausgesetzt wird.
Es werden Themen behandelt, die der professionelle Entwickler täglich anwendet und sonst nur durch den Besuch vieler ABAP-Seminare erfährt. Wenige Entwickler verwenden das komplette ABAP-Repertoire. Die meisten nutzen lediglich einen Bruchteil dessen, was ABAP bietet – die Essenz aus ABAP, die sie für ihre täglichen Arbeiten benötigen. Das ist es, was sie zu professionellen ABAP-Entwicklern macht.
Und genau um diese Essenz geht es in diesem Buch.
Der heutige ABAP-Entwickler ist kein reiner Programm-Codierer. Technisches Detailwissen zur Programmiersprache »ABAP« allein genügt nicht, um die an ihn gestellten Anforderungen zu bewältigen. Daneben muss er sich in die Lage des Anwenders versetzen können und mit Einfühlungsvermögen erfassen, was dieser von ihm erwartet.
Das bedeutet, dass sich ein ABAP-Entwickler über die Programmierung hinaus mit weiteren Themen auseinandersetzen muss, etwa mit den Möglichkeiten des SAP-Customizings und der SAP-Anwendungen. Ebenso bedarf es einiger Grundkenntnisse der SAP-Basis, um z.B. Dateien aus SAP-Verzeichnissen auf den Arbeitsplatzrechner herunterzuladen oder Transporte von Entwicklungen in Fremdsysteme zu importieren.
Die in diesem Buch zusammengetragenen Kenntnisse basieren auf meinen persönlichen Erfahrungen in mehr als 20 Jahren ABAP-Entwicklung für Versorgungsunternehmen. Die Versorgungswirtschaft setzt sowohl SAP-Core-Module wie die Finanzbuchhaltung, die Materialwirtschaft und die Instandhaltung als auch ein SAP-Modul mit dem Namen »Industry Solution – Utilities« (kurz: SAP IS/U) ein. Die Liberalisierung des Energiemarktes hat in den vergangenen Jahren zu enormen Umwälzungen beim Einsatz von IT-Technologien und damit zu einem hohen Anpassungsaufwand geführt.
Jede der in diesem Buch dargestellten Methoden bzw. jedes Verfahren kann analog auf andere SAP-Anwendungen übertragen werden. Unter der Prämisse, viele Facetten der Aufgaben eines ABAP-Entwicklers zu berücksichtigen, werden Themen behandelt, die über die Programmiersprache ABAP hinausgehen.
Soweit es Entwicklungstätigkeiten betrifft, wird in dieser zweiten Auflage auf die Eigenschaften der SAP-S/4HANA-Version hingewiesen, und Sie erhalten notwendige Erläuterungen zum besseren Verständnis des Einflusses der HANA-Datenbank.
S/4HANA
SAP S/4HANA wurde als Nachfolgeversion von SAP R/3 Anfang des Jahres 2015 von der SAP zur Verfügung gestellt. Die neue ERP-Version ermöglicht, das SAP-System entweder vollständig als internetbasierte Cloudanwendung, als On-Premise-Lösung im eigenen Haus oder als hybride Version mit Teilen der Anwendung in der Cloud zu nutzen. Damit verbunden ist der Einsatz der HANA-Datenbank. Diese »High-performance ANalytic Appliance« ist eine Multi-Modell-Datenbank, die Daten in Ihrem Arbeitsspeicher statt auf einer Festplatte speichert. Dadurch ist im Regelfall ein erheblich schnellerer Zugriff auf die Daten möglich als mit den zuvor eingesetzten relationalen Datenbank-Systemen. Das HANA-Datenbankmanagementsystem wurde von der SAP entwickelt und ist seit 2010 – und damit bereits unter der SAP-Version R/3 – verfügbar.
In Band I des ABAP-Praxishandbuches geht es darum, Anforderungen der Kunden zu erfassen und in ein Realisierungskonzept umzusetzen. Ich werde Ihnen u.a. die wichtigsten Aspekte des SAP Data Dictionarys beschreiben und näher auf den Debugger eingehen, der einerseits als Hilfsmittel zur Entwicklung eigener Programme und andererseits zur Lokalisierung von Fehlern in SAP-Programmen dient. Im letzten Kapitel lernen Sie häufig benötigte Methoden in der ABAP-Programmiersprache kennen.
Das erste Kapitel zeigt, wie eine konkrete Anforderung aus der Praxis zu Lösungsansätzen im SAP-System führt. Anhand dieser Umsetzung werde ich in den folgenden Kapiteln eine Reihe von Verfahren erläutern. Vor der ersten programmierten Zeile muss der Entwickler die Anforderungen des Anwenders vollständig erfasst haben und eine Lösungsstrategie erarbeiten. Jede andere Vorgehensweise kann zu Enttäuschungen aufseiten des Anwenders und zu Unmut beim Entwickler führen, weil die entwickelten Programme ansonsten wiederholt modifiziert oder erweitert werden müssten.
Das zweite Kapitel gehört dem SAP Data Dictionary und seinen Funktionen. Das Data Dictionary stellt die Schnittstelle zwischen dem Datenbankmanagementsystem (kurz DBMS, DBS oder DB) und den SAP-Anwendungen dar. Das gilt sowohl für traditionelle relationale DBMS als auch für das HANA-DBMS. Zunächst stehen grundlegende Aspekte inbesondere der HANA-DB im Fokus, bevor die Aufgaben des Data Dictionary erläutert werden.
Die Grundlage jeder Entwicklung ist das Datenmodell. Der Entwickler muss anhand der Bedarfe des Anwenders entscheiden, wie die Daten der zu entwickelnden Anwendung vorgehalten werden: Eignen sich SAP-Standardtabellen oder eher sogenannte Z-Tabellen als Erweiterung des SAP-Datenmodells? Sind es Anwendungs- oder Customizing-Tabellen, die als Wertehilfen verwendet werden? Müssen Tabelleninhalte im produktiven System durch den Anwender bearbeitet werden können? Jede Anforderung führt zu einer anderen Umsetzung des Datenmodells.
Das dritte Kapitel beschreibt die Handhabung des Debuggers. Er ist bei der Programmentwicklung und bei der Analyse von Fehlern in Programmen das Werkzeug der ersten Wahl. Der aktuelle »Standard ABAP Debugger« bietet um ein Vielfaches mehr Möglichkeiten der Fehleranalyse als der inzwischen veraltete »Klassische Debugger«. Neben einer übersichtlichen Darstellung des Programm-Codes werden der sogenannte ABAP-Stack sowie die verwendeten lokalen und globalen Variablen zu jedem Programmteil des ABAP-Stacks zeitgleich angezeigt. Das Debuggen ermöglicht ein Vor- und Rückwärtsspringen im Programmverlauf. Variablen können während des Programmlaufes manipuliert und damit die implementierten Funktionalitäten zur Laufzeit des Programms unter veränderten Bedingungen getestet werden.
Das vierte Kapitel ist erweiterten Funktionen und Entwickler-Tricks in ABAP gewidmet. Es geht hier insbesondere um die Notwendigkeit sowie die Möglichkeiten der Programmdokumentation und des Error-Handlings. Sie lernen immer wieder benötigte Programmiertricks kennen, wie z.B. ALV-Grid-Listen in der List- und Dialogverarbeitung, den Up- und Download von Daten, die Bearbeitung von Zeitscheiben, das Call-Transaction-Verfahren, den E-Mail-Versand, die »Dirty Assign«-Methode und dynamische Select-Statements.
Das fünfte Kapitel bietet einen Exkurs über neuere Entwicklungswerkzeuge, die zum einen schnellere Datenbank-Zugriffe und zum anderen die Entwicklung internetbasierter Komponenten in SAP ermöglichen sollen.
Im sechsten Kapitel finden Sie eine Auflistung der bisherigen Ergebnisse für die in Kapitel 1 dargestellten Anforderungen sowie einen Ausblick auf Verfahren und Methoden für die noch ausstehenden Aspekte der Umsetzung der anfänglich beschriebenen Aufgabe. Diese Methoden und Verfahren werden im zweiten Band des ABAP-Praxishandbuches behandelt.
In Teil II (Neuauflage erscheint im Frühjahr 2023) werden weitere Aspekte der ABAP-Programmierung vorgestellt: der Einfluss des Entwicklers auf die Performance, Modifikationen und Erweiterungen am SAP-Standard, das Customizing im SAP, das Transportwesen, Möglichkeiten der Fehlerbehebung und der Einsatz des SAP-Support-Portals bei der Behebung von Fehlern in SAP-Standard-Programmen.
Ich bin überzeugt, Ihnen mit diesem SAP-Kompendium für ABAP-Entwickler Werkzeuge an die Hand zu geben, mit denen Sie einen Großteil Ihrer Anforderungen umsetzen können. Damit das Wissen um diese Methoden und Verfahren auch zum beruflichen Erfolg führt, obliegt es Ihren persönlichen Fähigkeiten, die Wünsche des Anwenders gut zu erfassen und mithilfe der dargestellten Werkzeuge effizient und platziert umzusetzen.
Ich erhebe keinen Anspruch auf Vollständigkeit. Sollten Sie der Auffassung sein, dass aufgrund Ihrer Erfahrungen als ABAP-Entwickler wichtige Teile fehlen oder sich Fehler in dem Buch eingeschlichen haben, nehmen Sie bitte Kontakt zu mir auf. Ihre Hinweise können in einer neuen Auflage des Buches berücksichtigt werden.
Verwendete SAP-Versionen
Da sich die SAP-Versionen und deren Komponenten in den letzten Jahren sehr rasant entwickeln, weise ich darauf hin, dass sich die in diesem Ratgeber dargestellten Methoden und Verfahren auf folgende Versionsstände beziehen:
SAP Basis 7.5 oder älterSAP ABAP 7.5 oder älterSAP Logon GUI 7.7 oder älterSAP IS-U/T 6.18 oder älterDem Leser sollte bewusst sein, dass die ABAP-Syntax und -Befehle vom zugrunde liegenden SAP-Basis-Release und nicht von der Datenbank abhängig sind. Die im Praxishandbuch ABAP vorgestellten Verfahren haben sich im Laufe der Zeit zwar teilweise geändert, sind aber grundsätzlich weiterhin nutzbar.
Die SAP hat im Zuge der Einführung von S/4HANA im Graphical User Interface (GUI) ansprechendere und modernere Bildschirm-Layouts zur Verfügung gestellt.
Zeitgemäßes Bildschirmlayout in SAP-Systemen
Vergleichen Sie diese Abbildung mit dem älteren Design der Transaktion SE11 – Data Dictionary (siehe Abbildung 2.4). Sie werden feststellen, dass sich dieses Design aufgrund kleiner, auf größeren Bildschirmen kaum lesbarer Icons schlecht für eine begleitende Illustrierung der Erläuterungen eignet. Daher greife ich in diesem Ratgeber auf eine ältere Version des Layouts zurück.
Führen Sie einen Mausklick auf das kleine SAP-Icon oben links im SAP-Logon-Screen aus, um das Bildschirm-Design zu ändern.
SAP-Icon im SAP Logon
Daraufhin erscheint ein Kontextmenü, über das Sie mit einem weiteren Mausklick den Menüpunkt Optionen auswählen. Es öffnet sich folgender Eingabebildschirm:
Ändern des visuellen GUI-Designs im SAP Logon
Unter Visuelles Design • Theme-Einstellungen können Sie sich rechts im Feld Theme auswählen für eines der GUI-Designs entscheiden. Vergessen Sie nicht, die Änderung des Theme über den Button Anwenden zu bestätigen.
In dieser Neuauflage verwende ich aus Gründen der besseren Lesbarkeit das SAP Signature Theme.
SAP Signature Theme
Im Text verwenden wir Kästen, um wichtige Informationen besonders hervorzuheben. Jeder Kasten ist zusätzlich mit einem Piktogramm versehen, das diesen genauer klassifiziert:
Hinweis
Hinweise bieten praktische Tipps zum Umgang mit dem jeweiligen Thema.
Beispiel
Beispiele dienen dazu, ein Thema besser zu illustrieren.
Achtung
Warnungen weisen auf mögliche Fehlerquellen oder Stolpersteine im Zusammenhang mit einem Thema hin.
Um den Lesefluss nicht zu beeinträchtigen, verwenden wir im vorliegenden Buch bei personenbezogenen Substantiven und Pronomen zwar nur die gewohnte männliche Sprachform, meinen aber gleichermaßen Personen weiblichen und diversen Geschlechts.
Sämtliche in diesem Buch abgedruckten Screenshots unterliegen dem Copyright der SAP SE. Alle Rechte an den Screenshots hält die SAP SE. Der Einfachheit halber haben wir im Rest des Buches darauf verzichtet, dies unter jedem Screenshot gesondert auszuweisen.
Am Anfang jeder Entwicklung steht ein Kundenwunsch. In diesem Kapitel wird daher eine Anforderung aus der Praxis dargestellt. Ich zeige Ihnen auf, wie aus dem Kundenwunsch ein Konzept zur Realisierung der Anforderung in SAP entsteht. Bei den weiteren Erläuterungen von Methoden und Verfahren wird dieses Beispiel so weit wie möglich zugrunde gelegt.
»Ärmel aufkrempeln genügt nicht mehr – jetzt brauchen wir Konzepte.« Dieser bedeutende Satz eines Vertriebs-Mitarbeiters zeigt ein heute leider noch immer existierendes Phänomen: Dem Kunden werden Funktionalitäten versprochen, die nicht oder zumindest nicht in der gewünschten Form umzusetzen sind. Der Aufwand und die Dauer der Entwicklungen werden unterschätzt. Oder aber der Entwickler erhält unzureichende Beschreibungen von dem, was er umsetzen soll.
Und so schlittern IT-Dienstleister von einem Desaster zum nächsten, und die Enttäuschungen beim Kunden wachsen.
Was unternommen werden kann, um diese Situation zu entschärfen:
Beteiligen Sie die Entwickler an den Kundengesprächen.
Lassen Sie den Entwicklungsaufwand nur von erfahrenen Entwicklern abschätzen.
Vereinbaren Sie Termine zwischen Anwendern und Entwicklern, in denen die geforderten Funktionalitäten abgestimmt werden.
Fassen Sie die so diskutierten Anforderungen schriftlich zusammen.
Lähmen Sie die Entwickler nicht durch ein aufgeblasenes Projekt-Controlling.
Vereinbaren Sie Testmodalitäten, d.h. Testfälle sowie deren Umfang, Test-Mitarbeiter und Testdauer.
Stellen Sie rechtzeitig hinreichende Hardware-Ressourcen zur Verfügung.
Schulen Sie die Anwender kurz vor der Produktivsetzung in den neuen Anwendungen.
Dokumentieren Sie die Entwicklungen in der Form, dass zum einen der Anwender begreift, wozu er die Entwicklungen nutzen kann, und zum anderen Sie einen anderen ABAP-Entwickler in die Lage versetzen, Ihre Arbeiten zu erweitern bzw. zu warten.
Diese Liste lässt sich beliebig fortsetzen. Bei jedem IT-Dienstleister bzw. in jeder IT-Abteilung wird der eine oder andere Ratschlag helfen. Es ist nicht meine Absicht, an dieser Stelle Organisationsberatung zu leisten – jeder gute Mitarbeiter kennt die Schwachstellen in seinem Unternehmen am besten. Vielmehr möchte ich zu bedenken geben, dass zu einer erfolgreichen ABAP-Entwicklung deutlich mehr gehört als das reine Wissen um das Programmieren und die Programmiertechniken.
Im Folgenden werde ich die dargestellten Methoden und Verfahren anhand von Praxis-Beispielen verdeutlichen. Das nun aufgezeigte Beispiel einer Anforderung dient als Grundlage für die weiteren Erläuterungen von Verfahren und Methoden in den einzelnen Kapiteln. Es zeigt die Dimensionen einer »einfachen Anforderung« und die daraus resultierenden erforderlichen Arbeiten eines ABAP-Entwicklers.
Kennzeichnung im SAP-System für Kunden mit hohem Umsatz
Bei einem Energieversorgungsunternehmen sollen Kunden mit einem sehr hohen Umsatz für die Kundenbetreuer besonders kenntlich gemacht werden. Energieversorger steuern die Ablesung und damit indirekt die Abrechnung ihrer Dienstleistungen über sogenannte Ableseeinheiten.
Ziel dieser Maßnahme ist es, Kunden mit einem hohen Absatz in einer neuen Ableseeinheit zusammenzufassen.
In Gesprächen zwischen dem Energieversorger und dem IT-Dienstleister ergeben sich folgende Anforderungen:
Die Vertragskonten des Kunden sollen als
Kontoklasse
die neue Kontoklasse »First Customer« erhalten.
Ein
Geschäftspartner
mit einem Vertragskonto der Kontoklasse »First Customer« soll für die Kundenbetreuer in der Geschäftspartner-Verwaltung kenntlich gemacht werden.
Im
SAP Customer Interaction Center
(CIC) soll der »First Customer« durch einen besonderen Eintrag in den Geschäftspartner-Kontakten kenntlich gemacht werden.
Im Vertrag des Kunden sollen sogenannte
Rahmenvertragsdaten
des »First Customers« zugeordnet und kenntlich gemacht werden. Ein Rahmenvertrag besitzt die Attribute: »Rahmenvertragsnummer«, »Bezeichnung des Rahmenvertrags« und den »Kundenbetreuer«. Die Daten zur Verwaltung von Rahmenverträgen sollen aus einer lokalen Datei in das SAP-System hochgeladen werden.
Eine Umstellung der Ableseeinheit von »First Customer« soll stichtagsbezogen durchgeführt werden.
Durch die Änderung der Ableseeinheit ändern sich auch die Ableseportion (also das Ablesegebiet) und damit der Abschlagsplan für die Energiekosten der Kunden. Ein Programm soll die stichtagsbezogene Umstellung der Abschlagspläne von »First Customer«-Kunden ermöglichen.
Wie aus den Anforderungen hervorgeht, ist die Kennzeichnung der »First Customer« in verschiedenen SAP-Standard-Programmen erforderlich.
1. Die Kennzeichnung im Vertragskonto erfordert das Einstellen (sogenanntes Customizen) einer neuen Kontoklasse.
2. Die Darstellung eines »First Customers« in der Geschäftspartner-Verwaltung erfordert zusätzliche Felder in der Anzeige des Geschäftspartners.
3. Die Zuordnung von Rahmenverträgen zu den Verträgen des Geschäftspartners erfordert zusätzliche Ein- und Ausgabefelder in der SAP-Vertragsverwaltung.
Ebenso werden eine neue Datenbanktabelle und eine Suchhilfe benötigt.
Die Eingabe von Rahmenverträgen erfordert die Erstellung einer neuen kundenspezifischen Datenbanktabelle, in der diese Rahmenverträge gespeichert werden.
Damit einem Vertrag durch den Anwender die korrekten Rahmenverträge zugeordnet werden, soll eine Suchhilfe zu den Rahmenverträgen angezeigt werden.
Die stichtagsbezogene Einführung von »First Customer«-Kunden kann nur mithilfe von Eigenentwicklungen ermöglicht werden.
Die Zuordnung der neuen Kontoklasse »First Customer« zu den entsprechenden Vertragskonten erfordert die Entwicklung eines Programms, das die Kontoklasse gewählter Geschäftspartner umstellt.
Um die Daten von Rahmenverträgen in einer kundeneigenen Tabelle im SAP-System zur Verfügung zu stellen, wird ein Programm benötigt, das diese Daten aus einer externen Datei in das SAP-System hochlädt.
Die Ableseeinheit ist ein Feld in den
Zeitscheiben
der Anlagen, die beim Kunden installiert sind. Es muss ein Programm entwickelt werden, das zu einem Stichtag eine neue Anlagenzeitscheibe mit einer neuen Ableseeinheit erstellt.
Durch die Einführung einer neuen Ableseeinheit und damit einer neuen Ableseportion sind die Abschlagspläne umzustellen. Es ist ein Programm zu entwickeln, das die Portion in jedem Abschlagsplan der neuen Abrechnungsperiode prüft. Ist im Abschlagsplan die neue Portion für die neue Ableseeinheit korrekt, ist keine weitere Aktion erforderlich. Wenn nicht, dann muss der alte Abschlagsplan gelöscht und ein neuer angelegt werden. Sind bereits finanzielle Ausgleiche auf dem »alten« Abschlagsplan erfolgt, so kann dieser nicht mithilfe des neu entwickelten Programms gelöscht werden. Vor dem Löschen müssen die Ausgleiche manuell zurückgenommen und nach Umstellung auf einen neuen Abschlagsplan manuell gebucht werden.
Die Kennzeichnung eines First Customers im SAP CIC durch eine besondere Kontakt-Nachricht in der Geschäftspartner-Übersicht erfordert die Entwicklung eines Programms, das für selektierte Geschäftspartner diese speziellen Kontakt-Nachrichten anlegt.
Der Entwickler muss nun entscheiden, ob und wie er diese Anforderungen im SAP-System des Kunden umsetzen kann.
Das Datenmodell ist die Grundlage jeder Entwicklung. Ein ABAP-Entwickler muss wissen, wo welche Daten zu finden sind, ob bestehende SAP-Standardtabellen erweitert werden können und ob das Anlegen einer neuen kundeneigene Tabelle erforderlich ist.
Im vorliegenden Beispiel ist das Datenmodell relativ einfach (siehe Abbildung 1.1).
Abbildung 1.1: Datenmodell zur Anforderung
Ein Geschäftspartner kann mehrere Vertragskonten besitzen. Ein Vertragskonto hat immer genau eine Kontoklasse, ihm können beliebig viele Verträge zugeordnet werden. Ein Vertrag besitzt genau einen Rahmenvertrag. Diesem (Versorgungs-) Vertrag ist eine Anlage zugeordnet. Eine Anlage besitzt beliebig viele Anlagenzeitscheiben. Für die Verwaltung von Rahmenverträgen muss eine kundeneigene Datenbanktabelle erstellt werden. Die Zuordnung eines Rahmenvertrags zu einem Vertrag wird durch das Feld Rahmenvertrags-ID eingerichtet. Dieses Feld wird im Customer-Include CI_EVER (Felderweiterungen für den Vertrag) angelegt (siehe Abschnitt 2.7).
Für die Datenhaltung sind folgende Aktivitäten erforderlich:
Anlegen einer Tabelle ZRAHMENVERTRAG, in der die Daten für die Rahmenverträge gespeichert werden,
Erweiterung der Felder im (Versorgungs-)Vertrag für die Verbindung zwischen diesem und dem Rahmenvertrag, sowie die Aufnahme weiterer Felder für Ansprechpartner und deren Kontaktinformationen im Versorgungsvertrag,
Customizing von Prüftabellen, z.B. für die neue Kontoklasse.
Die Anforderungen des Anwenders setzen einige Erweiterungen von in den SAP-Standard-Programmen voraus (vgl. Abschnitt 1.4.1):
Anzeige der Kontoklasse im Vertragskonto,
Anzeige der »First-Customer«-Eigenschaft im Geschäftspartner,
Anzeige von Rahmenverträgen in Verträgen,
Anzeige einer bestimmten Kontaktklasse im Customer-Interaction-Center.
Für eine stichtagsbezogene Umstellung ist die Entwicklung von Programmen erforderlich (vgl. Abschnitt 1.4.2):
Upload von Rahmenvertragsdaten,
Umstellung der Vertragskonten auf die neue Kontoklasse,
Umstellung der Ableseeinheit über eine neue Zeitscheibe in den Anlagen,
Erstellung spezifischer Geschäftspartnerkontakte mit einer neuen Kontaktklasse,
Anpassen der Abschlagspläne.
Diese Anzeige wird durch das Einstellen (Customizen) der neuen Kontoklasse in der Prüftabelle zum Feld Kontoklasse des Vertragskontos erzielt. Das Customizing wird im zweiten Teil des »SAP-Praxishandbuchs ABAP« behandelt.
Für modifikationsfreie Erweiterungen im Geschäftspartner werden die Transaktionen BUPT und BUCO verwendet. Die Lösung dieser Problemstellung finden Sie im zweiten Teil vom »SAP-Praxishandbuch ABAP«, im Kapitel »Änderungen und Erweiterungen im SAP-Standard«.
Modifikationsfreie Erweiterungen von Feldern in der Vertragsverwaltung können über sogenannte User- und Screen-Exits erreicht werden. Die Lösung zeige ich ebenfalls in zuvor genanntem Kapitel vom zweiten Teil des Praxishandbuchs.
Umstellungsprogramme müssen eine Analyse-Funktion besitzen, die dem Anwender zeigt, welche Objekte wie umgestellt werden können und welche aus welchen Gründen nicht. Dabei ist zu berücksichtigen, dass bereits umgestellte Objekte nicht erneut umgestellt werden, d.h., das Programm muss »wiederaufsetzbar« sein. Erst in einem Umstellungs-Programmlauf werden die analysierten Objekte anhand der Analyseergebnisse so weit wie möglich umgestellt. Die Entwicklung dieser Programme wird im Abschnitt über die Programmierung von ALV-Grid-Ausgaben erläutert (siehe Abschnitt 4.11).
Und nun zu den geforderten Funktionalitäten der neu zu entwickelnden Programme.
Diese Entwicklung muss den Fall abfangen, dass die neue Kontoklasse in der Customizing-Tabelle noch nicht eingestellt wurde. Ansonsten ergeben sich keine weiteren Schwierigkeiten.
SAP speichert in bestimmten Tabellen die Historie von Datenobjekten. Diese Datensätze werden mit einem Ab- und einem Bis-Datum für ihren Gültigkeitszeitraum versehen. Die einzelnen Datensätze bezeichnet man mit dem Begriff Zeitscheibe.
Damit die Anlagenhistorie bzgl. der Ableseeinheiten in SAP verwaltet werden kann, dürfen die Zeitscheiben einer Anlage weder zeitliche Überlagerungen noch Lücken aufweisen. Es stellt sich die Frage, wie die Umstellung der Ableseeinheiten durchgeführt werden soll.
Zunächst stellt sich das Problem sehr einfach dar: Die Anlage erhält zu einem Stichtag eine neue Zeitscheibe. Die vorhandene Zeitscheibe erhält ein BIS-Datum mit dem Umstellungsdatum minus einen Tag.
Weitere Überlegungen machen erste notwendige Fallunterscheidungen für die Programmierung erkennbar:
Besitzt die Anlage einen aktiven Vertrag?
Hat die Anlage bereits die neue Ableseeinheit zum Umstellungstermin?
Hat die Anlage eine BIS-Zeitscheibe vor dem Umstellungstermin minus einen Tag?
In unserem Fallbeispiel stellte der Anwender bei Tests der Anwendung die Ableseeinheit weit in der Zukunft um und wählte anschließend einen Termin in der näheren Zukunft. Das führte zu einer Reihe von Fallunterscheidungen, die unterschiedliche Lösungen erforderten. Diese Anforderung des Kunden – obwohl sie nur einen Sonderfall darstellte – sprengte den geschätzten Aufwand. Also: Vorsicht bei der Bearbeitung von Zeitscheiben und der Aufwandsschätzung.
Auf die »fallenträchtige« Programmierung zur Änderung von Zeitscheiben werde ich im Abschnitt 4.8 eingehen.
Bei einem Programm zur Erstellung von Geschäftspartnerkontakten können SAP-Standard-Funktionsbausteine verwendet werden, die mit entsprechenden Parametern aufzurufen sind. Die Geschäftspartnerkontakte nutzen einen Nummernkreis, der ihre fortlaufende Nummerierung ermöglicht. Die Entwicklung des Programms wird im Abschnitt über die Nummernkreise erläutert (siehe Abschnitt 4.19).
Mit diesem Programm kommen wir in den für Versorgungsunternehmen sensiblen Abrechnungsbereich. Prinzipiell muss das Programm zunächst die grundlegenden Prüfungen für die Erstellung korrekter Abschlagspläne durchführen, d.h.:
Hat die Anlage eine Zeitscheibe mit der neuen Ableseeinheit?
