KMyMoney Digest, Vol 68, Issue 9

aga agander93 at gmail.com
Tue Mar 8 18:31:13 UTC 2016


Hi Greg

On 08/03/16 13:54, Greg wrote:
>     /Just to be clear, when you say "(there were no payee names E)", I
>     couldn't recocile that with your later comments. Unless you meant
>     "there were no payee names E in the QFX file"? I think there must
>     have been a payee E from the QIF imports. In Payees view, how is
>     matching set on payee "E"?/
>
> You are correct in asserting that there were no payees named 'E' in the
> qfx files. In contrast, there was a single payee in the qif file named
> 'E'. This 'E' payee in the qif file was mistake made a long time ago.
>
>   I'm not sure I understand under your question 'how is matching set on
> payee "E"?  I have not set the matching feature, it's set to the
> default.

That is what I was querying.  so, no matching.  However, you presumably 
had no cause to check that at the time of the QFX import.  I suspect 
that, somehow or other, it was at that time set to match on payee name.
Then, any payee name containing an 'E' would get recorded as 'E'.  So, 
those transactions would have 'E' as the payee, and any others would not 
match, which would account for the varying result you report.  As I say, 
'I suspect', but I don't expect any proof.  Again, why it would then be 
set to match, I don't know that either.

   If you're asking if KMM matched transactions in the files, the
> answer is that there should be no matching occurring at all.  Here is why.
>
>   * The dates in the qif files and the qfx files are much different,
>     there was no overlap:
>       o All transactions in*the qif file* occurred over 10 years  ago
>         (latest transaction was June 2003);
>       o All transactions in *the qfx file* occurred less than a year ago
>         (the earliest transaction was August 2015).

On importing a QIF file, an attempt is made to match the payee.  This 
makes no reference to the transaction date.  It is purely a payee name 
match.  It would not result in a transaction match.


>   * Payees named E
>       o There was a only single transaction in the*qif file* having a
>         payee named 'E' (changing the name in the qif file and
>         re-importing file fixes the problem in KMM)
>       o There were no transactions in*the qfx files* having a payee
>         named 'E'.  Every transaction included a named payee with the
>         tag <NAME>.
>           + for most transactions the 'Pay to' field was set to 'E' upon
>             import, e.g. qfx file showed <NAME>GIANT but KMM converted
>             this to 'E'
>           + for a few transactions the 'Pay to' field was set correctly,
>             e.g. qfx showed <NAME>PHO & GRILL and the KMM 'Pay to'
>             field showed PHO GRILL

I can't account for the difference here, but it might be significant 
that the one that was correct included a space in the name.  If you have 
the time/interest, might you copy the GIANT transaction with the name 
being two words, to see if that affects things.

>   * There were no transfers between the accounts.  The files were
>     imported into different KMM accounts:
>       o the qif files into an asset account
>       o the qfx files into a credit card account
>
> Hopefully, this helps.  Again, while I have fixed the problem, I don't
> understand why the problem occurred in the first place.

So, no definite solution, I'm afraid, but hopefully you are now sorted. 
  Importing QIF files is not always perfect, and it is often necessary 
to follow up.

Allan

