Kevin -- I've let this one sit for a while. However, I still observe behaviour that is different from what I think should happen and from what you describe. I'm going to try to post a screen snap of what I'm seeing to the images section of the main page. I'll try to name is something like "mergeTrans.jpg". Of the 9 merges it suggests, I think only the last one is correct. The other eight all appear to want to merge with the same transaction.
Byron On Jan 24, 9:56 am, Kevin Hoctor <[email protected]> wrote: > If the amount is not equal, the transactions should not be marked as > matching. That is the number one test and if it fails no other tests > are run. > > The exception to this is the testing for the unique ID number but > those get removed without being presented to you. > > Peace, > > Kevin Hoctor > No Thirst Software LLChttp://nothirst.com > > Sent from my iPhone > > On Jan 24, 2009, at 7:56 AM, bwbecker <[email protected]> wrote: > > > > > On Jan 10, 9:58 pm, Kevin Hoctor <[email protected]> wrote: > > >> MoneyWell matches ontransactiontype and amount because payee names > >> vary so wildly. There is an option on the Duplicates View to match a > >> certain range of days between transactions and that usually covers > >> most needs. In the case of too many transactions with the same > >> amounts, there is nologicto handle those right now. I'm working on > >> enhancements to allow you to manuallymergetransactions in a future > >> release. > > > Maybe I'm not understanding what you two are discussing, but this > > doesn't match my experience. > > > I just imported 7 transactions that somehow got missed earlier. > > MoneyWell > > matched each one to the sametransactionin the "Mergeand Remove > > Duplicates" > > screen. NONE of the dates match (the one it wanted to match to is > > 12/23/09; the > > dates on the transactions are between 1/5/09 ad 1/9/09). Furthermore, > > the > > amounts differed wildly and none matched. Thetransactionit wanted > > to match > > to is $40.95. The closest importedtransactionis $43.54. The others > > vary > > from $10.00 to $307. > > > It seems to me that a matching algorithm like this must be based on > > probabilities > > and evidence. Exact match on the amount increases the probability > > substantially. > > The farther apart the amounts, the lower the probability. Same for > > the dates, > > memo field, etc. A cut-off could then be implemented: transactions > > like the above > > would certainly have a probability below the cut-off and would not be > > matched. > > > Byron --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "No Thirst Software User Forum" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/no-thirst-software?hl=en -~----------~----~----~----~------~----~------~--~---
