GNOME Bugzilla – Bug 669964
Importing log file from a transaction that moves money between mutual funds creates a brokentransaction
Last modified: 2018-06-29 23:06:23 UTC
Created attachment 207429 [details] Log file I ran into this when trying to recover from a crash. I have two mutual fund accounts set up. I tried to move money from one to the other, and then Gnucash crashed. I then imported the log file from before the crash, and everything seemed OK, until the next time I started Gnucash. At that point one of the two splits suddenly had its price reset to "1" and the "Buy" amount changed, so that the transaction was no longer balanced. I'll attach the log file in question, the actual XML snippet in the Gnucash file generated from that log file, and the XML snippet for the same transaction after I just manually reentered it.
Created attachment 207430 [details] XML generated from the import
Created attachment 207431 [details] XML generated from manual entry The min difference seems to be the presence of the trn:currency block and the fact that the split:value ends up in units of 1/100 instead of 1/100000. Note that the log file did have the value in units of 1/100....
I just tried uprading to version 2.4.10, and it has the same problem.
Created attachment 207432 [details] Gnucash file to start with This is a a minimal testcase that reproduces the problem for me. Start with this Gnucash file, then import the log file I'm about to attach. Then save and quit. Then reopen the file that was just saved....
Created attachment 207433 [details] Log file to import Import this log file
Created attachment 207434 [details] Gnucash file I end up with after importing and saving
One observation: The actual log file that gets generated when I create the transaction I want to create in this minimal testcase seems to have three entries in it, because of the way the UI behaved. Specifically, when I entered the transaction in one account, it was entered with a blank for the number of shares in the other account. I then went and fixed the number of shares in that second account. The resulting log file has a "C" entry that puts 0 shares in the second account, then a "B" entry that looks identical to the "C" entry except for the time_now but seems to flip the order of the splits in it, and then a second C entry that actually has the correct information. The "file to import" above just has the last C entry. If I import all three entries, the transaction seems to import fine. In my original use case, I don't recall there being two separate C entries... but maybe I missed it.
Created attachment 207435 [details] Log file with all three entries
Ah, yes. I definitely only had the one C entry. The transaction in question was created by duplicating an earlier transaction with a different date, which leads to a log with a single C entry in it. The behavior when that log is imported is exactly what you see with the attached Gnucash file and log.
trunk r23058. Before, replaying the log file for a txn between mutual funds will forgot to set the trn:currency field, leading to the described messed-up behaviour in the register (e.g. the price is suddenly set to instead of 20 in the example). After, replaying the log file will correctly set the currency of the txn. In the saved file, you can nicely see the trn:currency tag appearing in the correct location, which was missing beforehand. Can someone verify, please?
Verified. The transaction is properly recreated and saved as of r23058.
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=669964. Please update any external references or bookmarks.