Hallo interessierte Hibiskus-Fans,

mit den folgenden Infos läßt sich wie im Handbuch beschrieben, ein Bank-Zugang anlegen:

1. Auswahl des HBCI-Verfahrens --> Pin/Tan; Übernehmen
2. Eingabe der Bank-Daten (s. U.); Übernehmen

Adresse / URL https://ebanking.opelbank.de/eBankingFinTS
Benutzerkennung/Kundenkennung Ihre Opel Bank Benutzerkennung
(Achtung: entspricht nicht der Kontonummer)
Version FinTS 3.0
Bankleitzahl 50025000

3. Details der Pin/Tan-Konfiguration; HBCI-Version FinTS 3.0; Speichern

Wie im Handbuch empfohlen nun zu "Konten" gehen:
4. Konten aus HBCI-Konfiguration laden...
5. Auswahl des HBCI-Verfahrens --> Pin/Tan; Übernehmen
6. Auswahl der Pin/Tan-Konfiguration --> GMAC Bank Rüsselsheim; Übernehmen
7. Pin-Eingabe --> Pin; OK; --> Fehler beim Lesen der Kontendaten. Bitte prüfen Sie die Einstellungen des Sicherheits-Mediums.

Nach dem Schritt 3 die Konfiguration testen schlägt auch fehl. Andere HBCI-Versionen auszuprobieren, bringt auch nichts.

Damit bin ich mit meinem Latein am Ende. Um eine tiefere Analyse zu ermöglichen, habe ich die verkürzte Datei jameica.log angefügt.

Hoffentlich kann jemand eine Lösung bieten. Häufig sitzt das Problem ja vor dem Bildschirm.

Viele Grüße

Don Uwe

Jameica: 2.6.4
Hibiskus: 2.6.18
OS: Windows 10

Hi!

Mein Konto bei der Opelbank habe ich schon länger anglegt. Ging immer problemlos.
Seit kurzem kann ich es jedocch nicht mehr abrufen -> scheint wohl eher ein generelles Problem zu sein / ich glaube also nicht, dass das Problem in deinem Fall vor dem Bildschirm sitzt.

Gruß Crazyalex

Ist gefixt. Die Opel-Bank ist tatsächlich noch eine der Banken, die in den BPDs eine kaputte HBCI-Version senden. Sie meinen eigentlich "210" (was fuer HBCI 2.1 steht), senden tatsaechlich aber nur "2". HBCI4Java hatte das bis Version 2.6.17 toleriert. Aufgrund der Fehlersuche des Problems mit dem langsamen Abruf bei den Sparkassen hatte ich diesen HBCI-Versions-Workaround aber entfernt, weil ich anfangs dort die Ursache vermutet hatte. Siehe http://www.onlinebanking-forum…real127210 (Reweiter "RInvalidSuppHBCIVersion").

Hab den Rewriter wieder aktiviert. Ist morgen im Nightly-Build. Siehe http://www.willuhn.de/wiki/dok…lds_nutzen

Das Problem mit dem langsamen Abruf bei den Sparkassen-Konten tritt dadurch nicht wieder auf, da das eine andere Ursache hatte.

Übrigens: Ich hatte wohl doch recht, dass es mit der neuen Angabe in den FI-UPDs zu tun hat. Offenbar füllt FI seine UPDs deswegen mit sovielen + am Ende auf, um ganz am Ende dieses neue Feld einzustellen: {"umsltzt"?:"2016-07-02-00.02.22.086146"}. Hier wird mitgeteilt, von wann der letzte gebuchte Umsatz ist. B4W fragt, wenn es diesen Umsatz schon hat, jetzt garnicht mehr auf neue Umsätze ab und ist gerade bei vielen FI-Konten hintereinander jetzt unglaublich viel schneller fertig...

Ja, genau das war die Ursache. Wenn hinter den optionalen Daten-Elementen nichts mehr kommt, kann man die "+"-Trennzeichen weglassen. Da aber jetzt das neue Feld mit dem JSON-codierten Datum des letzten Abrufes noch hinten dran haengt, darf nicht mehr abgekuerzt werden. Leider durfte das Daten-Element davor maximal 999 mal auftreten. Wenn nur 50 Datenelemente vorhanden sind, muessen da jetzt also ziemlich ineffektiv 949 Plus-Zeichen uebertragen werden.



Ich hatte auch schon ueberlegt, ob ich das neue Feld auswerten sollte. Allerdings ist mir das zu Fi-spezifisch. In der HBCI-Spezifikation ist nicht beschrieben, was genau in diesem Feld steht. Zumindest habe ich bisher keine solchen Informationen gesehen. Ich wuerde da ungern ein Feature einbauen, welches nur bei FI-Instituten funktioniert.

unabhängig von der evtl. Spezifikation ist es doch aber so, dass entweder vorhanden oder aber auch nicht oder?
wenn vorhanden: würde es den Abruf beschleunigen
wenn nicht vorhanden: alles wie bisher

dh. die Berücksichtigung hätte doch nur Vorteile und würde den restlichen Ablauf nicht beeinträchtigen

Nein. Eben nicht. Das Feld ist in http://www.hbci-zka.de/dokumen…ersion.pdf beschrieben:
Kapitel E.3. Feld Nr. 12 "Erweiterung, kontobezogen". In den Erlaeuterungen steht dazu:



Das heisst, die Bank kann nicht nur entscheiden, ob sie was reinschreibt, sondern auch noch in welchem Format. Das kann Freitext sein. Das kann - wie bei der FI - eine JSON-codierte Datenstruktur sein. Das kann aber auch XML oder sonstwas sein.

Heisst: Das Feld ist optional und es ist nicht festgelegt, in welchem Format die Daten da gespeichert sind.

Wenn man das so liest, möchte man (mal wieder) Bomben auf die werfen, die sich solche Spezifikationen ausdenken. Das geht mit den hunterten + Zeichen los und endet mit "man kann reinschreiben, was man mag, notfalls auch Grüße an Tante Trude". Zum Haare raufen

Hallo Hibiscus,

jedenfalls klappt die Einrichtung mit den Nightly-Builds von heute.

Da ich mir vorstellen kann, dass Du nicht über ein Konto bei jeder Bank verfügst, die folgende Frage: Gibt es etwas, dass ich in diesem Zusammenhang testen soll?

Ansonsten: Vielen Dank für die schnelle Hilfe.

DonUwe

Der Ursprung dieses Feldes ist zwar die FI, aber die Belegung wurde in einem Workshop mit den Herstellern diskutiert. Gemeinsam hat man auch die Version 1.0 einer Belegung erarbeitet, die jetzt eigentlich veröffentlicht werden müsste.
Die Version 0 mit dem "Umsatzstempel" wird u.a. auch von den Volksbanken und Raiffeisenbanken am RZ exGAD unterstützt und demnächst bei allen Volksbanken und Raiffeisenbanken.

Mit der Version 1 wird das Feld um weitere Bestände und auch weitere Informationen zum Konto und Kontoinhaber befüllt. Meiner Meinung nach mal ein Muster für die Zukunft, wie man als DK (ZKA gibt es nicht mehr) und Hersteller zu beiderseitigem Nutzen etwas voran bringen kann.

Viele Grüße

Holger

Gibt es diese Spezifikation auch irgendwo oeffentlich einsehbar?