Technische Umsetzung eines internen Kontrollsystems im Versicherungswesen: Grundlagen der SAP-Programmierung

Inhaltsverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

SAP-Abkürzungsverzeichnis

1. Einleitung
1.1 Aufbau der Arbeit
1.2 Beschreibung des Praxisunternehmens
1.3 Ergebnisse aus der vorangegangenen Praxisarbeit

2. Hintergründe und Vorwissen
2.1 Entwicklungsablauf nach dem ASAP-Prinzip
2.2 Grundlagen für die ABAP-Programmierung
2.2.1 Repository
2.2.2 ABAP-Workbench und Object Navigator
2.3 Grundlegende ABAP-Sprachelemente
2.3.1 Datenobjekte und Datentypen
2.3.2 Komplexe Datentypen
2.3.3 Feldsymbole
2.4 Entwicklungsorganisation und Transportwesen

3. Implementierung
3.1 Entwicklungsrichtlinien und Namenskonventionen
3.2 Verwendete Tabellen
3.3 Vorauszahlungsprozess aus Datenbanksicht
3.4 Anlegen und Aktivieren des Reports
3.5 Programmablauf
4. Fazit und Ausblick

Anhang: Anhangsverzeichnis
Anhang 1: Prozessablaufdiagramm
Anhang 1: Prozessablaufdiagramm
Anhang 2: Ebenen des R/3-Systems [04]
Anhang 3: Werkzeuge der ABAP-Workbench [04]
Anhang 4: Auswertungsliste
Anhang 5: Eingebaute elementare ABAP-Typen fixer Länge
Anhang 6: Eingebaute elementare ABAP-Typen variabler Länge

Glossar

Quellenverzeichnis

Der Autor

Abbildungsverzeichnis

Abbildung 1: Phasen eines ASAP-Projekts

Abbildung 2: Aufbau des R/3-Repository[04]

Abbildung 3: Transportauftrag[04]

Abbildung 4: Namenskonventionen

Abbildung 5: Felder der Auswertungsliste

Abbildung 6: Tabelle /xxx/T_CD_VZAHLP

Abbildung 7: Teilprozess Vertrieb

Abbildung 8: Teilprozess Rechnungswesen

Abbildung 9: Selektionsbildschirm

Abbildung 10: Selektion - nur offene Vorauszahlungen

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

SAP-Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

1.1 Aufbau der Arbeit

Diese Projektarbeit gliedert sich in vier Kapitel. Im ersten Kapitel werden zum einen die Ergebnisse der ersten Arbeit, auf dem diese Arbeit basiert, zusammengefasst und zum anderen das Praxisunternehmen näher beschrieben, indem dieses Projekt durchgeführt wird. Um die Implementierung für den Leser verständlich und nachvollziehbar zu machen, werden im zweiten Kapitel die Grundlagen der Entwicklungsumgebung und der Programmiersprache, mit denen das interne Kontrollsystem (IKS) erstellt wird, beschrieben. Anschließend wird in Kapitel drei gezeigt, wie diese Sprachelemente zur Implementierung des IKS verwendet wurden. Die Arbeit endet im vierten Kapitel mit einem Fazit und einem Ausblick zu dieser Projektaufgabe.

Fachbegriffe und erklärungsbedürftige Ausdrücke werden im nachfolgenden Glossar näher erläutert. Sie sind beim ersten Auftreten kursiv und mit Sternchen markiert. Verwendete Abkürzungen können im Abkürzungsverzeichnis nachgeschlagen werden und stehen beim ersten Auftreten im Text in Klammern hinter dem dazugehörigen Ausdruck. Quellenangaben sind mit eckigen Klammern und kursiv kenntlich gemacht.

1.2 Beschreibung des Praxisunternehmens

Die untersuchte Versicherung ist Spezialversicherer der Bauwirtschaft und mittlerweile auch einer der größten deutschen Auto- und Haftpflichtversicherer. Sie wurde als Haftpflichtversicherungsanstalt gegründet und hat ihren Hauptsitz in Hannover. Zurzeit sind ca. 2600 Mitarbeiter in dem untersuchten Versicherungsunternehmen beschäftigt, ca. 250 davon in der Informatik.

1.3 Ergebnisse aus der vorangegangenen Praxisarbeit

