Chris74

Hi, I'm looking for some advice relating to the nextinvoicedate field in the tblhosting table. A while back there seemed to be a problem with the cron jobs causing very high load and taking a long time to process. I noticed some issues with some hosting plans suddenly having the next due date of the year 1999 or 2000. Very strange. We resolved the handful of products with that problem. It would appear this is not the only issue caused. Some customers are contacting us saying that they haven't received an invoice for their renewals. They only become aware that they are overdue when the account is suspended for non payment. (Personally I think this problem has been related to Modulesgarden's "Hosting renewals" module.) There have been no problems with the domains table. Anyway, so I look in the database and I find over 800 products that have the nextinvoicedate field set to 0000-00-00 - which is most definitely the cause of this issue. WHMCS is not generating invoices for these products (as you'd expect). So my questions, if anyone would be so kind to help.... 1. Does WHMCS always store the dates in the database as yyyy--mm-dd regardless of the date format chosen in the config? 2. Why would all of the due dates on all of the products get updated daily? Is this something that WHMCS does, or should I be looking at a cron hook within an addon causing this? 3. Could someone please be so kind as to offer me the correct syntax to set any "nextinvoicedate" that is currently set to "0000-00-00" to the same value as the "nextduedate" in the tblhosting table? Thanks very much in advance for any help you can offer.

A client just upgraded his plan and was invoiced with VAT in the normal way. Then he decided to downgrade back again almost immediately. He was credited, as we have that option enabled in the settings. I checked his credits and noticed that the refund did not include VAT, so he was 20% out of pocket. I also found this thread from 2014... I don't know if this was fixed at some point and then re-introduced in a more recent version (I'm using 7.6.1) or whether WHMCS decided there was some reason not to include VAT on downgrades and didn't fix it.

Ahh yes, in the Miscellaneous section there are two options that will set a client to inactive - Change client status based on active/inactive products and Change client status based on active/inactive products and not logged in for longer than 3 months I think it might be a good idea for WHMCS to highlight this in their documentation since they introduced the new customer retention option. Prior to this, it makes sense to set the status of any account to inactive if it has no active products or domains - but since they introduced it, any new client that hasn't yet purchased anything will get deleted within 24 hours of signing up! Hope this is useful for anyone else who finds themselves in this situation. Just switch to the option - Change client status based on active/inactive products and not logged in for longer than 3 months and that will prevent it happening.

It seems that since 7.5 the cron designed to delete inactive customers is also deleting new customers that have had no activity. We asked a client to create an account so she could take on a service from someone else. We couldn't find her account but she showed us a screenshot of her welcome Email showing she did indeed create one. I checked the logs... 25/09/2018 08:06 Client Deleted - ID: 10278 System 24/09/2018 09:47 Created Client redacted - User ID: 10278 System Our daily cron runs at 8am, so I can only assume that the account was deleted due to inactivity. We have the automation option " After no invoice or transaction activity has occurred for the following number of months: " set to 72 months - but I think there may be a problem with the way this is calculated and it might also include accounts that have never logged in. Its possible she created the account, received the Welcome Email and never logged into it. Perhaps if she had, the account wouldn't have been deleted. I wonder if anyone would mind seeing if they can reproduce this.

I don't agree and I don't think WHMCS should assume anything. There's too much hard coded "assumption" built into WHMCS that we can't change. I'd like the flexibility to allow the client to set the auto renewal period per domain whenever they want. That way, after the initial renewal, they could reduce or increase it as they liked. I suppose it's actually very simple to implement too. Just one field to update. If we put the decision in the hands of the client - it's one less thing for us to worry about.

Yes, that goes without saying. I suppose what I meant was that I'd prefer WHMCS not to remember the registration period from the first order at all - and default the auto renewal period simply to 1 year. As you say, the client can always add years to the registration manually whenever they want to. It would be very restrictive to reduce the maximum registration period down to 1 year. My main point is that it isn't common sense to assume the customer will want to renew their domain for the same number of years they originally registered it for, so WHMCS should really consider providing an option in the general settings to effectively disable this behaviour and assume a 1 year renewal period for auto invoicing. Yes I'm using it and I completely forgot that this was hooked into the daily cron. What I did was to run the /modules/addons/resellerclubmods_tools/cron/resellerclubmods_dompricesync.php cron to update the prices after I'd made some changes to our domain pricing - I noticed that the client pricing didn't get updated. I thought incorrectly that the dompricesync.php would do that - but it's actually a different process that handles this. So after all this, I realise now that all I need to do is force the daily cron - or just wait until tomorrow!

Yeah I've just seen that auto price calculator module. I tried the demo but got an access denied error. Can't believe there's no simple way to do this in WHMCS. It should be built in. I also don't agree with the way WHMCS stores the original number of years registered and invoices for that same period on renewal. It's reasonable to assume that you might reg a domain for an initial period but not want to renew it for the same number of years the next time. I think the default auto renewal "registration period" should be set to one year and then clients can always add as many years as they want manually. It seems the wrong way around to me. The other alternative would be to allow the client to set the auto renewal period themselves. Ideally, I'd like an option to fix the "registration period" to 1 year on all domains after the initial registration - or to completely disable this functionality - then (most importantly) I'd like an option to synchronize the domain prices with the current pricing in the tld config. I might get a 7 day trial of that module and see if it's any good.

