Quelles considérations particulières sont nécessaires lors de la conception de bases de données pour conserver des documents financiers?

J'espère que cette question n'est pas trop large. À l'avenir, je devrais peut-être ajouter des systèmes de comptabilité et de suivi financier à certaines applications (principalement des applications Web, mais mes questions concernent également les applications de bureau).

Désormais, la création d'un simple enregistrement des transactions financières est théoriquement facile. Une table de base de données avec quelques colonnes pourrait faire le travail. Même MS Access, Excel ou même un simple fichier texte ASCII peuvent être utilisés pour stocker les dates de transaction, les ID de compte et les montants en dollars. Cependant, je pense que même une table SQL fréquemment sauvegardée avec intégrité transactionnelle peut ne pas être suffisamment robuste pour un suivi financier sérieux.

J'entends des termes comme «comptabilité à double entrée», et j'ai l'impression que la plupart des applications de suivi financier (par exemple, Mint.com ou GnuCash) ont une structure de données ou un processus beaucoup plus compliqué en place pour s'assurer que tout s'additionne parfaitement, exactement comme il se doit, et qu'aucune donnée n'est jamais perdue ou corrompue.

Ma question est la suivante: lors de la conception d'une application pour suivre les transactions financières, quelles considérations de conception spéciales doivent être prises? Il semble qu'il puisse y avoir tellement de problèmes potentiels ... des problèmes de précision d'arrondi, des contrôles de parité, une sorte de processus d'audit, des sauvegardes spéciales, la sécurité / le cryptage, des moyens supplémentaires de protéger les données en cas de crash de saisie de données. ... Je ne sais pas vraiment ce que je devrais demander spécifiquement, mais j'ai l'impression que l'industrie de la programmation a un ensemble de meilleures pratiques que je ne connais pas. Que sont-ils?

Éditer:

On dirait que j'ai ouvert une plus grande boîte de vers que ce à quoi je m'attendais. Pour clarifier, je pense spécifiquement à deux types d'applications:

1. Des applications de type «vérifier le registre» comme GnuCash ou Quicken qui conservent un enregistrement des transactions individuelles pour leur propre usage.
2. Applications qui suivent la facturation / le crédit / ou les "points" pour les fournisseurs et les clients qui traitent avec une entreprise.

Je ne ferai probablement pas de services bancaires directs ou (AFAIK) quoi que ce soit qui ait une tonne de réglementations gouvernementales liées aux finances.

Vous obtiendrez de nombreuses réponses à cela, j'en suis sûr, de nombreuses réponses idéalistes aussi, je ne peux que répondre de mon expérience avec les finances et de ce qui se passe réellement.

Vous avez déjà couvert la majorité des problèmes.

La précision de l'arrondi n'est généralement pas vraiment un problème dans mon expérience. La majorité des grandes organisations financières qui n'ont pas grandi du jour au lendemain (c'est-à-dire tout sauf les fonds spéculatifs) ont une vaste gamme d'applications héritées qui sont divisées en raison de divers carburants. Ils ont tendance à ne pas faire la précision d'arrondi de manière cohérente; généralement, une certaine erreur de profit et de perte est simplement acceptée pour l'arrondissement. En effet, de nombreuses heures de travail sont passées dans des endroits où j'ai travaillé, où les humains disposaient des sélecteurs ultimes `` oui qui sont assez proches '' lorsqu'il s'agit de faire correspondre les sommes exactes / attendues. Rappelez-vous, c'est une réponse basée sur la réalité, pas sur ce qui devrait arriver.

Chiffrement - ne vous y fiez pas franchement. Stockez les données d'identification dans un système physiquement et logiquement distinct des données dépersonnalisées (c.-à-d. Code de compte partout, données personnelles séparées).

Généralement, alors que des sauvegardes sont nécessaires, les sauvegardes hors ligne sont rarement appelées - les choses ont mal tourné à ce stade. Des copies de production à chaud sont généralement nécessaires, mais cela dépendra de vos propres besoins spécifiques. Dans la pratique générale, nous avons une copie de production sur site à chaud de tous les systèmes ET un site de reprise après sinistre avec sa propre production et des copies à chaud. Les copies chaudes ont tendance à avoir quelques minutes de retard dans la réplication, etc.

L'audit est la clé de chaque système financier sur lequel j'ai travaillé. Vous avez 2 exigences fondamentales A) Pouvez-vous suivre chaque modification apportée aux données, par qui, quand et pourquoi? B) Pouvez-vous prouver l'état historique de vos données? Qu'il n'a pas été trafiqué?

A) est requis pour les équipes opérationnelles - votre système sera utilisé de 100 manières que vous n'auriez jamais imaginées, et ces informations sont vitales pour l'expansion, les rapports ad hoc, les raisons juridiques et le débogage.

