[Kmymoney-devel] Yet another OFX import issue
Thomas Baumgart
thb at net-bembel.de
Thu Feb 5 07:16:53 UTC 2015
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 at 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.
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 225 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20150205/f4938ffd/attachment.sig>
More information about the KMyMoney-devel
mailing list