> On Jan 24, 2016, at 9:14 AM, Jesse Olmer <[email protected]> wrote: > > On Sun, Jan 24, 2016 at 7:19 AM, John Ralls <[email protected]> wrote: >> >>> On Jan 23, 2016, at 10:30 PM, Jesse Olmer <[email protected]> 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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
