Amisferme · machine à remonter le stock

—zoomtoutvitesse

barre FOURNISSEUR = commande (colis) → prépa J+2 → ● réception → auto-validée ✓ (verte en mode Correct = à re-commander) barres CLIENTS = cycle de vie par commande (réservé → expédié → livré ● → auto-validé ✓) rail fin sous une commande client = marchandise physiquement disponible → livraison client gris / hachuré = demande client non reliée à une réception fournisseur réelle bande ● (reçu/livré) → ✓ (scellé) = délai d'auto-validation : la marchandise a bougé, mais le ledger n'est crédité/décrémenté qu'au cron 12:01 suivant ligne LEDGER = stock : onHand scellé / physique / dispo · la bande ambre (reçu, pas scellé) et rouge (fantôme) = le décalage physique↔ledger, dans les deux modes bande rouge = fantôme (Actuel) · bande verte = stock détenu (Correct) contour ambré tireté (mode Actuel) = sur ce créneau configuré, le moteur prod commande une autre quantité que celle persistée. Survolez la barre. Là où il n'y a pas de stock (Baron), moteur et réel coïncident à 95%. boîte ambrée vide « moteur N » = créneau configuré où le moteur commande N colis et où aucun bon fournisseur n'existe. C'est le signal le plus exploitable, mais il reste à confirmer créneau par créneau : le rejeu propose aussi des bons sur des créneaux déjà passés, ce qu'aucun cron ne pourrait envoyer. barre grise « annulé » = bon au statut CANCELLED : jamais envoyé, jamais réceptionné, non compté comme réel, aucun crédit de stock. Ne les lisez pas comme des commandes perdues : sur cette fenêtre, ce sont des brouillons rétro-datés (créés après leur propre date d'envoi) qu'un nettoyage unique du 19/06 a annulés en bloc. curseur bleu = T (glissez / lecture)

Ce qu'il se passe Le fantôme, pas à pas

La cadence roulante garantit la panne : un client dont la date de livraison tombeentre deux réceptions fournisseur est servi alors que Product.stock = 0. Le cron d'auto-validation décrémente alors max(0, 0 − 1) = 0 : la consommation est silencieusement perdue. La réception qui couvrait ce client arrive plus tard et ajoute +N de stock… sans rien à compenser.

Ce qu'on a aujourd'hui (mode Actuel)

Actuel = production persistée : commandes fournisseur, commandes client et StockActions telles qu'elles ont été écrites par l'app de production actuelle, avec ses crons, son recalcul temps réel, son reconcile et ses garde-fous.
L'auto-validation SCELLE le mouvement, elle ne le constate pas à l'instant physique : la marchandise est reçue / livrée, mais le ledger n'est crédité / décrémenté qu'au cron 12:01 suivant (sur les barres : ● reçu/livré → ✓ scellé). Ce décalage est la fenêtre où le réappro lit un stock faux.
Réception : stock += N, sans plafond, sans annuler le réservé-entrée.
Livraison client : stock = max(0, stock − q), bridée à 0, la sortie est perdue.
Réception validée après les clients qu'elle sert (une CF couvre une fenêtre de dates).
Résultat : stock fantôme (onHand > stock réel) soustrait de l'envoi Baron suivant → sous-commande.
Passe l'audit I1 à I5 : stock == ledger == la valeur fantôme, invisible aux garde-fous existants.

Ce que ça devrait être (le correctif)

Enregistrer le stock au mouvement PHYSIQUE : créditer à la réception (arrivée), décrémenter à la livraison, pas au scellé du cron 12:01, et sans bridage à 0. Le ledger colle alors au réel : plus de décalage, plus de fantôme.
Σ réceptions − Σ livraisons = stock réel, toujours. Le clamp à 0 disparaît, le fantôme devient impossible.
Commander en colis entiers, net du stock : ceil((demande − stock) / pkg) colis, dimensionné pour couvrir chaque cycle. On ne peut pas commander 4 melons quand le colis en fait 15.
Résultat (mode Correct) : le stock physique oscille dans une petite bande, jamais de rupture, jamais de fantôme. Seul reste le reliquat d'arrondi colis : nul sur la viande (colis = 1), un léger surstock sur le primeur (colis de 6/12/18).

Les deux modes Ce qu'on mesure, ce qu'on corrige

● Actuel · prod persistée

Le mode Actuel n'est pas une hypothèse : il repart des vraies commandes fournisseur et des vrais StockActions de production.
Le ledger est rejoué depuis ces StockActions : la ligne blanche onHand (bridée ≥ 0) contre la ligne verte correct (le stock physique, qui plonge en négatif).
La bande rouge entre les deux = le fantôme accumulé.
La lecture « prochain envoi » montre comment ce fantôme rétrécit la commande Baron suivante (demande − stock affiché au lieu de demande − stock réel).
On mesure le dégât : sous-commande, dette masquée, ruptures.

● Correct · cible à atteindre

Le ledger enregistre au mouvement physique (réception / livraison, sans bridage), et chaque envoi est arrondi au colis entier, net du stock : ceil((demande − stock)/pkg) colis.
Barres vertes = les colis qu'il faudrait commander ; « réel N » = ce qui a réellement été envoyé ; « — rien » = cycle couvert par le stock.
Le stock physique oscille dans une petite bande, jamais négatif, jamais gonflé : pas de rupture, pas de fantôme, pas de dérive. Seul reste le reliquat d'arrondi colis (nul sur la viande, un peu de surstock sur le primeur).
C'est la cible : le comportement sur lequel s'aligner une fois le correctif en place.

Les chemins Processus modélisés dans la scène

La scène relie les flux réellement séparés dans le code :P1/P2 génération roulante des commandes fournisseur (cron 30 min + reconcile 07:15) → réservé-entrée ;P1 intake client (sync PrestaShop) → réservé-sortie ;P3 auto-validation réception (date prévue + 12 h) ;P4 auto-validation livraison client (date livraison + 12 h, avec le bridage) ;P5 le ledger (Product.stock + stockLedger). Le détail complet, les diagrammes Mermaid avant/après et la liste des correctifs + tests sont dans docs/stock/2886-rolling-stock-model.md.