Damo

Nope. Each cPanel login has to be its own account. As you’ve pointed out that’s what WHM resellers is designed for.

In my example screenshot the ‘Shopping Cart’ entry is for a domain renewal so an invoice number did exist. So MODULE-7151 needs to be expanded beyond initial signups.

The silence from WHMCS on these issues is telling. Support staff are responding to other posts but these payments ones are quiet at the moment. Would be good to get some kind of official acknowledgement.

Yes we are also seeing this with 7.8.3. The description in Stripe is still not correct. It now shows our {Descriptor} + Shopping Cart for manual Stripe payments. But between the 7.8 and 7.8.3 release it was showing {Descriptor} + invoice number. I can see a transaction on our account on Sept 24th that is set this way. For all cron payments it shows {Business Name} + Tax Invoice #99999 (Tax Invoice is a language string we use). The description needs to be consistent! Include the Descriptor or Business Name and the invoice reference number.

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.

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)

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.

Can someone at WHMCS please acknowledge the issue here? Manual payments (non-cron) do not have a descriptor set that includes the business name and invoice number. Instead they are showing the Payment ID. This change of behaviour affects our ability to auto reconcile payments. Thankfully the descriptor set on our customers statement still shows our details and the invoice number.

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.

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'

Also running v7.8.1 here and the descriptor for client initiated payments gets the payment ID instead of the invoice number. The system cron runs at 0900h and you will see in the screenshot below that the three with the incorrect description are all non-cron processed payments.

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.

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.

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.

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