Let's fix WHMCS' issue with up-/downgrade amount

[DennisHermannsen]

If you have specified multiple billing cycles for your products, and a client want to up- or downgrade to another plan, they are going to be billed incorrectly if they also switch their billing period while doing so.

Here's an example.
I have a product that costs 900DKK per year. Client wants to upgrade to a product that costs 1900 per year. If they keep the billing cycle annually, everything is good. I expect they would pay 1000DKK on the first day of their billing period.

However - if they client choses "monthly" billing cycle while doing the upgrade, nothing makes sense anymore. The client now has to pay MORE, even though they've already prepaid for a year.

I've already mentioned this to WHMCS, but apparantly this is by design and I should create a feature request (which I did - not live though, yet: https://requests.whmcs.com/idea/change-how-upgradedowngrade-amount-works-when-changing-billing-cycle)

Saying something is "by design" doesn't mean that it's correct. It just means it is meant to be that way - but it's obviously very incorrect.

When a client goes from yearly -> monthly, they need to pay more - if they go the other way around, they need to pay less.

Wouldn't the issue be solved if WHMCS stopped taking the new billing cycle into account and just used the current billing cycle?

 

[brian!]

1 hour ago, DennisHermannsen said:

However - if they client choses "monthly" billing cycle while doing the upgrade, nothing makes sense anymore. The client now has to pay MORE, even though they've already prepaid for a year.

wouldn't they effectively be refunded the 900 and then charged 2400, so a cost around 1500 wouldn't be far wrong... remember that due dates don't change on upgrades, so it's like they're paying for a year on monthly pricing.

1 hour ago, DennisHermannsen said:

I've already mentioned this to WHMCS, but apparantly this is by design and I should create a feature request (which I did - not live though, yet: https://requests.whmcs.com/idea/change-how-upgradedowngrade-amount-works-when-changing-billing-cycle)

there used to be 7-year feature request to charge the full amount on upgrades.. seem to recall it got tens of votes... it doesn't even exist any more... so I wouldn't hold out much hope for a request to work.

1 hour ago, DennisHermannsen said:

When a client goes from yearly -> monthly, they need to pay more - if they go the other way around, they need to pay less.

that sounds like it's because of the NDD not changing.

[DennisHermannsen]

5 minutes ago, brian! said:

wouldn't they effectively be refunded the 900 and then charged 2400, so a cost around 1500 wouldn't be far wrong

Well, then the client should've been charged 1600. The maths still doesn't add up. Besides, like it is now, the user is forced to keep their product for the next 12 months and gets it at a much higher cost than what it actually should be.

 

34 minutes ago, brian! said:

so I wouldn't hold out much hope for a request to work.

But now we get 3 votes per feature request - that's so much better! It's like printing more money. 😬

35 minutes ago, brian! said:

that sounds like it's because of the NDD not changing.

NDD?

[malfunction]

next due date?

[brian!]

15 hours ago, DennisHermannsen said:

Well, then the client should've been charged 1600. The maths still doesn't add up.

if you manually check the maths using the formula in the docs, I would expect the figures to match.

https://docs.whmcs.com/Automated_Upgrades_and_Downgrades

Quote

Old Product/Service
Price Per Day * Number of days until next due date = Amount Credited

New Product/Service
Price Per Day * Number of days until next due date = Amount Debited

Total Payable Today = Amount Debited - Amount Credited

15 hours ago, DennisHermannsen said:

Besides, like it is now, the user is forced to keep their product for the next 12 months and gets it at a much higher cost than what it actually should be.

i'm not disputing that the current upgrade process is madness, but as with so many WHMCS features, it is what it is and it's the way it always has been... good luck trying to change it!

15 hours ago, DennisHermannsen said:

But now we get 3 votes per feature request - that's so much better! It's like printing more money. 😬

only if more votes buys you success - i've seen requests get approved with 1 vote (hitting the mythical traction value), and requests declined with three figures.

besides, the request needs to be approved and others users need to find it... and then you have to hope that it's implemented before it gets archived from the system and the whole circus has to start all over again.

R.I.P the previous request - https://requests.whmcs.com/topic/charge-full-amount-on-upgrade_2  ⚰️

7 years, 13 votes, now archived and so nobody can even see it or vote for it... let us hope yours doesn't go the same way. 🙏

On 19/05/2021 at 19:40, Sufiyan Shaikh said:

Their feature requests suggestion is just for "show". They don't actually implement things with the higher votes. They do what they want and not what customer needs.

never forget that v7.8 was supposed to include the hosting renewal on demand feature, e.g the hosting equivalent of the domain renewal - if that feature had been added, then that could have taken some strain off this upgrade feature... two years later, it doesn't even get any mention as being a future feature... although it must be doable as MG has a module that would replicate it.