Quali considerazioni speciali sono necessarie quando si progettano database per conservare registri finanziari?

Spero che questa domanda non sia troppo ampia. In futuro potrei dover aggiungere alcuni sistemi di contabilità e monitoraggio finanziario ad alcune applicazioni (principalmente applicazioni basate sul Web, ma le mie domande riguardano anche le app desktop).

Ora, la creazione di un semplice registro delle transazioni finanziarie è teoricamente facile. Una tabella di database con alcune colonne potrebbe fare il lavoro. Anche MS Access, Excel o anche solo un semplice file di testo ASCII potrebbero essere utilizzati per memorizzare date di transazione, ID account e importi in dollari. Tuttavia, ritengo che anche una tabella SQL con backup frequente con integrità transazionale potrebbe non essere abbastanza solida per un serio monitoraggio finanziario.

Sento termini come "contabilità in partita doppia" e ho la sensazione che la maggior parte delle app di tracciamento finanziario (ad esempio, Mint.com o GnuCash) abbia una struttura o un processo di dati molto più complicati per garantire che tutto sia doppio si somma perfettamente, esattamente come dovrebbe, e che nessun dato viene mai perso o danneggiato.

La mia domanda è: quando si progetta un'app per tenere traccia delle transazioni finanziarie, quali speciali considerazioni di progettazione dovrebbero essere fatte? Sembra che potrebbero esserci così tanti potenziali problemi ... problemi con precisione di arrotondamento, controlli di parità, qualche tipo di processo di controllo, backup speciali, sicurezza / crittografia, modi extra per proteggere i dati in caso di crash durante l'immissione dei dati. ... Non so davvero cosa dovrei chiedere in modo specifico, ma ho la sensazione che l'industria della programmazione abbia una serie di migliori pratiche di cui non so nulla. Quali sono?

Modificare:

Sembra che abbia aperto una lattina di vermi più grande di quanto mi aspettassi. Per chiarire, sto pensando specificamente a due tipi di app:

1. App di tipo "Controlla registro" come GnuCash o Quicken che mantengono un registro delle transazioni individuali per uso personale.
2. App che tengono traccia della fatturazione / credito / o "punti" per fornitori e clienti che trattano con un'azienda.

Probabilmente non farò alcuna attività di direct banking o (AFAIK) qualsiasi cosa che abbia un sacco di regolamenti governativi relativi alla finanza collegati.

Ne conseguirò molte risposte, ne sono certo, anche molte risposte idealiste, posso solo rispondere dalla mia esperienza in materia finanziaria e da ciò che accade realmente.

Hai già coperto la maggior parte dei problemi.

La precisione dell'arrotondamento tende a non essere in realtà un grosso problema nella mia esperienza. La maggior parte delle grandi organizzazioni finanziarie che non sono cresciute dall'oggi al domani (cioè tutto tranne gli hedge fund) hanno una vasta gamma di applicazioni legacy che sono divise a causa di vari carburanti. Tendono a non arrotondare costantemente la precisione; generalmente un certo utile e perdita di errore è semplicemente accettato per arrotondamento. In effetti, molte ore di lavoro sono trascorse in luoghi in cui ho lavorato, dove gli umani hanno i selettori di "sì che sono abbastanza vicini" quando si tratta di abbinare somme esatte / attese. Ricorda, questa è una risposta basata sulla realtà, non su ciò che dovrebbe accadere.

Crittografia: non fare affidamento su di essa francamente. Conservare i dati identificativi in ​​un sistema fisicamente e logicamente separato rispetto ai dati non identificati (ad es. Codice account ovunque, dati personali separati).

Generalmente, mentre sono richiesti backup, i backup offline sono raramente chiamati a fare ricorso, a quel punto le cose sono andate male. Generalmente sono richieste copie di produzione calde, tuttavia ciò dipenderà dalle vostre esigenze specifiche. In pratica, disponiamo di una copia di produzione in loco a caldo di tutti i sistemi E di un sito di ripristino di emergenza con produzione propria e copie a caldo. Le copie calde tendono ad avere qualche minuto di ritardo nella replica, ecc.

Il controllo è la chiave di ogni sistema finanziario su cui abbia mai lavorato. Hai 2 requisiti fondamentali A) Puoi tenere traccia di ogni singola modifica apportata ai dati, da chi, quando e perché? B) Puoi provare lo stato storico dei tuoi dati? Che non è stato manomesso?

A) è richiesto per i team operativi: il tuo sistema verrà utilizzato in 100 modi che non ti aspettavi e queste informazioni sono vitali per l'espansione, i rapporti ad hoc, i motivi legali e il debug.

