Changing Plan Validity duration

My client has Plans with validity duration 1 year. They now want to change all those plans to "this calendar year".

I have two questions:

1) I just tested this with a 24h test plan which I changed to "today". This shows that after I have registered for 24h, if I then change the plan to "today", my expiry date as registered user does not change. It seems that the plan will - despite the change - still be active until the end of the paid period, so paid plans will not expire at the end of 2021, regardless if the users have paid for example in August (which would normally mean their plan expires Augst 2022), right?

2) This would mean, the users would have to renew in the middle of 2022 for the calendar year 2022, and thus pay double for all the months they paid for in 2021. What options do we have to refund / acknowledge the user's payment in 2022? Is there a setting that gives a discount according to their expiry date, or do I have to set up coupon codes manually?

Thank you in advance for some help!
Terry

bytekultur wrote: My client has Plans with validity duration 1 year. They now want to change all those plans to "this calendar year".

I have two questions:

1) I just tested this with a 24h test plan which I changed to "today". This shows that after I have registered for 24h, if I then change the plan to "today", my expiry date as registered user does not change. It seems that the plan will - despite the change - still be active until the end of the paid period, so paid plans will not expire at the end of 2021, regardless if the users have paid for example in August (which would normally mean their plan expires Augst 2022), right?

2) This would mean, the users would have to renew in the middle of 2022 for the calendar year 2022, and thus pay double for all the months they paid for in 2021. What options do we have to refund / acknowledge the user's payment in 2022? Is there a setting that gives a discount according to their expiry date, or do I have to set up coupon codes manually?

Thank you in advance for some help!
Terry

1) yes, correct

2) the renewal of the changed (from 12 months to calendar year) plan will not take into account the existing value. But it will take into account the current expiration date's year, and offer the renewal for the year in which the plan expires, and also take into account the "renewable in advance" setting, but not the "Bonus time before first period start (for calendar-based durations)" which is not for renewals.

If you want to keep the same plan, you would need to setup a promotion using a custom field (e.g. with CB Code, or CB Query).

But:

Pro-rating will happen on a plan upgrade to different plan. So if you setup a new calendar year plan as an upgrade, here how it would look like (all the computations and text output are automatic):



If you don't have too many places where the plan is conditioned upon, that's the approach I would recommend.

Hi Beat,

Thank you for the detailed explanation and very quick response.
I will discuss that with the client but it sounds a good option. Your screenshot does not really show our situation as in the upgrade plan shown there is not actually a calendar year one, but a 12 months plan from another month, but I guess the process would be the same, and with the upgrade to the calender year we could disallow renewal for the old (12months) one, and offer the "upgrade", so the prorating would then deduct the price already paid for that year, did I get that right?

Hi,
Yes, my example was a 12 months plan subscribed Sept 12th 2021, valid until Sept 12th 2022 (so of which already approx 2 months were already used. giving it a residual value of around 10/12th of 100$), upgraded to a 100$ calendar year plan starting July 1st (2021) until June 30th (2022), thus only 2/12th remained to be paid for the calendar year. In this example, the calendar year already started, and there was no "Bonus time before first period start (for calendar-based durations)". But if your calendar year starts January 1st, and you have a "Bonus time before first period start (for calendar-based durations)" of e.g. 2 months, then the prorating computation might be different.

In my test environment, I tend to have settings that test extreme settings, but you can test that use case with your exact own plans, just make the new plan access level such that your registered regular users don't see it, and it will show the computation on the membership tab in profile, and also on the basket display, to be tried out with your exact settings.

Does that solve your request ?