SEPA-Wahnsinn
Ich fass es nicht. Ich wollte gerade jemandem was überweisen, SEPA und so.
Eigentlich dachte ich, SEPA wäre eine europäische und keine amerikanische Erfindung. Weils doch für die EU gedacht ist, heißt ja immerhin Single Euro Payments Area.
Ging nicht. Jedenfalls nicht so wie ich wollte. Weil der Empfänger im Namen einen Umlaut hatte. Ich musste ein ü durch ue ersetzen.
Ich fass es nicht.
Nun hocken wir in Europa, einem Haufen von Staaten, die fast alle landesspezifische Sonderzeichen außerhalb des ASCII verwenden. Und bauen unser eigenes Überweisungssystem. Und dann kann es keine Umlaute.
Was steckt denn da wieder für ein Wahnsinn dahinter?
Ist das Ding am Ende so gebaut, dass die Amerikaner das möglichst leicht in ihre Datenbanken importieren können? Sind die Verwendungszwecktexte deshalb vielleicht so kurz? Haben die deshalb die einheitlichen Nummern eingeführt, damit man das leichter überwachen und durchsuchen kann?
Oder ist nur meine Bank wieder mal zu doof?
22 Kommentare (RSS-Feed)
Diese Umlautproblematik wird wohl eine Never-Ending-Story, damit werden sich die IT-ler bestimmt auch noch im Jahr 2514 rumärgern müssen. Sogar die Linuxer kriegen das nicht hin:
http://www.golem.de/news/schroedinger-s-cat-fedora-19-mit-uefi-problemen-1304-98703.html
Vielleicht unterschätzest Du der Verbreitungsgrad von 70er/80er-Technologie in der Finanz-IT und die lange Entstehungszeit von Standards wie SEPA.
Herrje, man kann auch wirklich in jedem Furz eine Verschwörung wittern. Wird man nur leicht wahnsinnig dabei.
Der Grund ist wohl eher, das die Umlaute entfallen, eben WEIL jeder europäische Staat eigene hat. Da trifft man sich eben auf dem kleinsten gemeinsamen Nenner, statt ewig viele Sonderwürste auf diversen Übertragungskanälen zu braten.
Zumal der Sinn einer Überweisung ist, Geld zu transferieren und nicht grammatikalisch korrekte Romane zu schreiben.
Einfach, simpel und möglichst wenig mögliche Fehlerquellen hat halt Vorrang vor rein optischem Blödfug.
Vielleicht kann Cobol keine Ümlaute?!?
Da ist Deine Bank einfach zu doof, alle Sepa-XML Dateien sind im utf-8 Format und müssen alle entsprechenden Zeichen verstehen.
Aber ich kann Dir aus eigener Erfahrung sagen – wir schreiben Software für Banken – das Problem liegt woanders:
Viele Banken verwenden Großrechner die dort seit den 80ern im Einsatz sind und an die sich schlicht keiner mehr ran traut. Wie sollen diese also die neuen XML-Dateien verarbeiten? Das ist ganz einfach, die werden von der Frontendsoftware einfach in das alte Format umgerechnet. Da wird die Kontonummer und die BLZ aus der Iban geholt und dann vom pain-Format (da sag einer ITler hätten keinen Sinn für Humor) ins alte Dtaus, MT940 oder was der Großrechner auch immer will umgewandelt.
Und wenn man da nicht aufpasst (ja, ist uns auch passiert) dann wird z.B. der Verwendungzweck ordentlich abgeschnitten nach der erlaubten Anzahl von Zeichen, aber Umlaute/Sonderzeichen haben wir nicht beachtet (weil natürlich auch sämtliche Testdateien der Banken keine enthielten). Und schon hat der Verwendungszweck ein Byte mehr als erlaubt, und schon schmeisst der Großrechner eine kryptische Fehlermeldung raus die kein Mensch mehr entschlüsseln kann.
Das ist natürlich ein Fehler den man selbst im Client – oder gar auf den Backend-Servern – behebt und nicht auf den Endnutzer abschiebt, aber alles ausser ASCII verbieten ist die einfachste und sicherste Methode…
Gibt es eigentlich international genormte Transkriptionsvorschriften? Also eindeutige ASCII-mappings für Søren, für ????????? ???????, für ???? Muss ja eigentlich… Wie soll sonst, sagen wir mal ein griechischer Landwirt, jemals widerspruchsfreie SEPA-Zahlungen empfangen können? Hmmm…
In related matters: Poettering macht jetzt auch den Kernel kaputt: http://www.heise.de/open/news/foren/S-Re-Hab-Angst/forum-273358/msg-24672920/read/
Also Cobol hat mit Umlauten kein Problem. Die meisten Großrechner nutzen EBCDIC, und da sind die Umlaute wunderbar kodiert, und die Umkodierung auf was-auch-immer ist auch kein Problem.
“Und wenn man da nicht aufpasst (ja, ist uns auch passiert) dann wird z.B. der Verwendungzweck ordentlich abgeschnitten nach der erlaubten Anzahl von Zeichen,.::”
So ähnlich ist uns das auch passiert (war Testleiter bei der SEPA-Umstellung einer größeren Direktbank). Bei uns lags nur dran, das Unix-Zeilenenden irgendwo in CR/LF gewandelt wurden und bumm, hatten wir 5 Zeichen zuviel in der DB. Sonderzeichen hatten wir natürlich, weil wir über HBCI und obskure Clients eh alles mögliche reinkriegen.
Die Behauptung, das das SEPA-Format alle Zeichen zulassen würde, ist nur insofern richtig, als das rein technisch für die XML-Dateien gilt.
Das ist aber irrelevant, weil *fachlich* Folgendes festgelegt ist:
“In SEPA-Zahlungen sind gemäß Anlage 3 des DFÜ – Abkommens als zugelassene Zeichen nur die des eingeschränkten SWIFT Latin Character SET vorgesehen.”
Nicht einmal ASCII ist komplett erlauubt.
Für die Erstellung von SEPA-Nachrichten sind die folgenden Zeichen in der Kodierung gemäß UTF-8 bzw. ISO-885933 zugelassen:
Numerische Zeichen (0 bis 9), Großbuchstaben (A bis Z), Kleinbuchstaben (a bis z), Apostroph, Doppelpunkt, Fragezeichen, Komma, Minus, Pluszeichen, Leerzeichen, Linke Klammer, Rechte Klammer, Schrägstrich.
Damit eben schon einmal nicht: Ausrufezeichen, Semikolon (wahrscheinlich zerhaut es sonst die Datenbankanfrage), Punkt, Sternchen (*), Unterstrich, Gleichheitszeichen, usw. Mit so hochkomplexen German-Umlauts muss man da gar nicht erst anfangen.
Schön finde ich auch die Umschreibung “SEPA-Nachrichten”. SEPA ist das neue Twitter mit noch besserer Überwachung. 😉
wat
jeder Deppenmailclient kann rfc822 und Co…
“In SEPA-Zahlungen sind gemäß Anlage 3 des DFÜ – Abkommens als zugelassene Zeichen nur die des eingeschränkten SWIFT Latin Character SET vorgesehen.”
Ganz so einfach ist es auch nicht, denn es gibt keinen Standard den man nicht nicht einhalten kann. Laut http://www.ebics.de/fileadmin/unsecured/anlage3/anlage3_spec/Anlage3_Datenformate_V2.7.pdf , Abschnitt 2.1, müssen Sepa-Dateien die vormals gültige Zeichen (insb. Umlaute) enthalten weiterhin akzeptiert werden.
auch in Österreich haben wir damals das interne Format nicht angetastet, sondern nur konvertiert. “getraut” hätten wir uns schon, aber es ist schlichtweg zu teuer, ein seit ~20 Jahren laufendes System umzubauen. Im IZV ändert sich sonst ja nichts.
Umlaute und manche Sonderzeichen wie § machen aber immer bei der Umwandlung von ASCII in EBCDIC und zurück Probleme, da je nach Codepage die Dinger im EBCDIC-Format woanders liegen. Das trifft einem sogar schon beim Programmieren, wenn man eine Tochterfirma in Ungarn hat und deren Source-Code hier keiner ändern darf, bevor er nicht die Codepage im Editor geändert hat.
Also besser kleinster gemeinsamer Nenner. Was das auch für ein Aufwand wäre, alle Besonderheiten der Dänen, Schweden, Ungarn, Tschechen, … kreuzweise zu testen.
@Patrix: Ja, das habe ich heute so indirekt bestätigt bekommen im Rahmen eines Projektes. Da ist (ausser in einigen osteuropäischen Ländern, die haben in den neunzigern neu angefangen) viel Wildwuchs, bei dem keiner mehr so richtig weiß, warum das jetzt noch läuft. Anhalten und verbessern will man aber auch nicht. In dieser Welt sind ja Millionenwerte mal eben in Minuten vernichtet.
“jeder Deppenmailclient kann rfc822 und Co…”
Nö.
http://quetzalcoatal.blogspot.de/2013/09/why-email-is-hard-part-1-architecture.html
http://quetzalcoatal.blogspot.de/2013/10/why-email-is-hard-part-2.html
http://quetzalcoatal.blogspot.de/2013/11/why-email-is-hard-part-3-mime.html
http://quetzalcoatal.blogspot.de/2013/12/why-email-is-hard-part-4-email-addresses.html
Viele Banken verwenden Großrechner die dort seit den 80ern im Einsatz sind und an die sich schlicht keiner mehr ran traut. Wie sollen diese also die neuen XML-Dateien verarbeiten?
Das ist übrigens eine Form des Cargo-Kults. Wegen dieses Effekts bricht jede technisch fortgeschrittene Zivilisation früher oder später zusammen: Weil das Wissen verlorengegangen ist, wie etwas funktioniert und nur noch die Erbstücke am Leben gehalten werden.
Gerade die IT ist ja so ein Beispiel, wo angebliches “Wissen” ganz schnell “veraltet” und dann schließlich komplett verlorengeht. Weshalb ich mich inzwischen weigere, “computer science” als echtes wissenschaftles Fach anzusehen.
In diesem Kontext kann man dann auch die SEPA-Migration sehen: Da wird jetzt immer weiter draufgesattelt, bis nichts mehr funktioniert. Ich bin mir ziemlich sicher: Schon 2150 wird es auf diesem Planeten keinen weltumspannenden elektronischen Zahlungsverkehr mehr geben, bis er dann gegen 4000 wieder neu erfunden wird…
Ich bin eigentlich ganz dankbar, dass nicht die Sonderzeichen und Umlaute aller europäischen Länder von SEPA unterstützt werden. Wenn ich mir die ganzen æ, ç, ÿ, ?, ? usw. nicht einprägen muss, von griechischem, kyrillischem und anderen Alphabeten ganz zu schweigen, bin ich dafür bereit, die vier deutschen Umlaute ö ä ü ß durch oe ae ue ss zu ersetzen 🙂
Ich bin eigentlich ganz dankbar, dass nicht die Sonderzeichen und Umlaute aller europäischen Länder von SEPA unterstützt werden.
Ich finde, man sollte da gleich konsequent sein und auch Umlaute wie K, J/Y, U, W, X und Z aus dem SEPA-Zeichensatz streichen, diese können problemlos durch C, I, V, VV, CHS und TS ersetzt werden.
@Hadmut: “u
@Puri:
Großrechner?
“Das ist ganz einfach, die werden von der Frontendsoftware einfach in das alte Format umgerechnet. Da wird die Kontonummer und die BLZ aus der Iban geholt und dann vom pain-Format (da sag einer ITler hätten keinen Sinn für Humor) ins alte Dtaus, MT940 oder was der Großrechner auch immer will umgewandelt.”
=> EBCDIC
http://de.wikipedia.org/wiki/Extended_Binary_Coded_Decimals_Interchange_Code
$ man 7 Lochkarte
Härtetest innert der EU:
Árvízt?r? tükörfúrógép
Wahrscheinlich sind deswegen keine Umlaute implementiert, weil man mit diesen leicht zum Terroristen wird:
> http://www.tagesanzeiger.ch/zuerich/Die-uePuenktliPosse/story/29970854