On 15/04/2009, at 12:59 PM, Jeff Hinrichs - DM&T wrote:
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.
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)
