Skip to content

Sous-traitance avec TMS

Le transporteur désigné sur le document (CARRIER) n'effectue pas lui-même le transport : il sous-traite à une autre société de transport, qui dispose elle-même de son propre TMS et de ses propres identifiants API. Ce scénario s'appuie sur la délégation de rôle : le rôle CARRIER reste porté par l'entreprise donneuse d'ordre, mais son accès est délégué à une autre organisation, qui confie ensuite le document à l'un de ses propres chauffeurs (sous-comptes). La délégation n'a qu'un niveau : le sous-traitant ne peut pas re-déléguer à un autre sous-traitant.

Points clés à retenir :

  • La délégation se fait au niveau du rôle (CARRIER), pas au niveau du document entier — le sous-traitant ne voit que ce à quoi son rôle délégué lui donne accès.
  • Le sous-traitant s'authentifie avec ses propres identifiants API — jamais avec ceux du donneur d'ordre.
  • Le sous-traitant désigne lui-même son chauffeur (un de ses sous-comptes) sur la délégation qu'il a reçue : PATCH /freightdocuments/{id}/roles/{role_id}/delegations/{delegation_id}/assign-subaccount. Sans désignation, tous ses sous-comptes voient le document.
  • Le donneur d'ordre continue de recevoir les webhooks de changement de statut du document.
  • Par défaut, les autres parties du document ne voient pas l'identité du sous-traitant — ni dans GET /freightdocuments/{id}, ni dans le payload webhook : pour l'expéditeur ou le destinataire, le rôle CARRIER reste affiché avec l'identité du donneur d'ordre. C'est une décision de confidentialité commerciale qui appartient au donneur d'ordre, titulaire du rôle : lui seul peut exposer ses délégataires actifs via PATCH /freightdocuments/{id}/roles/{role_id}/visibility — voir la référence API. Le sous-traitant, lui, ne voit du document que ce que son rôle délégué lui ouvre.
  • Le chauffeur doit signer sa propre acceptation de collecte (COLLECTION_ACCEPTANCE) avant de pouvoir signer la livraison — bloquée sinon (signature.collection_acceptance_required). L'application chauffeur enchaîne les deux automatiquement, sans action supplémentaire de votre part. Voir Signature électronique.
sequenceDiagram
    participant TMS as TMS donneur d'ordre
    participant API as API e-CMR
    participant SubTMS as TMS sous-traitant
    participant Driver as Chauffeur (app)

    TMS->>API: POST /freightdocuments + issue
    API-->>TMS: 200 OK, status=ISSUED

    Note over TMS,SubTMS: Délégation au niveau document
    TMS->>API: POST delegate (role Carrier vers email sous-traitant)
    API-->>TMS: 200 OK, délégation créée
    API-)SubTMS: Email: accès délégué reçu

    Note over SubTMS,API: Le sous-traitant utilise ses propres identifiants API
    SubTMS->>API: GET /freightdocuments?filters=ownRoles.eq:CARRIER
    API-->>SubTMS: Liste des documents délégués

    Note over SubTMS,Driver: Le sous-traitant désigne son propre chauffeur
    SubTMS->>API: PATCH .../delegations/{delegation_id}/assign-subaccount
    API-->>SubTMS: 200 OK, chauffeur désigné
    SubTMS-)Driver: Mission assignée (dans son propre système)

    Driver->>API: GET /freightdocuments/id (identifiants sous-compte)
    API-->>Driver: Document + ownPermissions

    Driver->>API: POST events (arrivée, chargement)
    Driver->>API: POST signature collecte
    API-->>Driver: 200 OK, status=TRANSIT
    API-)TMS: Webhook STATUS=TRANSIT
    Driver->>API: POST signature collecte-chauffeur (COLLECTION_ACCEPTANCE)
    API-->>Driver: 200 OK, signature enregistrée (statut inchangé)

    Driver->>API: POST events (arrivée, déchargement)
    Driver->>API: POST signature livraison
    API-->>Driver: 200 OK, status=DELIVERED
    API-)TMS: Webhook STATUS=DELIVERED

    SubTMS->>API: GET /freightdocuments/id (suivi de son propre transport)
    API-->>SubTMS: status=DELIVERED