Vorab: Danke für deine Diagnose-Vorarbeit! Es ist wirklich ausgesprochen hilfreich, wenn jemand den Code selbst analysieren und bei der Fehlersuche auf diesem Level helfen kann.


Ich nehme an, damit man zwischen Bank und Banking-Software immer eine gemeinsame Schnittmenge findet und verschiedene Software-Stände mit unterschiedlichem PAIN-Support unterstützt.


Da gibt es nach meinem Wissen keinen. Zumindest was die Version der Pain-Nachricht betrifft.


Hibiscus wählt aus der von der Bank gelieferte Liste der PAIN-Versionen die aktuellste, die zum Geschäftsvorfall passt.

pain.001.* sind Überweisungen und Daueraufträge
pain.002.* sind Kontoauszüge
pain.008.* sind Lastschriften

Die Zahl dahinter ist jeweils die Variante innerhalb der Auftragsart. Bei pain.001 wurde die irgendwann nach unten geändert, sodass neuere Versionen augenscheinlich für ältere Versionen gehalten werden können. pain.001.001.09 ist aktueller als pain.001.003.03. Unter https://vrkennung.de/sepa-formate-alte-pain-versionen/ und https://community.ifs.com/fina…-nov-38482 habe ich ein paar Versionlisten gefunden.


Selbst vorgeben kannst du das nicht. HBCI4Java wählt aus der Liste der von der Bank übertragenen Versionen die aktuellste.


Ich nehme an, um verschiedene Banking-Anwendungen mit unterschiedlichem Versionsstand zu unterstützen. Aber auch gut möglich, dass Banken verpflichtet sind, ein definiertes Mindest-Set an Versionen anzubieten.

Oft nur Kleinigkeiten. Im Package "hbci.GV.generators" findest du die Java-Klassen der Generatoren. Dort könntest du ja die beiden Versionen vergleichen. Wobei das im konkreten Fall eigentlich keine Rolle spielen sollte, da Hibiscus hier ja keine PAIN-Nachricht sendet sondern von der Bank in der angegbenen Version haben will. In dem Zusammenhang ist echt merkwürdig, dass die Bank das Format als unterstützt meldet, dann aber einen Fehler meldet, wenn man die Daueraufträge dann auch tatsächlich in diesem Format haben will.


Siehe oben.

Danke für die detaillierte Antworten!


Ein Test zeigt, dass der GV DauerSepaList auch mit der Version pain.001.001.03 funktioniert.

Es leuchtet mir ein, dass mehrere Pain-Versionen in den BPDs gelistet sind, damit man zwischen Bank und Banking-Software immer eine gemeinsame Schnittmenge findet. Aber die Konsequenz erscheint mir ambivalent. Auf der einen Seite kann eine Client-SW eingesetzt werden, die noch eine ältere Pain Version spricht, aber die Bank hat auch andererseits die Freiheit die GVs langsam von einer Version auf die andere umzustellen und zu verlangen, dass die Client-SW herausfinden muss, was die passende ist.

In deinem Link zum IFS Dokument findet sich auch eine schlüssige Begründung dafür, dass die CB die Version 09 anbietet, denn Instant Payment ist erst ab dieser Version verfügbar, ein Feature, dass die CB per HBCI anbietet. Für alle anderen GVs ist auch noch die Version 03 gültig bis Nov. 25. Da hat die CB noch fast ein Jahr Zeit, alle GVs auf 09 umzustellen.

Für mich als Außenstehender sieht es aus, als gäbe es eine Lücke in der Interpretation der Spezifikation. Falls dem so ist, was wären die Möglichkeiten, die zu schließen?

Die Client-SW könnte bei entsprechendem Fehler versuchen, die nächste, angebotene und unterstützte Pain-Version zu verwenden. Danach könnte die passende Version in einer Datenbank oder Konfigurationsdatei gespeichert werden.

Das wäre grundsätzlich die Aufgabe von Hbci4J. Aber die Library scheint zu funktionieren wie ein status-loser Automat, der kaum fallspezifische Ausnahmen handeln kann..

Was könnte Hibiscus hier? Kann es über den Mechanismus (oder temporären Workaround) den GV mit dem zusätzlichen Parameter aufrufen?



Natürlich würde ich gerne selber mit Hand anlegen, aber nur, wenn das aus der Sicht der Hauptentwickler Sinn macht.
Ich bin ja hier nicht unvoreingenommen und vielleicht sehe ich eine einfache Lösung und die harte Realität ist ganz anders.

Update:

Es hat sich beim zweiten Hinsehen eine Besonderheit in den BPDs der Commerzbank gefunden. Die Parameter für den GV DauerSEPAList lauten:

