Hello KMyMoney Experts,

My Env:
------------
Windows 7
KDE 4.7.4
KMyMoney 4.6.1
------------

I am migrating from GnuCash to KMyMoney2. I am using this for the first time. I was able to install and set it up on my windows 7 laptop. However, I am not able to import a QIF File.

I am trying to import a QIF file. The readings look as -

!Type:Bank
D07/12/2011
T-28,809.00
N
xxxxxxxxxxxxxx
M
LTCI
^

D08/12/2011
T-6,319.00
N
xxxxxxxxxxxxxxxxxxxxx
M
LTCI
^
or another file which reads as -

!Type:Cash
D12/24/2011
LExpenses
T-1.50
MWater
^
D12/24/2011
LExpenses
T-56.00
MTaxi to hotel
^

However, the import doesnt seem to do anything. The output reads as -

"The statements have processed with the following results:"
[ OK ]

and thats it... no results or any more details as shown on other screenshots in other websites. It also hasnt updated the transactions in kmymoney !

Any guesses on what could be done to correct it. Without a QIF import this tool would be useless for me ...

Best Rgds
DK

Before we go into deep analysis of your problem: did you try to import the GnuCash file directly? KMyMoney can do so, though YMMV.

Yes I did ! and also successfully imported it. But then I came to the opinion that I would rather not do it and leave it there. I want to start fresh from the new year - clean chit !

The problem I am facing is not importing from GnuCash but importing a QIF file.

The way I work is (being the lazy boy I am), I use my cards (debit/ credit) for all txns and then export/import those txns to a finance manger software (e.g. gnucash) to chew over the details once every 15 days / month .... So importing qif files is one of my basic requirements to use a finance manager !!

I just installed KMyMoney from Sourceforge (latest stable release) yesterday...

And I expect you get those QIF files from your bank, right?

Do you have an account structure setup in KMyMoney already? For each card you need an asset or liability account. Once you have those, you should be able to import QIF files, though they could be created during the import process as well.

For the processing: you should see a dialog that asks for the file and the type of import (bank statement vs. transfer from other app). In case you only use those two transactions you show in your first example you will be asked to select a date format. Next, you are asked to select an account into which the data shall be imported. The final step is the information window you mention.

I just tried to do that with your first data snippet and the final info dialog showed two transactions imported. Same with the second data snippet, just the question about the date format did not show as the data is not ambiguous. One major difference: I use a linux environment. One thing that is always crucial: does your file contain CRLF or LF line ending? Open your file in Windows notepad and if things look OK that it is CRLF if it looks odd, then it is probably only LF.

One thing that makes we wonder is the line containing those xxxxx. What is the first letter in them? The first letter of each line in a QIF file is an indication on what that line contains.

Some more information can be found in the (online) manual

Yes, these are from bank

Yes, I have accounts added to KMyMoney- savings / checking as Assets and credit cards as liability -selecting appropriately.

Yes, I get this window popup on click of File > Import > QIF
Where I select - filename to import, QIF Profile - the one that I created which has the right date format (%d/%m/%yyyy) using Tools > QIF profile editor, and Source of QIF. I have tried with both bank and other apps options.

The problem is in next step. I am not asked for any of these mentioned in your post - "Next, you are asked to select an account into which the data shall be imported. The final step is the information window you mention." - I dont get any windows after I click "Import" button on the first window.

I also tried changing to windows / unix format for both bank / app combinations. Same result - doesnt work.

I also tried changing to windows / unix format for both bank / app combinations. Same result - doesnt work.

I can confirm that this is a bug in the Windows version I'll take care of it.

Thank you !

Pls do drop a note here (or an email) when this is fixed. I would hold off using KmyMoney until this is fixed...

Please follow Bug #290483 instead since it could be that I'll forget about this thread . You can add your mail to the bug's CC and will be notified about any progress.

cristian.onet wrote:Please follow Bug #290483 instead since it could be that I'll forget about this thread . You can add your mail to the bug's CC and will be notified about any progress.

I've followed the bug with a big interest, and I'm very pleased of this workaround! Thanks! It's working great for me too ...except for one thing! I'm using french category names, and I'm not able to import characters like these: éèôëàç.

I did a rapid test... If I export account transactions from KMyMoney, and try to import them back in KMyMoney, I got "unknown characters" (black diamond with a question mark �), instead of my french characters.

Is there a workaround for this one too ? I've tried dos2unix to convert my file before importing it, but since KMyMoney can't import back what it has exported, I don't think the problem is there. What do you think ?

Thanks a lot in advance!

P.S. I'm using Windows Vista

The data is expected to be formatted in UTF-8. If your file is not, then please convert it before doing the import. The same applies for exported data.

ipwizard wrote:The data is expected to be formatted in UTF-8. If your file is not, then please convert it before doing the import. The same applies for exported data.

Thanks for this information! I'll try this tonight, with the GnuWin32 iconv and dos2unix tools I've found. But, obviously, the KMyMoney OFX export generate a Win-1252 file with LF instead of CR+LF standard. I'll say "on my side", because I'm new with KMyMoney, and I'm not sure if my configuration is OK.

A lot of "fun" all those encoding "standards"!

Thanks again!

I just added a fix to git master that ensures the usage of UTF-8 encoding during QIF export. So that should not be a problem in the future anymore.