Doppelpost ;-(
Hallo@Reisekostenrechner ,
der Fall hat sich nun endlich aufgeklärt.
In metadata.document_type darf nur einer der in DATEV-Online freigegebenen Dokumenttypen verwendet werden:
https://apps.datev.de/help-center/documents/1071401
Die CSV wird nur dann per API korrekt verarbeitet, wenn im Dateinamen ausschließlich EXTF_ gefolgt von numerischen Zeichen enthalten ist:
Bsp.: EXTF_20240502113227.csv
Viele Grüße
Dino
Hallo Dino,
vielen Dank für Deine wertvollen Hinweise. Ich melde mich nach unserer Prüfung morgen mit weiteren Erkenntnissen.
Viele Grüße
Reisekostenrechner
Hallo Dino,
jetzt haben wir auch für den Buchungsdatenservice die Freigabe für Produktiv Test.💪
Meine Frage ob das stimmt bezüglich des Dateinamens mit den Ziffern
"Die CSV wird nur dann per API korrekt verarbeitet, wenn im Dateinamen ausschließlich EXTF_ gefolgt von numerischen Zeichen enthalten ist:
Bsp.: EXTF_20240502113227.csv"
wurde verneint.
Viele Grüße
Reisekostenrechner
Hallo Reisekostenrechner,
wenn es bei dir auch anders gelingt, dann liegt das Problem an anderer Stelle.
Ich bin jetzt jedenfalls durch und gehe die endgültige Freischaltung an.
Viele Grüße
Dino
Hallo Reisekostenrechner
Nochmal ein Update.
Die Metadatenfelder document_type und note sollen im Buchungsdatenservice definitiv nicht übergeben werden, auch nicht leer.
Der heutige Support und Freigabetermin hat ergeben das die geänderte Schnittstellenbeschreibung für unser Vorhaben nicht zielführend ist.
Ich gebe das nur so weiter, ohne das ich es voll verstanden habe aus welchem Grund.
Schlußendlich konnten alle Daten in die Buchung übernommen werden.
VG
Dino
Hallo Dino,
wir übergeben diese Felder auch nicht. Wurde auch im Termin heute gesagt, dass die Doku so nicht sein sollte und man mit dem Kollegen sprechen würde.
➡️Vielen Dank für den netten Austausch diesbezüglich hier und toi toi toi für die Freigabe.
Vielleicht können wir uns noch über einen weiteren Punkt hier austauschen:
wie setzt ihr Euren Buchungsstapel zusammen und wie geht ihr damit um, wenn es einen Fehler gibt?
Erklärung:
Gestern im Freigabetermin hat sich als Feedback seitens des Beraters herausgestellt, dass so wie wir aktuell den Buchungsstapel aufbauen nach Meinung des Beraters wahrscheinlich zu Unzufriedenheit führen wird. Wir erstellen nämlich für jede Reise (Reise hat N Buchungen aber eben nur für diese Reise) und auch für jeden einzelnen Beleg (evtl mehrere Buchungen wg. Mehrwertsteuer oder Bewirtung oder Hotel) einen Buchungsstapel. Der Berater sagt, das entspricht nicht der Arbeitsweise in den Kanzleien.
Jetzt wollen wir mehrere Optionen anbieten, aus denen der Kunde dann wählen kann:
Schön, das können wir machen. Dann hat man z.b. für 20 Reisen nur einen Buchungsstapel.
Aber wenn dann ein Fehler z.B. bei einem der Belegbilder auftritt, wird in unserer Anwendung dann der Status (Workflow) der Reise nicht umgesetzt und ein Fehler angezeigt. Es wären denn 19 Reisen als "exportiert" gekennzeichnet und bei der einen müsste man etwas korrigieren und erneut übertragen. Deshalb ist unser Gedanke, dass wir dann auch den Buchungsstapel erst generieren können, wenn wir wissen, welche Belegbilder korrekt übertragen wurden. In den Buchungsstapel würden dann nur die Buchungen von den ok Reisen aufgenommen.
Wie ist da bei Euch der Use Case? Das würde mich interessieren.
Generell interessiert mich auch die Meinung von anderen die mitlesen und es bis hierher geschafft haben 😀,
Viele Grüße
Reisekostenrechner
Hallo Reisekostenrechner,
wir übergeben jede Rechnung direkt nach Erzeugung im ERP.
Unseren Kunden ist die zeitnahe Rechnungslegung sehr wichtig.
Dazu wird je eine Zeile in der SQL-DB mit dem Namen (incl. Zeitstempel) der CSV angelegt, womit sicher gestellt ist das die Aufträge sequenziell verarbeitet werden.
Die Verbuchung hingegen findet in der Steuerkanzlei statt. Die Zeiträume bestimmen sie dabei selbst. Vorteil der API-Lösung ist hier das immer alle bis zu dem Zeitpunkt gestellten Belege ohne Interaktion oder Rückfrage vorhanden sind.
Der Übertragungsstatus sollte sich durch den Prozess selbst ergeben, da im Fehlerfall entweder keine JOBId (CSV) oder keine GUID (Document) zurück kommen, bzw. der Status nicht 'successed' lautet.
Wir setzen für den ersten Fall je Datei ein FLAG 'processed=1', wenn alles glatt gelaufen ist.
Dateien mit 'processed=0' werden dann im nächsten Durchlauf verarbeitet oder ein Fehler wird gemeldet.
Die CSV übertragen wir grundsätzlich erst nachdem die Dokumente übermittelt wurden.
Da wir eine Konsolenanwendung/Dienst anstreben, werden Fehler an den zuständigen Mailverteiler zwecks manueller Prüfung übermittelt.
Die Zuordnung Stapel zur Datei kann meiner Kenntnis nach über die API gar nicht geprüft werden, sondern ist erst in Kanzlei Rechnungswesen festzustellen.
Sollte eine Rückmeldung zu einem fehlenden/defekten Beleg kommen, so kann die Datei (mit neuer GUID(!)) erneut übertragen werden.
Um das abschließend nochmal zusammen zu fassen: Die Übertragung von Bewegtdaten kann man zwar als Stapel sehen, der 'wahre Stapel' ergibt sich aber erst durch die zusammenfassende Bearbeitung im Steuerbüro. Sie gehen hin und laden sich alle übertragenen Daten in einen Vorgang. Das können auch mehrere Übertragungen zu einem Zeitraum sein - im Rechnungswesen werden sie dann zusammengefasst und endgültig verbucht.
Viele Grüße
Dino
Hallo Dino,
herzlichen Dank für Deine ausführliche Beschreibung. Das ist für uns sehr interessant zu lesen, wie andere die Schnittstelle nutzen.
Der Prozess bei uns ist ähnlich, zuerst übertragen wir die Bilder mit der GUID und danach die EXTF csv Datei.
Bei Erfolg wird bei uns die Reise oder die Ausgabe auf "exportiert" gesetzt, wohlgemerkt nur dann, wenn sowohl kein Fehler im EXTF und kein Fehler bei allen zu der Reise dazu gehörenden Belegen aufgetreten ist. Im Fehlerfall gibt es eine Info an den User per Oberfläche und eine Email wenn er das so eingestellt hat. Wir haben auch so was wie einen automatischen nächtlichen Export, der alle Reisen und Ausgaben abholt (die im entsprechenden Status "freigegeben") und dann überträgt. Im Fehlerfall kann dann der Export auch neu angestossen werden mit neuer GUID.
Unser Prinzip, auch bei den anderen REST Schnittstellen, z.B. bei lexoffice, ist auch das, dass wir davon ausgehen, dass alles automatisch laufen soll und nicht jemand hingehen muss und den Export anstossen muss. Also nächtlich automatisch. Irgendwie sagt mir aber mein Bauchgefühl, dass das im Falle DATEV und DATEV Anwender anders laufen wird, weil man in den Steuerkanzleien eine andere Art zu arbeiten hat.. Da bin ich mal gespannt. Bei uns ist das einstellbar pro Kunde.
Wir haben jetzt tatsächlich auch die Option gebaut, dass der Kunde einstellen kann, wie er den gerne den Buchungsstapel hätte, aufgrund des Ratschlags des Datev Beraters in der Freigabe Sitzung. Wir werden sehen, wie das angenommen wird oder ob es irrelevant ist. Default ist sowieso "Ein Stapel pro Export" - wobei das auch 2 Stapel werden können, wenn es 2 verschiedene Wirtschaftsjahre betrifft.
A pro pos: fragt ihr das Wirtschaftsjahr ab? Ich wollte das machen mit
https://accounting-documents.api.datev.de/platform/v2/clients/{cliend-id}
aber bekomme immer einen Fehler.
Viele Grüße
Reisekostenrechner
Hallo Reisekostenrechner,
nein, das benötigen wir nicht.
>>
A pro pos: fragt ihr das Wirtschaftsjahr ab? Ich wollte das machen mit
https://accounting-documents.api.datev.de/platform/v2/clients/{cliend-id}
aber bekomme immer einen Fehler.
<<
Liegt es evtl an der client-id? Die muss nämlich aus Beraternummer-Mandantennummer (mit Bindestrich) bestehen.:
string url = "https://accounting-clients.api.datev.de/" + gateway_url + "/v2/clients/" + datev_client_id + "-" + mandant_client_id; // 455148-1 (Sandbox)
VG
Dino
Hallo Dino,
ich habe gestern noch eine Antwort von der Schnittstellenberatung bekommen. Es ist nicht erlaubt den Endpunkt https://accounting-documents.api.datev.de/platform/v2/clients/{cliend-id} im Kontext des Buchungsdatenservice aufzurufen.
Das mit der Clientid-Mandantennummer war bekannt, trotzdem danke.
Viele Grüße
Reisekostenrechner