GNOME Bugzilla – Bug 355660
'Advanced Portfolio' report confused by split transactions
Last modified: 2018-06-29 21:12:46 UTC
Debian bug 387031: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387031 Package: gnucash Version: 2.0.1-2 Severity: normal With split transactions, the 'advanced portfolio' report takes a random split as the 'money in'. If you load the attached file in gnucash, and ask for the advanced portfolio report, it shows the money in as GBP -148.00, a total gain of GBP 307.00, and a net gain of -207.43%... This was ok with v1.8.xx Jeroen Nijhof
Created attachment 72645 [details] Jeroen's attachment The same test file from the Debian report.
Is this a duplicate of bug#115267 or one of the bugs mentioned in there?
This doesn't look like a duplicate of bug 115267 for the simple reason that this bug is a regression from 1.8.x to 2.0.x, while bug 115267 occurs in 1.8.x. Is there a way to flag bugs as regressions, by the way?
In trunk, specifically with the advanced portfolio file from r16637, I'm seeing $0 as the basis with the test file. Should this be assigned to andrewsw, given the recent commits?
If I set my default currency to GBP and the report currency to GBP, I do not see this behavior (comment #4). In fact it appears to be "working" in that the report gives the best information it can in light of other known issues. Specifically, the test data includes a split txn with a direct income split. This just doesn't work at this point. The split from the OP's payroll should move through an interim account ("brokerage acct") before the buy is made. I'll attach a reworking of that file in which everything seems to work, to my eye. To explain, the report is rather dumb and can't tell that the Income in the original test file is salary income and is unrelated to the stock account. It also can't tell that the other split, into checking account, is also unrelated to the stock. There's simply not enough information at the moment to make those distinctions without getting into using the Action field which is currently not implemented.
Created attachment 101136 [details] reworked test data showing a better way to enter txn. hmm... rounding error. but otherwise looks good to me. comments please!
This should be fixed in svn r16684, awaiting backport.
In the current state r16684 cannot be backported directly, so I remove the block on bug 486922. Three possibilities: 1) wait for 2.4 2) backport other changes so that r16684 can be applied syntactically and semantically. 3) if r16684 is orthogonal to the changes in 2), branch off 2.2 and apply r16684 manually there. Thanks!
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=355660. Please update any external references or bookmarks.