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

Hallo Eldi,
das hört sich ja so ähnlich an, wie unser Problem mit der DB+Proficash:
phpBB2/viewtopic.php?t=354

Gruß
Raimund

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...

Wird denn bei der Ini bereits eine Kontonummer benötigt?

Soweit ich dachte, hängt das Ini-Problem mit dem Dialog zum Bankrechner zusammen und dass dabei mit unterschiedlichen HBCI-Versionen gearbeitet werden müsse. Das ließ mich auch der Eintrag "[InitRDH201As210]" in der wpc.ini vermuten.

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

Nein, in der INI wird keine Kontonummer benötigt. Vielmehr legt man in den "Ausnahmefällen" über die hbciinf.ini fest, welche Kontonummernlänge an diese eine Bank, bzw. genauer an das HBCI-System der Bank (gesteuert über die BLZ) übermittelt werden soll. Standardlänge in Deutschland sind bekanntlich ja 10 Stellen, unter anderen ist das auch in der DTAUS Spezifikation so geregelt, die HBCI ja mitbenutzt.

Das Deuba HBCI System mag aber nur 9 Stellen, die Netbank z.B. hätte gerne 7. Weitere Ausnahmen gibt es sicherlich auch noch.

In der INI sieht das etwa so aud:

[Kontenlen]
XXX7XXXX=9

@Karsten
Unser Verfahren heisst DDV

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...

Hallo,

die DeuBa ist finde ich eh immer ein Problemkind. Wir haben relativ häufig Probleme. Das mit der BLZ ist schonmal immer Mist. Denn normalerweise sind Duetschland Bankleitzahlen 8 stellig und nicht 7 oder 9 stellig. Noch schlimmer wird es, wenn die DeuBa alle Unterkonten üder die Hauptkontonummer einbindet. Dann geht nämlich garnichts mehr!

Aber in der <knowledgebase findet man viele Lösungen oder nur hier im Forum

Cu

Michael

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

Gruß Mike

Die Suchefunktion der knowlegdebase ist meiner Meinung nach die letzten 2 Jahre immer schlechter geworden. (Und der Support einiger Mitarbeiter ist auch nicht immer das gelbe vom Ei)

Gruß

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

Jetzt habe ich das gleiche mit einen FTAM-Kunden. Dort wird auch die führende "0" gebraucht, die aber vom SFIRM32 einfach weggelassen wird. Er bekommt nun den Hinweis beim Auszugabholen, dass das Konto (ohne 0) nicht existiert.

?
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..).

Das Problem mit der führenden Null tritt auch erst beim Einlesen der
abgeholten Kontoauszüge auf, da die Kontonummer in der sta Datei
nicht der entspricht, die in Sfirm schon angelegt wurde. Daher kommt
dann von Sfirm die Frage, welchem Konto die Umsätze zugeordnet
werden sollen oder ob das Konto neu angelegt werden soll.
Hier einfach das schon in Sfirm angelegte Konto ohne die führende Null
auswählen und schon sind die Umsätze an der richtigen Stelle.
Die Zuordnung merkt sich Sfirm, sie muß also nicht bei jedem Kontoabruf
gemacht werden.

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.