importing transactions without setting CREC

[David Carlson]

On 7/31/2013 9:29 AM, David Reiser wrote:
> On Jul 29, 2013, at 2:53 PM, G. Paul Ziemba <pz-gnucash-devel at ziemba.us> 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 run into most frequently is that multiple transactions for the same (or nearly the same) amount within some number of days are handled poorly. I haven't been able to trace the code yet, but I think what is happening is something like: say you have transactions T1 and T2 in your register both for $100 (in my case, my wife and I both get money from an ATM within a couple days), then you download transactions from the bank. The bank's ofx file has transactions T1c and T2c which ought to match the two that you have. I think the matcher takes T1c and says "looks like that matches T1" then it gets to T2c and says "looks like that matches T1". Then after you click OK in the matcher dialog it starts finalizing the transactions and says "T1c matches T1, but look T1 is already matched to something, so T2c can't match T1" and it just throws away T2c.
>
> Most times, if I just reimport the same file after gnucash has skipped a transaction, the T2c-like transactions are properly matched. This past weekend, I had a pair where that didn't work. I haven't figured that case out.
>
> The nastiest version of this problem is that now that the vending machines at work take credit cards, I may have 3 or 4 identical amount transactions in the same week. To make matters worse, sometimes the vendor gets the charge posted immediately, sometimes it takes a few days. And I'm not tremendously vigilant at getting all those transactions entered in gnucash promptly. So I have a case with multiple same-amount transactions in an import, only some of which are already in gnucash. That's such a mess that I don't enter any vending transactions in gnucash anymore, I just import them later and let gnucash 'add' them all. I then have to look at them and think about whether the total is logical (did the vendor overcharge me...).
>
> And I'd like to strangle the person who changed the matcher behavior for those of us who don't choose to let an import change a transaction date (turning off preference for Update and Reconcile). It also looks to me that the Enable Autoskip preference takes away the ability to manually skip a transaction whether or not autoskip is enabled.
> --
> Dave Reiser
> dbreiser at icloud.com
>
>
>
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
A long time ago I used to have issues with OFX imports when transactions
were mis-matched. 
A re-import would fail because a transaction was not even on the match
list anymore because a transaction with a matching unique identifier had
already been matched previously.  Then I would need to edit the OFX file
to change the unique identifier for the transaction that failed to
re-appear in order to get it to import. 
I think that the only reason I have not seen it recently is because I
now religiously check every "match" to be sure it is correct, or if I am
not sure, I change the status to new so that I can check later.

If you are looking at ways to improve this, I would suggest adding a
status 'Already imported' for those transactions, with an option to
'Import Again'.
The 'Already Imported' transactions could be in a separate list that is
not cluttering up main list.

David C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xDC7C8BF3.asc
Type: application/pgp-keys
Size: 1729 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20130731/13e29d1a/attachment.bin>