Design und Implementierung einer Software für Fördervereine: Schwerpunkt Kassenbuch und Projektverwaltung

Inhaltsverzeichnis

Zusammenfassung

Abstract

1 Einleitung
1.1 Aufgabestellung und Motivation
1.2 Aufbau der Arbeit

2 Softwarebeschreibung
2.1 Benutzeranforderungen
2.2 Systemanforderungen
2.3 Funktionalität und Benutzung der Software

3 Entwurf
3.1 Softwarearchitektur
3.2 Klassendiagramm
3.3 Datenbankmodell
3.4 Schnittstelle zur Mitgliederverwaltung
3.5 Datenaustauschformate im Bankverkehr (Banking Communication Standards)
3.5.1 DTAUS
3.5.2 MT940
3.5.3 SEPA

4 Implementierung
4.1 Werkzeuge und Konzepte
4.2 Graphische Benutzeroberfläche
4.2.1 Observer-Observable
4.2.2 MVC
4.2.3 Layout-Manager
4.3 Anwendungsschicht und Datenhaltung der Software
4.4 Schnittstellen zur Außenwelt
4.4.1 Kontoauszug einlesen
4.4.2 Bankaufträge erstellen
4.4.3 PDF-Dateien erstellen
4.5 Integration und Test der Software

5 Fazit und Ausblick
5.1 Offene Punkte

Literatur

Anhang
Aufbau einer DTA-Datei
SEPA Beispiel
Klassenübersicht
CD
Abbildungsverzeichnis
Quellcodeverzeichnis
Eidesstattliche Erklärung

Zusammenfassung

Im Rahmen dieser Bachelorarbeit wird in Zusammenarbeit mit Leonid Oldenburger (s. Bachelorarbeit „ Design und Implementierung einer Software für Fördervereine: Schwerpunkt Mitglieder- und Spenderverwaltung“) eine Software entwickelt und implementiert, die für die Verwaltung von kleineren bis mittleren gemeinnützigen Fördervereinen eingesetzt werden kann.

Das in dieser Arbeit entstehende Softwaremodul wird zur Verwaltung von Finanzbereich eines Vereins verwendet, wobei der Schwerpunkt auf der Buchführung (inkl. Geldgeschäftsverkehr mit einer Bank), Jahresabschluss und Projektverwaltung liegt.

Abstract

This bachelor thesis produces in collaboration with the bachelor thesis of Leonid Oldenburger (look “Design and implementation of software for development associations: Focal point is the member- and bounty administration”) a software, which is available for small- and medium-sized charitable development associations.

The resulting software module of this bachelor thesis is in use for the administration of financial sphere of an association; however the focal points are the accountancy (inc. banking communication), the annual financial statement and the project administration.

1 Einleitung

Das Aufgabenfeld des Kassenwarts in zumeist gemeinnützigen Fördervereinen umfasst verschiedene Tätigkeiten. Zum einen muss der Kassenwart das Vereinskonto führen und alle Einnahmen und Ausgaben des Vereins in einem Kassenbuch eintragen. Periodisch müssen die Mitgliedsbeiträge eingezogen werden, und Informationspflichten gegenüber dem Finanzamt und dem Vereinsvorstand müssen erfüllt werden. Dazu wird ein Jahresabschluss erstellt. Zum anderen müssen die Einnahmen und Ausgaben klassifiziert und entsprechenden Projekten und Buchungsbereichen zugeordnet werden.

Alle diese Aufgaben sind zeitaufwendig und fehleranfällig. Versucht der Kassenwart zum Beispiel, einen Mitgliedsbeitrag einzuziehen und macht einen Fehler in der Kontonummer oder in der Bankleitzahl, so wird der Lastschriftauftrag von der Bank nicht ausgeführt. Außerdem entstehen dadurch verursachte Kosten, die der Verein zu tragen hat. Auch die gesetzlichen Vorschriften, die die Buchführung des Vereins und die Erstellung eines Jahresabschlusses betreffen und im Handelsgesetzbuch (HGB) kodifiziert sind, muss der Kassenwart einhalten. Sämtliche Geschäftsvorgänge werden ferner von einem Kassenprüfer kontrolliert.

Um den Alltag des Kassenwarts zu erleichtern und Klarheit und Übersichtlichkeit in die Vereinsbuchführung zu bringen, ist im Rahmen dieser Bachelorarbeit ein Teil einer Vereinsverwaltungssoftware mit dem Schwerpunkt Buchführung, Jahresabschluss und Projektverwaltung entstanden.

1.1 Aufgabestellung und Motivation

Das Ziel dieser Arbeit ist es, in Zusammenarbeit mit Leonid Oldenburger ein Softwareprodukt zur Verwaltung eines gemeinnützigen Fördervereins zu entwickeln und zu implementieren. Herr Oldenburger ist für die Softwarekomponenten „Mitgliederverwaltung“ und „Vereinskonfiguration“ zuständig.

Als Auftraggeber treten zwei in Deutschland fungierende gemeinnützige Fördervereine auf. Einer der Vereine löst die oben beschrieben Aufgaben mithilfe von einem Tabellenkalkulationsprogramm, der zweite Verein hat bis jetzt keine EDV-gestützte Lösung im Einsatz. Die durch die Auftraggeber durchgeführte Analyse des Angebots an Vereinsverwaltungssoftware hat ergeben, dass es zurzeit kein Produkt gibt, das allen Anforderungen genügt. In keiner der betrachteten Vereinsverwaltungssoftware ist beispielsweise eine Funktion zur Förderprojektverwaltung implementiert.

1.2 Aufbau der Arbeit

Die vorliegende Arbeit besteht aus fünf Kapiteln, die im Wesentlichen einzelnen Phasen des Softwareentwicklungsprozesses nach dem Wasserfallmodell entsprechen.

Nach der Einleitung werden in Kapitel 2 an die Vereinsverwaltungssoftware gestellte Anforderungen analysiert. Die Anforderungen unterteilen sich in die Benutzer- (oder funktionale) Anforderungen und in die Systemanforderungen. Zum Schluss wird im zweiten Kapitel ein Einblick in die Benutzung der Software gegeben.

Im dritten Kapitel, das der Entwurfsphase des Wasserfallmodells entspricht, wird ein Softwareentwurf erstellt. Zunächst werden die Softwarearchitektur, das Klassendiagramm und das Datenbankmodell der Software beschrieben. Danach kommt es zu Definition der Schnittstellen zwischen beiden Modulen der Vereinsverwaltungssoftware. Am Ende des Kapitels werden dem Leser drei Formate vorgestellt, die beim Datenaustausch im Bankverkehr verwendet werden.

