Upgrade/Downgrade

[MACscr]

I see that in v3 admins are able to updgrade/downgrade a hosting account (aka, change their package). Are clients able to do this as well? Aka, they can order an new package and it will be done automagically if we have it setup that way?

 

I am pretty sure thats what everyone has been wanting for a long time.

[Matt]

No, that's not been requested yet. Doing the change automatically isn't the difficult bit, but it's knowing which packages the user can upgrade/downgrade to from their current package and calculating how much to charge/credit the client for the change.

[generic]

lpanel did allow this, they set up a numeric "value" for the plans that way you can only upgrade to a higher value or downgrade to a lower value. There was NO prorating though. you had to manually figure out a way to do that - since lpanel did not have the credit feature you have, all you could do was extend the next billing date as credit.

[imaginit]

No, that's not been requested yet. Doing the change automatically isn't the difficult bit, but it's knowing which packages the user can upgrade/downgrade to from their current package and calculating how much to charge/credit the client for the change.

 

This could be done fairly easily with another table to track it...

 

Plans

Bronze: Id 1

Silver: Id 2

Gold: Id 3

 

CREATE TABLE tblupgradedowngrade (udid int( NOT NULL auto_increment, productid int( NOT NULL, canswitchtoid int( NOT NULL, switchtype ENUM('Upgrade','Downgrade'))

INSERT INTO tblupgradedowngrade (productid, canswitchtoid, switchtype ) VALUES (1,2, 'Upgrade');
INSERT INTO tblupgradedowngrade (productid, canswitchtoid, switchtype ) VALUES (1,3, 'Upgrade');
INSERT INTO tblupgradedowngrade (productid, canswitchtoid, switchtype ) VALUES (2,1, 'Downgrade');
INSERT INTO tblupgradedowngrade (productid, canswitchtoid, switchtype ) VALUES (2,3, 'Upgrade');
INSERT INTO tblupgradedowngrade (productid, canswitchtoid, switchtype ) VALUES (3,1, 'Downgrade');
INSERT INTO tblupgradedowngrade (productid, canswitchtoid, switchtype ) VALUES (3,2, 'Downgrade');

SELECT * FROM tblupgradedowngrade WHERE productid = '$productid';

 

Now you have the plans that can be upgraded to or downgraded to, along with their IDs and whether it is an upgrade or a downgrade. With the IDs you can now get the price differences, prorata information, and calculate additional costs for the rest of the month and make any needed changes.

 

I realized you probably already know and have thought of this, but I am just a total dork and love programming, so I took it upon myself to write this out.

[MACscr]

lol, nice. =P

[Matt]

Hi Lance,

 

Not bad! Although, I think I thought of something a bit simpler!

 

Two new fields on the tblproducts table, upgradeids and downgradeids, then simply store the possible product ids that a user can upgrade/downgrade to in a comma seperated list. Then have a listbox on the products configuration page that allows multiple packages to be selected using the Ctrl + Click method.

 

However, the issues I was thinking of were more related to the actual workings of it:

• Do we need to keep a history of upgrades/downgrades - if we just change the package and amounts the user should be paying then there will be no record of the previous package
  
• When downgrading, I presume for crediting it would be ok to take the recurring amount field and work out how much of that value has not yet been used - but what happens if they upgrade during the first billing period? Should any of the setup fee be refunded?
  
• What happens if the user wants to move from a package with a free domain to one without? Do we just rely on the admin deciding if this upgrade is allowed on the upgrades config?
  
• What happens if the user tries to move from a package with configurable options to one without? Same as above
  
• What happens if the user has an addon that does not apply to the new package - do we not allow the upgrade or just terminate the addon?
  

Well that's a few of them...!

 

Matt

[imaginit]

Not bad! Although, I think I thought of something a bit simpler!

 

Yeah you did! One of my biggest problems with technical stuff is over complicating things!

 

 

[*]Do we need to keep a history of upgrades/downgrades - if we just change the package and amounts the user should be paying then there will be no record of the previous package

 

This could be stored in the activity log table? Or even better (maybe, here I go over complicating again. lol), maybe a client history table could be created to track this among other things?

 

[*]When downgrading, I presume for crediting it would be ok to take the recurring amount field and work out how much of that value has not yet been used - but what happens if they upgrade during the first billing period? Should any of the setup fee be refunded?

 

I don't think setup fees should be refunded period ( Of course, on a per situation basis there can be exceptions.), this just allows for people to abuse your service, signup for Bronze, upgrade to Advanced etc. If they upgrade, and it is the first billing period, then they should pay the difference in the setup fee. If they downgrade and it is the first billing period, then maybe a credit here for the difference would be appropriate?

 

[*]What happens if the user wants to move from a package with a free domain to one without? Do we just rely on the admin deciding if this upgrade is allowed on the upgrades config?

[*]What happens if the user tries to move from a package with configurable options to one without? Same as above

[*]What happens if the user has an addon that does not apply to the new package - do we not allow the upgrade or just terminate the addon?

 

These three points should be handled by the admin probably? Maybe when cases like that happen, have a request sent to the admin, but require some manual processing? Or, if the admin configures it in such a way, just have the addons and configurable options terminated, with some very clear warnings displayed to the user that such will occur if and when downgrading? Of course, you get to the point of how do you track every possible situation that could arise from a dynamic system such as this with many different product types etc.

 

All I can say is, when you do figure out the solution, because I am sure you will, I will be looking forward to see how you handled it all!

[Sohan]

lpanel did allow this, they set up a numeric "value" for the plans that way you can only upgrade to a higher value or downgrade to a lower value. There was NO prorating though. you had to manually figure out a way to do that - since lpanel did not have the credit feature you have, all you could do was extend the next billing date as credit.

Yeh, but Lpanel suck. v3 is out, and this is working as well

[generic]

Yeh, but Lpanel suck. v3 is out, and this is working as well

 

who you kidding been looking for an alternative since the day i started using it Glad I found WHMCS

[taylorwilsdon]

Upgrade / Downgrade available to the client would be a godsend - I'd be happy to test out the new version once most of the kinks were gone if that was a feature.

[Host4cheap]

Yup, Upgrade / Downgrade available to the client is a great ++