Réponse directe
Chaque commande confirmée part via une intégration livraison et une ville fournisseur choisies à l’envoi. ERP-STOK centralise tracking_number, delivery_status et libellés synchronisés par transporteur. En multi-prestataires, filtrez par provider, ville et statut ; ne comparez pas les libellés bruts entre carriers sans normalisation. Le stock se déduit au ramassage par tracking via DeliverySaleService — quel que soit le livreur.
Étape 1 — Après confirmation : choix transporteur + ville
sendToDelivery lie la commande à un integration_id et une delivery_city (catalogue delivery_cities du prestataire).
Multi-transporteurs signifie que deux commandes voisines peuvent partir chez des prestataires différents selon les intégrations configurées et disponibles pour le compte, la couverture et les habitudes ops.
- Commande en statut confirmer.
- Sélection intégration livraison (prestataire A ou B).
- Sélection ville fournisseur correspondante.
- Envoi API → création colis + tracking_number.
- Commande passe en flux livraison (in_delivery, etc.).
Étape 2 — Sync et monitoring
Les statuts remontent par polling (ou webhook si configuré) avec des libellés parfois différents entre prestataires.
Le module In Delivery propose filtres provider, ville, agent, recherche — utiles pour trier par livreur une file mixte.
delivery_status ERP-STOK (pending, in_delivery, delivered, returned, return_pending_scan) normalise partiellement ; le libellé brut transporteur reste visible pour le détail.
Étape 3 — Stock et retours par tracking
DeliverySaleService déduit au ramassage/pickup signalé, identifié par tracking_number — indépendamment du prestataire.
Les retours et return_pending_scan se suivent par tracking ; les échanges peuvent référencer exchange_old_tracking (support variable selon carrier).
Erreurs ops multi-livreurs
Mélanger les villes catalogues : la ville client ≠ ville API prestataire B alors que l’envoi part chez B.
Suivre manuellement dans un tableur parallèle : double saisie et statuts contradictoires.
Comparer les délais sans tenir compte des sync intervals différents.
Exemple illustratif (fictif) — multi-prestataires
Semaine type (exemple fictif) : répartition entre deux prestataires configurés sur le compte. L’ops filtre In Delivery par provider pour la relance du matin. Une commande reste en in_delivery avec libellé spécifique ; le tracking déclenche la déduction stock au ramassage quel que soit le livreur.
Workflow ERP-STOK multi-transporteurs
Intégrations multiples selon les intégrations configurées et disponibles pour le compte (ex. Siftly, Coliaty, Rushliv, Truship, Speedex).
Catalogue delivery_cities par prestataire — resync nécessaire si le carrier ajoute des villes.
Filtres opérationnels In Delivery : provider, ville, agent, recherche, plages sent_to_delivery_at.
Tracking centralisé + DeliverySaleService pour stock au ramassage quel que soit le livreur.
Pour conclure
Multi-livreurs fonctionne si chaque envoi respecte intégration + ville catalogue, et si le monitoring passe par les filtres ERP-STOK — pas par des files parallèles.
Le stock et les retours restent ancrés sur le tracking, pas sur le nom du transporteur.
Limites et points d’attention
- Support échange et champs API non identiques entre transporteurs.
- Fréquence sync dépend configuration et scheduler.
- Pas de tableau de bord « SLA livreur » universal garanti dans le produit.