Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of dundeemt@gmail.com designates
 74.125.44.29 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:reply-to:in-reply-to:references:date:message-id
         :subject:from:to:content-type:content-transfer-encoding;
        b=tHXvjw/t9cMqTcU7P9ByyYolsdzVNuwZ+DjbWgxt2RVAAakaUKvTwUCxkJhrhOoAI7
         xWWnliogsDe7Bg8FTiAbf35ttd/tfubdKbh3IXCknIKyZZ9YAPdMzgPgpliivdkyQar7
         R0J9DbsmSefDFlUgrcURS9uRPT005fe5gTrJ4=
MIME-Version: 1.0
Reply-To: tech@dundeemt.com
In-Reply-To: <84324102-FCE6-447A-9F7A-F399911865E7@gmail.com>
References: <a6e65e8d0904122315s19eedbdcg61ce4b22ee3b162@mail.gmail.com>
	 <1A8CEBA7-32CF-4D47-BE52-6D31DB79B385@mac.com>
	 <55047b710904130929g451af4abw62e6ccd7281fbd77@mail.gmail.com>
	 <a6e65e8d0904141852i5fc16452jb06c395c8c7451d2@mail.gmail.com>
	 <5aaed53f0904142029v38576fadlbcfabf1f574b54ec@mail.gmail.com>
	 <84324102-FCE6-447A-9F7A-F399911865E7@gmail.com>
Date: Wed, 15 Apr 2009 09:25:56 -0500
Message-ID: <5aaed53f0904150725v6bbdc313k9a36799e97ae84f9@mail.gmail.com>
Subject: Re: using CouchDB for a finance manager?
From: "Jeff Hinrichs - DM&T" <dundeemt@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 14, 2009 at 10:50 PM, Antony Blakey <antony.blakey@gmail.com> w=
rote:
>
> 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. =A0google "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. =A0i.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.) =A0Your 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. =A0Which
>> means, you should calculate balances on demand. =A0Once you close a
>> period, you can create a summary balance for the period end to avoid
>> calculating over years and years of transactions. =A0Closing 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 th=
e
> 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 n=
eed
> 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 thi=
s
> 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 =96
> In itself =96 a quiet thing
> That may furnish the Fuse unto a Spark
> In dormant nature =96 lain =96
>
> Let us divide =96 with skill =96
> Let us discourse =96 with care =96
> Powder exists in Charcoal =96
> Before it exists in Fire =96
>
> =A0-=96 Emily Dickinson 913 (1865)
>
>