Jump to content

ju5t

Members
  • Content count

    28
  • Joined

  • Last visited

  • Days Won

    1

ju5t last won the day on March 12

ju5t had the most liked content!

Community Reputation

3 Neutral

About ju5t

  • Rank
    Junior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I've worked with WHMCS long enough to understand the perks of it. For people it's good to have a mind of their own, for systems, not really. WHMCS does things that it shouldn't do. I'm definitely trying to be an optimist here but a realist probably wouldn't bother discussing this at all. Which solution do you mean? Our current integration or overriding the Invoice-model? Your billing extension is 1000% more extensive than what I was suggesting. You can see the work that has been put into it. In essence I want to store invoices elsewhere. I can only assume that each invoice uses the \WHMCS\Billing\Invoice model. This model would have a few methods to initiate a new invoice, save and change it. Of course in reality it will be much more than that. Instead of storing the final result in the database it would be stored elsewhere -- if you could override it completely, that is.
  2. @brian! not sure if you are offended by what I wrote but if you are I'm sorry, it wasn't my intention. In fact I complimented you on how you've helped others. You could consider me a community newbie (point taken about this topic being in the wrong section), but WHMCS definitely isn't. You can't guess that though, I understand. Anyway, I guess you aren't very enthusiastic about my suggestion as you didn't comment on it at all, but that is exactly the kind of feedback I was after. I have no problem with 'hey that is a stupid suggestion'. In that case we'll live with the facts and that's it. If not, I'll take the time to gather what people wrote and put it in a feature request. Even if WHMCS doesn't do anything with it, it doesn't hurt to try. Fair enough, again, definitely not my intention but it's up to you.
  3. @brian! I know the pace at which WHMCS picks up feature requests. And I've seen you saying it to lots of people before too. I know you're trying to help (and frankly, I've seen awesome suggestions from you before) but in this case I'm not after 'hey WHMCS is pretty * when it comes to feature requests'. I just thought about something that could help us as a company and before I even bother to open a request, I thought I'd try it from a different angle and ask some people here first. @egrueda that's what we do at the moment, or similar at least. And you're 100% right that it's quick and easy. It has a few downsides. For example, you have to keep track of which invoice in your accounts belongs to an invoice in WHMCS. You could solve this by setting the `invoicenum` field in the database with the invoice id generated by your accounting software I guess but you would all sorts of hooks to make it clean (e.g. change it before the email goes out, etc.). As you often can't use the original invoice `id` in your accounting software, at least not in the EU as it's not allowed, you don't have much options. WHMCS makes changes to invoices at unexpected times. This feature would allow give you the opportunity to stop that, e.g. block `save()`-commands on existing invoices. Accounting software can process MT940 files. WHMCS can't. This means the old fashioned bank transfer has to be done twice. If you read the invoices from your accounting software in WHMCS, that problem is gone too. WHMCS isn't really ahead of the rest when it comes to invoices and accounting. And I completely understand that it's what they do. That's what accounting software is for. But if I want to send a UBL invoice, I can't. It's often the small things that are useful and WHMCS doesn't have them (and probably shouldn't write it either). Overall it helps to have a single source of truth. There are definitely downsides of using an API-based invoice model too. Downtime of the API being the biggest one. This is also why hooks aren't the best solution. If the API call fails you've lost that invoice. This is one of the reasons for https://requests.whmcs.com/topic/extend-the-module-queue-to-hooks-and-add-ons (and yea, it doesn't get much traction). The other you pointed out already, updates. Although I don't see much difference in writing hooks and all sorts of calls that depend on the internal structure of WHMCS and writing your own model, but you do have a point. And if not that its complexity would take some interest away.
  4. And replies like this kill discussions before they even start. Thanks.
  5. How long it takes for WHMCS to implement feature requests is besides the point. It's impossible for a developer to write this without the ability to override WHMCS\Billing\Invoice. Extending this class is not enough. We could throw development time at it but it would never integrate as neatly as I'm proposing.
  6. Everyone knows that WHMCS isn't meant to be or to replace your accounting software. There is no place for purchase orders, ledgers and other important aspects of accounting in WHMCS. Just to be sure, I'm not asking for it either. But I was thinking, would it be useful if WHMCS stores some data outside the WHMCS database? Invoices for example. If we could store invoices elsewhere and use that as the source of truth that would be helpful for some companies. I still want customers to manage and pay their invoices online from within WHMCS, it would just get its invoice data from somewhere else. You could make your own invoice page instead but that could affect automation settings or potentially stop from working and I don't want that. From a technical point of view we would like to override the WHMCS\Billing\Invoice class and implement the relevant methods for each action (e.g. ::find(100) should search the API of your accounting software instead of the database). A list of the methods it calls throughout WHMCS would help. If you decide to override WHMCS\Billing\Invoice and have other modules that depend on tblinvoices those other modules would be incompatible. I see the risk in that but if you don't override it everything would stay as it is. Before I raise a feature request I was hoping to get some feedback here so I can make the request as detailed as possible.
  7. ju5t

    Backups

    Ah right, sorry, I can see why this wasn't obvious from my initial post. We're offering R1soft at the moment. Every so often though we run into problems. This can be anything really. When it works it's great though I think it's always good to look out for alternatives. In the meantime I've had a look at Acronis but their minimum commitment is above our budget unfortunately.
  8. ju5t

    Backups

    Out of curiosity, what are most of you using to run your backups that integrates nicely into WHMCS?
  9. WHMCS does a decent job when it comes to VIES and MOSS. I think WHMCS' invoice changes have an impact on all companies no matter where they're from. I've illustrated that in my previous post. Companies in the EU will probably be affected more than others. I'm not asking them to implement a feature that's 'more or less the same in all countries', I'm asking them to add a feature that can stop automated changes. It's very specific. I'm not even talking about invoice changes you can make by hand. I don't expect them to create solutions for all rules and regulations local lawmakers find necessary, that would make the scope too large. It's a small change that solves a big problem for companies in the EU but also has its use for other companies around the world. And to be fair, Europe is quite a large portion of the world. It wouldn't hurt to follow some regulations here and there.
  10. Before this explodes into a discussion about when VAT is and isn't due; that's not the point I am trying to make. It's about whether or not WHMCS should change invoices automatically. I believe there are reasons not to do this no matter the country or continent you're from. Most changes are based on the assumption that customers always pay online. As much as I would like this, many of our customers still pay via bank transfer. If you send an email (even it's a proforma invoice) with the amount the customer is due and decide not to notify the customer of an automated change, customers will pay the wrong amount. I believe this can also happen when you e-mail PayPal links in your email. At the moment, customers are not informed and invoices are changed. This isn't a great experience for both ourselves as our customers. I think it makes more sense to create a new invoice for the additional fee(s), link it to the domain in case of the grace/redemption feature and inform the customer as it happens. If you process a bank transfer and the domain is not renewed because extra fees are due, let the customer know. I think that this benefits everyone, companies in the US, India and Europe but more importantly, the customer. I know WHMCS doesn't have a great track record and the general feeling is that most feature requests never see the light of day. For me that's not enough reason not to start a discussion. The more people talk about it, the more attention it may get from WHMCS.
  11. Don't get me wrong, I don't want WHMCS to replace our accounting software at all. And I don't want them to focus on the EU alone either. In essence all I'm looking for is a way to stop WHMCS from changing invoices automatically. The current grace/redemption feature is a great example of how this can go wrong. It will always change the original invoice, no matter if you choose to add the fees to an existing invoice or if you prefer a new invoice instead. Even when you go for a new invoice it removes the domain from the original invoice which is very confusing for us, but more importantly to the customer. I suggested to add a third option that complies with EU law -- and keeps the original functionality intact. We've been using WHMCS since 2010 after having used ModernBill in the years before that. We have been able to work around some of the quirks in the past. I don't think it is up to us to create work arounds for problems affecting so many others.
  12. Sorry, I misinterpreted your reference to proforma invoices in the sentence "It will be official only if it will be paid by the client" and thought you meant normal invoices -- but you are right. Our partial workaround is to export all invoices to our accounting software as soon as they are created. As our accounting software doesn't allow any changes so we've got most things covered. WHMCS can still change the invoices it has issued in its own system but at least we have some reference to fall back on. Customers can still pay too much or too little when WHMCS makes a change (e.g. when they pay via bank transfer based on an email they received while WHMCS has changed the invoice in the meantime) and that's taking up a lot of time lately. Unfortunately, even though this is on WHMCS' radar, nothing happens and we don't have much else we can do at this point.
  13. Wow, your font doesn't come out great on my screen. It's not easy on the eyes. VAT is chargeable at the moment the service is supplied, not when an invoice is paid. This is the case for every European country. I've referenced this article in a previous post but perhaps you've missed it: https://ec.europa.eu/taxation_customs/business/vat/eu-vat-rules-topic/chargeable-event-chargeability_en. A proforma invoice and not paying tax while you're providing a service is, unlike what you state in your post, not legal. You've provided a service that you should get paid for and therefore VAT is due. The current system of changing a proforma invoice into a fiscal document upon payment is not how it is dictated by European law. Even if proforma invoices were the solution (for the record: they're definitely not), they're not common or used at all by B2C or B2B service providers in The Netherlands and would be confusing for most customers. For some it's easy to say that you should teach your customers differently but that's not how we approach or deal with them. We're here to make it easier. The problem is the fact that WHMCS makes changes to invoices at its sole discretion. If a customer cancels a product on an unpaid invoice, this product is removed from the invoice, and that's not allowed. There are other cases too where WHMCS removes items from an invoice, resulting in customers either paying too little or too much. You could argue that proforma invoices can be used as a workaround but that would only be true if you haven't supplied the service yet. This essentially means you would have to suspend all services on the day the service is due for renewal. It's not the most customer friendly solution of all.
  14. 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.
  15. 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.
×

Important Information

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