GNOME Bugzilla – Bug 347739
Advanced Portfolio calculates values incorrectly when it involves a capital loss
Last modified: 2018-06-29 21:09:59 UTC
This bug may be related to 346062 When I record Capital losses (probably gains as well) according to the gnucash manual, the advanced portfolio no longer calculates the results of that commodity correctly. For example, I bought 200 shares of SUNW at 6.5 and sold them at 4.33 with a commission of 10.02 and recored at capital loss of 434 (shown as a negative gain). The portfolio shows some strange values, like a negative cost basis and -60.98% return, where the loss was actually only about 33% I will attach an example demonstrating this Here are the results for this commodity based on the listed transactions: Advanced Portfolio 07/16/2006 Account Symbol Listing Shares Price Basis Value Money In Money Out Realized Gain Unrealized Gain Total Gain Total Return SUNW SUNW NASDAQ 0.00 $3.88 -$1,300.00 $0.00 $2,168.00 $845.96 -$22.04 -$1,300.00 -$1,322.04 -60.98%
Created attachment 69019 [details] GnuCash file demonstrating Advanced portfolio report bug
I have the same problem in gnucash 2.0.2. The absolute value of a loss is added to the Money In column. Calculations get skewed from that point on. Here's an easy to reproduce example: - Create a dummy stock account. - Purchase 1000 shares at 1$ each - Sell 1000 shares at 0.75$ - Use the lot viewer to calculate the loss. It wil lalso take care of writing it in an orphaned gain/loss account as a 250$ charge. - Bring the advanced portfolio report. Set the date so it gets your transactions. Also enable display of accounts with 0 shares. See what the report shows: Value = 0 (ok) Money in = 1250 (wrong, expected=1000) money out = 750 (ok) realized gain = -500 (wrong, expected = -250) unrealized gain = 0 (ok) total gain = -500 (wrong, expected = -250) tot return = -40% (wrong, expected = -25% or 250/1000)
I think I've figured this one out. The problem with the report as written is that for each split in the account, it gets the parent txn and iterates over all the splits of that txn. It throws away the splits that aren't associated with actual stock (like a buy or sell) and then gathers up the number of shares and price and uses that to adjust the basis. That's fine except in this case, there are two splits in the account tied to the same transaction. That means that we hit the first split in the account, iterate through all its parent txn's splits looking for the split with shares in it and then grab that info to adjust the basis. Then we hit the next split in the account, which is from the same txn and do it all again which means that the split with the Sell in it gets hit twice and double adjusted out of the basis. The fix is to only look at the actual split that hits the register and stop going to its parent. If that split has a price and number of shares, then use it to adjust the basis, otherwise ignore it. So wipe the xaccTransGetSplitList and instead check for values in txn-amount. (if (not (gnc-is-it-a-zero (whatever that function is) txn-amount) (basis-builder)...
to expand on this, the problem is inherent in the structure of the transactions and the way the report looks at splits. Basically, as soon as an account has a txn showing a gain/loss, that extra entry that ties back to the account causes any number associated with that txn to be used twice. Further, the part of the transaction that offsets the gain/loss gets included into the money-in total because that split ties back to the account and thus gets included as if it was a buy even though there are no actual shares involved. its a mess. :(. I'm thinking the logic has to be redefined so that it definitely only looks at each txn once by either storing a list of transactions already seen or storing a complete list of all relevant transactions and then searching over those. Once that is done (either way), then there are only a couple little logic fixes to handle splits/mergers and gain/loss properly.
this specific problem should be fixed in r16620
branches/2.2@r16663. Thanks a lot!
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=347739. Please update any external references or bookmarks.