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
_______________________________________________
KMyMoney-devel mailing list
KMyMoney-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmymoney-devel
