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

 
tom_22
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 9
Dabei seit: 02 / 2016
Betreff:

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

 ·  Gepostet: 16.02.2016 - 19:52 Uhr  ·  #61
Danke!
Werde es morgen mit der hibiscus-server-2.7.0-nightly ausprobieren...
tom_22
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 9
Dabei seit: 02 / 2016
Betreff:

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

 ·  Gepostet: 18.02.2016 - 01:12 Uhr  ·  #62
Habe gerade das hibiscus-server-2.7.0-nightly ausprobiert. Sieht gut aus: der Verwendungszweck wird passend dargestellt. Natürlich habe ich noch die Felder [zweck] und [zweck2] auf Seiten der SQL Datenbank angepasst, d.h. falls sie 'nur' 26 Zeichen lang waren ein Leerzeichen angehängt.

Jetzt ist mir noch etwas anderes aufgefallen: im Feld [empfaenger_name] sehe ich einige Einträge, die an der 27.Stelle ein Leerzeichen haben und somit Wörter trennt. Könnte der Zusammenhang ein ähnlicher sein, wie bei [zweck], [zweck2] und [zweck3]?

Danke!
msa
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 62
Beiträge: 7499
Dabei seit: 03 / 2007
Betreff:

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

 ·  Gepostet: 18.02.2016 - 10:46 Uhr  ·  #63
Das Feld Empfänger war vor SEPA 27 Stellen lang, es gab noch ein weiteres Empfänger Zusatz mich nochmal 27 Stellen.
Bei SEPA ist das Feld Empfänger jetzt 70 Stellen lang - manchmal als 2*35 Stellen interpretiert. Somit ist es hier das selbe Glücksspiel, was genau als Empfängerstring ankommt, wie beim Zweck. Abhängig in welchen Masken das ursprünglich eingegeben, wie oft es konvertiert wird, wie es konvertiert wird und in welchem Format es schließllich ausgeliefert wird. Und wie es dann vom Kundenprodukt abgespeichert und exportiert oder angezeigt wird.
tom_22
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 9
Dabei seit: 02 / 2016
Betreff:

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

 ·  Gepostet: 18.02.2016 - 21:04 Uhr  ·  #64
Gibt es ein Log (ggf. muss man es mit einem Parameter einschalten), in dem die empfangenen Daten aufgezeichnet werden, noch bevor sie in irgendeiner Form bearbeitet werden?

Ich habe auch versucht, die Stelle zu finden, an der der hibiscus-server das 'parsing' macht - also das Extrahieren/Zuweisen aus den empfangenen Daten in die interne Datenstruktur. Hat jemand einen Tip (Forums-Eintrag oder Java-Datei)? Hab' schon einiges an Quellcode angesehen, z.B. "UmsatzImpl.java", "AbstractHibiscusTransferImpl.java" oder "AbstractSynchronizeBackend.java", aber sicher die entscheidende Stelle übersehen...
hibiscus
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Leipzig
Homepage: willuhn.de/
Beiträge: 10727
Dabei seit: 03 / 2005
Betreff:

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

 ·  Gepostet: 19.02.2016 - 10:10 Uhr  ·  #65
Zitat geschrieben von tom_22

Gibt es ein Log (ggf. muss man es mit einem Parameter einschalten), in dem die empfangenen Daten aufgezeichnet werden, noch bevor sie in irgendeiner Form bearbeitet werden?


Log-Level entweder auf DEBUG (in der GUI unter "Datei->Einstellungen" oder in "~/.jameica/cfg/de.willuhn.jameica.system.Config.properties" mit "jameica.system.log.level=DEBUG") stellen oder in der Desktop-Version von Hibiscus im Menu auf "Hibiscus->Erweitert->HBCI-Protokoll speichern..." klicken.
tom_22
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 9
Dabei seit: 02 / 2016
Betreff:

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

 ·  Gepostet: 10.03.2016 - 01:16 Uhr  ·  #66
Habe das Log-Level in der de.willuhn.jameica.system.Config.properties auf DEBUG gestellt.

Es wird aber leider nur die SQL Anweisung in das Log geschrieben, also z.B. "insert into umsatz ... ". Es sieht so aus, also ob im [empfaenger_name] (immer) an der 28 Stelle ein Leerzeichen steht.