Für den GV gibt die CB eine spezielle PAIN Version vor.
In der Methode zur Ermittlung der besten PAIN Version

kann ich für die Behandlung dieses Falles keine Funktionalität finden.
Vielleicht macht es Sinn, dies in hbci4j generell zu prüfen.
Da das dann ein Feature Request ist, wäre das ein Fall für den Issue Tracker des hbci4j Projekts.

Olaf hat seinen eigenen Fork vom hbci4java:
https://github.com/willuhn/hbci4java

Die Funktion "determinePainVersionInternal" macht genau das. Sie prüft, ob eine GV-spezifische PAIN-Version in den BPD angegeben ist. Das steht auch explizit so in dem Kommentaren im Code.

Andersrum. Ich hatte diesen Fork füher gepflegt. Seit einigen Jahren ist es aber https://github.com/hbci4j/hbci4java

Ja stimmt und den Kommentar habe ich gesehen, aber die Funktion iteriert über Properties, die sich lowLevelRestrictions (LLR) nennen. Jedoch sind die beim GV DauerSepaList leer, wie der Debugger zeigt. Die Bank-Info, dass für den GV eine spezielle PAIN Version erwartet wird

wird irgendwie nicht aufgegriffen.
Da ich in den Code nur reingeschnuppert habe, ist mir bisher nicht genau klar, wie die LLRs gebildet werden.
Vergleicht man aber die BPDs und die LLRs für andere GVs, wie DauerSepaEdit, scheint es, als seien die LLRs nur eine Untermenge der BPDs für den GV:

Auf den ersten Blick sieht es so aus, als würden nur die BPDs, die im Key den Substring

haben, in die LLRs übernommen.

Das ist der Abruf der existierenden Daueraufträge. Dort ist die Angabe der gewünschten PAIN-Formate auch gar nicht nötig.

Nachtrag: Gerade nochmal in der Spezifikation nachgeschaut. In "HKCDB" wird in der Tat durch die Banking-Software die PAIN-Version mitgeschickt. Wenn die Bank in den BPD keine geschäftsvorfallspezifische Version angegeben hat, dann wird die höchste in HISPAS zurückgemeldete Version verwendet. Ich habe gerade mal in den Daten meiner Bankzugänge geschaut. Mir ist liefert gar keine Bank Dauerauftragsspezifische PAIN-Versionen sondern nur für andere Auftragsarten sowie die global gültigen.


Wenn da ein genereller Fehler bei der Auswahl der passenden PAIN-Version in HBCI4Java wäre, dann müssten doch auch andere Banken von dem Problem betroffen sein, oder?

Wenn ich Kleingeld richtig verstanden habe, dann bietet die Commerzbank zwar die aktuellsten PAIN Versionen an, aber für den speziellen Dauerauftrag GV möchte sie eine ältere PAIN Version. Das könnte bei der Commerzbank außergewöhnlich sein, weshalb der Fehler noch nicht aufgefallen ist. Wenn andere Banken die höchste PAIN Version anbieten UND verwenden.

Grüß
Maik

Das ist nichts Commerzbank-spezifisches. Es gibt eine Liste von bekannten PAIN-Versionen und die Bank teilt in den BPD des GV mit, welche PAIN-Version sie haben möchte. Wenn dort etwas angegeben ist, wird das auch von HBCI4Java so berücksichtigt. Wenn dem nicht so wäre, hätte es schon an 100 anderen Stellen Fehler gegeben. Auch weil der Code dafür nichtmal spezifisch für die Daueraufträge ist. Genau der gleiche Code kommt auch bei den Überweisungen und Lastschriften zur Anwendung und funktioniert seit Jahren.

Stimmt genau.

Ja und Nein (s.u.)

Das habe ich mittlerweile verstanden. Sorry, wenn das in früheren Stellen meiner Kommentare anders klang.

Nachdem ich bei Bekannten ein paar BPDs anderer Banken einsehen konnte, scheint es möglich, dass nur die Coba bei nur dem GV einen anderen Weg geht.
Speziell ist der verwendete Key für die GV spezifische PAIN Version. Normalerweise wird der gebildet nach dem Pattern

Die Coba verwendet aber den Key

statt
.
Wenn das wirklich nur die Coba an dieser einen Stelle so macht, lohnt es sich wirklich nicht, zentralen Code anzufassen. Vielleicht wäre ein experimentales Feature, das den CoBa Kunden in der Übergangszeit hilft, noch einen Gedanken wert.
Trotzdem würde es mich interessieren, ob die Coba gegen die Spec verstösst oder ob das normale Muster der Keys nur gelebte Praxis ist.