Hi all,
We've always had a good number of failed merges each week due to the good ole "activity happened on the kept account" error. Sometimes I can see that something physically happened and so the error is legitimate (not that I always agree with it failing the merge because of that... but that's a different story). I also noticed a while ago that the LP_CUSTOMER_RANK was causing a lot of unwanted activity. Since we don't currently use ranking I disabled it which kind of helped.
But I find myself looking into this issue again as we've still been having a crazy number of merges failing each week and most of them are consistently the same people. This is what I've found and I'm looking for some advice on what other people have done.
The majority of the failures seem to be happening because of our nightly Manage Constituency updates. It's funny because most of these people have had the constituency for several months and the last_update_dt in TX_CONST_CUST is from several months ago. But their last_update_dt in T_CUSTOMER is for the exact time of the last constituency update run. How have other people gotten around this? Should I stop using the Manage Constituencies report and write up LPs to apply constituencies that don't modify the account unnecessarily?
This also leads me to wonder how I'll handle the ranking procedure and merges when we start using ranking in the future...
Thanks for any advice!
Unknown said: We've always had a good number of failed merges each week due to the good ole "activity happened on the kept account" error. Sometimes I can see that something physically happened and so the error is legitimate (not that I always agree with it failing the merge because of that... but that's a different story). [...] Thanks for any advice!
We've always had a good number of failed merges each week due to the good ole "activity happened on the kept account" error. Sometimes I can see that something physically happened and so the error is legitimate (not that I always agree with it failing the merge because of that... but that's a different story). [...]
If you're comfortable with modifying the SQL, it is possible to comment out the lines in AP_MERGE_CUSTOMER that perform this check. Yes, in general it's not a good idea to modify standard Tess sprocs, but several years ago this particular check had become annoying enough that we took the chance. Thousands of merges later, no regrets, just lots of time saved.
Thanks, Chris. I certainly have considered that very option... It's good to know that it worked well for you!