couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <antony.bla...@gmail.com>
Subject Re: using CouchDB for a finance manager?
Date Wed, 15 Apr 2009 03:50:54 GMT

On 15/04/2009, at 12:59 PM, Jeff Hinrichs - DM&T wrote:

> On Tue, Apr 14, 2009 at 8:52 PM, Li Zhengji <zhengji.li@gmail.com>  
> 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.

You need to be able to delete and modify entries when you discover  
after the fact that you were mistaken about reality e.g. you entered  
$21.35, but the bank statement shows $21.53.

I think the best solution to this is to treat each ledger entry as a  
document, with the balance being computed by the view reduction. If  
you need to capture a point in time, create another document from the  
view result and encode it as a specific 'point in time' document. I  
use a system like this that treats the bank statement entries as the  
canonical data that is subsequently annotated, and I capture snapshots  
of accounting state so I know the basis of the calculations I use when  
I submit monthly/quarterly results to the tax department. If the point  
in time snapshot and reality retrospectively diverge, I have a  
permanent record I can use for making sense of the compensating  
payments/claims.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

A Man may make a Remark –
In itself – a quiet thing
That may furnish the Fuse unto a Spark
In dormant nature – lain –

Let us divide – with skill –
Let us discourse – with care –
Powder exists in Charcoal –
Before it exists in Fire –

   -– Emily Dickinson 913 (1865)



Mime
View raw message