KMM seems to have problems with importing a CSV with amounts that carries digits (cents). For example, on the above example of transactions: -$16 will be imported correctly as a debit of $16.00 -$13.50 will be imported incorrectly as a debit of $1350.00 -$8.00 will be imported incorrectly as a debit of $800.00 I have tried importing the CSV without dollar signs, this makes no difference whatsoever... Reproducible: Always Steps to Reproduce: 1.Create a CSV with digits (cents) 2.Import in KMM 3.Watch it multiply the actual amounts by 100 Actual Results: All amounts carrying digits (cents) are multiplied by 100 Expected Results: KMM should use the amounts as is. Happens with 4.6.1 & 4.6.4 as I upgraded from 4.6.1 to 4.6.4 and this issue persists.
I don't see that here, your file imports with the correct values. The difference between the first an other transactions is the absence/presence of a decimal symbol. So that is a clue. In the UK, my locale has '.' as the symbol, as does your file, and that probably explains why it imports correctly here. In your case, while your file includes the $ symbol, I wonder what your locale symbol is, and whether on importing, you selected the symbol which matches your file, i.e. the '.' symbol?
" I wonder what your locale symbol is, and whether on importing, you selected the symbol which matches your file, i.e. the '.' symbol?" When you say "symbol" you mean decimal separator? For cents? In North America (US or Canadian dollar) we use "dot" to separate integers and decimals.. I know in Europe, they often use comma (,)... My locale? where can I change that? I suppose you are right, somehow KMM thinks the dot is only a floating (unimportant) character and somehow strips it off from the amount resulting in the multiplication by 100 as I stated initialy. This is highly impractical. That means, provided I understood you correctly, that before importing transactions from a CSV file, I need to change my locale to the corresponding decimal separator and import, then revert my locale to my previous setting? I propose that the CSV import or KMM (whichever is required) treats dots or commas as the same: cents , pennies, whatever ....
If you are doing your import in your local currency, then as long as things are set correctly in the first place, you should not need to change anything just to import. In KMyMoney, under the Settings menu, select KDE Language Settings, and check if all the locale, numbers, and currency settings are correct. Dots and commas cannot simply be treated the same - sometimes they represent cents, and sometimes they are a thousands separator. That's what the locale settings are for. KMM is not doing anything on it's own with this - it uses underlying KDE routines for much of this, so you are likely to see the same problems in other applications.
I think I have never noticed my locale settings were wrong because I never used KDE before.. I had also never imported CSV in KMM. Let me double check the settings where you suggested and I will confirm if its working well.
(In reply to comment #2) > " I wonder what your locale symbol is, and whether on importing, you > selected the symbol which matches your file, i.e. the '.' symbol?" > > When you say "symbol" you mean decimal separator? For cents? In North > America (US or Canadian dollar) we use "dot" to separate integers and > decimals.. I know in Europe, they often use comma (,)... > > My locale? where can I change that? I suppose you are right, somehow KMM > thinks the dot is only a floating (unimportant) character and somehow strips > it off from the amount resulting in the multiplication by 100 as I stated > initialy. > > This is highly impractical. That means, provided I understood you correctly, > that before importing transactions from a CSV file, I need to change my > locale to the corresponding decimal separator and import, then revert my > locale to my previous setting? > > I propose that the CSV import or KMM (whichever is required) treats dots or > commas as the same: cents , pennies, whatever .... It's not unknown for users to have to deal with more than one currency and to receive files in different currencies with differing separators/symbols. The CSV importer allows the user to select the symbol matching his CSV file. Making that correct selection in the wizard before import triggers a validation of the selected money column entries. When you installed your distro, I think you will have selected your country, and the correct prameters will have been set up. If you chosen desktop was not KDE, but KDE was subsequently installed, you have to make that same country selection for KDE to use. Again, once bitten, twice shy. Also, I'm not ruling out the possibility of a bug. There was a bug like this in the early release, but that was fixed in 2011.
The more I look at it, the more I realize that I was clueless in using the application and assumed these annoyances were bugs but really they were features that I didnt use properly/at all.. I use slackware. In slackware, we are not presented with a nice GUI install assistant like ubuntu or fedora which asks you about country, timezone, currency etc... ;) Slackware=KISS Again, let me confirm the KDE settings are wrong, and I will post back!
Created attachment 83529 [details] Screenshot of the KDE locale settings as found
See attached is a screenshot of my KDE locale settings as I have found them before modifying anything. As a matter of fact, I did not have to change anything as everything was already correct (dot for decilams and comma for thousands)... So the locale settings are not to blame. I repeated the import after looking at the KDE locale settings and closing the window, same behavior, amounts with decimals are imported as x100
Hmmm... OK, but I still can't get it to fail for me. I imported into an account set up for $Canadian, which worked correctly and then created a new file for $Canadian, and that too was OK. So, we're missing something, but what? Also, when you are about to click Import, are the values displayed in the importer the correct ones as per the CSV file? It's probably likely that they are as the plugin just displays the raw data, apart from a possible decimal symbol change. Also, when you are about to click Import, click the Decimal Symbol button and tell me what changes. Finally, can I ask you, just as an experiment, to create a new kmy file and repeat the import.
When I am about to import, the values are exactly as in the CSV file. For example, $16 appears as $16 and not $16.00 When I click on the decimal symbol (dot), all cells whose values having a dot (decimal) in the CSV file becomes green, the other cells having numbers with no decimal symbols become red and the plugin adds the decimals. See attached screenshots before and after I click on the "Decimal symbol" dropdown list. Also, after selecting the decimal symbol manually from the dropdown list, the transaction amounts are imported properly!!
Created attachment 83534 [details] Before manually selecting the decimal symbol
Created attachment 83535 [details] After manually selecting the decimal symbol
Well, well! So, do we think all is OK (for now) on this one?
Yes, but ideally, the import plugin shouldnt' use the locale settings, see that a dot is a decimal places then understand the numbers after the dot are cents?! To me, somethings not working the way it should be
(In reply to comment #14) > Yes, but ideally, the import plugin shouldnt' use the locale settings, see > that a dot is a decimal places then understand the numbers after the dot are > cents?! > There are probably any number of a ways this could be done. I chose a way that allows a user to receive a file in 'foreign' format, if needed, then translate it to his locale environment. > To me, somethings not working the way it should be Not really, remember that the problem was that you didn't select the correct symbol for your file. Probably, knowing now the cause, I could have directed you to the appropriate part of the handbook, Section 15, in the Help menu.
Agreed! Finally case closed for me ! thanks Allan for the help!