After an OFX download to an investment account Dividend (and possibly other) transactions are flagged with the ! diamond and the message "Transation has a missing assigment of ...". If I attempt to fix this by editing the transaction, the editor fills in the required "Account" information by default, however the "Enter" button is grayed out until some change is made (even adding a blank and backspace after the default entry). I think two things are at fault here: 1. The "Brokerage" account should have been filled in in the origional download, and 2. If the "edit" code is going to supply a default (and I think it should), it should allow immeadiat entry.
Is this the same behavior reported at BUG 337251?
(In reply to Cristian Oneț from comment #1) > Is this the same behavior reported at BUG 337251? The edit issue is the same, however, that report centered around a QIF import, which I believe now supplies the right Brokerage account. This report, basically is asking for the same behavior WRT OXF imports, which of course, are far more frequent. -- George
Could you provide a sample OFX file? Having all the data available to reproduce the bug means that the fix will be available faster. You can trace your OFX traffic and remove all personal information, or create a file from scratch.
(In reply to Cristian Oneț from comment #3) > Could you provide a sample OFX file? Having all the data available to > reproduce the bug means that the fix will be available faster. You can trace > your OFX traffic and remove all personal information, or create a file from > scratch. If I use version 4.6.6 to fetch the OFX info it results in the missing info. The git version does this correctly. On the otherhand, the mess left by the 4.6.6 version causes the edit function to behave as described. Given this, I would not really mind if you changed the status to Fixed in the git. If you would like to look into the edit issue I will provied the OFX file. -- George
(In reply to george from comment #4) > (In reply to Cristian Oneț from comment #3) > > Could you provide a sample OFX file? Having all the data available to > > reproduce the bug means that the fix will be available faster. You can trace > > your OFX traffic and remove all personal information, or create a file from > > scratch. > > If I use version 4.6.6 to fetch the OFX info it results in the missing info. > The git version does this correctly. On the otherhand, the mess left by the > 4.6.6 version causes the edit function to behave as described. > > Given this, I would not really mind if you changed the status to Fixed in > the git. > If you would like to look into the edit issue I will provied the OFX file. > Uh... Cancel that, the current git version still shows the missing assignment. What is the "correct" action? At the moment hitting Edit and Enter fixes things, but shouldn't KMM just assume the linked account? -- George
To be able to ensure we look at your actual problem, we really do need a sample OFX file that shows the problem, but not your password, etc. I've just imported an OFX file here, and that seemed all correct here.
Created attachment 89052 [details] OFX file that shows the problem This is a human readable copy of the OFX file. I don't have and OFX editor yet or I would have removed all the status stuff at the end. Shows two problems, the missing assignment on the stock transaction and the negative dividend reported in BUG 339774.
(In reply to george from comment #7) > Created attachment 89052 [details] > OFX file that shows the problem > > This is a human readable copy of the OFX file. I don't have and OFX editor > yet or I would have removed all the status stuff at the end. > Shows two problems, the missing assignment on the stock transaction and the > negative dividend reported in BUG 339774. Oh, and another problem... It appears that the transaction ID is lost when editing a transaction as the dividend transactions that I had edited to reverse the sign were not matched on the new import. This means I see all those dividend transactions again.
OFX is plain text, so emacs or vim or nano will work just fine. Some OFX software does not include any white space, making it very hard to read, but adding white space should not make any difference. There is no need for an OFX specific editor, unless you want it to actually help parse it for correctness and break it into human digestible pieces. (I don't know of one of those, but it would be a neat idea.) The transaction ID should be a field within the OFX, so unless you explicitly removed something, it would still be there. However, if there is no actual transaction ID included, then it will re-import every time, since it can't match by ID, and the previous transaction will already have been matched.
(In reply to Jack from comment #9) > OFX is plain text, so emacs or vim or nano will work just fine. Some OFX > software does not include any white space, making it very hard to read, but > adding white space should not make any difference. There is no need for an > OFX specific editor, unless you want it to actually help parse it for > correctness and break it into human digestible pieces. (I don't know of one > of those, but it would be a neat idea.) > I have written a bit of tcl/tk code that a: verifys correct structure, b: adds white space and indention and c: puts the result in a window that you can search, edit, and save. The addition I think would be nice is to have a command that, given a mouse position, would select to the matching closing </...>. > The transaction ID should be a field within the OFX, so unless you > explicitly removed something, it would still be there. However, if there is > no actual transaction ID included, then it will re-import every time, since > it can't match by ID, and the previous transaction will already have been > matched. I think you miss understand what I edited here. I edited the transaction in KMM. But then, the next down load produced the orgional un-edited transactions in KMM. To me this means that the KMM edit lost the transaction ID so it thought the new transaction was not same as the prior one.
I'd be interested in seeing a copy of your tcl/tk program. I'd be tempted to use emac. I have not explicitly used the sgml mode to have it validate the xml (assuming I have a copy of the DTD, and could figure out how to point emacs to it, since most OFX don't include that info) but I know it can find enclosing parens, braces, and brackets. (I haven't used that feature in a while, so i don't remember the commands, but I might now dig them up again.) Regarding the transaction ID, I'm pretty sure nothing you can do through the user interface in KMM would delete the ID. I suspect that the download doesn't have one. Without such an ID, KMM does not know that the new download is the same transaction as the previous one, so it imports it as a new transaction. If it DID have the ID, I believe it would simply reject it as a duplicate, and not even notice that any of the details had changed.
On 10/08/14 17:29, Jack wrote: > https://bugs.kde.org/show_bug.cgi?id=339192 > > Jack <ostroffjh@users.sourceforge.net> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |ostroffjh@users.sourceforge > | |.net > > --- Comment #11 from Jack <ostroffjh@users.sourceforge.net> --- > I'd be interested in seeing a copy of your tcl/tk program. I'd be tempted to > use emac. I have not explicitly used the sgml mode to have it validate the xml > (assuming I have a copy of the DTD, and could figure out how to point emacs to > it, since most OFX don't include that info) but I know it can find enclosing > parens, braces, and brackets. (I haven't used that feature in a while, so i > don't remember the commands, but I might now dig them up again.) I am not trying to validate against the DTD, but just that each <xx> has a properly nested <?xx> unless it is a simple value. I am toying with the tcl/tk code now to see if I can get it to easily select a closing (i.e. </..) given the opening. > > Regarding the transaction ID, I'm pretty sure nothing you can do through the > user interface in KMM would delete the ID. I suspect that the download doesn't > have one. Without such an ID, KMM does not know that the new download is the > same transaction as the previous one, so it imports it as a new transaction. > If it DID have the ID, I believe it would simply reject it as a duplicate, and > not even notice that any of the details had changed. Easy enough to check, by looking at the data file. I do know that the OFX has the IDs as I count on them when I down load, and, of course, I can see them in the OXF fille.
Git commit b9bfdf3f338492f64119958970f70e4610d103aa by Cristian Oneț. Committed on 19/10/2014 at 09:16. Pushed by conet into branch 'master'. Properly import OFX investment transactions. Since fixing a previous issue the amount is no longer negative for investment transactions so, to obtain the total, the fees need to be added (have the same sign as the amount). Now the provided file is imported without triggering the missing assignment error. This was caused by miscalculated values, the shares were properly imported. M +12 -7 kmymoney/converter/mymoneystatementreader.cpp http://commits.kde.org/kmymoney/b9bfdf3f338492f64119958970f70e4610d103aa
Git commit 41029ceb3662cc687ad77224d24e788d14de54db by Cristian Oneț. Committed on 19/10/2014 at 09:16. Pushed by conet into branch '4.7'. Properly import OFX investment transactions. Since fixing a previous issue the amount is no longer negative for investment transactions so, to obtain the total, the fees need to be added (have the same sign as the amount). Now the provided file is imported without triggering the missing assignment error. This was caused by miscalculated values, the shares were properly imported. (cherry picked from commit b9bfdf3f338492f64119958970f70e4610d103aa) M +12 -7 kmymoney/converter/mymoneystatementreader.cpp http://commits.kde.org/kmymoney/41029ceb3662cc687ad77224d24e788d14de54db
(In reply to george from comment #12) > On 10/08/14 17:29, Jack wrote: > > https://bugs.kde.org/show_bug.cgi?id=339192 > > > > Jack <ostroffjh@users.sourceforge.net> changed: > > > > What |Removed |Added > > ---------------------------------------------------------------------------- > > CC| |ostroffjh@users.sourceforge > > | |.net > > > > --- Comment #11 from Jack <ostroffjh@users.sourceforge.net> --- > > I'd be interested in seeing a copy of your tcl/tk program. I'd be tempted to > > use emac. I have not explicitly used the sgml mode to have it validate the xml > > (assuming I have a copy of the DTD, and could figure out how to point emacs to > > it, since most OFX don't include that info) but I know it can find enclosing > > parens, braces, and brackets. (I haven't used that feature in a while, so i > > don't remember the commands, but I might now dig them up again.) > I am not trying to validate against the DTD, but just that each <xx> has > a properly nested <?xx> unless it is a simple value. I am toying with > the tcl/tk code now to see if I can get it to easily select a closing > (i.e. </..) given the opening. > > > > Regarding the transaction ID, I'm pretty sure nothing you can do through the > > user interface in KMM would delete the ID. I suspect that the download doesn't > > have one. Without such an ID, KMM does not know that the new download is the > > same transaction as the previous one, so it imports it as a new transaction. > > If it DID have the ID, I believe it would simply reject it as a duplicate, and > > not even notice that any of the details had changed. > Easy enough to check, by looking at the data file. I do know that the > OFX has the IDs as I count on them when I down load, and, of course, I > can see them in the OXF fille. Ok, just got a boat load of dup transactions. Here is a clip from the *.kmy file showing the old and new: <TRANSACTION postdate="2014-09-17" commodity="USD" memo="DIVIDEND RECEIVED" id="T000000000000001865" entrydate="2014-10-07"> <SPLITS> <SPLIT payee="" reconcileflag="2" shares="25/1" reconciledate="2014-09-30" action="" bankid="" account="A000024" number="" value="25/1" memo="DIVIDEND RECEIVED" id="S0001"/> <SPLIT payee="" reconcileflag="0" shares="-25/1" reconciledate="" action="" bankid="" account="A000238" number="" value="-25/1" memo="" id="S0002"/> <SPLIT payee="" reconcileflag="0" shares="0/1" price="1/1" reconciledate="" action="Dividend" bankid="" account="A000212" number="" value="0/1" memo="DIVIDEND RECEIVED" id="S0003"/> </SPLITS> </TRANSACTION> <TRANSACTION postdate="2014-09-17" commodity="USD" memo="DIVIDEND RECEIVED" id="T000000000000001959" entrydate="2014-10-20"> <SPLITS> <SPLIT payee="" reconcileflag="0" shares="0/1" reconciledate="" action="Dividend" bankid="" account="A000212" number="" value="0/1" memo="DIVIDEND RECEIVED" id="S0001"/> <SPLIT payee="P000001" reconcileflag="0" shares="25/1" reconciledate="" action="" bankid="ID 14656805826201220140918" account="A000238" number="" value="25/1" memo="DIVIDEND RECEIVED" id="S0002"/> <SPLIT payee="" reconcileflag="0" shares="-25/1" reconciledate="" action="" bankid="" account="A000024" number="" value="-25/1" memo="DIVIDEND RECEIVED" id="S0003"/> </SPLITS> <KEYVALUEPAIRS> <PAIR key="Imported" value="true"/> </KEYVALUEPAIRS> </TRANSACTION> So, yes, turing the sign around in the edit did eliminate the transaction (AKA bankid) ID.
I assume the later entrydate is the one you just imported, and the earlier entrydate is the one you imported first, and then manually edited to change the sign. The main thing I notice is that these two transactions do not appear identical. The amounts are reversed between accounts A000024 and A000238. This doesn't make sense if the amount was imported incorrectly the first time and you manually corrected it. I see several other things I wonder about. The first transaction has apparently had one of the accounts reconciled, although the reconcile date is before the entry date. Strange things can happen if you edit a reconciled transaction. (I am assuming the entrydate gets updated on any edit to the transaction - but I don't know that for certain.) Only the new transaction shows "Imported" as "true." I don't know if editing an imported transaction changes this value. The split with the bankid present in the new transaction also has a payee assigned to that split. There is no payee assinged in the older transaction. That might have affected the matching (or lack) on import. I'm also not sure why the bankid is assigned to one of the splits instead of to the transaction itself. The three splits are in different order in the two transactions. I don't know if that is useful information or completely irrelevant. Hopefully someone else can make more sense of this than I can.
(In reply to Jack from comment #16) > I assume the later entrydate is the one you just imported, and the earlier > entrydate is the one you imported first, and then manually edited to change > the sign. Yes, after the change I reconciled. > > The main thing I notice is that these two transactions do not appear > identical. The amounts are reversed between accounts A000024 and A000238. If it helps, 24 is the investment Brokerage account and 238 appears to be _Dividend 212 is the security > This doesn't make sense if the amount was imported incorrectly the first > time and you manually corrected it. > > I see several other things I wonder about. The first transaction has > apparently had one of the accounts reconciled, although the reconcile date > is before the entry date. I think the reconcile date is not when it was reconciled, but to what date it was reconciled. Note it is to the end of the month. > Strange things can happen if you edit a > reconciled transaction. (I am assuming the entrydate gets updated on any > edit to the transaction - but I don't know that for certain.) > > Only the new transaction shows "Imported" as "true." I don't know if > editing an imported transaction changes this value. > > The split with the bankid present in the new transaction also has a payee > assigned to that split. There is no payee assinged in the older > transaction. That might have affected the matching (or lack) on import. > I'm also not sure why the bankid is assigned to one of the splits instead of > to the transaction itself. > > The three splits are in different order in the two transactions. I don't > know if that is useful information or completely irrelevant. > > Hopefully someone else can make more sense of this than I can.