DATEV-XML-Schnittstelle - x-Zeichen werden in den PDF- und XML-Dateinamen durch Leerzeichen ersetzt

[#1]

Wir als Softwarehersteller haben immer wieder erneut Probleme mit der Übertragung von Daten an DATEV.

Aktuell wird bei der Übertragung über den Belegtransfer nicht mehr ein +-Zeichen in den PDF- und XML-Dateien übertragen. Diese werden (warum auch immer) durch ein Leerzeichen bei der Übertragung ersetzt. Anschließend wird die Übernahme von DATEV nicht akzeptiert, da die in der document.xml referenzierten Dateien mit "+" nicht existieren.

Ein Beispiel:

Nach der Übertragung wird in DATEV aus Rechnung_12345+4545.pdf und Rechnung_12345+4545.xml eine Rechnung_12345 4545.pdf und Rechnung_12345 4545.xml.

In der document.xml wird aber auf datafile=Rechnung_12345+4545.xml und name=Rechnung_12345+4545.pdf referenziert.

Wir erhalten aktuell täglich Anrufe unserer Kunden, die bei der Übertragung entsprechende Fehlermeldung erhalten.

Das stellt uns erneut vor Problemen. Wir mussten zeitintensiv den Fehler eruieren und konnten diesen nur mit großem Aufwand für unsere Kunden übergangsweise lösen.

Wir haben leider regelmäßig derartig ärgerliche Probleme, die letztendlich alleinig durch DATEV zu verantworten waren/sind.

Wir fragen uns daher mittlerweile, ob DATEV technisch gegenüber Dritten souverän eine zuverlässige und fehlerfreie Schnittstelle anbieten kann.

Uns entsteht wiederholt ein enormer Supportaufwand, den wir selbst kaum noch leisten können und wir auch gegenüber unseren Kunden nicht rechtfertigend verrechnen können.

Was uns als Softwarehersteller künftig helfen würde:
Ein unbürokratisch direkter Kontakt zu DATEV ohne Kosten, um schnell Probleme ansprechen zu können und gemeinsam zu lösen.

PS: Wenn ich alleinig die mir bekannten Probleme bei einem von DATEV definierten Austausch von einfachen buchhaltungsrelevanten Daten sehe, dann stehe ich dem Projekt "Austausch und Meldepflicht durch E-Rechnungen über eine Plattform durch DATEV" kritisch gegenüber.

[#2]

Dann seid Ihr auf dem Marktplatz gelistet und Du schreibst in der Rolle eines Marktplatz Partners? Wenn ja, kann @Bernd_Meyer ggf. helfen?

Zwar soll das + zulässig sein. Ein _ ist es aber schon wieder nicht: Ascii-Import mit ungültigen Zeichen Da muss dann also TooGoodToGo an sein Rechnungsprogramm und aus dem _ ein anderes Zeichen machen, damit es für DATEV passt? 

[#3]

Hallo metalposaunist,

vielen Dank für Ihre Antwort.

Wir sind aktuell nicht auf dem Marktplatz gelistet. Wir haben ehemals die Schnittstellendokumentation von DATV erworben.

Tatsächlich geht es hier nicht um die ASCII-Schnittstelle von DATEV,  sondern um den Belegtransfer per Zip-Datei. Diese enthält eine referenzierte document.xml, sowie die Belegbilder als PDF-Dateien und die Buchungssätze als XML-Dateien.

Seit ein paar Tagen werden die Dateibezeichnungen der Belegbilder und der Buchungssätze bei dem Belegtransfer in DATEV verändert übernommen, sofern diese ein + Zeichen enthalten (eventuell auch noch bei anderen Zeichen).

Somit können auch die in der document.xml angegebenen Dateien von DATEV nicht zugeordnet werden.

In unserem Fall setzen sich die Dateibezeichnungen der Belegbilder und der Buchungssätze aus der Rechnungsnummer und Debitoren-/Kreditoren-Nummer zusammen.

Dies ermöglicht uns eine bessere Zuordnung/Recherche, wenn ein Buchungssatz fehlerhaft von DATEV beim Import gekennzeichnet wird.

Eine Firma unseren Kunden verwendet bei der Rechnungsnummer ein Plus-Zeichen.

Bis vor wenigen Tagen wurden alle Dateien (*.pdf und zugehörige *.xml) im Dateinamen unverändert übernommen. Nun wird ein Plus-Zeichen durch ein Leerzeichen ersetzt.

Viele Grüße ...

[#4]

Tatsächlich keine Reaktion von DATEV betreffend meinem Anliegen?
Also kein Dialog um angesprochene Probleme gemeinsam in einen bereitgestellten Forum lösen zu können?

[#5 · Accepted solution]

Guten Morgen @DeJa 

bitte entschuldigen Sie die späte Rückmeldung - es hat etwas gedauert, den Sachverhalt nachzustellen. Ihre gute Fehlerbeschreibung hat uns dabei geholfen, vielen Dank dafür 

Wir haben die Ursache gefunden: Durch eine Änderung im Url-Decodierung wird aus jedem "+" ein Leerzeichen erzeugt. Vorher war das ein gültiges Zeichen und wurde nicht durch ein Leerzeichen ersetzt.

Abhilfe: Wir werden das mit einer Programmübergabe voraussichtlich am 11.07.2024 so umstellen, dass bei einem "+" im Dateinamen kein URl-Decodierung mehr erfolgt.

[#6]

Hallo Frau Döbereiner,

vielen Dank für Ihre Rückmeldung, die Fehleranalyse und den schnellen Ausblick auf die Behebung der Problematik.

Ich möchte mich zudem für meinen kritischen Unterton bei Ihnen entschuldigen. Das war unangemessen und in der Sache auch völlig überflüssig.

Viele Grüße

Detlef Jäger 

[#7]

Der gleiche Fehler scheint aktuell auch bei Dateibezeichnungen mit einem Komma (",") aufzutreten.

Ist hier auch kurzfristige Abhilfe zu erwarten?

[#8]

Hallo @DenSeu , 

ich habe es weitergegeben und melde mich, sobald ich mehr weiß. 

Guten Wochenstart!🙂

[#9]

Hallo @DenSeu, 

folgende Zeichen sind zulässig:

Space &()+-._ 0-9A-Za-zÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõöøùúûüýþÿ

Alle anderen Zeichen werden automatisch durch einen Unterstich ersetzt.

Macht das Programm bei Ihnen aus dem Komma einen Unterstrich, so ist das richtig.

Als Abhilfe könnten Sie die Kommata im Filenamen durch ein zulässiges Zeichen ersetzen.

Sollte das Programmverhalten jedoch in Verbindung mit Zahlen falsch umgesetzt sein, würde ich Sie bitten, sich mit Ihrem Schnittstellenpartner in Verbindung zu setzen und uns die genauen Bezeichnungen der Daten und Informationen zukommen zu lassen.