letzte Änderung: 26.06.2021
12.05.2020
SFIRM und Starmoney-Business scheinen Probleme beim Einlesen von externen IBAN-Only Datensätzen zu haben, wenn bei der EBICS-Einrichtung ältere Signaturformate genutzt werden. Achten Sie bei der Einrichtung daher auf möglichst aktuelle Schlüsselformate.
Für Programmierer und Interessierte: Die relevanten Spezifikationen in deutscher Sprache finden sich hier: https://www.ebics.de/de/datenformate
Allerdings gilt das für EBICS, eine Schnittstelle für Massenzahlungen. Für FinTS/HBCI und andere Bankenschnittstellen kann es kleinere Abweichungen geben.
Tipp: Nahezu alle VR-Banken haben Zugriff auf ein Tool namens VR-Formatprüfer von Business Logics, das die XML-Files analysiert. Mailen Sie das Electronic Banking Team Ihrer genossenschaftlichen Bank an.
Vorsicht – wer sich mit den Dateien aus der Buchhaltung beschäftigen möchte: Office-Programme wie Word und Excel sind zur Bearbeitung ziemlich ungeeignet, nutzen Sie diese keinesfalls, wenn Sie neugierig auf die Inhalte einer Buchungsdatei sind oder sorgen Sie zumindest für ein Backup.
Die Art des Auftrages wird im Pain-Format definiert, pain.001 sind Überweisungen, pain.008 kennzeichnen Lastschriften.
Achten Sie auf die Deklarationen, in den veralteten Formaten ist das Weglassen der BIC-Einträge noch nicht erlaubt!
Bei IBAN-Only-Überweisungsaufträgen muss bei den Datenfeldern der Empfänger-/Zahlungspflichtigen der komplette Tag weggelassen werden, es reicht nicht, dass das Feld einfach leer bleibt.
Das hier ist falsch, der Auftrag ist fehlerhaft:
<BIC></BIC>
oder auch
<BIC>NOTPROVIDED</BIC>
Der komplette Eintrag darf also nicht im Auftrag sein. Wenn er aber d’rin steht, muss die BIC auch korrekt sein und zur IBAN passen.
Also so:
<BIC></BIC>
Dies bezieht sich auf die Empfänger-Seite der Buchungen.
Im Kopfteil, also dort wo die Auftraggeberdaten und die eigene IBAN stehen, sieht es anders aus. Hier darf ein „NOTPROVIDED“ eingetragen sein, dies muss aber in einem anderen Feld, also nicht im BIC-Tag stehen.
Für Lastschriften ist dies anders. Hier gilt dies auch nicht nur für den „Kopfteil“, sondern auch für die Einzeltransaktion, NOTPROVIDED darf hier nicht im BIC-Feld stehen, sondern muss so rein:
<Othr><Id>NOTPROVIDED</Id></Othr>. Das BIC-Feld muss aber weg. Da es Dateien mit mehreren „Auftrags-Gruppen“ geben kann, gilt dies für jede separat.
Lastschriften, getestet mit der Beispieldatei von ebics.de (pain.008.001.02)
Entsprechend sollte man mit einem ordentlichen Editor (z.B. Notepad++ unter Windows) mit "Suchen und Ersetzen" Lastschrift-Dateien mit diesem Fehler reparieren können:
Ersetze:
<BIC>NOTPROVIDED</BIC>
durch
<Othr><Id>NOTPROVIDED</Id></Othr>
Der Block des Debitoragents sind dann so aus:
<DbtrAgt>
<FinInstnId>
<Othr><Id>NOTPROVIDED</Id></Othr>
</FinInstnId>
</DbtrAgt>
Quellen:
Am deutlichsten hat es „Potzblitz“ bei uns im Forum beschrieben, finde ich: homebanking-hilfe.de
ebics.de, Version 3.3
Credit Transfer Transaction (Überweisungen): pain.001.0001.03
„Kopf“: Payment Info, Abschnitt 2.2.1.6
„Einzeltransaktion“: Abschnitt 2.2.1.8
Lastschriften (Direct Debit): pain.008.0001.02
Payment Info, Abschnitt 2.2.2.5
„Einzeltransation“: Abschnitt 2.2.2.7
EBICS:
Der EBICS-Server („Multivia“ heißt der bei den genossenschaftlichen Banken) gibt leider keine besonders hilfreiche Fehlermeldung aus. Das Kundensystem erhält im Protokoll nur die Fehlermeldung, dass die Datei nicht in Ordnung sei:
Ergebnis der Verarbeitung : 454 Daten nicht lesbar
Der Server gibt aber weder die Buchungsdatei noch die Fehlermeldung an das Banksystem weiter. Die „normale“ BankmitarbeiterIn erfährt vom Vorgang also gar nichts. Es gibt in jeder Bank nur wenig Fachleute mit Zugriffsberechtigung auf den EBICS-Server. Wenn diese in die Protokolle schauen, finden sie nur den Hinweis, dass in der Datei an der Stelle X unerlaubte Zeichen stehen:
Im Parser 'sepa-pain001groupingoption-strict-1' ist ein Fehler aufgetreten: Invalid XML. cvc-pattern-valid: Value '' is not facet-valid with respect to pattern '[A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}' for type 'BICIdentifier'.
Current input position: line=1, col=1009
Current logical position: (OrderFile=1, LogicalUnitGroup=1, LogicalUnit=1, Transaction=1)
Meist erst mit einer Analyse der Datei, entweder manuell oder mit einem Prüftool, wird dann deutlich, welche Ursache wirklich hinter dem Problem steckt.