Im vierten Kapitel wird die Implementierung der Software erläutert. Zuerst werden die bei der Implementierung verwendete Programmier-Werkzeuge und Konzepte aufgelistet, in weiteren Unterkapiteln wird die Implementierung einzelner Bestandteile der Software ausführlich beschrieben.

Die Arbeit wird mit Kapitel 5 „Zusammenfassung und Ausblick“ abgeschlossen. In diesem Kapitel werden technische Daten der Software erörtert, sowie einige offene Punkte genannt. Auch die zukünftigen Erweiterungsmöglichkeiten der in dieser Arbeit erstellten Software werden in Kapitel 5 behandelt.

2 Softwarebeschreibung

Der Zahlungsmittelfluss in einem gemeinnützigen Förderverein sieht folgendermaßen aus: Die Geldeinnahmen in Form von Mitgliedsbeiträgen und Spenden, Einnahmen aus verschiedenen Veranstaltungen sowie Zinserträge und Dividenden werden dem Vereinskonto gutgeschrieben. Den Einnahmen stehen – nicht unbedingt in gleicher Höhe – die Geldausgaben des Vereins gegenüber. Zu den Ausgaben zählen unter anderem projektbezogene Auszahlungen (z.B. Unterstützung einer Schule in Afrika), Verwaltungskosten des Vereins (z.B. Telefon- und Stromrechnungen) und andere Ausgaben (z.B. Einkauf von Waren und Kontoführungsgebühren).

Um all diese Geldbewegungen zu erfassen und unterschiedlichen Buchungsbereichen zuzuordnen soll ein Softwareprodukt zum Einsatz kommen. Die Softwareanforderungen wurden von den Auftraggebern als ein unvollständiger Katalog von Anwendungsfällen vorbereitet und zur Verfügung gestellt. Nach einer umfassenden Analyse der Anwendungsfälle, die in Zusammenarbeit mit den Auftraggebern stattgefunden hat, wurden Anforderungen an die Software identifiziert, die in den folgenden Unterkapiteln beschrieben sind.

2.1 Benutzeranforderungen

1. Kontoauszug einlesen und bearbeiten.

Ein Kontoauszug in MT940-Format (Kapitel 3.5.2) soll eingelesen werden können. Da unterschiedliche Kreditinstitute ihren Kunden Kontoauszüge in unterschiedlichen Formaten (z.B. CSV statt MT940) bereitstellen, soll die Software so modelliert werden, dass die Implementierung der Unterstützung diverser Formate unkompliziert und ohne großen Aufwand erfolgen werden kann.

Alle Einträge des Kontoauszuges sollen vom Kassenwart bearbeitet und im Kassenbuch vermerkt werden. Dabei kann es sich um folgende Buchungen handeln:

- Geldeingang

- Überweisung von einem Bankkonto (Spende oder Mitgliedsbeitrag)
- Einzahlung
- Einlösen einer Lastschrift (Mitgliedsbeitrag)
- Zinsen, Dividende und andere Einnahmearten.

- Geldausgang

- Überweisung auf ein Konto (Ausgabe für ein Förderprojekt)
- Auszahlung
- Lastschriftrückgabe (z.B. wenn ein Lastschriftauftrag nicht ausgeführt werden konnte)
- Kontoführungsgebühren und andere Ausgaben des Vereins

1.1 Einzahlungen verbuchen.

Falls es sich bei einer Einzahlung um einen Mitgliedsbeitrag handelt (das wird aus dem Verwendungszweck ersichtlich), dann soll dieser bei dem betreffenden Mitglied vermerkt werden. Die Mitgliedsnummer soll automatisch anhand Kontonummer und Bankleitzahl bestimmt werden. Alle Mitgliedsbeiträge werden im Kassenbuch vermerkt und dem Buchungsunterbereich „Mitgliedsbeiträge“ des Ideellen Buchungsbereichs zugeordnet (weitere Informationen über Buchungsbereiche des Vereins stehen unter „6. Jahresabschluss erstellen“).

Wenn eine Spende eingegangen ist, dann soll die ebenso einem Spender zugeordnet werden. Im Falle eines bekannten Spenders wird die Spendernummer genauso wie bei der Verbuchung eines Mit-gliedsbeitrags automatisch bestimmt. Falls eine Spende von einem bisher unbekannten (im System nicht gespeicherten Bankkonto) überwiesen wurde, dann soll es dem Kassenwart möglich sein, einen neuen Spender zu erfassen. Die Spende wird dann diesem Spender zugeordnet. Alle eingehenden Spenden werden auch im Kassenbuch des Vereins vermerkt. Außerdem sollen einzelne Spenden unterschiedlichen Förderprojekten (s. „4. Projektverwaltung“) zugeordnet werden können.

Weitere Gutschriften, die weder Mitgliedsbeträge noch Spenden darstellen, sollen im Kassenbuch vermerkt werden. Dabei sollen die Einnahmen entsprechenden Projekten und/oder Buchungsunterbereichen zugeordnet werden.

1.2 Auszahlungen verbuchen.

Auszahlungen sollen analog zu Einzahlungen bearbeitet werden:

Alle Auszahlungen sollen im Kassenbuch verbucht werden, förderprojektbezogene Ausgaben sollen bei entsprechenden Projekten vermerkt werden, andere Ausgaben sollen passenden Buchungsbereichen zugeordnet werden. Wenn es sich bei einer Ausgabe um eine Lastschriftrückgabe handelt, was bedeutet, dass ein Mitgliedsbeitrag nicht erfolgreich eingezogen werden konnte, dann wird dieser Vorfall bei dem betroffenen Mitglied vermerkt.

2. Mitgliedsbeiträge verwalten.

Eine Liste der Mitglieder, deren Mitgliedsbeträge offen sind, soll angezeigt werden. Der Kassenwart kann einen Sammellastschriftauftrag in Form einer DTAUS-Datei (Kapitel 3.5.1) erstellen. Der Bankauftrag wird danach an die Bank mittels Web-Interfaces des Online-Banking-Portals übermittelt und von der Bank ausgeführt. Bei allen Mitgliedern soll die Bezahlung des Mitgliedsbeitrags vorübergehend vermerkt werden. Der Vermerk wird genau dann aufgehoben, wenn ein Mitgliedsbeitrag wegen einer Lastschriftrückgabe dem Vereinsbankkonto nicht gutgeschrieben werden konnte. Kurz vor dem Abbuchungsdatum der Mitgliedsbeträge, das in der Programmkonfiguration festgelegt wird, soll dem Kassenwart beim Programmstart eine Erinnerung über offene Mitgliedsbeiträge angezeigt werden.

3. Zahlung tätigen.

Der Kassenwart soll einen Überweisungsauftrag erstellen können. Alle nötigen Überweisungsdaten

