Ich habe meinem Vater vor einiger Zeit Hibiscus eingerichtet, lief problemlos und er war zufrieden. Eine Raiffeisenbank in Oberbayern, wohl Fiducia.
Seit einigen Tagen ging es ganz plötzlich nicht mehr, Fehlermeldung beim Abrufen der Umsätze eines Kontos (Log):

[12.09.2014 18:45:42] Synchronisierung via HBCI läuft
[12.09.2014 18:45:42]
[12.09.2014 18:45:42] Synchronisiere Konto: Kontokorrent, Kto. xx [Raiffeisenbank yy]
[12.09.2014 18:45:42] Initialisiere HBCI-Sicherheitsmedium
[12.09.2014 18:45:42] Erzeuge HBCI-Handle
[12.09.2014 18:45:42] Öffne HBCI-Verbindung
[12.09.2014 18:45:54] Fehler: *** RDH-2/10-file does not contain a header field - aborting

Lässt sich daraus irgendwas ableiten?
Die Bank verweigert natürlich jeden Support und verweist auf vrnetworld, eine alte Version davon (in einer Win-VM) geht aber auch nicht mehr und mit einer neuen Version hatte mein Vater auch keinen Erfolg (muss ich mir noch anschauen).

Hibiscus war 2.6.3, nun aber mit 2.6.8 identisches Problem.

OK, das war jetzt seltsam. Die Schlüsseldatei war auf 0 Byte geschrumpft. Wodurch, kann er sich nicht vorstellen.
Ich habe also die Schlüsseldatei wieder restauriert.

Als Adresse enthält sie: https://hbci11.fiducia.de/cgi-bin/hbciservlet
dazu ist Port 3000 eingestellt.
Leider kommt beim "Konfiguration testen" nun
UnknownHostException: https://hbci11.fiducia.de/cgi-bin/hbciservlet org.kapott.hbci.manager.HBCIInstitute.fetchBPD(HBCIInstitute.java:251)

Die Adresse ist aber vom Rechner aus (zB telnet commandline) sehr wohl erreichbar - auf Port 443. An Port 3000 lauscht nichts. Wenn ich den Port ändere und "speichere", ist nach dem erneuten "Öffnen" der Schlüsseldatei wieder 3000 eingetragen.

Was könnte da los sein?
Dankbar für alle Vorschläge..

PS: im vrnetworld klappt der Umsatz-Abruf, aber eine Test-Überweisung kann dort nicht "aktiviert" werden ("überprüfen Sie die Geschäftsvorfallsberechtigungen .. evtl. auch deaktiviert")

ich befürchte, da hast du schlichtweg die falsche Adresse erwischt, nämlich die für PIN & TAN, da wäre dann auch 443 richtig (SSL).
Schau mal bei der Bank nach oder probiere
hbci01.fiducia.de
Port 3000 für Sicherheitsdatei oder Signatur per Chipkarte ist jedenfalls richtig.
Gruß
Raimund
ps: Habt ihr ein Antivir oder sowas laufen? ClamAV neigt wohl sehr zu Falschmeldungen...

Das Hibiscus läuft unter Linux (daher ja auch kein vrnetworld mehr) - also kein Virenwächter..

Die genannte URL wird auch bei vrnetworld angezeigt unter der Bankverbindung, und dort klappt es. Sie enthält ja auch "hbci", und sie scheint in der Schlüsseldatei enthalten zu sein!

Mich wundert nur, warum hier einerseits eine URL (statt nur eines Host - und wenn da ein nicht-default (443) Port gemeint wäre müsste er in der URL enthalten sein) und andererseits ein Port im Spiel ist.

OK, also ich wollts ja erst nicht glauben (war aber auch nicht vor Ort), jetzt hab ich es einfach mal probiert, und Du hattest Recht!
Steht ja auch hier: http://www.onlinebanking-forum.de/forum/topic.php?t=2116

Mit dem hbci01 als Host (und keine URL) klappt der Abruf der Salden wieder ganz normal - wo auch immer diese URL herkam..

Und beim Versuch einer Überweisung kommt der gleiche Fehler wie bei vrnetworld - von wegen Geschäftsvorfallsberechtigung..
Da muss dann jetzt wohl doch nochmal die Bank ran!

Danke!

