Schnittstellenvorgaben
Aufgaben zur technischen Prüfung der Importschnittstelle eAU-API
Hinweis: Anforderungen an die technische Prüfung der Schnittstelle für künftige „Anbieter mit DATEV Schnittstellen“.
Die in der Schnittstellenbeschreibung der eAU-API enthaltenen Angaben müssen seitens des Anbieters geprüft und in der Entwicklung berücksichtigt werden.
1. Beschreibung des Abnahmeprozesses zur technischen Prüfung
Die Schnittstellenprüfung erfolgt zunächst in einer Sandbox-Umgebung und anschließend in einer produktiven Umgebung. Der Prüfprozess ist jeweils in den folgenden beiden Unterkapiteln beschrieben.
Voraussetzungen:
- Client-ID und Client-Secret (für das OAuth-Verfahren)
- Zugangsdaten für die Sandbox
- Authentifizierungsmedium: Benutzerkonto
1.1 Schnittstellenabnahme in der Sandbox-Umgebung
Vorbereitung: Der Anbieter entwickelt und testet selbst gegen die Sandbox-Umgebung.
Ist die Schnittstelle bereit für die Abnahme, stellt der Anbieter im Rahmen einer Fernbetreuungssitzung bzw. Videokonferenz DATEV die Funktionalität der Schnittstelle in der Sandbox-Umgebung vor.
Dabei berücksichtigt werden:
- Erfolgreicher und fehlerhafter Get Clients-Abruf
- Absetzen eines erfolgreichen eAU-Requests (POST mit Status 201 created)
- Abholen der Rückmeldung zu einer vorher abgesetzten eAU-Anfrage (GET)
- Darstellung eines fehlerhaften eAU-Requests und Umgang mit der Fehlermeldung
1.1.1 Testfälle
Folgende Testfälle werden für den OBG 455148 – 1/2/3 angeboten:
| Berater | GET - Anfrage | ReturnCode |
|---|---|---|
| 1/2/3 | Berater ist berechtigt | RC 200 |
| 4 | Berater ist nicht autorisiert | RC 401 |
| 5 | Berater ist nicht authentifiziert | RC 403 |
| PersonalNr | POST - Anfrage | ReturnCode |
|---|---|---|
| ALLE | eAU Anfrage eines gültigen Arbeitnehmers (ohne E-Mail-Benachrichtigung) | RC 201 |
| 101 | eAU Anfrage eines gültigen Arbeitnehmers (mit E-Mail-Benachrichtigung) | RC 201 |
| 102 | eAU Anfrage eines gültigen Arbeitnehmers (mit ungültiger E-Mail-Benachrichtigungsadresse) | RC 201 |
| 400 | Arbeitnehmer ist privat versichert | RC 400 |
| 900 | Geburtsdatum des Arbeitnehmers in der Sozialversicherungsnummer ist fehlerhaft | RC 400 |
| PersonalNr | GET - Get feedbacks | ReturnCode |
|---|---|---|
| ALLE | Keine Rückmeldung (Anfrage eAU ohne E-Mail-Benachrichtigung) | RC 200 |
| 101 | Keine Rückmeldung (Anfrage eAU mit E-Mail-Benachrichtigung) | RC 200 |
| 102 | Keine Rückmeldung (Anfrage eAU mit ungültiger E-Mail-Benachrichtigungsadresse) | RC 200 |
| 200 | Rückmeldung einer eAU eines Arbeitnehmers bei stationärem Aufenthalt | RC 200 |
| 300 | Rückmeldung mit AU | RC 200 |
| 400 | eAU-Anfrage nicht gefunden | RC 404 |
| 500 | Kennzeichen aktuelle Arbeitsunfähigkeit (flag_current_work_incapacity) = 1 (unzuständige Krankenkasse) | RC 200 |
| 600 | Kennzeichen aktuelle Arbeitsunfähigkeit (flag_current_work_incapacity) = 4 (eAU liegt nicht vor) | RC 200 |
| 700 | Rückmeldung mit internem Fehler (DATEV) | RC 200 |
| 800 | Rückmeldung mit externem Fehler (Krankenkasse) | RC 200 |
| 900 | eAU-Anfrage nicht gefunden | RC 404 |
| 1000 | Rückmeldung mit Folge-eAU (start_work_incapacity_au: null und initial_certificate=false) | RC 200 |
| PersonalNr | DELETE - Cancel eAU-request | ReturnCode |
|---|---|---|
| ALLE | eAU Anfrage erfolgreich storniert | RC 204 |
| 400 | eAU Anfrage wurde nicht gefunden | RC 404 |
| 900 | eAU Anfrage wurde nicht gefunden | RC 404 |
| PersonalNr | POST – Register Webhook | ReturnCode |
|---|---|---|
| ALLE | Webhook wurde erfolgreich registriert | RC 201 |
| 400 | Registrierung abgelehnt wegen fehlerhafter URL | RC 400 |
| 404 | Webhook konnte aufgrund ungültiger Source nicht registriert werden | RC 400 |
| 2000 | Webhook ist bereits für diese Personalnummer registriert | RC 400 |
| PersonalNr | PUT – Change Webhook | ReturnCode |
|---|---|---|
| ALLE | Webhook wurde erfolgreich geändert | RC 200 |
| 400 | Webhook abgelehnt wegen falschem Parameter | RC 400 |
| 404 | Webhook wurde nicht gefunden | RC 404 |
| PersonalNr | GET – Get Webhook | ReturnCode |
|---|---|---|
| ALLE | Webhook wurde erfolgreich angefragt | RC 200 |
| 400 | Webhook abgelehnt wegen falschem Parameter | RC 400 |
| 404 | Webhook wurde nicht gefunden | RC 404 |
| PersonalNr | DELETE – Delete Webhook | ReturnCode |
|---|---|---|
| ALLE | Webhook wurde erfolgreich gelöscht | RC 204 |
| 400 | Anfrage wegen falscher Parameter abgelehnt | RC 400 |
| 404 | Webhook wurde nicht gefunden | RC 404 |
Anfragen mit Mandant 455148-4:
Alle Endpoints liefern RC 401, da der Mandant nicht autorisiert ist.
Anfragen mit Mandant 455148-5:
Alle Endpoints liefern RC 403, da der Mandant nicht authentifiziert ist.
2. Anbindung der produktiven Umgebung
2.1 Voraussetzungen für die Nutzung der produktiven Umgebung
Der Anwender benötigt die folgenden Komponenten:
- Client-ID und Client-Secret (für das OAuth-Verfahren)[1]
- Authentifizierungsmedium: DATEV Smart Login oder DATEV Smartcard[2]
- LODAS / Lohn und Gehalt zum Erfassen von Testdaten (Stammdaten)
2.2 Schnittstellenabnahme in der produktiven Umgebung
Vorbereitung: Der Anbieter entwickelt und testet selbst gegen die produktive Umgebung.
Ist die Schnittstelle bereit für die Abnahme, stellt der Anbieter im Rahmen einer Fernbetreuungssitzung bzw. Videokonferenz DATEV die Funktionalität der Schnittstelle in der produktiven Umgebung vor.
Dabei berücksichtigt werden:
- Umsetzung der Authentifizierung
- Die Authentifizierung erfolgt auf Basis des OAuth 2.0-Verfahrens
- Der Anbieter zeigt die Umsetzung in seiner Anwendung anhand der folgenden Kriterien:
- Erfolgreicher Get Clients-Abruf. Auf der Oberfläche wird eine passende Hinweismeldung angezeigt
- Es besteht die Möglichkeit mittels des Refresh Tokens ein neues Access Token anzufordern
- Kann der Anwender mehrere eAU-Anfragen hintereinander ausführen? Kann der Anwender, wenn er angemeldet bleibt, auch noch eine eAU Anfrage ohne erneute Authentifizierung bei DATEV durchführen?
- Das Speichern des Zugriffstokens darf nicht benutzerübergreifend erfolgen
- Es muss jedes Mal ein neuer Access Token angefordert werden
- Es muss eine erfolgreiche Abmeldung (Token revoke) vorgezeigt werden
- Prüfung negativer Szenarien:
- Bei der Authentifizierung wird ein abgelaufenes Token verwendet. Es darf keine Authentifizierung möglich sein
- Es wird eine Berater-/Mandantennummer verwendet, die nicht berechtigt ist. Es darf kein eAU-Request möglich sein (Fehlerhafter Get Clients-Abruf). Auf der Oberfläche wird eine passende Fehlermeldung angezeigt
- Prüfung fachlicher Szenarien:
- Es wurde erfolgreich ein eAU-Request abgesetzt (POST)
- Es wurde erfolgreich ein abgesetzter eAU-Request inkl. Rückmeldung angefragt (GET)
- Es wurde ein fachlich falscher eAU-Request abgesetzt und die Response verstanden (gleichen POST zweimal hintereinander absetzen >> Returncode 400 inkl. Fehlermeldung). Auf der Oberfläche wird eine passende Fehlermeldung angezeigt
- Es wurde ein abgesetzter eAU-Request storniert (DELETE)
- Es ist sicher zu stellen, dass Anwender vor einer Abfrage darauf hingewiesen werden, dass eine eAU-Abfrage nur abgesetzt werden darf wenn sich der Arbeitnehmer nach §5 Abs. 1 EntgFG krankgemeldet hat.
Zu beachten sind auch die Allgemeine Schnittstellenvorgaben | DATEV Developer Portal.
Fragen zu den Schnittstellenvorgaben können Sie an marktplatz@datev.de richten.
[1] Erhält der Anbieter nach der Einstiegsberatung Webservices
[2] Erhält der Anbieter von seinem Partnerbetreuer