Jump to content
Damo

Overage invoices sent to every customer

Recommended Posts

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.  

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

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';

Share this post


Link to post
Share on other sites
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'

Share this post


Link to post
Share on other sites

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'

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Hi all,

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

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by chrissie-penguin
Further info found

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

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?

Capture plein écran 30092019 090236.bmp.jpg

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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)...

Share this post


Link to post
Share on other sites
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?

Capture plein écran 30092019 090236.bmp.jpg

Oh wowzer!  

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Similar Content

    • By Luthersites
      When I try to do the update I get the following error:
      Unable to complete incremental updates: Unable to import the 7.8.0 Alpha1 database file. Unable to import /home/lutherh/public_html/resources/sql/upgrade780alpha1.sql: SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs
      I can't find anything on your site that talks about this error, and I find it odd that the database has incorrectly set column types.  Please advise as to what I need to do.
    • By noahesbjerg
      Hi,
       
      So, I just got a stripe account. And updated to the newest WHMCS version. But it seems that the new version completely broke the stripe module. For an example, if I try to delete a payment method I get this: https://i.imgur.com/xjtQkPn.png . And trying to add a new payment method results in this " Payment method failed to create successfully. Please try again.". I am using a custom theme, but it's also broken with the default one.
    • By loopmail
      Looking around and some clients have enabled 2fa for the primary user, but there seem to be no details for it on the contacts page. is this not a feature on offer to contacts or a way for administrators to see the status/clear the status for contacts?

       
    • By zarvis
      Hi,
       
      From today morning the Invoices are not being updated, and the API callback is getting failed for the Coingate and perfect money modules.
      Anyone else facing similar issue?
       
      Regards
      Chandrakant
    • By pushpendra
      After upgrading to WHMCS 7.8, the domain search is not working.
      When we search for domain, Its not showing search result. Its just showing suggestions. And Suggested Domains are also showing taken.
      https://hosting.india.to/clients/cart.php?a=add&domain=register
  • Recently Browsing   0 members

    No registered users viewing this page.

×

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated