Introduction
Dans Odoo, chaque type d’information métier — commandes, factures, écritures comptables — repose sur des modèles qui organisent la façon dont les données sont stockées et reliées en base. Ces modèles dictent les champs disponibles, les relations entre objets et la logique qui régit le traitement des enregistrements.
Maîtriser les modèles Odoo est indispensable tant pour les développeurs que pour les consultants fonctionnels. Ce sont les fondations de l’architecture des données : ils définissent les champs, les liens entre entités et la logique métier qui va s’exécuter lors des créations, modifications et validations.
Cet article se concentre sur un modèle central de la comptabilité Odoo : account.move. Que vous élaboriez des rapports sur mesure, synchronisiez des systèmes externes ou paramétriez des workflows de facturation, vous le rencontrerez régulièrement.
Qu’est-ce que le modèle account.move
Le modèle account.move correspond aux écritures comptables dans Odoo. Depuis Odoo 13, il regroupe plusieurs usages autrefois séparés : factures clients, factures fournisseurs, avoirs et écritures manuelles — tous sont désormais des enregistrements account.move.
account.move est exploité par le module Comptabilité et constitue le parent des lignes d’écriture (account.move.line) qui détaillent débits et crédits. Une facture, une facture fournisseur ou une écriture manuelle se matérialise par un account.move contenant une ou plusieurs lignes.
La définition de base du modèle se trouve dans le module account ; les autres modules l’étendent via l’héritage Odoo. Par exemple, Sale injecte la logique de création de facture depuis une commande, Purchase celle de génération de bills — chacun ajoute ses besoins sans dupliquer la structure centrale.
Champs essentiels du modèle
Voici les champs clés d’account.move à connaître. Les comprendre facilite la manipulation des factures, des bills et des écritures comptables au quotidien.
1. name
Type : Char. Sert à stocker le numéro ou libellé de l’écriture. Ce champ est généralement rempli automatiquement à partir de la séquence du journal et apparaît dans les listes et documents imprimés.
2. move_type
Type : Selection. Indique le type d’écriture : entry (écriture manuelle), out_invoice (facture client), out_refund (avoir client), in_invoice (facture fournisseur), in_refund (avoir fournisseur). Ce champ oriente les vues et les workflows appliqués.
3. state
Type : Selection. État du workflow : draft, posted ou cancel. Les écritures en brouillon sont modifiables ; une fois postées, elles sont verrouillées et impactent le grand livre.
4. date
Type : Date. Date du document, utilisée pour les rapports, le calcul des échéances et les clôtures. Pour une facture, il s’agit généralement de la date de facturation.
5. journal_id
Type : Many2one (account.journal). Journal auquel appartient l’écriture (Ventes, Achats, Banque, Divers). Le journal contrôle la séquence et les comptes par défaut.
6. company_id
Type : Many2one (res.company). Dans un environnement multi-sociétés, indique à quelle société rattacher l’écriture — impacte la visibilité et la consolidation.
7. partner_id
Type : Many2one (res.partner). Le client ou le fournisseur. Obligatoire pour factures et bills. Utilisé pour le lettrage, les états d’échéance et l’en-tête des documents.
8. currency_id
Type : Many2one (res.currency). Devise de l’écriture. Les montants sont saisis dans cette devise ; pour les rapports multi-devises, la devise de la société sert de référence.
9. amount_total
Type : Monetary. Montant total de l’écriture. Pour une facture, c’est le montant dû. Champ calculé à partir des lignes.
10. amount_residual
Type : Monetary. Montant impayé restant. Pour une facture soldée, il vaut zéro. Utilisé pour le suivi des paiements et les relances.
11. payment_state
Type : Selection. Statut de paiement : not_paid, in_payment, paid, partial, reversed, invoicing_legacy. Sert aux relances automatiques et rapports de trésorerie.
12. line_ids
Type : One2many (account.move.line). Lignes comptables de l’écriture : compte, débit et crédit. La somme des débits doit égaler la somme des crédits pour que l’écriture soit équilibrée.
13. invoice_line_ids
Type : One2many (account.move.line). Pour factures et bills, ce sont les lignes produits/services. Lors du posting, chaque ligne génère une ou plusieurs lignes comptables.
14. invoice_date
Type : Date. Date de la facture, utilisée pour le calcul des périodes fiscales. Elle peut différer de la date de l’écriture selon la configuration.
15. invoice_date_due
Type : Date. Date d’échéance de paiement. Calculée à partir des termes de paiement ou fixée manuellement ; sert au suivi d’échéance et aux relances.
16. ref
Type : Char. Référence externe (numéro fournisseur, référence bancaire). Utile pour rapprocher et réconcilier des documents externes.
17. invoice_origin
Type : Char. Document source (par exemple le numéro de commande). Facilite la traçabilité entre commande et facture.
18. create_date
Type : Datetime. Horodatage de création de l’enregistrement, géré automatiquement par Odoo.
19. write_date
Type : Datetime. Horodatage de la dernière modification, également automatique.
20. narration
Type : Text. Notes internes ou mémo affichés sur les écritures imprimées, mais pas destinés aux clients sur les factures.
21. fiscal_position_id
Type : Many2one (account.fiscal.position). Position fiscale déterminant les règles de taxe selon le partenaire et le pays.
22. invoice_payment_term_id
Type : Many2one (account.payment.term). Conditions de paiement (ex. Net 30) utilisées pour calculer la date d’échéance et répartir les paiements.
23. invoice_user_id
Type : Many2one (res.users). Utilisateur responsable (commercial) de la facture, utile pour les commissions et le reporting commercial.
24. reversed_entry_id
Type : Many2one (account.move). Lien vers l’écriture qui a été annulée ou inversée, ce qui permet de conserver la traçabilité des corrections.
25. to_check
Type : Boolean. Indicateur pour signaler les écritures à contrôler, fréquemment utilisé lors des rapprochements bancaires ou des exceptions.
26. active
Type : Boolean. Drapeau d’archivage. Lorsqu’il est false, l’enregistrement est archivé. Les écritures annulées peuvent être rendues inactives.
27. sequence_number
Type : Integer. Numéro séquentiel du journal servant au tri et à l’affichage, géré par le mixin de séquence.
28. amount_untaxed
Type : Monetary. Sous-total hors taxes. Pour les factures, somme des lignes avant application des taxes.
29. amount_tax
Type : Monetary. Montant total des taxes calculées à partir des lignes de facture et de la configuration fiscale.
30. invoice_source_email
Type : Char. Adresse e-mail source pour les bills créées automatiquement par ingestion d’e-mails, pratique pour l’automatisation des factures fournisseurs.
Utilisations du modèle dans les processus métier
1. Facturation client
Lorsqu’une livraison issue d’une commande de vente génère une facture, Odoo crée un account.move de type out_invoice. Les lignes d’articles proviennent de la commande et, une fois le move posté, les écritures comptables correspondantes sont créées et les comptes clients mis à jour.
2. Factures fournisseurs
Les commandes d’achat peuvent engendrer des bills ou celles-ci sont saisies manuellement. Chaque bill est un account.move de type in_invoice dont le partner_id est le fournisseur ; le posteage met à jour les comptes fournisseurs.
3. Rapprochement des paiements
Les paiements sont affectés aux factures en s’appuyant sur amount_residual et payment_state. Le rapprochement relie les écritures de paiement aux factures et remet à zéro le résiduel lorsque le règlement est effectué.
4. Écritures manuelles
Les comptables créent des moves de type entry pour des ajustements, des provisions ou des corrections. Ils saisissent manuellement les line_ids avec comptes, débits et crédits ; l’écriture doit être équilibrée avant d’être postée.
5. Avoirs et remboursements
Les avoirs sont représentés par des moves de type out_refund ou in_refund et annulent partiellement ou totalement l’effet d’une facture initiale. La liaison reversed_entry_id permet de retrouver l’écriture d’origine pour l’audit.
Comment les développeurs étendent ce modèle
Les développeurs enrichissent account.move selon plusieurs schémas : l’héritage de modèle est la méthode la plus courante.
Héritage de modèle
Déclarez _inherit = 'account.move' pour étendre le modèle : ajouter des champs, redéfinir des méthodes ou ajouter des contraintes. En gardant ces modifications dans un module séparé, on facilite les mises à jour et la maintenance.
Ajouter des champs
Déclarez de nouveaux champs adaptés (Char, Many2one, Boolean, Integer, Text, Selection). Pensez aux champs dépendant de la société pour les environnements multi-entreprises. Pour des champs spécifiques aux factures, restreignez leur affichage via un domain sur move_type.
Extensions Python
Surchargez create, write, _post ou button_draft pour insérer votre logique métier, en appelant super() pour conserver le comportement natif. Faites attention aux champs calculés et à leurs dépendances ; utilisez les décorateurs @api.model et @api.depends pour maîtriser l’exécution.
Odoo Studio
Odoo Studio permet d’ajouter des champs sans coder — pratique pour des adaptations rapides comme un champ de référence supplémentaire. Pour des règles complexes, des validations ou des automatisations robustes, privilégiez un module personnalisé.
Remarque : account.move est un modèle persistant standard, pas un modèle abstrait ni transitoire. Les modèles abstraits servent de modèle et ne créent pas de table ; les modèles transitoires sont temporaires pour les assistants. account.move conserve des données comptables définitives.
Bonnes pratiques
- Filtrez toujours selon move_type lors de la construction de rapports ou d’intégrations : chaque type requiert des champs et comportements différents.
- Utilisez le journal approprié pour chaque type d’écriture : un mauvais choix de journal casse les séquences et fausse le reporting.
- Lors de la création de moves via l’API, assurez-vous que les line_ids sont équilibrées (débits = crédits) avant le posting. Les écritures déséquilibrées seront rejetées par les validations.
- Pour l’import de factures depuis des systèmes externes, mappez correctement vos types de documents vers move_type : out_invoice pour ventes, in_invoice pour achats.
- Préfixez vos champs personnalisés par
x_pour limiter les risques de conflit avec de futures versions d’Odoo.
Erreurs fréquentes
- Poster des écritures non équilibrées : Odoo refusera l’opération. Vérifiez toujours que les totaux débit/crédit correspondent.
- Modifier directement des écritures postées : elles sont verrouillées. Préférez l’annulation et la création d’une nouvelle écriture corrective.
- Oublier d’indiquer partner_id sur les écritures client/fournisseur : cela casse de nombreux rapports et processus de rapprochement.
- Confondre les move_type : un out_refund n’est pas un out_invoice négatif. Utilisez le type approprié pour les avoirs et remboursements.
- Surcharger des méthodes cœur sans appeler
super(): risque de casser d’autres modules et de compliquer les évolutions futures.
Conclusion
Le modèle account.move est au cœur de la comptabilité sous Odoo : il unifie factures, bills et écritures manuelles. Connaître ses champs et la manière dont il est étendu vous permettra de configurer, personnaliser et intégrer Odoo plus sereinement.
Que vous soyez consultant fonctionnel en train de modéliser des processus ou développeur rédigeant des modules sur mesure, une bonne compréhension d’account.move évite beaucoup d’erreurs et de reprises coûteuses.
Besoin d’aide pour votre projet Odoo ?
Dasolo accompagne les entreprises dans l’implémentation, la personnalisation et l’optimisation d’Odoo. Nous sommes spécialisés en intégrations API et développement Odoo, avec une solide expérience de l’architecture des données et des modèles tels qu’account.move.
Si vous souhaitez un accompagnement pour votre déploiement Odoo, des modules personnalisés ou des intégrations, notre équipe est à votre disposition. Demandez une démo pour discuter de votre projet.