Progettazione del database di contabilità a doppia entrata

Sto creando software di contabilità. Devo imporre la contabilità in partita doppia. Ho il classico problema di una riga per transazione rispetto a due righe.

Facciamo un esempio e vediamo come verrebbe implementato in entrambi gli scenari.

Considera account Cashe account Rent. Quando pago l'affitto mensile, trasferisco $ 100 dal mio Cashaccount al mio Rentaccount.

Una riga per transazione

In un sistema a una riga, tale transazione verrebbe memorizzata come:

transazioni

 tx_id | posting_date
 1     | 23/05/2015

transaction_records

 id | tx_id | credit_account | debit_account | amount
 1  | 1     | Cash           | Rent          | 100.00

Due righe per transazione

In un sistema a due file, dovrei rispecchiare lo stesso record di transazione per creare un record opposto che una volta sommati entrambi, otterrei un saldo pari a zero.

transazioni

 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

Il problema

Prima di tutto vorrei sottolineare: il motivo per cui ho entrambi transactionse le transaction_recordstabelle (anziché una tabella) è quello di essere in grado di gestire le transazioni divise (un caso in cui trasferisco $ 100 dal Cashconto a due o più conti diversi).

All'inizio ho provato a implementarlo con una riga per transazione, ma è una seccatura calcolare il saldo del conto e recuperare effettivamente i dati.

Mi sto inclinando verso il secondo scenario; tuttavia, presenta anche alcuni problemi:

• Come aggiorno un singolo record? Supponendo di aver fatto un errore e invece di registrare $ 100 per il mio affitto, ho registrato $ 10. Ora ho 2 transaction_records- uno per il credito e uno per il debito, entrambi con un importo di $ 10.
• Ora faccio la mia riconciliazione e voglio correggere questo errore di battitura. Come lo risolverei nel database? Non conosco la connessione tra i record e, in caso di divisione, una transazione può avere più di 2 record. L'unica soluzione che mi è venuta in mente è di aggiungerne alcuni ref_idper ogni coppia di record che identificherà in modo univoco quei record come "lati opposti l'uno dell'altro" all'interno di un contesto di uno specifico tx_id.

Quale approccio è migliore / più semplice?

