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

John Ralls jralls at ceridwen.us
Sun Jan 24 14:38:31 EST 2016


> On Jan 24, 2016, at 9:14 AM, Jesse Olmer <jesse at wickedgoodtimes.com> wrote:
> 
> 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.

OK. For that purpose the GUID GHashTable will work fine.

I'll wait to see the code before I comment on the UI, but I'm worried about it being confusing.

Regards,
John Ralls




More information about the gnucash-devel mailing list