Advanced portfolio report

[Andrew Sackville-West]

On Thu, Nov 29, 2007 at 10:05:15PM -0500, Morrison J. Chang wrote:
> On Thu, 2007-11-29 at 12:32 -0800, Andrew Sackville-West wrote:
> > > whoops, that version is broken, disregard. 
> > 
> > here is one that actually works ;)
> > 
> > comments please
> > 
> 
> I'll make my code comments in my response to your comments.
> (In any case both of us are still failing cases..)
> 
> Attached is copy of my test file.
> 
> Looking at the report entry for Vanguard Test.
> 
> With the NAV value as 62.00
> I see a Money In as 997.50 which doesn't seem right.

you're right. I've got a dividend collector (dividendcoll, was in the
original report) sitting unused. It needs to be 'merge-ed into the
money-in collector to make that work properly. I left it floating
there as I'm still not really sure how to handle that whole income
thing. And it also depends on exactly what "money-in" is. If its truly
all money that moves "into" the account then that dividend income
should be 'merged back in to the moneyin-coll. I'll post this simple
change later today.

Another possibility that occurs to me is to create YAColumn for
"Income". That would count all income txn-splits in the account. That
doesn't solve the IRA contribution problem, but does break out how
much of the return comes from dividends and allows the gain to be
clean of that money. 

Really that might solve a lot of problems. RIght now gain is
calculated from the current value and money-in or basis depending on
which gain is being calculated. But reinvested dividends increase the
value but shouldn't cause a gain. That dividend-coll should be
substracted from the gain numbers and then listed separately so its
clear. 

Then the IRA question becomes simple -- the user has to move that
money into an interim account before it moves into the stock. That
makes it no longer look like income relative to the stock and *also*
probably more accurately reflects reality -- those paymetns are always
delayed.

I think the thing to do is figure out which version of this report to
use and get it cleaned up and committed as it currently stands. Then
go back in and add the feature of another frickin' column. How many is
too many? 

The current report is so broken, that I think we could get the devs to
backport a fixed version into 2.2.x to help alleviate the current bug
stack and then move with improvements to the report for 2.4 

.02

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/20071130/8a577031/attachment.bin