Aller au contenu

Erreurs à éviter · Erreurs courantes de déduction stock commandes COD

Pièges de déduction stock sur les commandes COD

Éditeur : ERP-STOK 8 min de lecture

Réponse directe

Erreur n°1 : croire que confirmer ou envoyer au transporteur déduit le stock — faux dans ERP-STOK : DeliverySaleService déduit au ramassage (pickup/ramassé) avec tracking et idempotence. Autres pièges : double déduction même tracking, déduction manuelle parallèle, restaurer avant scan retour, ignorer variante/SKU, compter disponible sans tenir compte des commandes en livraison non ramassées.

Piège 1 — Déduire mentalement à la confirmation

Beaucoup d’équipes soustraient « dans leur tête » ou dans un Sheet dès confirmer. ERP-STOK ne le fait pas : le stock système reste disponible jusqu’au ramassage.

Conséquence : rupture affichée en retard, ou sur-stock vendu si vous comptez deux fois (confirmation + ramassage ailleurs).

Piège 2 — Confondre envoi API et sortie magasin

sendToDelivery crée le colis chez le transporteur ; le colis peut encore être à l’entrepôt.

Attendez le statut ramassé/pickup reconnu pour la déduction automatique.

Piège 3 — Tracking manquant ou dupliqué

Sans tracking_number fiable, la chaîne DeliverySaleService ne peut pas idempotenter correctement.

Un même tracking ne doit pas générer deux SaleOrder — le service est conçu pour l’éviter ; ne contournez pas avec des ventes manuelles parallèles.

Erreur Conséquence
Vente manuelle + auto ramassage Double déduction
Pas de tracking Déduction auto absente ou incohérente
Restauration avant scan retour Stock gonflé

Piège 4 — Mauvaise variante ou quantité

Déduction sur SKU/variante de la ligne commande : une erreur à l’ingestion (mauvaise variante confirmée) déduit le mauvais stock au ramassage.

Corrigez les lignes avant envoi transporteur.

Vérité produit (à ne pas contredire)

Confirmation ≠ déduction. Envoi transporteur ≠ déduction. Ramassage/pickup + tracking → DeliverySaleService déduit et crée la vente liée.

Retour validé peut restaurer — selon flux retour entrepôt, pas au seul libellé transporteur.

Exemple illustratif (fictif) — double comptage

Une équipe entre une vente manuelle « sortie stock » dès confirmer, puis ERP-STOK déduit au ramassage → stock négatif sur variante S. Correction : supprimer la pratique manuelle et lire StockMovements / ventes liées tracking.

Garde-fous ERP-STOK

DeliverySaleService : déduction au ramassage/pickup, idempotence sur tracking_number.

Pas de déduction sur statut confirmer ou seul clic envoi transporteur.

Flux retour : scan et validation avant restauration stock.

Lignes commande liées aux variantes pour traçabilité des mouvements.

Pour conclure

Alignez vos habitudes sur le timing réel ERP-STOK : ramassage, pas confirmation.

Évitez ventes manuelles parallèles et restaurations anticipées.

Limites et points d’attention

  • Ce guide liste des erreurs humaines/process — il ne modifie pas DeliverySaleService.
  • Comportement exact selon statuts pickup reconnus par intégration.
  • Pour la théorie timing, voir guide « quand déduire le stock ».

Pages métier liées

Questions fréquentes

Tout ce que vous devez savoir avant de commencer.

Non. La déduction intervient au ramassage/pickup signalé par le transporteur, via DeliverySaleService.
Des mouvements manuels existent selon permissions, mais les cumuler avec la déduction auto au ramassage crée le piège double sortie.
Non automatiquement au libellé seul : le flux scan/validation entrepôt gouverne la restauration.
Pendant 15 jours : confirmez une commande test, envoyez-la, puis observez qu’aucune vente stock n’apparaît avant le statut ramassé — c’est le test décisif.

Stock aligné sur le ramassage

DeliverySaleService et tracking — testez sans double déduction.

Sans engagement · Sans carte bancaire