Vor der SQL Anweisung gibt es ein "now parsing MT94x data" Log-Eintrag. Die Daten werde also durch "GVRKUms.java: parseMT94x()" geschickt ... und jetzt hänge ich wieder. Kommt der spätere [empfaenger_name] aus "List<String> usage" oder wird der woanders geparsed?



kurzer Nachtrag zum Commit vom 16.2.2016 und der Nightly-Build: ich hatte jetzt zwei Salden, die keinen [zweck], [zweck2] oder [zweck3] hatten; also alle drei auf NULL ... leider kann die XML-RPC Abfrage damit nicht umgehen ("Fatal error: Call to a member function arraySize() on a non-object"). Sobald man per SQL in [zweck] einen Wert einträgt, geht es wieder. Reine Vermutung ob es mit dem Commit vom 16.2. zusammenhängt oder nicht, aber vielleicht hat jemand etwas ähnliche beobachtet.
hibiscus
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Leipzig
Homepage: willuhn.de/
Beiträge: 10727
Dabei seit: 03 / 2005
Betreff:

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

 ·  Gepostet: 10.03.2016 - 09:07 Uhr  ·  #67
Zitat geschrieben von tom_22

Habe das Log-Level in der de.willuhn.jameica.system.Config.properties auf DEBUG gestellt.

Es wird aber leider nur die SQL Anweisung in das Log geschrieben, also z.B. "insert into umsatz ... ". Es sieht so aus, also ob im [empfaenger_name] (immer) an der 28 Stelle ein Leerzeichen steht.


Die einzige Stelle, in der in Hibiscus sowas passieren koennte, waere
https://github.com/willuhn/hib….java#L416

HBCI4Java liefert zwei Namensfelder. Per Default wird das erste genommen. Nur dann, wenn das zweite Text enthaelt, wird es angehaengt. Da ich aber schon bei manchen Banken gesehen habe, dass (sicher weil das noch alte Mainframe-Hosts involviert waren) Felder bis zur 27-Zeichen-Grenze mit Leerzeichen aufgefuellt sind. In dem Fall wuerde Hibiscus "glauben", dass etwas drin steht. Im Zweifel sind es aber nur Leerzeichen. Ich hab die Stelle mal so geaendert, dass dort jetzt ein trim() gemacht wird.

https://github.com/willuhn/hib….java#L409

Zitat geschrieben von tom_22

Vor der SQL Anweisung gibt es ein "now parsing MT94x data" Log-Eintrag. Die Daten werde also durch "GVRKUms.java: parseMT94x()" geschickt ... und jetzt hänge ich wieder. Kommt der spätere [empfaenger_name] aus "List<String> usage" oder wird der woanders geparsed?


Unterschiedlich. In MT940 gibt es zwei Felder (32,33), in denen die Bank in dedizierten Feldern den Namen liefern kann:

https://github.com/willuhn/hbc….java#L658

Wenn die Bank dort nichts gesendet hat, dann macht Hibiscus ein Fallback auf das SEPA-Tag "ABWA" aus dem Verwendungszweck (insofern vorhanden):
https://github.com/willuhn/hib….java#L154

Zitat geschrieben von tom_22

kurzer Nachtrag zum Commit vom 16.2.2016 und der Nightly-Build: ich hatte jetzt zwei Salden, die keinen [zweck], [zweck2] oder [zweck3] hatten; also alle drei auf NULL ... leider kann die XML-RPC Abfrage damit nicht umgehen ("Fatal error: Call to a member function arraySize() on a non-object"). Sobald man per SQL in [zweck] einen Wert einträgt, geht es wieder. Reine Vermutung ob es mit dem Commit vom 16.2. zusammenhängt oder nicht, aber vielleicht hat jemand etwas ähnliche beobachtet.


Genau deshalb findest du im Commit DIREKT DANACH eine weitere Aenderung, die in dem Fall Leerstrings verwendet, da nicht alle XML-RPC-Implementierungen mit NULL-Werten umgehen koennen.

https://github.com/willuhn/hib…8d82c368ea

Siehe hierzu auch: http://www.willuhn.de/wiki/dok…aktivieren
Gewählte Zitate für Mehrfachzitierung:   0