Hallo zusammen,

habe da einen Kunden, der mit SFirm32 Ver. 2.0h arbeitet.
Es werden extern erstellte DTA-Dateien gesendet.
Bislang per BTX, da wir aber jetzt den ZKA-Dialog abgeschaltet haben, hat der Kunde auf HBCI-PIN/TAN umgestellt. Nun bekommt er folgende Fehlermeldung:

Der Auftrag wurde übertragen aber von der Bank nicht oder nicht vollständig akzeptiert
Meldung der Übertragungskomponente:
DTAUS-Format ungültig (Code 9000)
BB3.KSBD91F KUM1212 00000 F
Verwendete TAN: xxxxxx

Wir sind übrigens eine Voba mit RZ=GAD
In den BB3-Autorisierungsdaten kann ich nichts sehen.
Habe mir die DTA-Datei per Diskette kommen lassen und geprüft - aber keine Fehler.
Verarbeitung der Diskette in BB3 war dann auch problemlos möglich.

Hat vielleicht jemand eine Idee?

Gruß
Senastian Kruse

Werden die fremd-erstellten DTAUS Datein per Direktversand oder per Import und anschliessender normaler Ausgabe in Sfirm versendet?

Problem ist nämlich möglicherweise, dass die DTAUS wirklich eine Macke hat und bei Direktversand von Sfirm ohne jegliche Prüfung oder Veränderung übertragen wird. Der HBCI Host der GAD findet aber offensichtlich einen Fehler im Aufbau....

Ich würde dann einmal versuchen die Datei erst zu importieren und dann auszugeben, dabei wird dann durch SFirm ein frische DTAUS erstellt.

Mit welchem Programm hast du die DTAUS geprüft?
Unsere Diskettenstation ist z.B. wesentlich fehlertoleranter als die direkten Online Schnittstellen.

In SF32 ist auch direkt ein DTAUS Tester integriert, vielleicht auch damit mal Testen (Datei->DTA Dateien->überprüfen).

Eventuell hilft auch ein Update auf H-SP3, dann eigentlich regelmässig am HBCI PIN/TAN Kernel Änderungen durchgführt werden.

hi,

kann es evtl. auch sein, dass die datei zu viele buchungen beinhaltet?
ich habe mal bei einem kunden genau das gleiche problem gehabt, dass unsere rz (sparkasse) im bereich hbci nur nit einer maximal-anzahl von buchungsposten im bereich hbci umgehen...

gruß

der don

Soweit ich weiss bei der GAD nicht. Überasteigt eine Datei inhaltlich 300 C-Sätze wird asyncron verarbeitet. Danach sollte der Sender natürlich ein Status Protokoll abholen.

Interessant wäre aber mal was die BB3 Meldung "KSBD91F KUM1212 00000 F" bedeutet.... Das ist doch sicherlich irgendwo dokumentiert.