Nein, so nützt das nichts, du hast ja 99 % des Inhalts maskiert. Wie soll man da feststellen, was in den Feldern stand?

Fehler gefunden
Unter Kontoinhalber war mein Name in folgender Art eingetragen:
"XXXXX, XXXX XXXX; XXXX" Also mit einem Semikolon.

Semikolon entfernt; gespeichert und alles funktioniert.


EDIT: Ich habe nur bei meinem Namen die normalen Buchstaben (A-Z) maskiert und die Kontonummer.
So etwas möchte ich ungerne in einen öffentlichen Forum stehen haben.

Aha. Und wo kommt das Feld her? Gibst du das in Hibiscus bei den Auftraggeberdaten selbst ein oder zieht es sich das von der Bank?
Wenn es ersteres ist Rüffel an Olaf, in SEPA nicht zugelassene Zeichen müssen auch im Auftraggeberbereich unzulässig sein.

Hibiscus zieht sich die Informationen aus den beim Konto hinterlegten Informationen und diese Informationen hat Hibiscus sich bei der Erstbenutzung von der Bank gezogen.

Ah ok, dann nochmal an Olaf ohne Rüffel sondern als Vorschlag: Alles, was man von der Bank diesbezüglich abruft durch den SEPA-Zeichensatz-Filter schicken. Wir haben nämlich auch diesen Fehler schon mehrfach gehabt.

ich hab die SEPA-Umstellung zum Anlass genommen, bei der Bank den "Namen" zu berichtigen, nämlich statt A&B zu A+B somit sind die Daten für alle Drittprogramm iO

Also direkt beim Abrufen will ich das ungern schon rausfiltern. Hibiscus selbst hat ja keine Probleme mit Sonderzeichen oder Umlauten. Ich denke, wenn es die Bank so schickt, dann kann es Hibiscus auch so anzeigen.

Das Problem entsteht lediglich, weil das Semikolon in SEPA nicht erlaubt ist. Wobei mich hier im konkreten Fall wundert, wie da ein Semikolon von der Bank gesendet werden konnte. Schliesslich ist das z.Bsp. in DTAUS auch schon nicht erlaubt gewesen. Sprich: Das war bereits vor der SEPA-Umstellung ein problematisches Zeichen.

Aber zurueck zum Thema: Fuer das automatische Ersetzen von unerlaubten Zeichen beim Versenden von Auftraegen habe ich noch keine Loesung gefunden, die mich wirklich ueberzeugt. Sinnvollerweise sollte das in HBCI4Java (also der separaten Protokoll-Implementierung) passieren, da erst dort klar ist, welche PAIN-Version zum Einsatz kommt und daher auch erst dort klar ist, ob z.Bsp. äöü usw. erlaubt sind oder nicht. Allerdings ist der Auftrag zu diesem Zeitpunkt bereits aus Hibiscus "raus". Bisher ist es nicht moeglich, Ersetzungen oder Zeichen-Entfernungen an Hibiscus zurueckzumelden. In Hibiscus wuerde der Auftrag dann nach wie vor Zeichen enthalten, die so gar nicht an die Bank gesendet wurden. Ich wuerde das daher schon lieber in Hibiscus machen. Und dort dann eigentlich nicht kommentarlos sondern wenigstens mit Warnhinweis, welche Zeichen jetzt konkret entfernt wurden.

Lange Rede, kurzer Sinn: Alles technich nicht unmoeglich. Aber ich haette gern eine saubere und ordentliche im Programmcode. Daher will ich hier keinen Schnellschuss machen, sondern lieber in Ruhe ueberlegen, wie man das am sinnvollsten umsetzt. Und daher wirds noch etwas dauern.
Wichtiger war mir jetzt erstmal der Import und Export von SEPA-XML-Dateien.

Ja, Prios sind korrekt. Aber hast du mit dem Import das Problem der erlaubten Zeichen nicht schon wieder? Du musst doch an irgend einer Stelle prüfen, was da angeliefert wird.
Ich kann dazu soviel sagen: Meine alte Grundregel "Plausibilitäten für Eingaben sobald sie absehbar sind" hat sich hier bei SEPA bewährt. Schon bei der Eingabe von Texten achte ich darauf, dass nur zugelassen wird, was auch in die Ausgabe darf. Und dass ab 2.7 auch Umlaute zulässig sind erzähle ich einfach keinem bis es 2.6 nicht mehr am Markt gibt

Und beim Import muss man sich ja nicht nur mit Umlauten rumschlagen sondern auch schon wieder mit Zeichensätzen. Was machst du, wenn du eine XML Datei mit Umlauten bekommst, die aber nicht wie es im Kopf steht UTF sondern ISO ist? Selbst wenn im Kopf ISO steht und sie auch ISO ist, denkst du dann an die umkodierung nach UTF? Falls ja, machst du die doch auch nicht erst bei der Ausgabe sondern direkt beim Import, oder? Sonst hast du ja im Programm (sofern dies intern in UTF arbeitet) ständig Hiroglyphen in der Anzeige.

Das macht Hibiscus doch. Beim Eingeben eines neuen Auftrages duerfen nur die Zeichen eingegeben werden, die zulaessig sind. Und bei SEPA-Auftraegen sind das derzeit die bis SEPA 2.6 zulaessigen Zeichen.



Dann ist die XML-Datei kaputt. Und der Ersteller der XML-Datei sollte das meine Merinung nach fixen. Beim Import von XML-Dateien verlasse ich mich jedenfalls auf die Angabe im Header. Dafuer ist sie ja da. Das SEPA-XML-Format ist dank XSD-Schema und ausfuehrlicher Spezifikation hinreichend dokumentiert. Und wenn eine Software tatsaechlich kaputte SPA-XML-Dateien erzeugt, wuerde ich auch dem betroffenen User sagen, dass er sich beim Hersteller dieser Software beschweren soll. Solche Fehler will ich in Hibiscus nicht ausbuegeln.