The Idea of 'Common Account-Table Oriented Database Scheme'

1. Account-Table Architecture

The big idea is to develop a concept of 'Complex table'. A 'Common Account-Table' in financial accounting is an instance of 'Complex table'.

And also an account is an object. In fact, an account-table is a special object. 

I understand that this might sounds like a tricky concept to grasp and might even be outrageous. But then it isn't true, rather this is a simple concept and has enormous scope within it.

2. Using XML

The main reason which motivates me to propose the above idea is the problems of handling XML technology. Yes, although XML is a brilliant technology but it is never handled with broad vision in mind, and the reason is that, different Soft wares have different Schema of XML, so its not possible to map the financial transactions across different Financial Software Systems. Tell me if I am wrong...... Perhaps that is why XBRL which has evolved out of XML which is used only for consolidated financial reports is not so useful for intrinsic Audit Work like vouching and verification.

2. Meteoric Advantages of 'Common Account-Table Oriented Database Scheme'

Now imagine that what would happen after implementation of 'Common Account-Table Oriented Database Scheme' or 'CATODS'? Till now I have reckoned the following benefits: 

1. Transfer of Accounting Data with its double effect in heterogeneous environment: Firstly, Accounting transactions in detail would be transferred in heterogeneous environment. I reckon that, this itself would bring great revolution in the Accounting world as well as in the field of Auditing. As it would then be very easy for Accounting and Auditing and even Banking concern to procure and transfer data of detailed transactions along with the 'Principles of Accounting' being intact and thereby performing operations efficiently.
2. Reliability and Accuracy: Since the implementation of double effect is now possible there can be higher level of reliability and accuracy of financial data.
3. E-Vouching for Financial Audit: The other most important benefit would also be that, there can be a technology constructed to facilitate the Accounts Auditor's 'vouching' and 'verification' work on a very large-scale. This thing really excites me! as this would bring down considerably the chances of fraud and error.
4. A GPS-system of global-finance: Well, with the above development I see there is a way to keep a global track of finance by unifying the accounting system of every organisation globally. This would then eradicate the possibility of fraud, black-money, tax-theft, etc.

3. Account-Tables are 'Special Objects'

But first, let us see and understand, how accounts are objects?
An 'Object' has state, behavior and identity.
An 'Account-Table' too has state, behavior and Identity, but they are very simple indeed. To know how, read the following:

• States of an Account-Table: An account-table can be closed i.e. balance = nil or an account-table may have a debit balance or a credit balance. Thus, the above are the 3 possible states of account-tables and there is no 4th state of account-tables. Isn't that amazing?
• Behavior of Account-Table: Again an account only has 2 possible behavior either it will be debited or credited as a part of transaction.
• Identity: Of course, an account-table will also have an unique identity.    

Apart from being an object account-tables are also special object lets see how?
All the features of OOPS, namely Abstraction, Encapsulation, Polymorphism and Inheritance can be applied to account-table, when needed, but in addition to the above 4 there is a 5th feature i.e the principle of 'Double-effect'. And this makes the account-tables a special object.

4. New Account-Table Architecture

In the above, Account-Table architecture, the idea of normal forms has not been implemented that is why if we convert it into table there are empty cell.

To avoid it, lets make a new architecture, wherein there is no possibility of empty cell.

In the above architecture notice that there is no common attribute. There is a complex table namely Account and there are 2 sub-tables namely the 'Debit Table' and 'Credit Table'.

Accordingly what you get is the following:

Debit Table in XML format:

<Cash_DebitTable>

<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>

</Cash_DebitTable>

Credit Table in XML format:

<Cash_CreditTable>

<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>

</Cash_CreditTable>

In the above table Cash A/c is an account-table and has 2 sub-tables namely Debit Table and Credit Table. Here Debit table and Credit table are independently recorded because XML only allows recording of simple tables and not complex tables and thereby fails to implement over the 'double-effect principle'. If you refer to my earlier blog you I have mentioned 2 important features of an Account transactions.

Click the following:

The Twin-table technique