Overview

Artifact ID: bfff70eea99198c6dfe42e61800a96d780fe12cf
Page Name:Dev-Compta
Date: 2018-05-23 16:42:16
Original User: bohwaz
Mimetype:text/x-markdown
Next 07ce0b2b9e44391c235adcc073b2e0b1a0376e02
Content

Design de la compta à double entrée dans Garradin

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-2018)

Le design de stockage et gestion de la compta à double entrée adopté au début de Garradin 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 (2018+)

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

Idées à confirmer :

  • 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

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 :