Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by stormy

  1. Thanks for the quick reply, Brian! Let me clarify: Ok I got it! She ordered before the cron run, but was activated after it. So it WAS the cron that changed the status to inactive. And that also means that the manual accepting of the order does not mark the client as active, only the daily cron does. I know it's not a problem except that I like to look at my new clients of the day, and if they are not active, I won't see them till the next day. Any hints on how to code this?
  2. Just today I found out that a new customer was set as Inactive. This is something I thought was fixed many versions ago, I have a distant memory of even having a custom hook that would set clients to active after their first order was accepted. The cron works correctly when setting clients as active/inactive, though. I've searched the forums and the documentation and can't come up with a definitive answer. Does WHMCS mark new clients as active, and there's something wrong with my install? I'm on 7.6.2 by the way. If not, can somebody help me with a hook that does it? In case it matters: I have the "Only Auto Provision for Existing" checkbox ticked, to always leave orders by new clients pending for manual review. Thanks a lot!
  3. Fantastic!!! Works perfectly, and it's an elegant solution. Thank you very much!
  4. The error is "Error: Call to a member function toNumeric()"
  5. Unfortunately I'm getting a big "Oops! Something went wrong and we couldn't process your request." I'm on WHMCS 7.6.2 - maybe that's why?
  6. Hi Brian, Thanks! Some extra info I forgot: I found the problem when looking at domain renewals. Since we don't send automated invoices for domain renewals, customers have to enter a domain renewal order. And there are two different ways to do that! That's why I want the fix on two different places. Now I'll go implement your solution and report back 🙂
  7. I'm looking for a way to disclose the domain id protection price in the price summaries: the one in viewcart.tpl and the one in ordersummary.tpl. I haven't found a way to pull the prices of domain addons on those pages, and I'd rather not hardcode the text. Any ideas how to pull this off?
  8. Under which circumstances is the "Upgrade Order Cancelled" email sent? I've already seen it sent incorrectly twice, to customers that had upgraded correctly months ago and had no outstanding orders or invoices.
  9. This URL stopped working with a 502 error: https://www.google.com/jsapi As a result, all graphs in reports stopped working. I don't know if this is a temporary glitch, but I've found docs that call this "the old code": https://developers.google.com/chart/interactive/docs/basic_load_libs#update-library-loader-code I hope this can be hotfixed if the old api doesn't work any more.
  10. I live in a "normal" country called Spain, I think it's as "normal" as Italy and Portugal, although I envy many things from both countries! We are subject to the same stringent tax rules as the rest of the Euro Zone, and I take invoicing very seriously. I know it's unfortunate that WHMCS is in the UK where the system allows for a lot more leeway. As everyone else, I've done all the necessary workarounds to make sure my WHMCS invoicing is legal, with consecutive invoices, fixed invoice data, no zero amount invoices, not using the credit system, etc. I'm sure you all have done the same. WHMCS billing contacts have been a part of WHMCS forever: https://docs.whmcs.com/Clients:Contacts_Tab#Billing_Contact All they were missing was the Tax ID field. Now, if you think they are a bad idea, you can choose not to implement them. But the Tax ID field is not the problem. In fact, it's a bigger problem to have wildly different invoice details with the same Tax ID, which is what's been happening until now.
  11. (sorry for the double post!) Also - the contract is always with the main account holder, not with the Contacts. I'll also add that if you allow the modification of the main account details, that changes invoices too, and the only record of the changes, as you know, is the one email that WHMCS will send you about it. I see a lot more potential for good than for bad with this. I know our customers have been asking for this feature!
  12. Well, I think I have bad news for you then. All that you mentioned is already happenning in WHMCS. Customers can already select a contact as the billing contact and use any name and contact data that they please. The invoices will still keep the tax number of the main account, but that doesn't make those invoices with different names less wrong.
  13. That's funny, we've been asking for years to have a tax field for Contacts so customers can solve their billing problems using contacts. What problems do you think it could cause?
  14. Done, thanks! And Happy New Year to all of us crazies that work every day!!! 😄
  15. Ok - it gets worse. It seems that the NUMBER variable got reset on December 31st at the automation time, and the YEAR variable got reset today at the automation time. So now I have seven invoices from 2018 that have duplicate numbers and are out of series. And all my 2019 invoices start on number 9. Every invoice from yesterday and today needs to be manually corrected and resent.
  16. So did I - and it never worked for me either! 😄 Unfortunately it didn't work correctly. I have the format set as "D{YEAR}-{NUMBER}". At midnight the NUMBER variable got reset but the YEAR did not! The year got reset at 10:00 when the automation run. So - shall I fill a bug report or open a ticket?
  17. My invoice automation runs at 10:00 am, so probably no luck! 😄
  18. I have my EU VAT Addon configured with "Auto Reset Numbering" set annually. Now that the cron runs every 5 minutes, will it finally reset the invoice numbering at 0:00 January 1st? (which is the only correct behaviour) Or will it still reset them at the time the automations run, as usual? This is no use, because customers can generate invoices before this happens, which would need to be manually corrected one by one, as well as the "next invoice" number once that is done. We'll see tonight...
  19. Ah, I didn't look at the "ClientAreaFooterOutput" part. By the way, I've added to this hook another useful snippet to filter question marks from knowledgebase searches: jQuery('#kbsearch').submit(function() { var search = jQuery('#kbsearch input[name="search"]').val(); search = search.replace(/\?/g, ""); search = search.replace(/\¿/g, ""); jQuery('#kbsearch input[name="search"]').val(search); return true; }); Customers will frequently use question marks and they get less search results because they are used in the actual search.
  20. Not if you use external forms that post to the domain search. So this is the better option overall!!!
  21. There's another reason for using the hook instead of modifying the template!
  22. Awesome! Is there any advantage of the hook over editing the template? Besides not needing to edit the template, of course 🙂
  23. Put this code in the bottom of domainregister.tpl to get rid of any extraneous stuff that customers will type into a domain search: "www.", slashes, https, spaces, etc. By the way, this also solves a bug I've reported, where searching for a domain with "www.", like "www.thedomainiwant.com" will return "www.com is unavailable". <script> jQuery('#frmDomainChecker').submit(function() { var domain = jQuery('input[name="domain"]').val(); domain = domain.replace("www.", ""); domain = domain.replace("http://", ""); domain = domain.replace("https://", ""); domain = domain.replace(" ", ""); domain = domain.replace("/", ""); domain = domain.toLowerCase(); jQuery('input[name="domain"]').val(domain); return true; }); </script>
  24. Please read carefully if you use monthly and yearly pricing for your products. Unless the price is the same no matter what the cycle (i.e. no discounts for yearly billing), most of your upgrade orders will have wrong pricing. I've been trying unsuccessfully for WHMCS to recognize this as a bug. I thought I'd bring it up for discussion to see what everyone thinks. I encourage you to create a test user and try it on your install. It's a lot easier to see it with your own eyes than reading my explanation. I just had to refund 20 bucks to a customer due to this. Quick summary: -Upgrading from Monthly to Yearly: the customer is charged LESS than he owes.-Upgrading from Yearly to Monthly: the customer is charged MORE than he owes. Any upgrade that changes the billing cycle will have a wrong amount, unless the "price per day" of the cycles is exactly the same. How to test: 1. Create two products: one with monthly billing and another one with yearly billing. Put the due dates a month and a year in the future, minus a couple days. So this is equivalent to a customer placing an order a couple days ago. 2. Now let's see what happens when this customer wants to upgrade his plan. Login as the customer and go to the Yearly product. Go to the upgrades page. 3. In the upgrades page, choose an upgrade package. The Monthly billing cycle will already be preselected for you. Continue. 4. In the next page you will see a wrong price, which is higher than the customer should pay. Why? Because the amount is calculated using the monthly price! WHMCS will figure out the price per day of the monthly product and multiply it per 363. The due date never changes. 5. Go back, and choose the same product and Yearly billing instead: you will get the correct price, which is lower. 6. Now test the same with the Monthly product, and upgrade it to Yearly: the price is wrong again, but this time is lower than what they'd pay if they stay at Yearly. Thoughts?
  25. Yes, but I still lose the formatting. I.e: if I decide that I want to switch the order of a paragraph, or move a few sentences that already have bold and links, it's either lose the links and bolding or fix the extra formatting. And I still have to endure the small grey type. 😢
  • Create New...

Important Information

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