Quand une réception de véhicule sort de l’ordinaireTous les articles

Quand une réception de véhicule sort de l’ordinaire

Un véhicule sans propriétaire identifiable ou une réception au mauvais endroit ne sont pas des exceptions à régler plus tard. Ce cas montre quelle preuve correspond à quel cas particulier.

Publié: 2026-09-12Temps de lecture: 5 minAPI tapinomahub & processus
API & processusAPI

Un véhicule sans papiers est déposé sur le site pendant la nuit. Le même jour, un employé réceptionne un véhicule alors que le site n’y est pas autorisé. Les deux arrivent, et un contrôle ne juge pas s’ils sont arrivés mais comment ils ont été traités.

Quand une réception de véhicule sort de l’ordinaireUn cas particulier à la réception — Propriétaire introuvable, réception non autorisée, déclaration d’abandon — chaque cas a sa propre preuve. 1. Documenter une réception non autorisée (POST /compliance/cases/{id}/unauthorized-receipt-incidents): receivedAt, location, reason et safeguards — ce qui a été reçu et comment c’est sécurisé 2. Identifier le propriétaire (POST /compliance/cases/{id}/owner-identification): status identified, pending ou not_identifiable, avec attempts 3. Consigner l’abandon (POST /compliance/cases/{id}/owner-disposition-decisions): décision du propriétaire avec attestation — saisie seulement par une personne connectée 4. Orienter un véhicule sans propriétaire (POST /compliance/cases/{id}/ownerless-routing): targetAtfFacilityId et plannedTransferAt 5. Remettre le récépissé (POST /compliance/collection-receipts/{id}/deliveries): deliveryType receipt avec destinataire, support et date La branche applicable dépend du cas. La chaîne consigne qu’une décision a été prise et comment.Un cas particulier àla réceptionPropriétaire introuvable,réception non autorisée,déclaration d’abandon — chaquecas a sa propre preuve.Quand une réception de véhicule sort de l’ordinaireDocumenter une réception non autoriséePOST /compliance/cases/{id}/unauthorized-receipt-incidentsreceivedAt, location, reason et safeguards — ce qui a étéreçu et comment c’est sécuriséIdentifier le propriétairePOST /compliance/cases/{id}/owner-identificationstatus identified, pending ou not_identifiable, avecattemptsConsigner l’abandonPOST /compliance/cases/{id}/owner-disposition-decisionsdécision du propriétaire avec attestation — saisie seulementpar une personne connectéeOrienter un véhicule sans propriétairePOST /compliance/cases/{id}/ownerless-routingtargetAtfFacilityId et plannedTransferAtRemettre le récépisséPOST /compliance/collection-receipts/{id}/deliveriesdeliveryType receipt avec destinataire, support et dateLa branche applicable dépend du cas. La chaîne consigne qu’une décision a été prise et comment.
Cinq branches pour les cas particuliers de réception. Tous n’en ont pas besoin — mais chacun a besoin de la sienne.

La surface Compliance donne à chacun de ces cas particuliers sa propre commande et sa propre preuve. La branche applicable dépend du cas ; la chaîne d’événements consigne qu’une décision a été prise et comment — avec date, organisation et personne agissante.

SurfaceRôles
ComplianceRecycleurs automobiles

Ce que ce cas suppose

  • Un dossier créé. Toutes les commandes sauf la remise du récépissé portent sur un dossier ; chacune des cinq commandes exige la version ETag actuelle dans If-Match.
  • L’organisation dans l’appel. X-Compliance-Organisation-Id lie chaque événement à l’organisation responsable.
  • Une personne connectée pour l’abandon. La décision du propriétaire n’est consignée que dans une session humaine ; une clé API ne suffit pas.
  • Une installation cible pour les véhicules sans propriétaire. L’orientation nomme expressément l’installation de traitement destinataire.

Le déroulement

Le tableau indique pour chaque étape l’appel compétent et ce qui existe ensuite. La justification de l’étape figure en dessous.

La chaîne d’appels de ce cas d’usage
ÉtapeAppelCe qui existe ensuite
Documenter une réception non autoriséePOST /compliance/cases/{id}/unauthorized-receipt-incidentsreceivedAt, location, reason et safeguards — ce qui a été reçu et comment c’est sécurisé
Identifier le propriétairePOST /compliance/cases/{id}/owner-identificationstatus identified, pending ou not_identifiable, avec attempts
Consigner l’abandonPOST /compliance/cases/{id}/owner-disposition-decisionsdécision du propriétaire avec attestation — saisie seulement par une personne connectée
Orienter un véhicule sans propriétairePOST /compliance/cases/{id}/ownerless-routingtargetAtfFacilityId et plannedTransferAt
Remettre le récépisséPOST /compliance/collection-receipts/{id}/deliveriesdeliveryType receipt avec destinataire, support et date

Pourquoi chaque étape est nécessaire

  1. Documenter la réception non autorisée. POST /compliance/cases/{id}/unauthorized-receipt-incidents prend receivedAt, location, reason et au moins une mention dans safeguards. On consigne non seulement l’anomalie, mais la façon dont le véhicule est sécurisé jusqu’à clarification.
  2. Identifier le propriétaire. POST /compliance/cases/{id}/owner-identification prend status avec identified, pending ou not_identifiable et les attempts effectués. C’est la démarche qui est prouvée, pas seulement le résultat — avec not_identifiable, elle constitue la preuve même.
  3. Consigner l’abandon. POST /compliance/cases/{id}/owner-disposition-decisions prend ownerPartyId, decision, effectiveAt et une attestationId. Seule une personne connectée peut le consigner ; une clé API seule ne suffit pas.
  4. Orienter le véhicule sans propriétaire. POST /compliance/cases/{id}/ownerless-routing nomme l’installation cible dans targetAtfFacilityId et le transfert prévu dans plannedTransferAt. L’orientation est planifiée et nommée, non un enlèvement à la demande.
  5. Remettre le récépissé. POST /compliance/collection-receipts/{id}/deliveries porte deliveryType receipt, recipientPartyId, medium et deliveredAt. Celui qui a remis un véhicule reçoit le récépissé de façon justifiable — aussi dans un cas particulier.
Orienter un véhicule sans propriétaire vers une installation de traitement
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'

Ce que l’on obtient

Au final, chaque cas particulier a sa preuve : la réception non autorisée avec sa sécurisation, la recherche du propriétaire avec ses tentatives, l’abandon avec sa personne, le véhicule sans propriétaire avec son installation cible et le déposant avec son récépissé.

Où cela figure dans la documentation

Les listes de champs contractuelles, les codes d’erreur et les réponses d’exemple se trouvent dans le contrat OpenAPI de cette surface, à l’adresse docs.tapinomahub.com (tapinoma-compliance). Tous les cas d’usage classés par surface et par rôle : aperçu des cas d’usage.

Sources et références juridiques

Questions fréquentes

Dois-je parcourir les cinq branches ?

Non. Chaque branche correspond à un cas particulier. Un véhicule sans propriétaire exige la recherche et l’orientation ; une déclaration d’abandon exige la décision du propriétaire.

Puis-je consigner l’abandon avec une clé API ?

Non. Le contrat exige une personne connectée. Les autres branches peuvent aussi être saisies avec une clé API disposant du rôle adéquat.

Pourquoi consigner les recherches infructueuses ?

Parce que, lorsqu’un propriétaire est introuvable, la démarche elle-même est la preuve. Un simple « non identifiable » ne résiste pas à un contrôle.