In going through the Merge Duplicate process, there are some constituents that were auto identified as potential duplicates but we have determined to not be duplicates. Does anyone know a way of individually removing these constituents from the potential dups window at the top of the merge screen? I'm currently left with a bunch of constituents that were identified as potential dups but are not and have to sift through them all every time I go to schedule merges.
I look for the root cause of the identifications first, then use Void Merge. Typically the potential dupe process looks at fname, lname, street1 and zip of primary address (and sometimes primary eaddress), but not necessarily all the characters in those fields. Sometimes I find something the logical process identifies as a dupe that can be removed or altered slightly, thus remove them from identification at the source. For example, someone at some point misidentified one patron as the other and put in some data that doesn't go with that similar-seeming patron. Beyond that, we use void merge, even though it could prevent authentic dupe merges, which obstruct the merge process rather than remove from contention. Duplicates are a really big problem, but we don't throw many false ids (that we've caught) in our system. That said, we run the merges past members at all the consortium orgs for review first, which from time to time has caught deliberate dupes for some organizational purpose.
The problem with Void Merge is that it shuts off any merging with that constituent record, even if it is a different, and correct, merge target. I had created a separate attribute where you would enter the customer number of the customer not to be merged into, then added handling in the LP_CUSTOMER_MERGE (or wherever) to block merges with either the keep or delete had that attribute for the other. This required, of course, that this attribute be added to merge postprocessing so that the id would be updated if the selected customer was merged into a different account. I only recently realized that an Association was the perfect way to map and maintain (or rather let Tessitura maintain) this relationship.
The other problem was that the Attributes are only invoked after the customer accounts have been scheduled for a merge, generating an error, and guaranteeing that the same false identification will occur next time. I built a utility to run after a Potential Dup Identification run that would clear out any accounts I didn't want in there, but have recently completed (though not yet deployed) a new system for updating T_POTENTIAL_DUPS with either suggested duplicates or scheduled merges (where I have maximal confidence).
This has been delayed a bit, as I need to do two things: 1) really sort out how I'm going to handle Guest Checkout accounts and 2) build a proper report/utility frame around it.