On Tue, Apr 14, 2009 at 8:52 PM, Li Zhengji <[email protected]> wrote: > Thanks for your information that makes me confident to use CouchDB for > this task. > > Before getting start, I think to calculate the balance seems > difficult, no matter it is schema-less or not. > > For example, if I delete a older transaction, then all balance in > following transactions must be updated one after another. For CouchDB, > maybe some views need to be rebuilt, too. It seems to be time > consuming. (Suppose there is a balance field in each transation --- > CouchDB doc.) > > Any idears for this? Yes -- Accountants do not use erasers. google "accountants don't use erasers" No financial system should allow deleting entries -- posted entries. The application should allow for user errors, etc and create a way to correct wrong things but only by appending additional information on how that entry was corrected. i.e. If I incorrectly transfer 10000 from accountA -> accountB but only wanted to transfer 100, you should not delete the original transaction but instead either transfer the entire amount back with a notation for the reason and then initiate the correct transfer amount or transfer back 9900 from accountB -> accountA with a proper notation. (I prefer the former as it more accurately represents the problem and solution instead of mixing them together into a single correcting transaction.) Your balances in previous transactions would not need to be "updated" and should not be and really a balance is a report of status at a point in time. Which means, you should calculate balances on demand. Once you close a period, you can create a summary balance for the period end to avoid calculating over years and years of transactions. Closing a period means that it can not be modified by transactions posted after it is closed.
> 2009/4/14 Nicholas Orr <[email protected]>: >> I've looked into doing my own accounting app as well. Sitting with an >> accountant the main thing she had an issue with, in regard to all the >> products currently available, is tracking what the amount is for on each >> side of the transaction. >> >> Example, say I as an individual transfer $10K into a company I'm a director >> of. On the individual side (withdraw) of the transaction info needs to be >> recorded as one thing, then on the other side (deposit) different >> information needs to be recorded. This whole transaction needs to exist in >> both places so come tax time the account doing the work for tax can follow >> everything simply. >> >> The concept of schema-less documents now starts to shine as ideal. I have a >> few other projects on the go right now and will not be getting to this one >> anytime soon. Interested in what you guys come up with :) >> >> Nick >> >> >> > -- > Li Zhengji > ------------------------------------------------------------- > If all you have is a hammer, everything is a nail. > ------------------------------------------------------------- > Regards, Jeff Hinrichs
