Introducing myself

Andrew Sackville-West andrew at swclan.homelinux.org
Thu Jan 3 17:46:02 EST 2008


On Thu, Jan 03, 2008 at 10:02:47PM +0000, mark carter wrote:
> Christian Bjerre Nielsen wrote:
> > 1. Take a look at this bug 501497 min Nor All GnuCash UNCO Values in
> > Gnucash reports are hard to import in spreadsheets. My
> > comments/requirements may be what you're looking for.
> >   
> Thanks - and it's interesting food for thought.
> 
> 
> I've been reading around that GnuCash was in its death throes (the posts 
> are probably a couple of years old) - although I see that it actually 
> quite an active project. Must have gotten a kick-start somewhere along 
> the line!
> 
> I just heard of a project called KMyMoney - and had a quick play with 
> it. Unfortunately, it doesn't seem extensible like GnuCash is; although 
> GnuCash certainly seems to have accreted code. KMyMoney does look like 
> it works out the gains for the period, so looks fairly limited from my 
> view-point.
> 
> I got an email from Andrew earlier, expressing his dissatisfaction with 
> the current state of the advanced portfolio report. Having read bug 
> 501497, I have thought that a good way to proceed would be if 
> transactions could be exported in tab-delimited format. I think there is 
> another bug report that suggested exporting in gnumeric format.

Just for some limited history and clarification. First, I'm
dissatisfied the with *concept* of the advanced portfolio report -- it
doesn't really do anything useful except report the complete history
of the portfolio from day one, along with some data about the current
state. It's really only usefulif you are comparing them from different
time periods. My feeling is that if that's what makes the report
useful, then that's what the report (or a replacement of it) should
do. 

A lot of people have attempted, some successfully, to implement the
features they want using outside tools. This usually is done by some
serious string crunching (perl?) of the data file and turning it into
a report external to gnucash. None of these, to my knowledge, have
widespread adoption because they are external. You can't just enter a
few txns, click "reload" on the report and see the results. You have
to jump through hoops: enter txns, export data, import data, process
data etc. So, IMO, it is vastly superior to implement code within
gnucash to process the information internally into the form desired. 

...

> * Bug 501497 raises the philosophical question as to whether reports or 
> transaction should be exported. My gut reaction would be to say that it 
> is the reports themselves that should be exported. However, in the 
> particular case that I'm talking about (portfolios), I might prefer to 
> take the transactions, and work out my own reports from them.

I don't really see it as all that complicated. You export what you
need. But the question of exporting txns is really orthagonal to the
question of reports that fulfil user requirements. I'm all for
exporting txns in it's own right. Many users request this. It should be
done simply because of that. If it makes external report writing
easier, great!

...
> 
> As an aside, the way I calculated return was as an IRR (i.e. taking 
> cashflows, and using current share price as a sales value for any shares 
> that remain). I didn't make a distinction between realised and 
> unrealised gain. However, it was a statistic that was quite useful to me 
> - because it represented a "true" compound rate of return (although 
> there are some philosophical objections to it), and I could guage how I 
> was doing against a market index.

IRR has been brought up a couple of times and I think there is some
demand for it. I don't really understand it, but I think it includes
some evaluation of risk, which may really be a problem. But I don't
know enough to speak to that, really.

> 
> After having a quick look, there doesn't appear to be a good way of 
> using gnucash from the command line.

nope.

> Guile is ideally placed for people 
> who want to mess around with GnuCash programmatically via guile scripts 
> - but unfortunately, guile looks to be embedded within GnuCash, and 
> there's no simple of way of getting at the innards from the
> outside. 

It would be nice to be able to reload the guile modules on the
fly. Derek had implemented it for his testing purposes, but I think
its probably bit-rotted,and apparently it never really worked well.

Also, Derek has pushed several times for implementing e-guile within
gnucash. That would change the report structure quite significantly by
allowing users to embed guile code into html documents. It might open
up the reporting quite a bit. 

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-devel/attachments/20080103/2906a382/attachment.bin 


More information about the gnucash-devel mailing list