Reconciling after QIF import; Quicken conversion

Derek Atkins warlord@MIT.EDU
18 Oct 2001 18:37:20 -0400


linas@linas.org (Linas Vepstas) writes:

> Well, I was suggesting that essentially the same problems will occur
> with OFX support, so a non-qif-specific solution would be best.

Sorry, I was not trying to imply QIF-ness; obviously any import method
would do well to have such features, or the ability to "learn" about
various bogosities.  For example, the list of NetBank bogosities:

 . The (actio)N field is completely "non-standard."  I have a list of
   terms they use, which include:  ATM/POS Withdrawal, Check, Deposit,
   Interest Credit, Transfer Deposit, Debit Transfer, Withdrawal ACH
   (among others).

 . Check numbers are stored in the M(emo) field (and the rest of a
   "real check" transaction is fairly broken, too, namely it has no
   real payee information).

 . A few of their actions don't have enough identifying information in
   order to balance the transaction to another account (in particular
   the two Transfer actions, interest credit, and overdraft
   transfers).

 . Many times the P(ayee) and M(emo) fields are left blank (they
   exist, but there is no data).

I suppose I could get Gnucash to deal with all these bogosities, but
really this is a bank-specific issue.  It would be nice if I could
_teach_ Gnucash about the Netbank bogosities -- perhaps a plug-in that
described how to specifically parse "Netbank QIF"?  This way different
banks that produce bogus QIF is mutually-incompatible ways can still
be dealt with.  Also, while some banks have other issues, or some may
have none.  It would be a detriment to harm those banks that do not
have issues in order to support those banks that do.

> (similar thoughts apply to any import source ... e.g. now that gtt
> is a kind of 'mini-consultants-billing-system', it could export 
> data billing data, but maybe not quite in the format you'd want ...)

A plug-in system would solve this, too.  You just need to describe the
"gtt QIF" format in some way.

> Hmmm.
> I guess it would have to be changed to a two-stage process: first, read
> the data in, blindly, & stuff it into a stand-alone gnucash account
> tree.  Then, in the second pass, one would scan/filter/match accounts
> and transactions in that stand-alone tree, and merge them into the 
> main tree. 

Isn't it already a two-stage process?  Actually, I thought it was
currently a three-stage process:

 1) load all your qif files
 2) match qif accounts/categories to gnucash accounts
 3) match transactions against existing transactions (for duplication
    protection)

Unfortunately in my case step #2 is also part of the problem (due to
missing or broken information in the QIF files).  If we do add in the
scheduled transaction matching, it would be nice if there were some
way to deduce the accounts that way.

Here is a real example: I have three Vanguard accounts and an
automatic monthly transfer of $100 from one account to each of the
other two.  When I download the QIFs for these three accounts,
_all_ transfers are marked as "LUnknown".  In other words:

Acct 1:
  $100 -> Unknown
  $100 -> Unknown

Acct 2:
  Unknown -> $100

Acct 3:
  Unknown -> $100

If I had two scheduled transactions that moved $100 from Acct 1 to
Acct 2 and $100 to Acct 3, the matching should be able to deduce ALL
of these automated transfers.

Obviously it wont help when I manually perform additional transfers,
but it's certainly a start, at least until we get OFX support and I
can download OFX from Vanguard instead of QIF :)

> --linas

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available