- Empfängername,
- Kontonummer des Empfängers,
- Bankleitzahl des Empfängers,
- Betrag,
- Verwendungszweck,
- eventuell Ausführungsdatum

soll der Kassenwart manuell eingeben. Der Auftrag soll als eine Datei im DTAUS-Format erstellt und in dem Ausgabeordner gespeichert werden. Wie im Falle eines Lastschriftauftrages, wird ein Überweisungsauftrag an das Kreditinstitut übermittelt.

4. Kassenbuchverwaltung.

Alle auf dem Vereinskonto vollzogenen Einnahmen und Ausgaben des Vereins sollen in einem Kassenbuch verbucht werden. Der Kassenwart soll die Möglichkeit haben eine Kassenbuchübersicht mit Angabe von Start- und Enddatum zu erstellen, Einzelheiten zu jeder gebuchten Zahlung anzusehen und die Übersicht in Form einer PDF-Datei zu speichern.

5. Projektverwaltung.

Der Benutzer soll unterschiedliche Förderprojekte anlegen können. Jedes Projekt soll mit einem Start- und einem Enddatum versehen werden. Es kann mehrere Unterprojekte enthalten, die wiederum untergeordnete Projekte enthalten können. Als Startdatum eines Projekts wird das Er-stellungsdatum definiert. Einem Projekt können Spenden und Ausgaben zugewiesen werden. Der Kassenwart kann ein Projekt jederzeit beenden, also das Enddatum des Projekts auf das aktuelles Datum setzen, sowie den Namen eines Projekts ändern. Einem beendeten Projekt dürfen keine Ein- oder Auszahlungen zugeordnet werden. Über alle Projekte soll eine tabellarische Übersicht mit Angabe von Projektnamen und Summen von Einnahmen und Ausgaben jedes Projekts angezeigt werden. Beendete Projekte sollen in der Projektübersicht ausgeblendet werden können.

6. Jahresabschluss erstellen.

Einnahmen und Ausgaben eines Fördervereins werden unterschiedlichen Buchungsbereichen zugeordnet. Ein gemeinnütziger Förderverein hat vier Tätigkeitsbereiche[7]:

- Ideeller Bereich
Hierunter fallen Mitgliedsbeiträge und Spenden, Schenkungen und Erbschaften, Ausgaben für Förderprojekte und Verbandsbeträge, Verwaltungskosten und Versicherungen.
- Vermögensverwaltung
Dieser Bereich enthält Zinserträge und Dividenden, Mieten und Pachten, Kontoführungsgebühren und Ausgaben für Neubauten, Instandhaltungen und Reparaturen.
- Zweckbetrieb
Der Bereich umfasst unter anderem Eintritts-, Startgelder und Meldegebühren, Ausgaben für Geräte und Veranstaltungen.
- Wirtschaftlicher Geschäftsbetrieb

Hierzu zählen alle Einnahmen und Ausgaben, die durch nicht gemeinnützige Tätigkeiten des Vereins verursacht wurden. Das sind zum Beispiel kurzfristige Verpachtung oder Vermietung, Verkauf von Waren, Werbeeinahmen, Wareneinkauf, Körperschafts- und Gewerbesteuer.

Der Kassenwart soll die Möglichkeit haben, neue Buchungsunterbereiche zu definieren. Die vom Kassenwart angelegten Unterbereiche sollen analog zu Projekten beendet (deaktiviert) werden. Nicht aktive Buchungsunterbereiche werden in der Übersicht nicht angezeigt, ihnen können keine Zahlungen zugeordnet werden können.

Am Ende jedes Jahres soll mittels Software ein Jahresabschluss erstellt werden, in dem alle Einnahmen und Ausgaben entsprechenden Buchungsunterbereichen zugeordnet sind. Die Spendeneinnahmen und Ausgaben für Förderprojekte sollen dabei nach Projekten und auch Unterprojekten gegliedert sein. Die Gliederungstiefe soll einstellbar sein. In jedem Bereich werden Einnahmen und Ausgaben aufsummiert, zum Schluss wird der Saldo des Vereins (Schlusssaldo) ermittelt. Ein Jahresabschluss soll außerdem mit dem Anfangssaldo der Periode versehen werden und in Form einer PDF-Datei am Computer gespeichert werden können.

2.2 Systemanforderungen

Die in dieser Arbeit entwickelte Vereinsverwaltungssoftware soll in erster Linie auf Computern installiert werden, die unter dem Betriebssystem Windows arbeiten. In den letzten Jahren ist die Popularität anderer Betriebssysteme gestiegen (z.B. Linux oder MacOS von Apple). Damit die Software plattformübergreifend eingesetzt werden kann, wird diese in der Programmiersprache Java implementiert.

Desweiteren soll ein Datenbankmanagementsystem zum Einsatz kommen. Die Softwaredaten werden also in einer Datenbank abgelegt.

Die Software soll später ohne großen Aufwand erweitert oder verändert werden können, deswegen soll die Software aus Teilmodulen bestehen. Die Software soll so modelliert werden, dass die Unterstützung diverser Datenaustauschformate im Bankverkehr zu einem späteren Zeitpunkt problemlos implementiert werden kann. Außerdem soll die graphische Oberfläche der Software relativ einfach und benutzerfreundlich aufgebaut sein.

2.3 Funktionalität und Benutzung der Software

Das Hauptframe des Kassenbuchsmoduls der Vereinsverwaltungssoftware ist in Abbildung 1 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Kassenbuchübersicht

Dem Benutzer wird eine Kassenbuchübersicht angezeigt, in der alle Zahlungen aus einer durch den Benutzer bestimmten Periode enthalten sind. Ist das Start- (oder das End-) Datum der Periode nicht gewählt, so werden die letzten 15 im Kassenbuch vermerkten Zahlungen angezeigt. Der Saldo des Vereins (die Summe über alle im Kassenbuch vermerkten Beträge) wird im unteren rechten Bereich angezeigt. Wenn die aktuelle Kassenbuchübersicht in Form von einer PDF-Datei gespeichert werden soll, so muss der Button „Als PDF-Datei speichern“ betätigt werden. Die erstellte PDF-Datei wird dem Benutzer angezeigt und im Export-Ordner des Programms abgelegt.

In der Übersicht der offenen Mitgliedsbeiträge (Abbildung 2) sind alle Mitglieder und Spender aufgelistet, deren Beiträge fällig sind. Durch das Betätigen des Buttons „DTAUS-Datei speichern“ wird ein Bankauftrag zum Einzug der offenen Mitgliedsbeiträge erstellt und im Export-Ordner des Programms abgelegt. Der Auftrag soll später an die Bank übermittelt werden, damit er erfüllt werden kann.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Offene Beiträge

