[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