Umbrüche im Verwendungszweck für SEPA-Überweisung

geprüft, dass auch wirklich die letzte nightly läuft?

Zumindest habe ichs runtergeladen

Ich habe mich mißverständlich ausgedrückt: Es läßt sich weder das angezeigte "Sp ende" noch "H amburg" finden, egal ob ich mit Spende, Sp ende oder Sp.?ende, Hamburg, H amburg oder H.?amburg suche.

Leider funktioniert genau das nicht.

hauptsache gschwätzt

Ich habe oben bereits geschrieben, daß ich das neuste nightly gestern geladen hatte. Heute habe ich es nochmal geladen.
Die Suche funktioniert bei mir nicht. Daher auch meine Frage: Was für ein Zeichen wird noch als Blank angezeigt?
Können die Probleme mit dem OS (hier XP) zu tun haben?

Ich habe einwenig rumprobiert. Es muß mit dem Rechenzentrum zu tun haben.
Bei der Netbank wird "H amburg" nicht gefunden, bei der Berliner (=Deutsche) Bank sehr wohl.
Daher nochmal die Frage: Wie finde ich beliebige Zeichen? ".?" klappt nicht.

Kann mal bitte jemand anderes im Forum bestaetigen, dass die Suche mit den Leerzeichen funktoniert? Ich verstehe nicht, was bei "sme" da falsch laeuft.

1) Einfach einen Umsatz oeffnen, auf "Bearbeiten" klicken, im Verwendungszweck testhalber mal sowas wie "ABC DEF" eingeben (gern auch mit einem Zeilenumbruch statt Leerzeichen)
2) Dann auf der View "Umsätze" oben bei "Zweck, Notiz, Art enthält" den Text "abcdef" eingeben und testen, ob der Umsatz gefunden wird.

Haben rausgefunden, dass es an Zeilenumbruechen liegt. Die werden jetzt ebenfalls ignoriert. Ab morgen im Nightly-Build.

Danke fuer die Rueckmeldung.

Ja, das ist Absicht. Die Daten werden genauso angezeigt, wie in der Umsatzliste in Hibiscus. Das heisst, wenn das SEPA-Tag "SVWZ" im Verwendungszweck enthalten ist, wird auch nur dessen Wert angezeigt.
Das hat in der Tat den Effekt, dass dann u.U. Daten nicht mehr per XML-RPC verfuegbar sind, die es vorher waren. Ich fuehre daher neben "zweck" noch ein weiteres Element "zweck_raw" hinzu, weches ein Array mit den urspruenglichen unveraenderten Verwendungszweck-Zeilen enthaelt. Dann kann jeder selbst entscheiden, welche Daten er davon verwendet. Ist ab morgen im Nightly-Build.

Siehe https://github.com/willuhn/hib…efa807fb56

Im existierenden Feld will ich das ungern aendern, weil es ja vorher auch mit Leerzeichen war und so auch konsistent zur Darstellung in der Benutzeroberflaeche ist.
Ich hatte testhalber in der GUI von Hibiscus die Leerzeichen draussen gelassen. Da fielen mir viele Buchungen bei meinem eigenen Konto auf, wo dann zwei eigentlich getrennt geschriebene Woerter ploetzlich zusammengeschrieben waren. Da fand ich die jetzige Loesung das kleinere Uebel. Aber ich schau's mir nochmal an. Vielleicht aendere ich es ja nochmal.

Danke hibiscus.

Eine Nachfrage zu meinem Verständnis: kann es sein, dass der hibiscus-server nach dem Aufteilen des Verwendungszweck, auf die einzelnen Feldern [zweck], [zweck2] und [zweck3] noch ein trim anwendet?

Das wäre zumindest eine Erklärung für diese Situation: ich sehe einige Datensätze in der SQL Datenbank, bei denen a) das Feld [zweck] 26 Zeichen lang ist und mit dem Wortende endet; andere Datensätze/Felder, bei denen b) das Feld [zweck] 27 Zeichen lang ist und ggf. mitten im Wort getrennt ist;

Später beim Zusammensetzen, würde man für den Fall a) ein Leerzeichen benötigen, aber im Fall b) wäre das das nur in bestimmten Fällen nötig.

Ich verwende nur die hbiscus-server version und ich muss gestehen, dass ich die Übertragungs-Protokolle und das Prozedere nicht im Detail kenne (z.B. ob der Verwendungszweck auf Bankseite schon aufgeteilt wird, bzw. dort ggf. ein Trim durchgeführt wird).

Meines Erachtens wäre hier die Lösung auf das Trim zu verzichten (bin mir aber sicher, dass es einen Grund gab das anzuwenden).

Eine weitere Option wäre, wenn man die Möglichkeit hätte die Felder [zweck], [zweck2] und [zweck3] einzeln per RPC abzufragen ... oder das Trennzeichen als Parameter individuell einstellen könnte?