question about importing .qif files

[Eric Mitchell]

I think we're both shooting at pretty much the same target here.

Richard Wackerbarth wrote:

[snip many vs. one]

> > How does the user pick which processor to use?  How do they configure it
> > for their personal situation?
> 
> This problem is not particular to any method of accomplishing the import.

True.  But I see "configure this QIF importer/filter" as an easier 
thing than "Pick from these QIF importers", where one is configured for
Citibank QIFs, one is for Quicken QIFs, etc.  Since I see much of the 
same configuration for each such filter, (e.g. if this field matches 
this criteria, file under this category), I see it as a customization
of configuration, not a specialization of code.

> Unfortunately, each user thinks it is easy to convert from some Memo field
> that encodes his transaction information into his set of accounts. However,
> that ease is based on the false assumption that the next bank does things
> exactly the same way that the user's bank does it. Unfortunately, that is not
> the case.

I'm not advocating restricting the user to "one" importer configuration.
In my head, I saw "filter sets", which could be tuned for each QIF dealt 
with.  On the Import QIF dialog, you pick a file, then either pick a 
filter set or edit existing configurations.  Maybe get a preview of the 
data, so you can configure an importer before the default rule dumps 
everything into the unfiled category.

> > File->Import->QIF (Quicken, generic)
> >             ->QIF (Quicken, customizable)
> >             ->MsMoney
> >             ->Pocket$ for PalmPilot
> >             -----------------------
> >             ->Install New Importer
> >
> > Something like this is what I see in my head.
> 
> I quess that I would remove all of your (above the line) options and make
> them appear only after they get configured.

Even better.

> I would reduce the menu items to "Post from XYZ Bank", "Post from Ripoff
> Credit Card", "Post stock prices from YAHOO", etc.
> 
> Or perhaps we simply tie it to the current Gnucash Account. Open the ledger
> for "XYZ Bank" and select "Online update"

Even better yet. Or "Import File", for downloaded stuff.  Could add it
to the context menu of the account so you don't even have to leave the
front page.

> Hide the details from your wife.

That gets harder and harder the more she learns. =)

[snip stuff]

> > > Frankly, I am waiting for the new "text" format. Once we have it, I'll
> > > advocate stripping the QIF importer out of Gnucash proper and changing it
> > > into a reformatter that translates from QIF to "gnucash text". This
> > > translation step should be combined with appropriate additional commands
> > > to form part of an extensible user menu for acquiring additional data.
> >
> > So you're saying I should download the QIF, install, configure and
> > run "Joe's magic QIF processing script for Your Credit Card's screwy
> > files v0.2.1" on it, and import the output file?  As long as the GUI
> > shields me from having to drop to a shell to do it, I don't care what
> > happens under the hood.
> 
> I'm not sure how far I am willing to carry that. If your only objective is to
> do it all from the GUI, I would balk. The complexity of building an editor
> just so you can fetch "contributed" filters or write the code to implement a
> new one is not worth the effort. However, I do think that, from the GUI, you
> should be able to configure a new menu option from the set of available
> filters and supply some small set of "parameters" to finish the filter
> definition.

That's actually what I was thinking, too.  Different terminology,
but the same idea.  Also, that you should be able to install
external importers after initial installation, so you could, 
e.g. synch with a palm pilot via an import option, or import
data from some other source without having to recompile GnuCash 
to do so.

> > And a way to synch with my PalmPilot, but that's another story... =)
> 
> Not to too great of an extent. Palm import/export front ends should be
> developed because they are a popular device.

If I didn't have the demo from hell at work next month, I'd
already be working on it... 

-- ebm
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
| Eric B. Mitchell         mailto:emitchell@altaira.com |
| tel: (301) 809 - 3534    Altair Aerospace Corporation |
| tel: (800) 7 - ALTAIR    4201 Northview Dr. Suite 410 |
| fax: (301) 805 - 8122    Bowie, MD  20716             |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
              ,___
          /"\  / o=\  /"""---===/
         /   \_/  \__/   ---===/ 
         |    //\   || /""TT""/ //\   || ||""\
         |   //  \  ||    ||   //  \  || ||__/
         |  //--==\ |L--/ ||  //--==\ || || "=,
          \      ---===/
           \____---===/