Le bug de stock le plus courant dans la distribution est partout le même, quelle que soit la taille de l'entreprise : traiter le stock réservé comme encore disponible. C'est la cause racine de la survente, de la méfiance de l'équipe d'entrepôt envers l'équipe commerciale, des appels paniqués du samedi matin lorsqu'un chauffeur arrive pour récupérer un produit qui n'est pas là.
Le piège du champ unique
Si votre tableau de stock ne comporte qu'une seule colonne — quantity — vous ne pouvez faire qu'une seule chose : soustraire. Lorsqu'un devis est clôturé, vous soustrayez. Lorsqu'il est annulé, vous réajoutez. Toute livraison concurrente envoie le mauvais nombre.
La cause racine tient au fait qu'un champ unique ne peut pas distinguer le stock physiquement présent du stock promis. Les deux états se confondent dans le même entier. Cela fonctionne dans un système mono-utilisateur où la personne qui soustrait est la même que celle qui sait ce qui est promis. Cela casse dès que deux personnes touchent au système — et cela casse silencieusement. Rien ne lève d'erreur lorsque vous survennez. Le nombre devient simplement négatif, ou pire, il reste positif mais représente une promesse que vous ne pouvez pas tenir.
Deux champs, une propriété
Le système de stock de Quotery utilise deux champs — on_hand et reserved — ainsi qu'un champ dérivé available = on_hand − reserved. Clôturer un devis augmente reserved ; l'annuler le diminue. Seul un bon de livraison validé diminue on_hand. Le calcul tient dans tout scénario concurrent.
La séparation est ce qui rend le tout sûr. on_hand répond à la question « qu'est-ce qui est physiquement dans l'entrepôt ? » reserved répond « qu'est-ce qui est engagé sur un devis clôturé ? » available répond « qu'est-ce que je peux encore promettre au prochain client ? » Chaque champ n'a exactement qu'un seul auteur — on_hand ne change que via des documents de livraison validés ; reserved ne change que via les transitions d'état des devis. Aucun champ n'est touché par deux flux différents, donc il n'y a aucune condition de course.
Cette conception rend également possible la sur-réservation comme un choix délibéré. Lorsqu'un devis se clôture avec un stock disponible insuffisant, reserved peut dépasser on_hand — available devient négatif, ce qui est un signal visible, et non un échec silencieux. L'équipe commerciale le voit et agit en conséquence. La contrainte s'applique au moment de la livraison, pas à celui du devis. Pour en savoir plus sur ce choix, consultez notre article sur les raisons pour lesquelles la sur-réservation est une fonctionnalité.
Grand livre, pas calcul
Chaque changement est écrit dans une ligne StockMovement. Les deux nombres de la fiche de stock sont un cache ; le grand livre est la vérité. Reconstruire n'importe quel instant est une requête, pas une prière.
Le grand livre du stock vous permet de répondre à des questions que les systèmes à champ unique ne peuvent même pas se poser. Quel était le stock disponible de la SKU X mardi dernier à 15h ? Quels devis détenaient des réservations sur ce produit lorsque la réception de stock est arrivée ? Si le on_hand mis en cache venait à diverger de la somme des écritures du grand livre, c'est le grand livre qui fait foi. Vous reconstruisez le cache à partir du journal — vous ne modifiez jamais le journal pour qu'il corresponde au cache.
DHDTech.io