Hallöchen @ all,
ich hoffe Ihr könnt mir helfen. ops:

Folgende Situation:
Sparkassenkonten sind über EBICS eingerichtet (bisher FTAM)
Dresdner und Deutsche Bank per HBCI PIN/TAN.
Sfirm lokal installiert. C:\Programme
Sfirm32 Version 2.2.1 PL5
DFÜ per ISDN-Karte

Vor der Umstellung von FTAM auf EBICS lief der Rundruf sauber durch. Nach der Umstellung läuft Dresdner und Deutsche sauber und bei der Sparkasse kommt die folgende Meldung.

Ebics Fehler: 0Code:8,de.ppifis.travic.ebics.kernel.transport. Communikation Exeption. Bei der Kommunikation mit https://www.ebics-net.de

Das komisch daran ist, dass wenn ich Dresdner und Deutsche im Rundruf deaktiviere, läuft der Abruf der Sparkasse per EBICS sauber.
Es schein also, das der Automat bzw. der Ebics-Kernel nach der HBCI-Übertragung keine SSL-Verbindung zu https://www.ebics-net.de
aufbauen kann.

Was nun ?

Patchlevelreperatur wurde gemacht, Firewall und Virenscanner wurden zum Test deaktiviert ? Keine Änderung

Wer hat noch eine Idee ?

Hallo michaweb007 !

Vielleicht könnte man ja mal die DFÜ-Traces für EBICS und HBCI aktivieren
(Extras - Optionen - DFÜ Traces), dort dürfte ggfs. mehr zu erkennen sein, warum SFirm sich beim Umschwenken auf die EBICS-Verbindung so verhält, wie Du es hier beschrieben hast.
Ggfs. auch mal die Protokollierung nach jedem einzelnen Automatenzyklus anschalten.

Falls noch im Programm vorhanden, sollten die DFÜ-Einstellungen für das "alte" FTAM-Verfahren der Sparkasse einfach herausgenommen werden
(Extras - Optionen - Administrator1 - verfügbare DFÜ-Wege festlegen), dann die Rundrufdefinition noch mal raus und neu definieren (im Auftraggeber).

Mehr wüßte ich jetzt auch nicht dazu zu sagen, habe nur mein eigenes Konto im Zugriff und leider keine Fremdbanken dabei.

Was hat denn der Support der BIVG dazu gesagt - oder konntest Du die noch nicht fragen ?

Gruß
Black Knight

Hallo,

ich habe die Fehlermeldungen nicht mehr genau im Kopf - aber vielleicht hilfts ja als Spur, auch wenn mir das bisher eher bei Hypo und Coba über den Weg gelaufen ist.

In den BPD kann man die URL von EBICS noch zertifizieren lassen. Bei Sparkasse lief das bisher ohne Probleme aber wer weiß, vielleicht liegts ja daran.

Eventuell tatsächlich ein Zertifikatsproblem, nur ist das Verhalten ungewöhlich. Entweder gibt es ein solches oder nicht, keine Abhängigkeit zu den Banken im Rundruf.

Kannst du mal checken, ob du Zertifikate der Banken/Rechenzentren im Betriebssystem finden kannst?

Die Funktion Zertifikat prüfen in den Bankparametern führt "nur" eine Vorabprüfung durch. Nicht vorhandene Zertifikate können auf diesem Weg dem Programm bekannt gemacht werden. Das dürfte beim FIT-Zerti nicht nötig sein...

Habe mittlerweile 2 Kunden mit diesem Problem.
Das Problem konnte etwas näher eingegrenzt werden.
Die Zertifikate sind es meiner Meinung nach nicht, sonst würde ja ein EBICS-STA-Einzelabruf bzw. IZV-Dateien auch nicht funktionieren. Oder ?

Da die DFÜ per ISDN somit also DFÜ-Verbindung abläuft, habe ich einfach mal ein paar Einstellungsvarianten getestet.
Der Fehler trat immer auf, nachdem die Umsätze der HBCI-Banken sauber abgeholt wurden. In den DFÜ Einstellungen war hinterlegt, das die Verbindung nach Übertragung immer ohne Nachfrage getrennt werden soll.
Das Problem ist halt, dass nach dem HBCI-Abruf die Verbindung getrennt wird und für den EBICS-Abruf nicht erneut aufgebaut wird.
Wenn ich die Einstellung dahingehend ändere, dass die Verbindung bestehen bleiben soll.(keine automatische Trennung) dann läuft der komplette Rundruf samt EBICS sauber durch.
Die "Wartezeit bei langsamer Interneteinwahl" hab ich schon auf 30 Sek. hoch gesetzt, brachte aber keinen Erfolg.

Weitere Ideen :?:

Gesonderte Einwahlverbindung nur für SFIRM erstellen, diese in den SFIRM-DFÜ-Einstellungen für die Anwahl festlegen und bei dieser die betriebssystemseitige automatische Trennung nach z.B. 20 Sekunden Nichtnutzung einstellen, die Verbindung aber nicht automatisch durch SFIRM trennen lassen. Der Kunde bestätigt dann halt die Trennung wenn die Abfrage vom BS kommt bzw. kann man die vielleicht sogar automatisieren.

Ich vermute mal die EBICS-DFÜ startet schneller als die Trennung vom HBCI erfolgt. Somit erfolgt keine Wiederanwahl sondern die DFÜ bricht dann einfach ab wenn die Trennung erfolgt und erzeugt die Fehlermeldung.

Das wäre dann aber ein Programmfehler . Oder ?

Als Übergangslösung habe ich auch die Trennung nach 30 Sek. Inaktivität eingerichtet, doch der Kunde ist nicht so richtig glücklich damit, da es bei FTAM früher alles automatisch lief und das Problem jetzt mit der EBICS-Umstellung aufgetreten ist.
:roll:

Nein. Ich stelle mir das Praktisch so vor. Der alte Ablauf:

-> HBCI baut DFÜ per DFÜ-Netzwerk auf
-> HBCI-Übertragung läuft
-> HBCI trennt die DFÜ-Netzwerk-Verbindung
-> FTAM baut DFÜ per Capi auf (2. Leitung oder 1. wenn schon wieder frei)
-> FTAM-Übertragung läuft
-> alles i.O.

Jetzt passiert folgendes:
-> HBCI baut DFÜ per DFÜ-Netzwerk auf
-> HBCI-Übertragung läuft
-> EBICS erkennt die noch bestehende DFÜ-Netzwerk-Verbindung und beginnt mit der DFÜ
-> HBCI-Modul beendet aufgrund der Einstellungen die DFÜ-Verbindung und kappt somit den Abruf EBICS
-> für die EBICS-Übertragung ist die DFÜ gescheitert.

Wenn die EBICS-DFÜ erst einsetzen würde wenn die Trennung schon erfolgt ist sollte eine Wiederanwahl erfolgen und das Problem wäre nicht vorhanden würde ich meinen. Aber so versucht das EBICS-Modul natürlich die noch vorhandenen Verbindung zu nutzen und die wird dann getrennt.

Also zumindest ist das für mich die logischste Erklärung.