Auf der folgenden Abbildung ist ein eingelesener Kontoauszug dargestellt. Einzelne Posten des Kontoauszugs können auf zweierlei Weise im Kassenbuch verbucht werden. Durch einen Doppelklick auf einer Tabellenzeile, die eine nicht verbuchte Zahlung enthält, wird ein neues Popup-Fenster geöffnet (Abbildung 4), in dem alle Zahlungsinformationen dargestellt sind. Alternativ dazu kann der Benutzer alle Zahlungen nacheinander verbuchen (für jede Zahlung wird der Reihe nach ein Popup-Fenster angezeigt). Nachdem alle Zahlungen verbucht werden, kann ein neuer Kontoauszug eingelesen werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Kontoauszug

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Eine Zahlung verbuchen

Eine Projektübersicht wird auf der folgenden Abbildung dargestellt. Der Benutzer kann ein Projekt beenden. Durch einen Klick mit der rechten Maustaste auf einer Zeile der Tabelle erscheint ein Popup-Menü, in dem ein Eintrag „Projekt beenden“ enthalten ist. Um ein Projekt beenden zu können, müssen alle seine Unterprojekte bereits beendet sein. Der Benutzer hat außerdem eine Möglichkeit, ein neues Projekt zu erstellen. Dazu wird der Projektname in das Feld „Name“ eingegeben, sowie der Oberprojektname gewählt. Durch einen Klick auf den Button „Erstellen“ wird das neue Projekt in die Datenbank gespeichert. Der Name des Projekts sowie dessen Startdatum erscheinen unmittelbar danach in der Projektübersicht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Projekte

Analog zu der Projektübersicht ist die Übersicht der Buchungsbereiche aufgebaut (Abbildung 6). Der Benutzer hat eine Möglichkeit einen neuen Buchungsunterbereich zu definieren. Ein Jahresabschluss im PDF-Format wird durch einen Klick auf den „Als PDF-Datei speichern“-Button erstellt. Nach der Erstellung wird der Jahresabschluss dem Benutzer angezeigt und wie – alle andere Ausgabedateien – im Export-Ordner des Programms abgelegt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Jahresabschluss

3 Entwurf

In diesem Kapitel wird der Entwurf der Vereinsverwaltungssoftware beschrieben. Zunächst wird auf die Softwarearchitektur, auf das Klassendiagramm und auf das Datenbankmodell der Software eingegangen. Schließlich werden die Datenaustauschformate im Bankverkehr erläutert.

3.1 Softwarearchitektur

Die Architektur der Vereinsverwaltungssoftware soll anhand der folgenden Abbildung, die freundlicherweise von Leonid Oldenburger zur Verfügung gestellt wurde, erläutert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Softwarearchitektur

Die Vereinsverwaltungssoftware besteht aus zwei Teilen. Der erste Teil ist das Mitgliederverwaltungsmodul, welches auch die Vereinskonfiguration und den Schriftverkehr umfasst. Dieses Modul ist von Leonid Oldenburger in seiner Arbeit ausführlich beschrieben. In der Abbildung ist das Modul heller dargestellt. Das zweite Modul – das Kassenbuchmodul – ist in vier funktionelle Komponenten aufgeteilt, die ein oder mehrere Teilmodule umfassen:

- die Komponente Kassenbuch;
- die Komponente Zahlungsverkehr. Diese Komponente enthält alle Softwaremodule, die dem Austausch von Zahlungsinformationen zwischen der Software und einer Bank dienen;
- die Komponente Projekte;
- und die Komponente Jahresabschluss.

Der Aufbau der Software weist zum einen eine Drei-Schichten-Architektur auf. Die Software ist somit auf drei Ebenen aufgeteilt und besteht aus einer Präsentationsschicht (View), einer Logikschicht und einer Datenhaltungsschicht. Zum anderen ist die Software nach dem Model-View-Controller-Programmierkonzept aufgebaut. Die Präsentationsschicht der Software wird mit deren Logikschicht (oder Anwendungsschicht) mittels eines Controllers verknüpft. Die Umsetzung des MVC-Konzepts ist im Kapitel 4.2 beschrieben.

Schnittstellen zwischen beiden Softwareteilen werden im Kapitel 3.4 behandelt.

Übersichtshalber sind die Schnittstellen zwischen der Software und der Außenwelt in der Abbildung nicht dargestellt und werden im Kapitel 4.4 erläutert.

3.2 Klassendiagramm

Wie aus den Benutzeranforderungen hervorgeht, ist eine Zahlung eine der grundlegenden Klassen der Logikschicht von Software. Ein Verein hat Geldeinnahmen und Geldausgaben, die als Ein- oder Auszahlungen auf dem Bankkonto verbucht werden und auf dem Kontoauszug erscheinen. Somit stellen Objekte der Klasse Zahlung reale Ein- oder Auszahlungen dar und haben folgende Attribute:

- das Buchungsdatum – das Datum, an dem die Zahlung auf dem Bankkonto verbucht wurde;
- den Name und Kontodaten des Auftraggebers bzw. Zahlungsempfängers;
- den Verwendungszweck;
- den Betrag
- und den Buchungsbereich – der Bereich, dem die Zahlung zugeordnet wird.

Obwohl das letzte Attribut, der Buchungsbereich, bei einer realen Zahlung nicht vorhanden ist, ist dieser trotzdem notwendig, denn jede Zahlung, die in der Datenbank der Software gespeichert wird, muss einem der Buchungsbereiche zugeordnet werden, um später beim Jahresabschluss korrekt zugeordnet zu werden.

Ein Kontoauszug, der von der Software eingelesen wird und ein Ausschnitt der realen Welt verkörpert, wird aber nicht als eine Liste von Objekten der Klasse Zahlung, sondern als eine Textdatei dargestellt. Um diese Datei in eine Liste von Zahlungen zu konvertieren ist eine weitere Klasse – der KontoAuszugReader verantwortlich. Da der Kontoauszug in unterschiedlichen Formaten vorliegen kann und die Formate sich im Laufe der Zeit ändern können, soll dieser Sachverhalt berücksichtigt werden. Deswegen ist es sinnvoll, den KontoAuszugReader nicht als eine Klasse, sondern als ein Interface zu implementieren. Der MT940Reader ist dagegen eine Klasse und konkrete Implementierung des Interfaces KontoAuszugReader.

Aus zeitlichen Gründen wird die Unterstützung anderer Formate im Rahmen dieser Bachelorarbeit nicht implementiert. Der Einsatz des Strategy Patterns gestattet es jedoch die Software auf einfache Weise um diese Funktionalität zu einem späteren Zeitpunkt zu erweitern. Dafür müssen lediglich weitere Reader (z.B. ein CSVReader zum Einlesen von Kontoauszügen im CSV-Format oder ein XMLReader für die Konvertierung von Kontoauszügen, die in Form von einer XML-Datei vorliegen) erstellt werden, die das Interface KontoAuszugReader implementieren. Dabei wird die Wahl des Formates zur Laufzeit des Programms ermöglicht (vgl. Kapitel 4.4.1).

