Artifact ID: | bfff70eea99198c6dfe42e61800a96d780fe12cf |
---|---|
Page Name: | Dev-Compta |
Date: | 2018-05-23 16:42:16 |
Original User: | bohwaz |
Mimetype: | text/x-markdown |
Next | 07ce0b2b9e44391c235adcc073b2e0b1a0376e02 |
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 simpleVIEW
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 :
- Chapitre 2 : la comptabilité en partie double
- Subledger: Accounting for Developers 101
- Subledger: Accounting for Developers 102
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 :
- Plain text accounting a pas mal de ressources sur le sujet
- Syntax Quick Reference for the Ledger-Likes donne de bonnes pistes pour certains problèmes courants
- Keeping finances with Ledger Archive: http://archive.is/fITNv
- Collection of ledger-cli commands Archive: http://archive.is/nHvwX
- Ledger discussion on Hacker News Archive : http://archive.is/ZTVaJ
- Ledger, a powerful CLI accounting tool (another Hacker News discussion) Archive: http://archive.is/RPgY1
- List of Ledger-inspired software
- Groupe Reddit: https://www.reddit.com/r/plaintextaccounting/
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 :
- Basic double-entry bookkeeping system, for PostgreSQL donne un exemple de schéma PostgreSQL pour de la compta à double entrée, mais ça reste très basique.
- Sur StackExchange : Double entry bookkeeping database design pose la question de stocker les écritures sous la forme de deux lignes ou une seule ligne dans une table de transactions (conclusion : utiliser une seule ligne), avec notamment la problématique de faire des débits/crédits dans plusieurs comptes dans la même écriture (la solution donnée ne résoud pas le problème)
- Sur StackExchange encore : Should a ledger DB store a separate line for each side of a transaction? suggère qu'il faudrait une ligne par écriture de chaque opération
- Double Entry Accounting in a Relational Database par Michael Wigley. Miroir : https://medium.com/@RobertKhou/double-entry-accounting-in-a-relational-database-2b7838a5d7f8
- Database schema of double-entry accounting module - Archive : http://archive.is/XxFQk - Un exemple réel de base de données pour de la compta à double entrée, mais ne répond pas à la question de la création de bilans, comptes de résultat etc. avec ce schéma.
- Simple Accounting database design Archive : http://archive.is/ag2DI
- Structuring Database for Accounting (PDF)
- Le livre Martin Fowler - Analysis Patterns - Reusable Object Models (1996) (page 98 et suivantes) indique aussi d'utiliser des "multi-legged transactions" en fait d'avoir une table
Transaction
qui est liée par plusieurs entrées dans la tableEntry
etTransaction
est chargé de vérifier queSUM(Entry.amount) == 0
- http://www.vbforums.com/showthread.php?687131-SQL-Table-and-row-linking-Double-entry-accounts
- Autres discussions sur StackOverflow :
- https://stackoverflow.com/questions/5079506/accounting-and-database-design-storing-debit-and-credit-amount (la dernière réponse est la plus intéressante)
- https://stackoverflow.com/questions/4373968/database-design-calculating-the-account-balance
- https://stackoverflow.com/questions/1116823/accounting-system-design-databases
- https://stackoverflow.com/questions/29688982/derived-account-balance-vs-stored-account-balance-for-a-simple-bank-account/29713230#29713230 Très intéressant !
- https://stackoverflow.com/questions/4074737/accounting-database-storing-a-transaction Pareil !