Hi Sherlock, Thank you again — I tested your suggestion on a copy of my book with GnuCash 5.17 on Windows, and it works exactly as you described.
I duplicated the stock-split transaction and deleted the original in four accounts (mine and three family members'). Before the change, the 2025 lot showed 90,000 / 546,000 / 54,000 / 54,000 shares and was open in 5.17. After the change, all four 2025 lots show 0 shares with a closing date of 2025/12/31, the 2026 lots are unchanged, and the realised gain figures are identical. Transaction and split counts are unchanged; only the four split transactions have new GUIDs. For now I have decided not to modify the live book. I am keeping the original data, using 5.17, and simply leaving the lot display alone, in the hope that a later release handles these existing lots. I still have both the original copy and the cleaned-up copy for comparison. Two questions: 1. In the meantime, is there anything I should specifically avoid doing with these lots — for example running Actions > Scrub, or closing the lot manually — so that the transaction data stays untouched until a fix arrives? 2. When the fix for bug 799824 reaches a release, will books in this state be handled automatically, or will users have to re-link or rebuild the affected lots themselves? I would rather leave the book in the state that a future version expects. Thanks again for your help — it saved me from adding offsetting share entries that would have made things worse. Thomas Chen _______________________________________________ gnucash-user mailing list [email protected] To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
