Bug 352789 - Investment CSV import case sensitivity
Summary: Investment CSV import case sensitivity
Status: RESOLVED FIXED
Alias: None
Product: kmymoney
Classification: Applications
Component: importer (show other bugs)
Version: 4.7.2
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-16 10:32 UTC by Marcel
Modified: 2016-08-06 11:18 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.8.0
Sentry Crash Report:


Attachments
Testcase (10.00 KB, application/x-tar)
2015-10-04 11:36 UTC, Marcel
Details
Screenshots (420.00 KB, application/x-tar)
2015-10-04 11:37 UTC, Marcel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcel 2015-09-16 10:32:31 UTC
When importing a CSV that contains trades, the symbol matching always converts the symbols to lowercase. However, the usual convention is uppercase symbols. (I have AMD in my CSV and get amd, which looks weird).
The full equity names are also converted to lowercase (i.e 'Advanced Micro Devices Inc' ~> 'advanced micro devices inc'), even though they should certainly just stay as they are.

Even when I edit the symbol name afterwards to be uppercase, the matching for existing symbols during CSV import doesn't work. This matching should be case-insensitive (i.e it doesn't matter whether my CSV contains 'amd' or 'AMD').



Another minor issue: if the amount field contains no decimal separator, the default separator is automatically appended during import. This leads to problems when the CSV uses a different separator than the one in KMyMoney by default.
e.g for Amount "300" and Price "12.50" with , as the default decimal separator in KMyMoney, I have to change the CSV to have amount "300.00" because otherwise the import makes it "300,00". 

Reproducible: Always

Steps to Reproduce:
1. File > Import > CSV
2. Choose 'Investment'
3. Step through the process of choosing fields
4. Get to the "Edit equities and symbols" dialog

Actual Results:  
All fields in the symbols column are lowercase.