Per semplificare la mia domanda: voglio rappresentare un movimento di fondi dal conto A al conto B. I due scenari che ho fornito sono entrambi progetti validi per archiviare tale transazione. Come ho anche sottolineato, entrambi hanno contro e pro (il primo: più facile da salvare, più difficile da recuperare; il secondo è l'opposto).

Potrebbero avere altri pro / contro che non vedo in questo momento, quindi chiedo un parere a persone più esperte.

In effetti, lo schema contabile a riga singola proposto consente di eseguire correttamente la contabilità a doppia registrazione (per specificare sempre l'account addebitato e accreditato) senza introdurre la ridondanza dei dati "importo".

Lo schema a una riga fornisce un'implementazione di una doppia voce che equilibra per costruzione, in modo che sia impossibile "perdere l'equilibrio". La macchina può ricalcolare i registri al volo.

Devi fare 2 selezionare invece di uno per recuperare un libro mastro.

Nota, oltre alla suddivisione delle transazioni, ci sono altre transazioni come la valuta estera che potrebbe finire con 2 record invece di 4. Tutto dipende se si denormalizzare un po 'basta inserire 4 transazioni con una descrizione simile.

È possibile impedire l'immissione o la modifica di qualsiasi transazione per mantenere una pista di controllo, ciò è necessario se si desidera poter controllare il registro delle transazioni.

Sembra che nel thread sopra, per il CPA, "completamente normalizzato" significhi regole riconosciute da tutti i contabili, mentre per il programmatore ha un significato diverso, che non ci sono dati derivati ​​o ridondanti memorizzati.

Tutto ciò che resta dei dati contabili è un insieme di transazioni che danno importo e conti da cui e verso cui fluiscono, insieme alla loro data, una descrizione (e altri allegati). I registri e i saldi sono viste semplici derivate da questi dati transazionali facendo somme.

Un diario è un elenco cronologico di tutte le transazioni di un tipo specificato per un sistema contabile. Ecco una presentazione classica su un libro mastro di un semplice diario di vendita (su conto):

Si noti che ogni riga è una singola transazione, con Totale debiti = Totale crediti; e che ogni transazione raggiunge gli stessi tre account. Un diario delle vendite in contanti sembrerebbe simile ma sostituisce la colonna Debito verso clienti con un debito in contanti etichettato . Un diario delle erogazioni in contanti avrebbe una prima colonna etichettata Credito in contanti e colonne aggiuntive come Debito debiti e Debito spese dipendenti .

Questa presentazione è stata standard per centinaia di anni fino a quando i personal computer sono diventati accessibili un paio di decenni fa. Ha un vantaggio significativo nel verificare facilmente che ogni transazione sia bilanciata semplicemente controllando ogni riga. Allo stesso modo, prima di pubblicare una pagina di tale transazione nei libri contabili, i totali delle pagine potrebbero essere verificati in modo simile. Questo è un modello di elaborazione batch utilizzato in molti sistemi contabili.

È facile intuire che questo modello cartaceo presenta notevoli svantaggi se trascritto letteralmente in un sistema automatizzato:

1. La struttura dei dati è articolata, mentre l'esperienza ha dimostrato che è molto più semplice (anche più robusto e più facilmente verificabile) programmare su una struttura di dati ripiegata; e
2. Perché ogni specializzata Journal colpisce un diverso insieme di conti, ognuno di tali ufficiale dovrebbe essere progettato e programmato a parte, un'attività dispendiosa e soggetto ad errori.

Per questi motivi, si consiglia generalmente di utilizzare il design Riviste specializzate come interfaccia per il sistema contabile, ma di progettare una struttura di dati che può essere il repository numerico per più riviste. In un RDBMS moderno questo ha il potenziale vantaggio che il registro generale , e persino i subledger specializzati , possono diventare viste indicizzate sul diario, eliminando completamente il requisito di codificare un processo di registrazione (il passaggio in cui una transazione del diario è bloccata e ha il suo account totali trascritti nei vari registri).

Qualunque sia il progetto di dati che si ottiene, la chiave è avere una singola registrazione contabile per ciascun tipo di transazione (ovvero ogni giornale specializzato nel sistema cartaceo equivalente) in cui vengono effettuati i controlli del saldo.

Il mio punto è che entrambi gli approcci che proponete sono meccanismi privi di fondamento per la contabilità in partita doppia. Primo punto: le riviste sono tabelle scrivibili una sola volta per ottime ragioni. A volte le due tabelle virtuali Voci in sospeso e Voci registrate sono collocate in una singola struttura di dati, ma il bit IsPosted è sempre di sola scrittura e il sistema deve garantire che sia mantenuta la natura di sola lettura dei record delle voci registrate.

Il modo in cui i contabili hanno pubblicato voci di diario negli ultimi 800 anni è completamente normalizzato . L'unica differenza tra una presentazione cartacea e una solida presentazione elettronica è che una struttura di tabella piegata è più conveniente in quest'ultimo caso mentre una struttura di tabella imperniata nella prima, che storicamente era più significativa quando si desiderava un'elaborazione altamente parallela - cioè molti impiegati ciascuno mantenendo un numero singolo o ridotto di riviste specializzate. Solo il controllore aveva storicamente le autorizzazioni per il giornale generale.

Notare attentamente che in quanto sopra ho specificato che le voci di diario sono completamente normalizzate; Le voci del diario sono un registro cronologico di tutte le transazioni, raggruppate in riviste specifiche per ciascun tipo di transazione. La registrazione di registrazioni a giornale nei libri contabili è un'attività separata e, sebbene completamente normalizzata di per sé, è una copia ridondante delle registrazioni a giornale in cui tutte le transazioni sono riepilogate (libro mastro generale) o dettagliate (libro mastro secondario) per conto. Sia le riviste che i registri utilizzano la contabilità a doppia iscrizione in modo indipendente.

@Codism Qualsiasi sistema di contabilità, DEB o SEB, fornisce report generalizzati per tutti gli account registrati . Si noti che, internamente, un libro mastro è per definizione un record di contabilità a partita singola; l'altra parte sono i conti di controllo corrispondenti nel bilancio. DEB garantisce che per ogni dollaro di attività sia presente un registro preciso del credito commerciale sull'attività , vale a dire l' equità nell'attività, che si tratti di un capitale di debito (aka passività) o di un capitale di proprietà , e della priorità di tali crediti se il l'organizzazione diventa insolvente.

Posso suggerire di dare un'occhiata al tesoro del software Open Source che è là fuori in questa area?

Un Google di " software di contabilità a doppia entrata open source " offre diverse promettenti vie di indagine.

Puoi dare un'occhiata al pacchetto di contabilità GNU qui , un paio di siti di recensioni ( 1 e 2 ) e infine la wiki del software di contabilità con una sezione sul software libero.

Sono sicuro che esaminando alcuni del codice sorgente e degli schemi F / LOSS, potresti ottenere alcuni buoni suggerimenti e indicazioni su come scrivere schemi e / o software adatti alle tue esigenze particolari.

Ho un sistema che fa doppie linee e presenta molte sfide rispetto ad avere conti a linea singola. Per prima cosa ho riscontrato casi in cui una sola riga veniva spinta come il lato debito, risultando in un conto sbilanciato. Anche se non sto eseguendo controlli adeguati su commit e rollback, ciò non accadrà in una sola riga. infine, il tuo db cresce con un doppio tasso di crescita, la tua seconda riga di invio avrà molte informazioni duplicate, l'unica differenza è il secondo account. Consiglierei mantenere, account a linea singola, sto andando a quella rotta ..