Thema "Bug oder falsche Verwendung - Accounting Schnittstelle" in Technisches zu Software

Bug oder falsche Verwendung - Accounting Schnittstelle

upspot — Fri, 29 Apr 2022 16:53:57 GMT

Hallo,

ich programmiere aktuell gegen die neusten Version der Account Desktop API.

Mit folgender URL lese ich Debitoren aus:

http://localhost:58454/datev/api/accounting/v1/clients/UUID/fiscal-years/20220101/debitors?filter=business_partner_number eq 30336 and date_last_modification ge TIMESTAMP

Das ganze klappt soweit auch. Die gelieferten Datensätze sehen korrekt aus und können entsprechend weiterverarbeitet werden. Am Datensatz selber ist ein Feld "date_last_modification" welches in meinem Beispiel mit dem Wert "2022-04-29T18:37:03.037+02:00" gefüllt ist.

Nach meinem Verständnis müsste ich den Datensatz mit folgendem Aufruf also erhalten:

http://localhost:58454/datev/api/accounting/v1/clients/UUID/fiscal-years/20220101/debitors?filter=business_partner_number eq 30336 and date_last_modification ge 2022-04-29T18:37:03

Das ist aber leider nicht der Fall, das Ergebnis bleibt leer. Erst wenn ich von dem Timestamp 2 Stunden abziehe -> "2202-04-29T16:37:03" erhalte ich den Datensatz wieder.

Kann es sein, dass hier mit der Zeitzone nicht korrekt umgegangen wird? Dadurch gehen alle Änderungen innerhalb der letzten 2 Stunden eines Exports verloren. Klar, ich kann nun von meinem LastRun-Timestamp für Datev immer 2 Stunden abziehen, aber das ist ja eigentlich nicht korrekt oder habe ich einen Denkfehler?

Vielen Dank

Bug oder falsche Verwendung - Accounting Schnittstelle

quantenjoe — Fri, 29 Apr 2022 22:08:30 GMT

Moin Moin

Gleich zu Beginn: So etwas wie ein Hinweis zu einer möglichen Antwort haben ich nicht!!!

Schon weil mir allein die Aufrufe nicht bekannt sind. Derartiges Wissen ist mir bisher bei Datev nicht untergekommen. Ist ader sehr interessant - und würde ich gern mehr drüber wissen, liebe Datev!

Bei 2. Stunden Differenz im April denke ich zuerst an Univeral Time, Also CEST - 2h. Muss nicht stimmen, finde ich aber naheliegend. Warum, wieso und überhaupt, kann da nur Datev selber erklären. Jedenfalls glaube ich nicht dass die Community - so gut sie ist! - das klären kann.

Anmerkung: Ich hätte CET also 1 Stunde verstanden. Aber 2? Wie gesagt, UT springt da ins Auge, doch warum sollte Datev vom deutschen Zeitnormal da abweichen? Das kann nur Datev selber wohl erklären.

Bug oder falsche Verwendung - Accounting Schnittstelle

seprof — Sat, 30 Apr 2022 06:18:22 GMT

Das Wissen dazu gibt es auf developer.datev.de. Hier darf sich jeder kostenlos registrieren.

Bug oder falsche Verwendung - Accounting Schnittstelle

vogtsburger — Sat, 30 Apr 2022 09:18:20 GMT

... könnte noch ein wenig komplizierter/verwirrender werden:

... während der Sommerzeit 2 Stunden, während der Winterzeit 1 Stunde Zeitverschiebung

... ich 'kämpfe' bei der Auswertung von Zeiten, auf einem anderen Gebiet, auch immer mit diesem Effekt

... weiß aber nicht, ob das hier in die selbe Kerbe stößt 😉

Bug oder falsche Verwendung - Accounting Schnittstelle

fcp — Mon, 03 Jul 2023 14:19:29 GMT

Hast du mittlerweile Erfahrung mit dieser API?

Was ist damit ungefähr möglich ?

Bug oder falsche Verwendung - Accounting Schnittstelle

RAHagena — Mon, 03 Jul 2023 14:55:24 GMT

im Developer-Portal gibts die Antworten für die Techies 😉 u.a. die vollständige Schnittstellenbeschreibung

Bug oder falsche Verwendung - Accounting Schnittstelle

rschoepe — Tue, 04 Jul 2023 06:37:45 GMT

@upspot schrieb:
Feld "date_last_modification" welches in meinem Beispiel mit dem Wert "2022-04-29T18:37:03.037+02:00" gefüllt ist.

Nach meinem Verständnis müsste ich den Datensatz mit folgendem Aufruf also erhalten:

http://localhost:58454/datev/api/accounting/v1/clients/UUID/fiscal-years/20220101/debitors?filter=business_partner_number eq 30336 and date_last_modification ge 2022-04-29T18:37:03

Das ist aber leider nicht der Fall, das Ergebnis bleibt leer. Erst wenn ich von dem Timestamp 2 Stunden abziehe -> "2202-04-29T16:37:03" erhalte ich den Datensatz wieder.

Gibt dem Timestamp in der Abfrage mal die "+02:00" wieder mit, dann sollte es gehen. 😉

Denn ja, 18:37:03+02:00 ist eben nicht gleich 18:37:03 (implizit: +00:00) sondern 16:37:03(+00:00).