After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 774658 - Lots in Account - incorrect cap gain trans created if you delete cap gains transactions before lots
Lots in Account - incorrect cap gain trans created if you delete cap gains tr...
Status: RESOLVED OBSOLETE
Product: GnuCash
Classification: Other
Component: Engine
2.6.14
Other All
: Normal normal
: ---
Assigned To: gnucash-core-maint
gnucash-core-maint
Depends on:
Blocks:
 
 
Reported: 2016-11-18 02:49 UTC by Chris Good
Modified: 2018-06-29 23:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screendump1 (92.12 KB, image/png)
2016-11-18 02:49 UTC, Chris Good
Details
screendump2 (126.27 KB, image/jpeg)
2016-11-18 02:50 UTC, Chris Good
Details
screendump3 (95.54 KB, image/jpeg)
2016-11-18 02:50 UTC, Chris Good
Details
screendump4 (126.45 KB, image/jpeg)
2016-11-18 02:51 UTC, Chris Good
Details
screendump5 (115.25 KB, image/jpeg)
2016-11-18 02:51 UTC, Chris Good
Details

Description Chris Good 2016-11-18 02:49:11 UTC
Created attachment 340209 [details]
screendump1

This happens in 2.6.14 in Windows 10 and 2.6.9 in Debian 8.5.

If after scrubbing a security account you decide it is not what you want (say you have incorrectly linked splits to a lot), then you delete the capital gains transactions created by scrubbing (without first cleaning up the lots), then go into the Lots in Account window and click on a lot, it seems to try to recreate the cap gain transactions again but they are incorrect. 

For example:
1) create following transactions:
 1/1/2015 Buy  100 @ $10.00 ea = $1000.00		Lot 0
 1/2/2015 Sell  10 @ $11.00 ea = $110.00-
 1/3/2015 Buy  100 @ $12.00 ea = $1200.00		Lot 1
 1/4/2015 Sell 150 @ $13.00 ea = $1950.00-
See attached screendump: 1BeforeInitialScrubAccount.png

2)
Scrub Account correctly creates 3 cap gains transactions:
 1/2/2015 Lot 0 gain = sell 10 x 11.00 - buy 10 x 10.00 =  110.00 - 100.00 =  10.00
 1/4/2015 Lot 0 gain = sell 90 x 13.00 - buy 90 x 10.00 = 1170.00 - 900.00 = 270.00
 1/4/2015 Lot 1 gain = sell 60 x 13.00 - buy 60 x 12.00 =  780.00 - 720.00 =  60.00
See attached screendump: 2AfterInitalScrubAcct.png

3)
Delete the 3 capital gains transactions.
See attached screendump: 3AfterDeletingCapGainTrans.png

4)
Go into the Lots in Account window and click on lot 0. This creates:
 2 capital gain transactions for 1/2/2015 each with value $10.00
 1 capital gain transaction for  1/4/2015 with value $260.00
See attached screendump: 4AfterClickOnLot0.png

5) If you reset the lots and transactions to how they were just before point 4,
then click on lot 1, this creates:
 2 capital gain transactions for 1/4/2015 each with value $60.00
See attached screendump: 5AfterClickOnLot1.png

The correct procedure would seem be to delete the lots first (or at least unlink the sell splits from the lots), before deleting the capital gain transactions. I have found no problem when doing this.

I suspect this will be difficult to fix and there will not be much motivation for it to be fixed given the easy work-around, but I wanted to document it anyway.
I intend to update my recent documentation to specify that lots should be deleted or at least sell splits unlinked from the lots before deleting the capital gains transactions.
Comment 1 Chris Good 2016-11-18 02:50:05 UTC
Created attachment 340210 [details]
screendump2
Comment 2 Chris Good 2016-11-18 02:50:56 UTC
Created attachment 340211 [details]
screendump3
Comment 3 Chris Good 2016-11-18 02:51:24 UTC
Created attachment 340212 [details]
screendump4
Comment 4 Chris Good 2016-11-18 02:51:57 UTC
Created attachment 340213 [details]
screendump5
Comment 5 Stefan Söffing 2016-11-30 13:24:21 UTC
Confirm this on 2.6.12 on Ubuntu as well.

In my case with Trading accounts enabled:
One of the scrub transactions (created in step 4 of above description) is not even self-balanced (regarding trading account splits). This leaves the user trapped in transaction edit mode, which cannot be left until the user balances the splits manually.
Comment 6 John Ralls 2018-06-29 23:52:07 UTC
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=774658. Please continue processing the bug there and please update any external references or bookmarks.