Offenbar wird die SEPA Referenznummer (KREF?) von den Banken immer noch nicht korrekt verarbeitet.

Bei der Postbank ist online bspw. überhaupt kein Eingabefeld dafür vorhanden.
Bei der VoBa gibt es ein Eingabefeld für den Verwendungszweck und eins, das mit "oder Kundenreferenz" beschriftet ist.
(die Kundenreferenznummer ist doch nicht als alternatives Feld, sondern als zusätzliches zu definieren, oder sehe ich das falsch?)

Siehe auch hier.
Die Banken verschlucken offenbar die Kundenreferenznummer (PoBa) oder verwursten sie im Verwendungszweck (VoBa).

Dabei wäre das doch einer der wenigen Vorteile von SEPA-Überweisungen - dass man mit Referenznummern (z.B. Rechnungsnummern) eine Buchung sicherer automatisiert zuordnen kann.

Unfassbar, dass die RZ-Entwickler das nicht auf die Reihe kriegen
Das SEPA-Protokoll scheint aber auch - wenn ich das oberflächlich anschaue - übermäßig kompliziert definiert zu sein.
Vermutlich waren da dieselben Leute am Werk, die damals das "BTX"-Protokoll verbrochen haben..

Hallo Chaka,

dein Grundgedanke (Sinn und Zweck der Referenz und wichtig) ist erst mal richtig. Ab da ist das Thema leider komplizerter.
Die Referenz die Du meinst ist die End2EndID. Diese Referenz soll auf den ganzen Weg einer einzelnen Zahlung bei allen Beteiligten mitgegeben werden und identifziert diese so für alle eindeutig.

Wie Du schon richtig vermutet hast, wird die Referenz in ein eigenes Feld gestellt und weitergegeben.
Wenn die Zahlung dann bei der "Ziel" Bank gebucht wrd, muss diese Information jetzt nur noch dem Kunden bereitgestellt werden. Jetzt fängt das Problem an.
Das Format, das dafür in Deutschland noch genutzt wird (MT940) kennt keine Felder für diese Referenzen, also hat man sich für den Übergang bis sich ein neues Format etabliert hat (camt) Wege überlegt die Daten zu tranportieren.
Die Referenz wird in den Verwendungszweck gestellt und mit EREF+ als solche gekennzeichnet.
Das Problem ist jetzt, das es viele Banken gibt, die bei den Umsätzen nur 4 Verwendungszweckzeilen (wie International oft üblich) zur Verfügung stellen können. SEPA aber kennt z.B. nur einen VWZ mit 140 Zeichen
Wenn ich als Verwendungszweck in SEPA also 1 x 140 Zeichen habe und in den Umsätzen

VWZ1: 1. x 27 Zeichen
VWZ2: 2. x 27 Zeichen
VWZ3: 3. x 27 Zeichen
VWZ4: 4. x 27 Zeichen

sind alle Zeilen voll und ich muss den SEPA VWZ bereits um 32 Zeichen (4 x 27=108 ) kürzen. D.h. ich verzichte auf das Einstellen einer Referenz,oder ich muss den VWZ weiter kürzen (so vorgesehen). Jetzt nehmen wir mal eine Referenz mit 20 Zeichen, dann würde unter SEPA der Umsatz auch mit einer Kennzeichnung SVWZ+ dort eingestellt werden. Damit sieht der VWZ z.B. so aus

VWZ1: EREF+ & 20 Zeichen Referenz
VWZ2: SVWZ+ & die ersten 22 Zeichen des VWZ
VWZ3: 27 Zeichen
VWZ4: 27 Zeichen

Wenn die Referenz 30 Zeichen hat und somit nicht mehr in eine Zeile passt siehte so aus:

VWZ1: EREF+ & 22 Zeichen Referenz
VWZ2: die restlichen 8 Zeichen der Referenz
VWZ3: SVWZ+ & die ersten 22 Zeichen des VWZ
VWZ4: 27 Zeichen

D.h. hier bleiben bereits nur noch 49 Zeichen von 140 übrig. Sind weitere Referenzen vorhsanden wird exakt so weiter verfahren. Blöd, sobald eine Lastschrift kommt mit GläubigerID und Mandatsreferenz passt hier gar nichts mehr. Dann heißt es kürzen bis zur Unkenntlichkeit, andere Prioritäten setzen,oder ggf. auch einfach darauf verzichten.
Erst mit dem camt. können die Referenzen und der VWZ getrennt transportiert werden und kommen sich so nicht in die Quere.

SEPA Aufträge und auch der camt sind übrigens sauber in XML strukturiert. Auch der MT940 ist strukturiert, aber das ist noch ein altes vorallem technisches Format, was vorallem auf die Lesbarkeit durch Maschinen ausgelegt war.

D.h. die Referenzen werden sicherlich Ihre Bedeutung bekommen. Aber da wir uns in einer Übergangsphase befinden, wird das sicherlich noch etwas dauern (die Unternehmen, die die Umsatzinformationen verarbeiten, müssen ja auch erstmal ihre Technik umstellen und die sind derzeit mit der Umstellung der Aufträge genung beschäftigt).

Viele Grüße

Holger

Hallo Holger,

vielen Dank für deine ausführlichen Erklärungen.
Es liegt also an Platzproblemen bei der Konvertierung eines SEPA-Buchungssatzes nach MT940.
Das ist nachvollziehbar. Aber..



..das wird ja offenbar zumindest bei der Postbank nicht gemacht. Siehe mein Beispiel.
Im VWZ wurde die Referenz nicht weitergegeben.

Außerdem wird offenbar IBAN+BIC nicht in den entsprechenden Feldern zurückgegeben. (Bei der VoBa wird das richtig gemacht). Daher kann das Banking-Programm die Empfänger-Kontonummer nicht anzeigen.
Stattdessen wird die Empfänger-IBAN in den VWZ eingefügt. Das ist doch eindeutig Murks, oder?

Vermutlich wurde im Regelwerk vergessen, für solche Übergangs-Probleme verbindliche Regeln aufzustellen.
Stattdessen ist das jetzt wohl der künstlerischen Kreativität jedes Rechenzentrums überlassen, welche Daten weitergegeben werden und welche verlorengehen

Zu bedauern sind auch die Entwickler von MT940-kompatiblen Programmen (FiBu usw.). Die haben wahrscheinlich derbe Probleme beim Einlesen dieses Datensalats.

Ja, chakaa, ist so. Ich verstehe allerdings den Thread an sich nicht. Was willst du erreichen? Geändert wird daran eh nichts. Das Forum ist eigentlich besser für Fragen geeignet als für Herzausschüttungen

da magst du Recht haben

Aber zumindest werden durch solche Beiträge die Bugs im Netz dokumentiert. Wenn jemand anders per Suchmaschine darauf stößt, sieht er wenigstens den Stand der Dinge.
Außerdem konnte man ja auch von Holgers Beitrag was lernen.

Und vielleicht lesen hier ja sogar RZ-Entwickler mit und erfahren abseits vom abgeschirmten Elfenbeinturm von den Bugs..

hier gilt glaub einfach "kommt Zeit, kommt Rat"
das ganze wird sich in den nächsten Wochen/Monaten noch "einspielen".