[Kmymoney-devel] mymoneystatementreader.cpp matching problem - A bug in Git master

[Allan]

Hi Chris

I think I've got to the root of the different results between OFX and 
CSV import, if you are interested.

There were a couple of problems.  The first was actually in the code in 
MyMoneyStatementReader::processSecurityEntry() (starting on your on line 
498).  Using the CSV importer, there was a problem with -
"
} else if ((*it).tradingSymbol() == sec_in.m_strSymbol)  <----- Security 
found here"
I needed to add 'toLower()' to that statement because there was a case 
mismatch, even though I had entered caps. for the original transaction 
symbol and for the imported one.  That didn't fix the problem, but it 
did get me to having the messagebox appear that you had got.  The 
remaining problem was that your patch wasn't helping because 
statementTransactionUnderImport.m_strSymbol.toLower() was still empty.

To cut a long story short, the 'm_strSymbol' variable has two parents, 
one being MyMoneyStatement::Transaction and the other is 
MyMoneyStatement::Security.
The CSV importer, which I partly based on the QIF importer, was setting 
up the security variable but not the transaction one.

I'll open a bug for this now, so many thanks for your patch.  I haven't 
yet looked at your second one.

Allan


On 26/11/13 17:28, Chris Tucker wrote:
> Yes, the patch fixes the OFX imports that were causing a messagebox saying the transactions would be ignored.  Now they find the existing security by ticker and use it for the imported transactions.
>
> --
>
> Chris
>
>
> On Tuesday, November 26, 2013 02:02:39 PM Allan wrote:
>> I'm still investigating, but have now added your patch, and it makes no
>> difference here.  statementTransactionUnderImport.m_strSymbol.toLower()
>> is empty, but a match is still found on the security name.  Strangely,
>> at the moment, on iterating through the list, it doesn't match with the
>> existing transaction's name, which is correct, but with its own name
>> which is already in the list.  I don't yet understand that, but I think
>> I know why the symbol is empty, but I think it lies within the statement
>> reader, so CSV inport and OFX import should work the same way.
>>
>> Very strange, but to be sure, did your patch definitely fix your problem?
>>
>> Allan
>