As mentioned I did some follow through tests with empty and pre-populated currency price databases. Sharing it here:
Conclusions: When doing multi-currency csv imports, it works when the price database is pre-populated with exchange rates consistent with exchange rates used in the import. The issue I have with this is that pre-populating the price DB is cumbersome. There has to be a better way. More details of test here https://docs.google.com/document/d/1d-j6195r3-hHyKopCCwFmGDu94f_8m5bj-fVPb4IJwk/edit?usp=sharing On Fri, Mar 6, 2020 at 11:48 AM Gio Bacareza <[email protected]> wrote: > Thank you Adrien. Inspired by your answers I did a few more tests. > 1. I got rid of the lines with the trading accounts assuming from past > behavior that gnucash will autopopulate with trading currency accounts > based on price database: > Date Description Account Deposit Withdrawal > 3/6/2020 Description test_foreign 200 > test_local 10013 > > it was a success! gnucash added trading currency accounts automatically > and there was no imbalance line. > > 2. So I applied it to the actual transaction data using the same method. > FAILED. gnucash added the imbalances again :( > > 3. So I changed the price database for USD then made it all the same > value. Then I deleted and re-created the account. Then I reimported the > transactions. > SUCCESS!!! > > So conclusion: As long as price is consistent, you can import > multi-currency transactions using multiplit with 1 side currency 1 and the > other side converted currency 2. > > i'll do some test with a blank price database and let everyone know. > > > On Fri, Mar 6, 2020 at 12:55 AM Adrien Monteleone < > [email protected]> wrote: > >> >> >> > 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. >> > > > -- > cheers, > > Gio > -- cheers, Gio _______________________________________________ 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.
