Other QIF bugs (or misfeatures)
Wed, 14 Feb 2001 10:10:31 -0600
On Wed, Feb 14, 2001 at 10:39:17AM -0500, Derek Atkins wrote:
> * No default QIF account name: The 1.4 importer had the nice
> feature that if the QIF file itself didn't have a default
> QIF account, the importer would assume one based on the
OK, I'll put that back. I had a reason for removing it which I don't
remember any more :)
> * It would be nice if the list of "QIF files you have loaded"
> listed the filename and also the default QIF account.
This is iffy because many/most QIF files refer to lots of accounts,
and/or don't need a "default" account because every transaction is
explicitly listed in a !Account section. I'm leaning "no" on this
unless you can persuade me otherwise.
> * On the Match QIF account with Gnucash accounts page, there
> is no way to toggle the "new" column. Even if the Gnucash
> account already exists (through a previous QIF import of by
> choosing an account through the chooser), the importer will
> still keep the "new" column checked.
That's not supposed to be true, and I can't duplicate the behavior on
my end. Your later comments are confusing to me, too. The "name
conflict with existing account" happens only when you have specified
(through saved mappings or explicit account designation) a Gnucash
(a) already exists AND
(b) has a different currency/security from the account
intended for QIF import OR
(c) is of an incompatible type (i.e. Quicken expense categories
aren't compatible with a Gnucash Bank account).
With a current CVS gnucash (and I know you are running that :) if I
select an existing account in the account picker the "new" checkmark
goes away, even if the types are incompatible, and a new account is
created with the "conflict" message IFF the accounts are actually
incompatible. Could you please pop up the Edit Account window for the
"original" gnucash account and the "conflict" account and check the
account Type, Currency, and Security? (if the Security is grayed out,
it's ignored, so it doesn't matter if they differ). If they are all
the same, i'm not sure what's going on.
> * I did not get the "duplicate transaction" screen at all in
> the first import. For kicks, I tried to import the same QIF
> file a second time, and again I did not get the duplicate
> transaction screen.
You only get the duplicate xtn screen if duplicates are detected; the
algorithm is pretty strict right now, and given the way you described
the import failures I doubt it would detect any at all (the Gnucash
account endpoints of the transactions have to be the same for them to
be duplicates, and the way you're describing them they are put into
different, new accounts, so they aren't duplicates.).
> * After the second import I have two sets of the tranactions
> loaded. In addition I now have _three_ duplicate acount
> trees, two of which are labeled "QIF Import" Name conflict
> with another account".
*This* is a problem. My logic for finding a "fallback" account is to
append the number to the name and keep incrementing it until unique; I
should probably assume that if "foo" is incompatible and "foo 2" is
compatible I should use "foo 2" and not create "foo 3". However, the
existence of "foo 2" should just be transient; i.e. you should move
the transactions where you wanted them to go and delete the account.
> * The account picker is weird. The data that it displays as
> it scrolls is not necessarily the data it shows when it
> starts up.
That's just a bug in the way I'm setting the position of the widget.
It's not updating the display after I tell it to move. I'll fix that.