Help History

Design de la compta à double entrée dans Paheko

Cette page reflète des réflexions et recherches sur la gestion et le stockage des données comptables dans Paheko dans l'objectif d'une refonte effectuée dans le cadre de la version 1.0.

Elles ne sont ici qu'à titre de recherche et de réflexion.

En compta à double entrée on reflète l'idée que l'argent n'est jamais créé ou détruit mais simplement transféré d'un compte à l'autre. « Rien ne se crée, rien ne se perd, tout se transfère ! »

Design original (2012-2019)

Le design de stockage et gestion de la compta à double entrée adopté au début de Paheko est comme suit :

  • une table compta_journal stocke les écritures, chaque écriture est une ligne dans la table, avec un montant, le numéro du compte de débit et le numéro du compte de crédit
  • le solde des comptes est calculé dynamiquement en SQL quand on en a besoin
  • les bilans, compte de résultat, etc. sont calculés dynamiquement
  • les montants sont stockés en nombre à virgule flottante (FLOAT)

Avantages de ce design :

  • Simplicité du stockage des données, simplicité de l'entrée des écritures

Problèmes avec ce design :

  • Il y a eu des bugs avec des erreurs d'arrondi
  • Impossible de faire une écriture complexe qui créditerait/débiterait plusieurs comptes à la fois (mais avec toujours une égalité crédit/débit de l'écriture)
  • Requêtes SQL très complexes (et parfois lentes) pour obtenir des infos
  • Requête SQL trop lente pour le report à nouveau

Nouveau design (2020+)

Fonctionnalités désirées :

  • Portabilité des données depuis le design actuel
  • Possibilité d'avoir plusieurs entrées (plusieurs débits/crédits sur plusieurs comptes) dans une écriture
  • Amélioration des performances
  • Simplification des requêtes de visualisation (amenant une amélioration des performances)
  • Validation des écritures : une fois une écriture validée impossible de la modifier / supprimer mais possibilité de faire une écriture corrective ("reversability")
  • Possibilité d'activer une option inaltérabilité qui ajouterait une signature de chaîne à chaque transaction validée (écriture), voir le ticket idoine
  • Archivage des exercices précédents
  • Purge des écritures des exercices clos
  • Possibilité d'avoir un plan comptable différent par exercice
  • Possibilité de sélectionner plusieurs écritures dans un compte/recherche et de créer une nouvelle écriture à partir de celles-ci (par exemple pour le dépôt de chèque en banque : on ajoute les chèques dans "à encaisser" quand on les reçoit, et lors du dépôt on coche leurs écritures, et on crée une nouvelle écriture qui gardera les numéros de chèque et montants individuels)

Compta simplifiée

Une partie de compta simplifiée doit être présente pour permettre aux non-comptables de rentrer les opérations courantes d'une asso, cela signifie :

  • Saisie d'une balance initiale
  • Recettes, dépenses
  • Virements entre comptes, dépôt d'espèces, retrait d'espèces
  • Chèques en attente d'encaissement, dépôt de chèques
  • Dettes, créances
  • Contribution en nature et dons de bénévoles en nature

L'idée étant d'avoir un accès simplifié à la compta pour un non comptable, mais une progression possible (ou une utilisation hybride) vers la compta à double entrée.

Lorsqu'aucune écriture n'existe dans la compta, la page d'accueil de la compta doit proposer de choisir le plan comptable (belgee/français) puis de faire une saisie initiale.

Par défaut aucun exercice n'existe, on est sur un exercice glissant, qui doit permettre de remplir des opérations quelle que soit leur date et de générer des rapports (bilan, etc.) selon une période dynamique.

Si on crée un exercice, on doit découper les écritures existantes selon les périodes données. Ensuite il n'est plus possible d'être en exercice glissant.

Les opérations suivantes sont considérées comme accessibles aux débutants :

  • Saisie simple
  • Saisie simple rapide (saisie au km)
  • Saisie initiale
  • Gestion des comptes bancaires et caisses
  • Gestion des catégories de recettes/dépenses
  • Report automatisé des soldes

Fonctions avancées :

  • Saisie avancée directement de compte à compte
  • Rapprochement
  • Validation d'écriture (avec signature)
  • Ecriture corrective
  • Modification du plan comptable

Page d'accueil compta

Liens :

  • recherche
  • import / export CSV/ODS
  • soldes des comptes et caisses
  • nombre de dettes et créances en cours (avec liens vers leurs pages)
  • nombre de chèques à déposer en banque
  • nombre d'écritures à rapprocher
  • graphiques d'évolution recettes/dépenses

Lignes multiples pour une écriture :

  • Deux colonnes : une pour la somme au crédit, une pour la somme au débit. Une des deux doit valoir zéro.
  • Contrainte CHECK : débit * crédit == 0 et débit + crédit > 0
  • Ça permettra de calculer le solde d'un compte en utilisant SUM(debit) - SUM(credit) ou l'inverse, selon le sens du compte
  • Ajout de VIEWs pour permettre de simplifier les requêtes ?

Idées abandonnées :

  • Utilisation d'une seule colonne pour le montant, utilisation d'un montant positif pour débiter et négatif (-) pour créditer. Devrait permettre un calcul plus simple des totaux.
  • Une table compta_comptes_balances devrait exister et contenir le numéro du compte, le numéro de l'exercice et la balance du compte, cette balance étant mise à jour par un TRIGGER SQLite lors de l'ajout / modification / suppression d'une écriture, permettant d'avoir très rapidement la balance des comptes et aussi produire des résultats/bilans. Cela devrait rendre l'enregistrement d'écriture légèrement plus lent par contre (requête supplémentaire). Ça pourrait être une simple VIEW sinon ?

Résolutions :

  • Ajout d'une colonne validation dans le journal permettant de savoir si une écriture est validée ou non. Une écriture validée ne peut plus être modifiée / supprimée.
  • Séparation des écritures et "sous-écritures" pour permettre d'avoir plusieurs lignes dans une écriture (mais toujours balancée débit/crédit)
  • Utilisation de transactions et vérifications pour empêcher d'avoir seulement certaines des lignes de l'écriture dans la base si une des lignes échoue ! (solution : mettre un champ enregistré dans la table et changer sa valeur quand toutes les lignes sont ajoutées !)
  • Vérification que les lignes des écritures obtiennent toujours débit = crédit !
  • Stocker les montants sous forme d'entiers (INTEGER), ne pas utiliser d'opérations mathématiques pour rajouter la virgule (multiplication / division) mais simplement rajouter la virgule dans une chaîne de texte avant les deux dernières décimales
  • Possible d'avoir plusieurs plans comptables, et de choisir le plan comptable associé à un exercice
  • Simplification du code : suppression des tables catégories, rapprochement, projets, comptes_bancaires
  • Les comptes bancaires et catégories sont simplement des "types" spéciaux de comptes dans le plan comptable
  • Les projets sont dans le plan comptable (section 9 comptes analytiques)
  • Le rapprochement est une colonne dans les écritures
  • Possibilité de définir soi-même dans le plan comptable des types de comptes spéciaux : contributions en nature, dépenses, recettes, banque, caisse, en attente d'encaissement, etc. pour supprimer tout numéro de compte "en dur" dans le code

Ressources utiles

Pour comprendre / réviser les bases de la compta :

Une bonne inspiration pour comprendre la compta en informatique c'est de regarder du côté des logiciels de compta en ligne de commande (format texte) comme Ledger, Abandon, Beancount et hLedger :

Comme inspiration on peut aussi regarder du côté des logiciels libres faisant de la compta double entrée :

  • SQL Ledger est le plus connu mais son interface est horrible et son code est peu lisible (aucun commentaire). Leur schéma PostgreSQL peut donner des idées… si on arrive à le comprendre.
  • GNUCash est le plus complet probablement. Il peut faire des écritures simples ou complexes ("split") cf. la doc. Voir aussi de bonnes infos dans le code source : Transaction.h et Split.h. Ils utilisent des "transactions" qui contiennent des "splits" (ou "ledger entries"). Apparemment GNUCash permet de stocker ses données avec SQLite/mySQL et il y a donc un schéma SQL disponible qui confirme ce concept de stockage. Une discussion sur la liste explique aussi le concept de stockage des montants et du nombre de chiffres après la virgule. Leur doc interne est un peu vieillote mais explique un peu mieux.
  • KMyMoney semble utiliser le même modèle
  • Dolibarr utilise une table de transactions et une table de débits/crédits, de la même manière.

Conception de base de données pour la compta à double entrée :

Une solution de compta en ligne un peu brouillon mais intéressante : Zefyr

Fossil 2.20 [210e89a059] 2022-11-16 18:46:32
This page was generated in about 0.011s