importing transactions without setting CREC

[G. Paul Ziemba]

I think that's a good question and I'll do my best to answer:

I like to keep track of whether a transaction has actually
cleared the credit card provider. On occasion (about 4 times
in the past 5 years) for me, I have had receipts for transactions
which did not result in a posting to the CC provider. So it's
useful at least in that regard.

I also download CC transactions from the CC provider via OFX (n -> c)
and then reconcile against the paper statement (c -> y). So I make use
of both 'c' and 'y' states already.

(I'm not ready to get rid of the paper statement yet because I
still get occasional dropped transactions in online OFX import;
haven't had time to troubleshoot).

Could I live with having my transactions marked "cleared" before
getting them from the bank? Yes, if necessary. But I would rather
have the representation in gnucash correct (maybe that's picky,
but isn't that the nature of accounting?)

For the time being, I have switched to QIF for importing the
transactions scanned from receipts, which does the right thing
although it takes quite a few mouse clicks to get through.

cheers,

 ~!paul

christian at cstimming.de (Christian Stimming) writes:

>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?
>_______________________________________________
>gnucash-devel mailing list
>gnucash-devel at gnucash.org
>https://lists.gnucash.org/mailman/listinfo/gnucash-devel
-- 
G. Paul Ziemba
FreeBSD unix:
12:16PM  up 103 days, 23:34, 1 user, load averages: 0.85, 0.83, 0.82