question about importing .qif files

[Eric Mitchell]

As I just sent to Bill in an email about the QIF importer failing
to usefully import data from screwy online account statements:

Richard Wackerbarth wrote:
> 
> On Fri, 21 Jul 2000, James A. Treacy wrote:
> > At a minimum, could the importer be modified so that you can select which
> > field is used to select accounts when importing, e.g. the Memo field
> > instead of the category (L in .qif)? When importing data from my bank, all
> > the transactions appear to come from a single, blank category. This means
> > all transactions need to be dumped into a single account and then manually
> > moved around. Using the Memo field would allow most of the entries to be
> > automatically placed in the proper place.
> 
> Could? yes. Should? I'll argue no. The problem is really that the bank does
> not create an appropriate QIF file. 

Should? I'll go with yes.  The problem is that the bank does not have
sufficient data to specify a category on my transactions.  However,
for the most part there's a 1-to-1 mapping from payee to category.
For example, everything I pay to Petsmart gets filed under "Pets."
7-ELEVEN is a special case where it could be going to the "Gas" or 
the "Junk Food" categories.  If there were a way to configure filing 
transactions similar to the Netscape Mail filter, I think that would 
be quite usable.  The filter works on "any/all conditions" "more/fewer":
"select list of fields" "matches/doesn't" "pattern", "action".  This 
logic is a million times easier to understand than, say, procmail.  Not 
nearly as powerful, but for filing mailing list messages in different 
folders, a pattern similar to this one, it's sufficient.

> 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?  If it can't be driven from the GnuCash
GUI, it will never be used by a large quantity of average (i.e. hoping
to be former Quicken) users.  Or me, for that matter, and I like computers.

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.

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.

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

What I need in a QIF importer is a way to configure otherwise unassigned 
transactions to end up in the right place, given the info that I *do* 
have available to me, by telling it where to find the file, and which 
filter to use, and nothing more.  

And a way to synch with my PalmPilot, but that's another story... =)

-- 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--/ ||  //--==\ || || "=,
          \      ---===/
           \____---===/