What's your favorite year end method?

[Andrew Sackville-West]

On Mon, Dec 17, 2007 at 12:28:25PM -0500, Donald Allen wrote:
> I think it is pretty clear that the current reports implementation is
> a problem. 

...

I don't think you'll get any disagreement about this. 


> In an ideal world, gnucash would be as brilliant at making information
> of all that data that  it lets us accumulate so naturally, and in
> practice I think it fails in that regard (and, yes, I fully understand
> that this is a labor of love and that the developers have day jobs;
> I'm not being critical of anyone; I'm simply calling a spade a spade,
> at least as I see it).

see above.


> This is why I'm working on the Python program I
> mentioned in an email to this thread last night. I'm already getting
> income statement, balance sheet, net worth, and unrealized gains (with
> dividends) reports from it, sorted and presented the way I want
> them.

I don't want to speak for jsled, but he has talked a couple of times
about starting a next generation reporting system. He's even sketched
in some beginning design ideas (see -devel archives). The point is to
maintain the current reporting strucutre and keep it functioning while
a new structure gets put in place. This is no small task.

> Where they should, items it reports agree with gnucash to the penny.
> And it generates these reports in less than 30 seconds on a TP T60 (2
> Ghz Core 2 Duo). This was an act of desperation on my part, because I
> couldn't get gnucash to answer many key questions I had about my own
> finances, and a look at the reporting code led me to conclude that
> making an investment in improving what's there was not likely to be
> feasible or effective, given my time constraints and my worries about
> the performance of guile/scheme

I don't think anyone is married to Scheme. jsled wants to move the
option generation back into C and then any swig-ified language can be
used to generate reports. If I remember correctly, you are parsing the
actual data file instead of using the gnucash engine, correct? It
would be great if your efforts could be redirected at helping to
implement a new reporting structure instead :-)

also, just out of curiosity, how are you computing your unrealized
gains above? I'm having a terrible time getting the information I want
out of gnucash without relying on the user behaving in specific
ways. I have avoided things like using the Action field, for example,
in stock transactions because they aren't required to enter the
txn. 

A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.gnucash.org/pipermail/gnucash-user/attachments/20071217/25884015/attachment.bin