Constituent Merge in v11

Hi Mo -

I had this exact same 'huh?' moment earlier this year. This is what was determined (from Tessitura):

------

Merge pairs will be skipped if the value of the Last Activity Date is after the date on which the merge pair was identified.  The date the pair was actually scheduled does not come into play in this process.

It makes sense that we would use the date on which the merge pair was identified, because so many organizations do not check each merge pair when merging customer records.  Often, organizations only check segments of their database - major donors, VIPs, subscribers, etc.  If you are not checking most of your records, you would want your merge pair to be skipped in the case where activity has taken place.  For example, the customer name could have been changed.

------

Now I thought maybe I was not remembering how it used to be correctly, and it had always been like that. But if other people noticed the same change, maybe I am not so crazy after all.

Anywho - there's the scoop. The official 'why' of the matter. 

HTH,

Heather

After years and countless merges being delayed by a day due to just such trivial, non-transactional updates, we realized that these "Merge aborted! Reason: Customer activity took place..." errors had never resulted in a merge being skipped that we actually wanted to skip. So, we commented out the block of code in AP_MERGE_CUSTOMER that does this particular check, with no regrets and less wasted time. YMMV...

Hi All,

Sorry to dredge up an old thread, but we have noticed this happening a lot more since we upgraded to V11 (nearly a year ago now) as well and it's suddenly coming to a head.  For several months after the upgrade we fell way behind on merging but decided we'd just have to live with it for a while.  In late spring/early summer, our box office staff was able to get completely caught up with merging.  Unfortunately, they are now beginning to fall behind again now that our season is about to start and things are getting busier.  I think that this "Merge Aborted" problem is likely a significant contributor to their inability to get through all of the merges each week.  In July and August, nearly 40% of all scheduled merges failed because at least one of the accounts was altered after the date it was identified as a duplicate.  (By the way, I only very recently realized that it was based off of the date that the duplicates were identified.  The wording of "since this was drafted for merging" or "since this was scheduled for merging", to me, makes it sound like it's based on the date the merge is actually scheduled by the user.)  It makes sense that so many would have been altered because part of our merge procedure has always involved some amount of account cleanup.  That is, we standardize address formats, correct misspellings, etc. on the account that we plan to keep.  In addition, it's our policy to always keep the oldest account when merging (due to internal preferences to not change patrons' account numbers), so that often means updating the primary contact info on the kept account so that the more recent info from the account to be deleted doesn't get merged in as inactive/non-primary.

There definitely seems to be some difference between V10 and V11 regarding this error, but I can't figure out what it would be.  The V10 AP_MERGE_CUSTOMER used the same criteria for producing this error (T_CUSTOMER.last_activity_date > T_POTENTIAL_DUPS.create_dt) as the V11 AP_MERGE_CUSTOMER.  I'm wondering whether T_CUSTOMER.last_activity_dt is being updated more frequently in V11 for some reason, as I believe Mo was implying above.  It is updated by TP_CUST_ACTIVITY_UPD, which I assume is called by the application when certain things happen.  Is there a chance that it's being called now every time you save anything in the customer record?  Could someone from TN speak to this?

I like your suggestion, Chris, about commenting out that code in AP_MERGE_CUSTOMER, but I'm not sure how our DBA (or TN for that matter) would feel about that since it's not a local procedure.  (She's on vacation this week or I'd ask her!)  As a long-term solution, I think it would be nice if there were a T_DEFAULTS setting for that with a clause built into AP_MERGE_CUSTOMER that would skip that portion of the error checking if it was turned off.

As for now, I'm a little stumped.  Has anyone else found a creative way of getting past this issue?  Has anyone not experienced this issue at all?  And if not, do you have any insights into why you haven't?

Any advice would be appreciated!

Thanks,
Bryan Evans
Manager of Data Analysis
Cincinnati Symphony and Pops Orchestra 

Hi Bryan

I suspect that you could effectively bypass that check, without editing Tess code (which I would certainly try to avoid)  by running a script, immediately before the merge job each time, to reset the create_dt fields for your merge pairs.

Ie something like 

update [dbo].t_potential_dups pd

set pd.create_dt = getdate()

where pd.status in ('K', 'D')

/Ken

Ken,

That is both brilliant and obvious!  (Why didn't I think of that?!)

You've made my day.

Thanks,
Bryan