[Kmymoney-devel] A bug in Git master

[Allan]

On 08/12/13 17:39, Chris Tucker wrote:
> During the OFX import when direct downloading from a bank, the user is not prompted for anything and likely shouldn't be anyway.  The OFX import for an account should have all the information it needs to do the import correctly.  The trouble here is that statementTransactionUnderImport doesn't know the account that is getting the import and so cannot determine the brokerage account.  If we ask m_account (thisaccount from line 556) then we can get the correct brokerage and everything works.
>
> The code at line 1086 suffers the same problem since it asks statementTransactionUnderimport for the brokerage and comes up empty again.  So this section doesn't work either during the OFX import and might even be a bug somewhere else during the import process.
>

Yes, I found both areas had the same difficulty.  I won't commit just 
yet, because it might be that we're fixing the result of the problem 
rather than the cause.  I'll see if I can see first why the two existing 
tests fail.

> Also, I don't see how you can use an investment account without the corresponding brokerage.  I would prefer not to have two accounts for every investment I have as this makes my account list unnecessarily long (I have 20 investment accounts and so get 40 accounts in the list with brokerage accounts added).  It is also more difficult to work with two accounts rather than having the cash included in the investment account.  But it doesn't look like the investment accounts can handle cash at all so it cannot work properly without the corresponding brokerage account.  I also read that reports won't work properly without the brokerage so I am unsure how you are setup such that you don't need the accounts.

There was a bug a while ago that resulted in the premature creation of 
brokerage accounts, but I fixed that, I think.  I don't use brokerage 
accounts at all.  I never did, because I never used a broker.  When I 
create a new investment account, I do not click the box to create one. 
Instead, when importing, I specify the checking account to use, so the 
funds end up in a real account, and no extra transfer is needed.

I haven't used OFX for a long while and I can't remember the setup 
process, and Help doesn't help much, either.  But, I did use it without 
brokerage accounts, so there must be a way.  Oh, wait, I didn't use it 
for investments, only for checking accounts.  It may be that for you it 
is using a brokerage account because in the dim and distant past, you 
told it to.  Perhaps you could set up a new account for the import, 
without a brokerage account, and perhaps it will now ask which checking 
account to use, and remember that for next time.  I saw a suggestion to 
copy your existing file to a new account, which will have a new id, 
delete the old, then do the import and then rename the account.

Allan



>
> --
>
> Chris
>
>
> On Saturday, November 30, 2013 11:55:47 PM Allan wrote:
>> On 25/11/13 04:23, Chris Tucker wrote:
>>> I tried to subscribe to the list but am awaiting authorization.  According to the page at http://kmymoney2.sourceforge.net, this is the best way to submit a bug for the git development code.  If not the please point me in the right direction.
>>>
>>> Another bug found  when importing from OFX direct connect.  The reader trying to create splits cannot find the brokerage account for a split using statementTransactionUnderImport so all the imported transactions are broken.  This is likely because the transaction doesn't know the account name, but m_account does.  A patch:
>>>
>>> *** mymoneystatementreader.cpp.orig     2013-11-24 17:27:39.959812598 -0800
>>> --- mymoneystatementreader.cpp  2013-11-24 20:01:40.339204121 -0800
>>> ***************
>>> *** 565,570 ****
>>> --- 565,573 ----
>>>         if (brokerageactid.isEmpty()) {
>>>           brokerageactid = file->nameToAccount(statementTransactionUnderImport.m_strBrokerageAccount);
>>>         }
>>> +     if (brokerageactid.isEmpty()) {
>>> +       brokerageactid = file->nameToAccount(thisaccount.brokerageName());
>>> +     }
>>>
>>>         // find the security transacted, UNLESS this transaction didn't
>>>         // involve any security.
>>
>>> --
>>>
>>> Chris
>>
>> Hi Chris
>>
>> Thanks for this patch, too.  I've found here, though, that
>> brokerageactid gets over-written a bit later, circa line 1086 in
>> mymoneystatementreader.cpp -
>>
>>     // Add the 'account' split if it's needed
>>     if (! transfervalue.isZero()) {
>>       // in case the transaction has a reference to the brokerage
>> account, we use it
>>>>>     if (!statementTransactionUnderImport.m_strBrokerageAccount.isEmpty() && brokerageactid.isEmpty()) {<<<
>>         brokerageactid =
>> file->nameToAccount(statementTransactionUnderImport.m_strBrokerageAccount);
>>       }
>>       if (brokerageactid.isEmpty()) {
>>         brokerageactid =
>> file->accountByName(statementTransactionUnderImport.m_strBrokerageAccount).id();
>>       }
>> //  There is no BrokerageAccount so have to nowhere to put this split.
>>       if (!brokerageactid.isEmpty()) {
>>
>> and I needed to make the change on the line indicated by >>>....<<<, to
>> avoid that happening.
>>
>> I'm importing via CSV and there is no mapping of OFX source to an
>> account for the brokerage/checking account so the user gets asked to
>> enter this.  If he specifies an existing account, all is well.  If,
>> however, because he makes a mistake or abbreviates a long name, the
>> transfer will go to the investment account's associated brokerage
>> account.  Generally, personally, I don't use these brokerage accounts
>> because for me, they are not real and I would then have to make a manual
>> transfer.
>>
>> It might be interesting to know what happens with your OFX transfers
>> if/when they reach this code.
>>
>> Allan
>>
>