Réponse directe
La boutique pousse la commande vers ERP-STOK (webhook ou import). L’équipe confirme téléphone et adresse. Ensuite, un opérateur sélectionne la société de livraison parmi les intégrations configurées et disponibles pour le compte (ex. Truship, Siftly, Coliaty, Rushliv, Speedex) et la ville fournisseur, puis lance l’envoi API. ERP-STOK n’est pas une société de livraison : il transmet le colis au prestataire et suit les statuts par polling.
Les trois acteurs du flux
Boutique (Shopify, Woo, YouCan, Sheet…) : origine de la vente et des données client.
ERP-STOK : file confirmation, préparation envoi, suivi interne, stock au ramassage.
Société de livraison : ramassage, tournée, statuts livré/refus/retour — accès via API du compte marchand.
| Étape | Qui agit | Résultat |
|---|---|---|
| Vente | Boutique | Commande créée |
| Ingestion | ERP-STOK | Commande en file nouveau |
| Confirmation | Agents call center | Statut confirmer |
| Envoi | Opérateur ERP + API transporteur | Tracking créé |
| Suivi | Polling ERP-STOK | Statuts synchronisés |
Configuration transporteur côté tenant
Chaque transporteur est paramétré avec les identifiants API du compte marchand (ex. Truship via API, Siftly, Coliaty, Rushliv, Speedex — selon les intégrations configurées et disponibles pour le compte).
Le catalogue villes fournisseur (delivery_cities) doit être synchronisé : une ville client n’est pas interchangeable avec l’ID ville API d’un autre prestataire.
Moment de l’envoi : après confirmation, pas à l’ingestion
Recevoir une commande boutique ne déclenche pas automatiquement l’expédition. La confirmation COD valide l’intention et les coordonnées.
L’opérateur choisit ensuite le transporteur et la ville — étape manuelle dans le workflow actuel.
- Commande ingérée → statut nouveau.
- Agent confirme → statut confirmer.
- Opérateur ouvre l’envoi livraison, choisit prestataire + ville fournisseur.
- Envoi API → tracking_number enregistré.
- Polling met à jour delivered / returned / ramassé.
Stock et livraison : événements distincts
L’envoi API crée le colis chez le transporteur ; le stock ERP baisse au signal de ramassage (pickup), pas à la confirmation ni au seul clic envoi.
Un retour transporteur déclenche le flux retour entrepôt ; la restauration stock suit le workflow retours, pas le seul statut « refusé » portail.
Exemple illustratif (fictif)
Exemple fictif : commande WooCommerce COD Casablanca. Webhook → ERP-STOK. Agent confirme le créneau. Le responsable logistique envoie via un prestataire disponible sur le compte (ex. Truship) en sélectionnant la ville API correspondante — pas la ville saisie brute client si le mapping l’exige. Tracking créé. Le lendemain, statut ramassé → vente + déduction stock. ERP-STOK n’a jamais livré le colis : le transporteur l’a fait.
Où ERP-STOK s’arrête
ERP-STOK prépare et transmet la demande d’expédition au transporteur configuré, puis agrège les statuts par synchronisation périodique (polling).
Il ne remplace ni la boutique ni le livreur : pas de tournée propre, pas de claim « nous livrons vos colis ».
Pour conclure
Pensez ERP-STOK comme la salle de dispatch COD : il reçoit les commandes boutique, les fait confirmer, puis parle aux APIs transporteur de votre compte. Le colis physique reste du ressort du prestataire choisi.
Limites et points d’attention
- ERP-STOK n’est pas une société de livraison.
- Le suivi repose sur le polling, pas sur une garantie temps réel webhook transporteur.
- Les villes API diffèrent d’un transporteur à l’autre.
- L’envoi post-confirmation reste une action opérateur.