Hibiscus, keine Sonderzeichen und Umlaute möglich?

Guten Morgen banking-Community!

Geht es nur mir so, oder kann man keine "Sonderzeichen" bei einer Überweisung verwenden?

Wobei ich die folgenden "Sonderzeichen" (u.a. Umlaute) eher deklarieren würde als "geläufige und häufig genutzte Zeichen".

Beispiele: & (GmbH & Co. KG), Ä, Ö, Ü und das €-Zeichen, wobei letztes sich mittels "Alt Gr + E" gar nicht erst eingeben lässt.

Beispiel:
Käthe Kürbis muss ihre Domain dieärzte.de bei Provider Münchner Präzisionshosting GmbH & Co. KG per Überweisung bezahlen und diese als Verwendungszweck angeben. Sie müsste folglich das ü, ä und & als "ue", "ae" und "und" schreiben und dennoch kann ihre Zahlung der Domain nicht sofort und eindeutig zugeordnet werden, da sie laut Verwendungszweck fälschlicherweise für dieaerzte.de und nicht für dieärzte.de zahlt.

Also, geht's nur mir so? =) =]

Allem voran ist aber zu bemerken, daß gerade das & Zeichen im SEPA-Zeichensatz NICHT erlaubt ist. Im alten DTAUS-Zeichensatz des ehemaligen Inlandszahlungsverkehrs war es noch erlaubt jetzt nicht mehr. Und mit den restlichen Umlauten ist das so eine Sache: In früheren SEPA-Spezifikationen waren die Umlaute auch NICHT erlaubt, deswegen wird die Eingabe in halbwegs sinnvollen Kundenprodukten gleich unterbunden. Inzwischen sind in den neuesten Spezifikationen Umlaute erlaubt (das & nach wie vor nicht). Allerdings verwenden nicht alle Banken immer die neueste Spezifikation, so daß derzeit ein buntes Durcheinander herrscht und man Umlaute nach wie vor nicht verwenden sollte, wenn man keine überraschenden Effekte erleben will. Wenn nämlich Umlaute an einen Bankrechner übertragen werden, der sie beherrscht ist alles gut, wenn nciht, wird der Bankrechner den Auftrag entweder ablehnen oder "selbst tätig". Das kann bedeuten, daß er alle ä mit ae ersetzt und damit den Text verschiebt - mit allen Auswirkungen auf eine geplante Formatierung (wobei die eh wegen verschiedener Zeilenlängen auf verschiedenen Bankrechnern meist in die Hose geht). Andere Möglichkeiten sind komplettes Ausfiltern und Weglassen der Umlaute (dann wird "Kthe Mller" aus "Käthe Müller" - auch nicht schön) oder Ersetzen der Umlaute durch Leerzeichen ("K the M ller"). Und dies kann nicht nur beim ersten beteiligten Bankrechner passieren, sondern auch bei Übergabe der Texte von Bank zu Bank. Somit hat der Kunde eigentlich keinerlei Möglichkeit, zu bestimmen, was beim Empfänger ankommt, wenn er Umlaute (und nicht zugelassene Sonderzeiten) verwendet, von Zeilenlängen wollen wir garnicht erst reden. Verwendungszweck ist bei SEPA 140 Stellen, manche Banken definieren ihn komplett (so ist es eigentlich auch), manche verwenden 2*70 Stellen, manche 4*35. Teils als eigene Zeilen, teils hintereinandergeklemt mit oder ohne Leerzeichen und und und. Endlose Variationsmöglihkeiten.

Insofern ist die Frage, ob Hibiscus da nicht vielleicht etwas "besser" machen kann irgendwo recht naiv, denn Hibiscus kann eigentlich am allerwenigsten irgendwas machen, solang jeder Bankrechner macht, was er will.

P.S.: Und wer Domains durch Angabe des Domainnamens zahlt und nicht durch eine Kunden- oder Vertrags- oder Rechnungsnummer, der ist auch naiv. Denn dieses Vorgehen verursacht immer Nacharbeit in der Buchhaltung, denn es ist mit an Sicherheit grenzender Wahrscheinlichkeit NICHT so, daß das Kundenkonto in der Buchhaltung mit dem Domainnamen angelegt ist - und auch der offene Posten, der bezahlt werden soll, ist sicherlich nicht unter dem Domainnamen (oder irgend einem anderen Spezifikum mit Umlauten) angelegt. Somit muß dann ein armer Buchhaltungsmitarbeiter diesen offenen Posten unter Hinzuziehung von Listen (oder Lookupfunktionen) meist händisch zuordnen. Das sagt Dir jemand, der das leidvoll aus der Immobilienverwaltung kennt, weil viele Wohnungsnutzer kreativ "Miete Sowiesostr. 14" in den Verwendungszweck schreiben und nicht um's Verrecken ihre Mieter- oder Eigentümernummer oder Wohnungsnummer oder so. Besonders wenn über das Konto 50 Wohnungen in der Sowiesostr. 14 abgerechnet werden (oder gar eine ganze Wohnanlage mit Hunderten Wohnungen) und dann noch nicht der Mieter unter eigenem Namen überweist, sondern eine Freundin oder Familienangehörige mit teils völlig anderem Namen, dann wird's mühsam und nervig... Und wenn diese Leute dann eine Mahnung erhalten, weil solche Zahlungen absolut nicht zugeordnet werden können, dann sind sie beleidigt...

Das hilft Dir leider auch nicht weiter. Schon allein deshalb weil der Unterstrich.... geau. Nicht erlaubtes Zeichen im SEPA-Zeichensatz

