Wrong Prorated Amount

We've unfortunately lost revenue as a result of an improper calculation via CBSubs.

User purchased recurring plan using coupon code, then upgraded to higher plan. During the upgrade, the calculation for proration was made without taking into account the coupon code. So the upgrade was less than it should have been because it reduced the prorated amount in full as opposed to the reduced (coupon code) amount actually paid.

EX:
- user subscribes (and paid) to recurring plan A = $20/month - %50 coupon code = $10/month
- user upgrades to plan B = $50/month
- upgrade prorated amount user paid = $30, then $50/month
- upgrade amount should have been = $40, then $50/month

During this transaction there were also issues similar to this with the idevaffiliate amount. It seems from these examples, many calculations are being made to determine the actual paid amount as opposed to having a variable which stores the actual "paid/completed amount".
Having the actual paid amount stored in the db and used for these scenarios seems like the optimal solution. Due to what appears to be scenarios overlooked, the amounts are being miscalculated.

I could be wrong and understand code is complex, but this is the most important thing of all because it accounts for revenue and lost revenue. Thank you

Prorating is not based on amount paid. It's based off plan value. It has always worked this way within CBSubs. We've an old feature ticket to note implementing an option for it to prorate off of paid amount instead of plan value, but there has been no progress on this for some time.

forge.joomlapolis.com/issues/7181

We have to be extremely careful about making adjustments like this. I do not know when or if this will be implemented. At this stage of CBSubs making changes to calculations could destroy businesses depending on it.

Indeed this does do harm to businesses, for example losing revenue during this transaction as a result. Unfortunately, we've not triple checked every single payment upgrade made via CBSubs but for other reasons, we did catch this one.

So over the years, I can only imagine how much revenue has been lost as a result of this setup. I'm sure you all had a reason for this?

Having said that, this seems like a very important item to have updated. Logically, I am not sure why a business would want to lose revenue when they've a great customer who wishes to upgrade to a more expensive plans.

There are some large ticket items, and when users are upgrading from these, the result could be terrible! In fact, you could essentially end up providing an upgrade for nearly free if the user got a hefty discount and then upgraded to a slightly more expensive plan. This is very bad!

The prorating was designed this way long ago before coupons even existed (take notice that CBSubs Promotions is a plugin). So that's why it works the way it does. It has always worked this way. There are no plans to change the original behavior, but to try an extend it with an option to prorate based off paid amount, which is extremely complicated because a dozen different things can affect a baskets price.

I apologize if the parameter wasn't clear enough, but it directly states it applies to plan value. If you don't like how it's calculated I don't recommend using prorating at this time. You can try using CBSubs Promotions to apply an automatic discount when upgrading from 1 plan to another to create your own prorating behavior though. To do so I believe you'd just need the following Condition on the promotion.

To which plans this promotion applies: Plan B
Which plans must be purchased at same time: Plan B
Any of the following plans subscriptions: Plan A
Must be in state: Upgraded to other

I believe that should apply a discount to Plan B when upgrading from Plan A. Might need further adjustments to the conditions though. You could then store their previous payment amount to a CB field using CBSubs Fields and use that field as the discount amount or you could use a CB Code Field and calculate the remaining value yourself however you like and apply that as the discount.

I understand where you're coming from as well, but please keep in mind we've been in business for over 15 years. Some implementations may not make complete sense if they were implemented yesterday, but this wasn't. It was designed and implemented a very long time ago. CBSubs originally started as a means for us to collect payment to help fund CB development (which was and is still free). It wasn't even a product at that point.

With CB 3.x we hope to shed these old implementations as we shift CB into a modern stack.

Yes sir, we respect software development because we develop software as well and understand it is a hefty work load. I certainly wouldn't want to cause any unnecessary work. However, in this case it is very important because it directly impacts revenue (same with the idevaffiliate implementation).

krileon wrote:

I believe that should apply a discount to Plan B when upgrading from Plan A. Might need further adjustments to the conditions though. You could then store their previous payment amount to a CB field using CBSubs Fields and use that field as the discount amount or you could use a CB Code Field and calculate the remaining value yourself however you like and apply that as the discount.

I understand where you're coming from as well, but please keep in mind we've been in business for over 15 years.

I do appreciate your understanding and attempt to provide a temporary solution. I will look into this to see if it is doable for us. We absolutely need an automated way of handling this because the amount of time just to create this solution takes away from all internal efforts, and handling these things manually isn't feasible.

Please note: We have been a loyal customer as follows (Member Since 11 years ago)

Again, thank you for trying, and I will let you know as we have questions during this process of potentially using promotions to prorate. 

krileon wrote:

You could then store their previous payment amount to a CB field using CBSubs Fields and use that field as the discount amount or you could use a CB Code Field and calculate the remaining value yourself however you like and apply that as the discount.

Could you please elaborate on this, as I am not sure how to get and store the payment data accordingly, trying to find it now. I'd prefer the more simple option to eliminate time and mistakes. Thank you