SEPA-Überweisungen im Kontenabruf

Du glaubst doch nicht im Ernst, dass Du mit denen direkt kommunizieren kannst? Bzw. dass die wegen einem Kunden irgendwas machen bzw. verändern, wenn sie es von Anfang an schon nicht besser schaffen? Gestatte die Frage: Glaubst Du auch an's Christkind?

Somit klare Antwort: GARNICHT.

Na ja, das war nicht unhöflich von msa sondern ein Versuch, in einem superlativ darzustellen, wie hoffnungslos es ist, an einen RZ-Entwickler heran zu kommen. Du musst die Sachlagen so hinnehmen, wie sie sind. Eine Bank ändert daran nichts, wenn einer sich beschwert. Und du wirst keine nennenswerte Zahl Leute finden, die sich mit dir beschweren, weil den meisten Kunden das egal ist bzw. sie eh nicht verstehen, was da steht. Bei der PoBank sowieso nicht....

Also. Die Postbank liefert (wie FAST alle anderen Banken auch) die Umsätze im Format MT940 (das alte nicht-SEPA-Format), welches die gesamten SEPA-Felder nicht kennt. Also mußte man irgendwas tun. Und das ist: Man liefert die SEPA-Felder im Verwendungszweck aus und stellt Ihnen Feldkennungen voran. Die EndToEnd-Referenz wandert somit also in den VZ mit ERF+ voran.

Jetzt gibt es Softwaren, die seit eh und je den Verwendungszweck unverändert einfach in die VZ-Felder knallen. Bei denen gibt es weniger Probleme, man sieht halt alles und muß sich die Ref. selbst mit dem Auge raussuchen, indem man nach EREF+ Ausschau hält. Dann gab und gibt es Softwaen (B4* gehört dazu) die es besser gemacht haben. Die sind seit eh und je auf die Eigenheiten des jeweiligen RZ eingegangen und haben teils in den Daten gekennzeichnete Felder rausgesucht und an den richtigen Platz in der Datenbank verschoben. Das hat bis zu den Umstellungen klaglos geklappt. Jetzt allerdings haut das erst mal nicht mehr so richtig hin. In fast allen Fällen ist der Grund der, dass die RZs ihre Konstrukte nicht spezifikationsgemäß erstellen - sei es dass sie einfach zu doof sind oder keine Lust haben oder ihren Sonderweg besonders toll finden - keiner weiß es. Wenn nun der Datenstrom der da kommt nicht der Spezifikation entspricht, hat es die Software natürlich schwierig, was Sinnvolles zu finden und läuft oft in den Wald. Musterbeispiel hier ist derzeit die SPARDA-DV. Die haben seit der Umstellung mehrmals zwischen zwei "Auslieferungsversionen" hin und hergeschaltet - beide einfach nur FALSCH. Letztendlich hat man sich für die zweite Falsche entschieden und scheint dabei bleiben zu wollen. Laut Spez. darf so ein Feldschlüssel (EREF+) immer nur am ANFANG einer Verwendungszweckzeile vorkommen. Sparda kann sich das aber nicht leisten, da sie nur 4 Zeilen haben. Also fangen sie mit dem nächsten Feld nicht am Anfang einer neuen Zeile an, sondern irgendwo mitten in der laufenden. Spart Platz, klar. Wenn die VZ einfach so als VZ in die Datenbank geknallt werden ist das auch kein Problem, wenn aber, wie B4* es macht, der VZ nach Feldern durchsucht wird und die sinnvoll in die Datenbank kommen, dann wird es zum Problem. Beispiel: Anfang der ersten Zeile steht EREF+12345. Schön, das wird als Referenz erkannt und ins Referenz-Feld geschrieben - allerdings: ALLES was bis zum nächsten Feldschlüssel AM ANFANG EINER NEUEN ZEILE kommt, ist weiterhin Inhalt des alten Feldes und kommt somit auch ins Ref-Feld. Wenn also jetzt mitten auf der Zeile der Feldschlüssel für Name steht wird er nicht erkannt und trotzdem weiter alles ins Ref-Feld gegeben. Dies ist allerdings nicht beliebig lang, also wird hinten abgeschnitten. Und schon ist der Name WEG.

Ich gehe davon aus, dass bei Dir ähnliche Probleme vorliegen. Genauer anschauen könnte man das, wenn Du aus dem Protokoll mal den MT940 Datenstrom rauskompierst und anonymisiert postest oder mir per PN schickst. Dann könnte man genau sehen, was von der Postbank geliefert wird und ob die Infos schon bei der Postbank verloren gehen und nicht geliefert werden oder ob sie aufgrund von "Softwareunverträglichkeiten" untergehen.

