Alen, The multicurrency transactions are a problem because at the moment GnuCash is introducing a spurious unrelated amount into the transaction. For eg I had a simple $100 AUD debit to an AUD Savings Account with a split to a Savings USD account for $110 USD. This is correctly exported but when reimported it introduces an amount of $1000 USD. The following CSV when imported
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 produces SavingsAccount_From_AUD_ML_004.png <http://gnucash.1415818.n4.nabble.com/file/t375329/SavingsAccount_From_AUD_ML_004.png> and in the Savings USD account register this produces 2 transactions on import Savings_USD_From_AUD_ML_005.png <http://gnucash.1415818.n4.nabble.com/file/t375329/Savings_USD_From_AUD_ML_005.png> and when you open the first transaction to display the splits Savings_USD_From_AUD_ML_split1_006.png <http://gnucash.1415818.n4.nabble.com/file/t375329/Savings_USD_From_AUD_ML_split1_006.png> and the second transaction created is Savings_USD_From_AUD_ML_split2_007.png <http://gnucash.1415818.n4.nabble.com/file/t375329/Savings_USD_From_AUD_ML_split2_007.png> The multi-currency import is just not working correctly at all at the moment. I'm doing the imports into a pristine data file each time so I can see exactly what is happening when I vary the import conditions. I was waiting to test out a few more possibly related things for multiline imports of transactions between accounts in the same currency before reporting it as a bug. This will help with isolating where it is in the code. The Price is what should control the currency conversion. The book currency I am using is AUD so a price of 10/11 is the conversion rate from USD to AUD in my case for the second split. The price on the split to the AUD Savings Account is 1.00 which is as expected. This is how the account registers appeared before exporting the transaction. The way it is supposed to work is if I look at the AUD "Savings Account" register all amounts are rendered in the currency for that account, so the register appears as Savings_Account-GnuCash_Initial_013.png <http://gnucash.1415818.n4.nabble.com/file/t375329/Savings_Account-GnuCash_Initial_013.png> and if I look at the "Savings USD" account register all amounts are in USD as follows Savings_USD-GnuCash_Initial_015.png <http://gnucash.1415818.n4.nabble.com/file/t375329/Savings_USD-GnuCash_Initial_015.png> . I would be very cautious about using the export/import on multicurrency transactions at the moment I got into this because I some changes to the import matcher late last year and while testing them out noticed that the CSV documentation was way out of date when I was documenting my changes. I started to rewrite the documentation but then found anomolies in how it worked I couldn't understand after the release of V3. Geert really hadn't had time to debug it fully with the load of bug fixes after the v3 release so I undertook to go through it methodically initially mainly to look at the problem that GnuCash v3.2 could not import its own exported files, particularly in the multiline format. I'm preparing a documented report to identify the bugs in a reproducible manner. If Geert is unable to tackle fixing the bugs then when I finish doing that, then I will start working on fixes for them and updating the documentation. The CSV importer still seems to be able to work for what was its original functionality, importing CSV exports form bank accounts etc where single line mode is usually adequate. My bank exports categories in the record which I can setup so I have these set to match the GnuCash Income and Expense accounts I use. The majority of my transactions are usually matched on import but I have never been sure whether it is using the categories or the Bayesian matching algorithm or both. I suspect the latter as some of the transactions I regularly have problems with are ones where the provider uses a different reference number in the description field each time. Their number has a fixed part with a sequential number tacked on the end. The matcher algorithm tokenizes the information in the description field but it can't separate the fixed part of the number from the variable part so it rejects the match. The rest of the description field is not sufficient to override this. I'll have to delete the data file for te bayesian matcher between each import when i get around to testing how that works in detail. ----- David Cousens -- 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
