SEPA-Überweisung scheint's nicht zu tun (Verbindung hängt)

Hallo,

ich habe folgendes probiert:

SEPA-Überweisung angelegt.

Bei Verbindung mit der Bank klappt alles (wie sonst auch), aber wenn versucht wird, die SEPA-Überweisung zu übertragen, "hängt" die Verbindung, sobald Subsembly zum Schritt "CCS: <Empfängername>" kommt. Das heißt wohl, dass der Gegenstelle das HKCCS irgendwie nicht gefällt.

Im Ausgangskorb steht dann bei dem jeweiligen Auftrag:
"abgelehnt - 9800 Auftragsstatus ist wegen Zeitüberschreitung unklar"

Nun liegt's mir fern, mich zu beschweren - zum einen benutze ich gerade eine Testversion (da ich eben gerade wissen will, wie ich SEPA-Zeugs an's Laufen kriege), zum anderen ist SEPA noch so neu, dass es IMHO nicht ungewöhnlich ist, dass da noch nicht alles rundläuft.

Meine Frage Richtung Autor: Kann ich da irgendwie zum Debugging beitragen? Mach ich gern, wenn man mir sagt, wo ich hinklicken, was ich abspeichern und einschicken etc. soll.

Meine Frage an die restliche Leserschaft: Meine Bank ist bei der GAD angeschlossen. Gibt's Erfahrungen mit Subsembly und GAD-Banken (also Volks- und Raiffeisenbanken quasi in der Nordhälfte Deutschlands) ? Tut's das bei Euch mit SEPA-Überweisungen? Bzw. - tut's das überhaupt schon richtig bei der GAD? Könnte ja sein, dass SEPA-über-HBCI bei denen noch nicht so wirklich fertigprogrammiert ist. Ist ja alles neu, wie gesagt, und finde ich auch nicht schlimm. Aber Debugging wäre jetzt interessant ...


Viele Grüße,

ChrisK2

Das hat aber - zum Teil jedenfalls - auch einen guten Grund ...

Ich hab mir mal angesehen, was VR-NetWorld macht ... und das benutzt anscheinend nicht HKCCS für SEPA-Überweisungen, sondern irgendein proprietäres Zeugs (IKKLI hab ich im Log gesehen, und noch ein paar undokumentierte Sachen - leider ist das Log bei den proprietären Nachrichten nicht sehr detailliert, so dass ich nicht sehen konnte, was da *genau* passiert).

Daher eben mein Verdacht, dass da im Bereich der (bankübergreifend) HBCI-konformen Software rechenzentrumsseitig eventuell noch irgendwas nicht fertiggestellt ist. Aber ist im Moment reine Spekulation ... solange Logs nicht mehr hergeben, kann man ja nur raten.

Welche Programme (neben VR-NetWorld) hattest Du probiert, mit denen SEPA klappt? Profi Cash? Geno Cash (heisst das so?) ?


Viele Grüße,

ChrisK2

Hallo,



Scheinbar wurde der Auftrag erst mal vom HBCI-Server angenommen. Die Meldung "9800 Auftragsstatus ist wegen Zeitüberschreitung unklar" kommt von der Bank, d.h. da Timeout passiert irgendwo intern im Banksystem! Möglicherweise bekommt der HBCI-Server keine Rückmeldung vom Backend.



Ich befürchte, dass das Protokoll in diesem Fall nicht mehr hergibt als die bereits von Dir zitierte Fehlermeldung. Vielleicht war es auch nur ein vorübergehender Aussetzer. Schon mal einen zweiten Versuch gestartet?



So ein Feedback würde mich auch interessieren. Bislang kann ich nur sagen, dass es bisher (abgesehen von diesem Posting) noch kein negatives Feedback zu SEPA in Subsembly Banking überhaupt gegeben hat.

Selbst getestet hatte ich die SEPA-Überweisung bislang nur mit der Commerzbank und der RaiBa München Süd (Fiducia Rechenzentrum). Beim GAD Rechenzentrum habe ich leider kein Konto und alle meine anderen Produktivkonten können gar kein SEPA.

Da Commerzbank, Deutsche Bank, HypoVereinsbank und Dresdner Bank alle den gleichen HBCI-Lieferanten haben, denke ich, dass der Test mit der Commerzbank hier "repräsentativ" sein sollte.

Eigentlich dachte ich, dass GAD und Fiducia inzwischen die gleiche HBCI-Serversoftware einsetzen. (@Holger: Stimmt das?) Somit hätte ich auch hier keinen Unterschied erwartet.

Hallo,

logs interessieren mich immer. In Subsembly Banking unter Extras > Protokolle zu finden.

Leider bietet die StSpk München (ebenfalls SI) bislang noch kein SEPA, sonst könnte ich es selbst testen.

Hallo,

danke für den Tipp, werd' mein Glück bei der StSpk versuchen.

Danke auch für die Protokolle. Es ist wirklich so wie Du sagst, die IBAN ist in beiden Fällen identisch und sicher richtig. Ebenso der generelle Aufbau der XML-Daten.

Es gibt nur einen nennenswerten Unterschied. Im <Document> Wurzelelement wird von S-Firm ein schemaLocation Attribut eingestellt. Ich stelle dieses nicht ein. Im Detail sehen die Tags wie folgt aus:

S-Firm:


Subsembly Banking:


Wer kann mit Gewissheit sagen, ob es daran liegt? Benötigt die SI das schemaLocation Attribut wirklich? Wieso kommt die Fehlermeldung, dass die IBAN falsch sein?

Hallo,

das ist ja auch nur ein Beispiel. Die IBAN ist dort auch eine andere

Jetzt im Ernst. Das schemaLocation Attribut gibt an, wo die XML-Schemadatei zur Validierung der XML-Daten zu finden ist. Generell ist bei XML-Dokumenten dieses Attribut optional. Insbesondere, wenn man davon ausgehen kann, dass der Empfänger selbst weiß, wo er das Schema finden kann.

Die Angabe



besagt, dass das Schema mit dem Namen "urn:sepade:xsd:pain.001.001.02" mit dem Dateipfad (!) "pain.001.001.02.xsd" zu finden ist. Dabei handelt es sich um eine relative Pfadangabe, d.h. die Schemadatei muss im gleichen Verzeichnis wie die XML-Datei liegen. Auf dem Server wohlgemerkt. Deshalb wäre die eigentlich sinnvollere Angabe:



Womit ein definierter fester Pfad (URL) zur Schemadatei angegeben wäre. Auf Seite 24 der von Dir angegebenen Spezifikation ist unter Schema-Dateien auch genau dieser Pfad festgelegt. Leider sind die weiteren Ausführungen dort etwas schwammig: "Es wird davon abgeraten, direkt die im Internet abgelegten Schemata für die Validierung von
XML-Dateien zu verwenden." Und so weiter.

Eine robuste Implementierung der XML-Validierung wird keinesfalls auf das schemaLocation Attribut vertrauen, sondern die Daten mit der XML-Schemadatei seines Vertrauens validieren. Eine Angabe des Attributs halte ich daher für überflüssig. Bei den von mir getesteten Banken funktioniert es jedenfalls auch ohne dieses Attribut.

Ich werde mal zum Spaß eine SEPA-Überweisung mit genau diesem so zitierten Attribut bei anderen Banken machen. Außerdem werde ich zum Spaß mal so etwas wie "c:\pain.001.001.02.xsd" einsetzen.