B) Vedi il caso AMEX vs. Vee Vinhnee - in cui AMEX non è stato in grado di raccogliere 40k dovuti a loro in quanto non sono stati in grado di provare che i loro record non fossero stati compilati. La soluzione generalmente usata per questo è la timestamp affidabile. I grandi finanziari dispongono di banche garanti che garantiscono transazioni e quindi intrinsecamente timestamp attendibile. Ci sono fornitori commerciali per questo per altri ceti sociali / scenari.

Le considerazioni sono principalmente legali . Se lo guardi solo dal punto di vista della sicurezza / affidabilità, un foglio Excel potrebbe non essere intrinsecamente meno sicuro di un foglio di carta in un cassetto. L'accesso all'integrità transazionale può essere migliore di quello di un impiegato che viene interrotto da una chiamata.

Ma, affinché i tuoi clienti possano usarlo, devi renderlo conforme alle leggi locali. Alcune cose che ho incontrato (in Germania)

• Formati di documenti per questioni di archiviazione , perché esistono leggi che le aziende devono conservare i documenti per 10 anni. Tra 10 anni, forse il tuo programma non sarà più disponibile. Pertanto, è necessario archiviare i documenti in modo certificato DIN / ISO (.pdf sembra essere sufficiente in Germania)
• Le tracce di controllo sono spesso necessarie, ad esempio potrebbe essere necessario presentare versioni diverse dello stesso documento, con date di modifica.
• La posizione dello spazio di archiviazione è importante a causa del "Datenschutz" (privacy), che può essere diverso nel paese di archiviazione. Ciò rende i servizi basati su cloud un po 'complicati.
• Alcuni documenti devono essere archiviati in modo non modificabile . come esattamente questo risultato sembra dipendere principalmente dal nitpicking legalistico (un documento è immutabile, un cd è mutabile, un cd firmato da un lavoratore non lo è)

È necessario contattare in via definitiva un avvocato, per dettagli, o almeno lavorare in stretta collaborazione con un cliente.

I fattori di affidabilità diventano incredibilmente importanti quando hai a che fare con il denaro delle persone. Se Twitter perde un tweet, non è un grosso problema; se addebiti la carta di credito di qualcuno ma perdi il suo ordine, qualcuno nella tua organizzazione riceverà un guadagno da un cliente arrabbiato. Quindi due cose: 1. Non vuoi che ciò accada in primo luogo, ma 2. accadrà alla fine, non importa quanto stai attento, quindi vuoi mettere MOLTA energia nel tipo di meccanismi di registrazione e tracciamento che ti aiuterà a tornare indietro e trovare l'ordine "perso" e correggere la situazione.

La cosa peggiore in assoluto è avere, ad esempio, un addebito sulla carta di credito, ma NESSUN record a tutto ciò che serve, a chi appartiene, ecc.

Per motivi finanziari, devi davvero riflettere anche sugli scenari apparentemente super-improbabili e pianificare come gestirli: "Abbiamo addebitato la carta di credito, ma il server del database è inattivo prima di poter aggiornare il record corrispondente". OK, adesso? Annullare la carica? Registra la transazione su un file in modo che un essere umano possa risolverlo in un secondo momento? Ok, cosa succede se il disco è pieno e non riesci a scrivere sul file? Ecc. Ecc.

[1] Utilizza le tabelle di sicurezza (non confondere con gli utenti DB interni) per gli utenti e per la tua app. moduli, moduli, pagine Web:

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

[2] Non eliminare i record nella tua app. Utilizza un campo di stato, forse intero, forse booleano o bit, che indica che il record è considerato "eliminato". Crea la tua app. mostra i record che non vengono eliminati (contrassegnati come eliminati da quel campo) e crea alcuni moduli per i casi speciali, in cui l'app. mostra i record contrassegnati come eliminati.

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

Questa funzione si chiama "cancellazione virtuale". La vera cancellazione è chiamata in modo definitivo "cancellazione fisica".