In der vorangegangen Praxisarbeit wurde bereits ein Konzept für ein IKS für manuelle Vorauszahlungen imProvisionsexkasso*erstellt. Provisionsexkasso ist ein Begriff aus dem Finanzwesen und beschäftigt sich mit dem Transaktionsvorgang von Leistungen, in dem Fall mit der Auszahlung des Entgelts, das dieVermittler*undMakler*der Versicherung für ihre Tätigkeit bekommen. Die Höhe derProvision*ist vertraglich zwischen der Versicherung und den Maklern bzw. Vermittlern geregelt. Dabei besteht die Möglichkeit, Provisionen oder einen Teil davon vor Leistungsbescheinigung vorauszuzahlen. Für diesen Vorgang gibt es jedoch keine einheitlichen Tarife und Abstimmungen. Die Bedingungen für Vorauszahlungen und deren Höhe werden individuell zwischen den Maklern bzw. Vermittlern und der Versicherung abgesprochen und festgelegt. Die Motivation für ein IKS für den Vorauszahlungsvorgang besteht demnach darin, mögliche Fehler und auch vorsätzlichen Betrug zu vermeiden und einen Überblick über erfasste und getätigte Vorauszahlungen zu ermöglichen.

Der Prozess der manuellen Vorauszahlungen, wurde in der vorangegangenen Arbeit beschrieben und analysiert mit dem Ergebnis, dass an dem Vorgang insgesamt drei verschiedene Instanzen beteiligt sind, nämlich der Vertrieb und das Rechnungswesen für die Erfassung und die Freigabe und die Bank für die Auszahlung (siehe Anhang 1). Für jede Vorauszahlung gibt es jeweils zwei Buchungen. Das ist zum einen die kreditorische Buchung, die einen Aufwand für die Versicherung darstellt, weil sie an den Makler bzw. Vermittler überwiesen wird und somit vom Konto der Versicherung abfließt. Zum anderen ist das die debitorische Buchung, die die Rückzahlung und somit einen Ertrag für die Versicherung darstellt. Meistens erfolgt die Rückzahlung durch eine Verrechnung mit den tatsächlich angefallenen Provisionen des Maklers bzw. Vermittlers, der die Vorauszahlung erhalten hat.

Die Informationen über die Vorauszahlungen sollen in regelmäßigen Abständen dem Vertrieb und dem Rechnungswesen zur Verfügung gestellt werden. Das IKS, das diese Informationen bereitstellt, soll im SAP-Umfeld aufgebaut werden, da für den Prozess der Erfassung von manuellen Vorauszahlungen eine SAP-Komponente verwendet wird.

In der vorangegangen Arbeit wurde erläutert, dass sich eine Auswertungsliste als IKS eignet, für die ein eigener Report implementiert werden soll, der für die Erstellung der Liste zuständig ist. Die Liste soll im SAP List Viewer (ALV)-Grid erstellt werden, da es standardmäßig Funktionen anbietet, wie z.B. die Sortierung, Filterung und Summierung der angezeigten Tabellendaten. Für die technische Umsetzung soll ein von SAP mitgelieferter Funktionsbaustein, verwendet werden, der die Funktionen zum Erstellen einer Liste im ALV-Grid bereits enthält. Die benötigten Daten für die Auswertungsliste befinden sich in zwei verschiedenen Datenbanktabellen, die eine davon ist in der untersuchten Versicherung selbst programmiert worden und die andere wurde von SAP mitgeliefert.

Die Liste soll unter anderem darüber informieren, welche Vorauszahlungen noch offen sind. Dafür empfiehlt sich die Verwendung eines weiteren von SAP mitgelieferten Funktionsbausteins, der die Funktion, offene Posten aus einer Datenbank zu selektieren, bereits enthält und performant arbeitet. [01]

2. Hintergründe und Vorwissen

2.1 Entwicklungsablauf nach dem ASAP-Prinzip

Zum Entwickeln und Einführen neuer Programme wurde von SAP-Beratern die Methode Accelerated^[1]SAP (ASAP) entwickelt. Sie basiert auf dem Wissen und den Erfahrungen aus vielen Einführungsprojekten und bezieht auch bereits bestehende Vorgehenskonzepte und Einführungsmethoden mit ein. Ein ASAP-Projekt erstreckt sich über folgende fünf Phasen:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Phasen eines ASAP-Projekts

- Projektvorbereitung:Die Entscheidungsträger legen klare Projektziele und eine effiziente Vorgehensweise fest und stellen das Projektteam und sein Arbeitsumfeld zusammen.

- Konzept:Nach der Formulierung des Projektziels, das bewusst lösungsneutral gehalten werden soll, beginnt die Suche nach Lösungsmöglichkeiten für die Aufgabenstellung. Es wird ein Konzept entwickelt, das einen konkreten Lösungsweg beschreibt.

- Implementierung:Das Konzept wird umgesetzt.

- Produktionsvorbereitung:In dieser Phase erfolgt die endgültige Vorbereitung des Systems auf die Produktivphase. Dazu gehören beispielsweise Tests und Benutzerschulungen.

