Meine Bank nimmt bisher klaglos Sammelaufträge mit BLZ/Kontonr. an, deshalb habe ich Hibiscus lange nicht mehr upgedatet. Da ich die Sammellastschriften als DTAUS importiere, wäre es wichtig, daß diese Möglichkeit in Hibiscus auch weiterhin zur Verfügung steht. Wie sieht es damit aus?

(Die Datensätze werden durch Auslesen von Magnetstreifen von EC-Karten erzeugt, wo ja vorerst weder IBAN noch BIC enthalten sind und gibt Sammellastschriften als DTAUS-Datei aus.)

Laufen Kartenumsätze normalerweise nicht über den Terminalbetreiber? Da gibt es nämlich für bestimmte Übertragungen vom Betreiber zu den Rechenzentren Ausnahmeregeln, wo weiterhin Kto+BLZ verwendet werden kann. Aber ich kann mir kaum vorstellen, dass man diese Ausnahme auf FinTS ausweiten wird.

Das ist ein völlig anderes Thema. Die Magnetstreifenkarten werden jedenfalls noch eine ganze Weile im Umlauf sein. Die Frage ist:
Kann man mit Hibiscus weiterhin (wie mit Version 2.5.1, was ich derzeit nutze) DTAUS-Dateien importieren und versenden? (Letzteres demnächst wohl nur noch als SEPA-Auftrag)

wäre es mittel-/langfristig nicht sinnvoller einen DTAUS-Konverter einzusetzen?
(nächste Hürde kommt evtl. doch bereits am 01.08.)

Lieber Infoman, wo es nichts zu konvertieren gibt, setzt man auch keinen Konverter ein!

Für diese POS-Lastschrift-Zahlungen ist vereinbart, dass sie noch ich glaube 2 Jahre als BLZ/Kto Zahlungen gehen. Da ist eine Einreichung als SEPA-Lastschrift weder gefordert noch gewünscht. Das ist Absicht, es ist nicht nur die reine Datenübermittlung, es ist auch der rechtliche Rahmen der hinter der alten IZV-Lastschrift steckt, der b.a.W. erhalten belibt! Allein schon um den ganzen Fristen und dem Mandatsgefrickel zu entgehen. Wie onlbanker aber ganz richtig eingewendet hat, sind zwischen Terminalbetriebsfirmen und Banken Sonderwege zur Einreichung der Buchungen ihrer Kunden vereinbart und es ist eher unwahrscheinlich, dass die Banken die Möglichkeit der Einreichung von DTAUS-Dateien auf den bisherigen normalen Kunden-Wegen weiter unterstützen. Ich gehe davon aus, dass diese Wege Ende des Monats abgeschaltet werden. Somit würde ich da als Erstes mal mit meiner Bank reden ("Hallo, kann ich ab August eigentlich noch meine POS-Lastschriften über HBCI bei Ihnen einreichen?") und mir erst nach einem klaren JA Sorgen um die Software machen. Und falls die Antwort bei der Software nein lauten würde, weil der Programmierer die alten IZV-Funktionen nicht mehr pflegen mag und ausbaut, dann könnte man für diesen Übergangszeitraum (denn darum handelt es sich) ja immer noch eine Installation der letzten Softwareversion mit IZV zusätzlich behalten und für diese Transaktionen nutzen.

Das ist echt 'ne gute Frage. Wenn man die POS' per SEPA an die Bank schicken würde (Konvertierung von DTAUS in SEPA in der Software) wäre dann eine SEPA Lastschriftvereinbarung nötig? Oder ist das gedeckt durch die Regelung, dass POS Zahlungen noch im IZV verarbeitet werden dürfen?
Oder hängt das ganze am EInreichungsweg? Sehr gute Frage die man aber an die Bank stellen muss.
Denn die Bank wird das Zeug als DTAUS ja auch nicht los. Also muss an irgendeiner Stelle konvertiert werden. Denn Terminals werfen kein SEPA aus und POS Zahlungen auch nicht.

