Reconciling after QIF import; Quicken conversion

[Linas Vepstas]

On Thu, Oct 18, 2001 at 05:18:30PM -0400, Derek Atkins was heard to remark:
> 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).

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

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

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

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. 

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

--linas

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas@linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933