QFX Import Problem

[Greg]

Jack,

Again, thank you for your assistance.

I did attempt to import the QFX files using the File/Import/QFX method.

My main credit cards are from:

  *   Citibank
  *   Capital One
  *   FIA Card Services (Fidelity branded cards)
  *   USAA

But, I am still perplexed by the way the QFX file import works.  My experience showed that an import of a QFX file had some transactions handled appropriately but most were not.  Yet, the transactions appear similar inside the QFX file.  From your statements this import method would work for some banks but not others.

Is this due to the QFX file format being under the control of Intuit?  Or, is there a bug in KMyMoney in the QFX file import?

Greg


On 3/2/2016 11:59 AM, Jack wrote:
On 2016.03.02 09:03, Greg wrote:
Jack,

Thank you for the quick reply.  Unfortunately, I am unable to implement your method,  I must be missing something obvious.  Does your method require a plugin?

The OFX plugin is always included with the source, and it's obviously installed if you are importing QFX files.  (Am I correct to assume you use File/Import/OFX?)  Unfortunately, my description only applies if you have mapped to an online account.  That allows you to just click the "update" button to download transactions, instead of having to log into the bank's web site and download the QFX file.  You might want to try that, although there are some institutions where it doesn't work without some extra effort.  If you tell us which bank these credit cards are with, someone can hoepfully say whether it works well or not.  For example, Chase used to work just fine, but recently made a change so a direct mapping of the account no longer works without applying patches to the source code.  However, American Express works fine.

Allan - can you easily tell if that selection on where to get the payee name is applied during the OFX direct connect download, or later when actually importing the already downloaded OFX.  If it's the latter, I can file a wishlist to allow that configuration even if the account isn't mapped to an online account.


When I bring up the edit account window for the credit card accounts, there is no Online Settings Tab.  Rather, the only tabs showing are:

  *   General
  *   Institution
  *   Hierarchy
  *   Limits
  *   Tax

I examined each of these tabs, and there is nothing that resembles the tabs that you describe.  I also went through setting up a new credit card account and saw nothing that lead to connecting to an online account.  I am puzzled and assume that I have not implemented something.

I reviewed the help documents to find a description of a Online Settings Tab but came up empty.

Greg


On 3/1/2016 4:03 PM, Jack wrote:
On 2016.03.01 09:50, Greg wrote:
I am a new user of KMyMoney and still testing the program.  As such, maybe this is not an error but user inexperience.  My question is there something that I can do so that 'Pay to' field is filled in properly.  Your insight is welcome.

After setting up two credit card accounts I downloaded transactions from the two banks in the QFX file format.  While the files were imported into KMyMoney successful, some of the data do not enter into proper fields.  Specifically, most of the time the 'Pay to' contains the single letter, E, and the memo field contains the payee information.  However, some of the time the 'Pay to' field contains the proper payee information information but so does the 'Memo' field; the payee information is duplicated in these cases. To correct the 'Pay to' field I have to manually edit most transactions by moving the 'Memo' field information to the 'Pay to' field.  As a consequence, this editing of most transactions negates the convenience of downloading the transactions.

The date and charge (amount) fields have the correct information.

I can not find anything in the QFX files that would lead to this result.  I examined the QFX files, and the payee information is always contained in the line having tag <NAME>.   To demonstrate the file information I copied a few lines where the KMyMoney successful fills in the 'Pay to' field. and a few lines showing where the it is not.

KMyMoney successful filled in the 'Pay to' field (data in the date and amount fields editied) with these lines:
<STMTTRN>
<TRNTYPE>Debit
<DTPOSTED>yyyymmdd120000
<TRNAMT>-xx.xx
<FITID>yyyymmdd0001
<NAME>Amazon.com             AMZN
</STMTTRN>
While this transaction shows an Amazon charge, other transactions from local stores are properly inserted.

KMyMoney filled in the 'Pay to' field with the letter E (data in the date and amount fields removed, and the store number and location were changed to nnn and AAAA) with these lines:
<STMTTRN>
<TRNTYPE>Debit
<DTPOSTED>yyyymmdd120000
<TRNAMT>-44.55
<FITID>yyyymmdd0002
<NAME>HARRIS TEETER #nnn     AAAA
</STMTTRN>

This problem occurs for both credit cards that are issued by two different banks.  So, I do not believe that this issue is due to a particular bank.

I am using KMyMoney version 4.7.2 on a Windows 10 system.  The program was installed a few weeks ago.

Greg,

Welcome to KMyMoney.  Yes - this is something you should be able to configure.  However, right now, I can only find the way to do this if you have mapped the account to an online acccount.  (OFX and QFX are treated exactly the same by KMM).  In this case, with the ledger open for the account (you probably have to do it for each account for which you import) click the Edit Account button (or select the Account/Edit Account... menu item) then select the Online Settings tab, and then the Import Details subtab.  There is a dropdown at the bottom labelled "Payee's name is based on contents of the OFX tag" with possible values PAYEEID, NAME, MEMO.

Question to the developers:  is there an equivalent mapping for aqbanking, and for libOFX, is there a way to configure it for file import?  I would expect this shouldn't matter whether the OFX comes from a file or from a direct connect.

Jack

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kmymoney/attachments/20160303/7b5bdc39/attachment.html>