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 577032 - multicurrency QFX import not working
multicurrency QFX import not working
Status: RESOLVED OBSOLETE
Product: GnuCash
Classification: Other
Component: Import - OFX
2.2.9
Other All
: Normal normal
: ---
Assigned To: Benoit Grégoire
Benoit Grégoire
Depends on:
Blocks:
 
 
Reported: 2009-03-28 00:41 UTC by spleen42
Modified: 2018-06-29 22:20 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description spleen42 2009-03-28 00:41:30 UTC
Please describe the problem:
I have CAD and a USD bank accounts, and I download QFX files from my online banking to import into GnuCash. Imported transfers between my USD and and CAD accounts use the same amount for the debit and the credit. Changing one of the two results in an imbalance. The only way to fix it is to delete the transaction and re-enter it using the Transfer tool on the toolbar.

Steps to reproduce:
See above

Actual results:
Incorrect account balances

Expected results:
Correct account balances

Does this happen every time?
Yes

Other information:
Comment 1 Boyd Kelly 2010-09-08 18:52:58 UTC
I have run into a similar problem with importing the multicurrency OFX of my investment account. 

I have a single brokerage account with both a USD and CAD balance.  It appears to me that the importer considers that all transactions use the currency of the account specified by the<ACCTID> in the OFX file.  

When the currency of the imported transaction does not match the cash account, ie a USD transaction imported into the CAD cash account in gnucash, the transaction is imported but there is no 'amount' that shows in the register.  Its just blank.  If there is an FX transaction, I also have to use the Transfer tool to manually enter it.

My work-around has been to import twice. (I keep two cash accounts, CAD and USD.)  The first time I deselect all the US transactions and import only CAD transactions.

Then I edit the OFX file, and change the <ACCTID> tag value adding a USD suffix.  Then I change the <CURDEF> tag from CAD to USD.  On second import I may have to re-associate the OFX file with the USD cash account.  I then deselect all the CAD transactions.

This works for me, but it would be nice if gnucash would handle this somehow someday....
Comment 2 Christoph 2010-09-21 05:55:30 UTC
I have a similar, though seemingly more general problem. I have (amongst other things) bank accounts in EUR and expense accounts in USD. When I import OFX transactions into my EUR bank accounts, I have many of them automatically set to book into the respective USD expense accounts. After the transactions are imported, all the transactions are book with a 1:1 exchange rate, i.e. same amount in the EUR account and the USD expense accounts. 

It would be great if Gnucash could automatically take an FX rate/guess and put it into the transaction.

The problem has been happening with Gnucash ever since, and I observed it in 2.2.9 and all the 2.3.x betas, including 2.3.15.
Comment 3 Ian K 2011-02-09 10:26:24 UTC
This is still in 2.4.0.
If I import an OFX of USD transactions into a USD bank account, the transactions having GBP expenses, the Generic import transaction matcher automatically applies the transfers with a 1:1 exchange rate. I then need to edit the transactions' exchange rates via the register/transfer funds window (which upon opening shows the exchange rate as 1.0).
I guess to add functionality to the import transaction manager would be quite a bit of work, but wouldn't it be relatively simple to be able to pick the exchange rate in a similar way to the reports e.g. selecting Price Source in the report options Commodities tab? You could then select 'Most recent' or 'nearest in time' so each transaction could pick up the appropriate rate for its date.
Clearly automatically assigning a 1:1 rate without warning is wrong and makes importing extremely error-prone in a multi-currency environment.
Comment 4 John Karr 2013-01-20 03:40:06 UTC
I would like to add that this issue wasted a bunch of time for me today. In trying to work around this issue I encountered an even bigger issue, and that is that it is really hard to get data out of gnu cash and in to another program (or just to copy or move an account from one gnu cash file to another). This is because the first fix that came to my mind was to export the "wrong" account, delete, recreate it, and re-import the data for the account. I eventually found this bug report and the workaround. 

I would like to add to the workaround on the import of OFX/QFX files. 

1. make a copy of the file that is being imported to the wrong account.

2. in your copy change the account number to one that doesn't match any of your real accounts.

3. import the altered file and choose the account that gnuCash wanted to import the data to. Once you've chosen the account you can cancel, gnuCash will now associate that account with your fictitious account number.

4. when you try to import the original file again gnuCash will ask which account to import it. Choose the correct one this time and it will be remembered.
Comment 5 daniel.victoria 2016-06-25 12:40:04 UTC
I believe I'm seeing this problem also. Using GnuCash 2.6.12 in Win10
I have a credit card account in Brazilian Reais (BRL) but I also make purchases in Dollars (USD).

When importing my banks OFX into Gnucash, USD transactions will get imported without the co rate being applied.

This is how one transaction in my OFX looks like:
<STMTTRN><TRNTYPE>PAYMENT</TRNTYPE>
<DTPOSTED>20160524</DTPOSTED>
<TRNAMT>-70.01</TRNAMT>
<FITID>20160524554900000000_I_edited_this</FITID>
<MEMO>WILLIAMS-SONOMA E-COMM 800-541-1262</MEMO>
<CURRENCY><CURRATE>3.6556</CURRATE><CURSYM>USD</CURSYM></CURRENCY>
</STMTTRN>

And it got imported into GnuCash as if it where BRL 70.01
Comment 6 John Ralls 2018-06-29 22:20:03 UTC
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=577032. Please continue processing the bug there and please update any external references or bookmarks.