question about importing .qif files

[Richard Wackerbarth]

On Fri, 21 Jul 2000, Eric Mitchell wrote:
> > Rather than attempt to make a generalized
> > translation widget that does everything for everybody, I think we should
> > look to customized preprocessors that each handle one particular format
> > and translate it into a consistent format for importing. It is MUCH more
> > difficult to attempt to process many variations than it is to write many
> > specialized translators. From the user's perspective, once he knows which
> > preprocessor to use for a particular source, he can direct us to it
> > (hopefully through stored preferences) and we can "do the right thing".
>
> 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.

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.

> The usability question I keep asking myself is "Can I make this easy
> enough for my wife to use?"  Not install.  Not configure.  Not diagnose
> problems.  Just use.

Only if you do the configuration. Just as you note that the bank doesn't know 
how you wish to handle things, gnucash has the same problem. Only the user 
(installation level, not data entry clerk level) is in a position to know how 
they want various things handled.


> 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.

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"

Hide the details from your wife.
>
> > Such a scheme is certainly easier to maintain because you don't have to
> > comingle old, already working, code with new warts to handle the
> > inevitable new input source. As a user, it is highly unlikely that I will
> > be interested in all the formats used by some German bank and that used
> > by one in France and that of the local S&L here in Texas.
>
> The code in the importer is fine, AFAICT.  The GUI that drives it is
> incapable of handling anthing other than QIFs from Quicken.  Have a
> default, from-Quicken-and-has-all-fields importer.  Also, have one
> that's as-customizable-as-the-netscape-mail-filter for special cases.
>
> The user tries the generic one.  If it fails, they try the customizable
> filter.  Have online help/step-by-step assistance ready.
>
> > 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.

> 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.