Renewing fixed 12 (full) month membership adds extra month

[Marty]

According to the documentation:
If you want to ensure that memberships last 12 full months by rounding up a partial month (for people who join in the middle of the month), you should select 13 month duration and fixed period.  A user who joins on November 15, 2009 will have a start date of November 1, 2009 and an end date of November 30 2010.

The above is true for a new membership. Renewing this membership while it is still current, however, extends the end date to December 31, 2011 (13 months), which effectively adds an extra month of membership.

The "13 month fixed" duration choice seems to be a special case intended to provide a year-long membership that starts on the 1st of the month and ends on the last day of the same month of the following year. Membership renewal should recognize this case and simply extend the end date by 12 months. That is, you should get the partial month when you join, but not when you renew (because the end date has already been adjusted to provide the full month).

If others agree, I would like to submit the following patch to the function CRM_Member_BAO_MembershipType::getRenewalDatesForMembershipType( ) to recognize this special case.

Code: [Select]

            if ( $membershipTypeDetails['period_type']   == 'fixed' &&
                 $membershipTypeDetails['duration_unit'] == 'month' &&
                 $membershipTypeDetails['duration_interval'] % 12 == 1 ) {
                // Special case for annual/bi-annual/etc fixed-month memberships. The duration includes an extra month
                // used to round up a partial month on the inital join. Renewals should not include the extra month, so
                // it is removed here. This allows the end date to be extended by an even 12/24/36/etc months without
                // adding an extra month of membership.
                $membershipTypeDetails['duration_interval'] = $membershipTypeDetails['duration_interval'] - 1;
            }


[Dave Greenberg]

This fix for renewals makes sense to me although I don't know how common the use case is, nor how many folks are actually following the docs and setting a 13 month duration??

It does seems a bit non-intuitive to expect folks to set a 13 month duration when they are configuring 12 month memberships. I guess the intent was to support both the 11.x months behavior and the "12 full months" behavior. If we think 12 full months is the most commonly desired behavior, maybe the signup code should be modified rather than the renewal code (so it gives 12 full months on signup).

[petednz]

Keen to hear where this got to. A client is wanting the 'sign up during the month and have 12 months + xx days' ie the membership will needing renewing at the end of the 12th full month.

Documentation here http://wiki.civicrm.org/confluence/display/CRMDOC41/Membership+Types doesn't seem to have changed - and my testing on a 4.1.2 suggests that the status quo is still that you have to set it to 13 months but the outcome of renewal is then also 13 months.

Is that the case?

[Marty]

Hi Pete,

I never received any support for making this change so I never submitted a patch and the 13-month renewal behavior still exists.  Our organization allows initial membership signup anytime during the month, makes the membership retroactive to the first, and expires on the last day of the month one year later.  This makes it a 13 month membership for the first year.  When they renew, however, we only want to extend the membership end date 12 months and not 13.  Right now I'm just patching the code locally with each new CiviCRM release.

If you think this is a reasonable change to include in the base, then I can certainly submit a patch.  The only downside would be if someone is currently relying on the 13 month renewal behavior (an unusual use case), in which case this patch would break that for them.

Marty

[petednz]

Hi Marty - well you have my support - I can't think of an outcome that should have 13 months on renewal when it is meant to be a year.

If someone signs up on the 7th March - and we want them to be a member through till end of March (edit i incorrectly put April here) then the only logical behaviour is what you are doing, giving the person a membership for the whole of the month they are signing up in, plus 12 months, and 12 months thereafter.

If we can't get this in to core without further scenarios being included, then I might just ask for the code so we can apply it in the same way that you are.

[Marty]

I create a new issue CRM-10585 and submitted a patch there.

[petednz]

Thanks - I will take a look.

[Dave Greenberg]

I'll be looking at incorporating the fix into core for 4.3, but I want to clarify expected behaviors. It seems like Marty's desired scenario is a bit different from Pete's ??

Marty: Member signs up on March 7, 2012. Membership start date is set to March 1, 2012. Membership end date is set to March 31, 2013. (But this may not be what you mean by "last day of the month" ?? )

Pete: Member signs up on March 7, 2012. Membership start date is set to March 1, 2012. Membership end date is set to April 30, 2013. (Maybe this is a typo, but Pete's post says "member through end of April...")

If I'm misunderstanding and the desired behavior is the same for both of you, maybe we should make that the default behavior for 12 month fixed memberships work that way. The 13 month "trick" seems like a hack so might be better to just adjust behavior for the initial signup.

[petednz]

Hi Dave - thanks for engaging - yup think i got months confused.

Objective is that signing up part way through a month means they get the remaining days of that month 'free'

So if I sign up on Mar 7 I am purchasing Membership from then through to end of March next year

First Year

Join Date = March 7
Start Date = March 1 (since this is monthly and I expect this is the 'only' option)
End Date = March 30 next year

Second Year

Renewal kicks in = April 1
End Date = March 30

Is this the same behaviour as with Yearly Fixed Period but that we are basically setting the Fixed Period Rollover Day as the last day of the month?

[Dave Greenberg]

Tim Otten and I discussed this - and we think the better approach would be to "ditch" the 13 month hack and make this configurable by exposing the "Fixed Period Rollover Day" (day only - e.g. "fixed_period_rollover_day[d]") for membership types with Fixed period and N month's duration.

(Currently we expose a month and a date dropdown for Fixed Period Rollover Date for membership types with N year's duration - but we hide these dropdowns if duration unit is months.)

This way, each site could configure the day of the month when they want to trigger "this month is free" behavior. So if Pete's client wants the month to be free if signup is 7th of month or later, they'd select "7".

If we go this way, we could leave the 13 month "hack" code in place OR (better IMO) set a value of "1" for that field during upgrade for any membership type that has 13 month duration (and change duration to 12 months).

Thoughts?

[petednz]

Sounds to me like we are on the same track here - use same approach as with the Yearly rollover but make it based on Day of Month, not Month of Year.

[Dave Greenberg]

Marty - if you agree as well, can you update your patch to use this approach?

[torrance123]

Hi Marty,

We're keen to use your patch in the meantime (before the sort of changes suggested by Dave are implemented).

However, I'm running into some problems with you patch, namely that it seems to be shortening the time period for brand new membership creation to 12 months (eg. if I create the membership on the 7th August, the membership runs from 1 August to 31 July, as opposed to what we'd expect, 1 August - 31 August).

Additionally, if I renew a membership it doesn't appear to me that the section of the function you've patched is being called at all. It looks the patch should be patching getRenewalDatesForMembershipType() instead (though I have no idea where in the that function to place the code!).

[Dave Greenberg]

The new approach has been implemented for 4.3. Admins can now set a Fixed Period Rollover Day for fixed membership types with duration expressed in months.

http://issues.civicrm.org/jira/browse/CRM-10585

For example, 12 month membership duration AND  I want signups on or after the 20th of the month to get the current month 'free' - I set that form field to 20. Membership signups on or after the 20th get start date of current month, and end date of beginning of next month + 12.