CORE-13724 Overage invoices sent to every customer

[Damo]

The daily cron today just sent every active customer an invoice for overages.  $0 invoice.

This is the first cron run since updating WHMCS yesterday.  Each invoice showed the disk usage, but we don't have overage billing applied for disk usage, only bandwidth.

e.g. Total Disk Usage = 384 MB - Overage Charge = 384 MB @ 0/MB

[xyzulu]

Please open a ticket with WHMCS about this. They should be able to address this issue with a hotfix

[Himeko]

Same happened to me

[xyzulu]

You can skip the overage billing using a switch, see https://docs.whmcs.com/Crons 

.. a temporary workaround perhaps.

[Damo]

That work around is not useful at all.  Overages only bill once a month on the last day.  Which is why it did it today.  

We do charge overage rates for bandwidth but not disk space.  It has never sent out invoices for it in the past.  It's annoying and unprofessional that every single client received an invoice from the system this morning with a descriptor of an overage matching their actual disk usage and a zero amount.

A ticket is already open with support so will wait to see how they respond.

[xyzulu]

Sorry.. just trying to help.

I agree this isn't an acceptable solution for you. I've already billed my customers multiple times since upgrading to 7.8.. and now rolled back to 7.7.1... so I'm also fairly upset too.

[WHMCS Edward]

It appears that the following changelog item is what you're seeing here:

Quote

CORE-13060 - Correct calculation of overage billing with limit of 0

As part of this case, the overage billing feature was updated to support overage billing where the soft limit is 0.  Essentially a soft limit of 0 means you want to bill the customer for all usage.  If you have a product where you are enabling overage billing but do not want either disk space or bandwidth to be billed for, you should ensure you set a very high soft limit that will mean the customers usage never exceeds it, and therefore never gets billed.

Hope this helps!

-Ed

[Damo]

Well thanks for the extra information Ed. I’m still waiting for a reply to the ticket. 
 

So as a customer how are we supposed to know the ‘part of this case’ would result in ALL clients receiving an invoice?  
 

WHMCS don’t publicise details of changelog entries. 
 

A change like this is something that should be warned/flagged/alerted. Or even better don’t change the behaviour of something like a zero value so significantly. 
 

This is poor form.  

[WHMCS Edward]

There is discussion within the case and code change submission that it should be noted in the release notes, so it appears the lack of mention was an oversight. I will be sure to raise this with the team.

Sorry for any inconvenience it caused.

-Ed

[Damo]

An oversight is just poor form. If it was noted and didn’t happen then it was a decision someone made. 
 

WHMCS is not a product developed in someone’s home office / bedroom anymore. This kind of oversight has ramifications to businesses that use it. 

[WHMCS Lawrence]

Hey everyone,

Digging into this further, the overage billing you've noticed isn't occurring specifically due to this change from case CORE-13060. The instances I've seen of this have been due to an unexpected value of "0" in the overagesenabled field in the tblproducts database table - we expect it to be empty when the Overages Enabled setting is disabled on a product. Myself and my colleague are investigating how this happens. In the meantime, the result is that unexpected value appears to be causing the product to get included in the overage billing process. I've tested locally and editing and re-saving products without making any changes corrects the value in the database as needed to prevent this from occurring going forward.

If you wish to update all products at once, the following SQL query should do the job:

UPDATE tblproducts SET overagesenabled = '' WHERE overagesenabled = '0';

[radiantsolutions]

11 hours ago, WHMCS Lawrence said:

Hey everyone,

Digging into this further, the overage billing you've noticed isn't occurring specifically due to this change from case CORE-13060. The instances I've seen of this have been due to an unexpected value of "0" in the overagesenabled field in the tblproducts database table - we expect it to be empty when the Overages Enabled setting is disabled on a product. Myself and my colleague are investigating how this happens. In the meantime, the result is that unexpected value appears to be causing the product to get included in the overage billing process. I've tested locally and editing and re-saving products without making any changes corrects the value in the database as needed to prevent this from occurring going forward.

If you wish to update all products at once, the following SQL query should do the job:

UPDATE tblproducts SET overagesbilling = '' WHERE overagesbilling = '0';

Didnt Work

 

Error

SQL query:

UPDATE tblproducts SET overagesbilling = '' WHERE overagesbilling = '0'

MySQL said: Documentation
#1054 - Unknown column 'overagesbilling' in 'where clause'

[Damo]

In a ticket reply from Lawrence I was sent a different SQL statement to run.  I guess this is just an oversight. 🤨

UPDATE tblproducts SET overagesenabled = '' WHERE overagesenabled = '0'

