Leider ist es mir nicht möglich, mich mit meinen alten Account einzuloggen, daher ein neuer Thread. Trotz Passwort zurücksetzen komme ich einfach nicht mehr rein. :shock:

Nun, dann muss es halt so gehen.


Ich konnte jetzt die Sepa-Überweisung mit Hibiscus Server 2.5.1-nightly [Build: 220] ausprobiert, aber leider will es trotzdem nicht. Anbei der Logauszug:

HBCI error code: 9010:*Auftrag konnte nicht verarbeitet werden. Auftrag abgelehnt. (3: CustomMsg.GV.UebSEPA1) org.kapott.hbci.status.HBCIStatus.addRetVal(HBCIStatus.java:72)

18.09.2013 17:28:49

HBCICallbackServer

HBCI error code: 9050:Die Nachricht enthält Fehler. org.kapott.hbci.status.HBCIStatus.addRetVal(HBCIStatus.java:72)

-------------------------------

18.09.2013 17:28:49

HBCICallbackServer

entschlüssele Antwortnachricht

-------------------------------

18.09.2013 17:28:48

HBCICallbackServer

waiting for response

-------------------------------

18.09.2013 17:28:48

HBCICallbackServer

warte auf Antwortdaten

-------------------------------

18.09.2013 17:28:48

HBCICallbackServer

versende HBCI-Nachricht

-------------------------------

18.09.2013 17:28:48

HBCICallbackServer

verschlüssele HBCI-Nachricht

-------------------------------

18.09.2013 17:28:48

HBCICallbackServer

signiere HBCI-Nachricht

-------------------------------

18.09.2013 17:28:48

HBCICallbackServer

erzeuge HBCI-Nachricht CustomMsg

-------------------------------

18.09.2013 17:28:48

HBCICallbackServer

erstelle Auftragsdaten für Geschäftsvorfall UebSEPA1

-------------------------------

18.09.2013 17:28:48

HBCICallbackServer

Ergebnisdaten für Geschäftsvorfall UebSEPA1 empfangen

------------------------------



Fehler beim Ausführen des Auftrages an xxxxx xxxxx: Fehlermeldung der Bank:
9010 - *Auftrag konnte nicht verarbeitet werden. Auftrag abgelehnt.
9010:*Auftrag konnte nicht verarbeitet werden. Auftrag abgelehnt. (3: CustomMsg.GV.UebSEPA1)
9050:Die Nachricht enthält Fehler.


Die Bank sagt, es ist alles freigeschaltet für SEPA. Folgende PAIN-Versionen verwendet die Bank:

CCTCredit Transfer Initiation (SEPA Überweisung) pain.001.002.03.xsd
CDD Direct Debit Initiation (SEPA Basislastschrift) pain.008.002.02.xsd
CDB Direct Debit Initiation (SEPA Firmenlastschrift) pain.008.002.02.xsd

Hatte Hibiscus denn die neue Pain Version 1.2.3 schon drin? Oder kommt da erst noch ein Update?

Ja, im aktuellen Nightlybuild werden diese Pain-Versionen unterstuetzt. Das ist aber erst in den letzten Tagen eingebaut worden. Ggf ist also nochmal ein Update auf das tagesaktuelle Build noetig.

Mhhh, was kann ich da jetzt machen ? Der Build war ja vom 18.09.2013.

humty, kannst du bitte mal ein detailliertes Log zeigen. Bitte in Code Tags setzen.

1) Dich mit deiner Bank in Verbindung setzen und die fragen, was genau sie mit der Meldung "9010:*Auftrag konnte nicht verarbeitet werden. Auftrag abgelehnt." meinen

2) In "jameica.log" nachschauen, ob du da weitere Fehlermeldungen findest.

Soooo, hab den Fehler gefunden. Das schöne, in der Log ist ein Dump vom XML-Request drin gewesen

Nun zum Fehler.
Der Name des Kontoinhabers hat ein ü drin was die Bank so anlegte hatte
Beim Import der Schlüsseldiskette wurde das Konto/Inhaber immer mit einem ü angelegt. Einfach in der Tabelle "konto" die Sonderzeichen im Kontoinhaber durch wie in meinem Fall ue ersetzen und schon läuft es ohne Probleme.

Vielleicht könnte man ja sowas in zukünftigen Versionen berücksichtigen, eine Warnung oder so, dass da was nicht passt

Vielen Dank trotzdem für die Hilfe. :mrgreen:

Es war wirklich wegen eines Umlauts??

@hibiscus: Wenn das wirklich der Fehler war, musst du nochmal nachlegen. Auf Seite 23 ff (PDF Blatt 29) von http://www.ebics.de/fileadmin/…e_V2.7.pdf findest du auch die Best practice für den Umgang mit Umlauten und Sonderzeichen.

Ja, hab ich schon auf der Todo-Liste. Da ich mir nicht vorstellen kann, das deutsche Umlaute nicht erlaubt sind, vermute ich, dass ein falsches Encoding verwendet wurde. Ich schaue heue abend nochmal in die Spec.

Tja, dort steht "Die Kreditinstitute verpflichten sich zu deren Annahme".

Und unter der Tabelle heißt es "Das Kreditinstitut ist berechtigt, bei Verwendung von Zeichen außerhalb dieses Zeichenvorrats die unzulässigen Zeichen zu ersetzen oder gegebenenfalls auch die gesamte Datei zurückzuweisen"

Das heißt jetzt, sie müssen es annehmen, brauchen es aber nicht
Kommt darauf an, ob man in den erwähnten "Zeichenvorrat" nur die Basiszeichen aus der oberen Tabelle interpretiert oder auch die Sonderzeichen in der Tabelle darunter.
Eindeutig ist die Beschreibung nicht.

Ich empfehle: Alle Umlaute vorher umwandeln, dann kann das bei keiner Bank mehr ein Abweisungsgrund sein.

So, hab mir einen Ueberblick verschafft. Im Prinzip betrifft das nur den Inhabernamen des eigenen Kontos. Beim Inhabernamen des Empfaengerkontos, bei Verwendungszweck und bei der End-to-End ID lasse ich bereits in der Eingabe nur die in der Spec definitiv zugelassenen Zeichen zu.

Gluecklicherweise. Denn sonst waere das mit den Ersetzungen u.U. gar nicht so trivial, wie es klingt. Naemlich dann, wenn man zwar z.Bsp. ein "Ü" gegen "Ue" ersetzen will, dadurch aber der Text um ein Zeichen laenger wird und genau dadurch die maximal zulaessige Laenge (beim Verwendungszweck z.Bsp. 140 Zeichen) ueberschreitet - weil der Text vorher mit Umlaut schon exakt 140 Zeichen lang war. Die Ersetzung eines "Ü" nur gegen "U" finde ich nicht sonderlich schoen.

Aber wie gesagt - ist kein Problem, da nur der eigene Name betroffen ist. Und der ist beim bisherigen inlaendischen Zahlungsverkehr i.d.R. auf 27 Zeichen begrenzt - in SEPA sind aber 70 Zeichen zulaessig. Ich bau die Ersetzung rein - ist morgen im Nightly-Build.

Also ich hatte die hibiscus Datenbank als iso schwedisch und als utf8 general angelegt, beides ging nicht und das Dump sah immer so aus:

Naja, wie das immer so ist. Eine Nachfrage danach bei der Bank brachte die Info, dass das so nicht erlaubt sei mit den Sondereichen im Inhaber bei SEPA (Das Konto wurde aber so anlegt von der Bank).

Halten wir fest, SEPA ist auch für Banken "Neuland"

Siehe mein zweites Posting von gestern 23:18 - die Frage nach dem Encoding stellt sich nicht mehr. Ist gefixt. Durch Ersetzung der Umlaute.

Da man ja meistens im Verwendungszweck nur Nummern und paar Buchstaben braucht, isses nicht so tragisch. Soll ja auch kein Roman rein

Danke für den Patch

Aber die Daten von der Bank oder z.B. per API werden schon als UTF8 gespeichert ?

Wie gesagt - das Encoding spielt keine Rolle. SEPA laesst nur den ASCII-Raum als moegliche Zeichen zu. Da sowohl in Latin1/ISO-8859 als auch in UTF8 die Zeichen auf den ersten 7 Bit (Zeichen 0-127) identisch belegt sind, macht es gar keinen Unterschied, ob das vorher UTF8 war oder Latin1. An die Bank darf nur der kleinste gemeinsame Nenner dieser Zeichensaetze gesendet werden.