Statut des commandes clients : facturé, payé, livré — trois badges au lieu d'un

Contexte

Sur une commande client, rien ne distinguait clairement « la facture est partie », « le client a payé » et « la marchandise est livrée » — trois réalités différentes que les vendeurs confondaient parfois (une commande facturée peut très bien ne pas être payée). Le point de départ : reprendre côté ventes un principe déjà posé côté achats (confirmation de paiement fournisseur), avec un cahier des charges préparé à l'avance par Hugo.

Ce qui a été construit

• Trois badges indépendants — Facturation / Paiement / Livraison — au lieu d'un statut fusionné, avec un code couleur : rouge = à traiter côté vendeur, orange = à relancer côté client, vert = réglé.
• Le badge Paiement affiche directement le taux d'acompte reçu (« Acompte 30 % »).
• Le libellé « Reste à encaisser » bascule automatiquement en « Reste à livrer » une fois la commande soldée.
• Les lignes déjà livrées sont grisées et reléguées en fin de liste sur la commande.
• Les mêmes colonnes ajoutées à la vue liste globale « Commandes clients », plus une extension au retrait magasin (statuts « attente retrait » / « retrait OK »).

Ce qui était difficile

Séparer proprement trois notions qui se chevauchent dans les données Odoo (facturé, payé, livré) sans les fusionner artificiellement — et garder la logique cohérente avec le module symétrique déjà en place côté fournisseurs. Au passage, deux bugs de calcul corrigés : le badge se basait sur le prix catalogue au lieu du prix réellement facturé, et un acompte partiel n'était pas reconnu comme « payé ».

Stack

Odoo (vues formulaire + liste sale.order), XML, Python (calculs de statut).

Ce que ça illustre

Un pattern qui se répète chez Cobra : une fois qu'un principe UX fonctionne d'un côté du métier (paiement fournisseur), il se transpose de l'autre côté (paiement client) — et chaque transposition fait remonter des bugs de calcul latents qui traînaient depuis longtemps sans qu'on les voie.