Se rendre au contenu

Le modèle sale.order.line : architecture des lignes de commande Odoo

Guide complet du modèle ligne de commande de vente d’Odoo pour développeurs et consultants fonctionnels — tout ce qu’il faut savoir pour configurer, personnaliser et intégrer les lignes de vente dans vos processus métier.
10 mars 2026 par
Le modèle sale.order.line : architecture des lignes de commande Odoo
Dasolo
| Aucun commentaire pour l'instant

Introduction


Dans Odoo, chaque type d’information métier s’organise autour d’un modèle : c’est la fiche qui définit quelles données on garde, comment elles se relient entre elles et comment on peut les manipuler. Ventes, factures, contacts — tout repose sur ces structures.


Maîtriser les modèles est indispensable, que vous configuriez le système ou que vous développiez des modules. Ce sont eux qui matérialisent la logique métier : champs, liens entre enregistrements et comportements automatisés.


Ici, nous mettons l’accent sur un modèle central du module Ventes : sale.order.line. Que vous prépariez une intégration, développiez un module sur-mesure ou paramétriez des règles tarifaires, vous croiserez forcément ce modèle.

Le modèle sale.order.line en quelques mots


Le modèle sale.order.line correspond à chaque ligne d’un devis ou d’une commande : produit, quantité, tarif et taxes. C’est l’unité de base qui compose un document commercial.


C’est un composant du module sale qui hérite notamment d’analytic.mixin pour le suivi des coûts liés aux projets et des feuilles de temps. Ajouter un produit à un devis crée une ligne sale.order.line.


Le modèle est défini dans le module de ventes, mais d’autres modules viennent le compléter via l’héritage : par exemple, des modules logistiques ajoutent des champs de livraison, d’autres prennent en charge le calcul des marges. Chaque extension enrichit sans recréer la structure de base.

Champs essentiels du modèle


Voici les champs que vous rencontrerez le plus souvent sur une ligne de commande. Les connaître vous permettra de comprendre comment les devis et factures sont construits.


1. order_id

Type : Many2one (sale.order). Obligatoire. Référence vers la commande parente. C’est le lien qui rattache la ligne au document principal ; la suppression de la commande entraîne celle des lignes.


2. sequence

Type : Integer. Valeur par défaut 10. Sert à ordonner l’affichage des lignes (sections, notes, produits) dans le document.


3. company_id

Type : Many2one (res.company). Provenant de order_id. Utilisé pour appliquer les règles multi-sociétés et les contrôles d’accès.


4. currency_id

Type : Many2one (res.currency). Relié via order_id. Sert de monnaie pour tous les montants de la ligne afin d’assurer des calculs cohérents.


5. order_partner_id

Type : Many2one (res.partner). Relié depuis order_id. Représente le client et influence les règles de prix et de taxe.


6. salesman_id

Type : Many2one (res.users). Relié depuis order_id. Identifie le commercial pour la commission et le reporting.


7. state

Type : Selection. Relié depuis order_id. Indique l’état de la commande (brouillon, envoyé, vendu, terminé, annulé) et conditionne l’édition des champs.


8. display_type

Type : Selection. Valeurs possibles : line_section ou line_note. Permet de marquer une ligne comme en-tête de section ou note, sans information produit.


9. is_downpayment

Type : Boolean. Indique si la ligne correspond à un acompte, qui sera facturé séparément.


10. is_expense

Type : Boolean. Vrai quand la ligne provient d’une dépense ou d’une facture fournisseur, utile pour la traçabilité des coûts projet.


11. product_id

Type : Many2one (product.product). Le produit vendu. Le domaine restreint aux produits vendables ; champ requis pour les lignes produit.


12. product_template_id

Type : Many2one (product.template). Calculé à partir de product_id. Utilisé pour la configuration des variantes.


13. name

Type : Text. Description de la ligne, construite à partir du produit et des options choisies, avec les éventuelles informations de variante.


14. product_uom_qty

Type : Float. Quantité commandée. Obligatoire. Valeur par défaut : 1.0. Peut être influencée par l’emballage.


15. product_uom

Type : Many2one (uom.uom). Unité de mesure. Par défaut issue du produit, utilisée pour les calculs de quantité et de prix.


16. tax_id

Type : Many2many (account.tax). Taxes affectées à la ligne, calculées à partir du produit et de la position fiscale.


17. price_unit

Type : Float. Prix unitaire par unité de mesure. Calculé par la grille tarifaire ou le produit, mais modifiable manuellement.


18. discount

Type : Float. Pourcentage de remise appliqué au prix unitaire avant taxes.


19. price_subtotal

Type : Monetary. Sous-total hors taxes, dérivé de la quantité, du prix unitaire et de la remise.


20. price_tax

Type : Float. Montant total des taxes pour la ligne, calculé depuis le sous‑total et les règles fiscales.


21. price_total

Type : Monetary. Total TTC : c’est ce montant qui sert souvent de base pour la facturation.


22. product_packaging_id

Type : Many2one (product.packaging). Emballage optionnel (ex. boîte de 12). Peut influencer la quantité affichée ou saisie.


23. customer_lead

Type : Float. Délai en jours entre la confirmation de la commande et l’expédition, utilisé pour calculer la date de livraison.


24. qty_delivered

Type : Float. Quantité livrée à ce jour. Mise à jour par les mouvements de stock ou manuellement; utile pour la facturation partielle.


25. qty_invoiced

Type : Float. Quantité déjà facturée, calculée à partir des lignes de facture.