Nachdem ein Kontoauszug von der Software eingelesen wird, müssen alle darin enthaltenen Zahlungen bearbeitet werden. Wie bereits in Kapitel 2.1 erörtert wurde, müssen die Zahlungen klassifiziert und einem der Buchungsbereiche zugeordnet werden. Die Klasse Beitrag ist von der Klasse Zahlung abgeleitet und besitzt ein weiteres Attribut – die Mitgliedsnummer. Die Klasse Spende ist ebenfalls von der Zahlung abgeleitet, verfügt aber über zwei zusätzliche Attribute:

- die Spendernummer
- und den Projektnamen.

Da jede Spende einem der Projekte zugeordnet wird, ist die Angabe des Namens eines Projekts erforderlich. Man könnte auf die Idee kommen, die Klasse Spende als Unterklasse von Beitrag und nicht als Unterklasse von Zahlung zu entwerfen. Da es aber nicht der Realität entspricht, erscheint diese Überlegung als nicht plausibel.

Ein Verein hat neben Beiträgen und Spenden andere Einnahmearten, einige davon wurden bereits in dem Kapitel 2.1 „Benutzeranforderungen“ beschrieben. Eine Einnahme, bei der es sich weder um einen Beitrag noch um eine Spende handelt, wird durch ein Objekt der Klasse Zahlung repräsentiert.

Auszahlungen sind analog zu Einzahlungen modelliert worden – alle projektbezogene Ausgaben werden als Objekte der Klasse ProjektAuszahlung dargestellt. Sonstige Ausgaben sind Objekte der Klasse Zahlung.

Das Klassendiagramm der Anwendungsschicht der Software ist in der folgenden Grafik dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Klassendiagramm der Anwendungsschicht

Attributen und Methoden von Klassen sind übersichtshalber weggelassen worden. Klassen, die für das Erstellen einer Kassenbuchübersicht sowie eines Jahresabschlusses in Form von PDF-Dateien verantwortlich sind, sind ebenso in der Grafik nicht enthalten.

An dieser Stelle soll auf die zentrale Klasse der Anwendungsschicht – das Kassenbuch – eingegangen werden. Zum einen bildet die Klasse Kassenbuch eine Schnittstelle zwischen der Datenhaltungsschicht (Interface DBManager und seiner Implementierung für eine Derby-Datenbank/JavaDB DerbyManager mit der darunterliegenden Datenbank) und der Anwendungsschicht der Software. Zum anderen stellt das Kassenbuch eine Schnittstelle zwischen dem Softwaremodul Kassenbuch und dem Softwaremodul Mitgliederverwaltung dar. Alle von der Mitgliederverwaltung benötigten Daten (z.B. Spenden oder Mitgliedsbeiträge von einem Spender/Mitglied) werden durch Aufruf von entsprechenden Methoden der Klasse Kassenbuch zur Verfügung gestellt. Die wichtigsten Methoden der Klasse Kassenbuch werden in Kapitel 4 „Implementierung“ genauer beschrieben.

3.3 Datenbankmodell

Das Volumen von Daten, mit dem das Kassenbuchmodul der Vereinsverwaltungssoftware und die gesamte Software operiert, ist ziemlich groß. So werden in dem Programm mehrere Personen erfasst (in einem kleinen Förderverein beträgt die Mitgliederanzahl um die 50 bis 100 Mitglieder, hierzu kommen noch ungefähr genauso viele Spender). Allein der Einzug von Mitgliedsbeiträgen verursacht mehrere Buchungssätze, die von der Software bearbeitet, entsprechenden Personen, Buchungsbereichen und eventuell Projekten zugeordnet und dauerhaft gespeichert werden müssen. Deswegen ist der Einsatz eines Datenbanksystems (DBS) unvermeidlich.

Innerhalb der Analyse-Phase stand die Wahl zwischen einem Objektorientierten-, einem Relationalen- und einem nativen XML-Datenbanksystem. An das einzusetzende System wurden dabei folgende Anforderungen gestellt:

- die Kommunikation zwischen der Datenbank und der Software soll mittels Java Database Connectivity (JDBC) erfolgen;
- das Datenbankmanagementsystem soll unter Open Source Lizenz stehen.

Eine Übersicht über zurzeit verfügbare und unter Open Source Lizenz stehenden Datenbankmanagementsysteme ist in [4] zu finden.

Die Wahl fiel auf Apache Derby (JavaDB) – ein relationales eingebettetes Datenbanksystem, das 2 MB Speicherplatz benötigt, Structured Query Language (SQL) unterstützt und sich komplett in die Software integrieren lässt [4], [5]. Die Einrichtung eines Datenbankservers ist damit überflüssig, somit erhöht die Verwendung eines eingebetteten DBS die Benutzerfreundlichkeit der Software. Trotzdem kann später ein anderes Datenbanksystem (z.B. MySQL auf einem lokalen DB-Server) ohne großen Aufwand eingesetzt werden, da dieser Aspekt bei der Modellierung der Datenhaltungsschicht der Software berücksichtigt wurde. Nähere Informationen diesbezüglich sind in Kapitel 4 „Implementierung“ enthalten.

Der Leser sei außerdem auf die Bachelorarbeit von Leonid Oldenburger hingewiesen – in dieser werden eine Analyse unterschiedlicher Datenbankmanagementsysteme und die Entscheidung für ein relationales und speziell für ein eingebettetes DBS ausführlicher erläutert.

Zunächst erfolgte die konzeptuelle Modellierung der Datenbank. Bei der Erstellung des Datenbankmodells, genauer des Entity-Relationship-Modell (ER-Modell) wurden zuerst folgende Fragen beantwortet:

- Welche Objekte der Anwendungsschicht der Software sollen überhaupt gespeichert werden?
- Wie sehen Beziehungen zwischen den gespeicherten Objekten aus?
- Wie werden die Objekte eindeutig definiert?

Die Liste der zu speichernden Objekte, die in einem ER-Modell Entities genannt werden, ist einleuchtend:

- alle Objekte der Klasse Zahlung sowie die Objekte von ihren Unterklassen (Mitgliedsbeiträge, Spenden, projektbezogene Ausgaben);
- Projekte
- und Buchungsunterbereiche.

Des Weiteren soll auch der Anfangssaldo des Vereins mit Datum, an dem die Software in Betrieb genommen wurde, in der Datenbank abgelegt werden.

Das ER-Diagramm des Finanzbereichs eines gemeinnützigen Vereins ist in Abbildung 9 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Entity-Relationship-Diagramm

