Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


ju5t last won the day on March 12

ju5t had the most liked content!

Community Reputation

3 Neutral

About ju5t

  • Rank
    Junior Member
  1. Hi @WHMCS John, thanks for your reply but from where I'm sitting this is not quality service. Nobody answered between 7AM UTC and 10AM UTC. This is pretty much our morning gone as we're in the CET timezone. We were unable to raise any tickets as your systems were offline. When we finally could raise a ticket we received a standard reply to acknowledge the problem and the promise that we would be updated once the issue was resolved. This didn't happen. When we asked for an update it took your team 5 hours to respond with a standard text that gets copied and pasted to everyone. The last 2 replies were quick but don't answer my concerns about not wanting to write a public post mortem. I appreciate the fact that you believe support has been improved over the last 6 years and although I don't see this myself and my experiences are flakey at best, that's not the point here. I think your communication has been far from great during this major problem. Not wanting to write a public post mortem like other companies do feels to me as if you want to hide the issue under the carpet to avoid bad publicity. I don't see public post mortems that way, I see them as an invaluable tool to talk to your customers, say sorry and explain how you're going to do better in the future. Again, everyone understands that IT breaks, we've all been through it, but you have to communicate and that's not what you did, at least at the level I expect from a company your size.
  2. Your team didn't respond very fast to be honest. It took hours for them to acknowledge that there was a problem. There has been very limited communication and so far I have been denied an official reason for outage including steps on how you plan to prevent this in the future. Your team is downplaying the problem by using words as 'reduced availability' and 'degradation' for a major problem which I can't really appreciate. Your team also claims that service was restored at 12:30 UTC. We were still experiencing issues at 14:30 UTC. We already had a ticket open about the issue and it took 5 hours to respond with a standard answer. We're all working in IT so we know that things can go wrong. When it does, you need to solve the issue and communicate. You didn't, and still don't, communicate very well. My biggest problem is the fact that you were entirely off the grid when the problem occurred and didn't communicate out in the open when the issue was found. The communication of WHMCS has been very, very poor to say the least and the fact that your team denies to give a proper public explanation feels wrong. Sorry, I'm not impressed.
  3. In this case though, WHMCS is changing an invoice after it has been sent. If you take this to your comparison; it's a self-driving car that forces you to drive 170km/h, and although I doubt there are case laws about this yet, I assume the car manufacturer would be the one to change this (if you can't, and in the case of WHMCS, you have no choice). And I know you can change invoice records one way or another, that's besides the point, WHMCS shouldn't do it by itself. This isn't a binary discussion, it's not a case of true or false, I was merely making a suggestion which you seem to be taking as an offence. If that's the case I'm sorry, but that wasn't my intention. I don't agree. I'm giving feedback on a process that I think should be changed. You have solved it by changing your business process to proforma invoices which is great, as it helps your company, but we have another opinion. You don't seem to see this as feedback but as an attack on WHMCS (or yourself), it isn't. I just want a solution for a problem we've had in the last 8 years. Until now we've been able to work around it by developing custom add-ons that prevent certain situations from happening, but WHMCS keeps on adding features that are able to change invoices automatically. I don't think this is right as EU legislation is very clear about this. As I pointed out before: the change is only illegal if there is no reliable audit trail. Our accounting software doesn't allow you to change invoices. If you do want to make a change it forces you to do so in a way that creates an audit trail. Of course there are always ways around it but as I started this reply, that's not the point. We're not the only ones. It was raised over 4 years ago already: https://requests.whmcs.com/topic/prevent-invoices-from-being-changed. If you or anyone else has any EU laws or case laws that I'm not familiar with please share them, as again, this is feedback, it's not an attack. I'm more than happy to change my feedback if it turns out my understanding of EU legislation has been wrong.
  4. I'm not entirely sure what you're after. My question is not about how to run your business it's about WHMCS offering an option that hasn't been properly implemented. You seem to be looking for answers on how we decide to run our business and you're hinting that we should change that, but that's not what we want. Regardless of how you run your business, WHMCS allows you to make changes to invoices (in your case, for paid services) and that's illegal. It doesn't matter if you use proforma or not, once it becomes an invoice it shouldn't be possible to change it. It really is that simple. Again, we don't want to use proforma invoices, not now, not in the future. We want to be able to send standard invoices, as is currently possible already, and it should not be possible to change them, ever.
  5. This is not what you initially wrote down. You said that unpaid invoices are to be considered proforma and that's not true. I know the difference between the two, that's not why I'm pointing it out. WHMCS supports both invoices as well as proforma invoices. Their implementation of invoices is wrong. Even if you would use proforma invoices WHMCS allows you to change an invoice after it has been paid, this should stop. Either way, this entire question is not about what alternatives are out there, it's about the fact that we're using invoices (and not proforma invoices) and we don't want to change that. Our customers wouldn't understand. Proforma isn't common in a lot of European countries, definitely not in ours, when it comes to B2C. Yes. Exactly that. This is an edge case for us, it rarely happens, so we choose to send out invoices immediately. You pick out one example, but what about renewals? If you renew a service you are already providing the service and VAT is due. Do you immediately suspend the service when payment is due? We don't. We chase our customers if they don't pay. I know proforma is widely used for custom purposes but it's not very common in B2C transactions. Even in B2B it's not used often, at least not by the companies we work with. Again though, we don't want to use proforma invoices, it's not a solution, it's a workaround.
  6. Unpaid invoices aren't considered proforma invoices in the EU by default. An invoice sent via e-mail is a fiscal document and gives you a legal ground to chase a payment, proforma invoices don't. Also, as VAT is chargeable at the moment the service is supplied, not when an invoice is paid, it makes sense to use invoices for companies in the EU. The fact that WHMCS gives both options doesn't change the fact that it is illegal to remove or adjust invoices after they have been sent. It's illegal to change invoices because you are required to have a reliable audit trail. WHMCS just deletes information from an invoice. It doesn't make a credit note, it doesn't log the change, it's just gone. https://ec.europa.eu/taxation_customs/sites/taxation/files/resources/documents/taxation/vat/traders/invoicing_rules/explanatory_notes_en.pdf https://ec.europa.eu/taxation_customs/business/vat/eu-vat-rules-topic/chargeable-event-chargeability_en
  7. I'm confused. WHMCS has successfully implemented GDPR in time before the deadline but it still makes illegal changes to invoices after they have gone out to a customer. In 7.5 they have added another feature that does this. The domain redemption feature makes sense in a lot of ways. It should never remove the domain from an invoice when it expired though. I always get the idea that such features aren't given enough thought. This is the second time in under 6 months that a new feature causes problems. I'm really disappointed by this. It would be great if WHMCS would keep EU laws and regulations in mind when developing new features. For example, this means you can never, ever change an invoice after it has been sent.
  8. Unfortunately that's what it is these days. Let's hope WHMCS will pick up longstanding issues too.
  9. I just found there is an open request for this that hasn't received any traction in the last couple of years. https://requests.whmcs.com/topic/e-mail-template-preview I think it is vital to be able to debug your email messages properly without having to send a million test e-mails. I wonder how others are testing this at the moment. Is everyone just sending test emails to a user to see how an email behaves or are there tools that I have missed?
  10. This has a pretty big impact on us and the longer it takes for this release to be out the bigger of a problem it becomes. Why is it taking so long? I would appreciate a bit more openness about releases from WHMCS so we know what we can tell our customers aside from 'sorry, our supplier made a mistake'. As that story gets old and we're getting the blame.
  11. I ran a few tests on our test environment. Looks good. I didn't find any issues so far. I appreciate the quick resolution @WHMCS John!
  12. We're looking for a company that can develop a WHMCS template for us. Proven track record. We're looking for companies who have done this before. Maintainability. WHMCS upgrades should be possible without too much hassle. Git is a requirement. Simplicity. It needs to fit our corporate brand. Some features need to be removed. We prefer Sass. Our website is based on Sass too. Experienced in integrating 3rd party software / modules in WHMCS. We're not looking for just a header and footer integration. Do you have any recommendations?
  13. They are giving you two options. down to the nearest 0.1 p – for example, 86.76 p would be rounded down to 86.7 p; or to the nearest 1 p or 0.5 p – for example, 86.76 p would be rounded up to 87 p. WHMCS has chosen to round to the nearest penny. This is not necessarily incorrect but it should be an optional setting so you can choose where rounding should take place. Our accounting software for one can't deal with this change and I have asked them to provide us with a similar option, but to be fair, they haven't changed their VAT calculation in the middle of the game. @WHMCS John this is something WHMCS needs to address. I have also mentioned this in the conversation we had via email. Instead of proactively helping us to find a solution for this, for which I even offered to pay, we were told to get different accounting software. I don't feel like WHMCS is taking its customers very serious on this matter. Why is that?
  14. I was pointed at this post by WHMCS as we are having exactly the same problems as others have expressed already. I don't think there is much I can bring to the table apart from to further stress how ridiculous this change has been and how many problems it has been causing us. One thing I did find is that in our attempts to work around the issue by illegally changing the VAT-amount is that WHMCS puts it back when customers pay their bills. Yes. WHMCS forces this change throughout the application even at points where it should't. This leaves corrected invoices marked as unpaid with 1 to 20 cents or more depending on the number of lines on the invoice. Both changes were illegal and punishable by law, but hey, so far WHMCS doesn't seem to care much. You have taken two (for us) foreign accounting companies and based your decision on them to pick a standard. What kind of research is that? We were told to switch accounting software as a solution. After 8 years this is the only suggestion you get. This is absolutely shocking. As I've also pointed out in the ticket I raised with WHMCS we understand that calculating tax per invoice line is the way forward. There's nothing wrong with that. Though you should have made rounding tax at the invoice line level optional or something that can be adjusted through a hook or other means. You're leaving your customers to dry and that's something I don't appreciate after working with WHMCS for so long now. I'm really disappointed in how this case is being handled and the lack of priority it seemingly gets.
  15. Welcome to WHMCS.Community ju5t! We're glad you're here please take some time to familiarise yourself with the Community Rules & Guidelines and take a moment to introduce yourself to other WHMCS.Community members in the Introduce Yourself Board.


Important Information

By using this site, you agree to our Terms of Use & Guidelines