Details
-
Type:
New Feature
-
Status: Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 3.0.0.b3
-
Fix Version/s: Short Term
-
Component/s: None
-
Labels:None
Description
We need an advanced option for packages, that allow the package to automatically be changed at renewal.
There would need to be at least 2 options for this feature.
1. Which package to change to (drop down)
2. What term for that package to change to (drop down)
Package change must occur at time of renewal, just prior to invoicing and bumping renew date.
This is effective for free trials, where the initial package is free, but after the trial the user must pay.
Example:
Take for example a 15 day free trial. This package has a paid package attached. User orders the free package. Days before renewal is 5, so on day 10 the following happens..
1. The package is changed to a 1 month paid package.
2. The service is invoiced, for the paid package.
3. The renew date is bumped on the service, to be +1 month.
What's interesting is that the package you switch to could be set up to switch them again so it would be possible for the package to change each time it renews.
The package you switch to MUST use the same module. There are no module actions performed, it will not do any kind of upgrade action to the module.
We should discuss where to place this on the package edit/create page, but I'm thinking a toggle-able option so that it's hidden by default.
Also, editing a package should warn if a term is removed that is used by another package for switching to.
Activity
For simplicity, we can start by saying the package switches when it renews. So, we would not have an option for the number of renewals before it switches, and would not need to track that. This will cover many cases. For example, if you want to offer a 60 day trial instead of a 30 day trial, then just set a 60 day term.
This is becoming increasingly important for free trials.
With my suggested change, we would only need 2 fields, instead of 3:
1. Which package to change to (drop down)
2. What term for that package to change to (drop down)
Paul Phillips
added a comment - For simplicity, we can start by saying the package switches when it renews. So, we would not have an option for the number of renewals before it switches, and would not need to track that. This will cover many cases. For example, if you want to offer a 60 day trial instead of a 30 day trial, then just set a 60 day term.
This is becoming increasingly important for free trials.
With my suggested change, we would only need 2 fields, instead of 3:
1. Which package to change to (drop down)
2. What term for that package to change to (drop down) This should happen immediately after the service is added, since it'll just be set to renew at the new term after the current term.
Paul Phillips
added a comment - This should happen immediately after the service is added, since it'll just be set to renew at the new term after the current term. 
The idea behind this one is for support for trials and similar. Buy for cheap or free, and then it switches to another package at the next renewal, or after x renewals and invoices at that package rate.
The package must use the same module.