Red line on OFX input

[David Reiser]

> On May 29, 2016, at 3:55 AM, A.J. Bonnema <gbonnema at xs4all.nl> wrote:
> 
> On 05/28/2016 06:12 PM, Alton Brantley wrote:
>> Just a heads up on this. CHECK THE DATE OF THE MATCH! If you have recurring transactions, then it’s possible that this is matching to a previously cleared transaction and will not be added to the import. These can sometimes be hard to track down!
> Thanks for the advice. However, these transactions are not on recurring base at all. The example I gave was just getting groceries. Nothing recurring about the amount. And I am also sure date+amount do not occur.  So to me this is a mystery: why does gnucash insist on redlining certain transactions without traceable cause?Is it possible to find out what the criteria are?
> 
> My post also clearly states that I have by definition a lot of duplicates. For instance, yesterday (28th of May) I imported all transactions from 1st of January until 27th of May. I did the same on the 14th of May : these included all transactions from 1st of January to 13th of May. So by definition, all transactions from 1st of January to 13th of May are duplicates.
> 
> These duplicates *are not* the red lined transactions.
> 
> Only among the new transactions -- in this case from the 14th of May -- do red lines occur. Duplicates is not the issue: it's not a duplicate! But what is the issue? What makes gnucash decide it should not process a transaction?
> 
> If not duplication, what else could it be?
> 
> The flip side is ofcourse, could gnucash give an indication of what is wrong, additional to the red line?
> 
> Kind regards, Guus Bonnema.
> 

The “Info” column shows the degree of match to a transaction already in your data file. The bars go from red to green. If you don’t get at least one green bar, then the default action is not to import the transaction — no check in A, U+R, or R columns. If none of the action columns are checked, the transaction line is colored red.

In my experience, gnucash is overly critical of date matching. If the amount and date match exactly, you’ll get four green bars and a check in the U+R column (whose action is an accounting abomination, IMO). If the date in your file is as little as 3 days (maybe 2) off from the posting date listed in the incoming transaction list, you’ll be down to only yellow bars in the match, and the transaction gets proposed as a “do not import” transaction (red background for the whole line).

If you know that the incoming transaction can’t possibly have been entered manually, then the red+yellow match bars mean that the matcher has found another transaction that might be a match. I run into this problem when I import batches that have vending machine purchases in them. I don’t ever enter those manually anymore because the matcher says it has a potential match and then throws the import-pending transaction away anyway. And even though I only ever import those reactions via the “A” option, all the subsequent imports show a couple yellow bars and the red background of the potential match.

So, I always check “A” for my vending transactions, and “R” for any of the other matches showing red+yellow bars plus the red background. I’ve found I still have to pay attention to the results because occasionally there are oddities that crop up.
--
Dave Reiser
dbreiser at icloud.com