Se rendre au contenu

Le modèle purchase.order : Comprendre l'architecture des commandes d'achat d'Odoo

Un guide complet sur le modèle de bon de commande d'Odoo pour les développeurs et les consultants fonctionnels.
11 mars 2026 par
Le modèle purchase.order : Comprendre l'architecture des commandes d'achat d'Odoo
Dasolo
| Aucun commentaire pour l'instant

Introduction


Dans Odoo, les modèles définissent comment les données sont structurées et stockées dans la base de données. Chaque élément de données commerciales avec lequel vous travaillez, des commandes d'achat aux factures en passant par l'inventaire, vit dans un modèle.


Comprendre les modèles Odoo est essentiel tant pour les développeurs que pour les consultants fonctionnels. Les modèles sont la base de l'architecture des données Odoo. Ils définissent les champs Odoo, les relations et la logique commerciale.


Cet article se concentre sur l'un des modèles les plus importants d'Odoo : purchase.order. Que vous construisiez des modules personnalisés, intégriez des systèmes externes ou configuriez des flux de travail d'approvisionnement, vous travaillerez avec ce modèle.

Qu'est-ce que le modèle purchase.order


Le modèle purchase.order représente les commandes d'achat et les demandes de devis (RFQ) dans Odoo. C'est l'endroit central où toutes les transactions d'approvisionnement sont enregistrées avant de devenir des réceptions ou des factures fournisseurs.


Ce modèle dans Odoo est utilisé par le module Achats. Lorsqu'un acheteur crée une RFQ, il crée un enregistrement purchase.order. Lorsque le fournisseur confirme ou que l'acheteur approuve, la commande passe de brouillon à confirmée. Le même modèle dans Odoo contient à la fois des RFQ brouillon et des commandes d'achat confirmées. Le champ état suit le cycle de vie.


D'autres modules étendent ce modèle par le biais de l'héritage de modèle Odoo. L'inventaire ajoute la logique de réception et de prélèvement. La comptabilité ajoute des champs de factures fournisseurs. La fabrication peut créer des commandes d'achat à partir de nomenclatures. Chaque module ajoute ce dont il a besoin sans dupliquer la structure de base.

Champs clés dans le modèle


Voici les champs Odoo les plus importants dans le modèle purchase.order. Comprendre ceux-ci vous aidera à travailler efficacement avec les commandes d'achat.


1. nom

Type : Char. Ce champ stocke la référence de la commande (par exemple, PO00042). Il est généralement généré automatiquement et affiché dans les vues en liste et sur les documents. C'est l'identifiant principal de la commande d'achat.


2. état