B) Voir l'affaire AMEX contre Vee Vinhnee - où AMEX n'a ​​pas été en mesure de collecter les 40k qui lui sont dus car ils n'ont pas pu prouver que leurs dossiers n'étaient pas constitués. La solution généralement utilisée pour cela est l'horodatage de confiance. Les grandes sociétés financières ont des banques garantes qui garantissent les transactions et fournissent donc intrinsèquement un horodatage fiable. Il existe des fournisseurs commerciaux pour cela pour d'autres horizons / scénarios.

Les considérations sont principalement d'ordre juridique . Si vous le regardez simplement du point de vue de la sécurité / fiabilité, une feuille Excel peut ne pas être intrinsèquement moins sûre qu'une feuille de papier dans un tiroir. L'intégrité transactionnelle d'Access peut être meilleure que celle d'un employé qui est interrompu par un appel.

Mais, pour que vos clients soient autorisés à l'utiliser, vous devez vous conformer à vos lois locales. Certaines choses que j'ai rencontrées (en Allemagne)

• Formats de documents pour le stockage , car il existe des lois obligeant les entreprises à conserver leurs documents pendant 10 ans. Dans 10 ans, votre programme n'est peut-être plus disponible. Par conséquent, vous devez stocker les documents de manière certifiée DIN / ISO (.pdf semble suffire en Allemagne)
• Des pistes d'audit sont souvent nécessaires, par exemple, vous devrez peut-être présenter différentes versions du même document, avec des dates de modification.
• L'emplacement du stockage est important , en raison du «Datenschutz» (confidentialité), qui peut être différent dans le pays de stockage. Cela rend les services basés sur le cloud un peu délicats.
• Certains documents doivent être stockés de manière non modifiable . la façon dont cela est réalisé semble dépendre principalement de la piqûre légaliste (un document est immuable, un cd est modifiable, un cd signé par un travailleur ne l'est pas)

Vous devez définitivement contacter un avocat, pour plus de détails, ou au moins travailler en partenariat étroit avec un client.

Les facteurs de fiabilité deviennent étonnamment importants lorsque vous traitez avec l'argent des gens. Si Twitter perd un tweet, ce n'est pas si grave; si vous facturez la carte de crédit de quelqu'un mais que vous perdez sa commande, un membre de votre organisation va en avoir plein la bouche d'un client en colère. Donc, deux choses: 1. Vous ne voulez pas que cela se produise en premier lieu, mais 2. cela se produira éventuellement, peu importe votre prudence, vous voulez donc mettre BEAUCOUP d'énergie dans le type de mécanismes de journalisation et de traçage cela vous aidera à revenir en arrière et à trouver l'ordre "perdu" et à corriger la situation.

Le pire absolu est d'avoir, par exemple, des frais de carte de crédit, mais AUCUN enregistrement du tout à quoi il sert, ni à qui il appartient, etc.

Pour les aspects financiers, vous devez vraiment réfléchir même aux scénarios apparemment super improbables et planifier comment les gérer: "Nous avons débité la carte de crédit, mais le serveur de base de données est hors service avant de pouvoir mettre à jour l'enregistrement correspondant." OK, et maintenant? Annuler la charge? Enregistrer la transaction dans un fichier afin qu'un humain puisse la corriger plus tard? Ok, que faire si le disque est plein et que vous ne pouvez pas écrire dans le fichier? Etc.

[1] Utilisez des tables de sécurité (à ne pas confondre avec les utilisateurs de bases de données internes) pour les utilisateurs et pour votre application. modules, formulaires, pages Web:

User = {userID, username, pwd, email1, email2}
Modules = {moduleID, moduleTitle, moduledescription}
ModulesPerUser = {modulesperuser, userID, moduleID}

[2] Ne supprimez pas les enregistrements de votre application., Utilisez un champ d'état, peut-être entier, peut-être booléen ou bit, qui indique que l'enregistrement est considéré comme "supprimé". Faites-vous app. afficher les enregistrements qui ne sont pas supprimés (marqués comme supprimés, par ce champ), et créer des formulaires de cas spéciaux, où l'application. affiche les enregistrements marqués comme supprimés.

anytable = {anytableID, anytablefield1, anytablefield2, ..., bool anytableisdeleted }

Cette fonctionnalité est appelée "suppression virtuelle". La véritable suppression est appelée frecuemment "suppression physique".

[3] Utilisez des champs dans toutes les tables qui se rapportent à l'accès, stockez l'utilisateur (unique) qui crée l'enregistrement et le (dernier) utilisateur qui a modifié l'enregistrement, et le datetime, si possible, ajoutez le module ou l'option où chaque enregistrement était modifié:

AnyTable = {anytableID, anytablecreateuserID, anytablecreatedatetime,
anytableupdateuserID, anytableupdatedatetime,
moduleID, anytablefield1, anytablefield2, ..., anytableisdeleted }

[4] Dans certains cas, les valeurs monétaires ou monétaires peuvent affecter les résultats, lorsqu'elles sont utilisées plusieurs enregistrements dans un détail et, ajoutées dans une seule valeur, dans un enregistrement d'en-tête.

La plupart des marques de bases de données prennent en charge, de nos jours, un champ de données de devise ou d'argent. Utilise le.

Dans certaines circonstances spéciales, certaines personnes les stockent dans une valeur flottante fixe qui prend en charge plusieurs chiffres décimaux, ("décimaux") ou même sous forme de valeurs de chaîne.

Ces techniques sont une épée à double tranchant. Si votre application nécessite ce type de prescription, recherchez sur le Web un didacticiel sur la façon de l'implémenter correctement.

À votre santé. [N'oubliez pas de donner une boîte de thon ouverte au chat, ou moins de votes positifs]

Vous avez marqué votre question securitymais vous parlez principalement de cohérence et de fiabilité, je vais donc essayer de répondre à cette partie de l'équation:

• Utilisez les transactions de base de données pour garantir l'intégrité des opérations par lots. L'exemple le plus élémentaire est un transfert entre deux comptes - un compte est déduit du montant et l'autre est crédité. Utilisez les transactions pour éviter qu'un transfert partiel ne se produise (un seul côté est changé).
• Pour plus de précision, utilisez le DECIMALtype au lieu de flottants. Les calculs sont beaucoup plus lents mais vous ne devriez pas le ressentir car la plupart des calculs financiers sont très basiques
• Utilisez la réplication pour la disponibilité et les hotcopies pour la sauvegarde. Vous devez également examiner les instantanés LVM pour la récupération

Certaines des considérations que je vois sont que vous devez tenir compte des contrôles internes. Cela signifie que tous les accès aux actions sur les tables (insertion / suppression / mise à jour) doivent se faire via des proc stockés (et pas de SQl dynamique) afin qu'aucune table n'autorise les droits d'écriture ou de suppression directement sur la table à quiconque, sauf à un administrateur système. Vous devez également tenir compte des contrôles internes qui ne permettent pas à quelqu'un de créer une nouvelle entreprise, puis de facturer des articles à cette entreprise (une route pour fraude). De telles actions nécessiteront toujours l'approbation de personnes occupant deux rôles différents. De plus, les chèques ne doivent pas être coupés à moins qu'une personne n'entre des données et qu'une autre approuve les dépenses.

Toutes les tables doivent avoir des déclencheurs qui créent des enregistrements d'audit. Vous cherchez à prévenir la fraude et si cela se produit pour déterminer exactement qui a pris les mesures à quel moment.

Dans les applications financières, vous êtes beaucoup plus concerné par de nombreux processus back-end qui ne sont jamais vus par l'interface utilisateur. Votre première préoccupation est de prévenir les fraudes et donc de nombreux contrôles dont personne n'a connaissance sont effectués dans le backend.

Je ne voudrais pas aborder une application financière de quelque nature que ce soit sans lire les PCGR (aux États-Unis, d'autres pays ont leurs propres normes comptables) et avoir un CPA en tant que consultant, car des pratiques comptables incorrectes peuvent entraîner des peines de prison. Il s'agit d'un domaine hautement technique et une personne n'ayant pas les connaissances requises n'a aucune activité à tenter de créer des logiciels dans ce domaine.

La comptabilité est souvent une question de vérification. Tant que vous vous en souvenez et comprenez la relation entre chaque entité, il est assez difficile de se tromper.

J'essaierai d'énumérer autant de vérifications que possible, mais j'en manquerai invariablement, j'espère que cela vous suffira pour commencer votre propre fouille.

Total Debits == Total Credits, cela est vrai que vous parliez de l'ensemble des comptes ou d'une seule transaction isolément. Si cela ne correspond pas, vous avez manqué au moins une publication quelque part. C'est ainsi que le grand livre s'équilibre.

Débiteurs (débits nets sur le compte de contrôle) == Total facturé (somme totale de tous les montants facturables) - Total reçu (somme totale de tous les paiements reçus). Ceci est un exemple de la façon dont la transaction totalise en termes de documents physiques et tangibles réels doit s'équilibrer avec le grand livre (double entrée).

Solde bancaire (selon votre relevé bancaire) == le total de votre grand livre général pour ce compte + tous les chèques reçus qui ne sont pas déposés - quels que soient les chèques émis qui ne sont pas encaissés. Registre.

Comme vous pouvez le voir, chaque transaction, grand livre, même stock, est directement liée au grand livre.

Si vous effectuez des tests unitaires, il est assez facile d'exécuter des tests qui garantissent que ces soldes existent à chaque fois que vous insérez / mettez à jour des transactions tant que vous savez quoi vérifier.

Bien sûr, il y a plus de soldes à vérifier / compter, mais vous devriez obtenir l'essentiel du travail requis. Essentiellement, tout s'équilibre avec tout le reste, qu'il s'agisse de documents physiques, d'articles du grand livre général, de relevés bancaires. C'est censé être un équilibre parfait, ou dans les cas où vous êtes paresseux pour gérer l'arrondi, presque parfait.

Plus vous pouvez effectuer de contrôles pendant que vous le développez, moins vous avez de chances de vous tromper.

BTW, lorsque vous traitez avec l'arrondi, essayez d'aller avec des décimales au lieu de flotteurs, cela vous évitera beaucoup de maux de tête sur la route. : P