- Produktivstart:Das Projekt wird abgeschlossen mit dem so genannten Go-Live, bei dem das System in den Produktivzustand gesetzt wird.

Bei der Erstellung des Konzepts und der anschließenden Implementierung des IKS wurde das ASAP-Prinzip eingehalten. Zu Beginn fanden Gespräche mit den Auftraggebern (dem Rechnungswesen und der Revision) statt und es wurde definiert, welche Informationen bzw. Felder die Auswertungsliste des IKS haben soll. Nach diesen Vorbereitungen folgte die zweite Phase mit der vorangegangenen Arbeit und der Erstellung des Konzeptes. In dieser Arbeit wird die dritte Phase, die Implementierung beschrieben. Auch während dieser Phase besteht der Kontakt zu den Auftraggebern. Die betroffenen Mitarbeiter des Rechnungswesens, werden regelmäßig über den aktuellen Stand der Implementierung informiert und Unklarheiten und offene Fragen werden mit ihnen besprochen und geklärt. Nach der Implementierung wird das IKS dem Rechnungswesen zum Testen überlassen, womit die fünfte Phase des Projekts beginnt. Nach ausreichendem Testen werden eventuell aufgetretene Fehler beseitigt und das IKS in den Produktivzustand gesetzt.

2.2 Grundlagen für die ABAP-Programmierung

Da das IKS im SAP-Umfeld aufgebaut wird, wird für die Implementierung die Programmiersprache ABAP verwendet. ABAP steht für Advanced Business Application Programming und wurde für die Programmierung von kommerziellen Anwendungen im SAP-Umfeld entwickelt. In diesem Abschnitt werden die SAP Entwicklungsumgebung und ihr Einstiegswerkzeug als Grundlagen für die ABAP-Programmierung vorgestellt und näher erläutert.

2.2.1 Repository

Die betriebswirtschaftliche Standardsoftware R/3 von SAP, die die Gebiete Rechnungswesen, Logistik und Personalwirtschaft in einem Unternehmen unterstützt, besteht aus drei verschiedenen Ebenen: die Datenbankschicht, die Applikationsschicht und die Präsentationsschicht (siehe Anhang 2). Die Applikationsschicht enthält die ABAP-Laufzeitumgebung und führt den Großteil der Anwendungslogik des SAP-Systems aus. Die Logik, die zur Aufbereitung von Benutzeroberflächen für die Endanwender nötig ist, ist in der Präsentationsschicht enthalten. Die Datenbankschicht beinhaltet ein relationales Datenbanksystem, in dem neben Anwendungsdaten auch Objekte der Applikationsschicht (z.B. Programme) gespeichert werden. Diese Objekte werden in einem separaten Bereich der Datenbank, dem so genannten Repository gespeichert. Dort gibt es eine vordefinierte hierarchische Gliederung der Objekte. Die oberste Gliederungsebene bilden die Anwendungskomponenten (z.B. FI^[2]). Diese können geschachtelt werden und wiederum andere Komponenten enthalten. So ist z.B. die Komponente FS-CD^[3]in der Komponente FS^[4]angesiedelt. Komponenten können aber nicht nur andere Komponenten beinhalten, sondern auch Pakete, die zur Organisation von Entwicklungsobjekten dienen (siehe Abbildung 2). In den Paketen sind Repository-Objekte, wie z.B. Funktionsbausteine, Programme und Tabellendefinitionen enthalten. Somit sind alle Repository-Objekte Teil eines Pakets.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Aufbau des R/3-Repository[04]

Bei einem Programmstart wird zuerst das ABAP-Programm aus dem Repository geladen und in der ABAP-Laufzeitumgebung ausgeführt. Erst im Anschluss beginnt die Verarbeitung des ABAP-Codes. [int02]

2.2.2 ABAP-Workbench und Object Navigator

Die Entwicklungsumgebung für ABAP-Programme und all ihre Komponenten ist die so genannte ABAP-Workbench. Hier sind alle Werkzeuge zusammengefasst, die für die Anwendungsentwicklung erforderlich sind (siehe Anhang 3). Die Workbench ist in jedem ABAP-basierten System vorhanden und ist selbst vollständig in ABAP programmiert. Um mit ihr Workbench arbeiten zu können, benötigt man eine entsprechende Berechtigung als Entwickler.

