--------------ABD37C4A2B63DF15BDCB9372
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I'd like to see the QIF importer automagically assign the appropriate tax
category to imported accounts, though, I'm not sure there is sufficient
information in the QIF file. Several months ago, I looked at the QIF code
for a few hours, but I really couldn't understand what was going on.
Perhaps a set of default accounts with pre assigned tax categories would
be appropriate?
Gilligan
Bill Gribble wrote:
> 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
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnumatic.com
> http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
--
Gilligan | __o .oooO
/| _ \<,_ ( )
/p|\ (_)/ (_) \ ( Oooo.
/ | \ ------------ \_) ( )
======== ) /
======== gilligan@mpinet.net (_/
~~~~~~~~~~~~~~~~ uschold@cs.ucf.edu
--------------ABD37C4A2B63DF15BDCB9372
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
I'd like to see the QIF importer automagically assign the appropriate tax
category to imported accounts, though, I'm not sure there is sufficient
information in the QIF file. Several months ago, I looked at the
QIF code for a few hours, but I really couldn't understand what was going
on. Perhaps a set of default accounts with pre assigned tax categories
would be appropriate?
Gilligan
Bill Gribble wrote:
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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@lists.gnumatic.com
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
--
Gilligan | __o .oooO
/| _ \<,_ ( )
/p|\ (_)/ (_) \ ( Oooo.
/ | \ ------------ \_) ( )
======== ) /
======== gilligan@mpinet.net (_/
~~~~~~~~~~~~~~~~ uschold@cs.ucf.edu