Desktop APIs Abruf Offene Posten

[#1]

wir möchten offene Posten zu einem Konto aus unserer Abrechnungssoftware abrufen.

Probiert habe ich die Endpunkte:

/clients/{client-id}/fiscal-years/{fiscal-year-id}/accounts-receivable
und 
/clients/{client-id}/fiscal-years/{fiscal-year-id}/accounts-payable

Als Parameter übergebe ich nur die client-id und fiscal-year-id.

Es wird keine Fehlermeldung ausgegeben. Da es sich um einen Testmandanten handelt, ist auch die Datenmenge überschaubar.

Bei beiden bekomme ich nichts zurück geliefert, obwohl offene Posten vorhanden sind.

Nutze ich die falschen Endpunkte oder liegt es an den Rechten des Users oder?

[#2]

Wenn mich nicht alles täuscht, gibt es für die "Offenen Posten" keinen API Endpunkt und es wird KR Export (bspw. KRExport: ASCII-Daten automatisiert exportieren - DATEV Hilfe-Center) benötigt.

[#3 · Accepted solution]

Der wahrscheinlichste Fehler: Es wurden Klartextwerte statt der DATEV-internen Kennungen übergeben.

Die client-id ist eine GUID (z. B. 78a11a29-2a32-…), nicht die Mandantennummer. Und die fiscal-year-id ist der erste Tag des Wirtschaftsjahres im Format YYYYMMDD (z. B. 20260101), nicht die Jahreszahl „2026".

Wer die Mandantennummer oder „2026" direkt in den Pfad setzt, adressiert einen Bestand, den es so nicht gibt — und bekommt einen technisch gültigen, aber leeren Response. Genau das Symptom: kein Fehler, keine Daten. (Das ist auch der Grund, warum meine App die GUIDs erst über /clients und /fiscal-years auflöst, bevor sie die OP zieht.)

Falls die IDs korrekt waren, bleiben folgende zwei Punkte :

Die Datenpfad-Kollision (Dok 1071637) — DATEVconnect findet den richtigen Datenpfad nicht selbst, greift auf einen leeren zu, meldet aber keinen Fehler. Das ist der zweithäufigste Auslöser für genau dieses „läuft durch, liefert nichts".

Und die Rechte des Schnittstellen-Users — Leserechte müssen auf genau diesen OPOS-Bestand gehen; „im Programm sichtbar" heißt nicht automatisch „über diesen Datenpfad lesbar".

[#4]

Testen konnte ich noch nicht. Aber es scheint am /fiscal-years zu liegen. Wahrscheinlich habe ich hier ein Jahr übergeben, was im Testmandanten in Datev nicht angelegt ist.