Tja, woher das stammt ist echt merkwürdig. Aber HBCI ist eigentlich beides, es gibt halt auch HBCI mit PIN & TAN und das wird die Bank auch anbieten.

Wenn es vorher mit dem gleichen Zugang geklappt hat, würde ich mal ganz genau nachsehen, ob alles richtig auf SEPA umgegestellt ist, also IBAN und BIC eingepflegt ist, etc. Das kann an unterschiedlichen Stellen stecken.

Gruß
Raimund

Bisher haben wir tatsächlich immer mit Kto/BLZ getestet, und zwischenzeitlich waren wir nun auch auf die Idee gekommen mal eine Überweisung mit IBAN zu machen. Et voila, das klappt.
Demnach hat die Bank mal eben die alte Variante (Punkt Zahlungsverkehr alt bei Hibiscus) deaktiviert? Angekündigt wurde das nicht - oder mein Vater hats verdaddelt..
Aber eigentlich kann man als Privatkunde doch noch bis Frühjahr 2016 auch mit Kto/BLZ arbeiten?? Er soll mal nachfragen..

Scheinbar hat Hibiscus ja sogar einen automatischen Umrechner integriert, bin aber nicht mehr vor Ort um das zu testen. Gestern waren jedenfalls Adressbucheinträge drin, die keine IBAN hatten, zB das Test-Zielkonto (wurde im "neuen" Zahlungsverkehr gar nicht gefunden, weil IBAN nicht ausgefüllt, drum haben wir auf Zahlungsverkehr-alt gewechselt). Wurde vielleicht mittlerweile aktualisiert, als wir mal ins Adressbuch rein sind (laut hier http://www.willuhn.de/blog/ind…chner.html) - aufgefallen war es nicht. Wäre natürlich im Prinzip sinnvoll, das auch schon bei der Suche o.ä. anzustossen, so muss man es halt wissen. Und seltsam, das Feature scheints ja schon länger zu geben, und mind. Anfang 2014 bei der Ersteinrichtung waren wir auch im Adressbuch (hatte das glaub ich irgendwie importiert).

jein, das wurde im Forum aber nun schon mehrfach besprochen, analysiert usw.
um es kurz zu machen, SEPA ist Standard
die Banken bieten im Prinzip einen Umrechungsservice an, aber evtl. nicht auf allen Kanälen.

Es ist unverständlich warum man sich an Konto+BLZ klammert, alle Programmierer haben tolle Arbeit geleistet und mache es doch so einfach wie nur möglich

Ich hatte nicht vor zu klammern. Aber es ist doch wohl ein klares Versäumnis der Bank, wenn sie ihren Kunden nicht deutlich ankündigt, wenn da mal eben sowas von heute auf morgen abgeschaltet wird. Denn die Sache mit 2016 hat man nun mal im Hinterkopf, war nun wirklich bei jeder Meldung zum Thema immer dabei, mit dem Effekt, dass man sich denkt "alles nicht so eilig". Und dann noch so nichts-sagende Fehlermeldungen über Geschäftsvorfallsberechtigungen, statt klipp und klar in den Text-Teil reinzuschreiben "nur noch SEPA unterstützt" o.ä. (laut Log scheint mir das durchaus von der Bank zu kommen und nicht nur die von Hibiscus via Mapping aufgelösten Fehlercodes - ??)

Wenn man es weiss, ist es ja in Ordnung, da i.a. eine Umrechnung kein Problem ist. Aber natürlich werde ich (ich selbst verwende nur die Web-GUI meiner Bank) im Zweifel noch so lange wie es geht lieber Kto/BLZ von der Rechnung eintippeln, statt der ungleich längeren IBAN/BIC. Solange nicht alles voll "elektronisiert" ist, bleibt das schon etwas nervig.

Hallo Hibi,

ein ganz weit verbreiteter Irrtum, da leider auch immer wieder schlecht kommuniziert. Der Privatkunde (korrekter der Verbraucher) hat keinerlei Anrecht darauf, bis 2016 mit Kontonummer und Bankleitzahl zu arbeiten. Seit dem 01.02.2014 gilt für alle SEPA.
Laut Gesetz darf aber eine Bank, für eine Übergangszeit bis zum 31.01.2016, von Verbrauchern noch Zahlungen mit Kontonummer und Bankleitzahl annehmen, wenn sie
- diese konvertiert
- sicherstellt, dass das Ergebnis der Konvertierung richtig ist

Die Bank kann also so ein Service anbieten, sie muss es nicht. Die Bank muss es demnach auch nicht für alle Auflieferungswege anbieten.

Da es also den alten IZV eigentlich nicht mehr gibt und nur im Rahmen einer Ausnahmeregelung noch erlaubt ist, könnte man auch Argumentieren, dass die Bank nur informieren sollte, wenn Sie von der Ausnahmeregelung Gebrauch machen möchte.

Aber egal wie rum man argumentieren möchte, meiner Meinung nach steht man immer besser da, wenn man klar kommuniziert, was man vorhat.

Viele Grüße

Holger

also doch wie ich gesagt hatte, man klammert

die ist doch im Prinzip fast genauso lange (abgesehen von LänderCode und Prüfziffer)
Des weiteren solltest du berücksichtigen, dass man bspw. bei Konto, BLZ keine Prüfziffer hat und somit das Geld schnell auf einem anderen Konto landen könnte.
(bei IBAN wie oe. Prüfziffer, somit Sicherheit für den Einreicher)

Das stimmt für D nicht. Jeder deutschen BLZ ist ein Prüfziffernverfahren zugewiesen, nach dem die Kontonummer gerechnet werden muss. Das sind inzwischen weit über 100 verschiedene Verfahren. Nur wenige davon sind so trivial, dass praktisch keine Berechnung erfolgt. Die meisten bieten sehr guten Schutz gegen Vertipper. Und soweit ich informiert bin werden die in Hibiscus auch beachtet und gerechnet.

es handelt sich dort um keine Prüfziffern, sondern um Plausibilitäts-Berechnungen, bspw. dass div. BLZ nur Konten in einem gewissen Nummernkreis haben.
das von dir angesprochene ist zudem zu detailliert (+ungenau/fehleranfällig) und würde hier doch nur Verwirrung stiften, zumal bspw. ein Zahlendreher in deiner angegeben Berechnung nicht auffallen würde - bspw. Konto 12589 u.d 12689 würde durchrutschen. (und bevor die Umwandlung in den Apps nun noch aufgeführt wird, hier wird auf Grundlage der evtl. falschen Eingaben von Konto+BLZ eine evtl. falsche Prüfziffer ermittelt)



finde den Unterschied und teil mit welches das sichere Verfahren ist (jeweils manuell eingetragen = somit Tippfehler möglich)

Konto+BLZ < > IBAN
da die Prüfziffer der IBAN jedoch aus den Ziffern (Konto+BLZ) berechnet wird, ist eine Abweichung jeglicher Art sofort feststellbar bzw. wird entsprechend gemeldet/angezeigt.

@infoman
Dein erster Absatz stimmt schon wieder nicht. Es handelt sich um Prüfziffernberechnungen. Lies das bitte mal auf der Bundesbank Seite nach! http://www.bundesbank.de/Navig…hnung.html
Du bist da scheinbar nicht tief im Thema oder falsch informiert.

danke für den Link, da bin ich tatsächlich falsch informiert w.

aber du musst mir zustimmen, dass die direkte Eingabe der IBAN sicherer ist, also die Eingabe von Konto+BLZ mit nachträglicher Umrechnung (egal ob von app oder Bank)

Um das Thema noch komplexer zu machen:
Auch bei den Prüfziffernverfahren gibt es Verfahren ohne Pürffziffernberechnung (grundsätzlich oder für bestimmte Nummernkreise)
Löst damit auch das Problem nicht zu 100 %


Da die Umrechnungen sehr komplex (manchmal auch noch abhängig vom hinterlegtem Prüfziffernverfahren.....) und Umfangreich sind, ist die direkte Eingabe sicherlich sicherer, solange die eingegebene IBAN nicht auch ermittelt wurde. Wir haben hier schon diverse Fälle gehabt, bei der jemand meinte er hätte die komplexen Umrechnungsmethoden verstanden und falsch umgerechnet hat. Aber für das falsch ermittelte Ergebnis hat er die Prüfziffer richtig berechnet, so dass der Fehler beim Eintippen der IBAN nie auffallen würde.

Viele Grüße

Holger