Praxishandbuch SAP und SEPA

2.1 Übersicht und Aufbau von ISO 20022-Nachrichtentypen

Weltweit existieren zahlreiche Standards im Finanzwesen, die den Austausch von Nachrichten zwischen Unternehmen und Finanzinstitutionen ermöglichen sollen. Allerdings fehlt an der Stelle die Interoperabilität, was bedeutet, dass der Datenaustausch zwischen Geschäftspartnern, die mit unterschiedlichen Standards arbeiten, erschwert ist.

Die Interoperabilität als Voraussetzung finden wir im Artikel 4 der Verordnung (EU) Nr. 260/2012, die letztlich den Zahlungsverkehr in Europa für alle Beteiligten vereinfachen soll. Hier liegt der Ursprung für das Format ISO 20022 – ein gemeinsamer Standard zum Austausch von Finanznachrichten.

Bei ISO 20022-Nachrichten handelt es sich ausschließlich um Finanznachrichten, die auf Basis der erweiterbaren Auszeichnungssprache XML von der Internationalen Organisation für Normung (ISO) veröffentlicht werden. Der Katalog der herausgegebenen Nachrichten erstreckt sich über zahlreiche Geschäftsbereiche wie beispielsweise:

• Zahlungsverkehr,
• Treasury,
• Wertpapiere und
• Außenhandelsfinanzierung.

Richten wir den Blick auf den Nachrichtenkatalog für die Zahlungsverkehrsnachrichten, so teilen sich diese unter ISO 20022 in drei Gruppen auf:

• PAIN (Payment Initiation) Kunde-Bank-Beziehung,
• PACS (Payments Clearing und Settlement) Interbankenbereich,
• CAMT (Cash Management) Bank-Kunde-Beziehung.

Während die PACS-Formate nur im Interbankenbereich verwendet werden, etablieren sich nicht zuletzt durch SEPA die PAIN- und CAMT-Nachrichten im Zahlungsverkehr zwischen Finanzinstitutionen und Unternehmen. Mit den Elementen aus den XML-Nachrichten ist nun eine verbesserte, durchgängige Verarbeitung in den ERP-Systemen möglich geworden.

Ein weiterer Vorteil der ISO-Nachrichtentypen ist deren ständige Weiterentwicklung in den einzelnen Versionen. Somit ist gewährleistet, dass zusätzlich für den Datenaustausch benötigte Felder in einer aktuellen Version eingebaut werden können. Die im Datenträger verwendete Version ist grundsätzlich aus dem Namespace im Header der Datei ersichtlich (siehe Abbildung 2.1).

Abbildung 2.1: Namespace im Header einer XML-Datei

Aufgrund der umfangreichen, für den Regelfall nicht benötigten Feldbelegungsmöglichkeiten, die die ISO 20022-Formate bieten, wird der aktuelle Basis-Standard von den meisten Geschäftsbanken derzeit nicht akzeptiert. Daher sind um diesen Standard in den vergangenen Jahren einige Initiativen entstanden, die aus den Nachrichtenkatalogen eigene Subsets entwickelt haben (siehe Abbildung 2.2).

Abbildung 2.2: Unterschiedliche ISO 20022-Formate im Zahlungsverkehr

Die wichtigsten Formatdefinitionen, die auf dem Basis-Standard aufbauen, werden derzeit gepflegt bei:

• Common Global Implementation - Market Practice (CGI-MP),
• European Payments Council (EPC),
• Länderversionen aus dem SEPA-Core-Format.

Auch wenn Sie die SEPA-Migration bereits vollzogen haben, ergeben sich in der Formatstrategie durchaus noch Optimierungs- und Entwicklungspotenziale (etwa für den Einsatz einer Payment Factory).

Grundsätzlich ist das SEPA-Core-Format in seiner Reichweite eingeschränkt. Die Formatdefinition beschränkt sich auf die Mitgliedsländer des SEPA-Raums sowie auf die Transaktionswährung »Euro«. Erschwerend kommt hinzu, dass sich unter diesem Format zahlreiche Länderformate etabliert haben, was den Aufwand in Bezug auf Wartung und Integration der Datenträgerformate in SAP deutlich erhöht hat.

