Hallo,
ich (Unternehmer) nutze DUO und nutze fertige (selbsterstellte und gut funktionierende) Stapeldateien im DATEV-Format (EXTF), die ich ins DUO hochlade, damit mein StB Sie herunterlädt, bei sich abspeichert und in REWE einspielt. Jetzt habe ich (Programmierer) die REST API vom DATEV Buchungsdatenservice (https://www.datev.de/web/de/datev-shop/91000-buchungsdatenservice/) mit accounting:extf-files entdeckt.
Ist es richtig, dass ich die API selbst aber nicht nutzen kann, weil ich kein DATEV-Partner bin? Falls ja, kennt jemand DATEV-Partner die mir nur den Zugang zur API Buchungsdatenservice geben können? Stimmt das diese API deprecated ist? Welche Schnittstelle ersetzt diese API später?
Vielen Dank!
Jan
@hatterja schrieb:
Ist es richtig, dass ich die API selbst aber nicht nutzen kann, weil ich kein DATEV-Partner bin?
Ja, man kann aber DATEV Partner werden. Ist aber nicht mit 2 Klicks getan. Das ist etwas bürokratischer gestaltet: Dokumente per API hochladen, eigene ID vergeben Das hatte @madduck auch so ähnlich wie Du vor.
@hatterja schrieb:
Falls ja, kennt jemand DATEV-Partner die mir nur den Zugang zur API Buchungsdatenservice geben können?
Bin mir unsicher, ob das vertraglich erlaubt ist.
Das DATEV Developer Portal ist Dir sicher bekannt?
Danke. Ja, das DATEV Developer Portal hab ich bereits gefunden. DATEV Partner zu werden ist scheinbar auch eine Kostenfrage. Irgendwo hab ich von einem vierstelligen Onboarding Betrag gelesen, wenn das auch für diese API gilt. Das steht dann nicht mehr im Verhältnis. Den bürokratischen Aufwand würd ich vielleicht noch stemmen wollen/können.
Danke für den Link zu @madduck. Ich lese mir das mal durch...
Ist einfach lachhaft, wie DATEV in 2024 die Welt sieht. Wir schauen uns längst Odoo an und werden vermutlich wechseln. Keinen Euro mehr als notwendig an innovationsresistente Dinosaurier...
@hatterja schrieb:
wenn das auch für diese API gilt.
Ja, gilt es.
Servus
Tatsächlich geht es ohne das kostenpflichtige Onbarding gar nicht erst los. Die Postman und Bruno Collections sind nicht öffentlich und noch dazu fehlerhaft bzw. überholt.
EDIT: @hatterja : für die accounting:extf-files gibt es einen direkten Nachfolger. Im wesentlichen ändern sich die Routen auf v3 von v2. Für die korrekte Funktion sind noch 3 weitere APIs notwendig.
Trotzdem entwickle ich gerade eine Schnittstelle in C#/.net die Rechnungen und Bewegungsdaten, sowie Stammdaten vom Desktop (Server) per API übermittelt. Nach der Freigabe mit UI die auch zur Authentifizierung vorgeschrieben ist soll das per Konsolenanwendung automatisch laufen.
Soweit so gut - trotz leider fehlerhaften Vorgaben und unzureichenden Informationen bin nun fast durch die Sandbox-Anforderungen durch, es fehlt noch der letzte Teil: Validierung der hochgeladenen CSV-Dateien.
Trotz dessen das ich die aktuellen Demodateien vom 27.3.24 übertrage erhalte ich immer die Meldung:
Invalid EXTF-Header
"DATEV Format Label","reason":"must be 'EXTF' (1)"
Das ist wie ein Puzzle bei dem andauernd ein Teil fehlt. Ob ein weiteres Support-Ticket das Problem beheben kann wird sich herausstellen.
Die Übertragung wird mit RestSharp durchgeführt, POST, "Content-Type", "application/octet-stream".
Selbstverständlich steht das Label in Anführungszeichen und korrekt geschrieben in Zeile eins im ersten Feld, so wie auch in den Demodaten. Diverse Zeichenformate habe ich auch schon getestet.
Hat jemand evtl. einen Tipp für mich?
Neuigkeiten trage ich hier im Verlauf ein.
Vielen Dank!
Dino
Danke für die Infos. Das mit dem deprecated hatte ich im Nachgang auch entdeckt. Es galt nur für v2 weil es nun v3 gibt.
Was deinen "Invalid EXTF-Header" angeht. Ich lasse schon sehr lange die DATEV-Format Dateien manuell von meinem StB direkt als File in DATEV Kanzlei-Rechnungswesen importieren. Meine Dateien beginnen oben immer mit diesen beiden Zeilen
"EXTF";700;21;"Buchungsstapel";9;20240221083912000;;"SV";"JH";"";12345;54321;20240101;4;20240101;20240131;"Buchungen";;;;0;"";"";"";"";"";"";;;"";""
und in Zeile 2 dann
"Umsatz (ohne Soll/Haben-Kz)";"Soll/Haben-Kennzeichen";"WKZ Umsatz";"Kurs";"Basis-Umsatz";"WKZ Basis-Umsatz";"Konto";"Gegenkonto (ohne BU-Schlüssel)";"BU-Schlüssel";"Belegdatum";"Belegfeld 1";"Belegfeld 2";"Skonto";"Buchungstext";"Postensperre";"Diverse Adressnummer";"Geschäftspartnerbank";"Sachverhalt";"Zinssperre";"Beleglink";"Beleginfo - Art 1";"Beleginfo - Inhalt 1";"Beleginfo - Art 2";"Beleginfo - Inhalt 2";"Beleginfo - Art 3";"Beleginfo - Inhalt 3";"Beleginfo - Art 4";"Beleginfo - Inhalt 4";"Beleginfo - Art 5";"Beleginfo - Inhalt 5";"Beleginfo - Art 6";"Beleginfo - Inhalt 6";"Beleginfo - Art 7";"Beleginfo - Inhalt 7";"Beleginfo - Art 8";"Beleginfo - Inhalt 8";"KOST1 - Kostenstelle";"KOST2 - Kostenstelle";"Kost-Menge";"EU-Land u. UStID";"EU-Steuersatz";"Abw. Versteuerungsart";"Sachverhalt L+L";"Funktionsergänzung L+L";"BU 49 Hauptfunktionstyp";"BU 49 Hauptfunktionsnummer";"BU 49 Funktionsergänzung";"Zusatzinformation - Art 1";"Zusatzinformation- Inhalt 1";"Zusatzinformation - Art 2";"Zusatzinformation- Inhalt 2";"Zusatzinformation - Art 3";"Zusatzinformation- Inhalt 3";"Zusatzinformation - Art 4";"Zusatzinformation- Inhalt 4";"Zusatzinformation - Art 5";"Zusatzinformation- Inhalt 5";"Zusatzinformation - Art 6";"Zusatzinformation- Inhalt 6";"Zusatzinformation - Art 7";"Zusatzinformation- Inhalt 7";"Zusatzinformation - Art 8";"Zusatzinformation- Inhalt 8";"Zusatzinformation - Art 9";"Zusatzinformation- Inhalt 9";"Zusatzinformation - Art 10";"Zusatzinformation- Inhalt 10";"Zusatzinformation - Art 11";"Zusatzinformation- Inhalt 11";"Zusatzinformation - Art 12";"Zusatzinformation- Inhalt 12";"Zusatzinformation - Art 13";"Zusatzinformation- Inhalt 13";"Zusatzinformation - Art 14";"Zusatzinformation- Inhalt 14";"Zusatzinformation - Art 15";"Zusatzinformation- Inhalt 15";"Zusatzinformation - Art 16";"Zusatzinformation- Inhalt 16";"Zusatzinformation - Art 17";"Zusatzinformation- Inhalt 17";"Zusatzinformation - Art 18";"Zusatzinformation- Inhalt 18";"Zusatzinformation - Art 19";"Zusatzinformation- Inhalt 19";"Zusatzinformation - Art 20";"Zusatzinformation- Inhalt 20";"Stück";"Gewicht";"Zahlweise";"Forderungsart";"Veranlagungsjahr";"Zugeordnete Fälligkeit";"Skontotyp";"Auftragsnummer";"Buchungstyp";"USt-Schlüssel (Anzahlungen)";"EU-Land (Anzahlungen)";"Sachverhalt L+L (Anzahlungen)";"EU-Steuersatz (Anzahlungen)";"Erlöskonto (Anzahlungen)";"Herkunft-Kz";"Buchungs GUID";"KOST-Datum";"SEPA-Mandatsreferenz";"Skontosperre";"Gesellschaftername";"Beteiligtennummer";"Identifikationsnummer";"Zeichnernummer";"Postensperre bis";"Bezeichnung SoBil-Sachverhalt";"Kennzeichen SoBil-Buchung";"Festschreibung";"Leistungsdatum";"Datum Zuord. Steuerperiode";"Fälligkeit";"Generalumkehr (GU)";"Steuersatz";"Land"
statt 12345 in Zeile 1 muss deine Berater-Nr. rein und statt 54321 deine Mandaten Nr.
Es gibt auch ein Windows Tool zum Validieren von der DATEV, aber das kennst du wahrscheinlich schon, oder?
Viele Grüße
Jan
@Dino_G schrieb:
Invalid EXTF-Header
"DATEV Format Label","reason":"must be 'EXTF' (1)"
Der Dateiname der CSV stimmt auch? Der muss mit EXTF beginnen, damit DATEV Rechnungswesen die CSV auch einspielt. EXTF in der CSV als "Dateityp" reicht hier nicht aus. Also DATEV.csv geht nicht aber EXTF_DATEV.csv sollte (in etwa) gehen. Ggf. sich an einen DATEV EXTF klemmen und das Schema übernehmen.
Danke, ebenso.
Das Tool kannte ich noch nicht. Läßt sich nicht installiern (W10x64) - Setup geht einfach zu.
Das die CSV-Daten manuell eingelesen werden können wurde mir auch schon mehrfach bestätigt.
Der Umweg über den Mail-Assistenten (Hatte ich in einem anderen Thread gelesen) scheint nicht mehr zu funktionieren wie ein Kollege berichtet und ist auch nicht meine Wunschumsetzung.
Ich habe deine Zeilen mit Notepad++ und einer Buchungszeile von uns verschmolzen. Die Berater- und Mandantennummer sind in der Sandbox vorgegeben und auch eingesetzt.
Voller Hoffnung leider mit dem selben Ergebnis.
// raw content as string
jobStatus_response.Content:
{"id":"cb21c41c-06de-4116-8818-98eea8c12345x","filename":"EXTF_Buchungen_WA_2024022915542199.csv","client_application_display_name":"APPNAME","client_application_vendor":"UNKAPUTTBAR","result":"failed","timestamp":"2024-04-09T15:35:47.967897Z","validation_details":{"type":"http://www.datev.de/lexinform-infodb/1008834","title":"Invalid EXTF-header","detail":"Error in header field","affected_elements":[{"name":"DATEV Format Label","reason":"must be 'EXTF' (1)"}]}}
Vorgabe passt:
https://developer.datev.de/datev/platform/de/dtvf/formate/header
Spannenderweise ist dieser Fehler auch bei den Definitions gelistet, obwohl er nicht der Erste in der Reihe der 1008834er ist:
Header-Fehler(runterscrollen):
Definitions:
Mir gehen die Ideen aus.
Ich bin gespannt was mir dazu jemand vom Support mit Blick auf die Logs und die tatsächlich eingegangenen Files sagen kann.
Danke auch dir Daniel für die schnelle Rückmeldung!
Der Dateiname ist:
EXTF_Buchungsstapel_WA_20240409150001.csv
Schemata habe ich auch schon komplett übernommen - auch das von Jan.
Habe die neuen Demodaten auch alle durch. Da das Problem meistens vorm Bildschirm sitzt kommen mir schon leichte Zweifel. Kodierung der CSV UTF-8 ohne BOM.
VG
Dino
Nein, die DATEV möchte Windows-1252 mit Zeilenumbrüchen als CRLF (Windows, carriage return line feed)
Viele Grüße
Jan
@metalposaunist schrieb:Das DATEV Developer Portal ist Dir sicher bekannt?
Hat das Developer Portal tatsächlich keine Suchfunktion?
... die müsste man vielleicht erst 'developpen' 😎
... und wenn man die Antwort schon kennt, fällt das Suchen meist leichter 😎
ontopic
Bin gespannt, was @Dino_G als Fehlerursache nennt. Der manuelle Import soll funktionieren und utf-8 ist in der API-Reference angegeben. Verstehe jedoch nicht, was dort "Accept optional" bedeutet.
@vogtsburger schrieb:
... die müsste man vielleicht erst 'developpen' 😎
... und wenn man die Antwort schon kennt, fällt das Suchen meist leichter 😎
Falsche(r) Browser / Addons ggf. mit zu hohen Sicherheitseinstellungen, falsches Portal, Bezahlschranke, Gebetsteppich nicht genau Richtung Nürnberg ausgerichtet… Zumindest haben Sie mir nicht vorgeschlagen, die Suchfunktion zu benutzen, die entweder dysfunktional oder schlichtweg nicht vorhanden ist.😉
Dort wo man keine Ahnung hat, was der Anwender braucht, steigt man ihm hinterher (Forum, Suchanfragen, Programmstatistik...) und dort wo man es weiß, kassiert man ab. Zumindest an dieser Stelle ist ein durchgehendes Konzept erkennbar.🌥️
Den Nürnberger finde ich am besten 🙂
Montag gibt es eine korrigierte Bruno Collection über den 'Deeplink' - den habe ich bisher nicht gefunden. Die bisherige Collection habe ich von einem netten Berater.
Morgen erhoffe ich mir die Lösung zu erfahren.
Unter Umständen 1 Woche Lebenszeit zu verschenken:
Problem:
Übertragung der Bewegungsdaten per EXTF_Buchungsstapel.csv und anschließende Abfrage des Job-Status mit folgender Fehlermeldung in Kurzform:
Invalid EXTF-Header
"DATEV Format Label","reason":"must be 'EXTF' (1)"
An der Datei oder der Headerzeile hat es nicht(!) gelegen, sondern an der Art der Übermittlung.
Habe es immer mit addFile probiert, aber die Datei muss als ByteArray im Body übergeben werden. Klingt einfach, bin aber nicht ohne Anschubser darauf gekommen. Das besagte Problem das vorm Bildschirm sitzt.
Lösung:
// Body
filePath = documentFile.path + @"\" + documentFile.filename;
byte[] bytes = System.IO.File.ReadAllBytes(filePath);
request.AddParameter("application/octet-stream", bytes, ParameterType.RequestBody);
// Request insgesamt:
url = "https://accounting-extf-files.api.datev.de/"
+ gateway_url + "/v3/clients/" + datev_client_id
+ "/extf-files/import";
// AUTH
options = new RestClientOptions(url)
{
MaxTimeout = -1,
Authenticator = new OAuth2AuthorizationRequestHeaderAuthenticator(
code, // AccessCode
"Bearer"),
};
client = new RestClient(options);
request = new RestRequest(url, Method.Post);
// Body
filePath = documentFile.path + @"\" + documentFile.filename;
byte[] bytes = System.IO.File.ReadAllBytes(filePath);
request.AddParameter("application/octet-stream", bytes, ParameterType.RequestBody);
// Header
request.AddHeader("X-DATEV-Client-Id", X_DATEV_Client_Id);
request.AddHeader("Filename", documentFile.filename);
request.AddHeader("Content-Type", "application/octet-stream");
// Im Anschluss gibt der JobStatus dann endlich das ersehnte 'succeeded' zurück
url = "https://accounting-extf-files.api.datev.de/" + gateway_url + "/v3" + jobId_url;
request = new RestRequest(url, Method.Get);
request.AddHeader("X-DATEV-Client-Id", X_DATEV_Client_Id);
request.RequestFormat = DataFormat.Json;
RestResponse jobStatus_response = client.Execute(request);
Puuh. Endlich.
Bis zum nächsten Puzzleteil.
VG
Dino
Super. Danke für das Posten deiner Lösung! Das behalte ich für den Hinterkopf, wenn die API integriere weil die DATEV im Jahr 2030 auf Druck der Unternehmer auf die Onboarding-Gebühr verzichtet und die API für jeden zugänglich macht. 🙂
Viele Grüße
Jan
Hier nochmal ein Link zu einem nützlichen Tool das die DATEV-Formate strukturell prüft und das Jan vermutlich meinte, ich habe es aber zuvor nicht gefunden. Vor dem Senden von Daten sollte hier schon alles sauber sein 😉
Prüfprogramm | DATEV Developer Portal
https://developer.datev.de/datev/platform/de/dtvf/tools
VG
Dino
Hallo Dino und alle,
mit Interesse lese ich diesen Beitrag.
Wir bauen auch gerade die Schnittstelle zum Buchungsdatenservice.
Stimmt leider, was Du über die fehlerhafte Doku schreibst, das hier ist m.E. auch falsch, haste schon gefunden? :-):
https://developer.datev.de/datev/platform/de/node/33197
Korrekt wäre ohne das /import/
GET https://accounting-extf-files.api.datev.de/platform-sandbox/v3/clients/{client-id}/extf-files/jobs/{jobid}
Den so ist es im location header des vorherigen request UND in der doku. Da kann man schon mal Lebenszeit sinnvoll investieren.
Dein Post ist jetzt 2 Wochen her, seid Ihr schon im Produktivtest?
Wir noch nicht. Wir bauen allerdings auch parallel gleich den Rechnungsdatenservice und da haben wir Produktiv-Test-Freigabe. Wir warten darauf, dass unsere Kunden auch eine Testumgebung haben, denn das fordert die Datev auch. Also um mich korrekt auszudrücken: Test des Produktivsystems mit Kunden aber nicht produktiv aufgrund Datenschutz...OMG
Da wir schon diverse Schnittstellen zu anderen REST APIs gebaut haben, kann ich Dir bestätigen, dass auch hier im Unternehmen große Augen zum Thema Kosten und Ablauf gemacht werden. Immerhin sind die Termine bei denen man gemeinsam den Code anschaut (Naja letztendlich ist es nicht der Code sondern nur die Calls bzw das logging!) sehr konstruktiv, da war ich wirklich positiv überrascht und beeindruckt. Leider muss man da immer eine Stunde buchen. Da muss man dann Fragen zusammen kommen lassen. Schwierig zu organisieren...
Nichtsdestotrotz habe ich den Eindruck, dass man bei DATEV das nichtvorhandensein von einer passenden technischen Infrastruktur und entsprechender professioneller Dokumentation (tut mir echt leid aber es ist so, incl Schreibfehler) für sich in den Vorteil umdreht, hier noch Umsatz zu generieren. Wenn man das alles dokumentieren würde UND entsprechende Testsysteme hätte, dann bräuchte es diesen Ablauf nicht.
Ich nenne mal als Beispiel die API von Stripe, die wir auch angeschlossen habe. https://docs.stripe.com/api alles perfekt dokumentiert, first level support per chat, dann per email. Alles kostenlos. So wäre es schön. Das hat richtig Spaß gemacht.
Über die Funktionalität der Sandbox kann man streiten und staunen, es ist tatsächlich ja eher ein Mock. Rückgabewerte sind immer gleich, egal was man rein schickt.
Viele Grüße
Reisekostenrechner
@Reisekostenrechner schrieb:
Nichtsdestotrotz habe ich den Eindruck, dass man bei DATEV das nichtvorhandensein von einer passenden technischen Infrastruktur und entsprechender professioneller Dokumentation (tut mir echt leid aber es ist so, incl Schreibfehler) für sich in den Vorteil umdreht, hier noch Umsatz zu generieren. Wenn man das alles dokumentieren würde UND entsprechende Testsysteme hätte, dann bräuchte es diesen Ablauf nicht.
Genau das. Der Dinosaurier hat den Anschluss verpasst und versucht nun krampfhaft noch zu melken, so lange es was zu melken gibt. Längst Zeit, sich nach Alternativen umzuschauen.
Servus @Reisekostenrechner ,
die Fallstricke der DOKU haben wir mühsam abgearbeitet und wir sind (endlich) im Produktivtest und stehen kurz vor der Vollendung.
APIs haben wir auch schon mehrere umgesetzt - von daher kann ich deine Argumentation nachvollziehen. Die Hürden sind hier besonders hoch.
In unserem Fall arbeiten wir direkt mit dem Steuerbüro zusammen, so das der Produktiv-Testfall sehr unkompliziert geregelt ist. Die Dokumente landen in einem klar abgegrenzten Ordner, die CSV-Dateien und Dokumentinhalte sind mit Phantasiedaten gefüllt und unübersehbar gekennzeichnet.
Immer weiter rudern..
Viele Güße
Dino
Hallo @Dino_G ,
habe ich Dich korrekt verstanden, Ihr nutzt einen produktiven Mandanten, aber setzt dem Folder im Metadata Tag auf einen extra Folder?
Wenn das Datev seitig "erlaubt" ist, wäre das für uns auch eine gute Lösung.
Viele Grüße
Reisekostenrechner
Hallo @Reisekostenrechner ,
Die API legt serverseitig automatisch einen Ordner mit dem Namen der Anwendung an.
Der Wert wird mit <metadata.category> übergeben.
<metadata.folder> spielt hier eigentümlicherweise kein Rolle.
Vielleicht kannst Du mir bei einem Problem helfen: In Datev-Online wird das Feld Dokument-Typ nicht ausgefüllt bei den übertragenen Dokumenten.
Im Prüftermin wurde mir deutlich gesagt das metadata.document_type und metadata.note nicht nur leer sein sollen (wie in der DOKU angegeben), sondern gar nicht erst mit übergeben.
"Wenn das Datev seitig "erlaubt" ist, wäre das für uns auch eine gute Lösung."
Unser SB hat sich das explizit gewünscht, da für Ihn der Aufwand die Testdaten zu löschen einfacher ist als einen weiteren Mandanten zu verwalten.
VG
Dino
Hallo @Dino_G
hier steht das auch, dass man das Feld nicht übergeben darf:
https://developer.datev.de/datev/platform/de/node/33197
"Für jedes Dokument ist zusätzlich zwingend ein Metadaten-Objekt (JSON) Namens "metadata" zu übermitteln. Metadata enthält insgesamt fünf Datenfelder von denen die ersten beiden (document_type, note) nicht verwendet werden sollen. Die letzen drei Datenfelder (category, folder, register) sollen den Ablageort des Dokumentes angeben. category soll einen Verweis auf die 3rd-Party App darstellen, folder die Art der Dokumente und register den Kalendermonat und -jahr des Dokumentes, also z.B. (SuperERP, Belege, 2023-05)"
"If the value of the document_type is empty, then the parameter will be ignored and will not be returned in the response. In this case, and if the parameter document_type is not used, the term “ohne Belegtyp” (without document type) is displayed in the DATEV applications."
nun, aber Doku lesen kannst Du selbst. Wir sind noch nicht beim Test im Produktivsystem und deshalb kann ich Dir leider nicht sagen wie wir es machen, aktuell übergeben wir nur die 3 gewünschten Parameter category, folder, register.
"Unser SB hat sich das explizit gewünscht, da für Ihn der Aufwand die Testdaten zu löschen einfacher ist als einen weiteren Mandanten zu verwalten."
-> gut zu wissen, dass das so von DATEV akzeptiert wurde, für uns wie gesagt auch eine Option.
Viele Grüße
Reisekostenrechner
Hallo Dino,
ich habe auch eine Frage: wenn ihr eine Buchung ohne Beleg habt, lasst ihr dann die GUID im EXTF einfach weg oder übergebt Ihr ein Dummy Bild?
Viele Grüße
Reisekostenrechner
Hallo @Reisekostenrechner
..document_type..
mir geht es auch nicht um das 'return value', sondern darum das der Belegtyp in Unternehmen Online nicht ausgefüllt wird. Wir haben die Übertragung gerade auch mal mit den unerwünschten Feldern getestet mit gleichem Ergebnis.
Hallo @Reisekostenrechner ,
möchtest Du die Frage eventuell zurückziehen? 😉
Wenn es keinen Beleg gibt, dann ist das Feld leer.
Viele Grüße
Dino
Hallo Dino,
die Frage wurde im Rahmen der Formatprüfung geklärt. Das Feld darf leer sein.
Auf die andere Frage werde ich gerne antworten, wenn wir an dem Punkt angekommen sind.
Viele Grüße
Reisekostenrechner
Hallo Dino,
wir haben am Donnerstag unseren Produktiv Freigabe Termin für den Buchungsdatenservice. Ich gehe gerade noch einmal alle Punkte durch, um zu prüfen, ob ich etwas vergessen habe, da fällt mir eine Änderung in dem Dokument auf:
https://developer.datev.de/datev/platform/de/node/33197
Ich hatte dieses Dokument in diesem Thread hier zitiert, siehe oben (ansonsten hätte ich nämlich gedacht, dass ich mich da in der Vergangenheit geirrt habe bzw. nicht aufmerksam war). Ich war es aber! Datev hat das Dokument einfach geändert, ohne den Changelog anzupassen.
Vorher stand da:
"Für jedes Dokument ist zusätzlich zwingend ein Metadaten-Objekt (JSON) Namens "metadata" zu übermitteln. Metadata enthält insgesamt fünf Datenfelder von denen die ersten beiden (document_type, note) nicht verwendet werden sollen. Die letzen drei Datenfelder (category, folder, register) sollen den Ablageort des Dokumentes angeben. category soll einen Verweis auf die 3rd-Party App darstellen, folder die Art der Dokumente und register den Kalendermonat und -jahr des Dokumentes, also z.B. (SuperERP, Belege, 2023-05)"
Jetzt steht da:
"Für jedes Dokument ist zusätzlich zwingend ein Metadaten-Objekt (JSON) Namens "metadata" zu übermitteln. Das Objekt enthält insgesamt fünf Parameter:
Viele Grüße
Reisekostenrechner
Hallo @Reisekostenrechner ,
vielen Dank für die Rückmeldung, alles andere entbehrt auch jeder Logik. (Im Termin zur Produktiv-Freigabe wurde ich deshalb noch gerügt, da ich alle Felder übergeben, aber die besagten Werte dann leer gelassen habe.)
Leider hilft das nicht weiter in meinem Fall.
Ich bin gerade nochmal mit unserem Steuerberater einen Upload durchgegangen, bevor ich am Donnerstag das bestehende Problem erneut in einem Support-Termin zu erörtern versuche;
Die CSV-Dateien tauchen nicht in Unternehmen-Online auf, obwohl die Prüfung seitens DATEV korrekt war.
Die Dokumente sind alle sichtbar.
Der Belegtyp wird auch mit allen gefüllten META-Objekten NICHT angezeigt.
Bei einer manuellen Übermittlung derselben Dateien mittels Belegtransfer ist alles sichtbar.
Hoffe, wir finden da gemeinsam eine Lösung.
Viele Grüße
Dino