DTA-Dateien aus dem DATEV-Rechenzentrum (LODAS)

[#1]

Moin,

im Infoservice Februar 2018 steht u.a. drin, dass die DTA-Dateien aus dem Rechenzentrum ab März 2018 auf SEPA 3.0 angepasst werden und in einer PAIN/XML-Version pain.001.001.03 erzeugt werden.

Das sagt mir im ersten Schritt erst mal nicht viel, ich leite die SEPA-Dateien ja letztlich nur an unsere Mandanten weiter. Nachdem ich einigen Mandanten die Info direkt aus dem Infoservice kopiert habe, erhielt ich inzwischen eine Rückmeldung, dass doch die aktuellen SEPA-Dateien schon eine neuere pain-Version haben.

Ich habe mir daraufhin mal die aktuellen SEPA-Dateien aus dem Lohn und den Aufbau der Dateien angeguckt. Schon seit längerem (geprüft habe ich dies mit Dateien aus Mitte 2017) haben diese eine Versionskennung pain.001.003.03. Das klingt erst einmal aktueller als die im Infoservice angegeben Version.

Die SEPA-Dateien aus dem Rechenzentrum erstellen wir über die Auswertung in LODAS - Zahlungsverkehr (Rückübertragung aus RZ - DTA-Datei).

Ändert sich hierbei nun was? Müssen Mandanten irgendwas tun, wenn die aktuellen Daten gelesen werden können?

Irgendwie stehe ich gerade ein wenig auf dem Schlauch...

Viele Grüße

Uwe Lutz

[#2]

Hallo Herr Lutz,

sollten Zahlungsdaten für den Datenträgeraustausch (DTA-Dateien), welche nach dem 01.03.2018 erzeugt wurden, nicht eingelesen werden können, aktualisieren Sie bitte die Banking-Software.

Beste Grüße

Kristin Frohmeyer
Personalwirtschaft
DATEV eG

[#3]

Seit dem 19.11.2017 hat sich der sepa Standard geändert.

Hatte selbst das Problem dass ich bei einem Kunden ( Schweizer Bankverbindung) nicht mehr abbuchhen konnte. Grund Formatänderung, bei Kunden ausserhalb der EU muss die Adresse auf 2 neuen Felder mit angegeben werden.

Lies sich nur lösen in dem ich meine Banking Software Starmoney Business upgedatet haben.

Zur Info folgender Link:

https://www.hypovereinsbank.de/content/dam/.../pdf/SEPA/SEPA_Formate_de.pdf

[#4]

Hallo Frau Fromeyer,

soweit hatte ich das schon verstanden -  das stand ja auch schon im Infoservice.

Ich hatte unsere Mandanten vorab darüber informiert, damit eine Aktualisierung -wenn notwendig- vorher erfolgen kann. Und dabei ergab sich ja gerade mein geschildertes Problem:

Die aktuellen Dateien (vor dem 01.03.2018 erstellt) haben eine PAIN-Version 001.003.03.

Lt. Infoservice haben die neuen Dateien (ab dem 01.03.2018 erstellt) eine PAIN-Version 001.001.03.

Und das klingt, als passt da irgendwas nicht, denn die aktuellen Dateien haben danach eine höhere Versionsnummer.

Und damit die Mandanten nun für die eigene Bankingsoftware klären können, ob ein Update notwendig wird, wäre hierzu eine weitere Info sinnvoll, was es mit diesen PAIN-Versionen auf sich hat.

Und dies sollte möglichst passieren, bevor die nächsten Daten nicht eingelesen werden können, da es ggf. etwas dauert bis der EDV-Verantwortliche dann auch das Update erstellen kann. Und so lange können Lohnzahlungen meistens nicht warten...

Viele Grüße

Uwe Lutz

[#5]

Moin,

ich habe einmal bei einer heute erstellten Abrechnung die Versionskennung geprüft. Diese ist unverändert pain.001.003.03.

Wurde dies noch nicht umgestellt?

Was sagen mir diese Pain-Versionsnummern? Was müssen/können die Mandanten denn nun tatsächlich vorab prüfen?

Viele Grüße

Uwe Lutz

[#6 · Accepted solution]

Hallo Herr Lutz,

im Zahlungsverkehr sind die Pain-Versionen gängiger als die SEPA-Versionen, weshalb wir uns dafür entschieden haben, diese mit anzugeben.

Die Pain-Versionen werden nicht laufend durchnummeriert. Die von Ihnen angegebenen Pain-Versionen entsprechen folgenden SEPA-Versionen:

001.003.03 = SEPA 2.7

001.001.03 = SEPA 3.0

Freundliche Grüße

Monique Schauer

Personalwirtschaft

DATEV eG

[#7]

Hallo Frau Schauer,

ich danke für die Erläuterung. Wieder was dazu gelernt.

Ich bin doch bloß Steuerberater und will mich doch eigentlich um die EDV gar nicht so viel kümmern

Viele Grüße

Uwe Lutz

[#8]

Da seit dem 19.11.2017 das Sepa Format 3.1 gilt, wäre doch die spannende Frage wann das in welche Pain Version umgesetzt wird.

[#9]

Ich bin doch bloß Steuerberater und will mich doch eigentlich um die EDV gar nicht so viel kümmern

Ich befürchte für ihre Mandanten dürfen Sie das Steuer durch Universal ersetzen.

Und das wird zukünftige wohl immer mehr. Ich weiss glaube ich nicht mehr wieviel meiner Mandanten und Exmandanten ich schon gehofen habe nur eine einfachen Elster Login hinzubekommen.

[#10]

Hallo,

bitte entschuldigen Sie die verspätete Antwort. Aktuell ist die Umsetzung des SEPA Formates 3.1 noch nicht geplant. 

Viele Grüße

Verena Heinlein
Personalwirtschaft
DATEV eG

[#11]

D.h. aber doch wenn ich richtig informiert bin das mit den DTA Dateien eine Zahlung z.Bsp auf ein schweizer Bankkonto nicht (mehr) möglich ist, da mit dem Format 3.1.

zwingend die Adresse des Kunden mit eingepflegt werden muss und dies m.E. erstmal mit Format 3.1 möglich ist ?

[#12]

Hallo,

wir geben SEPA.xml Dateien nach dem Standard der deutschen Bundesbank aus. Die Ausgabe einer Adresse ist prinzipiell möglich, aber nicht zwingend erforderlich. Daher wird – zumindest aktuell – keine Adresse innerhalb des Zahlungsträgers gefüllt.

Freundliche Grüße

Verena Heinlein

Personalwirtschaft

DATEV eG

[#13]

Nichts für ungut Frau Heinlein.

Ich machen Lastschriften auch auf Schweizer Bankverbindungen mit Starmoney Business Version 8.0. ( Hier ist das Sepa Format  3.1 hinterlegt.

Die Vorgängerversion hatte dies nicht sondern Sepa 3.0. Folge war dass ich seit dem 17.11.2017 oder 19.11. die Lastschriften nicht mehr eingelöst wurden.

Nachfrage bei der einzulösenden Bank war zunächst- Adresse ist pflicht. Gut habe ich halt die Adresse eingegeben - Ging trotzdem nicht. Eben weil sich der Sepa Standard ins Nicht EU Ausland verändert hat hier ist zwingend die Adresse erforderlich und zwar nicht an der Stelle wo man das erwarten würde beim Namen des Kunden , sondern hier wurden 2 neue Felder eingefügt, die im alten Standard gar nicht vorhanden sind.

Offensichtlich setzt das dann DATev Zahlungsverkehr für Lastschriften ins nicht EU Ausland niemand ein ?

Schöne Grüße aus dem Grenzgebiet.