1. Pourquoi chaque société porte son propre plan comptable

Une fois plusieurs sociétés créées (cf. l'article ADM·1), chaque entité juridique a besoin de tenir sa propre comptabilité. Cela suppose un plan comptable distinct — autrement dit une grille de comptes propre à la société, avec son propre référentiel fiscal et ses propres taxes. Odoo 19 modélise tout cela au niveau res.company :

• account.account — chaque ligne du plan est rattachée à une (ou plusieurs) sociétés via company_ids.
• account.journal — chaque journal appartient à une seule société (champ company_id M2o).
• account.tax — pareil, company_id M2o.
• res.company porte la configuration comptable : exercice fiscal, taxes par défaut, devises, verrous de date.

Conséquence pratique : une facture émise depuis la société active n'utilise jamais les comptes ou les journaux d'une autre société du groupe. La règle d'enregistrement globale company_id in user.company_ids (cf. ADM·2 §5) ferme la porte côté ORM, et l'isolation des journaux ferme la porte côté UI.

2. Rattacher une société à sa localisation fiscale

En Odoo 19, le plan comptable d'une société n'est plus un enregistrement que l'on choisit dans une liste : il se rattache via le champ Localisation fiscale de la société, qui prend une valeur par pays — Algérie, France, Maroc, Belgique, plan générique, SYSCOHADA… Charger ce pack instancie d'un coup le plan de comptes, les journaux, les taxes et les positions fiscales du pays pour la société active.

Tout se pilote depuis l'écran de configuration, sans intervention technique. Côté UI, l'écran Paramètres → Facturation expose la section Localisation fiscale : un pack pays s'affiche avec un bouton Recharger, suivi des taxes par défaut et de la devise principale de la société active. C'est l'écran à mémoriser pour vérifier qu'une société est bien rattachée à sa localisation :

3. Lire le plan comptable — exemple SCF algérien

Une fois la localisation chargée, le plan comptable apparaît sous Comptabilité → Configuration → Plan comptable. Pour une société algérienne sous l10n_dz, ce sont environ 300 comptes pré-créés, organisés en classes selon le Système Comptable Financier (SCF) :

• Classes 1-2 : capitaux, immobilisations
• Classes 3-5 : stocks, tiers, financiers
• Classe 6 : charges (achats, services extérieurs, impôts, personnel, dotations)
• Classe 7 : produits (ventes, production stockée, subventions, financiers)

Le filtre par classe permet d'inspecter ce qui a été généré. Voici, par exemple, les comptes de la classe 6 pour une société algérienne — tous attribués à la société active via la colonne Sociétés :

Le formulaire d'un compte expose les champs structurants :

4. Les journaux par société — neuf journaux types

Chaque localisation chargée génère un jeu de journaux types — typiquement neuf pour une société CE complète : Ventes (FAC), Achats (FACTU), Banque (BNK1), Caisse (CSH1), Opérations diverses (OD), Différence de change (EXCH), TVA sur encaissements (CABA), Valorisation d'inventaire (STJ), Point de Vente (POSS).

Le formulaire d'un journal de vente expose la configuration essentielle :

5. Les taxes par société — vente, achat, et taux multiples

Chaque société porte ses propres taxes, isolées par société. Chaque taxe est typée vente, achat ou aucun — ce dernier type servant de composant pour des taxes parentes (taxes en cascade).

Pour une société algérienne, la TVA standard est de 19 % en vente, avec des taux réduits (9 %, 0 %) pour certains produits et services. La l10n_dz instancie ces taux automatiquement :

Les taxes par défaut de la société (une en vente, une en achat) se règlent au niveau de la société — c'est ce qu'on a vu en Figure 1. Une nouvelle ligne de devis créée sur Démo SARL France héritera de ce taux 19 % en vente, sauf si le produit force une autre taxe via sa propre configuration.

6. Exercice fiscal & les 5 verrous de date v19

L'exercice fiscal est défini par deux champs sur res.company : fiscalyear_last_day (Integer, défaut 31) et fiscalyear_last_month (Selection, défaut décembre). Soit un exercice qui clôture le 31/12 par défaut. Pour un exercice décalé (clôture au 30/06 par exemple), ces deux champs suffisent — Odoo en déduit les bornes des rapports comptables.

La grosse nouveauté v19 concerne les verrous de date qui passent de deux à cinq. Voici l'arborescence complète :

• fiscalyear_lock_date — Global Lock Date. Aucune écriture ne peut être créée ou modifiée jusqu'à cette date, tous journaux confondus. C'est le verrou qu'on pose après une clôture fiscale.
• tax_lock_date — Tax Lock Date. Verrou spécifique aux écritures portant de la TVA. Posé automatiquement après chaque clôture de période TVA.
• sale_lock_date — NEW v19. Verrou granulaire pour les journaux de type vente. Utile quand on veut figer la facturation client sur un trimestre sans bloquer la saisie côté achats.
• purchase_lock_date — NEW v19. Symétrique du précédent, côté journaux d'achat.
• hard_lock_date — NEW v19, IRRÉVERSIBLE. Aucun administrateur ne peut le retirer ou le contourner par exception. C'est le verrou pour archiver définitivement un exercice clos et audité.

Les modifications de verrou sont tracées dans le chatter de la société — chaque changement est journalisé par utilisateur, avec ancienne et nouvelle valeur :

7. Au-delà du natif — la frontière premium

Tout ce qui précède relève du natif Community. Plusieurs sujets restent volontairement hors périmètre :

• Consolidation comptable multi-société — agrégation des plans des filiales en un bilan groupe. Totalement absente en CE, réservée à l'édition Enterprise.
• Positions fiscales complexes — neutralisations intra-CEE, exonérations conditionnelles, écritures de redressement TVA. Le mécanisme natif des positions fiscales existe, mais sa configuration fine dépasse le cadrage d'administration.
• Clôture annuelle automatisée — génération des écritures de clôture (résultat, soldes), réouverture, états comparatifs N/N-1. Workflow complet.
• Cash basis accounting — paramétrage du journal CABA, gestion des écritures de transition, impacts sur la TVA déclarée.
• Multi-devise avancé — pivotement automatique des écritures, écarts de change réalisés vs latents.
• Exports légaux par pays — FEC français, taxonomie XBRL, formats e-invoicing nationaux.

Le présent article suffit néanmoins pour démarrer proprement la compta d'une PME multi-société sur Community.

8. Checklist setup plan comptable par société

À appliquer dès la création d'une nouvelle société dans la base :

1. Vérifier que la société a un country_id avant de charger sa localisation. Le module l10n_xx auto-suggéré dépend du pays légal.
2. Choisir explicitement le chart_template via Paramètres → Facturation → Localisation fiscale, et utiliser Recharger en cas d'évolution de l10n. Ne jamais laisser une société avec un chart vide en production.
3. Confirmer la devise principale au moment de charger le chart — un changement ultérieur de devise sur une société qui a déjà des écritures est très difficile à rattraper.
4. Renommer les journaux génériques si plusieurs sociétés du groupe utilisent les mêmes codes (FAC, FACTU…) — sinon les exports CSV deviennent ambigus.
5. Définir fiscalyear_last_day et fiscalyear_last_month dès le départ. Une fois des écritures saisies, l'exercice est implicite et difficile à modifier sans rejouer la clôture.
6. Poser fiscalyear_lock_date après chaque clôture, et tax_lock_date après chaque clôture de période TVA. Ne pas attendre la fin d'année.
7. Garder hard_lock_date pour la fin — exercice définitivement clos, audité, comptes déposés. Pas avant.