[3] Usa i campi in tutte le tabelle relative all'accesso, archivia l'utente (singolo) che crea il record e (l'ultimo) utente che ha modificato il record e il datetime, se possibile aggiungi il modulo o l'opzione in cui era ogni record modificata:

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

[4] In alcuni casi, i valori di valuta o denaro possono influire sui risultati, se utilizzati in diversi record in un dettaglio e, aggiunti in un singolo valore, in un record di intestazione.

La maggior parte dei marchi di database supporta, al giorno d'oggi, un campo dati in valuta o denaro. Usalo

In alcune circostanze speciali, alcune persone li memorizzano in un valore float fisso che supporta diverse cifre decimali, ("decimali") o anche come valori stringa.

Questa tecnica è un'arma a doppio taglio. Se la tua applicazione richiede quel tipo di presunzione, cerca nel web un tutorial su come implementarlo correttamente.

Saluti. [non dimenticare di dare una scatoletta di tonno aperta al gattino, o scatenare il voto]

Hai taggato la tua domanda con securityma stai principalmente parlando di coerenza e affidabilità, quindi proverò a rispondere a quella parte dell'equazione:

• Utilizzare le transazioni del database per garantire l'integrità delle operazioni batch. L'esempio più semplice è un trasferimento tra due account: uno viene detratto l'importo e l'altro viene accreditato. Utilizzare le transazioni per garantire che non si verifichi mai un trasferimento parziale (viene cambiata solo una parte).
• Per precisione, utilizzare il DECIMALtipo anziché i float. I calcoli sono molto più lenti ma non dovresti sentirlo poiché la maggior parte dei calcoli finanziari sono molto basilari
• Utilizzare la replica per uptime e hotcopies per il backup. Dovresti anche guardare le istantanee LVM per il recupero

Alcune delle considerazioni che vedo sono che devi tenere conto dei controlli interni. Ciò significa che tutti gli accessi per le azioni contro le tabelle (Inserisci / elimina / aggiorna) devono avvenire tramite processi memorizzati (e nessun SQl dinamico) in modo tale che nessuna tabella consenta diritti di scrittura o eliminazione direttamente sulla tabella a chiunque tranne un amministratore di sistema. Devi anche tenere conto dei controlli interni che non consentono a qualcuno di creare una nuova società e quindi addebitare articoli a quella società (un percorso per frode). Azioni del genere richiederanno sempre l'approvazione di persone con due ruoli diversi. Inoltre, i controlli non devono essere tagliati a meno che una persona non inserisca i dati e un'altra approvi la spesa.

Tutte le tabelle dovrebbero avere trigger che creano record di controllo. Stai cercando di prevenire le frodi e se accade per determinare esattamente chi ha intrapreso le azioni quando.

Nelle applicazioni finanziarie, sei molto più interessato a molti processi di back-end che non vengono mai visti dall'interfaccia utente. La tua prima preoccupazione è prevenire le frodi e quindi molti controlli di cui nessuno è a conoscenza vengono effettuati nel backend.

Non affronterei un'applicazione finanziaria di alcun tipo senza leggere attentamente i GAAP (negli Stati Uniti, altri paesi hanno i propri standard contabili) e avere un CPA come consulente in quanto pratiche contabili errate possono portare al carcere. Questo è un campo altamente tecnico e qualcuno senza la necessaria conoscenza non può tentare di creare software in quest'area.

La contabilità riguarda spesso la verifica. Fintanto che lo ricordi e capisci la relazione tra ogni entità, è piuttosto difficile sbagliarla.

Cercherò di elencare quanti più controlli posso ma inevitabilmente ne mancherò alcuni, speriamo che ti basti iniziare a scavare da solo.

Totale debiti == Totale crediti, questo vale sia per l'INTERO set di conti sia per una sola transazione isolata. In caso contrario, hai perso almeno un post da qualche parte. Questo è il modo in cui la contabilità generale si bilancia da sola.

Crediti verso clienti (addebiti netti sul conto di controllo) == Totale fatturato (somma totale di tutti gli importi fatturabili) - Totale ricevuto (somma totale di tutti i pagamenti ricevuti). Questo è un esempio di come la totale della transazione in termini di documenti FISICI e tangibili effettivi dovrebbe essere bilanciata con la contabilità generale (doppia registrazione).

Saldo bancario (secondo il tuo estratto conto) == Il totale della contabilità generale per quel conto + qualsiasi assegno ricevuto che non sia depositato - qualunque assegno emesso che non sia stato depositato. Questo è un esempio di come i conti bancari / in contanti coincidono con il Generale Ledger.

Come puoi vedere, ogni transazione, contabilità generale, persino azioni, si lega direttamente alla contabilità generale.

Se si eseguono test di unità, è abbastanza facile eseguire test che assicurino che questi saldi esistano ogni volta che si inseriscono / aggiornano transazioni purché si sappia cosa controllare.

Naturalmente ci sono più equilibri da controllare / sommare, ma si dovrebbe ottenere l'essenza del lavoro richiesto. In sostanza, tutto è in equilibrio con qualsiasi altra cosa, che si tratti di documenti fisici, voci di contabilità generale, estratti conto bancari. Dovrebbe essere un equilibrio perfetto, o nei casi in cui sei pigro per affrontare gli arrotondamenti, vicino alla perfezione.

Più controlli puoi eseguire mentre lo stai sviluppando, minori sono le probabilità che tu abbia qualcosa di sbagliato.

A proposito, quando hai a che fare con gli arrotondamenti, prova ad andare con i decimali invece che con i galleggianti, ti farà risparmiare un sacco di mal di testa lungo la strada. : P