Expected Results:  
The symbols column keeps whatever case was in the CSV.
Comment 1 allan 2015-09-17 12:21:25 UTC
(In reply to Marcel from comment #0)
> When importing a CSV that contains trades, the symbol matching always
> converts the symbols to lowercase. However, the usual convention is
> uppercase symbols. (I have AMD in my CSV and get amd, which looks weird).
> The full equity names are also converted to lowercase (i.e 'Advanced Micro
> Devices Inc' ~> 'advanced micro devices inc'), even though they should
> certainly just stay as they are.
> 
> Even when I edit the symbol name afterwards to be uppercase, the matching
> for existing symbols during CSV import doesn't work. This matching should be
> case-insensitive (i.e it doesn't matter whether my CSV contains 'amd' or
> 'AMD').

Yes, that is so.  I now have it working, preserving the case from the input file.
I need to do further testing, however.

> 
> Another minor issue: if the amount field contains no decimal separator, the
> default separator is automatically appended during import. This leads to
> problems when the CSV uses a different separator than the one in KMyMoney by
> default.
> e.g for Amount "300" and Price "12.50" with , as the default decimal
> separator in KMyMoney, I have to change the CSV to have amount "300.00"
> because otherwise the import makes it "300,00". 

I'll also look into this.
Comment 2 allan 2015-09-21 23:34:15 UTC
I'm still looking into this, but a query.

At the moment, there is a problem applying the different decimal symbol when then converting the text value to a MyMoneyMoney() value.  Presently, when passing a valid text amount, the decimal separator is not getting recognised, and the result appears as though multiplied by 100.

I can avoid that by changing the KDE decimal symbol to a '.', and that imports correctly, but all of KMyMoney values now show that as their symbol.

When you are importing such a file, does that file use the  '.' symbol, or the ',' symbol?  In other words, are you expecting a mix of decimal symbols in that file?  Or, just the '.' symbol?

At the moment, I'm not sure such a mix is valid.  @Thomas
Comment 3 allan 2015-09-22 12:08:43 UTC
https://bugs.kde.org/show_bug.cgi?id=352789

--- Comment #2 from allan <agander93@gmail.com> ---
I'm still looking into this, but a query.

At the moment, there is a problem applying the different decimal symbol 
when then converting the text value to a MyMoneyMoney() value. 
Presently, when passing a valid text amount, the decimal separator is 
not getting recognised, and the result appears as though multiplied by 100.

I can avoid that by changing the KDE decimal symbol to a '.', and that 
imports correctly, but all of KMyMoney values now show that as their symbol.

When you are importing such a file, does that file use the  '.' symbol, 
or the ',' symbol?  In other words, are you expecting a mix of decimal 
symbols in that file?  Or, just the '.' symbol?

At the moment, I'm not sure such a mix is valid.  @Thomas

You say "... I have to change the CSV to have amount "300.00"... ".  I 
take it that you are editing the input file?  When you now import that, 
successfully, is it into a .kmy file with ',' as separator or '.'?  What 
is the KDE decimal symbol when importing? (in case you are changing this 
to cope).

Allan
Comment 4 Marcel 2015-09-23 14:39:38 UTC
Yes, I'm editing the input file to add the trailing '.00'. 

Basically, my KDE is set up for German, so ',' is the decimal symbol. I'm assuming that's also the decimal symbol of my .kmy file (at least that is what amounts are displayed with). I personally wouldn't mind changing it to '.' in KDE (but haven't tested this).
The CSV uses only '.' as the decimal symbol (no mix), and it gets successfully imported into my (',' decimal symbol) /kmy file after editing.
Comment 5 allan 2015-09-24 10:12:14 UTC
(In reply to Marcel from comment #4)
> Yes, I'm editing the input file to add the trailing '.00'. 
> 
> Basically, my KDE is set up for German, so ',' is the decimal symbol. I'm
> assuming that's also the decimal symbol of my .kmy file (at least that is
> what amounts are displayed with). I personally wouldn't mind changing it to
> '.' in KDE (but haven't tested this).
> The CSV uses only '.' as the decimal symbol (no mix), and it gets
> successfully imported into my (',' decimal symbol) /kmy file after editing.

OK, thanks.  Now a supplementary question.  When you do the import. is it to a solely '.' account, or a mixed one?
What would be most helpful, to ensure I fix your problem and not some incidental one, would be for you to produce an anonymous minimal .xml file that demonstrates the issue,  and also a copy of your CSV file, with anything sensitive disguised.  You can attach to this bug, or send direct to me.
Comment 6 Marcel 2015-10-04 11:34:48 UTC
Ok, I have created some test files and also screenshots during the import process.

My column mapping is Date=4, Price=6, Type/Action=9, Amount=5, Commissions/Fees=7, Note=12*, Amount=8, Symbol=2, Details=3 and I import line 2-2.

Basically, the right thing happens when I ignore the warning/red background for the Quantity column (Step 4a/4b in the attachment.)
When I switch the decimal separator to Comma, everything becomes green and the right amounts are still displayed  (Step 4c/4d in the attachment), but after the import, amounts are multiplied by 100 (though there is a warning message about a missing decimal separator in column 8). 

When I switch to Comma and back to Point as decimal separator, several columns become red (step 4e in the attachment), but as a user I would expect to get the same result as before switching to Comma. The import succeeds again in that case. 

To summarize, the main problem is that columns become red/green when they shouldn't, which confused me.



This test file also exhibits #352792, as the commision of 1 gets ignored (or maybe I didn't quite get the import process. I always get asked to enter the name (instead of choosing one) of the checking account used for transfers, even when I create the kind of investment account that also adds a settlement account.
Comment 7 Marcel 2015-10-04 11:36:08 UTC
Created attachment 94834 [details]
Testcase
Comment 8 Marcel 2015-10-04 11:37:07 UTC
Created attachment 94835 [details]
Screenshots
Comment 9 allan 2015-10-04 18:20:15 UTC
(In reply to Marcel from comment #6)
> Ok, I have created some test files and also screenshots during the import
> process.

Good, thanks for that.  I see that your asset account is in USD, but there appears to be no investment account into which to import the CSV file.   I assume you do have one, and am I right in assuming that that also is in USD?  I want to be sure to match your setup, as I haven't as yet been able to get a good import?  I take it that your locale is German, and therefore uses the comma decimal symbol?

Before completing the import, on the  Edit Securities and Symbols window the symbol AAPL appears, without a security name, but that doesn't show in your .kmy file.

> My column mapping is Date=4, Price=6, Type/Action=9, Amount=5,
> Commissions/Fees=7, Note=12*, Amount=8, Symbol=2, Details=3 and I import
> line 2-2.
> 
> Basically, the right thing happens when I ignore the warning/red background
> for the Quantity column (Step 4a/4b in the attachment.)
> When I switch the decimal separator to Comma, everything becomes green and
> the right amounts are still displayed  (Step 4c/4d in the attachment), but
> after the import, amounts are multiplied by 100 (though there is a warning
> message about a missing decimal separator in column 8). 
> 
> When I switch to Comma and back to Point as decimal separator, several
> columns become red (step 4e in the attachment), but as a user I would expect
> to get the same result as before switching to Comma. The import succeeds
> again in that case. 
> 
> To summarize, the main problem is that columns become red/green when they
> shouldn't, which confused me.
> 
> 
> 
> This test file also exhibits #352792, as the commision of 1 gets ignored (or
> maybe I didn't quite get the import process. I always get asked to enter the
> name (instead of choosing one) of the checking account used for transfers,
> even when I create the kind of investment account that also adds a
> settlement account.
Comment 10 Marcel 2015-10-11 12:23:19 UTC
Hi,
I've tested again with a setup with an investment and asset account and starting kMyMoney with KDE_LANG=en_US, since my remaining problems are probably not related to my German setup (the CSV is also as generated by a US broker).

One thing about the import process that always confuses me is that I get "Enter the name of the Brokerage or Checking Account used for the transfer of funds" after clicking Import CSV. Shouldn't I get a dropdown with my existing accounts here?

Afterwards, I'm asked to choose which account my import is for. If I choose the investment account here, I get "This imported statement contains investment transactions with no security.", which is clearly not the case. If I choose the brokerage account, I do get an import, but not in the investment account.

The imported file was the same as before (the corresponding settings can be seen in the screenshot), the kMyMoney setup is simply creating a new Investment account together with a brokerage account in a new .kmy file.
Comment 11 allan 2015-10-11 14:24:19 UTC
Hi,

On 11/10/15 13:23, Marcel wrote:
> https://bugs.kde.org/show_bug.cgi?id=352789
>
> --- Comment #10 from Marcel <kde@picodesign.de> ---
> Hi,
> I've tested again with a setup with an investment and asset account and
> starting kMyMoney with KDE_LANG=en_US, since my remaining problems are probably
> not related to my German setup (the CSV is also as generated by a US broker).
>
> One thing about the import process that always confuses me is that I get "Enter
> the name of the Brokerage or Checking Account used for the transfer of funds"
> after clicking Import CSV. Shouldn't I get a dropdown with my existing accounts
> here?

OK.  The reason for this is that you will be importing into a file which 
you select during the import process.  However, if say, you are dealing 
with a file including monetary values, for instance, a Buy or a Sell, 
you need to specify the checking-type account to use, and not everyone 
uses a brokerage account linked to the investment account.  So, that is 
the purpose of that little window.  In fact, you can enter anything you 
like there, and it will just show up as an unbalanced transaction and 
you can then enter what you require.


That part was actually written in the very early days of the plugin, and 
I did not then wish to access KMM features inside the plugin.

> Afterwards, I'm asked to choose which account my import is for. If I choose the
> investment account here, I get "This imported statement contains investment
> transactions with no security.", which is clearly not the case. If I choose the
> brokerage account, I do get an import, but not in the investment account.

I suspect that that is because the kmy file includes a stock without a 
name.  If I give the stock a name, like say Apple, then you don't get 
that problem.  The investment file does need to be imported into an 
investment account.  KMM requires separation between the shares aspect 
and the money side.  Possibly that will change in time, but don't hold 
your breath.

> The imported file was the same as before (the corresponding settings can be
> seen in the screenshot), the kMyMoney setup is simply creating a new Investment
> account together with a brokerage account in a new .kmy file.
>

Using USD for the relevant accounts does allow successful importing, 
whereas Euro does not.

Allan
Comment 12 wojnilowicz 2016-05-08 07:56:58 UTC
Hi Marcel,
It might be that there is duplicate of your but at #360435.
Anyways the latter bug is fixed in master branch. If you know how to compile code yourself, then please try it, and if not then please wait for next KMM release
Cheers
Łukasz