Übrigens, wie onlbanker schon gesagt hat - ich wollte mit dem Christkind absolut nicht unhöflich sein. Ich war nur fassungslos und amüsiert, dass ein Bankkunde meint, er könnte irgendwas beeinflussen oder verändern oder gar an die Entwickler, die im RZ hinter einer Bank sitzen, herankommen. Ich habe noch NIE erlebt, dass das geglückt ist bzw. irgendwas dabei herausgekommen ist. Und das wollte ich damit zum Ausdruck bringen. Wenn Du noch "ans Gute" glaubst, ich halte Dich nicht auf. Versuche, was zu bewegen. Falls es Dir in irgend einer Form gelingt, wäre ich sehr dankbar, wenn Du den Erfolg hier postest. Dann würde ich ggf. auch wieder anfangen, ins Gute (bzw. ans Christkind) zu glauben.

Da muß ich leider widersprechen. In der derzeitigen fehlerhaften Auslieferung der SPARDA-DV habe ich Buchungen, wo was drin steht. Hier ein Beispiel. Im B4W-Feld "Referenznummer" steht drin:

6957903 MREF+ 1055100790 CRED+ DE2

Im Web hatte das so ausgeschaut:

Wertstellung: 07.01.2014
ZAHLUNGSGEGNERNAME
SEPA-BASISLASTSCHRIFT
EREF+ 6957903 MREF+ 1055100
790 CRED+ DE28ZZZ00000xxxxx
x SVWZ+ xxxxxxxxxxxxxxxxxxx
xxxxxxxx xxxxxx

Nachdem die EREF am Beginn des VZ eingestellt wird, kommt die - wenn vorhanden - eigentlich immer durch. Ab MREF+ wird es nicht mehr erkannt, weil die Feldschlüssel nicht mehr am Anfang einer Zeile kommen. Es würde alles ins Feld Referenznummer getan, was aber wohl zu kurz ist. Somit steht dann im Verwendungszweck nur SEPA-BASISLASTSCHRIFT. MREF, CRED und SVWZ gehen komplett verloren...

Achso, ja. Das fand ich bei SPARDA-DV ja schon fast selbstverständlich. "Wir wollen den Kunden doch nicht mit einem neuen Feld überfordern...."

hurra, das war's, was ich wissen wollte

Fazit: da das zumindest bei einigen Banken fehlerhaft implementiert ist, werde ich die Referenznummer nur noch in den VWZ schreiben. (so praktisch dieses Feld ja besonders für den Empfänger wäre..)

Schwierige Problematik. Einerseits hat die SPARDA-DV (dort läßt die netbank ja leider rechnen) schwammig angekündigt, dass man im Rahmen der SEPA-Umsetzung die Auslieferung der Umsätze komplett umstellen (im Sinne von vergessern, meinen sie wohl) will. Wann und wie und so weiter gibts natürlich keinerlei Aussagen. Aber immerhin schon mal besser als die erste Aussage. Man hatte ja mehrfach zwischen zwei kaputten Datenformaten hin und hergewechselt, und dann irgendwann erklärt "so bleibt es jetzt" - also kaputt.

So wie ich Andreas kenne wird er, wenns wirklich so bleibt, irgendwann schon eine Sonderlocke für die SPARDA-DV einbauen. Aber derzeit hat er wohl mit SEPA genug zu tun und außerdem hat er das Thema SPARDA-DV erst mal beiseite gelegt, nachdem die jedesmal, wenn er was gemacht hatte, wieder ne sinnlose Änderung in ihren Daten vorgenommen hatten.

Kann man die Lastschriftbuchungen im Rohformat in den Auszug hineinbekommen, bis die SPARDA-DV mal fertig ist? So hat es glaube ich Olaf Willuhn erstmal bei Hibiscus gelöst. Zur Zeit stehen bei mir in Banking 4A Dinge wie "+SVWZ" und die erste Hälfte vom Verwendungszweck im Feld Ende-zu-Ende-Referenz und alles kommt durcheinander.

Es gibt da eine klare Spezifikation, nur hält sich das Sparda-DV RZ leider nicht dran.

Ich bin zwar nicht für Sonderlocken, aber mir wäre es auch sehr lieb, wenn B4* bis auf weiteres die kompletten VZs in die VZ-Felder knallen würde und nicht versuchen würde, die SEPA-Feldschlüssel auszuwerten - was ja bei dem SPARDA-Format nicht klappen kann. Problem ist, dass man sonst im Umsatzarchiv auf Dauer fehlende Informationen beklagen muß. Gerade wenn eine End2End-Ref angegeben ist, dann erkennt B4* die derzeit, nicht aber den nächsten Feldschlüssel. So wird alles ins Ref-Feld geknallt, nur das was nicht mehr reinpaßt (u.a. VZ) geht ersatzlos verloren... Und unter uns - ich gehe nicht davon aus, dass SPARDA-DV da in absehbarer Zeit was korrektes liefert