Die Werkzeuge der ABAP-Workbench können alle separat aufgerufen werden, jedoch empfiehlt sich der Zugang über den Object Navigator, ein Einstiegswerkzeug, das zur zentralen Bearbeitung von Repository-Objekten dient. Der Object Navigator zeigt Repository-Objekte als Knoten verschiedener Baumdarstellungen, wie z.B. Repository- Browser, Repository-Infosystem oder Erweiterungsinfosystem. Der Zugang zu den Repository-Objekten über den Repository-Browser ist über so genannte Objektlisten organisiert. Eine Objektliste wird nach ihrem Typ ausgewählt, z.B. Paket oder Programm. Der Object Navigator kann über die Transaktion SE80 aufgerufen werden. Eine Transaktion bezeichnet eine vom Benutzer aufrufbare Funktion und hat immer einen vierstelligen Namen bestehend aus einem Buchstaben optional gefolgt von weiteren Buchstaben oder Ziffern. [03]

2.3 Grundlegende ABAP-Sprachelemente

Nachdem im vorherigen Abschnitt die Grundlagen für die ABAP-Programmierung vorgestellt wurden, wird im folgenden Abschnitt näher auf grundlegende Sprachelemente eingegangen, die später bei der Implementierung verwendet werden. Die allgemeine Syntax betreffend bestehen ABAP-Befehle aus einzelnen Sätzen, wobei jeder Satz mit einem Schlüsselwort eingeleitet und mit einem Punkt beendet wird. Es wird nicht zwischen Groß- und Kleinschreibung unterschieden. Die Großschreibung von Schlüsselwörtern erhöht jedoch die Übersichtlichkeit.

2.3.1 Datenobjekte und Datentypen

Die ABAP-Elemente eines Verarbeitungsblocks arbeiten mit Daten, die im Arbeitsspeicher eines Programms abgelegt sind. Externe Daten wie Eingaben auf der Benutzeroberfläche oder Daten aus der Datenbank müssen für eine Verarbeitung mit ABAP-Anweisungen immer in den Arbeitsspeicher eines Programms transportiert werden. Der Abschnitt im Arbeitsspeicher, dessen Inhalt von ABAP-Anweisungen adressiert und interpretiert werden kann, wird als Datenobjekt bezeichnet. Wenn der Inhalt eines Datenobjekts über die Laufzeit eines Programms bestehen bleiben soll, muss er vor Programmende persistent gespeichert werden.

Die wichtigste Anweisung für die Deklaration eines Datenobjekts ist DATA. Sie deklariert eine Variable^[5]mit beliebigem Datentyp, z.B.:

DATA text TYPE string. à Deklaration einer Variable vom Typ String mit dem Namentextzur Speicherung und Darstellung von textuellem Inhalt

Das deklarierte Datenobjekt ist innerhalb des aktuellen Kontextes ab dieser Stelle sichtbar. Sein Name und die technischen Typeigenschaften sind für die Dauer seiner Existenz festgelegt. [02]

Der Datentyp eines Datenobjekts wird mit der Anweisung TYPE definiert. Er bestimmt, wie die Daten im Speicher abgelegt werden, und er zeigt einer ABAP-Anweisung, wie sie mit den Daten umgehen muss. Datentypen reflektieren die Tatsache, dass es verschiedene Arten von Daten für verschiedene Verwendungszwecke gibt, z.B. zeichenartige Daten zur Speicherung und Darstellung von textuellen Inhalten und numerische Daten für Zahlen. Die möglichen Datentypen sind in drei Gruppen unterteilt[int02]:

- Elementare Datentypen: Sie werden immer durch einen von zehn eingebauten ABAP-Typen spezifiziert. (siehe Anhang 5 und 6)
- Komplexe Datentypen: Sie sind aus beliebigen anderen Datentypen zusammengesetzt und erlauben die Verwaltung und Bearbeitung von semantisch zusammengehörigen Datenmengen unter einem Namen. Es gibt keine eingebauten komplexen Datentypen, sie müssen aus vorhandenen Typen selbst konstruiert werden.
- Referenztypen: Sie beschreiben Datenobjekte, die Referenzen auf andere Objekte enthalten.

2.3.2 Komplexe Datentypen

Zu den komplexen Datentypen gehören strukturierte Datentypen. Das bedeutet, sie sind nicht elementar, sondern setzen sich aus einer Folge anderer Datentypen zusammen und stellen den Aufbau komplexer Datenobjekte wie eine Art Bauplan dar. Strukturdefinitionen werden nie auf der Datenbank erstellt, sie werden nur in ABAP-Programmen und anderen Repository-Objekten verwendet. Ein Datenobjekt eines strukturierten Datentyps wird auch einfach als Struktur bezeichnet. Es kann auf eine gesamte Struktur oder auf ihre einzelnen Komponenten zugegriffen werden. Es folgt ein Beispiel für eine Strukturdefinition:

