couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Hinrichs - DM&T" <dunde...@gmail.com>
Subject Re: using CouchDB for a finance manager?
Date Wed, 15 Apr 2009 14:25:56 GMT
On Tue, Apr 14, 2009 at 10:50 PM, Antony Blakey <antony.blakey@gmail.com> wrote:
>
> 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.
>
It depends on the state of the transaction.  If it is unposted then
the entry should be marked as voided, if it is posted then absolutely
not.  Accounting software should have the same attributes as keeping
your ledger on paper and pen.  i.e. Once recorded it is permanent and
enduring.

Anyhow, it is not my project so I shall bow out of the conversation.


Regards,

Jeff Hinrichs

"Intellectuals solve problems, geniuses prevent them."
-Albert Einstein

> 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