Dass die Gesamt-Stellenanzahl falsch ist, hatte ich ja nicht behauptet. Aber die Auftreilung auf einzelne Felder ist falsch und eben auch kontraproduktiv, weil damit der Text noch mehr verhackstückt wird, als es es eh schon wird, weil der "normale Nutzer" dann mit Abkürzungen usw. arbeitet, um die Felder einzeln zu füllen. Beim Zusammenfassen werden dann dazwischen sinnlose Leerzeichen gesetzt, oder auch nicht... Alles in allem Murx und eben nicht der Definition entsprechend. Wenn es dann auch noch 27er-Felder von nach'm Krieg sind... gute Nacht.

haben aber manche Mitbewerber auch bzw. wenigstens wird es so in der Ansicht dargestellt.
anstatt sich mal von dem "Formular" zu verabschieden und einfach minimalistisch die Daten abzufragen.

aber wo soll man da anfangen/aufhören, gibt einige Punkte die nicht mehr zeitgemäß sind.

Eben. Drum sperre ich mich dagegen, so einen altbackenen Murx als leuchtendes Vorbild hinzustellen.

Ich bin nun wirklich nicht als jemand bekannt, der modenen Strömungen hinterherläuft, ich halte immer extrem lang an althergebrachtem - auch Benutzeroberflächen - fest, weil ich die meistens einfach zweckmäßiger finde, als das moderne überladene. Aber hier sollte man echt den alten Zopf abschneiden.

Naja, die Aufteilung auf 4 Zeilen ist eh sinnvoll, weil eine Aufteilung nötig ist. Das gebietet die Lesbarkeit (Typografie) gerade bei Daten. In den meisten Fällen reicht eine Zeile. Denkt dabei an die Nicht-HBCI-User mit 15.4" Schirmen, die das auch im Browser lesen können möchten. Beim Verwendungszweck ist ja übrigens eh fraglich, ob alles beim Empfänger ankommt.
Und dann waren und sind da auch die Konvertierer. Es wäre einfach nicht sinnvoll gewesen, die den Mengen an vorhandenen Datensätzen irgendwie auf ein Feld zu 140 Zeichen umzubrechen.
Was ich persönlich gut finde, ist ein Modus bei der Erfassung, der automatisch bei Leerzeichen und größeren Wörtern ins nächste Feld springt, so wie das hier im Forum läuft.
Gruß
Raimund

aber gerade die Aufteilung ist doch irreführend, denn der unbedarfte User glaubt, dass die 4 "Text-Päckchen" so beim Empfänger eintreffen.
hierdurch, wird nämlich jedes Feld neue angefangen besetzt und die Software generiert hieraus den Fließtext, was der Absender/Auftraggeber aber nicht will.
Die Aufklärung ist langwierig, da es doch so auf dem Bildschirm dargestellt wird.

Dh. der Kunde will es einfach haben, wenn es ein Fließtext ist, dann bitte auch den VWZ so darstellen, zur Not bei kleinen "Schirmen" halt nach rechts "laufend".

Die Entwickler (Mitbewerber von o.g.) sieht dies auch, weißt jedoch eher auf das Papierformat hin und dass es halt dort schon immer so war.
was ja nicht stimmt, denn dort ist es ja auch ein Fließtext lediglich erfolgt die Begrenzung durch die Papierbreite und hier sollte theoretisch auch ein "update" erfolgen.
(Hinweis: dies betrifft nur den VWZ ...)

Genau das isses! Mit den vermeintlichen Zeilen wird der Nutzer dazu animiert, den Text zu formatieren, und genau das kommt beim Empfänger so eben NICHT an. Und bei der weiteren Konvertiererei zwischen 140 ganz, 40er Felder, 27er Felder und zurück kommen dann noch mehr Umbrüche und Leerzeichen an Stellen rein, die völlig widersinnig sind. Aus dem Grund ist es eben gerade sinnvoll, einen 140stelligen Text ohne Feldgrenzen einzugeben. Dabei kommt mit der Konvertiererei bei dem Emfänger auf jeden Fall etwas weniger Schlechtes an, als mit den Fake-Feldern. Das Ganze ist derzeit ja so unmöglich, dass einem, wenn man automatische Abgleiche macht, nichts anderes übrig bleibt, als alle Verwendungszwecke (wenn denn mehrere Felder ausgeliefert werden) zusammenzuhängen, dann sämtliche Leerzechen zu entfernen und DANN nach irgendwelchen Strings zu suchen.

Wie man mit dem Verwendungszweck am sinnvollsten umgeht, zeigt mal wieder Subsembly. Dort gibt der Erfasser seinen Text in ein mehrzeiliges Feld ein, dieses wird automatisch ungebrochen, wenn der Text für eine Zeile zu lang wird. Sobald man das Feld verlässt, wird dann ein Textstring draus gemacht, indem sofort sichtbar alle Zeilenumbrüche entfernt werden und mehrere Leerzeichen hintereinander in ein Leerzeichen umgewandelt werden.

Das hat mich anfangs etwas verwirrt. Macht das Programm doch tatsächlich meine schöne Formatierung kaputt ...

Ja, aber es ist am ehrlichsten und sinnvollsten, weil es eh nicht so formatiert beim Empfänger ankommt...

Das finde ich ja auch gut, nur weiß das der "normale" Anwender ohne das Hintergrundwissen ja nicht. Deshalb war es für mich erst mal überraschend und deshalb könnte dieses Feature der App auch negativ ausgelegt werden.
@subsembly: Vielleicht wäre hier ein Infotext sinnvoll?

