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 christ...@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@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
