Sommaire
Réponse directe
Le statut transporteur « retourné » ou « refusé » (sync polling) n’équivaut pas à un retour physique contrôlé en entrepôt : ERP-STOK bascule typiquement en return_pending_scan en attendant scan puis validation. Une journée retours/échanges combine suivi transporteur, scan entrepôt (tracking ou exchange_old_tracking), validation stock, et parfois un nouvel envoi shipment_type exchange. Coordination confirmation ↔ logistique via notes. Support échange variable par transporteur. Voir aussi le guide « retour signalé transporteur pas en stock ».
Règle de base : statut provider ≠ retour physique validé
Quand le transporteur marque un colis retourné, refusé ou en retour, ERP-STOK synchronise cette information — mais le stock reste déduit (ramassage antérieur) tant que le colis n’a pas été scanné et validé en entrepôt.
return_pending_scan signifie « retour attendu, vérification scan requise » : le colis peut être encore en transit retour, pas encore réceptionné, ou déjà là sans scan.
Ne confondez pas l’avancement du KPI livraison (libellé provider) avec la disponibilité stock vendable — ce sont deux niveaux distincts.
| Signal | Ce que ça veut dire ops | Stock ERP |
|---|---|---|
| Libellé provider returned/refused | Information transporteur synchronisée | Inchangé si déjà déduit au ramassé |
| return_pending_scan | Retour en attente de scan entrepôt | Toujours déduit — pas encore restauré |
| Scan + validation entrepôt | Contrôle physique terminé | Restauration selon workflow retour |
Scan puis validation : la séquence obligatoire
Le flux entrepôt est en deux temps : d’abord le scan (association colis physique ↔ commande via tracking_number ou exchange_old_tracking), puis la validation qui déclenche la restauration stock via DeliverySaleService.
Sauter le scan ou valider sans colis présent crée un stock fictif. Valider au seul statut portail transporteur sans contrôle physique est la même erreur.
Si le colis n’est jamais revenu malgré le statut provider, documentez et escaladez transporteur — ne validez pas un scan absent (voir guide retour signalé sans stock).
- Repérer la commande en return_pending_scan (file retours).
- À réception physique, scanner tracking_number ou exchange_old_tracking.
- Contrôler état produit (neuf, abîmé, manquant).
- Valider dans la session scan — restauration stock selon règles produit.
Matin : file return_pending_scan
Les commandes en return_pending_scan attendent vérification physique : le transporteur signale un retour en route ou arrivé, le colis n’est pas encore validé en entrepôt.
Priorisez par ancienneté et montant COD pour libérer stock et trésorerie.
- Ouvrir la vue retours / return_pending_scan.
- Croiser avec tracking_number transporteur.
- Préparer poste scan entrepôt.
Scan et validation entrepôt
Le scan retour associe le colis physique à la commande (tracking_number ou exchange_old_tracking pour les échanges).
La validation — distincte du scan — déclenche la restauration stock. Le simple statut transporteur « retourné » ne suffit pas.
Après validation, le workflow stock restaure selon les règles produit — distinct du libellé provider synchronisé par polling.
Échange client : création du remplacement
Confirmer avec le client le nouvel article/variante par téléphone si besoin.
Créer envoi shipment_type exchange avec exchange_old_tracking / exchange_old_order_id.
Vérifier que le transporteur choisi supporte l’échange (champs API selon intégration — ex. package_old_tracking chez Coliaty, contexte exchange chez Truship si disponibles sur le compte).
Nouveau colis → suivi ramassage → déduction stock du neuf au pickup.
Coordination équipe
Confirmation note « échange taille L demandé » ; logistique crée l’envoi exchange.
Évitez double traitement : une commande en retour ne doit pas recevoir un second envoi normal par erreur.
| Situation | Action ops |
|---|---|
| Retour simple | Scan → validation → clôture |
| Échange | Retour ancien + envoi exchange lié |
| Refus sans retour physique | Suivre statut transporteur, pas de scan |
Exemple fictif
Exemple illustratif (fictif) — journée retours
9h : 12 colis return_pending_scan. Entrepôt scanne 8 trackings, 4 manquants → relance transporteur. 11h : client demande échange sur commande livrée — agent note, manager crée exchange lié tracking d’origine, envoi via un prestataire configuré. 16h : ramassage nouveau colis → déduction variante neuve. Ancien colis scanné le lendemain → restauration.
Modules ERP-STOK retours / échanges
delivery_status returned et return_pending_scan pour piloter la file retours.
Écrans scan retour avec résolution tracking / exchange_old_tracking.
shipment_type normal vs exchange à l’envoi, avec contrôle de réutilisation ancien tracking.
DeliverySaleService : déduction neuf au ramassage ; restauration après validation retour.
Pour conclure
Retours et échanges demandent une routine : file pending scan → entrepôt → validation, plus branche exchange si remplacement.
Séparez ops quotidien (ce guide) et règles stock (guide échange dédié).
Limites et points d’attention
- Support échange non universel entre transporteurs.
- Ce guide ne remplace pas le guide intégrité stock des échanges.
- Délais retour dépendent du carrier et du réseau.