[Kmymoney-devel] Re: Importing Puzzles

[aga]

On Fri, 4 Mar 2011 09:04:11 +0100
Thomas Baumgart <thb at net-bembel.de> wrote:

> Hi,
> 
> on Friday 04 March 2011 01:22:10 aga wrote:
> 
> > Having a day or so ago updated the csv plugin, it became possible to
> > extend unit testing to the recent extra functionality, so off I
> > went.
> > 
> > I've made some decent progress but was a little puzzled as to what
> > is a valid monetary value, and what is not.  So, I thought I'd try
> > out some values in a qif import.  If anything, I'm now more puzzled.
> > 
> > The immediate issue I had was whether it was valid to have no
> > decimal places in an amount, and obviously this should be OK.  So,
> > I thought, an amount '123,456' should, depending upon one's locale,
> > be accepted either as 123 thousand, four hundred and fifty six, or
> > 123 point 456.
> > 
> > So, I made a qif file, and imported using UK locale.  I then
> > repeated the process, but with the order of the entries reversed,
> > to make for easier comparison with KMM, but was surprised to see
> > that the results changed.  First run in ( ),  second run results in
> > [ ].  A third run with German locale produced the same results as
> > the second, except that 12.35 became 12,35.  So, at least that
> > entry seems correct.
> > 
> > !Type:Bank
> > D16/09/2009
> > Ppayee
> > T12.3456  (imports as 123456,00) [12.35]
> > ^
> > D15/09/2009
> > Ppayee
> > T987,654  (imports as 987,65) [987654,00]
> > ^
> > D14/09/2009
> > Ppayee
> > T-123,456.78  (-123,46) [-123456,78]
> > ^
> > D13/09/2009
> > Ppayee
> > T123,456  (imports as 123,46) [123456,00]
> > ^
> > 
> > The file entries with ',' I was expecting to be accepted as so many
> > hundreds of thousands, but the comma appears to cause confusion.
> > Or, is it me, again?
> 
> Having all these different methods in a single file is not a valid
> test case!
> 
> The QIF importer logic goes out and tries to detect the 'right'
> format and uses it for all conversions alike. BTW: The last one for
> each type wins (thus in your example "T123,456". The result will be
> decimal symbol = ',' and thousand separator = none.  This should be
> the same across all locales, as I don't see any locale information
> used in the whole conversion process. 
> 
> If you change the order of the entries in the file, the last one will
> be a different one. In your case 'T12.3456' now wins the game and the
> assignment is as follows: decimal symbol = '.' and thousand separator
> = none.
> 
> Looking at it, it all makes sense to me and follows the logic I see
> in source code.
> 
> 

Ah, I see!  That is, I see now why changing the order changes the
outcome.  However, if I import each entry as a separate file, I still
think there may be a problem, where there is no decimal point present.

1) T123,456 imports as 123.46 (thousands separator taken as decimal.)
2) T-123,456.78 imports as 123,456.78 (correct.)
3) T987,654 imports as 987.65 (same as case 1 above.)
4) T12.3456 imports as 12.35 (correct.)

If I import the suspect entries as CSV, and so bypassing
the qifimporter, all seems OK.

I have at least one genuine (not built by me) file where an amount
does not have decimal places, which is why I was using it as a test
case for csv import.

Allan