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.

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

Hello, This is the first time we have seen this happen, so not sure if it was present before v7.7. A customer called and provided their new card number over the phone. Via the admin area the profile was located, the card details pop up opened and the new card entered. All appeared to work with a success message. Now it's impossible to charge the customer. In the gateway log it shows: UserID => 400 id => cus_XredactedX object => customer deleted => 1 Looking up the customer is Stripe it shows as: This customer account has been permanently closed. Any attempt to charge the customer results in Invoice ID => 999999 User ID => 400 Amount => 60.00 No such customer: cus_XredactedX Trying to update the card, and even removing the paymentgatewayID from the database manually results in: UserID => 999999 token => tok_Xredacted# error => No such customer: cus_XredactedX UserID => 999999 No Stripe Details Found for Update I'd like to know the following: Why does WHMCS issue a delete customer API call? (This should NEVER happen, as it's irreversible) How can we now get a valid customer / token created for this customer? (Any attempt results in the customer being deleted at Stripe, so I suspect I need to manually alter this client record in the database) Can I link a customer created in Stripe to a WHMCS profile? (I added the customer manually into Stripe so that the payment could be processed)

Are you using WHM/cPanel to manage the hosting accounts? If so you can import the accounts from the server(s) and then move them to an existing client or edit the imported client to update it to reflect the client. The import works well but you will need to check the dates, prices, etc.. post import.

I added the hot fix (CORE-12200) and the errors went away but now the View Cart button returns a missing page message. Is something else needed beyond uploading the file?

System Detected - Full Friendly Rewrite.

Hello, All went well with the auto updater (first time it's worked without issue for us). The screenshot shows which two files are missing, and the resulting JS error. This is when viewing the renew domains page inside the client area and when using the default Six template and the standard_cart order form. Thanks in advance for your assistance.

Hi Corey, No, no answer was forthcoming. I talked the customer through updating their details after logging in. We haven't had to updated any card details since but never got an answer to why WHMCS deleted the client at Stripe instead of just removing the linked card.