error in advanced portfolio report (svn r16781)
Andrew Sackville-West
andrew at swclan.homelinux.org
Thu Jan 3 00:15:46 EST 2008
On Wed, Jan 02, 2008 at 11:19:16PM -0500, David Reiser wrote:
>
> On Jan 2, 2008, at 8:43 PM, Andrew Sackville-West wrote:
>
>>> a few lines above the scm that appeared in the last report, I get:
>>>
>>> * 17:59:57 DEBUG <gnc.scm> b-list is ((#<<gnc-numeric> num: 4189799520000
>>> denom: 204700000000> . #<<gnc-numeric> num: 72682214900000000 denom:
>>> 418979952000000>)) b-units is #<<gnc-numeric> num: 0 denom: 10000>
>>> b-value
>>> is #<<gnc-numeric> num: 0 denom: 100> b-method is average-basis
>>
>> You have a txn with no shares and no value in the split that touches
>> this account. What is the other side of that transaction? What are you
>> trying to do with that txn?
>>
>> It's a real bug, no doubt, but I want to make sure it gets handled
>> properly -- there is no code to handle that case, duh, so its
>> <#unspecified>. So if you can find that txn, and tell what it looks
>> like and what its trying to do, then I can fix it straight-away.
>
>
> OK. My error. But the register wasn't complaining, either. What happened
> was: 3 years ago, I couldn't figure out why my tracking of my wife's
> TIAA-CREF contributions left me 0.002 shares low in one of her three funds.
> So I added 0.002 shares at zero cost. Probably would have worked out right
> if I had used the stock split wizard, but I didn't think of that. It has
> been tracking fine since (and I now import all the transactions via
> ofx...).
>
> It turns out I had both the 0.002 shares and the 0 value balancing split
> coming out of the stock fund account. (Remember, the register wasn't
> complaining, and no imbalance account.). Once I put the $0 split into the
> parent 'brokerage' account, the report works.
well, its still a bug (fix going up tonight) in that there should have
been *something* done, so that it wouldn't spit out <#unspecified>.
Thanks for finding it!
>
> Can you tell me why the advanced portfolio report gives me transaction
> based calcs even though the preference for price list use is selected? With
> transaction based calculations, the retirement accounts all show 0% total
> return (which isn't what I was expecting).
I think that is broken at the moment. It only gets a price from the
txn if there is no price in the PriceDB. Close but not
quite... someone (me?) should file a bug so I remember to fix it.
>
> Thanks for all your work on the report. It is now fast enough to be usable.
> Before I never bothered to figure out the options because any change took
> so long to test.
Well, thanks! I'm surprised you're seeing a speed increase, I wasn't
in search of that. Don't hesitate to find other bugs ;)
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/20080102/d3f03c69/attachment.bin
More information about the gnucash-devel
mailing list