Sunday 3 July 2011

Accounts in XML format: The Twin-table technique

1. An Introduction
Although there is availability of XBRL (Extensible Business reporting Language), which is made by application of XML. And XBRL I believe that can store accounting data in a simple table easily and not only that it can store but also process accounting data and can produce reports as desired. However, I am determined to find out a way for storing Accounting data along with its double effect by re-inventing the table structure itself. And I propose a 'Twin-table' technique for implementing the idea. 


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
Even after knowing that it is not so practical to use XML for storing accounting data with its double-effect, yet for time being just to give a glimpse of what is there in my mind I am using simple XML tags for recording few transactions with double-effect. So far, I found and have tried many ways to do that but the best of them is below:
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.

3. An Explanation                                          
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.

4. Principle of double-effect at work
5. Features of Twin-Table of an Account
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:

Or download an e-book from the following link:


No comments:

Post a Comment