HBCI-Diskette mit Deutscher Bank

Hallo Leute,

habe mal zwei Fragen zur Einrichtung von HBCI mit Diskette im SFIRM32 für DeuBa-Konten:

1. Beim Austausch des öffentlichen Schlüssels stimmte der Schlüssel auf dem INI-Brief und dem ausgetauschten stimmten nicht überein. Die Kollegen der Deuba meinten, dass würde so funktionieren, da das eine der private und das andere der öffentliche Schlüssel. Das kam mir reichlich komisch vor.

2. Nachdem das Konto erfolgreich initiallisiert wurde ("Benutzer anfordern"), ging der Umsatzabruf nicht, mit dem Hinweis, dass das Konto nicht existiert oder die Kunden-ID falsch ist. Habe noch mal alles überprüft, alles ok.

Die Lösung von der BIVG: in der HBCIINF.ini die BLZ der DeuBa auf 9-stellig setzen. Das hat auch funktioniert.

Alles etwas seltsam. :? Hat jemand anderes schon Erfahrung damit gemacht?

Schönes Wochenende wünscht der

ELDI-Man

Die Sache mit der Begrenzung auf eine maximal 9-stellige Kontenlänge im HBCI Dialog über die INI-Datei ist unter anderem auch in der SFirm Knowlegebase beschrieben.

Das es sich um das gleiche Problem wie in ProfiCash handelt, bezweifle ich aber. SFirm benutzt für HBCI Chipkarte und die Sicherheitsdatei-Lösung den good-old Starfinanz Kernel, nicht die PPI Geschichte.

Die Problematik habe ich auch schon mal im internen SFirm Forum beschrieben und gefragt ob den eine allgemeingültige Lösung nicht auch von anderen Beratern gewünscht würde. Darauf gab es glaube ich null Reaktion...

Die HBCI-Versionen müssen gleich sein, sonst kann es zu Problemen kommen. Der Deuba-Rechner verlangt nur exakte Kontonummern. Ohne Eintrag in der INI erzeugt SF32 eine 10stellige Kontonummer (mit einer 0 vorne aufgefüllt) und die kennt der Deuba-Rechner nicht.
Der Eintrag der hier angezeigt wird hat damit nur wenig zu tun. Der Eintrag hat etwas mit der Schlüsselart zu tun. RDH ist der von der Deuba verwendete "Typ". Dieser wird entweder auf einer Diskette/Festplatte abgelegt oder auch auf einer Chipkarte. Viele Sparkassen nutzen einen anderen Typ. Ich komme aber momentan nicht auf den Namen.

Gruß Karsten

Hey, das wusste ich auch noch nicht. Und mir ist gerade klar geworden, dass es sich ja hier um 2 Probleme handelte, hab ich einfach überlesen, sorry.

Nunja, mein Fazit: Ich hätte gerne eine Datenbank für diese ganzen Ausnahmen. Irgendwie behalte ich das in meinem Alter nicht mehr so alles im Kopf...

Stimmt genau, doch wenn ich in der Knowledgebase "Deutsche Bank" eingebe, kam ich nicht auf die Lösung. Half nur ein Hotlineanruf.

Gruß Mike

Hallo Michael,


Da ich SFirm nicht weiter kenne, verstehe nicht was bei der DeuBa so problematisch ist...

BLZ: die ganz normale achtstellige BLZ

HBCI Daten
Kundennummer: dreistellige Filialnummer + siebenstellige Hauptkontonummer (alles hintereinander weg ohne Leerzeichen)
Benutzerkennung: Buchstaben-Zahlen-Kombination die dem Kunden mitgeteilt wird
HBCI Version: 2.01
IP: 193.150.167.8

Beim Syncronisieren mit dem Bankrechner werden alle freigeschalteten Konten zurückgemeldet und zur Kontoeinrichtung angeboten. So zumindest meine Erfahrungen mit SM und DDBAC-basierenden Produkten.

Gruß
Daniel

?
Bei nem Abruf einer MT940/MT942 Datei über FTAM wird eigentlich nur die Kunden-ID benötigt. Die Umsätze über FTAM werden ja kontounabhängig bereitgestellt, ich verstehe daher nicht so ganz wie das Problem überhaupt entsteht.

Einzig beim Verarbeiten der abgeholten Umsätze kommt manchmal die Frage, zu welchem in Sfirm vorhandenen Konto die Umsätze zugeschlüsselt werden sollen, oder ob ein neues angelegt werden soll (neues Konto, falsches Unterkontomerkmal usw..).

Hallo,

ja und zwar legt Sfirm32 dies in der Konten.ini ab. Also einmal zuordnen und dann funktioniert es. Dies trifft häufig bei Coba, Dreba und Deuba auf, da diese meist vorstellige oder nachführende Nullen an die Kontonummer anhängen.

PS: Es geht hier um FTAM.