Kardinalitäten der Beziehungen zwischen den Entitäten und Markierung von Schlüsselattributen der Entitäten sind in der Grafik nicht dargestellt und werden später erläutert (Kardinalitäten können der Abbildung 8 „Klassendia-gramm der Anwendungsschicht“ entnommen werden).

Eine Zahlung wird mit allen ihren Attributen (Eingangsdatum, Kontonummer, Bankleitzahl, Kontoinhaber, Betrag und Verwendungszweck) eindeutig identifiziert. Diese Überlegung basiert auf der Annahme, dass eine Person innerhalb eines Tages nicht mehr als eine Zahlung mit einem bestimmtem Betrag leistet. Das hat sowohl Vor- als auch Nachteile. Beim Einlesen eines Kontoauszuges werden alle darin enthaltenen Buchungssätze darauf überprüft, ob sie bereits in der Datenbank gespeichert sind. Ist das der Fall, so kann eine Zahlung nicht zum zweiten Mal verbucht werden. Das könnte beim wiederholten Versuch geschehen, einen Kontoauszug zu bearbeiten, der bereits zu einem früheren Zeitpunkt eingelesen und bearbeitet wurde. Außerdem sind das Start- und das Enddatum bei Erstellung eines Kontoauszuges über Online-Banking-Portal eines Kreditinstitutes frei wählbar. Deswegen kann es zu Überschneidungen zwischen zwei Kontoauszügen kommen. Die Verletzung der oben beschriebenen Annahme wird aus der Praxiserfahrung als unwahrscheinlich eingestuft. Trotzdem kann es vorkommen, dass zwei gleiche Zahlungen auf dem Bankkonto verbucht werden (z.B. man betrachte den Fall, dass ein Spender, aus welchen Gründen auch immer, zwei gleiche Beträge an einem Tag überweisen würde). Bei derzeitiger Implementierung der Software ist es aber nicht möglich, beide Zahlungen im Kassenbuch zu vermerken. Das Problem kann durch spätere Erweiterung gelöst werden. Dem Benutzer kann beispielsweise eine Meldung angezeigt werden, dass eine Zahlung in der Datenbank bereits vorhanden ist. Wiederholte Verbuchung der Zahlung kann dann nur mit der Zustimmung des Benutzers erfolgen. Eine andere, aufwendigere Lösung des Problems ist im Kapitel 5.2 „Offene Punkte“ geschildert.

Ein Projekt, sowie ein Buchungsunterbereich sind durch den Projektname bzw. durch den Name des Unterbereichs eindeutig definiert.

An dieser Stelle muss die Redundanz bei der Speicherung der Kontodaten (Kontonummer, Bankleitzahl und Kontoinhaber) erwähnt werden. In beiden Modulen der Vereinsverwaltungssoftware, sowohl in der Mitgliederverwaltung, als auch im Kassenbuchmodul, werden diese Daten gespeichert. Da aber Entwurf und Implementierung der Module anfangs parallel und unabhängig voneinander erfolgten und die Integration erst später stattgefunden hat, wurde diese Redundanz akzeptiert. Andererseits wird eine Zahlung unter anderem durch die Kontodaten eindeutig identifiziert, dadurch ist deren Auslagerung in die Datenbank des Mitgliederverwaltungsmoduls nicht möglich bzw. sinnlos. Bei der Weiterentwicklung der Software, speziell beim Übergang zu einer gemeinsamen Datenbank für beide Module, kann dieses Problem gelöst werden.

Nachdem das konzeptuelle Modell der Datenbank erstellt wurde, erfolgte der zweite Schritt der Datenbankmodellierung – die Abbildung des ER-Modells auf die Tabellen der Datenbank, also die Überführung des ER-Modells in das Relationen-Modell. Die Umsetzung umfasst folgende sieben Schritte[10]:

- Starke Entitätstypen. Für jeden starken Entitätstyp wird eine Relation R mit den Attributen {a1, a2,..., an} und k mit k als Primärschlüssel erstellt.
- Schwache Entitätstypen sind im ER-Modell der Vereinsverwaltungssoftware nicht vorhanden.
- 1:1-Beziehungstypen. Für einen 1:1-Beziehungstyp der Entitätstypen T, S wird eine der beiden Relationen um den Fremdschlüssel für die jeweils andere Relation erweitert.
- 1:N-Beziehungstypen. Für den 1:N-Beziehungstyp der Entitätstypen T, S wird die mit der Kardinalität N eingehende Relation T um den Fremdschlüssel der Relation S erweitert.
- N:M-Beziehungstypen. Für jeden N:M-Beziehungstyp wird eine neue Relation R mit den Attributen {a1, a2,..., an} für die Attribute der Beziehung sowie kT und kS für die Primärschlüssel der beteiligten Relationen T und S erstellt.
- Mehrwertige Attribute sind im ER-Modell nicht vorhanden.
- n-äre Beziehungstypen sind im ER-Modell ebenso nicht vorhanden.

Für die Generalisierung gibt es im relationalen Modell keine unmittelbare Umsetzung[11]. Es gibt drei gängigste Möglichkeiten, die Vererbungsbeziehungen auf eine relationale Datenbank abzubilden[6]:

- Single Table Inheritance – in diesem Fall werden alle Klassen der Hierarchie auf eine Tabelle abgebildet.
- Class Table Inheritance – jede Klasse der Hierarchie wird auf eine eigene Tabelle abgebildet.
- Concrete Table Inheritance – jede nicht abstrakte Klasse der Hierarchie wird auf eine eigene Tabelle abgebildet.

Diese drei Möglichkeiten können auch miteinander kombiniert werden.

In der ersten Phase der Implementierung wurde jede der Klassen Zahlung, Beitrag, Spende und ProjektAuszahlung mit allen Attributen auf eine eigene Tabelle abgebildet. Außerdem wurde auf Verwendung von Ersatzschlüssel (Surrogate Key) verzichtet, denn jedes Objekt hat einen natürlichen Schlüssel. Die Datenbankstruktur war somit intuitiv verständlich, die Fehler in der Anwendungsschicht, sowie in der GUI-Schicht der Software ließen sich leichter lokalisieren und beseitigen. Vor der Integration, nachdem die grundlegende Funktionalität des Softwaremoduls implementiert wurde, wurde eine Kombination von Single Table Inheritance und Class Table Inheritance angewandt. Ferner wurden alle Relationen um einen fremden Schlüssel erweitert. Eine gewisse Redundanz bei Speicherung der Daten wurde damit eliminiert, die Abfragen wurden einfacher, die Effizienz der Datenhaltungsschicht ist gestiegen. Der Aufwand dafür war nicht groß – dank der Drei-Schichten-Architektur der Software musste lediglich eine Klasse – der DerbyManager angepasst werden. Das endgültige relationale Datenbankmodell der Software ist in der Abbildung 10 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Relationales Datenbankdiagramm

