Änderung bei z. B. Kontoauszugsjahr nicht möglich / fehlerhafte Anzeige des Verwendungszwecks bei bestimmten Buchungen

Da gibt es ziemlich sicher keine Lösung, weil das ein Problem ist, das mit der Einführung von SEPA-Formaten gekommen ist und mit dem Programm nichts zu tun hat. Wenn man Verwendungszweck formatiert eingibt kann man nie wissen, wie der beim Empfänger ankommt.

Hintergrund ist, dass die Banken einen Mischmasch als alten (vor SEPA) und neuen (SEPA) Datenformaten verwenden. Und zwar teils sogar innerhalb einer Bank-EDV verschiedene. Beim Verwendungszweck war es z.B. so, dass der Verwendungszweck aus 14 Zeilen je 27 Stellen bestand. Bei SEPA besteht ein Verwendungszweck eigentlich aus einem langen Feld mit 140 Stellen. Teilweise wird das von Banken aber auch als 4 Zeilen je 35 Stellen interpretiert. Jedes Mal, wenn nun der Verwendungszweck von einer Welt in die andere übergeben wird, wird er etwas anders. Bei Nicht-SEPA zu SEPA werden meist die einzelnen 27er Zeilen erst zu einer langen Zeile zusammengefügt, und zwar mit je einem Leerzeichen dazwischen, das wird dann in 35er Portionen aufgeteilt. Oftmals unter Weglassen von Leerzeichen, die am Anfang oder am Ende einer solchen neuen Zeile stehen. Umgekehrt genauso. 35er Zeilen zusammen und dann auf 27er aufgeteilt. Zusätzlich werden, wenn SEPA im alten Format übertragen wird, auch noch Feldinhalte von neuen SEPA-Feldern, die es im alten Format nicht gibt, mit besonderen Feldschlüsseln zusätzlich in den Verwendungszweck gepackt. Nachdem die Gesamtlänge von SEPA viel geringer ist als die von früher, kann es dabei sogar passieren, dass Teile eines originalen VZ weggelassen werden. Das kann man nicht beeinflussen.

Fazit: B4 überträgt die Zahlungen im SEPA-Format (ein VZ mit 140 Stellen) an die Bank. Wie diese das dann weiterverarbeitet und ob der Umsatzabruf im neuen CAMT-Format oder mit veränderten Texten im alten MT940-Format erfolgt, ist bankabhängig. Und wie der Text beim Empfänger ankommt ist völlig unvorhersehbar. Eine Formatierung von Verwendungszwecken "lohnt" sich also nicht, man hat es nicht in der Hand. Wenn man derzeit programmgesteuert in Verwendungszwecken sucht, führt deshalb kein Weg dran vorbei, aus dem gesamten Verwendungszweck alle Leerzeichen zu eliminieren und in dem entstehenden Bandwurm dann nach Strings zu suchen. Man findet sonst nichts, weil Teile des Strings evtl. durch einfügte Leerzeichen getrennt wären oder erwartete Leerzeichen (wie in Deinem Fall) irgendwo auf dem Weg verloren gegangen sind.

Um welche Bank handelt es sich in Deinem Fall? Hast Du schon mal im WebBanking der Bank nachgeschaut, wie da der Text dargestellt wird? Außerdem kannst Du noch unter Extras/Protokolle in B4 nachschauen, was genau an Text via HBCI von der Bank geliefert wird....

Dass das Leerzeichen bei der eingegebenen Überweisung da ist, ist klar. Dass es in den avisierten Buchungen da ist, ist auch klar, weil B4 da die eigene abgesendete Überweisung darstellt. Erst wenn sie verbucht ist, fällt der lokale Datensatz weg und es wird der Umsatzdatensatz der Bank angezeigt, der vom Bankrechner abgerufen wurde. Und der ist - wahrscheinlich - eben anders.

Wie ich gerade bei einem Test mit Entsetzen feststelle, wurde die Protokollfunktion von B4 verändert - in dem Protokoll ist jetzt "nichts Sinnvolles" mehr drin. Insbesondere die abgerufenen Datensätze sind nicht mehr protokolliert. Insofern kann man meine Meinung auf diesem Weg leider nicht mehr verifizieren.

Man kann doch prüfen, was von der Bank kommt!

• Unter Einstellungen (F12)/Protokollierung auf "Komplette Diagnose" einstellen
  
• Umsatzabruf tätigen (so, dass der bewußte Umsatz übertragen wird, ggf. den Umsatz vorher löschen, wenn er schon da ist)
  