Ob Hibiscus am Ende aus DTAUS Lastschriften SEPA Lastschriften bauen kann weiß ich nicht, müssen wir mal auf Olaf warten, was er geplant hat.

Wieso wird die Bank das als DTAUS nicht los? Wie denn sonst? Es SIND Zahlungen im alten IZV. Man bekommt diese Lastschriften ja als Endbeteiligter ja auch als IZV-Lastschriften und nicht als konvertierte SEPA-Lastschriften. Schau mal auf Dein Sparkassen-Konto. Da bekommt man von POS "LASTSCHRIFT" und nicht "ERSTLASTSCHRIFT", "FOLGELASTSCHRIFT" oder "EINMALLASTSCHRIFT".

Aber denkst du, die werden tatsächlich noch im DTAUS gecleart? Dann wäre es ja wirklich einfach aber ist das so?

Ich weiß es nicht. Aber ich kann mir nicht vorstellen, daß die erste Bank DTA->SEPA wandelt, und die endbeteiligte wieder zurück... Zumal der gesamte rechtliche Hintergrund DTA-IZV ist und nicht SEPA.

Wäre dämlich aber möglicherweise nicht anders möglich. Keine Ahnung. Vielleicht sind das XML Sätze mit bestimmten Kennzeichen die bei der Empfängerbank dazu führen, dass die Kundenkontobuchung wie früher aussieht.


Ja, das ist nämlich die spannende Frage. Wird ein SEPA Mandat fällig, nur weil Kunde oder Bank eine POS Zahlung in XML weiterleitet? Ich meine nicht denn juristisch ist das ja die alte POS Zahlung und kein SEPA LS Mandat. Von daher sehe ich die rechtliche Situation unabhängig vom Übertragungsformat. Echt spannend.

Um zur urspruenglichen Frage zurueckzukehren. In der aktuellen Hibiscus-Version 2.6.7 ist vom alten Zahlungsverkehr noch nichts entfernt bzw deaktiviert worden. Der ist also noch vollstaendig drin. Das SEPA-Zeug kam *zusaetzlich* rein. Der in 2.5.1 existierende Funktionsumfang ist in 2.6.7 also auch noch enthalten. Wie lange aber noch, kann ich nicht sagen. Ich hatte aber schon vor, in den naechsten Versionen mit dem Rueckbau des alten Zahlungsverkehrs zu beginnen.

Danke für die Auskunft. Ich denke, so lange es einen Sinn ergibt, sollte die Funktionalität erhalten bleiben. In diesem Fall: so lange EC-Karten mit BLZ/Kontonr. im Umlauf sind. Optimal wäre natürlich, wenn man die eingelesene Datei in Hibiscus ins SEPA-Format konvertieren könnte. Wäre das möglich?

Da sieht man, wie die Meinungen auseinander gehen. Seit die SEPA-Geschaeftsvorfaelle in Hibiscus einigermassen komplett sind, kriege ich auch regelmaessig Fragen von Usern, wann denn endlich der alte Zahlungsverkehr aus Hibiscus verschwindet.



Also eine automatische Umwandlung von kompletten Zahlungsaufträgen/DTAUS-Daten nach SEPA wird es nicht geben. Dafuer sind die Formate einfach zu unterschiedlich, als dass sich das mit vertretbarem Aufwand automatisch umwandeln liesse.

Olaf, was hälst du davon, den alten IZV per Parameter aktivieren zu können? Ich denke mir immer, dass man DTAUS vielleicht auch zukünftig nochmal für irgendwas gebrauchen kann. Und wenn es für eine Bank ist, die nicht im SEPA-Raum agiert oder eben für solche Sonderlocken mit Kartenumsätzen.

Ich werd's die naechsten 1-2 Versionen erstmal so lassen, wie es ist. Danach seh ich mal weiter.