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 de vente aux factures en passant par les contacts, 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, les relations et la logique commerciale.
Cet article se concentre sur l'un des modèles les plus importants d'Odoo : sales.order. Que vous construisiez des modules personnalisés, intégriez des systèmes externes ou configuriez des flux de travail de vente, vous travaillerez avec ce modèle.
Qu'est-ce que le modèle sales.order
Le modèle sales.order représente les devis et les commandes de vente dans Odoo. C'est l'endroit central où toutes les transactions de vente sont enregistrées avant qu'elles ne soient facturées ou livrées.
Ce modèle dans Odoo est utilisé par le module Ventes.
Lorsqu'un vendeur crée un devis, il crée un enregistrement sales.order. Lorsque le client confirme, la commande passe de brouillon à confirmée. Le même modèle dans Odoo contient à la fois des devis brouillons et des commandes 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. Le CRM relie les opportunités aux commandes. La comptabilité ajoute des champs de facture. L'inventaire ajoute des dates de livraison et d'engagement. 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 sales.order. Comprendre ceux-ci vous aidera à travailler efficacement avec les devis et les commandes.
1. nom
Type : Char. Ce champ stocke la référence de la commande ou le numéro de devis. Il est généralement auto-généré (par exemple, S00042) et affiché dans les vues en liste et sur les documents. C'est l'identifiant principal de la commande.
2. état
Type : Sélection. Suit le cycle de vie de la commande. Valeurs : brouillon (devis), envoyé (devis envoyé au client), vente (commande confirmée), fait (entièrement livré et facturé), annulé (annulé). L'état détermine quelles actions sont disponibles.
3. partner_id
Type : Many2one (res.partner). Le client. Requis. C'est le contact principal ou l'entreprise pour la commande. Utilisé pour toute la logique et les rapports liés aux clients.
4. partner_invoice_id
Type : Many2one (res.partner). L'adresse de facturation. Si non définie, elle par défaut à partner_id. Utilisez ceci lorsque l'adresse de facturation diffère du contact principal (par exemple, facturation centralisée).
5. partner_shipping_id
Type : Many2one (res.partner). L'adresse de livraison. Si non définie, elle par défaut à partner_id. Utilisé pour les commandes de livraison et les calculs d'expédition.
6. user_id
Type : Many2one (res.users). Le vendeur ou l'utilisateur responsable. Utilisé pour la gestion de la relation client, les commissions et l'attribution d'activités. Souvent défini à partir de l'équipe de vente ou de l'opportunité.
7. team_id
Type : Many2one (crm.team). L'équipe de vente. Regroupe les vendeurs et alimente les rapports. Utilisé pour les tableaux de bord et les quotas basés sur l'équipe.
8. date_order
Type : Datetime. La date de la commande. Pour les commandes brouillon : date de création. Pour les commandes confirmées : date de confirmation. Utilisé pour les rapports et le tri.
9. validity_date
Type : Date. La date d'expiration du devis. Après cette date, le devis peut devenir invalide. Utile pour les offres à durée limitée.
10. commitment_date
Type : Date/heure. La date de livraison promise. Lorsqu'elle est définie, les commandes de livraison sont programmées en fonction de cette date plutôt que des délais de production. Important pour les engagements envers les clients.
11. ligne_de_commande
Type : One2many (sale.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.
12. montant_non_imposable
Type : Flottant. Le sous-total avant taxe. Calculé à partir des lignes de commande. Utilisé pour les rapports et l'affichage.
13. montant_taxe
Type : Flottant. 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.
14. montant_total
Type : Flottant. Le montant total y compris la taxe. Le montant principal pour la facturation et les rapports.
15. id_devise
Type : Many2one (res.currency). La devise. Généralement héritée de l'entreprise ou de la liste de prix. Tous les champs monétaires utilisent cette devise.
16. id_liste_de_prix
Type: Many2one (product.pricelist). La liste de prix utilisée pour la commande. Détermine les prix unitaires sur les lignes. Peut être définie à partir du partenaire ou manuellement.
17. 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.
18. fiscal_position_id
Type: Many2one (account.fiscal.position). La position fiscale pour le mapping des taxes. Appliquée lorsque le client est dans un pays différent ou a un régime fiscal spécial.
19. client_order_ref
Type: Char. La référence client ou le numéro de bon de commande. Utilisé lorsque le client fournit sa propre référence de commande. Affiché sur les documents et dans les rapports.
20. origin
Type: Char. Le document source. Par exemple, lorsqu'une commande est créée à partir d'une opportunité, le nom de l'opportunité est stocké ici. Utilisé pour la traçabilité.
21. 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.
22. write_date
Type: Datetime. Stocke la date et l'heure de la dernière modification. Géré automatiquement. Aide à suivre quand les données ont été mises à jour pour la dernière fois.
23. note
Type: Texte. Termes et conditions ou notes internes. Peut être affiché sur le devis et la facture. Utilisé pour le texte légal ou les instructions spéciales.
24. require_signature
Type: Booléen. Lorsque True, le client doit signer en ligne avant que la commande ne soit confirmée. Utilisé pour les flux de commerce électronique et de portail.
25. require_payment
Type: Booléen. Lorsque True, le paiement est requis avant la confirmation. Utilisé pour les commandes prépayées ou basées sur un dépôt.
26. invoice_status
Type: Sélection. Suit la facturation : non (non facturé), à facturer (prêt à être facturé), facturé (entièrement facturé), ou upsell (lignes supplémentaires à facturer).
27. locked
Type: Booléen. Lorsque True, la commande ne peut pas être modifiée. Défini automatiquement lorsque la commande est confirmée ou lorsque des documents connexes sont publiés.
28. company_id
Type: Many2one (res.company). Dans les configurations multi-entreprises, cela indique à quelle entreprise Odoo la commande appartient. Affecte la visibilité et l'accès aux enregistrements.
29. tag_ids
Type: Many2many (crm.tag). Étiquettes pour la catégorisation. Utilisées pour le filtrage, le reporting et la segmentation. Flexibles pour des workflows personnalisés.
30. signed_by
Type: Char. Nom de la personne qui a signé la commande lorsque require_signature est utilisé. Stocké pour audit.
31. signed_on
Type: Datetime. Date et heure de la signature. Utilisé lorsque la signature est requise pour la confirmation.
32. prepayment_percent
Type: Float. Le pourcentage de la commande qui doit être payé en tant qu'acompte. Utilisé avec require_payment pour les commandes basées sur des dépôts.
Comment ce modèle est utilisé dans les flux de travail commerciaux
1. Devis à Commande
Le vendeur crée un devis (brouillon). Ajoute des lignes, fixe des prix, envoie au client. Le client confirme. La commande est confirmée (état = vente). Des factures et des bons de livraison peuvent être créés.
2. E-commerce et Portail
Les clients passent des commandes sur le site web. Les commandes sont créées en tant qu'enregistrements sales.order. require_signature et require_payment peuvent imposer un paiement en ligne ou une signature avant la confirmation.
3. CRM vers Ventes
Lorsqu'une opportunité est gagnée, un devis est créé à partir de celle-ci. Le champ d'origine renvoie à l'opportunité. user_id et team_id pilotent les rapports de vente et les commissions.
4. Facturation
À partir d'une commande confirmée, les utilisateurs créent des factures. Les lignes de factures sont tirées des lignes de commande. payment_term_id et fiscal_position_id proviennent de la commande. invoice_status suit l'avancement.
5. Livraison et Engagement
commitment_date détermine la planification des livraisons. Lorsqu'il est défini, les commandes de livraison sont planifiées autour de cela. partner_shipping_id définit l'adresse de livraison.
Comment les développeurs étendent ce modèle
Les développeurs étendent sales.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 = 'sale.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. Considérez les champs dépendants de l'entreprise pour les multi-entreprises.
Extensions Python
Surchargez action_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 maintenables.
Meilleures pratiques
- Utilisez l'état correct pour chaque étape. Ne sautez pas d'états ou ne contournez pas la logique de confirmation.
- Définissez commitment_date lorsque le client a une date promise. Cela améliore la planification des livraisons.
- Utilisez commercial_partner_id lorsque vous avez besoin de l'entité de niveau supérieur pour le regroupement (par exemple, pour le crédit ou le reporting).
- Lors de la création d'intégrations API, utilisez l'API XML-RPC ou JSON-RPC. Le modèle sales.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 les verrouillages. Les commandes verrouillées ne peuvent pas être modifiées. Créez une nouvelle révision ou utilisez le bon flux de travail.
- Confondre partner_id, partner_invoice_id et partner_shipping_id. Chacun a un but distinct. Définissez les trois lorsque les adresses diffèrent.
- Surchargez action_confirm sans appeler super(). Cela peut casser d'autres modules ou des mises à jour futures.
- Ajout de champs personnalisés requis sans valeurs par défaut. Les commandes existantes échoueront à la validation lors de la mise à niveau.
- Oublier de définir pricelist_id lorsque la devise ou la tarification diffère de la valeur par défaut. Des prix incorrects peuvent entraîner une facturation erronée.
Conclusion
Le modèle sales.order est central pour Odoo Sales. Il stocke les devis et les commandes confirmées. Comprendre ses champs et comment les modules l'étendent vous aidera à configurer, personnaliser et intégrer Odoo efficacement.
Que vous soyez un consultant fonctionnel cartographiant les processus de vente ou un développeur construisant des modules personnalisés, une bonne compréhension de sales.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 de modèles comme sales.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.