Tronc commun · Achats · Chantier A1
Le bon de livraison, lu puis rapproché.
Un document, deux produits, une même discipline. Le BL devient une pièce à part entière : l'OCR en extrait les lignes, le moteur les rapproche à la commande, l'opérateur valide avant que le stock ne bouge. Conçu pour le tronc, instancié dans Anim'Gest puis Cockpit'Gest.
Note de l'éditeur
Cette note traite le bon de livraison comme un concept commun aux deux produits. Le cœur — lire, rapprocher, valider — est agnostique et vit dans le tronc ; seuls le mapping et le branchement diffèrent d'un produit à l'autre. On cadre une fois, on instancie deux fois.
L'intention
Le bon de livraison passe d'une trace implicite à un document source, dans les deux produits.
Quand un fournisseur livre, il joint un bon de livraison qui liste ce qui est réellement arrivé. Aujourd'hui, ni Anim'Gest ni Cockpit'Gest ne gèrent le BL comme une pièce : la réception est saisie à la main. A1 introduit le BL comme document lu par la machine : on le photographie ou on l'importe, l'OCR en extrait les lignes, et un moteur propose à quelle commande il correspond.
L'opérateur voit le rapprochement proposé, le corrige si besoin, et le valide. Ce n'est qu'à cette validation que la réception — et donc l'entrée de stock — est générée. La machine prépare ; l'humain engage. Le même principe, la même brique, pour les deux produits.
Les deux produits
Même concept, deux points de départ. L'INV de chaque côté confirmera l'existant.
Anim'Gest · premier
Terrain le plus riche
Anim'Gest porte déjà un flux fournisseur et un pipeline OCR (constaté sur les chèques). Le BL s'y grefferait sur l'existant.
- Commande fournisseur présente (à confirmer INV)
- OCR déjà en place (à réutiliser)
- Attention : compta en procédure stockée opaque
Cockpit'Gest · second
Socle Achats récent
Cockpit'Gest a livré commande + réception + stock (C4). Le BL s'insère en amont de la réception existante.
- Commande / réception / stock livrés
- Moteur Eliot agnostique disponible
- Compta versionnée, hors procédure stockée
Le flux (partagé)
Quatre temps, identiques dans les deux produits.
1. Capture — le BL est importé (photo/PDF). 2. Extraction — l'OCR lit les lignes (référence, quantité livrée) et l'entête (fournisseur, date, numéro BL fournisseur). 3. Rapprochement — le moteur propose la commande et associe chaque ligne du BL à une ligne de commande. 4. Validation — l'opérateur confirme ou ajuste ; le BL validé génère la réception.
Les variantes à couvrir
Un BL n'est pas toujours simple. Le cadrage prévoit :
| Cas | Description | Effet |
|---|---|---|
| BL simple | Un BL couvre une commande, quantités complètes | Réception totale |
| BL partiel | Le BL ne livre qu'une partie de la commande | Reste attendu |
| Multi-BL | Plusieurs BL pour une même commande (livraisons échelonnées) | Cumul progressif |
| Bon de retour | Marchandise renvoyée au fournisseur (total/partiel) | Contre-passe stock |
Le multi-BL sur plusieurs commandes (un BL couvrant des lignes de commandes différentes) est le cas le plus complexe. Reco : le sortir de la v1 (P1), pour ne pas alourdir le rapprochement initial. À confirmer selon le besoin réel de chaque produit.
Ce qui est tronc, ce qui est produit
La frontière d'extraction, posée dès le cadrage :
Tronc commun
Se lève tel quel
- Modèle BL + lignes (concept agnostique)
- Moteur de rapprochement BL → commande
- Cœur OCR Eliot (extraction)
- Écran de rapprochement (générique)
Produit
Se réinstancie
- Adaptateur OCR → BL (mapping produit)
- Branchement à la réception du produit
- Conventions de nommage / préfixes
- Archivage GED propre au produit
Règles de gestion
- Validation manuelle — le rapprochement proposé par l'OCR n'engage rien ; seule la confirmation de l'opérateur génère la réception et l'entrée de stock. Vrai dans les deux produits.
- Rapprochement traçable — chaque ligne de BL est liée à une ligne de commande ; on sait toujours quel BL a servi quelle ligne, en quelle quantité.
- Cohérence quantités — la quantité livrée cumulée ne peut dépasser la commande sans alerte ; le sur-livré est signalé, jamais écrit en silence.
- Snapshot — les lignes de BL figent référence et libellé à la réception (immuables ensuite).
- OCR isolé — le cœur d'extraction reste agnostique (tronc) ; le mapping vers le BL de chaque produit vit dans l'adaptateur.
- Retour = contre-passation — un bon de retour génère un mouvement de stock inverse traçable, jamais une suppression du mouvement d'origine.
INV préalable — bloquant des deux côtés
On constate avant de concevoir — dans chaque produit, séparément.
Deux inventaires read-only, un par produit, à mener avant tout build. Ils partagent les mêmes questions, mais chaque base a son existant.
INV Anim'Gest
Dans le projet dédié
- Commande / réception existantes ?
- OCR : le pipeline existant est-il réutilisable ?
- GED : archivage d'un upload ?
- Compta : impact procédure stockée
INV Cockpit'Gest
CC-READ, base de dev
- Réception actuelle : structure, compteurs
- Couplage BL / réception : seul chemin ou coexistence ?
- Point de greffe OCR (Eliot)
- GED, numérotation du BL
Chaque RECAP recalera le modèle (section 05) pour son produit et tranchera le couplage BL / réception. Aucun build avant ces constats.
Un maillon commun, instancié deux fois.
A1 pose le bon de livraison comme document source : lu par la machine, rapproché automatiquement, validé par une personne avant que le stock ne bouge. Conçu tronc, il se lève une fois et s'instancie dans les deux produits — et sert de fondation à A2, la facture d'achat, qui ne se rapproche qu'à des BL qui existent.