Jack, On Wednesday 04 February 2015 18:03:24 Jack wrote:
> On 2015.02.04 15:19, Thomas Baumgart wrote: > > Hi Jack, > > > > On Monday 02 February 2015 18:04:33 Jack wrote: > > > Using OFX direct connect, I just updated an investment account. The > > > most recent transactions imported were for 2014/12/31. The online > > > settings have start date of import set to last update. If I delete > > > > one > > > > > of the transactions from 2014/12/31 and update the account again, it > > > re-imports that transaction. Since the last update was today, I > > > > would > > > > > not expect it to import anything from over a month ago. > > > > > > Looking into the log (ofxlog.txt) the relevant line looks like > > > "<DTSTART>20141202" and this does not seem to change to today's date > > > after an import, whether or not it actually imports any > > > > transactions as > > > > > new. If I explicitly set a start date of import, that date does > > > > show > > > > > up in <DTSTART> in the next update, but if I set it back to date of > > > last update, it goes back to 20141202. The clock on my PC is > > > > correct. > > > > > This is with git head (Version 4.7.90-826bb6aa03) as of a few weeks > > > ago. I'll try to do some more testing, but would appreciate any > > > suggestions as to where I might look for anything else that could > > > affect this. I wouldn't expect a bug, as I don't recall any > > > > changes in > > > > > this area recently - have I missed something? > > > > > > > > > Another minor odd point is that if it DOES import a transaction, I > > > > get > > > > > the popup showing how many transactions were downloaded, how many > > > > were > > > > > duplicates, etc. If all the downloaded transactions are > > > > duplicates, I > > > > > don't get the popup at all. > > > > > > Thanks for any ideas. > > > > I looked into the sources and found out, that we keep the date of the > > last > > transaction from the previous import as that date. I remember that > > for HBCI we > > even subtract a few days from that to be on the safe side as banks > > might add > > data later on (we've seen this happen here via HBCI). Would that > > explain the > > behavior you experience? > > I think I found the issue. The date of last update is not kept in the > ONLINEBANKING part, where I first thought it would be, but in the > keyvaluepairs of the account for lastImportedTransactionDate key. My > credit card and bank accounts all have an appropriate value for that. > However, none of my investment accounts have that keyvaluepair in the > kmy file. This may be another difference between banking/credit card > and investment accounts that need to be thought about again. I don't > know if I can follow the code well enough to dig up where this date > gets updated during an ofx import and why it is apparently handled > differently for different types of accounts. I am guessing that what > happens is if KMM can't find a lastImportedTransactionDate, then it > defaults to either 60 days ago, or the number of days in the settings, > even if the account is set to use last update date. > > Have I missed something, or is this a bug? If you don't find that value in the KVP section of the account, then this is a bug. Here's how I find where it gets set: thb@thb-nb:~/devel/kmymoney (master)$ git grep "lastImportedTransactionDate" | grep setValue kmymoney/converter/mymoneystatementreader.cpp: m_account.setValue("lastImportedTransactionDate", s.m_dateEnd.toString(Qt::ISODate)); kmymoney/mymoney/mymoneyfiletest.cpp: a.setValue("lastImportedTransactionDate", QDate(2011, 12, 1).toString(Qt::ISODate)); kmymoney/mymoney/mymoneyfiletest.cpp: a.setValue("lastImportedTransactionDate", QDate(2011, 12, 1).toString(Qt::ISODate)); So it's only one spot, the other two are testcases. -- Regards Thomas Baumgart GPG-FP: E55E D592 F45F 116B 8429 4F99 9C59 DB40 B75D D3BA ------------------------------------------------------------- 90 percent of all errors are sitting 60 cm in front of the display. -------------------------------------------------------------
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel