Reconciling after QIF import; Quicken conversion

Derek Atkins warlord@MIT.EDU
18 Oct 2001 17:18:30 -0400


linas@linas.org (Linas Vepstas) writes:

> I'm wondering whether we should think about creating a generic 
> 'translation service', that could recognize transactions of a certain
> sort, (such as those delivered by the bank), and 'convert' them
> to the form that you want them?

I basically started writing a Perl script to massage all of my Banks'
QIF files into something "Reasonable."  Some of my banks work fine
without any massaging (e.g. Chase Credit Card).  Some banks require
a LOT of massaging (e.g. Vanguard).  Some banks require a little
massaging (e.g. NetBank).

Perhaps we might want to be able to modularize the QIF import so that
we can add specific rules?  For example, it's fairly easy to
categorize the ways NetBank screws up (Vanguard is much more
challenging to categorize due to the information loss with multiple
Vanguard accounts -- in particular the lack of "destination"
information of cross-account transfers).

> I would imagine that the 'scheduled payment' infrastructure would
> be handy for this, in that a scheduled transaction is a kind of a
> template that is filled out with the 'real data'.  

Something like this would certainly help, if the QIF importer actually
looked at that earlier in the import process.  Currently the importer
tries to do account matching well before it tries to perform
transaction matching.

> So, for instance, during QIF import, we'd look at a transaction, 
> and notice that it matchs up to a template in a table of 'scheduled 
> transactions'.  We'd then fill-in the blanks (date, amount) in the 
> template from the QIF data .... 

-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