Type : Sélection. Suit le cycle de vie de la commande. Valeurs : brouillon (RFQ), envoyé (envoyé au fournisseur), à approuver (en attente d'approbation), achat (confirmé), fait (entièrement reçu et facturé), annulé (annulé). L'état détermine quelles actions sont disponibles.


3. partner_id

Type : Many2one (res.partner). Le fournisseur ou le partenaire. Obligatoire. C'est le contact principal ou l'entreprise pour la commande. Utilisé pour toute la logique et les rapports liés aux fournisseurs.


4. partner_ref

Type : Char. La référence du fournisseur ou le numéro de commande fournisseur. Utilisé lorsque le fournisseur fournit sa propre référence de commande. Affiché sur les documents et aide à faire correspondre les réceptions et les factures.


5. date_order

Type : Datetime. La date de commande. Pour les commandes en brouillon : date de création. Pour les commandes confirmées : date de confirmation. Utilisé pour les rapports, le tri et comme date par défaut attendue pour les lignes de commande.


6. date_approve

Type : Datetime. La date d'approbation ou de confirmation. Définie lorsque la commande passe à l'état d'achat. En lecture seule. Utilisé pour les rapports et les pistes de vérification.


7. order_line

Type : One2many (purchase.order.line). Les lignes de commande. Chaque ligne contient le produit, la quantité, le prix et la taxe. C'est le détail principal de la commande d'achat.


8. amount_untaxed

Type : Float. Le sous-total avant taxe. Calculé à partir des lignes de commande. Utilisé pour les rapports et l'affichage.


9. amount_tax

Type : Float. Le montant total de la taxe. Calculé à partir des lignes de commande en fonction de la configuration fiscale. Affiché sur la commande et la facture du fournisseur.


10. amount_total

Type : Float. Le montant total incluant la taxe. Le montant principal pour la facturation et les rapports.


11. currency_id

Type: Many2one (res.currency). La devise. Généralement héritée de l'entreprise ou du fournisseur. Tous les champs monétaires utilisent cette devise.


12. origin

Type: Char. Le document source. Par exemple, lorsqu'une commande est créée à partir d'une commande de vente (dropship) ou d'une commande de fabrication, le nom de la source est stocké ici. Utilisé pour la traçabilité.


13. dest_address_id

Type: Many2one (res.partner). L'adresse de livraison. Si non définie, par défaut, elle utilise l'adresse de l'entreprise. Utilisé pour le dropshipping lorsque les marchandises vont directement au client.


14. priority

Type: Selection. Priorité de la commande : Normale ou Urgente. Utilisé pour le tri et la mise en évidence. Les commandes urgentes peuvent bénéficier d'un traitement spécial dans les flux de travail.


15. invoice_status

Type: Selection. Suit la facturation : non (non facturé), à facturer (prêt à être facturé), facturé (entièrement facturé). Influence la visibilité de l'action Créer une facture.


16. invoice_count

Type: Integer. Nombre de factures fournisseurs associées. Calculé. Utilisé pour l'affichage et pour ouvrir la liste des factures.


17. invoice_ids

Type: One2many (account.move). Les factures fournisseurs associées. Lien entre les commandes d'achat et la comptabilité. Utilisé pour la correspondance à trois voies et le suivi des paiements.


18. picking_ids

Type: One2many (stock.picking). Les bons de livraison ou réceptions associés. Utilisé lorsque le module d'achat est installé avec l'inventaire.


19. picking_count

Type: Integer. Nombre de réceptions associées. Calculé. Utilisé pour l'affichage et pour ouvrir la liste des réceptions.


20. create_date

Type: Datetime. Stocke la date et l'heure de la création de l'enregistrement. Géré automatiquement par Odoo. Utile pour les rapports et l'audit.


21. write_date

Type: Datetime. Stocke la date et l'heure de la dernière modification. Également géré automatiquement. Aide à suivre quand les données ont été mises à jour pour la dernière fois.


22. notes

Type: Text. Termes et conditions ou notes internes. Peut être affiché sur la commande d'achat. Utilisé pour des instructions spéciales au fournisseur.


23. company_id

Type : Many2one (res.company). Dans les configurations multi-entreprises, cela indique à quelle entreprise Odoo appartient la commande. Affecte la visibilité et l'accès aux enregistrements.


24. user_id

Type : Many2one (res.users). L'acheteur ou l'utilisateur responsable. Utilisé pour les flux de travail d'approbation et l'attribution d'activités.


25. fiscal_position_id

Type : Many2one (account.fiscal.position). La position fiscale pour le mapping des taxes. Appliquée lorsque le fournisseur est dans un pays différent ou a un régime fiscal spécial.


26. payment_term_id

Type : Many2one (account.payment.term). Conditions de paiement (par exemple, Net 30, 50 % d'avance). Utilisé lors de la création de factures fournisseurs.


27. display_name

Type : Char. Nom d'affichage calculé. Combine le nom avec les informations du fournisseur. Utilisé dans les menus déroulants many2one et les résultats de recherche. En lecture seule.


28. active

Type : Boolean. Indicateur de suppression douce. Lorsque Faux, l'enregistrement est archivé et caché des vues par défaut. Les commandes d'achat ne sont pas physiquement supprimées pour préserver l'historique.

Comment ce modèle est utilisé dans les flux de travail commerciaux


1. Demande de prix à commande d'achat

L'acheteur crée une demande de prix (brouillon). Ajoute des lignes, envoie au fournisseur. Le fournisseur confirme ou l'acheteur confirme manuellement. La commande est confirmée (état = achat). Les réceptions et les factures fournisseurs peuvent être créées.


2. Réception fournisseur

Lorsque les marchandises arrivent, l'utilisateur crée une réception à partir de la commande d'achat. Les picking_ids sont liés. Les quantités reçues mettent à jour le stock. Les coûts des produits sont mis à jour à partir du prix d'achat.


3. Facture fournisseur

À partir d'une commande confirmée, les utilisateurs créent des factures fournisseurs. Les lignes de facture sont tirées des lignes de commande. payment_term_id et fiscal_position_id proviennent de la commande. invoice_status suit l'avancement.


4. Dropshipping

Lorsqu'une commande de vente déclenche un achat, l'origine renvoie à la vente. dest_address_id est défini sur l'adresse du client afin que le fournisseur expédie directement. Le modèle purchase.order est le pont entre les ventes et les achats.



5. Fabrication et MRP

Lorsqu'un ordre de fabrication a besoin de composants, il peut créer des commandes d'achat pour les matières premières. Le champ d'origine est lié à l'ordre de fabrication. Ce modèle est central dans le cycle procure-to-pay.

Comment les développeurs étendent ce modèle


Les développeurs étendent purchase.order en utilisant plusieurs modèles. L'héritage de modèle Odoo est le principal mécanisme.


Héritage de modèle

Utilisez _inherit = 'purchase.order' pour étendre le modèle. Ajoutez de nouveaux champs Odoo, remplacez des méthodes ou ajoutez des contraintes. Le modèle hérité dans Odoo conserve vos modifications dans un module séparé pour des mises à jour faciles.


Ajout de champs

Définissez de nouveaux champs Odoo dans votre modèle hérité. Utilisez le bon type de champ : Char, Many2one, Boolean, Integer, Text, Selection. Envisagez des champs dépendants de l'entreprise pour les multi-entreprises.


Extensions Python

Remplacez button_confirm, create ou write pour ajouter de la logique. Utilisez super() pour appeler l'original. Faites attention aux champs calculés et à leurs dépendances.


Odoo Studio

Odoo Studio vous permet d'ajouter des champs sans code. Bon pour des personnalisations rapides. Pour une logique complexe ou des mises à jour, les modules personnalisés sont plus faciles à maintenir. Le modèle API dans Odoo (purchase.order) est entièrement exposé via XML-RPC et JSON-RPC pour les intégrations.

Meilleures pratiques


  • Utilisez l'état correct pour chaque étape. Ne sautez pas d'états ou ne contournez pas la logique de confirmation.
  • Définissez partner_ref lorsque le fournisseur fournit une référence. Cela aide à faire correspondre les réceptions et les factures.
  • Utilisez origin pour tracer la source des commandes d'achat. Essentiel pour le dropshipping et la fabrication.
  • Lors de la création d'intégrations API, utilisez l'API XML-RPC ou JSON-RPC. Le modèle purchase.order est entièrement exposé. Mappez les ID externes avec soin.
  • Pour les champs personnalisés, utilisez le préfixe x_ ou un préfixe de module pour éviter les conflits avec les futures versions d'Odoo.

Erreurs courantes


  • Modifier des commandes confirmées sans vérifier l'état. Les commandes confirmées ont des champs restreints. Créez une nouvelle commande ou utilisez le bon flux de travail.
  • Confondre partner_id et dest_address_id. partner_id est le fournisseur ; dest_address_id est l'endroit où vont les marchandises (pour le dropshipping).
  • Surcharger button_confirm sans appeler super(). Cela peut casser d'autres modules ou des mises à jour futures.
  • Ajouter des champs personnalisés requis sans valeurs par défaut. Les commandes existantes échoueront à la validation lors de la mise à jour.
  • Oublier de définir currency_id lors de la gestion de fournisseurs multi-devises. Une mauvaise devise peut entraîner des coûts et une facturation incorrects.

Conclusion


Le modèle purchase.order est central pour Odoo Purchase. Il stocke les RFQ et les commandes d'achat confirmées. Comprendre ses champs Odoo et comment les modules l'étendent vous aidera à configurer, personnaliser et intégrer Odoo efficacement.


Que vous soyez un consultant fonctionnel cartographiant les processus d'approvisionnement ou un développeur construisant des modules personnalisés, une bonne compréhension de purchase.order vous fera gagner du temps et évitera des erreurs.

Besoin d'aide avec votre implémentation Odoo ?


Dasolo aide les entreprises à mettre en œuvre, personnaliser et optimiser Odoo. Nous nous spécialisons dans les intégrations API et le développement Odoo. Notre équipe a une grande expérience de l'architecture des données Odoo et des modèles comme purchase.order.


Si vous avez besoin d'aide pour votre mise en œuvre Odoo, vos modules personnalisés ou vos intégrations, nous sommes là pour vous aider. Réservez une démo pour discuter de votre projet.

Le modèle purchase.order : Comprendre l'architecture des commandes d'achat d'Odoo
Dasolo 11 mars 2026
Partager cet article
Se connecter pour laisser un commentaire.