Is there a better option than the "Bulk Pricing Updater" for keeping the prices of clients domains updated? Now that we sell dozens of different domain types, this tool is very difficult to use. Each tld you want to update has to be selected manually and the price entered manually - for each number of years. With 250 tld's that's 2500 individual price changes! Is there any other way? We pay for our domains in USD and sell in GBP. Domain prices are synced daily from the registrar into the WHMCS configuration - and can change regularly. That works fine for new registrations and manual renewals - but I would guess that any domains set to auto renew will be invoiced at the price the client paid when they purchased the domain (or whatever is showing in the client's account for each domain). I want to update the clients individual domain prices automatically to match the main prices in the TLD configuration. I'm astounded that there doesn't seem to be any way to keep these synchronized.

You've not properly explained how it works. I'm more confused now than when we started this conversation. Either way it all looks far too complicated. I like the way in WHMCS a client can enable or disable auto renew for a domain but still have the option to manually renew whenever they like. It works great. All I really want is the same option for hosting plans too. I think your addon has some great features but we wouldn't use most of them - and I'm sorry if this sounds unfair, but I've asked you some pretty straightforward questions and your replies just don't make any logical sense to me, so I don't think I could use your module. Thanks for your time anyway.

Really? That doesn't make sense at all. If you choose not to automatically renew something. It doesn't mean you don't wish to renew it. The client may want to renew the product manually. Do you not differentiate between automated and manual renewals? The client may also wish to renew their domain automatically, but not their hosting. In your above reply you said... Did you really mean that? Simply switching off automated renewals will do that for a domain (even f you don't want to?) and cancel the associated hosting service? Where is the logic in that? Domains and hosting are entirely different and should be independent. It looks like you've actually managed to make WHMCS even less user friendly and reduced the functionality of the auto renew process by a long way. How can you call it "enhanced" renewals when you've made it more restrictive?

Thanks for your detailed responses. I'm sorry but I'm still unclear about the reminders. Can you confirm that a client will still receive reminders to renew, even if auto renew is disabled for a service?

Ok but what if they have auto renew disabled? Will they still get a reminder? Imagine the scenario where a client is not sure if they want to renew so they switch off auto renew. They still need reminding that the product is due for renewal, even if they don't get invoiced for it. With standard WHMCS, you can renew a domain without an invoice but you also receive reminders regardless of whether an invoice exists. It seems logical to offer the same option for services too. Regarding payment type and cards etc... If I place an order though WHMCS and pay by card, that card gets added to my account, even if I didn't want that to happen. This is pretty bad. I am forced to login and go to billing > Manage Debit / Credit Card to manually remove it. Also, we know customers who really want to pay for different services with different cards or payment types - but in WHMCS there is no flexibility for this. They cannot add more than one card. The payment method is fixed for a particular service, depending on which method was used originally to pay for the order. This is not flexible. With most billing systems you can add different cards, different billing or invoice addresses and payment types. This has more of a requirement with WHMCS where many clients have clients of their own. It would make sense for the client to to associate a different contact or card with an individual product. The options in WHMCS currently are woefully inadequate. You can add contacts but you can't directly associate different contacts with different products, or have different billing methods or cards associated with each contact. You've completely re-written the invoicing system, so perhaps you can add in more functionality for contacts / addresses and multiple cards too? My final question is this... As you have totally rewritten the entire invoicing process, If I start to use your module - then I decide to remove it later - how will that affect the invoices, transactions etc etc that were generated during the time your module was installed? If it is removed, will everything still appear the same as if WHMCS itself had performed all those processes?

Thanks for your reply. Can you please explain the process relating to the auto renewal of services... Currently in WHMCS, invoices are generated for services automatically - and this can't be switched off unless the client chooses to manually cancel the product before the end of the term. With your system, can I specify that I do not want to auto renew a hosting plan? If so, can I do that before an invoice is raised or also after an invoice has already been raised, resulting in the invoice being cancelled? If you support the above, how is this achieved? Is it the same way as with domains? in that the invoice is simply not generated? Does your product include any enhancements for the choice of payment type? In WHMCS this is badly implemented - only one card can be added and it is added automatically without the customer's approval - and different payment methods can't be specified by the end user for different products. Does your module tackle any of these issues? Does your module have any support for product reminders? I might be wrong but I think WHMCS has no provision for sending reminders about services, although it does for domains. If a hosting plan has auto renew disabled, is there a mechanism to remind them to pay manually?

It looks like there have been some improvements to this module and I would consider trying it again. We used it a few years ago and it had too many problems, so I was forced to remove it. Would like to hear from folks who are successfully using this version and would like to hear some feedback about the new "all in one" domains and product pages. Do your customers like it? I'd also be interested to understand more about the functionality for auto renewing products. Specifically the option to disable and enable auto renew on hosting plans. This is a major feature missing from WHMCS and we have been using the Modulesgarden "Hosting Renewals" module. Unfortunately this module causes problems with the daily cron and we've found hosting plans where the next due date has been set to 00/00/0000 or the year has been set to 1999 or 2000 - and causing hosting plans to be suspended and terminated. We are looking for an alternative. I'd like to know how your module handles the renewal of hosting. Is it in the same way as domains? Where an invoice is simply not raised if auto renewal is disabled?

Does anyone know if it's ok to upload the 7.6 Nominet module to a 7.5 installation? I'm not ready to update to 7.6 yet and I missed the notifications about the TLS 1.2 requirement. Edit... That appears to have worked so far.