I'd like to automate some of my transaction entry by parsing OCRed scans of my credit card receipts for account numbers, dates, totals, etc. and producing transaction data that I can import to gnucash.
First I generated OFX format data. It worked OK, but all the transactions are flagged as cleared when they should be just 'n'. This behavior seems to be hard-coded into the ofx import logic. It makes sense if you assume OFX always represents a bank statement. I looked at QIF, which appears to support a transaction field indicating the reconciled status, but it seems as if I will need to walk through a series of popups to match the categories each time I import (despite the QIF account strings being crafted to match the gnucash account paths). Maybe I am mistaken here: is gnucash supposed to remember the associations for future QIF imports? It seems the most streamlined approach would be to enhance the OFX parser and importer to recognize a new tag inside <STMTTRN>, such as perhaps <RECONCILE>, that would specify the reconcile status for the transaction. It would default to 'c' to retain the existing behavior for standard OFX files, of course. I'm willing to produce a patch to do this. It could also be done with a global preference switch, but that seems more prone to error (forgetting to change it when needed). Have I overlooked anything? Is there a better way to solve the problem? -- G. Paul Ziemba FreeBSD unix: 3:26AM up 92 days, 14:44, 1 user, load averages: 2.04, 1.94, 1.49 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