Das führt korrekt zu einem zusammenhängenden Textstring von maximal 140 Zeichen.

Nur die Banken behandeln diesen Textstring unterschiedlich.
Die Postbank beispielsweise zerlegt im Webbanking den Textstring rigoros in 35 Zeichen pro Zeile, im Kontoauszug in 52 Zeichen pro Zeile.

mfg Volker

Das ist schon klar, aber ein zusammenhängender Textstring, der dann zerhackt wird, ist "weniger schlimm" als ein String, der erst in 27ern angenommen wird, dann per 27 + leerzeichen + 27 + leerzeichen.... zu einem String zusammengesetzt wird, bei der nächsten beteiligten Bank wird er dann in 35er Feldern gespeichert und für den Kontoauszug dann wieder mit 35 + leer + 35 + leer... zusammengesetzt und dann schließlich in 52er portionen abgedruckt. Die ganzen unnötigen Leerzeichen befinden sich dann natürlich nach wie vor drin und Wörter sind so und so irgendwo umgebrochen...

da die Banken es in der "Selbstverwaltung" nicht hinbekommen, sollte die EU mal ein Machtwort reden
schlussendlich wird Geld für das Konto bzw. die Transaktion verlangt

PS: wobei das Bild von "Seite 1" aber auch irreführend war.
klick

Welchen Sinn hat es, den Screenshot eines 6 Jahre alten Programms zu posten und dann darüber zu diskutieren?
Der erste Screenshot zeigt Moneyplex 12.

gutes Design ist zeitlos

Wenn ich mich nicht verzählt habe, würde die Postbank den Verwendungszweck folgendermaßen darstellen:

Rechnung Nr. 1234567 Kunden-Nr. 778
980

Sehr lustig.

Kürzlich wollte ein Online-Händler im Verwendungszweck partout die Rechnungsnummer in der 1. Zeile und den Namen in der 2. Zeile eingetragen wissen, zusammen weniger als 35 Zeichen. Das wäre dann nicht möglich -;)

mfg Volker

Richtig, nachdem es keine Zeilen gibt, ist das nicht möglich. Aber die Kundennummer ganz zu Beginn macht durchaus Sinn, weil damit die höchstmögliche Wahrscheinlichkeit erreicht wird, dass diese Nummer in jedem Fall beim Empfänger ankommt und auch nicht durch bei Konvertierungen eingestreute Leerzeichen unterbrochen wird.

Eigentlich wäre das Feld "Ende zu Ende Referenz" min. genauso wichtig wie den VWZ. Wo ist das Feld? Gibt es immer noch Banken, die das nicht sauber umsetzen?

Also, ich kann mit der Ende-zu-Ende-Referenz nichts anfangen, die Postbank scheinbar auch nicht. Im FinTS-Protokoll ignoriert die Postbank die "EndToEndID" vollständig.

Die Stadtsparkasse München beißt sich da was ab, indem sie den Parameter "EREF+" vor die Ende-zu-Ende-Referenz setzt und damit die ohnehin nur 27 Zeichen lange Zeile um eine weitere Zeile verlängert.

Ebenso verfährt sie mit dem Verwendungwzweck, indem sie den Parameter "SVWZ+" davorsetzt.

mfg Volker

Dann lieber Volker, fragst Du die Umsätze im alten MT940-Format ab, in dem es diese Felder noch nicht gab. Es gibt aber eine Norm, wie die neuen Felder bei Verwendung von MT940 eingestellt zu werden haben, damit Programme das automatisiert zerkegen können. Und genau das macht das Sparkassen-RZ FI. Die Einstellung erfolgt mangels anderer Möglichkeiten in die Verwendungszweckfelder und zwar so, dass an den beginn des Feldes ein Feldschlüssel gestellt wird - und der lautet nun mal für den Verwendungszweck SWVZ- und für die Ende-zu-Ende-Referenz EREF+. Direkt nach dem + geht dann der Feldinhalt los, wenn die 27stellige Zeile nicht ausrecht, geht es direkt in der nächsten Zeile weiter. Wenn das einzustellende Feld zu Ende ist, bleibt der Rest der 27er Zeile leer und es geht auf der nächsten Zeile mit dem nächsten Feldschlüssel weiter. So wie FI das macht ist das 100% regelkonform. Eigentlich sollte Dein Programm diese Feldschlüssel interpretieren und die Inhalte korrekt auf die richtigen Felder verteilen - unter Weglassung der Feldschlüssel - das tut es aber offenbar nicht Genauso ist das mit der E2E-Referenz: Nach den Vorgaben gibt es KEINE leere E2E-Referenz. Wenn es keine gibt, ist die Konstante NOTPROVIDED einzustellen - die von jedem "vernünftigen" Programm natürlich bei der einstellung in die Datenbank unterdrückt wird.

Allerdings ist diese Übertragung nur noch für "alte" Programme vorgesehen, die nur MT940 beherrschen (z.B. Fibu-Programme, die selbst abholen). Normalfall für die Übertragung ist inzwischen das Format CAMT - ein XML-SEPA-Format. In diesem gibt es alle "neuen Felder" nativ und es bedarf keiner Hilfskonstruktionen.

Somit solltest Du Deinen Abruf auf CAMT umstellen (was FI natürlich auch anbietet) und schon hat Du alles sauber...

Danke für die ausführliche Erläuterung zu meinem alten MT940-Format.
Ich hatte nur das FinTS-Protokoll meines alten Bankingprogramms interpretiert, es zeigt aber die korrekten Felder an:

EndToEndID.........: ZV<22 Ziffern>
CustomerReference..: NONREF

mfg Volker