We are not able to merge some duplicate constituent records. The error message says that there was activity on the record after the merge was scheduled. When we look at the constituent record on the General Tab, we can see in the "Last Activity Date" field that something happens nightly at 10:45 pm. We've searched the constituent record to find some change/update that corresponds with the Last Activity Date and can find nothing.
- Is there a place on the constituent record to find a record of all changes?
- Without accessing SQL, is there a place to check the AP_update and TP_check_ schedules that are running?
We do not have a SQL resource on staff. Thanks for any help or suggestions.
Susan Carey
Wadsworth Atheneum Museum of Art
susan.carey@wadsworthatheneum.org
Hi Susan,
Chris is on the right track with looking at the Audit history on the Constituent record. The audit history is on the Transactions tab of the Constituent record on the Audit radio button. It's possible that you have a nightly SQL job, or your Membership Update Utility is set up as a scheduled report. If you aren't able to track this down, please open a User Support ticket in TASK so the Support team can assist you further.
Karen
We have the same issue and were able to find the procedure that was running nightly (for us it was related to primary emails and creating a temporary log-in), then we were able to change our procedure so that we update the account(s) so that the nightly procedure doesn't get triggered, however, we still end up getting the error if we schedule the merge the same day as we make updates to the account so we have to update accounts one day and schedule the merge the next.
We had asked our IT department to look into the merge set-up and restrictions to see if there was something they could turn off or change so that accounts that had activity could still be merged. It was something we didn't have a problem with until a version or 2 ago. Before that we never got the "activity has taken place" error.
I don't believe our IT folks have ever gotten to looking into the merge set-up to see if this is possible. Has anyone looked into this and been able to update the system so that it doesn't fail the merge if there is activity on the account?
Laurel
Cal Performances, UC Berkeley
Hi Laurel,
We too would like to turn ff that annoying activity error. Unless the activity is something that would interfere with the merge, I don't care that there was activity on the accounts.
If someone from the network sees this, can you explain why this error exists and if there is any reason why we shouldn't have it turned off?
Thanks
Susan
The merge procedure checks to see if activity has taken place on Constituent records to help avoid merging accounts incorrectly. For example you might not want an account to be merged if an address was recently updated, an account has been marked inactive or membership status has changed.
Having said that, there is a defect reported and listed on the Tessitura Reported Defect List as reference number 68047 with the description "In the cursor to update last_activity_dt in AP_MEMBERSHIP_UPDATE, there is no filter on @run_no, so more records get updated than are expected". This has caused problems when merging constituents because constituents whose memberships did not change were having their last activity date triggered. This issue will be resolved in v14 with the resolution of "In Reports and Utilities, when running the Membership Update Utility, Last Activity Date was being updated for constituents whose memberships were updated in previous runs of the utility. Now, only constituents whose memberships are updated in the current run of the utility will have their Last Activity Date updated."
There is a workaround if the Membership Update Utility is causing your merges to fail due to the last activity date. In AP_MEMBERSHIP_UPDATE you can add the following clause to the select query for the cursor that does the last_activity_dt update to:
and b.run_no = @run_no
If you are encountering other issues with your merges failing unexpectedly, you can open a User Support ticket for assistance. If you find there are specific business cases that would be ideal for the merge procedure to exclude looking at activity on a Constituent record, we would love to get get your feedback and have an Enhancement Request ticket opened in TASK with the details. This would allow Tessitura to then review the business case to determine if additional parameters could be added to the procedure.
Thank you Karen,
I will let our Dev folks know about the membership bug.
However, with the exception of the account being marked inactive, I would still want to merge accounts in the examples you gave. I may, in fact, change the address of one of the merge accounts if it has an old address and I want to make sure both addresses match. If the membership status has changed, I would definitely want a single account to avoid confusion.
We are part of a consortium, and we are trying to mitigate our duplicates issues. The only changes that I can see being an issue for activity changes are changing the constituent type, status, or A1/A2 status in households. Other than that - I would want accounts that I have requested to merge - to become one.
I will ask our hub organization to request an enhancement.
Thanks again,
Hi Karen,
Gawain Lavers from Cal Performances here (Laurel's org). I'm not certain the Membership Update Utility would be to blame for us, since it only runs once a month, and these errors can crop up on any day (our merge process runs nightly).
Examining one of these failed merges and checking against the Audit Trail for each user, I see activity on the account to be kept a few minutes before the merge is scheduled, and no activity on the account to be deleted for over a month prior. Neither should trigger the error, right? Does the merge procedure look at something that isn't recorded in the Audit Trail before making this decision?