On 7/31/2013 9:29 AM, David Reiser wrote:
> On Jul 29, 2013, at 2:53 PM, G. Paul Ziemba
> wrote:
> [snip]
>> (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).
> [snip]
>
> The tra
On Jul 29, 2013, at 2:53 PM, G. Paul Ziemba wrote:
[snip]
> (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).
[snip]
The transaction matcher has a few holes in it. The one that I ru
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 provid
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.
Hi,
"G. Paul Ziemba" writes:
> 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
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 cleare
