Comment fonctionnent les ERP: modules, flux de données et grand livre sous-jacent
Une transaction suivie à travers chaque module d'un ERP, avec les écritures comptables réelles, et pourquoi le grand livre général est la source de vérité de tout le reste.
Un système ERP fonctionne en enregistrant chaque événement commercial une seule fois, dans une base de données unique, et en permettant à chaque module de lire et d'écrire dans ce registre partagé. Une commande expédiée est exactement le même enregistrement, qu'elle soit consultée par l'entrepôt, l'équipe commerciale ou le comptable. Le module qui garantit la cohérence de l'ensemble du système est le grand livre général (general ledger) : chaque événement ayant une valeur monétaire y aboutit sous la forme d'une écriture comptable équilibrée, et chaque rapport est issu de ces écritures.
Cet article suit une vente à travers les différents modules, présente les écritures comptables qu'elle génère et explique pourquoi l'intégration avec un ERP concerne les événements et le grand livre plutôt que les écrans.
La base de données partagée
Avant les ERP, chaque département gérait son propre programme. Les stocks vivaient dans un système d'entrepôt, les factures dans un outil de facturation et la comptabilité dans un logiciel dédié. La fin de mois était consacrée à la réconciliation des trois. L'article Qu'est-ce qu'un logiciel ERP présente cette catégorie de logiciels; le mécanisme qui permet de les faire fonctionner repose sur un modèle de données unique dans lequel:
- un enregistrement de partenaire (partner) est utilisé aussi bien par les ventes, les achats que le grand livre,
- un enregistrement d'article (item) contient la quantité en stock, les couches de coûts FIFO (FIFO cost layers), le prix de vente et le compte de produits,
- un document (commande, facture, avoir, achat, ordre de fabrication) fait référence aux partenaires et aux articles pour produire exactement un ensemble d'écritures comptables,
- une écriture comptable (journal entry) fait référence au document qui l'a générée, de sorte que chaque chiffre d'un rapport peut être retracé à la source.
Lorsque les données sont partagées, il n'y a plus rien à réconcilier entre les modules. Ce qui reste à réconcilier, c'est le monde extérieur: les relevés bancaires et les déclarations fiscales.
La carte des modules
| Module | Écrit | Lit |
|---|---|---|
| Ventes | Commandes, factures, avoirs | Partenaires, articles, prix, règles de TVA |
| Achats | Bons de commande, factures fournisseurs | Partenaires, articles, comptes de charges |
| Stocks | Mouvements de stock, couches FIFO, inventaires | Articles, entrepôts |
| Production | Ordres de fabrication, consommation de composants, produits finis | Nomenclatures, stocks |
| Banque | Transactions importées, rapprochements de paiements | Factures ouvertes, comptes bancaires |
| Paie | Bulletins de paie, cotisations, déclarations | Employés, contrats, tables fiscales |
| Immobilisations | Registre des immobilisations, amortissements | Groupes d'immobilisations, durées d'utilité |
| TVA | Déclarations de TVA, états européens des ventes, Intrastat, factures électroniques | Documents émis et enregistrés |
| Grand livre | Écritures comptables, clôtures de périodes | Tout ce qui précède |
| Reporting | Rien | Le grand livre et les balances auxiliaires |
Toutes les lignes, à l'exception des deux dernières, se terminent par une écriture dans le grand livre. C'est cette règle de conception qui distingue un ERP d'un ensemble d'outils connectés.
Un flux de données pratique
L'exemple ci-dessous utilise les points de terminaison (endpoints) de Nordlet et les comptes par défaut du plan comptable lituanien fourni avec la solution. N'importe quel ERP effectue les mêmes étapes; seuls les codes de comptes et les noms de points de terminaison diffèrent.
1. Commande
Une boutique en ligne passe une commande via POST /v1/ecommerce/orders/create: un partenaire, des lignes comprenant des articles et des quantités, ainsi qu'un pays de livraison. Rien n'est encore comptabilisé dans le grand livre. Une commande est un engagement, pas une transaction.
2. Réservation de stock
orders/reserve met les quantités de côté afin qu'une seconde commande ne puisse pas vendre les mêmes unités. Toujours pas d'écriture comptable: le stock réservé appartient toujours à l'entreprise.
3. Exécution (fulfillment)
orders/fulfill enregistre la sortie des marchandises de l'entrepôt. Deux choses se produisent lors d'une seule transaction de base de données:
- Le stock est consommé au coût FIFO: les couches de coûts les plus anciennes pour chaque article sont utilisées en premier, selon la méthode décrite dans l'article du glossaire Évaluation des stocks selon la méthode FIFO.
- Le coût de ces unités est enregistré sous forme d'écriture comptable: débit du coût des marchandises vendues, crédit du stock.
| Compte | Débit | Crédit |
|---|---|---|
| 6000 Coût des marchandises vendues | 600,00 | |
| 2040 Stock | 600,00 |
L'exécution crée également un projet de facture (draft invoice) pour la commande et détermine le traitement de la TVA en fonction du pays de livraison à l'aide du moteur de TVA de l'UE.
4. Émission de la facture
L'émission de la facture correspond au moment où le chiffre d'affaires est comptabilisé pour une vente ponctuelle. Le document reçoit son numéro séquentiel ininterrompu et une écriture équilibrée est passée: le montant TTC au débit des créances clients, la TVA au crédit du compte de TVA collectée, et le montant HT au crédit du compte de produits.
Pour une vente nette de 1 000,00 € soumise à la TVA lituanienne de 21 %:
| Compte | Débit | Crédit |
|---|---|---|
| 2410 Clients et comptes rattachés | 1 210,00 | |
| 5000 Ventes de marchandises | 1 000,00 | |
| 4492 TVA collectée à payer | 210,00 |
Si une ligne comporte une méthode de constatation autre qu'ponctuelle, le montant net est affecté à des produits constatés d'avance, et le moteur de reconnaissance des revenus les libère selon le calendrier prévu. L'enregistrement des créances et de la TVA reste inchangé.
La facture peut désormais être exportée sous forme de PDF, de facture électronique au format Peppol BIS 3.0 ou selon le format de facturation électronique national requis par le pays de l'entreprise.
5. Rapprochement bancaire
Deux semaines plus tard, la somme de 1 210,00 € arrive. Le mouvement est transmis via un flux bancaire PSD2 ou par l'importation d'un relevé au format camt.053. Le module bancaire note les factures candidates en fonction du montant, de la référence de paiement, du nom de la contrepartie et de l'IBAN, et bank/transactions/match enregistre le règlement:
| Compte | Débit | Crédit |
|---|---|---|
| 2710 Banque | 1 210,00 | |
| 2410 Clients et comptes rattachés | 1 210,00 |
Le statut de la facture passe à payé et un webhook sale_invoice.paid est émis. L'article sur le rapprochement des paiements détaille la logique de correspondance. Un paiement dans une autre devise comptabilise l'écart de change réalisé dans le compte de gains ou pertes en une seule étape.
6. Déclaration de TVA
À la fin du mois, aucune saisie manuelle n'est nécessaire. La déclaration de TVA est calculée à partir des documents émis et enregistrés: declarations/eu/vat-return/compute pour la déclaration nationale (FR0600 en Lituanie), declarations/eu/oss/compute pour les ventes aux consommateurs transfrontalières relevant du régime de l'Union. La vente ci-dessus est affectée à la case du taux standard de la déclaration nationale, car son régime de TVA est domestic.
7. Clôture de période
Une fois la déclaration déposée, ledger/periods/lock clôture le mois. Dès lors, toute écriture datée de cette période, y compris un rapprochement bancaire tardif ou un appel API rejoué, est rejetée avec une erreur HTTP 409. La clôture déclenche également la constatation de tout produit constaté d'avance arrivant à échéance à la fin de la période, de sorte qu'un mois ne peut se clore en laissant des revenus acquis dans le compte de passif.
Pourquoi le grand livre est le système d'enregistrement de référence
Chacun des modules ci-dessus gère un grand livre auxiliaire (subledger): créances par client, dettes par fournisseur, stocks par article, immobilisations par bien. Le grand livre général contient les totaux avec lesquels ces grands livres auxiliaires doivent concorder. L'article Grand livre auxiliaire vs grand livre général détaille cette relation; sur un plan pratique, un rapport généré à partir du grand livre et un rapport généré à partir d'un grand livre auxiliaire doivent afficher le même chiffre, et un ERP le garantit en produisant les deux à partir des mêmes écritures comptables.
Trois propriétés garantissent la fiabilité du grand livre en tant que système d'enregistrement:
- L'équilibre est obligatoire. Dans Nordlet, la base de données refuse toute écriture dont les débits ne sont pas égaux aux crédits. Un bogue dans un module ne peut pas générer une écriture déséquilibrée.
- L'historique est immuable. Une écriture validée n'est jamais modifiée. Une erreur est corrigée par une extourne et une nouvelle écriture, toutes deux liées à l'originale. L'article sur le grand livre immuable explique pourquoi les auditeurs exigent ce principe.
- Les périodes se clôturent. Un mois verrouillé ne peut plus être modifié, de sorte que les chiffres que vous avez déclarés restent figés dans le système.
Intégration : événements et idempotence plutôt que traitements par lots nocturnes
Les anciennes intégrations d'ERP reposaient sur des fichiers échangés la nuit: exporter les commandes, les importer, vérifier le journal des erreurs au matin. Les ERP modernes exposent une API, et l'intégration relève désormais de deux principes fondamentaux.
Événements sortants. Lorsqu'un changement survient, l'ERP vous en informe. Nordlet écrit chaque événement de webhook dans une file d'attente (outbox) au cours de la même transaction de base de données que la modification, de sorte qu'un document annulé n'émet jamais d'événement et qu'aucun événement n'est perdu. Les livraisons sont signées avec HMAC-SHA256 et relancées avec un délai exponentiel (exponential backoff). Votre système réagit à l'événement sale_invoice.paid au lieu de demander toutes les cinq minutes si une facture a été payée.
Nouvelles tentatives sécurisées entrantes. Les réseaux connaissent des pannes, et une requête rejouée ne doit en aucun cas créer une deuxième facture. Nordlet accepte un en-tête Idempotency-Key sur chaque appel de modification: la même clé associée à la même charge utile (payload) renvoie la réponse enregistrée, la même clé associée à une charge utile différente est rejetée, et les clés expirent après 24 heures. L'article du glossaire sur l'idempotence et le guide des conventions d'API décrivent ce comportement en détail.
Puisque chaque opération s'articule autour d'un appel POST /v1/{module}/{resource}/{action} et que l'application utilise les mêmes points de terminaison, une intégration peut exécuter l'intégralité du flux décrit ci-dessus sans qu'aucun utilisateur n'ait à ouvrir un écran. Le guide Comment intégrer une API de comptabilité cloud dans une plateforme SaaS détaille la réalisation d'une telle architecture.
Ce que lisent les rapports
Les rapports ne stockent aucun chiffre. Ce sont des requêtes exécutées sur le grand livre et les grands livres auxiliaires à un instant donné:
- La balance, le bilan, le compte de résultat et le tableau des flux de trésorerie lisent les écritures comptables par compte et par période.
- La balance âgée lit les créances et les dettes ouvertes par date d'échéance.
- L'état et les mouvements de stock lisent le grand livre auxiliaire des stocks et ses couches FIFO.
- Le récapitulatif de TVA lit les lignes de TVA des documents émis et enregistrés.
- Les rapports par centre de coûts lisent la dimension centre de coûts rattachée à chaque ligne d'écriture.
Dans Nordlet, un rapport est généré en arrière-plan aux formats XLSX, PDF ou JSON, et un webhook est déclenché dès que le fichier est prêt. Les chiffres consolidés proviennent de la consolidation, qui combine les grands livres de plusieurs sociétés en tenant compte des pourcentages de participation et de la conversion des devises.
Où cela coince en pratique
La plupart des problèmes liés aux ERP proviennent de défaillances du principe de données partagées plutôt que de problèmes logiciels. Les cas les plus fréquents sont:
- Un tableur parallèle pour gérer un besoin que l'ERP "ne sait pas faire", ce qui entraîne immanquablement des divergences avec la comptabilité.
- Des écritures manuelles au journal utilisées pour corriger la sortie d'un module au lieu de rectifier le document source, ce qui brise la traçabilité entre le rapport et sa source.
- Des intégrations qui écrivent des soldes au lieu de documents, si bien que le grand livre contient des totaux que personne ne peut expliquer.
- Des périodes ouvertes laissées non verrouillées pendant des mois, provoquant une dérive des chiffres déclarés au cours du trimestre précédent.
L'article Pourquoi les implémentations d'ERP échouent explique comment ces habitudes s'installent lors d'un déploiement, et Calendriers réalistes d'implémentation d'ERP indique à quel moment du projet elles se manifestent généralement.
FAQ
Quel est le cœur d'un système ERP ?
Le grand livre général et le modèle de données partagé qui l'entoure. Chaque module rédige des documents qui génèrent des écritures comptables équilibrées, et chaque rapport est dérivé de ces écritures.
Comment les données circulent-elles dans un ERP ?
Un événement est enregistré une seule fois sous forme de document (commande, facture, mouvement, bulletin de paie). Le document génère des écritures dans le grand livre et des mouvements dans le grand livre auxiliaire correspondant. Les rapports et les déclarations fiscales sont calculés à partir de ces enregistrements. Rien n'est copié d'un module à un autre.
Quelle est la différence entre un module et une intégration ?
Un module écrit dans la même base de données et dans le même grand livre que le reste du système. Une intégration est un programme externe qui appelle l'API de l'ERP. Avec un ERP orienté API, cette distinction est minime, car l'intégration utilise exactement les mêmes points de terminaison que les modules.
Un ERP comptabilise-t-il automatiquement les écritures ?
Oui. L'émission d'une facture, l'exécution d'une commande, le rapprochement d'un paiement, l'établissement de la paie ou l'amortissement d'un actif génèrent chacun leur écriture comptable sans qu'aucune personne n'ait à saisir manuellement les débits et les crédits. Les comptes utilisés proviennent de règles de validation paramétrables par entreprise.
Pourquoi les ERP verrouillent-ils les périodes comptables ?
Afin de garantir que les chiffres déclarés ou publiés pour une période ne puissent plus être modifiés par la suite. Une période verrouillée rejette les nouvelles écritures, ce qui protège la piste d'audit et oblige à comptabiliser les corrections dans la période en cours, où elles restent visibles.