[WHMCS Lawrence]

On 9/8/2019 at 2:43 AM, Damo said:

In a ticket reply from Lawrence I was sent a different SQL statement to run.  I guess this is just an oversight. 🤨

UPDATE tblproducts SET overagesenabled = '' WHERE overagesenabled = '0'

Apologies for any confusion. That's the correct query.

[Damo]

Thanks Lawrence.  It was not confusion, it was two different queries provided by the same Technical Analyst.  I know my sarcasm above wasn't understood (or perhaps skipped over) I am Australian after all but in fairness it was pretty poor form to provide an incorrect query to fix an issue.

In this instance it did nothing more than generate an error but what if the consequence was incorrectly updating entries and causing more issues?

I have read a few posts where the suggestion has been to setup and test a beta / pre-release version before pushing it across to our live sites but how exactly (and why would we) do we test these types of things that only occur on the last day of the month and include real customer data and their credit card information / payments? 

I know I don't keep my support subscription up-to-date so that I can beta test software that I use to  run my business and charge my clients in the hope that I get some 'free swag' like a pen or mouse-pad.  I pay it so that it works - and that it works without a negative impact to my clients or my reputation.  From the information provided this issue has come about because the system received the result of 0 instead of an empty string in a query.  This is GIGO (to quote John Kipling in CORE-13697 - similar issue of an unexpected result) and tells me that the developer wasn't performing basic validation of the query result (i.e. a result of 0 shouldn't exist).  It should be either nothing or a valid string such as '1,MB,MB'.

Please take this feedback seriously and use it to improve your use-case testing.

[WHMCS John]

Hi all,

A hotfix has now been published with additional logic to handle these legacy product configuration values:

 

[Damo]

Thank you for the hot-fix.  A correction though, it was in 7.8.0 not 7.8.2.  The issue was reporting in August.

[chrissie-penguin]

Has anyone had any issues with this again at the end of this month? I have had a load of invoices go out as it seems the overage settings we have had in place have been overwritten - I am manually resetting them but wanted to check if anyone else had seen the same?

Edited September 30, 2019 by chrissie-penguin
Further info found

[Damo]

No issue for us. But I did run the SQL above and also went through each product and set the zero values to 99999999 just to ensure that ‘soft limit’ would never me met for things we don’t charge an overage on (ie disk quota)

[chrissie-penguin]

Good to hear!  Thanks for your reply.

[benduick]

Same here, the system sent today to all clients some CRAZY invoices!!!...

Firt time for me and since the last update done... yesterday! Do I have to run the SQL above to avoid this?

[Damo]

Wow. I feel for you and the work this kind of issue generates. I would have thought that WHMCS would have responded by now. 
 

I’ve posted and eluded to this to date but feel it needs to be clearly stated. Something is different in this major release. 
 

Either a new set of developers, a rush to release it or lack of real testing. Something is different and unfortunately it’s us that looks bad/unprofessional. 

[slim]

Your not wrong. We can’t upgrade due to a ballsed  up eWAY gateway implementation they rewrite for 7.8.x and I’m glad we didn’t due to all the other bug reports.

[brian!]

23 hours ago, Damo said:

Either a new set of developers, a rush to release it or lack of real testing.

of the three, i'm inclined to think it is the latter - the v7.8 beta forums were virtually dead with more posts by staff than beta users... I can remember active beta forums here, but 7.8 definitely wasn't one of them! these v7.8 discussion forums have been far more active - because far more users are now running these releases.

which I assumed either meant there were few bugs to be found, or not a lot of users were testing - so when WHMCS started to beg users to test the beta in the hope of winning WHMCS merchandise, then I knew it wasn't be tested by users... I can't recall that begging happening before in the last 6+ years of betas.

the sad truth is that with insufficient internal and external testing, the betas are effectively alphas; the first GA is still a beta (and may include new features that haven't been tested in the alpha stage) - and so only at the GA stage do they get widespread external testing...

never forget that with the exception of v7.3, every v7 major release has needed at least one maintenance release within its first month.... I think on one or two occasions, the maintenance was released on the same day as the first GA!

although, I can't recall a time when a GA has needed 3 maintenance releases in a month with, I assume, a possible 4th on the way (judging by these v7.8 discussion forums still not being closed yet)...

[chrissie-penguin]

On 9/30/2019 at 2:31 PM, benduick said:

Same here, the system sent today to all clients some CRAZY invoices!!!...

Firt time for me and since the last update done... yesterday! Do I have to run the SQL above to avoid this?

Oh wowzer!