Sommaire
Réponse directe
En COD marocain, l’écart stock affiché / physique vient surtout du décalage temporel : ERP-STOK déduit via DeliverySaleService uniquement au ramassé (pickup), pas à la confirmation ni à l’envoi transporteur. Les statuts transporteur « retourné » ou « refusé » ne restaurent pas le stock automatiquement — il faut le flux entrepôt (return_pending_scan, scan session, validation). Ajoutez retards de sync polling, colis en transit non ramassés et erreurs de scan pour expliquer la plupart des écarts observés.
Le problème : chiffres ERP vs comptage entrepôt
Vous comptez 47 pièces en rayon ; ERP-STOK affiche 52, ou l’inverse. En COD, ce décalage est fréquent et coûteux : survente, colis incomplets, ruptures fictives ou relances transporteur inutiles.
Avant de « corriger » manuellement le stock, identifiez la cause : un écart structurel (timing produit) ou une erreur opérationnelle (scan oublié, mauvaise variante).
Cause n°1 — Déduction au ramassé, pas à la confirmation
ERP-STOK ne déduit pas le stock quand un agent confirme la commande, ni au moment du sendToDelivery. La déduction intervient quand le transporteur signale le ramassé (pickup), via DeliverySaleService et le tracking_number.
Conséquence : entre confirmation et ramassé, le stock affiché reste plus élevé que la réalité si vous préparez ou sortez déjà les colis. Entre ramassé et sortie physique, l’inverse peut arriver si la sync polling n’a pas encore remonté le statut.
| Événement | Impact stock affiché |
|---|---|
| Confirmation agent | Aucune déduction |
| Envoi transporteur (tracking créé) | Aucune déduction |
| Ramassé / pickup (sync statut) | Déduction via DeliverySaleService |
| Retour validé entrepôt | Restauration selon workflow retour |
Cause n°2 — Retours transporteur sans validation entrepôt
Quand le prestataire marque un colis « retourné » ou « refusé », ERP-STOK peut passer la commande en return_pending_scan. Le stock n’est pas restauré à ce stade : le colis n’est pas encore contrôlé physiquement.
Tant que la session scan retour et la validation entrepôt ne sont pas faites, le stock affiché reste bas (déduit au ramassé) alors que la pièce n’est pas réellement disponible à la vente — ou le colis est revenu mais non scanné.
- Vérifier la file return_pending_scan avant tout ajustement manuel.
- Croiser tracking_number transporteur et scan entrepôt du jour.
- Ne pas interpréter le libellé « retourné » comme stock disponible immédiat.
Cause n°3 — Sync livraison par polling (décalage temporel)
Les statuts livraison remontent par polling planifié, pas en temps réel via webhooks universels. Un colis ramassé hier peut n’apparaître en ramassé dans ERP-STOK que lors du prochain cycle de sync.
Pendant ce délai, le stock affiché surévalue l’inventaire vendable. Inversement, un retour signalé chez le transporteur peut tarder à basculer en return_pending_scan.
Cause n°4 — Commandes en cours de vie (non ramassées, en transit)
Les commandes confirmées et déjà expédiées (in_delivery) occupent moralement du stock mais ne l’ont pas encore déduit dans ERP-STOK tant que le ramassé n’est pas synchronisé.
Les échanges (shipment_type exchange) ajoutent une seconde ligne de suivi : le neuf se déduit à son propre ramassé ; l’ancien tracking reste lié au flux retour.
Méthode de diagnostic en 5 points
- Exporter ou filtrer les commandes confirmées / in_delivery sans ramassé sync — stock encore « intact » côté ERP.
- Lister return_pending_scan : stock déduit, pièce pas encore validée en retour.
- Vérifier les dernières sync transporteur (délai polling) sur un échantillon de tracking.
- Compter physiquement une variante problématique et comparer au stock ERP + commandes ouvertes sur cette variante.
- Documenter l’écart et la cause probable avant toute correction manuelle de stock.
Ce diagnostic ne promet pas un inventaire zéro écart
ERP-STOK aligne le stock sur des événements traçables (ramassé, validation retour), pas sur une photo instantanée de l’entrepôt. Un écart résiduel peut subsister entre deux sync ou avant scan retour.
Aucun pourcentage d’exactitude inventaire n’est garanti ; l’objectif est de réduire les écarts en respectant le flux produit plutôt qu’en ajustant au feeling.
Exemple fictif
Exemple illustratif (fictif) — écart variante T-shirt M
Stock ERP : 18 unités. Comptage physique : 14. Analyse (fictif) : 2 commandes in_delivery pas encore en ramassé (+2 ERP) ; 1 colis return_pending_scan non scanné (−1 physique) ; 1 ramassé sync retardé de 4 h (−1 ERP pas encore déduit). Après scan retour et prochain polling, l’écart tombe à 1 unité — investigation scan variante L/M sur le poste entrepôt.
Comment ERP-STOK aide à lire l’écart stock
DeliverySaleService déduit au ramassé (pickup) par tracking — pas à la confirmation ni à l’envoi livraison.
return_pending_scan isole les retours signalés transporteur en attente de scan entrepôt ; la restauration stock suit validation, pas le seul statut provider.
Module livraison : filtres in_delivery, return_pending_scan, delivered pour croiser stock et statuts.
Sync statuts transporteur par polling — prévoir un décalage temporel dans vos contrôles inventaire.
Pour conclure
L’écart stock affiché / physique en COD s’explique surtout par le timing : déduction au ramassé, retours non validés et sync polling.
Diagnostiquez avec les files livraison et retour avant d’ajuster manuellement ; alignez l’équipe entrepôt sur return_pending_scan.
Limites et points d’attention
- Le délai exact de sync dépend du transporteur et de la configuration polling du tenant.
- Sans tracking_number, DeliverySaleService ne peut pas appliquer la déduction idempotente.
- Les ajustements manuels de stock hors workflow masquent la cause racine.
- Aucune garantie d’inventaire parfait au centime près.