La date de verrouillage d'Odoo est une date unique, posée au niveau de la société, qui empêche de toucher à ce qui précède. C'est peu : en pratique, une banque se clôture au mois pendant que les ventes restent ouvertes, et le risque n'est pas seulement de modifier le passé — c'est aussi de saisir dans le futur.
Quatorze modules communautaires reprennent le contrôle de la saisie comptable.
Résumé
Quatre modules traitent le verrouillage : par journal indépendamment, une date de verrouillage vers l'avenir empêchant de saisir au-delà, le hachage des pièces imposé et non désactivable sur les journaux de vente, d'achat et d'opérations diverses, et la traçabilité de la date et de l'utilisateur de comptabilisation.
Quatre modules traitent la fiabilité de la saisie : une politique de partenaire par compte — obligatoire, interdit ou optionnel —, le blocage d'une facture quand la position fiscale exige un numéro de TVA absent, la taxe génératrice rendue modifiable sur une ligne en brouillon, et une date d'échéance par défaut égale à la date d'écriture.
Trois modules traitent la numérotation et l'impression : des séquences optionnelles personnalisées par type de pièce, un numéro d'écriture indépendant par journal avec son assistant de renumérotation, et un rapport d'impression de pièce comptable, absent du standard.
Trois modules enfin traitent le travail de clôture : des modèles d'écritures récurrentes, la compensation entre un solde client et un solde fournisseur du même partenaire, et le lettrage des comptes de transit de stock depuis la commande d'achat.
L'essentiel
- Un verrouillage par journal, pas seulement par société.
- Une date de verrouillage vers l'avenir : interdire de saisir au-delà.
- Le hachage des pièces imposé et non désactivable.
- La date et l'utilisateur de comptabilisation tracés sur chaque écriture.
- Le partenaire obligatoire ou interdit selon le compte.
- Une facture bloquée si la position fiscale exige un numéro de TVA absent.
- L'impression d'une pièce comptable, absente du standard.
- La compensation entre solde client et solde fournisseur d'un même tiers.
Ce que ces modules ajoutent à l'instance
| Famille | Modules | Nombre |
|---|---|---|
| Verrouillage | account_journal_lock_date, account_lock_to_date, account_journal_restrict_mode, account_move_post_date_user | 4 |
| Fiabilité de saisie | account_partner_required, account_fiscal_position_vat_check, account_move_line_tax_editable, account_maturity_date_default | 4 |
| Numérotation et impression | account_sequence_option, account_journal_general_sequence, account_move_print | 3 |
| Clôture et lettrage | account_move_template, account_netting, purchase_unreconciled | 3 |
Les menus : Facturation ▸ Comptabilité ▸ Mettre à jour les dates de verrouillage futures, Renumber journal entries, Créer une écriture à partir d'un modèle, et Facturation ▸ Configuration ▸ Comptabilité ▸ Modèles d'écritures.
Verrouiller : par journal, et dans les deux sens
La date de verrouillage unique d'Odoo oblige à choisir entre deux risques : la poser tôt et bloquer les équipes qui travaillent encore sur le mois en cours, ou la poser tard et laisser modifier une banque déjà rapprochée.
account_journal_lock_date lève ce choix : chaque journal se verrouille indépendamment. La banque se clôture dès le rapprochement, les ventes restent ouvertes, les opérations diverses se ferment à l'arrêté.
account_lock_to_date ajoute le mécanisme symétrique : une date de verrouillage vers l'avenir, qui empêche de créer ou de modifier des écritures au-delà. Un assistant dédié met à jour ces dates sous Facturation ▸ Comptabilité ▸ Mettre à jour les dates de verrouillage futures.
Le besoin est réel et peu connu : une facture saisie par erreur à une date de l'année suivante ne réapparaît dans aucun contrôle courant, et se découvre à la clôture.
Le hachage et la traçabilité
account_journal_restrict_mode force l'activation du verrouillage par hachage sur les journaux de vente, d'achat et d'opérations diverses, et empêche de le désactiver. Toutes les pièces de ces journaux sont donc chaînées de façon inaltérable.
account_move_post_date_user (LGPL-3) trace sur chaque écriture la date exacte de sa dernière comptabilisation et l'utilisateur qui l'a comptabilisée. Le standard ne conserve pas cette information séparément de la date d'écriture.
Savoir qui a comptabilisé une écriture, et quand, est la première question d'un contrôle interne — et la première auxquelles la plupart des instances Odoo ne peuvent pas répondre.
Fiabiliser la saisie
account_partner_required ajoute à chaque compte comptable une politique de partenaire : obligatoire, interdit ou optionnel sur les lignes qui utilisent ce compte.
C'est le contrôle qui manque le plus : un compte client sans tiers rend une balance auxiliaire inexploitable, et un compte de charge avec un tiers pollue le lettrage.
account_fiscal_position_vat_checkbloque la validation d'une facture ou d'un avoir client quand la position fiscale appliquée exige un numéro de TVA que le client n'a pas renseigné. C'est le contrôle de l'autoliquidation intracommunautaire : facturer hors taxes sans numéro de TVA valide expose au redressement.account_move_line_tax_editablerend modifiable la taxe génératrice d'une ligne de taxe, sur une écriture en brouillon seulement. Le champ est en lecture seule dans le standard, ce qui bloque la correction d'une reprise ou d'un import.account_maturity_date_defaultpose une date d'échéance par défaut égale à la date d'écriture sur les lignes de comptes clients et fournisseurs non renseignées. Une ligne sans échéance n'apparaît dans aucune balance âgée.
Numéroter et imprimer
account_sequence_option(LGPL-3) définit des séquences de numérotation optionnelles par type de pièce — facture client, avoir, facture fournisseur, paiement, écriture diverse —, en s'appuyant sur un mécanisme générique de séquences.account_journal_general_sequence(LGPL-3) ajoute un numéro d'écriture indépendant, configurable par journal, distinct du numéro natif qui reste la référence légale de la pièce. Il fournit un assistant de renumérotation sous Facturation ▸ Comptabilité ▸ Renumber journal entries.account_move_print(LGPL-3) ajoute un rapport PDF d'impression d'une pièce comptable. Odoo imprime les factures, pas les écritures — ce module comble le manque.
L'impression d'une écriture paraît anecdotique jusqu'au premier contrôle fiscal, où l'on demande la pièce justificative d'une opération diverse. Une capture d'écran n'est pas une pièce.
La distinction entre numéro légal et numéro de séquence interne est importante : renuméroter le premier est une faute, renuméroter le second est un travail d'organisation.
La clôture et le lettrage
account_move_template définit des modèles de pièces comptables réutilisables : une structure fixe de lignes au débit et au crédit, pour générer rapidement des écritures récurrentes — loyers, abonnements, provisions, écritures de clôture. Deux menus : la création d'une écriture depuis un modèle, et le référentiel des modèles.
account_netting permet de compenser le solde d'un compte client avec le solde d'un compte fournisseur pour un même partenaire, en générant l'écriture de contrepartie et en la lettrant avec les lignes d'origine.
La situation est banale dans le négoce et la sous-traitance : le même tiers est client et fournisseur, et les deux soldes restent ouverts jusqu'à ce que quelqu'un passe l'écriture à la main.
purchase_unreconciled ajoute à la commande d'achat un indicateur de lettrage et un mécanisme pour identifier puis lettrer en un clic les écritures non lettrées des comptes de transit de stock.
Les comptes de transit de stock — les comptes interimaires entre la réception et la facture — sont l'endroit où s'accumulent silencieusement les écarts d'un ERP mal réglé. Un solde qui grossit sans explication, année après année, et que personne n'ose solder.
Limites connues
- Le verrouillage par journal s'ajoute au verrouillage global, il ne le remplace pas : les deux mécanismes coexistent et se cumulent.
account_journal_restrict_modeempêche de désactiver le hachage : c'est l'objectif, mais cela ferme aussi la porte à une correction qu'un hachage interdit.- Rendre le partenaire obligatoire sur un compte bloque les imports qui ne le fournissent pas : traiter les reprises avant d'activer.
account_fiscal_position_vat_checkvérifie la présence du numéro de TVA, pas sa validité auprès du service européen : c'est un contrôle de saisie, pas une vérification.- La taxe génératrice modifiable n'est ouverte qu'en brouillon : une écriture comptabilisée reste intouchable, ce qui est correct.
account_nettinggénère une écriture de compensation : son admissibilité juridique dépend du contrat et de l'accord du tiers, pas du module.- La renumérotation d'écritures touche une donnée sensible : la faire sur une base de recette d'abord, et ne jamais la confondre avec le numéro légal de pièce.
Identité technique
Les quatorze modules viennent du dépôt OCA account-financial-tools, branche 18.0. Dix sont en AGPL-3, quatre en LGPL-3. Les dépendances notables : base_vat pour le contrôle de TVA, base_sequence_option pour les séquences optionnelles, account_move_line_purchase_info et purchase_stock pour le lettrage des comptes de transit.
Voir aussi immobilisations, emprunts et charges étalées pour le reste du dépôt.
Questions fréquentes
Peut-on verrouiller un journal comptable sans verrouiller toute la comptabilité ?
Oui : account_journal_lock_date permet un verrouillage par journal, indépendamment de la date globale de société. La banque se clôture dès le rapprochement, les ventes restent ouvertes, les opérations diverses se ferment à l'arrêté. Les deux mécanismes se cumulent.
Comment empêcher une saisie comptable dans le futur ?
account_lock_to_date ajoute une date de verrouillage vers l'avenir, qui bloque la création et la modification d'écritures au-delà, avec un assistant de mise à jour dédié. Une facture saisie par erreur à une date de l'année suivante n'apparaît dans aucun contrôle courant et se découvre à la clôture.
Qui a comptabilisé cette écriture, et quand ?
Le standard ne conserve pas l'information séparément de la date d'écriture. account_move_post_date_user trace la date exacte de la dernière comptabilisation et l'utilisateur qui l'a faite. C'est la première question d'un contrôle interne.
Peut-on rendre le tiers obligatoire sur certains comptes ?
Oui : account_partner_required ajoute une politique de partenaire par compte — obligatoire, interdit ou optionnel. Un compte client sans tiers rend la balance auxiliaire inexploitable ; un compte de charge avec tiers pollue le lettrage. Attention aux imports, qui seront bloqués s'ils ne fournissent pas le tiers.
Odoo sait-il compenser un solde client et un solde fournisseur du même tiers ?
Pas en standard. account_netting génère l'écriture de contrepartie et la lettre avec les lignes d'origine. La situation est banale dans le négoce et la sous-traitance. L'admissibilité juridique de la compensation dépend du contrat et de l'accord du tiers, pas du module.
Se faire accompagner
Le contrôle de la saisie comptable est le seul domaine où ajouter des blocages fait gagner du temps : chaque écriture fausse coûte dix fois plus à retrouver qu'à empêcher. Verrouillage par journal, tiers obligatoire, échéance par défaut, numéro de TVA exigé — quatre réglages, et la balance redevient lisible.
Nous posons ces contrôles avec votre expert-comptable, après avoir traité les reprises qu'ils bloqueraient, et nous vérifions la chaîne de hachage avant de la rendre non désactivable. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
En résumé
La date de verrouillage unique d'Odoo oblige à choisir entre bloquer les équipes et laisser modifier une banque rapprochée. Quatorze modules lèvent ce choix : verrouillage par journal, blocage vers l'avenir, hachage imposé, tiers obligatoire par compte, compensation client-fournisseur. Parlons de vos contrôles comptables.