>
> Greg
>
> On 3/8/2016 3:34 AM, kmymoney-request at kde.org wrote:
>> Send KMyMoney mailing list submissions to
>> 	kmymoney at kde.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> 	https://mail.kde.org/mailman/listinfo/kmymoney
>> or, via email, send a message with subject or body 'help' to
>> 	kmymoney-request at kde.org
>>
>> You can reach the person managing the list at
>> 	kmymoney-owner at kde.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of KMyMoney digest..."
>>
>>
>> Today's Topics:
>>
>>     1. Re: QFX Import Problem (Greg)
>>     2. Re: QFX Import Problem (aga)
>>     3. Re: KMyMoney does not close properly (new issue)
>>        (christian-david at web.de)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Mon, 7 Mar 2016 18:05:14 +0000
>> From: Greg<dybalskigo at hotmail.com>
>> To: KMyMoney Users' mailing list<kmymoney at kde.org>
>> Subject: Re: QFX Import Problem
>> Message-ID:
>> 	<SN1PR11MB07204788111E5A5CDBD26DA9C4B10 at SN1PR11MB0720.namprd11.prod.outlook.com>
>> 	
>> Content-Type: text/plain; charset="utf-8"
>>
>> Previously, I reported unusual behavior from a qfx file import of credit card transactions.  I believe that I have found the problem.  It's a rather bizarre problem that perhaps somebody could explain.  I not sure if it is a bug or KMM configuration problem.  Hopefully, my explanation helps an understanding of the problem because I certainly do not understand it.
>>
>> Summary of the Problem
>> The problem was that KMM failed to show the proper payee information from an import of a qfx file.  Upon import the 'Pay to' field listed the single letter E as payee even though there were payee names in the qfx file (there were no payee names E).  To add to the confusion this occurred for most imported transactions but not all.
>>
>> The KMM version is 4.7.2 under Windows 10.  KMM was installed several weeks ago, and I have been testing how it works before I made it my personal finance program.  Currently, I am using Quicken 2015 so there are file imports.  My method to set up the KMM file consisted of creating a series of KMM files.  After each change to the KMM file I created a new file so that I had a series of KMM files representing the changes.  Consequently, I could back up the process without much effort.
>>
>> The Cause of the Problem
>> The apparent cause of the problem was that previously I imported several qif files, one of which had an errant payee name.  The payee name was E when it should have been Earnings.  It occurred in a single transaction.  This payee E was subsequently used in the qfx file import.
>>
>> Why This Was the Cause
>> Prior to importing the qfx file I had imported several qif files from old investment accounts; these accounts were closed and had only a few transfers.  This was done because I was learning how to import accounts from Quicken, and these files contained 'simple' transactions.  These qif file transactions were imported successfully, but I noticed in KMM's payee view that there was a payee name E.  There was a single transaction with the letter E for payee, and it came from the qif file (and Quicken).  Most likely, this was a typo from a long time ago.  Afterwards when I imported the qfx files, most of the transactions had an E in the 'Pay to' field.
>>
>> Why I Believe This Is the Problem
>> Test 1
>> If I reversed the sequence of file imports by initially importing the qfx files first, the payee problem disappeared.  The correct payee information was inserted into the 'Pay to' field in KMM for all transactions.  The problem is not in the qfx file.
>>
>> Test 2
>> To further test this idea I restarted the file imports from scratch but modified the errant transaction in the qif file.  The letter E was changed to Earnings in the qif file, and the qif files were imported successfully with no payee name E.  Next, the qfx files were imported, and the payee information was inserted correctly into the 'Pay to' field for all transactions.  The problem was corrected by merely changing a single transaction in a prior import.  Why would KMM use payee information from a prior import when the qfx file included payee information.
>>
>> Test 3
>> I tested this idea by restarting the import process all over again but with the original files.  I imported the qif files without the corrected transaction and then imported the qfx files.  The letter E shows up in 'Pay to' field for most of the transactions but not all. I was able to replicated the problem.  But, why do some transactions import successfully?
>>
>> Greg
>>
>> On 3/3/2016 10:43 AM, Jack wrote:
>> On 2016.03.03 10:27, Greg wrote:
>> 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?
>>
>> First, understand that QFX and OFX are effectively the same thing.  The format may have initially been created by Intuit, but the standard is now published by The Open Financial Exchange Consortium.  One problem is that different OFX software (as used by the banks, but generally written and run by other software companies) interpret the standard somewhat differently, leading to subtle differences in OFX produced by each of them.
>>
>> That said, I don't think there are bugs, either in the libOFX library that KMM uses, or in how KMM uses it.  Actually, although there may well be bugs, I suspect your issue is related to configuration.
>>
>> So, to go back to the beginning, which version of KMM are you using, and on what platform or distribution?  If you are not uses 4.7.2, the most recent version, that would be the first thing to change, since there have been some changes in this area.
>>
>> In addition, we need more details to be able to focus in on a cause.  For now, let's stick to data from just one of those institutions.  (I'm not aware of any particular problem with any of them, but I don't use any of them myself.)  Also, when you say you did attempt to import, if that was in response to this discussion, what did you originally try?
>>
>> You say for one OFX file, some transactions are imported "correctly" (or at least as you would expect) and some are not.  What are the differences?  Does it have to do with matching to already entered transactions?  Does it have to do with matching on Payee name?
>>
>> Have you tried to map to any of these online accounts?  This doesn't always work easily, but if it does, it will let you configure where the Payee name is detected, if that is your primary problem.
>>
>> Sorry to answer with more questions then conclusions, but eventually you should be able to get it all working smoothly.
>>
>> Jack
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:<http://mail.kde.org/pipermail/kmymoney/attachments/20160307/46c204f3/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Mon, 7 Mar 2016 19:03:31 +0000
>> From: aga<agander93 at gmail.com>
>> To:kmymoney at kde.org
>> Subject: Re: QFX Import Problem
>> Message-ID:<56DDD083.8040909 at gmail.com>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> Good work.
>>
>> On 07/03/16 18:05, Greg wrote:
>>> Previously, I reported unusual behavior from a qfx file import of credit
>>> card transactions.  I believe that I have found the problem.  It's a
>>> rather bizarre problem that perhaps somebody could explain.  I not sure
>>> if it is a bug or KMM configuration problem.  Hopefully, my explanation
>>> helps an understanding of the problem because I certainly do not
>>> understand it.
>>>
>>> *_Summary of the Problem_*
>>> The problem was that KMM failed to show the proper payee information
>>> from an import of a qfx file.  Upon import the 'Pay to' field listed the
>>> single letter E as payee even though there were payee names in the qfx
>>> file (there were no payee names E).  To add to the confusion this
>>> occurred for most imported transactions but not all.
>> Just to be clear, when you say "(there were no payee names E)", I
>> couldn't recocile that with your later comments.   Unless you meant
>> "there were no payee names E in the QFX file"?  I think there must have
>> been a payee E from the QIF imports.
>>
>> In Payees view, how is matching set on payee "E"?
>>> The KMM version is 4.7.2 under Windows 10.  KMM was installed several
>>> weeks ago, and I have been testing how it works before I made it my
>>> personal finance program.  Currently, I am using Quicken 2015 so there
>>> are file imports.  My method to set up the KMM file consisted of
>>> creating a series of KMM files.  After each change to the KMM file I
>>> created a new file so that I had a series of KMM files representing the
>>> changes. Consequently, I could back up the process without much effort.
>>>
>>> *_The Cause of the Problem_*
>>> The apparent cause of the problem was that previously I imported several
>>> qif files, one of which had an errant payee name.  The payee name was E
>>> when it should have been Earnings.  It occurred in a single
>>> transaction.  This payee E was subsequently used in the qfx file import.
>>>
>>> _Why This __Was the Cause_
>>> Prior to importing the qfx file I had imported several qif files from
>>> old investment accounts; these accounts were closed and had only a few
>>> transfers.  This was done because I was learning how to import accounts
>>> from Quicken, and these files contained 'simple' transactions.  These
>>> qif file transactions were imported successfully, but I noticed in KMM's
>>> payee view that there was a payee name E.  There was a single
>>> transaction with the letter E for payee, and it came from the qif file
>>> (and Quicken).  Most likely, this was a typo from a long time ago.
>>> Afterwards when I imported the qfx files, most of the transactions had
>>> an E in the 'Pay to' field.
>>>
>>> *_Why I Believe This _**_Is the Problem_*
>>> _Test 1_
>>> If I reversed the sequence of file imports by initially importing the
>>> qfx files first, the payee problem disappeared.  The correct payee
>>> information was inserted into the 'Pay to' field in KMM for all
>>> transactions.  The problem is not in the qfx file.
>>>
>>> _Test 2_
>>> To further test this idea I restarted the file imports from scratch but
>>> modifiedthe errant transaction in the qif file.  The letter E was
>>> changed to Earnings in the qif file, and the qif files were imported
>>> successfully with no payee name E.  Next, the qfx files were imported,
>>> and the payee information was inserted correctly into the 'Pay to' field
>>> for all transactions.  The problem was corrected by merely changing a
>>> single transaction in a prior import.  Why would KMM use payee
>>> information from a prior import when the qfx file included payee
>>> information.
>>>
>>> _Test 3_
>>> I tested this idea by restarting the import process all over again but
>>> with the original files.  I imported the qif files without the corrected
>>> transaction and then imported the qfx files.  The letter E shows up in
>>> 'Pay to' field for most of the transactions but not all. I was able to
>>> replicated the problem.  But, why do some transactions import successfully?
>>>
>>> Greg
>>>
>> Allan
>>
>>
>>
>


More information about the KMyMoney mailing list