[GNC-dev] Transactions vs Splits

[David Cousens]

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