TYPES: BEGIN OF strukturtyp,

- komponente_1 TYPE typ,
- komponente_n TYPE typ,
- END OF strukturtyp.

Neben Strukturen sind interne Tabellen der zweite komplexe Datentyp. Sie bieten die Möglichkeit, dynamische Datenmengen im Arbeitsspeicher von ABAP zu speichern. Dabei werden die Daten zeilenweise im Speicher abgelegt, wobei jede Zeile die gleiche Struktur hat. Interne Tabellen werden immer dann verwendet, wenn Datenmengen einer festen Struktur programmintern verarbeitet werden. Sie können verschiedene Tabellenarten haben, die definieren, wie ABAP auf einzelne Tabellenzeilen zugreift. Es gibt folgende Tabellenarten[int02]:

- Standard-Tabellen:Es wird intern ein linearer Index gepflegt. Der Zugriff auf die Daten kann entweder über diesen Tabellenindex oder über den Tabellenschlüssel erfolgen. Beim Schlüsselzugriff hängt die Antwortzeit linear von der Anzahl der Tabelleneinträge ab. Der Schlüssel einer Standard-Tabelle ist immer nicht eindeutig.
- Sortierte Tabellen:Sie werden immer nach dem Schlüssel sortiert abgespeichert. Auch hier wird intern ein Index gepflegt. Der Zugriff kann über den Tabellenindex oder den Schlüssel, der eindeutig oder mehrdeutig sein kann, erfolgen. Beim Schlüsselzugriff hängt die Antwortzeit logarithmisch von der Anzahl der Tabelleneinträge ab.
- Hash-Tabellen:Es wird kein Index gepflegt. Der Zugriff ist nur über den Schlüssel, der eindeutig sein muss, möglich. Dabei ist die Antwortzeit konstant und hängt nicht von der Anzahl der Tabelleneinträge ab.

Eine sortierte Tabelle mit eindeutigem Schlüssel wird z.B. folgendermaßen definiert:

TYPES: BEGIN OF example,

- column1 TYPE i,

- column2 TYPE i,

- column3 TYPE i,

- END OF example.

TYPES itab TYPE SORTED TABLE OF example WITH UNIQUE KEY column1.

2.3.3 Feldsymbole

Feldsymbole sind Platzhalter bzw. symbolische Namen für bestehende Felder. Ein Feldsymbol reserviert keinen physischen Platz für ein Feld, sondern zeigt auf ein beliebiges Datenobjekt. Das Datenobjekt, auf das ein Feldsymbol zeigt, wird ihm nach seiner Deklaration zur Laufzeit des Programms zugewiesen. Wird in einem Programm ein Feldsymbol angesprochen, wird dadurch immer das Feld, welches dem Feldsymbol zugewiesen ist, adressiert. Somit sind Feldsymbole vergleichbar mit Zeigern. Sie können entweder mit oder ohne Typangaben angelegt werden. Ohne Typangaben übernimmt das Feldsymbol alle technischen Eigenschaften des zugewiesenen Feldes. Die Vorteile von Feldsymbolen liegen darin, dass sie eine große Flexibilität bei der Adressierung von Datenobjekten ermöglichen. Zur Deklaration von Feldsymbolen wird die Anweisung FIELD-SYMBOLS <field-symbol> verwendet. [03]Die spitzen Klammern sind immer ein Bestandteil des Namens und müssen im Programm angegeben werden, z.B.:

FIELD-SYMBOLS <fs> TYPE ANY TABLE. à Feldsymbol, das alle Tabellenarten umfasst.

2.4 Entwicklungsorganisation und Transportwesen

Das Transportwesen ermöglicht es, Repository-Objekte zwischen verschiedenen Systemen bzw. Systemstufen zu transportieren. Eine SAP-Systemlinie besteht meist aus drei Systemen, nämlich Entwicklung, Test/Qualitätssicherung und zum Schluss Produktion. Um Objekte zwischen den einzelnen Systemen bewegen zu können, werden so genannte Transportaufträge verwendet. Sie beinhalten Referenzen auf Repository-Objekte. Alle Änderungen an einem System, die auf ein Folgesystem übertragen werden sollen, müssen einem Transportauftrag zugeordnet werden. Nach der Freigabe des Transportauftrags werden durch das Transport Management System (TMS) alle Objekte in diesem Auftrag in das Zielsystem transportiert (siehe Abbildung 3).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Transportauftrag[04]

Grundsätzlich wird zwischen zwei Typen von Transportaufträgen unterschieden, zum einen die Customizing-Aufträge (Transport von Einträgen in Customizing-Tabellen) und zum anderen die Workbench-Aufträge (Transport von Repository-Objekten). Jeder Transportauftrag wird von einem Benutzer verwaltet, meistens vom Projektleiter bzw. von der Person, die für die Entwicklung verantwortlich ist. Einem Auftrag können mehrere Mitarbeiter zugeordnet werden, die jeweils eine eigene Aufgabe in diesem Auftrag erhalten. Jede Aufgabe enthält die Objekte, die der jeweilige Mitarbeiter angelegt bzw. geändert hat. Am Ende der Bearbeitung muss jeder Mitarbeiter seine Aufgabe freigeben. Erst wenn alle Teilaufgaben freigegeben sind, kann der Projektleiter den Auftrag freigeben und transportieren. [04]

In dem untersuchten Versicherungsunternehmen gibt es der SAP-Systemlinie entsprechend drei Systeme: das Entwicklungssystem NVT, das System NVQ für Test und Qualitätssicherung und die Produktion NVP. Das KürzelNVsteht dabei fürNichtversicherungstechnik. Dazu gehören in der Versicherung alle Systeme, die branchenübergreifend sind und nicht speziell nur für das Versicherungsgeschäft benötigt werden.

Das System NVQ besitzt produktionsnahe Daten. In diesem System werden Neuentwicklungen und Änderungen für die Freigabe in die Produktion getestet. Das NVQ System soll immer einen Entwicklungsstand haben, der identisch ist zum Produktionssystem NVP. Importe in das NVP Produktivsystem erfolgen nur nach vorhergegangenen Tests und Freigabe durch die jeweiligen Auftraggeber.

3. Implementierung

3.1 Entwicklungsrichtlinien und Namenskonventionen

Bei der Definition von Variablen, Strukturen und internen Tabellen müssen die Entwicklungsrichtlinien und Namenskonventionen der Versicherung eingehalten werden. Alle ABAP-Programme sollen einen einheitlichen Aufbau haben. Unter anderem soll derProgrammkopfeine kurze funktionale Beschreibung, einen Verweis auf externe Dokumentation und eine Änderungshistorie enthalten, z.B.:

Abbildung in dieser Leseprobe nicht enthalten

Bei der Definition von Daten innerhalb eines ABAP-Programms sollen eindeutige Namen mit Beziehung zur Verwendung vergeben werden, um eine bessere Lesbarkeit und ein einfacheres Zurechtfinden in Programmen zu gewährleisten. Für die Datendefinition in der untersuchten Versicherung ist folgendes zu beachten:

- Namen für interne Tabellen, Typen, Konstanten und Selektionsparameter müssen jeweils mit bestimmten Buchstaben und einem Unterstrich anfangen.
- Der Bindestrich darf nicht in den Namen vorhanden sein. Der Bindestrich ist nur für die Identifizierung von Strukturfeldern und Unterstrukturen vorgesehen.
- In den Objektbezeichnungen sind keine Umlaute zugelassen.
- Lokale Deklarationen sollen mit dem Präfixlbeginnen.

Die folgende Tabelle zeigt die Namenskonventionen für programminterne Objekte, die für das IKS verwendet werden, im Überblick:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Namenskonventionen

3.2 Verwendete Tabellen

Die Informationen für die Auswertungsliste in den Datenbanktabellen DFKKOP und /"Name der Versicherung"^[6]/T_CD_VZAHLP enthalten. Die Tabelle DFKKOP enthält alle Positionen eines Kontokorrentbelegs und die Tabelle /xxx/T_CD_VZAHLP enthält alle Einzelpositionen einer Vorauszahlung. Bei der ersten Tabelle handelt es sich um eine von SAP definierte Tabelle, und die zweite ist eine Eigenentwicklung der untersuchten Versicherung, was man an ihrem Namen erkennt. Der Kundennamensbereich der Versicherung beginnt nämlich mit /xxx/. Wird dieser Bereich verwendet, werden diese Objekte während des Einspielens eines neuen Entwicklungsstands nicht durch SAP-Objekte überschrieben. DasTsteht fürTabelle,CDfür die gleichnamige Komponente undVZAHLPfürVorauszahlungspositionen.

Um die Daten aus den beiden Tabellen im Report miteinander zu verbinden und in einer Zeile der Auswertungsliste auszugeben, wird am Anfang des Reports eine programmlokale Struktur definiert mit den benötigten Feldern aus den beiden Tabellen. Die Definition der Struktur ty_vzahlp sieht folgendermaßen aus:

Abbildung in dieser Leseprobe nicht enthalten

In Abbildung 5 wird die Bedeutung der Felder genannt und gezeigt, aus welcher Tabelle ihre Daten ausgelesen werden:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Felder der Auswertungsliste

