Conception de base de données de comptabilité à double entrée
Je crée un logiciel de comptabilité. Je dois appliquer la comptabilité à double entrée. J'ai le problème classique d'une ligne par transaction contre deux lignes.
Prenons un exemple et voyons comment il serait implémenté dans les deux scénarios.
Considérez le compte Cash et le compte Rent. Lorsque je paie mon loyer mensuel, je transfère 100 $ de mon compte Cash vers mon compte Rent.
Une ligne par transaction
Dans un système à une ligne, une telle transaction serait stockée sous la forme:
transactions
tx_id | posting_date
1 | 23/05/2015
transaction_records
id | tx_id | credit_account | debit_account | amount
1 | 1 | Cash | Rent | 100.00
Deux lignes par transaction
Dans un système à deux rangées, je devrais refléter le même enregistrement de transaction pour créer un enregistrement opposé qui, une fois que je résume les deux, j'obtiendrais un solde nul.
transactions
tx_id | posting_date
1 | 23/05/2015
transaction_records
id | tx_id | type | account | amount
1 | 1 | credit | Cash | 100.00
2 | 1 | debit | Rent | 100.00
Le problème
Tout d'abord, je voudrais noter: la raison pour laquelle j'ai à la fois transactions et transaction_records tables (au lieu d'une table) est de pouvoir gérer des transactions fractionnées (un cas où je transfère 100 $ du compte Cash vers deux ou plusieurs comptes différents).
Au début, j'ai essayé de l'implémenter avec une ligne par transaction, mais c'est difficile de calculer le solde du compte et de récupérer les données.
Je penche vers le deuxième scénario; cependant, il a également quelques problèmes:
- Comment mettre à jour un seul enregistrement? En supposant que j'ai fait une erreur et au lieu d'enregistrer 100 $ pour mon loyer, j'ai enregistré 10 $. J'ai maintenant 2
transaction_records- un pour le crédit et un pour le débit, tous deux d'un montant de 10 $. - Maintenant, je fais ma réconciliation et je veux corriger cette faute de frappe. Comment pourrais-je résoudre ce problème dans la base de données? Je ne connais pas le lien entre les enregistrements, et en cas de scission, une transaction peut avoir plus de 2 enregistrements. La seule solution que j'ai trouvée est d'ajouter quelques
ref_idpour chaque paire d'enregistrements qui identifiera de manière unique ces enregistrements comme étant les "côtés opposés les uns des autres" dans un contexte d'untx_id.
Quelle approche est meilleure/plus simple?
Pour simplifier ma question: je veux représenter un mouvement de fonds du compte A vers le compte B. Les deux scénarios que j'ai donnés sont tous deux des modèles valides pour stocker une telle transaction. Comme je l'ai également souligné, ils ont tous les deux des inconvénients et des avantages (le premier: plus facile à enregistrer, plus difficile à récupérer; le second à l'opposé).
Ils pourraient avoir d'autres avantages/inconvénients que je ne repère pas en ce moment, c'est pourquoi je demande l'avis de personnes plus expérimentées.
En effet, le schéma comptable à une seule ligne proposé permet de faire une comptabilité en double entrée correcte (pour toujours spécifier le compte débité et crédité) sans introduire la redondance des données "montant".
Le schéma à une ligne vous donne une implémentation d'une double entrée qui s'équilibre par construction, de sorte qu'il est impossible de "perdre l'équilibre". La machine peut recalculer les registres à la volée.
Vous devez faire 2 sélections au lieu d'une pour récupérer un grand livre.
Notez que, en plus du fractionnement des transactions, il existe d'autres transactions telles que le change pourrait se retrouver avec 2 enregistrements au lieu de 4. Tout dépend si vous dénormalisez un peu entrez simplement 4 transactions avec une description similaire.
Vous pouvez empêcher la saisie ou la modification de toute transaction pour maintenir une piste d'audit, ceci est nécessaire si vous voulez pouvoir auditer le journal des transactions.
Il semble que dans le fil ci-dessus, pour le CPA, "entièrement normalisé" semble signifier des règles reconnues par tous les comptables, alors que pour le programmeur, cela a une signification différente, qu'il n'y a pas de données dérivées ou redondantes stockées.
Tout ce qu'il y a dans les données comptables, c'est un ensemble de transactions qui donnent le montant et les comptes desquels et vers lesquels elles découlent, avec leur date, une description (et d'autres pièces jointes). Les livres et les soldes sont de simples vues dérivées de ces données transactionnelles en faisant des sommes.
Un journal est une liste chronologique de toutes les transactions d'un type spécifié pour un système comptable. Voici une présentation classique sur du grand livre d'un simple journal des ventes (sur compte):
Notez que chaque ligne est une transaction unique, avec Total Debits = Total Credits; et que chaque transaction touche les trois mêmes comptes. Un Journal des ventes au comptant se ressemblerait mais remplacerait la colonne Débit des comptes clients avec un libellé Débit en espèces . Un Journal des décaissements aurait une première colonne intitulée Crédit en espèces et supplémentaire des colonnes telles que Débit des comptes créditeurs et Débit des dépenses des employés .
Cette présentation a été standardisée pendant des centaines d'années jusqu'à ce que les ordinateurs personnels soient devenus abordables il y a quelques décennies. Il présente un avantage significatif de vérifier facilement que chaque transaction est équilibrée en vérifiant simplement chaque ligne. De même, avant de publier une page de cette transaction dans les grands livres le les totaux de page pourraient être vérifiés de la même manière. Il s'agit d'un modèle de traitement par lots utilisé dans de nombreux systèmes comptables.
Il est facile de voir que ce modèle papier présente des inconvénients importants lorsqu'il est littéralement transcrit dans un système automatisé:
- La structure de données est pivotante, alors que l'expérience a montré qu'il est beaucoup plus simple (également plus robuste et plus facile à vérifier) de programmer contre une structure de données pliée; et
- Parce que chaque journal spécialisé frappe un ensemble de comptes différent, chacun de ces journaux devrait être conçu et programmé séparément, une activité inutile et sujette aux erreurs.
Pour ces raisons, il est généralement recommandé d'utiliser la conception des revues spécialisées comme interface avec le système comptable, mais de concevoir une structure de données qui peut être numérique. référentiel pour plusieurs revues. Dans un SGBDR moderne, cela présente l'avantage potentiel que le grand livre général , et même les livres auxiliaires spécialisés , peut devenir Vues indexées sur le Journal, éliminant complètement la nécessité de coder un Processus de publication (le étape où une transaction de journal est verrouillée et dont les totaux de compte sont transcrits dans les différents livres).
Quelle que soit la conception des données avec laquelle vous vous retrouvez, la clé est d'avoir une seule entrée de publication pour chaque type de transaction (c'est-à-dire chaque spécialité Journal dans le système papier équivalent) où les vérifications de solde sont effectuées.
Mon point est que les deux approches que vous proposez sont des mécanismes non fiables pour la comptabilité à double entrée. Premier point: les journaux sont des tables à écriture unique pour de très bonnes raisons. Parfois, les deux tables virtuelles Les entrées en attente et les entrées publiées sont colocalisées dans une seule structure de données, mais le IsPosted le bit est toujours en écriture seule et le système doit s'assurer que la nature en lecture seule des enregistrements des entrées publiées est maintenue.
La façon dont les comptables ont publié les écritures de journal au cours des 800 dernières années est entièrement normalisée . La seule différence entre une présentation papier et une présentation électronique solide est qu'une structure de table pliée est plus pratique dans ce dernier cas tandis qu'une structure de table pivotante dans le premier, qui était historiquement la plus importante lorsqu'un traitement hautement parallèle était souhaité - c'est-à-dire de nombreux commis chacun maintenir un seul ou petit nombre de revues spécialisées. Seul le contrôleur avait historiquement des autorisations pour le Journal général.
Notez soigneusement que dans ce qui précède, j'ai spécifié que les entrées de journal sont entièrement normalisées; Les entrées de journal sont un enregistrement chronologique de toutes les transactions, regroupées dans des journaux spécifiques à chaque type de transaction. L'enregistrement de écritures de journal dans les grands livres est une entreprise distincte et, bien que entièrement normalisé en soi, est une copie redondante des écritures de journal où toutes les transactions sont résumées (grand livre) ou détaillées (grand livre) par compte. Les journaux et les livres utilisent la comptabilité en partie double indépendamment.
@Codism Tout système comptable, DEB ou SEB, vous fournit des rapports généralisés pour tous les comptes enregistrés . À noter qu'en interne, un grand livre auxiliaire est par définition un registre de comptabilité à entrée unique; l'autre côté est le ou les comptes de contrôle correspondants au bilan. DEB s'assure que pour chaque dollar d'actif, il existe un enregistrement précis de la créance commerciale sur l'actif , c'est-à-dire les capitaux propres dans l'actif, qu'il s'agisse d'une dette nette (aka passif) ou d'une l'équité de propriété , et de la priorité de ces créances si l'organisation devient insolvable.
Puis-je vous suggérer de jeter un œil aux trésors des logiciels Open Source qui existent dans ce domaine?
Un Google de " logiciel de comptabilité à double entrée open source " donne plusieurs pistes d'investigation prometteuses.
Vous pouvez consulter le GNU package comptable ici , quelques sites de revue ( 1 & 2 ) et enfin le wiki des logiciels de comptabilité avec une section sur les logiciels libres.
Je suis sûr qu'en examinant certains des codes source et des schémas F/LOSS, vous pourriez obtenir de bons conseils et des indications sur la façon d'écrire des schémas et/ou des logiciels qui répondent à vos besoins particuliers.
J'ai un système qui fait des doubles lignes et ses nombreux défis que d'avoir des comptes simples lignes. J'ai d'abord rencontré des cas où une seule ligne était poussée comme le côté débit, ce qui entraînait un compte déséquilibré. Même si je ne fais pas les contrôles appropriés de validation et d'annulation, cela ne se produira pas dans les comptes à une seule ligne. enfin, votre base de données croît en taux de croissance double, votre deuxième ligne d'envoi aura beaucoup d'informations en double, la seule différence étant le deuxième compte. Je conseillerais de conserver, compte à ligne unique, je vais sur cette route ..