1.5 code-freeze for 2.0? Need a better general QIF importer

[Bill Gribble]

On Mon, Jan 29, 2001 at 05:57:58PM -0500, Derek Atkins wrote:
> One piece of functionality which I would hope would make it into a
> code-freeze would be the ability to load (read: merge) Bank-generated
> QIF files into already-existing accounts.  Most of the code is there
> now; the only issue is that there is no way to check a QIF import
> against the current account tree for duplicate transactions.

You're right.  In fact, the additional code doesn't belong in the QIF
importer at all; rather, we need a generalized account-tree merging
routine that merges two gnucash account groups.  At the moment, the
interface the QIF importer uses is xaccGroupMergeAccounts.  I would
like a nice graphical replacement that provides the same functionality
but handles eliminating duplicate transactions based on matching
heuristics.

> I would hope that this functionality would take a higher priority
> that, say, SQL (or even client-server).

The DB and multiuser stuff aren't going into gnucash-2.0.  That's just
speculation, prototyping, and planning for the future.  The set of
folks that have been committing code for gnucash-2.0 doesn't really
overlap the set of people discussing the database and multiuser
changes.  Please don't misunderstand: I am very happy that people have
started addressing the SQL and multiuser issues, and that work is very
valuable.  But I'm also glad that the people who are working on
2.0-critical projects aren't really part of the discussion :)

> Previous discussions led me to believe that this was in the works.
> If I was wrong, I suppose that I should spend the time to tear apart
> the QIF importer and generalize it.

Please don't.  I think it's important to add this functionality, but I
feel very strongly that it is independent from the QIF importer.  Keep
it separate, and keep the API the same as xaccGroupMergeAccount's.

I still have this on my personal list of things to do, but I have a
lot of other things going on right now, mainly focusing on the
reporting and networking infrastructure.  If you have the time and
motivation to do it I'd be happy to help in any way I can.

> My personal view is that the current functionality of the QIF
> importer is really a misnomer.  It does not really import QIF, it
> initializes an account tree based upon a set of QIF files.

That's explicitly what it was designed to do, because the main goal of
importing QIF files is to make gnucash accessible to people who use
Quicken.  The role of QIF files as a network file format is very
important, but importing them flawlessly is the second-most important
kind of QIF importing IMO.  I think that (though there are still a few
bugs left) the basic "import my Quicken data" functionality works
pretty well so it's a good time to add the other.

> The hardest part I can see is determining how to notice a duplicate
> transaction.

Welcome to a very difficult problem in heuristic matching.  That's why
I focused on the "other" kind of QIF importing first.

Bill Gribble