Alle Informationen bis auf die offenen Beträge sind also in /xxx/T_CD_VZAHLP enthalten. Sie müssen für das IKS mit den entsprechenden offenen Beträgen aus DFKKOP zusammengeführt werden.

Auf Basis der oben gezeigten Struktur werden eine interne Tabelle und eine Variable vom Typ einer Zeile der internen Tabelle definiert:

Abbildung in dieser Leseprobe nicht enthalten

So eine Variable wird auch als Work Area bezeichnet und ist die einzige Schnittstelle zwischen dem Programm und der internen Tabelle. Mittels der Work Area können Datensätze in die interne Tabelle eingefügt, verändert, gelöscht und ausgelesen werden.

3.3 Vorauszahlungsprozess aus Datenbanksicht

In der vorherigen Praxisarbeit wurde bereits der Ablauf des Prozesses für manuelle Vorauszahlungen beschrieben. In diesem Abschnitt wird dieser Prozess im Hinblick auf die Daten, die während dieses Prozesses entstehen, genauer betrachtet.

Die ersten Daten entstehen, sobald der erste Teilprozess für manuelle Vorauszahlungen abgeschlossen ist, also nachdem die manuelle Vorauszahlung von einem Sachbearbeiter des Vertriebs im von der untersuchten Versicherung eigenentwickelten Erfassungsdialog eingetragen und anschließend für den Freigabedialog freigegeben wurde. Jetzt entsteht ein Datensatz in der Tabelle /xxx/T_CD_VZAHLP. Er ist so aufgebaut, dass er mehrere Felder für Teilvorgänge und die dazugehörigen Beträge und Fälligkeitsdaten enthält (siehe Abbildung 6).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Tabelle /xxx/T_CD_VZAHLP

In dem ersten Teilvorgangsfeld einer Vorauszahlung (TVORG_01) ist entweder das Kürzel VZK4 oder VZK5 eingetragen. Sie stehen für die kreditorische Buchung einer Vorauszahlung, also für den Betrag, der von dem Konto der Versicherung abgezogen wird und unterscheiden sich dadurch, dass VZK4 für eine Vorauszahlung auf Basis eines Flottenvertrags steht, während VZK5 zeigt, dass die Vorauszahlung zu einem Einzelvertrag gehört. Entsprechend wird in dem ersten Betragsfeld (BETRH_01) die Höhe dieser kreditorischen Buchung eingetragen und im ersten Fälligkeitsdatums-Feld (FAEDN_01) das Datum, an dem der Betrag von der Versicherung überwiesen wird. Im zweiten Teilvorgangsfeld desselben Datensatzes (TVORG_02) steht entweder das Kürzel VZD4 oder VZD5 und im zweiten Fälligkeits-Feld (FAEDN_02) das Datum, an dem die Vorauszahlung an die Versicherung zurückgezahlt werden muss bzw. mit den angefallenen Provisionen des Maklers verrechnet wird. Das entspricht also der debitorischen Buchung der Vorauszahlung. Die beiden Buchungen haben denselben Betrag, die kreditorische allerdings mit negativem Vorzeichen, da sie einen Aufwand für die Versicherung darstellt. Das dritte Teilvorgangsfeld (TVORG_03) wird benötigt, falls die Versicherung Zinsen für die Vorauszahlung verlangt. In diesem Fall steht im TeilvorgangsfeldZinsund im dritten Betragsfeld (BETRH_03) die Höhe dieser Zinsen. Verlangt die Versicherung keine Zinsen für eine Vorauszahlung bleiben die Felder TVORG_03 und FAEDN_03 leer und in BETRH_03 steht ein Betrag von 0.

Ein weiteres wichtiges Feld des Datensatzes ist das Feld Freigabestatus (FREIGABE_STAT). Es gibt Auskunft darüber, ob die Freigabe für eine Auszahlung erteilt wurde und die Vorauszahlung schon gebucht wurde und kann folgende Werte mit folgenden Bedeutungen haben:

- 0 = Erfassung

- 1 = Erfassung abgeschlossen

- 2 = Freigabe erteilt

- 3 = gebucht

Der erste persistente Datensatz entsteht somit nach dem ersten Teilprozess und hat den Freigabestatus 1. Nach jeder korrekt erfassten Vorauszahlung entsteht genau ein Datensatz in der Tabelle /xxx/T_CD_VZAHLP (siehe Abbildung 7).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Teilprozess Vertrieb

