SUMMARY The CSV import setup has a "Decimal symbol" setting on the Formats page, but it ignores it when performing the import. This creates problems on systems that have customised locale settings. On my system, I have numbers as en-GB, which use . (dot) as a decimal point and currency as ro-RO, which uses , (comma). The reason for that is that many tools assume lists of numbers are separated by commas, so I cannot process files easily across my tools with the ro-RO number locale. At the same time, I cannot read the en-GB/US currency formats, with negative numbers in parentheses etc. Side comment: it was better before. For some reason, kmymoney chose to use comma everywhere, including in the CSV importer, and not the number locale. Even if I set the Decimal symbol to dot in the bank setup, the number parser seems to walk over the dot. STEPS TO REPRODUCE 1. Create a CSV that represents numbers using a different decimal symbol than the system locale. 2. Setup your number format to en-GB and your currency format to ro-RO 3. Import the CSV OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Actually, it does not work even if I process the CSV to format numbers using commas as decimal symbol, regardless if the CSV importer settings is set to comma, dot or auto. Everything gets multiplied by 100 after the import, thus no transactions can be matched or imported correctly. Maybe the issue appears when the system locale has a different decimal symbol than the dot?