On Thu, Oct 18, 2001 at 05:18:30PM -0400, Derek Atkins was heard to remark: > [EMAIL PROTECTED] (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!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
