Sommaire
Réponse directe
Quand le transporteur marque un colis retourné ou refusé, ERP-STOK bascule typiquement en return_pending_scan via sync polling — le stock reste déduit (ramassé antérieur) tant que le colis n’est pas scanné et validé en entrepôt. Si le colis n’est pas physiquement revenu, le statut ERP peut avancer avant la réalité : croisez tracking, file return_pending_scan et scan session avant de conclure. DeliverySaleService restaure le stock après validation retour, pas au seul libellé provider.
Le problème : statut « retourné » mais rayon vide
Le tableau de bord livraison affiche retourné ; l’entrepôt n’a jamais reçu le colis. Ou inversement : le colis est là, le stock ERP n’a pas remonté.
Confondre statut transporteur et stock disponible fausse inventaire, réapprovisionnement et litiges avec le prestataire.
Trois niveaux à ne pas mélanger
| Niveau | Signification | Stock ERP |
|---|---|---|
| Statut provider (returned/refused) | Information transporteur synchronisée | Inchangé — toujours déduit si ramassé |
| return_pending_scan | Retour attendu, scan entrepôt requis | Toujours déduit — en attente validation |
| Retour validé (scan + workflow) | Contrôle physique terminé | Restauration via DeliverySaleService / flux retour |
Pourquoi le provider ne restaure pas le stock
La déduction a eu lieu au ramassé (pickup) via DeliverySaleService. Le retour provider est un signal logistique, pas une preuve que la marchandise est contrôlée et remise en vente.
ERP-STOK exige le flux entrepôt : scan session retour, association tracking, validation — seulement alors le stock peut être restauré selon les règles produit.
Sync polling : le statut peut précéder le colis physique
Les mises à jour transporteur arrivent par polling planifié. Un libellé « retourné » peut apparaître dans ERP-STOK avant que le livreur dépose le colis — ou avec retard si le polling tarde.
Ne lancez pas de réclamation stock interne sur le seul statut écran ; vérifiez la file return_pending_scan et le registre réception.
Processus entrepôt : scan session et validation
- Ouvrir la vue retours / return_pending_scan filtrée par ancienneté.
- À réception physique, scanner tracking_number (ou exchange_old_tracking si échange).
- Contrôler état produit (neuf, abîmé, manquant).
- Valider le retour dans la session scan — déclenchement restauration stock selon workflow.
- Si colis absent après délai raisonnable : note ops + litige transporteur, pas de validation fictive.
Cas : colis jamais revenu (retour fantôme)
Commande en return_pending_scan depuis X jours, entrepôt vide. Actions : relance transporteur avec tracking, vérifier adresse retour hub, documenter dans notes commande.
Ne validez pas un scan absent pour « remettre le stock » — vous créeriez un surstock fictif. La restauration doit correspondre à un colis contrôlé.
- Délai d’attente documenté avant escalade transporteur.
- Photo / PV réception si politique interne l’exige.
- Annuler validation erronée via revert parcel si scan incorrect (workflow retour).
Cas : colis revenu mais stock non restauré
Cause fréquente : scan non effectué ou mauvais tracking scanné. Vérifiez que le ramassé initial a bien créé la vente DeliverySaleService — sans vente initiale, la restauration retour ne trouve rien à inverser.
Variante incorrecte scannée = stock restauré sur la mauvaise SKU.
Exemple fictif
Exemple illustratif (fictif) — retour fantôme puis réception
Commande TRK-5541 : ramassé mardi (stock −1). Jeudi polling → return_pending_scan. Vendredi entrepôt : colis absent. Lundi colis arrive sans scan : stock ERP toujours à −1. Mardi scan session → validation → DeliverySaleService restaure +1. Entre jeudi et mardi, le KPI livraison montrait « retourné » mais le stock vendable était faux.
Workflow retour ERP-STOK
Sync statuts livraison par polling → bascule return_pending_scan sur returned/refused provider, sans restauration auto.
Vue retours et scan session pour associer colis physique à commande.
DeliverySaleService : déduction au ramassé, restauration après handleReturn / validation entrepôt.
Revert parcel possible si validation erronée — repasse en return_pending_scan.
Pour conclure
Statut transporteur retourné ≠ stock disponible : le pont est return_pending_scan → scan → validation.
Traitez retours fantômes côté transporteur ; traitez retards de scan côté entrepôt — sans mélanger les deux.
Limites et points d’attention
- Délais et libellés retour varient par transporteur marocain.
- Sync polling — pas de mise à jour instantanée garantie.
- Restauration stock conditionnée au workflow scan/validation réel.
- Pas de garantie que tout colis retourné provider revienne physiquement.