importing transactions without setting CREC

[Christian Stimming]

I don't understand why it is a problem for you to have the transactions set to 
CREC / "cleared". There is also the state YREC / "reconciled", which is yet 
another state that can be used to distinguish the transactions that are 
"really reconciled" vs. those that are still waiting for reconciled. (Just for 
completeness: Transactions can be switched from "c" and "n" to "y" by marking 
them reconciled in the "Reconcile" dialog window and pressing "Finish 
Reconciling" there.)

Can you elaborate why having those transactions in "c" instead of "n" is a 
problem for you, while keeping in mind that there is still the state "y" 
available? Also, having transactions entered by parsing the credit card 
receipts in my opinion also makes them somewhat more reliable than having 
entered them purely by hand, which makes me think the "c" state is also quite 
suitable.

Regards,

Christian


Am Donnerstag, 18. Juli 2013, 10:02:04 schrieb G. Paul Ziemba:
> 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?