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 731019 - Since Last Run Assistant creates stock transactions with wrong currency
Since Last Run Assistant creates stock transactions with wrong currency
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Scheduled Transactions
2.4.x
Other Windows
: Normal major
: ---
Assigned To: gnucash-core-maint
gnucash-core-maint
Depends on:
Blocks:
 
 
Reported: 2014-05-31 00:33 UTC by David Carlson
Modified: 2018-06-29 23:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test data file (82.57 KB, application/xml)
2014-05-31 02:31 UTC, David Carlson
Details

Description David Carlson 2014-05-31 00:33:28 UTC
Steps to repeat:
1. Create a new data file with accounts for investments, default USD currency.
2. set up a security of type FUND called PRIME with symbol TRMXX
3. Assign that security to a stock account under a brokerage account
4. In that stock account create a purchase transaction for 100 shares at $1.00 US using funds transferred from the brokerage account.  Trading accounts are optional, this works either way.
5. From the stock account, highlight that transaction and select Schedule to create a scheduled Transaction.
6. Use the Since Last Run assistant to create a transaction.  

This new transaction will be assigned a currency FUND TRMXX.  It should have the default currency of the brokerage account.

I have a sample data file that I can attach if required.
Comment 1 David Carlson 2014-05-31 02:31:37 UTC
Created attachment 277594 [details]
test data file
Comment 2 David Carlson 2014-05-31 02:31:55 UTC
Perhaps I should add some info.  This problem cannot be seen from either side of the newly created transaction.  However, if the newly created transaction is edited with a changed dollar amount in the stock account register and saved, the dollar amount will be incorrect in the brokerage account register. 

The transaction will be incorrect in the XML file where the <trn:currency> can be seen to be <cmdty:space>FUND with <cmdty:id>TRMX instead of <cmdty:space>ISO4217 with <cmdty:id>USD.  After a failed edit the split line representing the currency transfer between the brokerage account and the stock account will have an incorrect ratio of <split:value> to <split:quantity>.

I am not sure whether the error is actually in the image of the scheduled transaction or if the SLR assistant is processing it incorrectly.  I was unable to figure out where the transaction currency is assigned for the scheduled transaction.

As I stated above I have a sample file that I will now try to attach to this bug report.
Comment 3 John Ralls 2014-05-31 21:22:52 UTC
I can replicate this in 2.4.15 but not in 2.6.3. I'm inclined to regard it as fixed.
Comment 4 David Carlson 2014-06-01 22:51:43 UTC
Would it be possible to use the Actions>Check and Repair function to fix or at least highlight transactions that have an incorrect type of currency?  I guess it would have to allow all ISO4217 currencies as being OK.

In my file there are 27 flawed transactions and I will be able to fix them manually now that I know how to find them, but an automatic repair would be easier for most users.
Comment 5 John Ralls 2014-10-13 20:26:57 UTC
I don't think so, because it's possible -- sadly common since 2009 -- to need to transfer shares from e.g. one mutual fund account to another. For example, I just had several of my Nuveen muni bond funds consolidated into a single fund, so I had to transfer their shares to the destination fund.
Comment 6 John Ralls 2017-09-24 22:48:32 UTC
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
Comment 7 John Ralls 2018-06-29 23:31:06 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=731019. Please update any external references or bookmarks.