Windows-Programm für Onlinebanking

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.

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.

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 ...)

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

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 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...

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.

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

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?

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...