Sommaire
Réponse directe
Une commande COD entre par ingestion (Shopify, Woo, YouCan, Sheets, manuel, WhatsApp) avec dédup par external ID si disponible. Branche confirmation : statuts jusqu’à confirmer ou annulation. Branche livraison : sendToDelivery → tracking → in_delivery → sync polling. Au ramassé, DeliverySaleService déduit le stock. Branche succès : delivered. Branche échec : returned/refused → return_pending_scan → scan entrepôt → validation restaure le stock. Chaque commande ne parcourt qu’un sous-ensemble de ces étapes.
Vue d’ensemble : un cycle non linéaire
Le schéma mental « entrée → livré » oublie annulations, faux numéros, refus à la porte et retours fantômes. Ce workflow liste les étapes possibles ; votre commande s’arrête où son statut le dicte.
| Phase | Statuts / événements clés | Stock |
|---|---|---|
| Ingestion | nouveau, external_order_id si source | Inchangé |
| Confirmation | confirmer, annuler, double_commande, etc. | Inchangé |
| Envoi livraison | tracking, in_delivery, sent_to_delivery_by | Inchangé |
| Ramassé | pickup sync polling | Déduction DeliverySaleService |
| Succès | delivered | Déduit |
| Retour signalé | returned/refused → return_pending_scan | Toujours déduit |
| Retour validé | scan + validation entrepôt | Restauration |
Étape 1 — Ingestion multi-sources
La commande arrive via intégration boutique, import Google Sheets, API ou saisie manuelle. Si la source fournit un identifiant externe, la dédup évite le réimport ; sinon (WhatsApp, manuel) le contrôle humain prévaut.
- Réception ligne / webhook / import.
- Enregistrement articles, client, montant COD.
- Dédup source + external_order_id si applicable.
- Statut initial nouveau — assignation agent possible.
Étape 2 — Confirmation (branche obligatoire avant envoi)
L’agent appelle, corrige téléphone/adresse/ville, note le contexte. Statuts possibles : confirmer (suite livraison), annuler, faux_numéro, double_commande, pas_de_reponse, rappel_plus_tard, etc.
Aucune déduction stock à cette phase — une commande annulée ici ne devrait jamais partir au transporteur.
Étape 3 — Envoi transporteur
sendToDelivery choisit intégration livraison et ville catalogue prestataire. Création colis API → tracking_number. sent_to_delivery_by trace l’agent logistique.
Stock toujours inchangé : le colis n’est pas encore ramassé.
Étape 4 — Sync polling et ramassé
Les statuts remontent par polling (pas via un webhook universel en temps réel). Passage en ramassé/pickup : DeliverySaleService crée la vente liée au tracking et déduit le stock — idempotent si resync.
C’est le moment où stock affiché et sortie transporteur s’alignent en principe.
Branche A — Livraison réussie (delivered)
Client paie le livreur ; statut delivered. Compte dans delivery_rate_pct et COD livré des Insights. Stock reste déduit — vente consommée.
Fin de cycle pour cette branche.
Branche B — Refus ou retour (return_pending_scan)
Transporteur signale refus ou retour → sync polling → return_pending_scan. Stock NON restauré automatiquement.
Colis en transit retour vers entrepôt ou hub — suivi tracking jusqu’à réception physique.
Étape 5 — Retour physique entrepôt (si branche B)
- Réception colis — vérifier tracking.
- Scan session retour dans ERP-STOK.
- Validation — DeliverySaleService restaure stock selon workflow.
- Option échange : nouvel envoi shipment_type exchange, déduction neuf au ramassé du replacement.
- Si colis absent : litige transporteur, pas de validation fictive.
Branches d’arrêt anticipé (courantes)
- annuler / faux_numéro en confirmation — jamais envoyé.
- hors_zone — pas d’envoi transporteur.
- double_commande — une seule ligne expédiée.
- in_delivery bloqué longtemps — succès ou retour incertain.
Exemple fictif
Exemple illustratif (fictif) — trois destins
Même jour, 3 commandes Sheets (fictif). #1 : confirmer → envoi → ramassé → delivered (stock −1 définitif). #2 : faux_numéro en confirmation (stock jamais touché). #3 : confirmer → ramassé (−1) → retour provider → return_pending_scan 5 jours → scan mardi (+1). Aucune des trois n’a parcouru le même chemin complet.
ERP-STOK sur tout le cycle
Ingestion centralisée multi-sources avec external_order_id par intégration.
Confirmation : assignation, statuts, notes — sans impact stock.
Livraison : sendToDelivery, tracking, polling statuts, sent_to_delivery_by.
DeliverySaleService : déduction ramassé, restauration validation retour.
return_pending_scan + scan session pour clore la branche retour.
COD Insights en aval sur cohortes livrées/refusées — pas sur chaque micro-étape.
Pour conclure
Pensez par branches : ingestion → confirmation → envoi → ramassé (stock) → delivered OU retour → scan.
La majorité des erreurs ops viennent d’étapes sautées (envoi sans confirmation, restauration supposée au statut provider).
Limites et points d’attention
- Libellés et délais transporteur variables ; sync polling non instantanée.
- Échanges : support API variable selon prestataire.
- Toutes les branches ne s’appliquent pas à chaque commande.
- Aucune garantie de parcours sans refus ni retour.