Lastschriften mit pain.008.001.08 werden nicht aktzeptiert

Wenn Foren-User nun schreiben, Banker/Banken bzw. deren Systeme sind "anno dazumal", da kommt ein "grüner User" (nein nicht die Partei) und will gleich erläutert haben "was sind die Banker/Banken und deren Systeme ..."
Realistisch muss man sagen, dass halt alles vertreten ist, von "haben wir schon immer so gemacht" bis "Echtzeitüberweisung ist bei uns Standard" ** oder die PB die auf das System der DB umgezogen ist usw.
**=GLS Bank-Interview: “Schnell Geld zu überweisen, sollte keine Bonus-Leistung sein!” https://www.it-finanzmagazin.de/gls-bank-interview-148532/

... und so verhält es sich mit den Zahlungsformaten - bis Ende 2025 ist halt für viele (nicht alle) Banken noch viel Zeit ...
Fakt ist - es wird kommen: https://banking.vision/umstell…t-formate/

Wobei man aber doch unterscheiden muss, zwischen Banking-Prog. und Banken-Server, denn beides müssen es ja können bzw. es ist halt die Frage wenn es der Banken-Server kann, ob die Banking-Software es durchleiten/sofort versenden kann.

Vielen Dank für die fachkundigen Antworten

Bis dahin wirst Du mit unterschiedlichen Konstellationen leben müssen.

Und woher weis der Anwender welches Format er braucht, bezw. welches nicht mehr funktioniert ?
Ich kenne im Moment nur die "Versuch-und-Irrtum"-Methode und das die Bank-Berater auch keine genauen Angaben machen können.

Genau das Problem.
PAIN.008.001.08 IST die neueste Version.

Leider steht unsere Hotline erstmal da "wie vom anderen Planeten"

Die unterstützen Formate werden über die BPD geliefert.

Das ist mir klar. Zwischen FinTS und EBICS gibt es so einige Differenzen bzgl der Formate.
In FinTS muss bei Überweisungen z. B. das Ausführungsdatum mit einem Datum 1.1.1990 entwertet werden. In EBICS muss es ein gültiges Datum sein.

Meistens behelfen sich Kunden dann damit dass die SEPA Dateien nicht nur versendet werden, sondern man sie importiert und die Software die dann zum Versand in der richtigen Formatversion neu zusammen baut. Solche Dinge bekommt ihr dann nicht mit.
Erst jetzt, wo noch nicht alle Software Produkte die neuste SEPA Version unterstützen, fallen solchen Dinge dann auf.

Meine Idee zu dem Thema war: Ich erzeuge keine SEPA-Dateien sondern "nur" CSV-Import-Dateien im Format des eingesetzten Softwareproduktes. Diese CSV-Dateien enthalten nur die wirklich nötigen Datenfelder. Der ganze Rest wird von der Banking-Software erledigt. Das klappt eigentlich wunderbar, die CSV-Importformate der Bankingsoftware ändern sich so gut wie nie.

Stellt sich dann nur noch die Frage: Gibt man EIN Bankprogramm fest vor, das zu verwenden ist. Oder macht man mehrere Module für verschiedene Bankprogramme, ggf. auf Zuruf mit Rechnungsstellung oder gar konfigurierbar. Da muss man überlegen, wie man bei seiner Software am besten klar kommt. In dem Zusammenhang erinnere ich mich wieder mit Wehmut an das gute DTAUS-Verfahren, welches von den Anfängen bis SEPA unverändert über Jahrzehnte gültig war...

Wir haben viel gemeinsam Ich bin zwar 5 Jahre jünger, aber auch alt genug. Auch bei mir ist es so, dass ich das Arbeiten nicht mehr zwangsweise nötig habe sondern noch mache, weil es mir Spaß macht. Mich gruselt immer, wenn ich überlege, ich wäre jetzt jünger und müsste mir alles zu den heutigen Bedingungen neu hart erkämpfen... was sicher in vielen Bereichen so gar nicht mehr machbar ist. Ich erwische ich manchmal dabei, dass ich schon so klinge wie meine Oma

Weil es dann unter Garantie genug Spezialisten gibt, die BEIDE absenden. Zumal es ja auch Fälle gibt, wo es zwei Dateien geben kann, die abgesendet werden müssen. Z.B. Erst-/Wiederholungslastschrift, verschiedene Ausführungstermine usw. Und an der Doppelausführung der zwei Dateien ist dann natürlich der Softwarehersteller schuld

Das ist schon klar. Aber es gibt viele Softwaren, die nach wie vor noch zwischen Erst/Wiederholungs/Letzt-LA trennen, auch wenn's nicht mehr nötig ist. Und bei verschiedenen Terminen müssen es getrennte Dateien sein.