Im Detail betrachtet, ergeben sich in der Formatbeschreibung zwischen dem EPC und der Deutschen Kreditwirtschaft (DK) nur geringfügige Abweichungen. Gegenüber dem SEPA-Core-Format wird in den DK-Versionen (SCT und SDD) allerdings nur rund ein Viertel der nutzbaren Felder verwendet. Der überwiegende Teil der Felder ist von der DK als nicht empfohlen gekennzeichnet.

Weitaus mehr Möglichkeiten bieten die CGI-MP-Formate. Wie auch bei den SEPA-Formaten, ist CGI-MP eine Untermenge von ISO 20022. Dabei ist die Initiative weitestgehend nicht auf Teilnehmerländer oder Währungen beschränkt und eignet sich somit für den globalen Zahlungsverkehr (siehe auch Kapitel 2.4). Allerdings steigt auch hier die Komplexität der Integration und Pflege der Formate.

2.1.1 Validierungsmöglichkeiten von XML-Nachrichten

Im Rückblick dürfte die Einführung der SEPA-Formate an manchen Stellen herausfordernd gewesen sein. Die bisher vertrauten DTA-Formate wurden durch deutlich größere und umfangreichere XML-Formate abgelöst. Ab einer bestimmten Anzahl von Transaktionen (mehr als 10 bis 20 Belege) geht hier schnell der Überblick bzw. die Detailtiefe in einer Nachricht verloren. Die XML-Nachricht wird dann unübersichtlich und schwer lesbar, was auch daran liegt, dass die einzelnen XML-Tags im Klartext dargestellt werden.

Erschwerend kommt noch hinzu, dass regelmäßige Änderungen und Ergänzungen in der Dateistruktur Anpassungen in den Formatbäumen notwendig machen. Jede Änderung in den SAP-Formatbäumen erfordert wiederum im Anschluss eine erneute gründliche Prüfung der erzeugten XML-Nachrichten.

Für eine erste Validierung reicht es zunächst, die erzeugte Datei gegen das jeweils gültige XSD-Schema zu prüfen. Dazu ist bereits ein einfacher XML-Editor geeignet, wie beispielsweise das XML Notepad der Firma Microsoft, das Ihnen im Download Center http://www.microsoft.com/de-de/download/ kostenlos zur Verfügung gestellt wird.

Laden Sie zunächst das Schema (siehe Abbildung 2.3) hoch, gegen das die XML-Nachricht geprüft werden soll.

Abbildung 2.3: XML-Schema für die Validierung von SEPA-Nachrichten

Öffnen Sie anschließend die Nachricht und prüfen Sie das Ergebnis (siehe Abbildung 2.4) der Validierung. Beachten Sie in diesem Zusammenhang, dass es sich hierbei nur um eine technische Prüfung handelt, also nur kontrolliert wird, ob im XML-Dokument die technischen Regeln des gewählten Schemas eingehalten sind.

Abbildung 2.4: Ergebnis der Validierung von XML-Nachrichten

Eine erweitere Prüfung gegen die SEPA Usage Rules nach Gültigkeit der IBAN oder BIC in einem Datenträger findet an der Stelle nicht statt. Dies sind Regeln, die nicht über die XSD-Datei abgebildet werden können, wie beispielsweise die Prüfung gegen das SCL-Directory (siehe auch Kapitel 1.3).

Durch diese erweiterte Prüfung der Datei erhalten Sie bereits frühzeitig Informationen darüber, ob der eingereichte Datensatz valide ist und später bei der Bank verarbeitet werden kann.

Die Anforderungen an die Usage-Rules-Prüfungen werden im Regelfall von kostenpflichtigen Programmen abgedeckt. Darüber hinaus stellen mittlerweile auch die meisten Banken kostenlose Online-Prüfprogramme zur Verfügung, die ebenfalls eine fachliche Prüfung der Datei durchführen.

Abbildung 2.5: Testbericht einer SEPA-Nachricht

In beiden Fällen erhalten Sie im Anschluss an die Validierung einen ausführlichen Testbericht, der Ihnen mögliche Hinweise auf Fehler in der Datei aufzeigt (siehe Abbildung 2.5).