Als nächstes folgt der zweite Teilprozess im Rechnungswesen. Ist eine Vorauszahlung, die einem Sachbearbeiter im Rechnungswesen im eigenentwickelten Freigabedialog zur Anzeige gebracht wird, nicht korrekt, wird ihr Status aufin Bearbeitungzurückgesetzt. Das hat zur Folge, dass der entsprechende Datensatz in der Tabelle /xxx/T_CD_VZAHLP geändert wird. Das Feld FREIGABE_STAT hat nun nicht mehr den Wert 1, sondern den Wert 0.

Ist die Vorauszahlung jedoch korrekt und wird von dem Sachbearbeiter im Freigabedialog freigegeben, ändert sich der Freigabestatus auf den Wert 2. Nach der Freigabe wird eine Buchung erzeugt, für die mindestens zwei und höchstens drei neue Datensätze in der Tabelle DFKKOP entstehen. Der erste Datensatz repräsentiert die kreditorische Buchung mit dem entsprechenden Teilvorgängen VZK4 oder VZK5 und einem Betrag mit negativem Vorzeichen. Der zweite entstehende Datensatz ist die entsprechende debitorische Buchung mit den Teilvorgängen VZD4 oder VZD5 und einem positiven Betrag. Ein dritter Datensatz mit dem TeilvorgangZinsentsteht nur in dem Fall, wenn Zinsen für die Vorauszahlung verlangt werden. Außerdem wird durch die Buchung der Vorauszahlung das Feld FREIGABE_STAT des entsprechenden Datensatzes in der Tabelle /xxx/T_CD_VZAHLP auf den Wert 3 geändert. Damit ist die Erfassung und Buchung der Vorauszahlung vollständig abgeschlossen.

Bei der Freigabe werden keine Sperren gesetzt. Ist eine Vorauszahlung einmal freigegeben, ändert sich dauerhaft ihr Freigabestatus auf den Wert 3 und sie kann nicht erneut im Freigabedialog freigegeben werden. Für den seltenen Fall, dass mehrere Mitarbeiter gleichzeitig denselben Datensatz freigeben wollen, ist nur die Aktivität desjenigen Mitarbeiters relevant, der am schnellsten ist.

Abbildung 8 zeigt zusammenfassend welche Auswirkungen der zweite Teilprozess auf die Persistenzschicht hat.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Teilprozess Rechnungswesen

Diese Datenbank-Aktualisierungen wurden bereits zu einem früheren Zeitpunkt von Mitarbeitern der untersuchten Versicherung erstellt und müssen nicht im Rahmen dieser Projektarbeit implementiert werden. Für die beiden Datenbanktabellen gibt es ein Berechtigungskonzept. Der Zugriff wird durch Berechtigungsobjekte geregelt. Ein Berechtigungsobjekt fasst bis zu zehn Berechtigungsfelder zusammen, die in UND-Verknüpfung geprüft werden. Bei einer Berechtigungsprüfung vergleicht das System die Werte zu den einzelnen Feldern eines Berechtigungsobjektes, die dem Benutzer über sein Berechtigungsprofil zugeordnet sind, mit den Werten, die zur Ausführung einer Aktion im Programm vorgegeben sind. Um die Berechtigungsprüfung erfolgreich zu durchlaufen, muss der Benutzer die Prüfung für jedes im Berechtigungsobjekt enthaltene Feld "bestehen". Diejenigen Mitarbeiter, die die Berechtigungsobjekte besitzen, den Erfassungs- und Freigabedialog für Vorauszahlungen aufzurufen, haben auch die Berechtigung auf die Tabellen /xxx/T_CD_VZAHLP und DFKKOP zuzugreifen. Wir im Laufe des Vorauszahlungsprozesses ein neuer Datensatz in die Tabelle DFKKOP geschrieben, geschieht dies über einen von SAP mitgelieferten Schreibbaustein. Er wird im selbst programmierten Freigabedialog aufgerufen und erstellt für jede freigegebene Vorauszahlung zwei bis drei neue Datensätze (abhängig davon, ob Zinsen für die Vorauszahlungen verlangt werden) in der Tabelle DFKKOP.

Diese Daten, die beim Erfassen und Buchen von Vorauszahlungen entstehen, sollen durch ein IKS kontrolliert und auf einer Auswertungsliste zusammengefasst werden, um Fehler zu vermeiden, Betrug vorzubeugen und einen Überblick über die Vorauszahlungen zu erhalten.

[...]

^[1]deutsch:beschleunigt

^[2]Financial Accounting

^[3]Financial Services – Collections and Disbursements

^[4]Financial Services

^[5]Benanntes Datenobjekt, dessen Wert zur Laufzeit eines ABAP-Programms geändert werden kann

^[6]Im Folgenden durchxxxersetzt