[GNC] importing csv multisplit multicurrency problems

[Adrien Monteleone]

> On Mar 5, 2020 w10d65, at 7:14 AM, Gio Bacareza <gbacareza at gmail.com> 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