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 compte Cashet compte Rent. Lorsque je paie mon loyer mensuel, je transfère 100 $ de mon Cashcompte vers mon Rentcompte.

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 les deux tables transactionset transaction_records(au lieu d'une table) est de pouvoir gérer des transactions fractionnées (un cas où je transfère 100 $ du Cashcompte 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'en ai maintenant 2 transaction_records- un pour le crédit et un pour le débit, les deux avec 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 consiste à en ajouter ref_idpour chaque paire d'enregistrements qui identifiera de façon unique ces enregistrements comme étant les "côtés opposés les uns des autres" dans un contexte spécifique tx_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é à 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, outre le fractionnement des transactions, il existe d'autres transactions telles que le change peut 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, cela est nécessaire si vous souhaitez 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 papier de 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 serait similaire, mais remplacerait la colonne Débit des comptes clients par une colonne intitulée Débit en espèces . Un journal des décaissements aurait une première colonne intitulée Crédit en espèces et des colonnes supplémentaires telles que Débit des comptes créditeurs et Débit des dépenses des employés .

Cette présentation a été standard 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, les totaux des pages peuvent ê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é:

1. La structure de données est pivotante, tandis 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
2. Étant donné que chaque journal spécialisé touche 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 le référentiel numérique 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 , peuvent devenir des vues indexées sur le journal, éliminant ainsi complètement la nécessité de coder un processus de comptabilisation (l'étape où une transaction de journal est verrouillée et possède son compte totaux 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 écriture comptable pour chaque type de transaction (c'est-à-dire chaque journal spécialisé dans le système papier équivalent) où les vérifications de solde sont effectuées.

Ce que je veux dire, c'est que les deux approches que vous proposez sont des mécanismes peu fiables de comptabilité à double entrée. Premier point: les journaux sont des tableaux à écriture unique pour de très bonnes raisons. Parfois, les deux tables virtuelles Entrées en attente et Entrées publiées sont colocalisées dans une structure de données unique, mais le bit IsPosted est toujours en écriture seule et le système doit s'assurer que la nature en lecture seule des enregistrements d'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 écritures 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. La comptabilisation des écritures de journal dans les grands livres est une entreprise distincte et, bien que entièrement normalisée 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 offre un reporting généralisé 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 de l'actif, qu'il s'agisse d'un avoir de dette (aka passif) ou d'un avoir de propriété , et de la priorité de ces créances si le 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 " offre plusieurs pistes d'investigation prometteuses.

Vous pouvez regarder le paquet de comptabilité GNU ici , quelques sites de révision ( 1 et 2 ) et enfin le wiki du logiciel de comptabilité avec une section sur les logiciels libres.

Je suis sûr qu'en examinant certains du code 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 contrôle pas correctement les validations et les annulations, cela ne se produira pas dans les comptes sur 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 ..