> On Mar 5, 2020 w10d65, at 7:14 AM, Gio Bacareza <[email protected]> wrote: > > I'm encountering problems with importing transactions in csv when accounts > have different currencies. > > I've been reading the debates. So this is not about definitions of > multi-split or terminology. > > I did a test with a sample csv with the following contents: > > Date,Description,Account,Deposit,Withdrawal > 1/3/2019,Description,test_foreign,,200 > ,,Trading:CURRENCY:PHP,,10013 > ,,Trading:CURRENCY:USD,200, > ,,test_local,10013, > > gnucash imported successfully but it created an extra line Imbalance-USD. > See results below: > Date Description Account Deposit Withdrawal > 1/3/2019 Description 200 > Trading:CURRENCY:USD 197.78 > test_local 10013 > Imbalance-USD 2.22 > test_foreign 200 > Trading:CURRENCY:PHP 10013 > > 1. Why does it do that when imported transactions is already balanced in > the first place?
Not certain, sorry. Perhaps this is a bug, or perhaps there is a price in the database that is conflicting and GnuCash is trying to use that rather than set a new price based on the transaction. (I’m not intimately familiar with multi-currency import) See below about manual entries, as I’d suspect either some step is missing for the import, or there is a bug. > 2. When I try to manually correct in gnucash (197.78->200), it wouldn't > allow me. It keeps the imbalance no matter what I do. I’m not certain if this will work with editing an existing imported transaction, but doing a manual version of your test I was able to get it to behave properly. > 3. How do I solve this? I entered these splits first: (Dr/Cr. reversed for my book which is in USD) Dr. test_local 200 Cr. test_foreign 10013 When I tabbed off the last one, the exchange rate dialog popped up. It defaulted to having me enter or fetch the rate, instead I chose Debit Amount (credit in your case) and entered the amount in the test_local account that I wanted to debit and committed the dialog. This created 2 more splits in their respective trading accounts that were exact @ 200 and 10013 respectively as they should be. Your post reminded me of an issue I had a few months ago that I couldn’t get rid of a similar Imbalance split involving trading accounts. I solved it by switching to using the debit/credit amount field instead of the exchange rate field. This makes sense because if you know the exact amounts, you are defining a new price, you don’t need to fetch or employ an existing one. I find that fetching or using price db figures are good for current-value reports of my foreign currency and commodity assets. They aren’t as useful (to me) for transaction entry. Regards, Adrien _______________________________________________ gnucash-user mailing list [email protected] To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