Es sind wenige Abweichungen zwischen dem ER-Diagramm und dem Datenbank-Diagramm festzustellen, die sich einfach erklären lassen. Im Laufe der Implementierung der Software wurde das Datenbankmodell geringfügig verändert und an neue Benutzeranforderungen angepasst. Beispielsweise lässt die spätere Verwendung von Triggern, die von JavaDB unterstützt werden, die Effizienz des Systems weiterhin steigern.

3.4 Schnittstelle zur Mitgliederverwaltung

Sowohl das Mitgliederverwaltungs- als auch das Kassenbuchmodul verwenden dieselbe Datenbank. Da die Implementierung der Software in der ersten Stufe unabhängig voneinander erfolgte, war ein direkter Zugriff eines Moduls auf die Daten des anderen Moduls nicht erlaubt. Beide Softwaremodule sollten daher über eindeutig definierte Schnittstellen verfügen, um den Datenaustausch zwischen diesen zu ermöglichen.

Der Datenfluss zwischen beiden Modulen ist in Abbildung 11 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: Schnittstellen zwischen Softwaremodulen

Die Vereinsverwaltungssoftware wird bei dem ersten Start konfiguriert. Von dem Kassenbuchmodul benötigte Vereinsdaten (Name, Bankverbindung) werden in den Datenbanktabellen der Mitgliederverwaltung abgelegt.

Das Datum der Inbetriebnahme der Software, das für die Erstellung des ersten Jahresabschlusses notwendig ist, sowie der Startsaldo werden dagegen direkt in dem Datenbereich des Kassenbuchsmoduls abgelegt, da diese Informationen von der Mitgliederverwaltung später nicht gebraucht werden.

Um einen Bankauftrag erstellen zu können, müssen Mitglieder- und Spenderdaten von der Mitgliederverwaltung zur Verfügung gestellt werden. Dabei handelt es sich um solche Personen, deren Beiträge fällig sind. Das Zeitmanagement findet dabei in dem Mitgliederverwaltungsmodul statt.

Beim Verbuchen einer Zahlung, die einem Mitglied oder einem Spender zugewiesen werden muss, sollte anhand von Zahlungsinformationen (Kontonummer und Bankleitzahl) eine Mitglieds- oder Spendernummer bestimmt werden. Die Zuordnung von Kontodaten zu den Mitglieds- und Spendernummern wird dabei in den Tabellen der Mitgliederverwaltung abgelegt. Die Mitgliederverwaltung sollte also zu einem Konto eine Personennummer liefern, falls das Konto bekannt ist.

Das Kassenbuchmodul sollte anhand einer Mitglieds- oder Spendernummer eine Liste mit allen von dieser Person geleisteten Beiträgen liefern.

3.5 Datenaustauschformate im Bankverkehr (Banking Communication Standards)

Die Kommunikation zwischen dem Verein und dem den Verein bedienenden Kreditinstitut geschieht in elektronischer Form. Sollte eine Geldüberweisung getätigt werden oder Mitgliedsbeiträge per Lastschrift eingezogen werden, so wird mittels Software ein Bankauftrag im DTAUS-Format erstellt und an die Bank übermittelt. Wenn die bereits erfolgten und auf dem Vereinskonto verbuchten Zahlungen im Kassenbuch des Vereins erfasst werden sollen, dann wird ein elektronischer Kontoauszug im MT940-Format in die Vereinsverwaltungssoftware importiert und bearbeitet.

DTAUS und MT940 sind zwei Vertreter der Datenaustauschformate im Bankverkehr. In den folgenden Abschnitten wird auf die Formate näher eingegangen.

3.5.1 DTAUS

DTAUS ist ein Datenträgeraustausch-Format zur Übermittlung von Zahlungsverkehrsnachrichten im deutschen Inlandszahlungsverkehr. Für den Auslandszahlungsverkehr wird dagegen das DTAZV-Format verwendet, das im Weiteren nicht betrachtet wird. Die Implementierung der Software ist aber so konzipiert, dass eine spätere Erweiterung auf DATZV problemlos möglich ist.

Ursprünglich wurden die DTA-Dateien im DTA-Format auf Disketten, Magnetbänder, Speicherkarten oder andere ähnliche Medien gespeichert, die anschließend an die Bank übermittelt wurden. Heutzutage ist der Einsatz der Speichermedien nicht mehr nötig, denn fast alle Kreditinstitute verfügen über On-line-Banking-Portale und ermöglichen ihren Kunden DTA-Dateien direkt über Web-Interface hochzuladen [9].

Das Format ist in der Anlage 3 der Schnittstellenspezifikation für die Datenfernübertragung (DFÜ) zwischen Kunde und Kreditinstitut gemäß DFÜ-Abkommen „Spezifikation der Datenformate“ [8] beschrieben.

Eine physische DTA-Datei kann aus mehreren logischen DTA-Dateien bestehen. Eine logische DTA-Datei besteht aus einem A-Satz (Datenträger-Vorsatz), einem oder mehreren C-Sätzen (Zahlungsaustauschsatz) und einem E-Satz (Datenträger-Nachsatz) und kann einen oder mehrere Bankaufträge enthalten. Dabei darf eine logische DTA-Datei entweder nur Überweisungs- oder nur Lastschriftaufträge umfassen.

Datensatz A (Datenträger-Vorsatz)

Dieser Satz enthält unter anderem den Speichermedienabsender und -Empfänger, die Art der Transaktionen (Last- oder Gutschriften, Bank- oder Kundenseitig) sowie das Ausführungsdatum (optional) und ist je logischer Datei nur einmal vorhanden. Die Länge des A-Satzes beträgt 128 Byte. Der Aufbau des A-Satzes ist in der Tabelle 2 (Anhang) dargestellt.

Datensatz B (Zahlungsaustauschsatz)

Der B-Satz (Tabelle 3 im Anhang) enthält die eigentliche Zahlungsinformation: beteiligte Konten mit Namen des Kontoinhabers, Betrag, Transaktionstyp (z.B. Abbuchung, Einzug, Überweisung, vermögenswirksame Leistungen usw.) sowie Verwendungszweckangaben. Der Satz gliedert sich in einen konstanten und einen variablen Teil und kann durch bis zu 15 Erweiterungsteile verlängert werden.

Der variable Teil enthält den Name des Begünstigten/Zahlungspflichtigen und den Verwendungszweck und bildet mit dem konstanten Teil eine Einheit.

Datensatz E (Datenträger-Nachsatz)