• Unter Extras/Protokolle/Details die übertragene XML-Datei suchen (ggf. vorher das Protokoll als Text speichern und mit dem Editor öffnen). Dort ist der Verwendungszweck zu finden, wie ihn die Bank liefert. Du kannst auch sofort einen Teilstring des Verwendungszweckes suchen. Dann siehst Du, ob die Bank das fragliche Leerzeichen mit sendet (dann ist das Programm an der Anzeige "schuld" oder ob das Leerzeichen schon von der Bank "unterschlagen" wurde)
  

Die Commerzbank liefert die Umsätze leider immer noch im alten, nationalen MT940-Format aus, also ist es leider genau das Problem, das ich angesprochen habe.

Im MT940 gibt es 14 Verwendungszweckfelder zu je 27 Stellen. In denen muss dann sowohl der Verwendungszweck der SEPA-Zahlung (140 Stellen) als auch alle neuen SEPA-Felder untergebracht werden - und da hakts dann oft. Die Angaben zu einem Umsatz beginnen in MT940 mit einem Feldschlüssel - dürfte hier :86: sein. Danach kommen dann die einzelnen Felder - und zwar getrennt durch Subfeldschlüssel, die immer aus einem ? und zwei Ziffern bestehen. Nach ?23 folgt somit das dritte Verwendungszweckfeld zu max. 27 Stellen. Am Ende mit dem nächsten ? beginnt das nächste Subfeld. In diese Verwendungszweckfelder werden bei SEPA dann alle Felder reingezwängt, die es vor SEPA noch nicht gab - und zwar mit Feldkennzeichen. In Deinem Fall ist das SVWZ+ . Dieses Feldkennzeichen steht für Verwendungszweck. Somit wird das Ganze dann mehrfach codiert, erst der SEPA-VZ in "SVWZ+Blablablabla" und das wird dann in die MT940-Felder eingefüllt. Dafür gibt es wiederum Regeln, die aber die Commerzbank nicht wirklich beachtet sondern ihren eigenen Dialekt benutzt.

In Deinem Fall endet also ein 27er Feld mit -019 und das nächste beginnt mit APR. Das Leerzeichen dazwischen fällt bei der Konvertierung dem 27er Zeilenende zum Opfer. Nachdem mitunter nicht alles reinpasst, werden von den Banken auch gerne mal Leerzeichen entfernt, die an Zeilenenden stehen. Dumm halt, dass es hier nicht wirklich an einem Zeilenende steht sondern mitten drin und nur zufällig an ein Zeilenende der alten Welt fällt. Früher hat dieses Entfernen von Leerzeichen am Ende einer Zeile nicht gestört, weil die Zeile ja zuende war... Wenn jetzt zufällig ein Leerzeichen an eine alte Feldgrenze fällt, obwohl es in der neuen Welt mittendrin steht, dann PUFF ist es hinterher weg.

Um also wieder an den Verwendungszweck zu kommen muss das Programm erst mal den Gesamtangaben-Datensatz mit :86: isolieren, dann die VZ-Subfelder ?21 bis ?29 isolieren, diese zusammenpappen und darin dann nach SEPA-Kennzeichen XXXX+ (die eigentlich immer nur am Feldanfang stehen dürften, es bei der Commerzbank aber nicht tun) suchen und daraus dann den Verwendungszweck zusammenbauen und diesen ins SEPA-Datenbankfeld der Anwendung schreiben. Bei dem Hin-und-Her geht bei der Commerzbank Dein Leerzeichen verloren - es wird nicht im Umsatz geliefert.

Wenn Du bei der nächsten Buchung mal vor Deinen VZ noch einige Zeichen davorsetzt (z.B. 12345) dann schiebt sich der Text insgesamt nach hinten, beim Textgefrickel verschieben sich die Grenzen und dann müßte Dein Leerzeichen wieder da sein, weil es dann wieder mitten in einem Text steht und nicht am Rand eines Subfeldes, wo es untergeht.

Ist das halbwegs verständlich, was ich da schreibe? Ich fürchte nein...

Alles in allem: B4 ist nicht schuld, sondern die xfache Konvertiererei zwischen alten und neuen Datensätzen und die Commerzbank, die sich nicht völlig an die Regeln hält sondern ihr eigenes Süppchen kocht. Somit ist das Problem nicht lösbar. Man kann nur hoffen, dass die Commerzbank irgendwann das Geld in die Hand nimmt, ihre Altanwendungen an SEPA anzupassen. Bei den Überweisungen (also reinwärts) mussten sie es, weil die alten DTA-Formate nicht mehr genutzt werden dürfen. Bei der Übermittlung von Umsätzen (also rauswärts) gibt es keine Vorschriften, deswegen haben sich die Privatbanken die Anpassungen gespart und wursteln mit dem alten nationalen Format weiter - mit allen Problemen, die das mit sich bringt. Aber Probleme beim Kunden stören die Banken üblicherweise wenig bis garnicht.