Wenn eine Fahrzeugannahme nicht der Normalfall ist

Auf dem Gelände steht ein Fahrzeug ohne Papiere, abgestellt über Nacht. Am selben Tag nimmt ein Mitarbeiter ein Fahrzeug an, obwohl der Standort dafür nicht zugelassen ist. Beides passiert, und beides wird bei einer Prüfung nicht danach beurteilt, ob es passiert ist, sondern wie damit umgegangen wurde.

Die Compliance-Fläche gibt jedem dieser Sonderfälle ein eigenes Kommando mit eigenem Nachweis. Welcher Zweig gilt, entscheidet der Einzelfall; die Ereigniskette hält fest, dass und wie entschieden wurde — mit Zeitpunkt, Organisation und handelnder Person.

Was dieser Fall voraussetzt

• Einen angelegten Fall. Alle Kommandos außer der Belegzustellung beziehen sich auf einen Fall; jedes der fünf Kommandos verlangt die aktuelle ETag-Version in If-Match.
• Die Organisation im Aufruf. X-Compliance-Organisation-Id bindet jedes Ereignis an die verantwortliche Organisation.
• Eine angemeldete Person für die Entledigung. Die Entscheidung des Eigentümers wird nur in einer menschlichen Sitzung erfasst; ein API-Schlüssel genügt nicht.
• Eine Zielanlage für eignerlose Fahrzeuge. Die Weiterleitung nennt die empfangende Behandlungsanlage ausdrücklich.

Der Ablauf

Die Tabelle nennt je Stufe den zuständigen Aufruf und das, was danach vorliegt. Die Begründung, warum die Stufe nicht übersprungen werden kann, steht darunter.

Warum jede Stufe nötig ist

1. Die unzulässige Annahme dokumentieren. POST /compliance/cases/{id}/unauthorized-receipt-incidents nimmt receivedAt, location, reason und mindestens eine Angabe in safeguards. Festgehalten wird nicht nur, dass etwas schiefging, sondern wie das Fahrzeug bis zur Klärung gesichert ist.
2. Den Eigentümer ermitteln. POST /compliance/cases/{id}/owner-identification nimmt status mit identified, pending oder not_identifiable und die unternommenen attempts. Belegt wird die Bemühung, nicht nur das Ergebnis — gerade bei not_identifiable ist sie der eigentliche Nachweis.
3. Die Entledigung festhalten. POST /compliance/cases/{id}/owner-disposition-decisions nimmt ownerPartyId, decision, effectiveAt und eine attestationId. Diese Handlung erfasst nur eine angemeldete Person; ein API-Schlüssel allein genügt nicht.
4. Das eignerlose Fahrzeug weiterleiten. POST /compliance/cases/{id}/ownerless-routing nennt die Zielanlage in targetAtfFacilityId und den geplanten Übergang in plannedTransferAt. Die Weiterleitung ist geplant und benannt, nicht eine Abholung auf Zuruf.
5. Den Annahmebeleg zustellen. POST /compliance/collection-receipts/{id}/deliveries trägt deliveryType receipt, recipientPartyId, medium und deliveredAt. Wer ein Fahrzeug abgegeben hat, bekommt den Beleg nachweisbar — auch in einem Sonderfall.

curl -X POST \
  -H 'X-Api-Key: <API_KEY>' \
  -H 'X-Compliance-Organisation-Id: <ORGANISATION>' \
  -H 'If-Match: "<etag>"' \
  -H 'Idempotency-Key: eignerlos-weiterleitung-0417' \
  -H 'Content-Type: application/json' \
  -d '{"targetAtfFacilityId":"<facilityId>","plannedTransferAt":"2026-09-15T08:00:00Z"}' \
  'https://api.tapinomahub.com/compliance/cases/<id>/ownerless-routing'

Was am Ende vorliegt

Am Ende hat jeder Sonderfall seinen Nachweis: die unzulässige Annahme mit ihrer Sicherung, die Eigentümerermittlung mit ihren Versuchen, die Entledigung mit ihrer Person, das eignerlose Fahrzeug mit seiner Zielanlage und der Abgebende mit seinem Beleg.

Wo das in der Dokumentation steht

Die verbindlichen Feldlisten, Fehlercodes und Beispielantworten stehen im OpenAPI-Vertrag dieser Fläche unter docs.tapinomahub.com (tapinoma-compliance). Alle Anwendungsfälle nach Fläche und Rolle geordnet: Übersicht der Anwendungsfälle.