Der E-Satz (Tabelle 4 im Anhang) besteht aus einem Zähler der C-Sätze, sowie Prüfsummen von Kontonummern, Bankleitzahlen und Beträgen aus den Datensätzen C. Der Satz dient der Abstimmung und ist je logischer Datei nur einmal vorhanden.

Beispiel

Um die Komplexität des Aufbaus einer DTA-Datei zu verdeutlichen, wird im Folgenden eine logische DTA-Datei mit einem Überweisungsauftrag (C-Satz) betrachtet:

Abbildung in dieser Leseprobe nicht enthalten

Man beachte, dass die Daten in einer Zeile ohne Zeilenumbrüche gespeichert werden.

Der A-Satz der Datei sieht folgendermaßen aus:

Abbildung in dieser Leseprobe nicht enthalten

Folgende Informationen sind fett gedruckt:

- Kennzeichen „ GK “ (Gutschrift Kunde) bedeutet, dass es sich bei der logischen Datei um eine kundenseitige Gutschriftdatei handelt, d.h. dass der Kunde der Bank einen Überweisungsauftrag erteilt; das Geld wird also vom Kundenkonto überwiesen;
- 40050060 ist die Bankleitzahl des Kreditinstituts;
- Name des Auftraggebers oder des Absenders der Datei lautet „ Foerderverein e.V. “;
- die Datei wurde am 16.08.2010 (160810) erstellt;
- die Kontonummer des Auftraggebers ist 0000123456;
- der Auftrag soll am 20.09.2010 (20092010) ausgeführt werden;
- Währung des Auftrags ist Euro (1).

Der C-Satz

Abbildung in dieser Leseprobe nicht enthalten

umfasst nachstehende Informationen:

- Bankleitzahl (22222222) und Kontonummer (1234567890) des Zahlungsempfängers;
- Kennzeichnung der Zahlungsart (51000), in diesem Fall steht 51000 für eine Überweisungs-Gutschrift;
- Bankleitzahl (40050060) und Kontonummer (0000123456) des Auftraggebers;
- Betrag in Cent (10000), entspricht 100,- €;
- Name des Empfängers „ Max Mustermann “;
- Name des Absenders „ Foerderverein e.V. “;
- schließlich folgt der Verwendungszweck („ Verwendungszweck-1 Verwendungszweck-2 Verwendungszweck-3 “), der sich aus drei Felder mit je 27 Bytes zusammensetzt. Dabei ist die Anzahl der Erweiterungsteile (02) fett gedruckt und mit einer punktierten Linie unterstrichen. Bei den Erweiterungsteilen handelt es sich um weiteren Text des Verwendungszwecks, das gibt das Erweiterungskennzeichen „ 02 “ an (mit einer durchgezogenen Linie unterstrichen).

Der E-Satz

Abbildung in dieser Leseprobe nicht enthalten

besteht wie oben bereits geschrieben aus Prüfsummen:

- 00000001 gibt an, dass die Datei genau einen C-Satz enthält;
- darauf folgen die Summe der Kontonummer (00000001234567890), die Summe der Bankleitzahlen (00000000022222222) und die Summe der Beträge aus den C-Sätzen (0000000010000).

3.5.2 MT940

MT940 (Message Type 940) ist ein internationaler Standard, der für die beleglose Übermittlung von Kontoinformationen entwickelt worden ist. Der Standard wird von Kreditinstituten weltweit verwendet und wird als Schnittstelle zwischen Online-Banking-Portal und verschiedenen Finanz-Software-Produkten benutzt. MT940-Nachrichten gehören zu den SWIFT-MT-Nachrichten (Society for Worldwide Interbank Financial Telecommunication) – standardisierte Datenformate für den Nachrichtenaustausch zwischen Kreditinstituten, Börsen, Wertpapier-Lagerstellen, anderen Finanzinstitutionen und auch großen Unternehmen anderer Branchen[14].

Ein Kontoauszug im MT940-Format kann auf zwei Wegen von einer Bank bekommen werden: entweder über Web-Interface oder über die HBCI / FinTS – Schnittstelle z.B. mittels einer Buchhaltungssoftware (viele Finanzverwaltungs- und Buchhaltungsprogramme werden via Internet mit einer Bank verbunden, die meisten davon unterstützen den Export von Kontoinformationen im MT940-Format). HBCI ist Homebanking Computer Interface, das im Jahr 1996 vom Zentralen Kreditausschuss (ZKA, http://www.hbci-zka.de/) veröffentlicht wurde. FinTS (Financial Transaction Services) ist die Weiterentwicklung von HBCI. Heutzutage werden beide Schnittstellen von fast allen deutschen Banken unterstützt.

Das Format ist in der Anlage 3 der Schnittstellenspezifikation für die DFÜ [8] beschrieben.

Eine Kontoauszug-Datei im MT940-Format besteht aus mehreren Sätzen. Jeder Satz fängt mit einer Nummer an, die den Typ des Satzes definiert. In einer MT940-Datei sind unter Anderem folgende Informationen enthalten:

- Erstellungsdatum des Kontoauszugs;
- Kontoinformationen (Kontonummer und Bankleitzahl);
- Anfangssaldo;
- ein oder mehrere Umsätze;
- Endsaldo.

Sätze bestehen aus einem oder mehreren Feldern, auf die diese Informationen teilweise verteilt sind. Nachfolgend wird ein Beispiel eines Kontoauszuges im MT940-Format betrachtet, die genauere Beschreibung des Formats ist in [8] zu finden.

Beispiel

Als Beispiel wird ein Kontoauszug mit zwei Zahlungen (einer Überweisung und einer Lastschrift) betrachtet.

Abbildung in dieser Leseprobe nicht enthalten

Der Kontoauszug fängt mit dem Auftragsreferenz-Nummer-Feld an (:20:). Das Feld ist nicht strukturiert und je nach Bank unterschiedlich belegt. Das nächste Feld (:25:) enthält die Bankleitzahl und die Kontonummer, oder Swift-Code und die Kontonummer. In diesem Fall ist 40050060 die BLZ und 0000123400 – die Kontonummer. Das Auszugsnummer-Feld (:28C:) wird folgendermaßen belegt: xxxxx/yyy, wobei xxxxx die Auszugsnummer ist und yyy – die Blattnummer des Auszugs.

Felder „:60F:“ und „:62F:“ enthalten Start- und Endsalden. Das erste Zeichen gibt an, ob es sich um Haben (C = credit) oder Soll (D = debit) handelt. Die nächsten sechs Ziffern geben das Saldodatum an (JJMMTT), darauf folgt die Währung (EUR) und der Betrag mit Komma als Dezimaltrennzeichen. Im Beispiel sind beide Salden positiv. Der Saldo am 17.06.2010 beträgt 100,00 Euro und am 18.06.2010 beträgt der Saldo 90,00 Euro.

[...]