1. An Introduction
Note a very crucial point: I recently discovered and I am highly convinced that, an Account is not the usual table which we are used to, rather an Account is not a simple table, its actually a Twin-table in my opinion and a bit more complicated.
2. A Glimpse of the big idea
Cash Account in XML format:
- <Cash>
- <CashAccount Effect="Dr.">
- <CashTransaction>
<Voucher_No.>NA</Voucher_No.>
<Date_Dr.>01/04/2011</Date_Dr.>
<Particulars_Dr.>To Balance b/d</Particulars_Dr.>
<Amount_Dr.>50000</Amount_Dr.>
</CashTransaction>
- <CashTransaction>
<Voucher_No.>S1</Voucher_No.>
<Date_Dr.>30/04/2011</Date_Dr.>
<Particulars_Dr.>To Sales a/c</Particulars_Dr.>
<Amount_Dr.>60000</Amount_Dr.>
</CashTransaction>
</CashAccount>
- <CashAccount Effect="Cr.">
- <CashTransaction>
<Voucher_No.>B1</Voucher_No.>
<Date_Cr.>01/04/2011</Date_Cr.>
<Particulars_Cr.>By Bank a/c</Particulars_Cr.>
<Amount_Cr.>10000</Amount_Cr.>
</CashTransaction>
</CashAccount>
</Cash>
If you convert the above XML code into a table, you get the following table:
Sales Account in XML format:
- <Sales>
- <SalesAccount Effect="Dr.">
- <SalesTransaction>
<Voucher_No.>SR1</Voucher_No.>
<Date_Dr.>30/04/2011</Date_Dr.>
<Particulars_Dr.>To Sales returns a/c</Particulars_Dr.>
<Amount_Dr.>5000</Amount_Dr.>
</SalesTransaction>
</SalesAccount>
- <SalesAccount Effect="Cr.">
- <SalesTransaction>
<Voucher_No.>S1</Voucher_No.>
<Date_Cr.>30/04/2011</Date_Cr.>
<Particulars_Cr.>By Cash a/c</Particulars_Cr.>
<Amount_Cr.>60000</Amount_Cr.>
</SalesTransaction>
- <SalesTransaction>
<Voucher_No.>D1</Voucher_No.>
<Date_Cr.>30/04/2011</Date_Cr.>
<Particulars_Cr.>By Sundry Debtors a/c</Particulars_Cr.>
<Amount_Cr.>50000</Amount_Cr.>
</SalesTransaction>
</SalesAccount>
</Sales>
If you convert the above XML code into a table, you get the following table:
Note: I admit that there are empty cells above which makes the database inefficient and that there are no implementations of normal forms. But for time being let that be as it is. As the main focus is on understanding the accounting architecture.
If you see the above tables carefully you will find that, the table has 2 parts, which are independent and unrelated directly to each other. The columns namely 'Date_Dr.', 'Particulars_Dr.' & 'Amount_Dr.' are recording Debit-effect of a transaction. While columns namely 'Date_Cr.', 'Particulars_Cr.' & 'Amount_Cr.' are recording Credit-effect of another transaction. Thus, as already said above that an Account is actually a Twin-table. Still there are 2 common columns shared by both the debit & credit parts namely 'Effect' & 'Voucher_No.' The 'Effect' column clearly mentions whether it is a debit effect or credit effect, while the 'Voucher_No.' mentions the transactions number, which will help in plotting the transactions across different ledgers in other words assure that there is a double effect making the account details.
Example:
The above transaction is of Cash sales, wherein the Cash A/c is debited (Debit what comes in.) for Rs. 60000 & Sales A/c is credited(Credit all incomes and gains.) for Rs. 60000 which is equally opposite effect.
Note: I admit that there are empty cells above which makes the database inefficient and that there are no implementations of normal forms. But for time being let that be as it is. As the main focus is on understanding the accounting architecture.
3. An Explanation
Example:
The above transaction is of Cash sales, wherein the Cash A/c is debited (Debit what comes in.) for Rs. 60000 & Sales A/c is credited(Credit all incomes and gains.) for Rs. 60000 which is equally opposite effect.
Following are 2 important features of the Twin-tables of an Account (read carefully):
- Its a twin table where in every account has one independent table for recording Debit effect of the transactions and another one for recording Credit effect of the transactions. And most importantly, the Debit-table and Credit-table of the Account are independent of each other. A transaction is recorded in either of those 2 tables and never in both the tables of the same account, as debiting an account & crediting the same account in the same transaction is meaningless and never happens.
- However, each Transaction in Debit table of one or more accounts has equally opposite effect in the credit table of another account or accounts and vice-versa, which can be traced by 'Voucher No.'. This is none other than the Principle of Double-effect itself.
Thus, XML can be used efficiently for storing Accounting Data, but only after implementing a 'Twin-table' technique it cannot be used to store accounting data efficiently as of now.
However, if you are still finding it hard to understand the principle of double-effect visit the following links:
However, if you are still finding it hard to understand the principle of double-effect visit the following links:
- http://www.futureaccountant.com/accounting-process/study-notes/accounting-principles-rules-of-debit-credit.php
- http://en.wikipedia.org/wiki/Double-entry_bookkeeping_system
- http://simplestudies.com/double-entry-accounting-system.html
Or download an e-book from the following link:
No comments:
Post a Comment