Bug 739571 - Matching imported transactions doesn't indicate previously matched entries

[Jesse Olmer]

On Sun, Jan 24, 2016 at 7:19 AM, John Ralls <jralls at ceridwen.us> wrote:
>
>> On Jan 23, 2016, at 10:30 PM, Jesse Olmer <jesse at wickedgoodtimes.com> wrote:
>> ImportA has an automatic best match to Trans1. I write into the table
>> Trans1's guid as the key, and 1 as the value
>> ImportB has an automatic best match to Trans1. I update the table
>> Trans1's guid as the key, 2 as the value
>> The User changes ImportA to match Trans2. I update the table twice:
>> {Trans1, 1}, {Trans2, 1}
>>
>
> Hmm. ISTM that's going a bit beyond what the bug asks for, but maybe I'm not thinking through the situation fully. How are you going to present this information to the user? Are you going to change the matcher logic to take it into account, so that if there are (say) 3 similar existing transactions and 3 imported transactions that match them with equal scores the matcher will assign one of the imported transactions to each of the existing transactions?

I wasn't planning on changing the match heuristic at all. This is
simply the best way I could think of to solve according to "Possible
Solution 2" in the bug description. Copied here for convenience:

> 2) Indicate (either by foreground or background color, or by including a new
> column with a "cleared" indicator) in the SMET window that a transaction
> has already been cleared by matching during a previous import process.
> (Potentially this could be expanded to indicate that the transaction has
> already been chosen for matching during the current import process as well.)

My change indicates previously cleared transactions by adding a
"Reconciled" column to the match picker and populating it with
gnc_get_reconcile_str. For the portion of the solution in parenthesis
(indicate that it's chosen during the current import) the solution
we've been discussing was my attempt at that.

The use case here, as I understand it (and have personally
encountered) is that the import tool provides no help when trying to
match 2 identical transactions. Both imports will auto match to the
same transaction, and you'll be left with 1 of the 2 transactions as
not cleared. Adding a column to match picker which indicates pending
state helps the user to ensure that the two identical imported
transactions are distributed evenly to the two identical transactions
on the account, and everything ends up fully reconciled.