On 25/11/13 23:24, Chris Tucker wrote:
During OFX import when direct downloading from the brokerage there isn't a
popup box for matching securities, as there likely shouldn't be. Since the OFX
import should just pull in the transactions and try to match, this make sense.
I might be able to get a OFX transaction to test with if you need it but I will
try explaining first so you can see the problem in the code.
Yes, thanks Chris, but I think I'd got that. I wasn't 100% certain
though that, although the match didn't occur, the transaction did or did
not get accepted. I see now that you actually got that message box
appear. Wonder how my CSV import via the same code managed to avoid
that. Must investigate.
<snip>
My patch may have one problem, though, since I assumed the OFX security name should not
be compared to the iterator symbol and changed the code to compare symbol -> symbol
or name -> name. Maybe there was a reason for the name -> symbol comparison and
the code should read:
if (statementTransactionUnderImport.m_strSecurity.toLower() ==
(*it).tradingSymbol().toLower()
|| statementTransactionUnderImport.m_strSymbol.toLower() ==
(*it).tradingSymbol().toLower()
|| statementTransactionUnderImport.m_strSecurity.toLower() ==
(*it).name().toLower()) {
No, the original code definitely looks wrong, and I don't think your
second idea is necessary. I would say your first was adequate. I've
checked, partly in case I'd slipped up, but that code is over four years
old.
In my testing I never found a reason to compare the OFX name to symbol.
I don't think it would achieve much really!
--
Chris
I'll put that through as soon as my backlog has cleared.
Allan
On Monday, November 25, 2013 10:51:13 PM Allan wrote:
On 25/11/13 01:49, Chris Tucker wrote:
Vanguard Index FDS Mid-Cap Value Index (VOE)
@ Thomas please, below.
Hi Chris
I've had a quick look at your patch, and, while I've not sat and thought
about it in detail, it does look OK.
However, my first thought was 'How do I test it, as I don't have OFX?'
Then, your patch is for mymoneystatementreader.cpp, which is common to
all input methods, so I knocked up a simple CSV file. First, I entered
into KMM, your original security, with a single Buy transaction. Then,
I imported my CSV file containing a Dividend Reinvest for your imported
security. The CSV i9mporter, prior to the actual import, displays the
data from the file, to give the user the chance to edit security names
to correspond to existing securities. This recognises the existing
symbol and security, and doesn't show the new data. I proceed, and
continue the import. The import statement stats show one transaction
processed and one added, with no duplicates. Looking now at the ledger
for the import account, both transactions appear with their own distinct
security names, and the investment view contains both securities with
their own separate names. Back in the Ledger, starting a new
transaction gives a choice of either security, so everything seems OK,
unless you actually wanted the two securities to match, rather than be
independent. You say "...the transaction import fails to find the
security by name.", and it can't because it's dealing with a different
name, but it actually finds it by symbol.
I have not used your proposed patch. Forgive my asking, but I'm
assuming you tested your patch? Did it give the result you wanted, and
to be clear, you do want the two to match?
@ Thomas please, below.
The next point is of principal. I've always taken it that a symbol
needs to be unique within KMM, and I can see possible problems having
two different securities with the same symbol. Of course, this would
resolve if the two securities can actually match.
Allan
_______________________________________________
KMyMoney-devel mailing list
KMyMoney-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmymoney-devel
