Looks to me, that you get tricked by a feature here. Please check the following :

Do you have a payee "P field" that has a matching option setup to cause the above behaviour?

This is the only thing I could think of as things are working here fine and there haven't been any changes in this area of the code lately.

Please confirm or provide more information.

Thomas,

thank you for looking into this. 
Yes, you're right, I got caught by the "matching option". The file I sent works fine when the matching is disabled.

However, my original problem remains and it is the following. I have a .qif file which, when imported in the KMyMoney data files containing all my accounts, does not import properly the Details field. However, for the purpose of testing/experimenting, I created a new, empty .kmy file. When importing the same .qif file, all the Details are imported properly.

The next step for me is to produce a simpler (almost empty) .kmy file for which the import does not behave as expected so that can provide it to you for testing (I wouldn't like to distribute the original file as it obviously contains lot of sensitive, personal data).

Of course, if there is anything you would like me to do to help you, let me know!

Antony.

An example to reproduce the problem sure would be fine.

Regarding the sensitive information: do you know about the anon-xml file format? Check http://kmymoney2.sourceforge.net/online-manual/details.formats.html for details.

My apologies for not following this up earlier.

After numerous experiment at importing different QIF files into different KMY files, I have finally got this problem sorted. 

Also I cannot confirm it, I believe I know what the problem was. At some point a blank payee got added to KMY file and the default option is to match transaction automatically. The QIF file I tried to import had P fields containing 2 consecutive white spaces in the middle of the description. When importing, the matching process identified these payees as identical to the blank payee already in the KMY database and automatically replaced those payee by a blank payee.

While the new matching feature confusing me for some time, I am not quite sure if this is the expected behaviour. I leave you the decision on whether this bug must be close without further investigation or not.

Thank you for your help with this. KMyMoney is a great application, thank you to all of the contributors!

Antony J.

PS: While trying to follow you suggestion about using the anon-xml, I noticed that unfortunately the Save-as command crashed KMyMoney every time I used it. Unfortunately, my system could not collect enough debug infos to report it in a useful way. I'll check if this has already been reported.

Made it a wishlist item, so that we can come back later to it for decision.

can i get some more information on what is, and where to find this matching feature?

I am having some issues with importing qif files but would like to explore as many options as possible before submitting a bug report

I have some problems with the automatic matching feature too: several of the transactions imported via HBCI are matched wrong (my bank is the ING-DiBa). Complicating is, that KMM doesn't display the original transaction texts from the bank, so I have no chance to correct the wrong matching.

So I have to wishes and would like to propose:
1) please implement a global feature where you can switch on/off the automatic matching
2) please implement a global setting for new payees where I can preset if you would like to auto match it or not by default
3) please improve the handling of the HBCI imported transactions text: all text should be available after conceiling it

In general I would place an idea for improving the process to match imported transactions with existing transactions:
It would be more clear and easier, if you get a two divided window with two lists:  on the upper side you see all new imported transactions via HBCI (or QIF or whatever). Below that list you can find your transactions from the ledger,
Then you can select a transaction from the import list and add it to your ledger, or you can select an existing transaction in the ledger to "connect" / match them. 

You can see this behaviour for example im Quicken or in Mac Giro.

It seems the original poster is ok closing this as WORKSFORME, although he asks whether it is correct or not for a P field which contains two spaces embedded between other text to match to a payee with a blank name.  Unless someone confirms this is wrong behavior, this should probably be closed.

I originally responded to Harry Bennett on th emai list, and I think Markus' request should be opened as a new wishlist item if they are still desired, although we probably already have some existing requests in this area.

Is it time to close this, or does the wishlist item still need to be filed?

I'm finally going to close this, but I do note that there is a new feature recently added to the master branch that imported transactions now show "Original payee: " so you don't lose that text if the payee was matched.  Unfortunately, there is not yet a timeline for a release with this feature.