# ADR-0010 — Une commande n'a pas de fournisseur

> Date : 2026-08-21
> Statut : `accepted`

## Contexte

Le stock n'avait jusqu'ici que des sorties — les ventes — et des corrections : ajustements, démarques, inventaires. Les entrées existaient dans l'enum, mais rien ne les produisait : quelqu'un tapait « +24 » dans un formulaire, sans qu'aucune trace ne dise pourquoi.

Un stock qui n'a que des sorties n'est pas un stock, c'est un compteur qui descend.

Le module de commandes vient combler ce trou, et il a une seconde raison d'être : l'application sert de support de cours. Commander puis pointer une réception, c'est littéralement le métier qu'on enseigne.

Reste la question qui fait exploser tous les modules de commandes : **jusqu'où va-t-on ?**

Un vrai logiciel de gestion commerciale porte un catalogue par fournisseur, des prix négociés, des conditions de règlement, des minimums de commande, des bons de livraison, des factures, des avoirs, des litiges. C'est cette chaîne-là qui transforme « deux entités » en plusieurs mois de travail — et c'est exactement la sur-ingénierie que le projet s'interdit.

## Décision

**Une commande n'exprime qu'un besoin de marchandise. Elle ne porte aucun fournisseur.**

Ce qu'elle est : une liste de produits, avec une quantité voulue, préparée à partir du cadencier, puis pointée à la réception.

Ce qu'elle n'est pas : un document envoyé à quelqu'un. Personne ne reçoit cette commande. Elle ne quitte jamais l'application. Le vrai bon de commande — s'il existe — se fait ailleurs : au téléphone, dans un caddie de supermarché, sur le site du grossiste.

Concrètement, ce qui est **hors périmètre et le reste** :

- fournisseurs, catalogues et prix d'achat négociés ;
- envoi de la commande par mail ou par un quelconque canal ;
- facturation, règlement, avoirs ;
- délais de livraison, dates promises, relances.

Ce qui entre dans le périmètre : préparer, valider, réceptionner — y compris **partiellement**, parce qu'une livraison incomplète est le cas normal et non l'exception.

## Conséquences

- **+** Le module tient en deux entités et réutilise `StockService` tel quel. Aucune écriture directe sur `Product.stock` : la réception passe des mouvements comme tout le reste.
- **+** La boucle se ferme. Les entrées de stock ont enfin une raison d'être, et le journal des mouvements devient lisible : on sait de quelle commande vient chaque entrée.
- **+** L'exercice pédagogique est intact. Ce que les élèves apprennent — analyser un cadencier, décider une quantité, pointer une réception — ne dépend pas de l'existence d'un fournisseur dans la base.
- **+** Le prix d'achat reste sur le produit, où il est déjà. Pas de second endroit qui pourrait le contredire.
- **−** On ne saura pas ce qu'une commande a coûté au moment où elle a été passée, seulement au prix d'achat courant du produit. C'est le même compromis que la marge dans les statistiques, et il est déjà assumé là-bas.
- **−** Pas d'historique par fournisseur, donc pas de comparaison de prix. Une association scolaire achète au supermarché du coin ; le jour où elle négocie avec un grossiste, cette décision sera à reprendre.
- **−** Rien n'empêche de commander deux fois la même chose sans s'en apercevoir. Le cadencier montre la couverture, ce qui limite le risque, mais ne l'élimine pas.