Membership Contributions merged accounts

I'm not sure if this helps, but we deactivate rather than delete the memberships so the contributions stay connected to the merged membership.

John,

I believe the default is to allow two accounts with active memberships to merge.  Its likely something in your local procedure has been altered to prevent this from happening, which in my opinion is not a bad thing.   Merging accounts where both have memberships can be messy if you're not careful.  Generally I try to avoid it when possible.

Dale

Dale,

I suspect we had a reason for our setup at some point.  I can imagine a rude burp from a merge bringing down a manually manipulated honorary boost.   What else ought I to imagine?

John,

Its been so long since I've merged two accounts with active memberships, I can't remember the actual results.  I just remember not being happy, probably because I didn't know how the merge dealt with the different fields.  I recommend testing if possible.

Some things I would look for: if you have two memberships with two different exp dates, I'm guessing the exp date from the keep account is the one that is kept.  In some cases that would obviously be undesireable so some manual adjustment would be necessary before you schedule the merge.  Obviously, this applies to the other dates involved as well.  Not sure what happens to the Recog amt but would assume the numbers are combined.  As far as status/trends go, again, I would do some testing.  I can't remember if they are kept from the keep account or if they are somehow "recalculated".

Dale

Thanks Kevin!

I keep forgetting that there is now amazing documentation on just about everything!

Some days I'm still in 2003 when the only way to figure things out was to test them.

Dale

Kevin posted exactly the paragraph that sent me to this forum to seek advice.

Following up:

We tried commenting out the code blocking merge for active memberships in our test system.  We found that TX_CUST_MEMB is updated by the native function but not TX _CONT_MEMB.  So new membership is created in the merged account, likely with overlapping dates, instead of desired behavior to roll into the existing membership, or otherwise following membership rules set up in campaigns.  .  

We had  on hand a rarely-used custom utility for assigning contributions to memberships.  When we process the merge by deleting a membership, merging, then assigning a contribution to the merged membership, we get our desired result.  Maybe we even did this previously didn't document the exact process or lost the complete documentation.

In any case, our process now works for our needs, though it seems overcomplicated to achieve a fairly simple membership merge.  I would prefer to see the native merge function handle the contribution data at the same time as the membership data.

Hi John

If you already have the code to follow your logic, that would be probably fairly easy to convert into a step within LP_CONST_MERGE, which is called before and after the Tess merge code, to let you add your own processing steps to the merge process.

We do quite a bit of specialised processing in there now, including some code written for us by Tess poppets that does something like what you want, I suspect, ie "If merged memberships have contributions attached move the contributions to the kept membership and recalc."

Happy to post that code snippet if you'd like to see it... actually, i've just remembered that it's already posted on my files page - an old version, but it has the membership stuff in it.

Ken