I have tested import from OFX and CSV file, but both ignore the Payee field and enter "-" for payee when it starts with a number, e.g. when the Payee is given by an bank account number. Reproducible: Always Steps to Reproduce: 1. Have a CSV or OFX file with a Payee starting with a number, e.g. 000-1111111-22 2. Import the file in kmymoney Actual Results: Import successful but payee is '-" Expected Results: Payee should be 000-1111111-22 or the name if already known by kmymoney
I've had a look at the CSV importing, and, for me, there is no problem. Might you be using via aqBanking?
No, I just use the menu File > Import > CSV
Oh, OK. I've reinstalled 4.6.3, and still I don't see any problem, even with your payee 'number'. It isn't by any chance already in your list of payees, is it, with an incorrect match value? If so, just delete it and try again. That could explain why it affects OFX too.
Created attachment 77644 [details] Test case 1 CSV file as a test case (see comments).
I have tested it a bit further, please see added CSV file I used for testing (comma for amount! :) ). - In a new .kmy file: no problem, added as expected - In the .kmy file I have (created with this kmymoney version, only using it since 2 weeks): the order gets interpreted as a transfer between two of my accounts, with a Pay to value of -. So I guess it is something in my file, but I have no clue as to what it might be...
(In reply to comment #5) > I have tested it a bit further, please see added CSV file I used for testing > (comma for amount! :) ). Your CSV file imports correctly here. > - In a new .kmy file: no problem, added as expected > - In the .kmy file I have (created with this kmymoney version, only using it > since 2 weeks): the order gets interpreted as a transfer between two of my > accounts, with a Pay to value of -. > > So I guess it is something in my file, but I have no clue as to what it > might be... The CSV plugin treats the payee field as alphnumeric and doesn't differentiate so I can only see the problem being how you handle that particular payee. Normally, in the case of a particular user's data file giving unexpected results, the best way ti proceed is with an anonymized version of your .kmy file. This can be produced on saving by selecting in the file selector filter 'anonymous files', and then loading that file as normally, to ensure the problem remains. However, I must confess that I don't know if the anonymizing process itself may change your payee name and sidestep the problem. It might still be worthwhile trying. Just in case, though, would you please remove any payee in the Payee view, that matches your problem payee, and/or selecting that payee in the view, opening the Matching tab, and selecting 'no match', but first saying what is currently set there.
Rereading your last post, I get a different impression compared to your original one. "...but both ignore the Payee field and enter "-" for payee when it starts with a number". I took that to mean that the Payee field became "-", but now you seem to be saying that the amount becomes "-". So, does the payee name actually get imported correctly? If it does, then payee matching would not appear to be the problem, but more a question of matching an already existing transaction. 1) Is there already in your file a transaction involving the two accounts you mention and this payee? 2) In the payee list, for this payee have you set a default account? 3) When importing your file, which fields/columns do you select?
I have checked it further and due to an earlier ledger, a payee '-' was created. Afterwards things seemed to start failing as '-' was used as payee for every transaction. Removing it or setting it to 'no matching' fixes everything. So probably the weird behavior was due to a false payee value and some strange reaction of kmymoney to it.
Closing this since the reported issue was resolved.