Problems with QIF import for checking account - category matching seems horribly designed

[Andrew Sackville-West]

In response to your previous email: the qif importer handles split 
transactions very well. I routinely import multiple transactions with 
upto 20 splits each (payroll... weeee) with no problems at all. In fact, 
its so painless that I get annoyed that I have to surf my directory tree 
to find the import file. the rest of it is so painless as to be a 
non-event for me. ymmv.

Randy Burgess wrote:
> I should clarify that I use the import process primarily to reconcile 
> checking - not to import totally new transactions.

how do you mean? there is a reconcile feature in the program that works 
fine. are you using it to import transactions from your bank? I'm 
confused by this, details would help.
> 
> As I remember the old process, if you identified a transaction as a 
> "dupe," the dupe expense account was used - thus there was no wiping out 
> of this info when importing checking account transactions. That appears 
> to be gone now.

If the importer sees what it "thinks" is a duplicate transaction, and 
you mark it as a dupe, then it doesn't import that dupe as you obviously 
don't need two copies of the same transaction. I can't imagine how old 
the last version you used was, but it must have been creaky. my 
understanding, from lurking on -devel is that the qif importer hasn't 
changed AT ALL for many years.
> 
>> For one reason or another I haven't used the QIF import function in 
>> about a year. Today I just made my first try at importing a QIF for my 
>> checking account, and to my dismay the functionality has been altered 
>> to effectively make it useless -  unless there's some clever trick I'm 
>> missing. (This is Gnucash 1.8.11 on Gentoo.)

I'm using 1.8.11 on debian (mostly cause I'm too lazy to upgrade to 
1.8.12), and qif works flawlessly.
>>
>> Here's the problem: The import wizard forces you to match categories 
>> before it proceeds to actually do the import. The idea seems to be 
>> that it will remember the matches and automate this process the next 
>> time around.

yes. when you bring in a transaction from qif it theoretically has an 
expense "Category". that expense category has to be matched up to an 
expense "Account" in gnucash, unless you are creating a new expense 
account, which it can also do. Once the categories and accounts are 
mapped, you don't have to do it again, unless something changes.
>>
>> But why does it need to match categories like this in the first place? 
>> It didn't used to, back in previous versions (whatever I was using a 
>> year ago).

as I said, that must have been REALLY old.
>>
>> Obviously this process can't handle splits, of which I have many. It 
>> can't handle the fact that for many of my payees, I have more than one 
>> category depending on the nature of the expense.

see above. are you possible using a malformed qif file?
>>
>> So basically the import is more trouble than it's worth. And I haven't 
>> found any options to get around the problem.

that's a matter of opinion. I suspect there maybe something 
fundamentally wrong with what you are doing and if we can fix that, the 
rest should work great. please provide specific details about what you 
are doing. include, if you could, a snippet of the qif you are importing 
as that could help. obviously strip/modify any personally identifiable 
information.

A
>>
>>
> 
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>