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 669964 - Importing log file from a transaction that moves money between mutual funds creates a brokentransaction
Importing log file from a transaction that moves money between mutual funds c...
Status: VERIFIED FIXED
Product: GnuCash
Classification: Other
Component: Import - Other
2.4.x
Other All
: Normal critical
: ---
Assigned To: Christian Stimming
Depends on:
Blocks:
 
 
Reported: 2012-02-13 04:11 UTC by Boris Zbarsky
Modified: 2018-06-29 23:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Log file (851 bytes, application/octet-stream)
2012-02-13 04:11 UTC, Boris Zbarsky
Details
XML generated from the import (1.13 KB, text/plain)
2012-02-13 04:16 UTC, Boris Zbarsky
Details
XML generated from manual entry (1.35 KB, text/plain)
2012-02-13 04:18 UTC, Boris Zbarsky
Details
Gnucash file to start with (983 bytes, application/gzip)
2012-02-13 04:51 UTC, Boris Zbarsky
Details
Log file to import (743 bytes, text/plain)
2012-02-13 04:52 UTC, Boris Zbarsky
Details
Gnucash file I end up with after importing and saving (1.24 KB, application/gzip)
2012-02-13 04:53 UTC, Boris Zbarsky
Details
Log file with all three entries (1.89 KB, text/plain)
2012-02-13 04:59 UTC, Boris Zbarsky
Details

Description Boris Zbarsky 2012-02-13 04:11:06 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.
Comment 1 Boris Zbarsky 2012-02-13 04:16:49 UTC
Created attachment 207430 [details]
XML generated from the import
Comment 2 Boris Zbarsky 2012-02-13 04:18:12 UTC
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....
Comment 3 Boris Zbarsky 2012-02-13 04:24:20 UTC
I just tried uprading to version 2.4.10, and it has the same problem.
Comment 4 Boris Zbarsky 2012-02-13 04:51:47 UTC
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....
Comment 5 Boris Zbarsky 2012-02-13 04:52:20 UTC
Created attachment 207433 [details]
Log file to import

Import this log file
Comment 6 Boris Zbarsky 2012-02-13 04:53:10 UTC
Created attachment 207434 [details]
Gnucash file I end up with after importing and saving
Comment 7 Boris Zbarsky 2012-02-13 04:58:47 UTC
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.
Comment 8 Boris Zbarsky 2012-02-13 04:59:58 UTC
Created attachment 207435 [details]
Log file with all three entries
Comment 9 Boris Zbarsky 2012-02-13 05:13:28 UTC
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.
Comment 10 Christian Stimming 2013-06-19 15:53:05 UTC
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?
Comment 11 Geert Janssens 2013-06-21 12:36:16 UTC
Verified. The transaction is properly recreated and saved as of r23058.
Comment 12 John Ralls 2017-09-24 22:44:26 UTC
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
Comment 13 John Ralls 2018-06-29 23:06:23 UTC
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.