Unabhängig davon werden ggf. von den beteiligten Bankrechnern wieder eigene Leerzeichen eingestreut. Fiktives Beispiel:
Der Zahler arbeitet mit einer Software, die in der Generierung des Auftrages (Gehaltsabrechnungs-Zahlungsdatei oder Maskenerfassung) mit den guten alten Vor-SEPA-Feldern mit 27 Zeichen arbeitet. Die Übertragungssoftware muß das zusammenfassen in 35er oder 70er oder 140er Feld/er. Die geben üblicherweise die ersten 27 Zeichen ins Feld, dann ein Leerzechen (!), dann wird auf 35 bzw. 70 mit dem Anfang der nächsten Ursprungszeile aufgefüllt, dann im nächsten Feld mit dem Rest der zweiten Ursprungszeile weiter, wieder ein Leerzeichen, dritte Ursprungszeile usw. Dann geht es weiter, die nächste beteiligte Bank baut es evtl. wieder in kürzere Teilfelder um und so weiter. Am Ende muß das dann entweder für den Papierkontoauszug gemäß Layout umgebaut werden (wird halt wieder mit dem großen Hammer eingepaßt) oder für die Übertragung an den Empfänger in Datensätze gestellt. Ggf. in das alte MT940-Format, wo die ganzen neuen SEPA-Felder nicht existieren und deswegen mit vorgelagerten Feldschlüsseln mit in den Verwendungszweck kommen. Somit steht dann im Verwendungszweck-Feld alles mögliche drin, z.B. EREF+xxxxx, also End2End-Referenz xxxxx. Der eigentliche Verwendungszweck - bzw. das war bei der endbeteiligten Bank angekommen ist - folgt auf den Feldschlüssel SVWZ+
Was da dann rauskommt ist völlig unvorhersehbar.

Wenn man sowas maschinell verarbeiten will geht es derzeit eigentich nur, alle Verwendungszweckzeilen aneinanderzupappen, alle Leerzeichen daraus komplett zu entfernen und dann zu suchen, ob man darin irgendwas findet. So würde dein beispiel "Jan. xxxx" auch wieder zu finden sein...

Und was das & betrifft: Wir haben für einige Firmen, die das & im Namen führen, bankseitig die Kontobezeichnung gegen den anfänglichen Widerstand der Hausbank umstellen lassen. Von bsp. "Müller & Huber GmbH" auf "Mueller + Huber GmbH". Das + ist nämlich ein zugelassenes SEPA-Zeichen. Der Firmenname ist zwar nicht mehr so wie im Handelsregister, aber es ist "weniger schlecht" wenn das Konto bei der Gegenseite als "Mueller + Huber GmbH" ankommt, als wie vorher, wo der Absender dann "Mller Huber GmbH" war. Das haben letztendlich sogar die Hausbänker eingesehen

Doch noch was zum Thema "besser machen".
Mir ist es im Verwendungszweck einige male passiert, daß ich Umlaute usw. getippt habe. Man bekommt dann keine Meldung - das Zeichen wird einfach nicht angenommen.
In der Empfängerzeile wird es angenommen. Man bekommt aber beim Abschicken eine Fehlermeldung.

Mein Vorschlag: in beiden Eingabefeldern die Sonderbuchstaben automatisch in ae, oe, ss usw. umwandeln. (Wenn ich mich recht erinnere, machen das andere BankingClients auch so.)

Grüße

@ msa: hahaha, du hast natürlich Recht - da hatte ich beim wühlen nach Lösungen nicht dran gedacht: Den_als_Verbinder geht ja nicht. :whistle:

Das piepen (optional als "Akustisches Feedback: ja/nein") wäre eine Bereicherung. Habe da gestern auch dran gedacht, als ich an einen erneuten Defekt meiner Tastatur dachte, hihi ... aber für die anderen Sachen gibt es ja bereits einen Hinweis (mit kleinen Schwächen), zumindest bei den Umlauten, denn z.B. beim €-Zeichen ist es wie gesagt so, dass "nichts passiert" (da die Eingabe gesperrt wurde).

Fehler in Hinweismeldung:

Bsp. 1.) = nur das "böse Zeichen" wird (nicht praxisnah, ich weiss) benutzt
Bsp. 2.) = "böses Zeichen" in einem Wort

Die Meldung lautet (richtig): 1.) Das Zeichen "ü" darf in "ü" nicht ... oder 2.) "ü" darf in "Kürbis" nicht ...

stattdessen heisst es bei "&": 1.) Das Zeichen "" darf in "" nicht ... oder 2.) "" darf nicht in "Gmbh _Co" nicht ...

Das mit dem Umwandeln (sme, #7) find ich einen tollen Vorschlag, allerdings sehe ich ein solches Verhalten ähnlich wie msa.

Daher mein Vorschlag zum Vorschlag:

Der Benutzer sollte eingeben (können) was er will und vor dem senden wird, um eine möglichst hohe Kompatibilität zu erreichen, alles nötige (im Hintergrund) konvertiert. Aus "ü" wird "ue", aus "&" wird "und". Das tut dem Benutzer nicht so arg in den Augen weh.

das ist aber sehr kurzsichtig denn dann kommt es trotzdem falsch an.
da die Entwickler immer nach Spezifikationen gehen, müsste auch hier die letzte greifen und was die Bank/Banken dann draus machen oder nicht (es müsste ja theoretisch jeden Tag bessern werden), muss dann akzeptiert werden