Well, I've figured out at least part of what's going on: The database has no ACME trading account, so when it encounters the split for one in the first transaction it creates an Orphan-AUD account and sets that as the account for what used to be the trading split. Then it runs the balancing code on the transaction and that creates a new trading account for UNLISTED:ACME and an Imbalance--AUD to balance the Orphan-AUD split.
So far so good, right? But the account creation happens during database load and to prevent attempts to insert duplicate records (which would fail, but in failing they'd substantially slow down the load that's already too slow and log a ton of errors that would slow things even more) the loading code sets a flag that disables writing to the db during the load. That causes those accounts not to get written so the same thing happens when you start the next session. Doing a save-as writes a new database from the contents of memory that includes the newly created accounts. So I need to figure out a clean way to tell the sql backend that the new accounts aren't in the db already and that it should go ahead and write them. Regards, John Ralls > On Oct 9, 2022, at 10:49 PM, Chris Grinton <cgrin...@gmail.com> wrote: > > Good to know that this isn't just me. Using "File > Save As" works as a > workaround for me too - good find! > > Chris > > > On Fri, 7 Oct 2022 at 12:59, john <jra...@ceridwen.us > <mailto:jra...@ceridwen.us>> wrote: >> I can reproduce this with your sample file, and I discovered another facet: >> If one does a File>Save As, either to XML or SQlite3, the new file doesn't >> exhibit the behavior. >> I also found that if I remove the extra splits in the original file they >> don't come back. It's not a last-transaction issue, either: If one creates >> two transactions in a session they'll both get the Orphan and Imbalance >> splits created. >> >> I''l try watching the program load in the debugger next. >> >> Regards, >> John Ralls >> >>> On Oct 5, 2022, at 9:33 PM, Chris Grinton <cgrin...@gmail.com >>> <mailto:cgrin...@gmail.com>> wrote: >>> >>> Good spotting on the share balance difference! I hadn't intended that in >>> the screenshots; it was just a side effect of me playing around trying to >>> get it to work between the first and 2nd screenshot - I had added some >>> other transactions for testing that did adjust the share balance. >>> >>> Selecting "Edit Exchange Rate" on the CapitalLosses:CurrentYear:Realized >>> split in the CapitalLosses:CurrentYear:Realized account register shows an >>> error: "The two currencies involved equal each other". >>> >>> I can reproduce the problem by creating a brand new (empty) GnuCash file >>> and then following the steps I described, and using only a single currency >>> in that file. So I don't think a multi-currency factor is at play here. >>> >>> If it helps and I've inspired anybody to dig deeper, I've shared a .gnucash >>> file at https://app.box.com/s/xdrru5yr8gjm3r7ovatmsn92jcvme053 that can be >>> used to reproduce: simply create a new buy or sell transaction involving >>> the ACME security in the Assets:ACME Corp account, and new Orphan & >>> Imbalance splits will be created in your transaction the next time the file >>> is opened. >>> >>> Chris >>> >>> On Thu, 6 Oct 2022 at 11:59, john <jra...@ceridwen.us >>> <mailto:jra...@ceridwen.us>> wrote: >>>> That looks like a proper cap gains transaction. It's odd that the share >>>> balance differs by 250 between the two screenshots: Is there some other >>>> transaction that might be affecting things? >>>> >>>> The next thought is that there might be a non-AUD transaction currency >>>> involved. If you open the transaction in the >>>> CapitalLosses:CurrentYear:Realized account register, right-click on the >>>> split for that account, and select "Edit Exchange Rate" does it open the >>>> transfer dialog or pop an error box? If the former, what is the non-AUD >>>> currency/commodity it wants to price; if the latter, >>>> what's the error? >>>> >>>> Regards, >>>> John Ralls >>>> >>>> > On Oct 5, 2022, at 7:33 PM, Chris Grinton <cgrin...@gmail.com >>>> > <mailto:cgrin...@gmail.com>> wrote: >>>> > >>>> > Good thought - but the problem still occurs even if the share count and >>>> > price are non-0. (The example transaction I've described is a simple >>>> > reduction in the cost base of the asset without changing the number of >>>> > shares held. But I think that is not directly relevant to the problem and >>>> > probably the example I described more complex than it needed to be.) >>>> > >>>> > Chris >>>> > >>>> > >>>> > On Thu, 6 Oct 2022 at 09:45, R Losey <rlo...@gmail.com >>>> > <mailto:rlo...@gmail.com>> wrote: >>>> > >>>> >> Perhaps I'm missing something, but if there is a transaction that has a >>>> >> cost of 5000, and you have shares with a price of 0, that may be >>>> >> causing it >>>> >> to think there is an imbalance, and thus the transactions get added? >>>> >> >>>> >> On Wed, Oct 5, 2022 at 7:09 AM Chris Grinton <cgrin...@gmail.com >>>> >> <mailto:cgrin...@gmail.com>> wrote: >>>> >> >>>> >>> Hi GnuCashers, >>>> >>> >>>> >>> I have a strange situation where a transaction is automagically (and >>>> >>> unexpectedly) getting splits added to it against the >>>> >>> "Orphan-<currency>" >>>> >>> and "Imbalance-<currency>" accounts when my GnuCash data file is closed >>>> >>> and >>>> >>> reopened. I can't work out why these splits are getting added, and >>>> >>> would >>>> >>> love any insights that people might have on how to stop it from >>>> >>> happening. >>>> >>> >>>> >>> The unexpected behavior here appears to be somehow related to having >>>> >>> trading accounts enabled, and a consequence of changing the namespace >>>> >>> of a >>>> >>> security. >>>> >>> >>>> >>> Here are steps I do to reproduce this problem: >>>> >>> >>>> >>> 1. Create a transaction as follows: >>>> >>> Expenses:Realised capital losses DR 5000 >>>> >>> Assets:Stock account CR >>>> >>> 5000 (with shares & price = 0) >>>> >>> >>>> >>> This appears in GnuCash as per the following screenshot: >>>> >>> >>>> >>> [image: image.png] >>>> >>> >>>> >>> No change occurs to this transaction as long as I keep the GnuCash file >>>> >>> open. >>>> >>> >>>> >>> 2. Edit the UNLISTED:ACME security, and change its namespace. For >>>> >>> example, >>>> >>> change the namespace from "UNLISTED" to "UNLISTED2". >>>> >>> >>>> >>> 3. Open a different GnuCash file (or close GnuCash), and then open the >>>> >>> original file again. The act of opening the file appears to cause the >>>> >>> transaction to be updated with additional splits to read as follows: >>>> >>> >>>> >>> Expenses:Realised capital losses DR 5000 >>>> >>> * Orphan-AUD DR 5000* >>>> >>> Assets:Stock account CR >>>> >>> 5000 (with shares & price = 0) >>>> >>> * Imbalance-AUD >>>> >>> CR >>>> >>> 5000* >>>> >>> >>>> >>> Here's a screenshot showing this: >>>> >>> [image: image.png] >>>> >>> >>>> >>> 4. If I delete the Orphan & Imbalance splits, they continue to reappear >>>> >>> every time I reopen the GnuCash file. >>>> >>> >>>> >>> I have not seen this behavior occurring for securities that have not >>>> >>> had a >>>> >>> namespace change, but is reliably reproducible for securities that have >>>> >>> had >>>> >>> a namespace change. >>>> >>> >>>> >>> I'm using GnuCash 4.8 on Windows with a SQLite data file. >>>> >>> >>>> >>> Thoughts? >>>> >>> >>>> >>> Thanks, >>>> >>> Chris >>>> >>> _______________________________________________ >>>> >>> gnucash-user mailing list >>>> >>> gnucash-user@gnucash.org <mailto:gnucash-user@gnucash.org> >>>> >>> 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. >>>> >>> >>>> >> >>>> >> >>>> >> -- >>>> >> _________________________________ >>>> >> Richard Losey >>>> >> rlo...@gmail.com <mailto:rlo...@gmail.com> >>>> >> Micah 6:8 >>>> >> >>>> > _______________________________________________ >>>> > gnucash-user mailing list >>>> > gnucash-user@gnucash.org <mailto:gnucash-user@gnucash.org> >>>> > 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. _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org 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.
