David, that's a very elaborate explanation. I'm sure there will be enough information once you are through with testing. So far our findings match. One thing I'd like to note,
David Cousens wrote > Date,Transaction ID,Number,Description,Notes,Commodity/Currency,Void > Reason,Action,Memo,Full Account Name,Account Name,Amount With Sym,Amount > Num.,Reconcile,Reconcile Date,Rate/Price > 15/11/18,b60da83af9b84334aa2f5e129c23016f,,Transfer with currency > exchange,,CURRENCY::AUD,,,,Assets:Current Assets:Savings Account,Savings > Account,$100.00,100.00,n,,1.00 > ,,,,,,,,,Assets:Current Assets:Savings USD,Savings > USD,-$110.00,-110.00,n,,10/11 > <snip> > The Price is what should control the currency conversion. I find the Price and Amount information redundant, if both are sent. For example, if they don't match, which one is the relevant one? If amounts are sent in all splits, it would be better to read the amounts and calculate the price/rate on import. I assume your export is from GnuCash so it is good to learn that it exports the Price element, too. I'll adjust my export to do the same, just in case. In conclusion, the current state of import would work fine for transactions in single currency. Another issue I had with QIF import was that it was matching accounts by name, which is not what I wanted. When exporting transactions that use categories, then expenses in all currencies go to, for example, Dining. QIF import would always match Dining to Expenses:Dining, which is in EUR, in my case. So it would always create duplicate accounts after the holidays. One thing for me to check is if the CSV importer is better in that regard and will match (or at least remember manually set values) the categories to the accounts in correct currency (i.e. Expenses:Dining:AUD etc.). -- Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel