Zitat geschrieben von Boris
umgestellt :), aber erhalte seitdem unvollstaendige Umsatz-Informationen. Der Verwendungszweck ist einfach "irgendwo" in der Mitte abgeschnitten. Habe mir das CAMT-Format im HBCI-Trace angeguckt und beispielsweise diese Paypal-Abbuchung gefunden, deren RmtInf-Element folgendermassen aussieht:
Danke für die Analyse!
Zitat geschrieben von Boris
Angezeigt wird von Hibiscus nur der Inhalt des ersten Elements. Habe mal in den Quellcode von hbci4java geguckt und gesehen, dass "Ustrd" in den XSDs auch immer als genau ein Element definiert ist.
Das stimmt so nicht ganz. In den XSDs ist der Verwendungszweck so definiert:
Code
<xs:element maxOccurs="unbounded" minOccurs="0" name="Ustrd" type="Max140Text"/>
Darf also - wie Holger schon schreibt - beliebig oft vorkommen. Und das berücksichtigt HBCI4Java auchkorrekt. Siehe
https://github.com/hbci4j/hbci….java#L186
Der Fehler entsteht erst in Hibiscus - konkret hier:
https://github.com/willuhn/hib….java#L123
Wenn es ein CAMT-Umsatz ist, wird pauschal nur die erste Zeile übernommen. Grund: Laut XSD darf eoine Zeile Verwendungszweck maximal 140 Zeichen lang sein, es dürfen jedoch mehrere enthalten sein. Seit der Umstellung auf SEPA-Überweisungen und -Lastschriften kann man bei Aufträgen aber nur noch eine Zeile Verwendungszweck angeben. Sprich: Als Initiator einer Zahlung habe ich technisch gar keine Möglichkeit, mehr als eine Zeile zu erzeugen.
Und da seit CAMT die SEPA-relavanten Informationen EREF, KREF, IBAN, etc. auch nicht mehr in den Verwendungszweck gepackt werden müssen (da es hierfür ja in CAMT dedizierte Felder gibt), sollte im Verwendungszweck eigentlich auch nur noch eben dieser stehen.
Ich hatte mir daher mal die Verwendungszwecke meines SPK-Kontos angeschaut. Die schreiben alles in die eine 140 Zeichen lange Zeile. Also nahm ich an, dass das jetzt generell so ist und nur noch diese eine Zeile nötig ist.
Und dann sehe ich jetzt, dass es tatsächlich Banken gibt, die das neue CAMT-Format (der Heilsbringer, damit die SEPA-Daten nicht mehr in das alte MT940-Format gepresst werden müssen) zwar verwenden aber dennoch alle 27 Zeichen zerhacken und damit jetzt das alte MT940-Format in CAMT pressen? GAD? Das finde ich peinlich. Wozu haben wir das neue Format, wenn dessen Möglichkeiten dann nicht genutzt werden.
Wie auch immer. Ich ändere Hibiscus jetzt so, dass die Zeilen alle übernommen und zusammengefasst werden. Ist morgen im Nightly-Build.