26. qty_to_invoice

Type : Float. Quantité restante à facturer, calculée à partir de qty_delivered et qty_invoiced.


27. invoice_status

Type : Selection. États possibles : upselling, invoiced, to invoice, no — indique l’état de facturation de la ligne.


28. invoice_lines

Type : Many2many (account.move.line). Liens vers les lignes de facture issues de cette ligne de vente pour assurer la traçabilité.


29. create_date

Type : Datetime. Date de création de l’enregistrement, gérée automatiquement par Odoo.


30. write_date

Type : Datetime. Date de la dernière modification, utile pour l’audit et le suivi des changements.

Rôle du modèle dans les processus métier


1. Devis et commandes

Lorsqu’un commercial compose un devis, chaque produit ajouté devient une ligne : quantité, prix, remise et total s’affichent. La commande bascule en ‘confirmée’ lorsque le client valide.


2. Tarifs et remises

Les règles de tarification s’appliquent au niveau de la ligne : price_unit et discount sont souvent pilotés par la grille tarifaire (pricelist) pour gérer remises par volume ou conditions client.


3. Livraison et facturation

Les flux de stock mettent à jour qty_delivered. La facturation peut se faire au fur et à mesure des livraisons ou globalement ; invoice_status aide l’utilisateur à savoir ce qui reste à facturer.


4. Projets et services

Pour les services, une ligne peut être reliée à des tâches et feuilles de temps. L’héritage analytic permet de suivre les coûts par projet et d’imputer correctement les dépenses.


5. E‑commerce et portail

Sur le site web, chaque article ajouté au panier devient une ligne de commande lors de la validation. Le configurateur produit s’appuie sur product_template_id et les options choisies.

Comment les développeurs l’étendent


Les développeurs enrichissent sale.order.line via différents patterns, l’héritage de modèle étant le principal levier.


Héritage de modèle

Déclarez _inherit = 'sale.order.line' pour ajouter des champs, redéfinir des méthodes ou ajouter des contraintes. Ce mécanisme permet d’isoler les modifications dans un module afin de faciliter les mises à jour.


Ajout de champs

Définissez des champs Odoo dans votre modèle hérité en choisissant le type adapté : Char, Many2one, Boolean, Integer, Text, Selection. Pensez aux champs dépendant de la société pour les environnements multi‑sociétés.


Extensions Python

Surcharger des méthodes de calcul (ex. _compute_price_unit, _compute_price_subtotal) ou utiliser create/write pour injecter de la logique. Appelez super() pour conserver le comportement existant et faites attention aux dépendances des champs calculés.


Odoo Studio

Odoo Studio permet d’ajouter des champs sans coder — pratique pour des ajustements rapides. Pour des règles complexes ou un maintien long terme, préférez un module personnalisé.

Bonnes pratiques


  • Utilisez display_type pour insérer des sections ou notes plutôt que d’ajouter de fausses lignes produit : ça préserve la qualité des rapports et des contrôles métiers.
  • Pour les intégrations API, créez les lignes dans le contexte de la commande en manipulant order_line_ids sur sale.order avec les commandes appropriées.
  • Respectez les contraintes SQL : une ligne produit doit avoir product_id et product_uom, tandis qu’une ligne de type section/note doit utiliser display_type.
  • Pour une tarification sur mesure, préférez les règles de pricelist lorsque c’est possible. Ne surchargez les compute que si la logique n’est pas réalisable via les pricelists.
  • Pour vos champs personnalisés, préfixez-les par x_ ou par un préfixe lié à votre module afin d’éviter des collisions lors des évolutions d’Odoo.

Pièges fréquents


  • Création de lignes hors contexte de commande. order_id est requis : créez toujours des lignes en lien avec une commande pour éviter des incohérences.
  • Confusion entre product_id et product_template_id. Les lignes produit doivent référencer product_id ; product_template_id sert surtout lors de la configuration et au choix de variantes.
  • Modifier price_unit ou discount après facturation. Si qty_invoiced > 0, changer les prix peut générer des divergences comptables ou des écarts de reporting.
  • Surcharger des méthodes cœur sans appeler super(). Cela peut casser la compatibilité avec d’autres modules ou empêcher de futures mises à jour.
  • Oublier display_type pour une section ou note. Sans ce marqueur, la ligne sera traitée comme produit et échouera aux validations attendues.

Conclusion


Le modèle sale.order.line est au cœur du module Ventes : il enregistre chaque ligne de produit d’un devis ou d’une commande. Bien comprendre ses champs et la manière dont les modules l’étendent facilite la configuration, les développements et les intégrations.


Que vous soyez consultant fonctionnel cartographiant des processus ou développeur implémentant des extensions, une bonne connaissance de sale.order.line évite des heures de débogage et des erreurs opérationnelles.

Besoin d’aide pour votre projet Odoo ?


Dasolo accompagne les entreprises dans la mise en place, la personnalisation et l’optimisation d’Odoo. Nous intervenons sur les intégrations API et le développement, avec une expertise solide sur l’architecture des données et des modèles comme sale.order.line.


Si vous avez besoin d’un accompagnement pour votre implémentation Odoo, la création de modules sur mesure ou vos intégrations, notre équipe peut vous aider. Réservez une démo pour échanger sur votre projet.

Le modèle sale.order.line : architecture des lignes de commande Odoo
Dasolo 10 mars 2026
Partager cet article
Se connecter pour laisser un commentaire.