"9010:Verarbeitung fehlgeschlagen. (3: CustomMsg.GV.DauerSEPAList1)" beim Abrufen der SEPA-Daueraufträge

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.

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

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

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?

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.

Hallo erstmal,

Ich würde das gernen nochmal aufgreifen:



Bei einem Spec-Verstoß wäre ein experimentelles Feature-Flag optimal. Wenn es korrekt ist (und somit in hbci4java unvollständig implementiert) wäre ein Schritt Richtung Vollständig (auch wennn z.Z. nur eine Bank den Bug kitzelt) schön.

Wie sehen die Anderen CoBa-Kunden hier das Problem?

Oder das Banking-Programm: unter Banking4 tritt der hier beschriebene Fehler bei der Commerzbank nicht auf.

Das ist keine Werbung, sondern lediglich der Hinweis, dass kein Bankenwechsel - wie von dir empfohlen - nötig ist. Den Hinweis habe ich mit einem beispielhaften Produkt versehen, welches - im Gegensatz zu Hibiscus - hiermit kein Problem hat.
Er gibt vermutlich keine Bank, die alles "richtig" macht, deswegen scheint mir dein Kommentar, die Bank zu wechseln fehl am Platz - zumal das Problem so klein ist, dass es einen Bankwechsel nicht rechtfertigt.
Mein Posting war eine Reaktion auf deinen Versuch die Commerzbank schlecht zu reden.

Das ist ja eine tolle Begründung.


Die Bank ist Verursacher des Problem, welches mit mindestens einer anderen Banking-Software garnicht vorhanden ist. Drauf habe ich hingewiesen. Ein Bankwechsel - wie von dir empfohlen - ist nicht nötig, vorallem nicht wegen so einem kleinen Fehler.
Bitte denke auch dran, dass für jedes Posting alle Teilnehmer des Threads per Mail benachrichtigt werden, deswegen wäre es schön, wenn du jetzt nicht weiter offtopic bist, das ist nämlich auch eine Foren-Gepflogenheit. Vielen Dank 🫶

Habe gleich nochmal neu Syncronisiert. Leider ist der Fehler in der 2.12.1 nicht verschwunden. Und unbedeutend ist er leider nur wenn man keine Daueraufträge hat bzw. verändern muß.



@hibiscus: Danke.

PS: @yoda.man: Abgesehen von deiner Fremdwerbung - Der Tipp ist unbrauchbar - nicht für Linux verfügbar