Jump to content

I propose a tax-free world


Kian

Recommended Posts

I'm opening this thread to ask for some help but I have no hope. The problem I'm trying to solve is so frustrating that even describing it is a frustrating experience. It's about Upgrades/Downgrades.

Preamble

For various reasons (tax regulations in force in several countries) I have to consider Add Funds invoices with tax. Normally when you want to add 100 € funds WHMCS issues a 100 € invoice. Customers pay their taxes when the credit is used to pay other invoices.

As I said earlier, this is wrong in several countries (please don't ask me to explain 😩) where you have to charge tax every single time you receive a payment. There are no exceptions to this rule. Now let me take Italy as example where VAT is 22%. When you add 100 € funds, the invoice must be corrected to 100 € + 22 € VAT = 122 € (or 81.97 € + 18.03 € VAT = 100 €). The customer has to pay 122 € (or 100 €) and receives 100 € (or 88.97  €). This way we're fine with taxes but when you solve a puzzle a new one spawns.

Every time customers use their VAT-free credit to pay invoices, we have to make sure that they don't pay taxes for credit otherwise they're going to pay taxes twice (when they Add Funds and Apply Credit). That means that we have to return/refund VAT. Let me show you an example. This is what WHMCS normally does:

  • Subtotal: 100 €
  • 22% VAT: 22 €
  • Credit: 122 €
  • Total Due: 0 €

This is what we're supposed to do:

  • Subtotal: 100 €
  • 22% VAT: 0 €
  • Credit: 100 €
  • Total Due: 0 €
  • Bonus: this invoice must be suppressed since it makes no sense (no payments involved)

Things get complicated when you have to deal with partial credit:

  • Subtotal: 100 €
  • 22% VAT: 22 €
  • Credit: 50 €
  • Total Due: 72 €

The Total Due and VAT are both wrong. In fact we have to recalculate tax on Subtotal minus Credit:

  • Subtotal: 100 €
  • 22% VAT: 11 €
  • Credit: 50 €
  • Total: 61 €

All this mess have to be applied every time an invoice is issued, updated, has a new transaction or credit applied. As you can imagine coding this thing hurts but we managed to solve it with 185 updates 😨

The problem

Now that you know the mechanics involved with credit balance, there's an hardcore problem that I can't solve. We have already wasted 2 weeks. As you probably know, when you Upgrade/Downgrade a product WHMCS does two things:

  • Refunds unused resources for the current cycle
  • Charges for the remainder of the cycle at the new price

Let me make an example. I want to remove Backup from my hosting package (-50 €) and add Antispam (+50 €). They're both Configurable Options. WHMCS issues the following invoice:

  • Subtotal: 50 €
  • 22% VAT: 11 €
  • Credit: 50 €
  • Total Due: 11 €

Too bad that Total Due and Tax are wrong. This is how it should be:

  • Subtotal: 0 €
  • 22% VAT: 0 €
  • Credit: 50 €
  • Total Due: 0 €
  • Bonus: invoice suppressed

Here's another example. This time let's suppose that it's -10 € and +50 €:

  • Subtotal: 50 €
  • 22% VAT: 11 €
  • Credit: 10 €
  • Total Due: 51 €

While it should be:

  • Subtotal: 40 €
  • 22% VAT: 8.8 €
  • Credit: 10 €
  • Total Due: 38.8 €

The problem is that there are no action hooks that allows to correct numbers. We have:

  • OrderProductUpgradeOverride which is cool but works only for Product Upgrades. There's no equivalent for Configurable Options Upgrades
  • InvoicePaid, UpdateInvoiceTotal, InvoiceCreated. None of them can be used since when they trigger tblorders.invoiceid is still "0" even if the invoice already exists hence I cannot select "refunds" details stored in tblupgrades
  • Another place where I could retreive refunds is tblcredit but WHMCS doesn't store any relid or useful description when it runs Upgrade/Downgrade

We're on a dead line with literally no possible solution apart from crazy ones that would require me to remove standard WHMCS Upgrade/Downgrade functionality (cool story) and reinvent it. Probably a new hook point could solve my problem but it scares me.

I have no idea why I keep putting myself in such awkward situations, fixing things that very few people even understand / care about. I should start designing templates. They're easy, everyone loves you, you get good reviews and you sleep peacefully 😅

Link to comment
Share on other sites

Yes, it's too late.

I can fix invoices fully paid by credit but the real problem is that customers are forced to pay more than they owe with real money. Okay, I can deal with it (issue invoice, add funds etc.) but it makes no sense when you have situations like the following one:

  • Customer owes you 68.93 euro
  • WHMCS wants 92.40 euro
  • You have to refund and invoice 23.47 euro injecting in 3 action hooks with scripts that are a nightmare to follow
Link to comment
Share on other sites

It shouldn't be necessary to hook our way out of this. We ran into the same issue a few years ago, and we ended up disabling the feature.

WHMCS should rewrite the entire thing so it's done correctly.

There's also another issue with VAT (although minor). If you have a total due amount that ends up in 23.425 (that's a decimal seperator, not 23 thousand...), WHMCS only calculates tax for 23.42. No rounding up, just removing the third decimal.
Example:

Sub total: 18.74
25.00% VAT: 4.68
WHMCS shows this as total due: 23.42
When in fact it should be shown as 23.425

As far as we know, it only happens when the third decimal is 5.

To be fair, the 25% VAT should have given 4.684 (and not just 4.68), but some of our client's have been nagging us about incorrect values on the invoices.

 

Link to comment
Share on other sites

1 hour ago, DennisHermannsen said:

It shouldn't be necessary to hook our way out of this. We ran into the same issue a few years ago, and we ended up disabling the feature.

I know the feeling. Sometimes it looks like the only option you have is to disable a feature.

1 hour ago, DennisHermannsen said:

There's also another issue with VAT (although minor). If you have a total due amount that ends up in 23.425 (that's a decimal seperator, not 23 thousand...), WHMCS only calculates tax for 23.42. No rounding up, just removing the third decimal.

I run into this problem a long time ago. It took us weeks of hard work to find a solution just because WHMCS was causing 0.01 cent* of tax evasion on invoices.

Edit: * nope! More precisely from 0.001 to 0.005

Edited by Kian
Link to comment
Share on other sites

It drives me crazy. As a customer, WHMCS wants me to pay 68.93 EUR. This is 100% correct.

okay.png.941438663cbead9a88131139b4490f7f.png

As soon as I click confirm, WHMCS no longer wants 68.93 EUR but 92.40 EUR instead.

not-okay.png.d4e8d12b5aac53f288d9ae3323f1212b.png

First screenshot

Total Due = (Total Debited - Total Credited) + 22%

in numbers

(163.2 - 106.7) + 22% = 68.93

Second screenshot

Total Due = (Total Debited + 22%) - Total Credited

in numbers

(163.2 + 22%) - 106.7 = 92.40

So...

Why should I pay extra 23.47 EUR for no reason? I am speachless. Am I missing something? Regardless of what is the right approach, WHMCS behavior is inconsistent.

The simple fix would be to include negative amounts instead of credit. This is what I'm trying to do but after 3 weeks of coding I got nothing.

 

Edited by Kian
Link to comment
Share on other sites

On 12/5/2019 at 7:07 PM, Kian said:

You have to refund and invoice 23.47 euro injecting in 3 action hooks with scripts that are a nightmare to follow

One day i was in a similar situation where every hook was too early or too late. It also had also to do with invoicing. I solved it pretty dirty with some hooks and I hope the system will work forever, because I completely lost track of this code mess.
Fortunately, this has now been running since about WHMCS v6.3 fairly maintenance-free. 

This has not really something to do with your problem, but i wish you good luck 😄

Link to comment
Share on other sites

56 minutes ago, string said:

One day i was in a similar situation where every hook was too early or too late. It also had also to do with invoicing. I solved it pretty dirty with some hooks and I hope the system will work forever, because I completely lost track of this code mess.

This looks like my daily routine since 2008.

At the moment I'm trying to intentionally cause a fatal error to stop WHMCS from issuing the invoice so that I can try to do something I still don't know.

Probably for the very 1st time I'll give up and next year I'll reconsider my view on WHMCS projects. It makes no sense that we have to invest weeks/months for such silly problems.

When you find the solution it's not even rewarding since you have already received 999 tickets with complaints and negative reviews. You can't even try to explain why it took so long because a) no one cares b) it takes 60 minutes c) very few people can understand what you say.

I'm probably done with billing and legal stuff. Every year there's something new and stupid (GDPR, cookie law, MOSS, electronic invoicing, Italy, Australia, San Marino, Vatican City, Tenerife, Canary Islands, invoicing, conditional rules, exceptions, accounting softwares, tax stamps and ACCOUNTANTS) and WHMCS doesn't help. It would be a lot easier with new hook points but the idea of opening so many feature requests where I need to explain taxation system, share my knowledge for free and wait is depressing.

 

Link to comment
Share on other sites

 
 
 
1
17 hours ago, string said:

One day i was in a similar situation where every hook was too early or too late.

When I will be declared Emperor of Universe, I'll  make a law that will require every WHMCS hook to be unencoded, in order to allow the poor developer:

  • to know that a certain hook exists
  • to modify its priority

Meanwhile, it would be a good thing if developers would put hooks declarations in clear code, leaving just the related function obfuscated.
That's to say., each module should have an unencoded hooks.php file with just, i.e.:

add_hook("InvoicePaidPreEmail",1,"function_to_do_something");
// function_to_do_something does some unuseful things

  function_to_do_something() will be defined elsewhere and obfuscated, but doing so the poor developer:

1 - knows that it exist

2 - can decide to remove the hook

3 - can decide to give it a priority different from "1" (BTW: have you ever seen any hook which has a priority different from "1" ?  🙄

Link to comment
Share on other sites

The idea of having customers and unknown developers playing with nuclear bombs (hooks) scares me to death.

 Below you can find the partial flowchart of 4 action hooks with 2 special "guests" (Admin/Client interface) and intruders (xxxPreEmail) that most of the times triggers simultaneously (kind of). What you see below is a how I handle just two events (overpayments and VAT returns). I'm not even mentioning hook priority and most of endpoints.

flux.thumb.png.9048b51a6064a60a910908506fef00ef.png

When I need to make a slight change, we sit in front of the monitor (2 developers) for hours following all steps until we reach the correct point only then we can start coding. Surely I'm not the best developer in the world but this mess is not intentional or due to my skills. This is where invoice-related hook points bring you. And if that wasn't bad enough, there are more trouble right around the corner thanks to taxation systems. Just look at how Australia's GST laws work for credit notes.

whmcs-australian-taxation-system-flowchart.png.f4491669cd4e838180b8241048831cab.png

Before you can start implementing this mess first you'll need to "teach" WHMCS what are ABN, GST, SBS, RCTI etc. and find your way in the jungle of hook points. It's like learning biology from books written in binary code. I'm probably done with this.

Edited by Kian
Link to comment
Share on other sites

Haha, the "LOL zone" made my day.

On 12/5/2019 at 5:30 PM, Kian said:

I should start designing templates. They're easy, everyone loves you, you get good reviews and you sleep peacefully 😅

Or don't create modules that will keep you awake all night long 😋

"Generate a fake ajax post to cheat WHMCS about redirect", these hacks sound like fun. Must be exhausting to test all workarounds on new WHMCS versions.

Link to comment
Share on other sites

4 hours ago, Kian said:

 The bad news is that they can't provide an ETA at the moment 😞 I'll wait.

AFAIK, the never provide an ETA.

Time kept to fix a bug may be:

  • very little: in a short time, you'll get an email with the patch
  • medium: wait for next WHMCS realease, maybe you'll find your bug fixed
  • never ...    😕
Link to comment
Share on other sites

  • 4 weeks later...

What's the point of syncing WHMCS invoices with external accounting softwares when the real problem is that WHMCS issues invoices that are wrong? I mean wrong amounts, tax calculation, rounding, refund and gigantic lacks of billing concepts.

I'll give you 6 examples taken from my book of examples:

  • WHMCS issues an invoice where VAT is required but missing since it doesn't understand that AddFunds invoices must be taxed. Instead of 122 euro (100 + 22 VAT) the client paid 100 and I have an invoice that makes no sense. Who's gonna pay 22 euro? Ghostbusters! 👻
  • WHMCS issues an invoice with VAT but it was not necessary since it doesn't understand the concept of Split Payment. If you happen to have Public Administrations as clients it's game over for you
  • State-owned companies... ouch
  • Credit notes... ouch
  • Refunds that make sense
  • Tax stamp
Edited by Kian
Link to comment
Share on other sites

18 hours ago, Kian said:

I'll give you 6 examples taken from my book of examples

I suspect there probably is a book too. 😮

i've said for years that they should get you directly involved to sort the mess out... at least to get the basic structure correct going forward in v8.

Link to comment
Share on other sites

On 1/14/2020 at 8:05 PM, Kian said:
  • Tax stamp

Tax stamp is just italian crazyness.
It makes sense as the emperor of Nowhere island forcing you to personally bring him a perforated shell jumping on one foot only for each invoice issued ... 🤣

Don't blame WHMCS about tax stamp because AFAIK any billing/accounting software in the world has issues in managing it... 

But for everything else you are completely right.

One little trick, which maybe will be helpful: ROUNDING.
Almost anywhere in the world small roundings are VAT free.
In Italy too ("fuori campo IVA"), and if you look at any italian water bill you'll find an easy rounding to + or - one full euro...
So no one will ever blame you for a 1 o 2 cents rounding in a single invoice...

About WHMCS invoicing mess: Have you ever thought of "stealing" the whole billing part from WHMCS?
That is: rename all the WHMCS documents "proforma", "order confirmation", or something like that ... and then you issue the real tax invoice in a  completely independent way
Thatìs to say:
- let WHMCS handle "billing" as he wants, but make his invoices "unofficial" (and you can also not have them sent to the customer)
- then take the WHMCS "invoice", completely redo the calculations as you need, adjust what needs to be adjusted, fill in and send the official invoice to the customer, and store it in your own table, completely separate from those of WHMCS
In this way, instead of having 1000 different hooks that intercept the work of WHMCS in various ways, you will operate on a unique and definitive situation, and much easier to control ... 

Just my two cents!!!!!   

Link to comment
Share on other sites

2 hours ago, Remitur said:

Tax stamp is just italian crazyness.

It's used also in other countries 😪 That's why last year I had to make it activable by companies from any country.

2 hours ago, Remitur said:

In Italy too ("fuori campo IVA"), and if you look at any italian water bill you'll find an easy rounding to + or - one full euro...
So no one will ever blame you for a 1 o 2 cents rounding in a single invoice... 

End-clients would kill you. People open PayPal dispute and threaten you for much less.

2 hours ago, Remitur said:

Have you ever thought of "stealing" the whole billing part from WHMCS?

[...]

In this way, instead of having 1000 different hooks that intercept the work of WHMCS in various ways

It makes sense but it would require 2000 action hooks 🤣

18 hours ago, brian! said:

i've said for years that they should get you directly involved to sort the mess out... at least to get the basic structure correct going forward in v8.

I'm shy 😁

Edited by Kian
Link to comment
Share on other sites

2 hours ago, Kian said:

It makes sense but it would require 2000 action hooks 🤣

No, just one hook and a cron.

The hook on InvoicePaid: you take the WHMCS invoice (that, thanks to some editing on invoice template, has been changed to a "order confirm"), and generate the "real", right invoice

The cron just to analize and check transactions during the last day, and check if everything is rightly reported in your system (to intercept, i.e., the recurring payments that WHMCS in certain circumstances assign to the original invoice of years ago...) and other erratic operations which should to be billed

Link to comment
Share on other sites

I wish it was like this but its not.

Let's say that you receive a payment for a VPS that costs 100 euro + 22% VAT from the following customer:

  • Italian
  • Public Administration
  • Split Payment

WHMCS doesn't know anything about cross out sentences. As result you forced your customer to pay 22 euro for VAT that was not due to Split Payment. Here are the consequences:

  • You charged 122 euro instead of 100
  • You issued an electronic invoice of 100 + 22% with Split Payment
  • Your customer (Public Administration) paid 22% to Revenue Agency and 22% to your company

At the end of the day the customer paid 144 euro instead of 122 and you stole 22 euro not from me or from my grandma but from State. What's the point of issuing the invoice correctly on a third-party platform when this mess happened? You'll need to refund 22 euro issuing a credit note followed by an electronic credit note that I can hardly imagine. But I can imagine a lot of unhappy Public Administrations, state-owned companies and corporations.

Here is another example. In WHMCS Add Funds invoices are something special. They're VAT-free for no damn reason. In most EU countries (but I'd say that it's the same everywhere!) you are not allowed to issue an invoice without VAT unless there's a valid reason (eg. VIES, extra-EU, Split Payment, credit usage, special tax regime...). The fact that you're adding funds doesn't make it special so here's the thing. A customer uploads 100 euro of credit and on my third-party platform I issue the correct invoice:

  • Subtotal 81.97 euro
  • Tax (22%) 18.03 euro
  • Total 100 euro

In the meantime on WHMCS the customer didn't pay VAT. Here are the consequences:

  • In 2020 WHMCS creates 18.03 euro of money out of nowhere
  • Toc toc... hello Mr. White I'm the Revenue Agency. We need to talk
  • Bonus distaster 1 🍬 In 2022 VAT raises from 22% to 23%
    • Payment received in 2020
    • I used 50% of 18.03 euro in 2021 with 22% VAT
    • I spend the rest in in 2022 wih 23% VAT
      • Bonus disaster 2 🍬 In Italy you're not allowed to postpone invoicing later than 12 days (if you have electronic invoicing) or 1 month for other countries (generally). Here we have 3 years of delay. If you are italian it means that you're going to pay a fine of 28 euro for each invoice if you report yourself to Revenue Agency or 250 euro if you don't say anything... for an invoice of 81.97 euro. Cool.

Go figure out how to fix this mess. I stop here but I cloud go on for days.

1 hour ago, Remitur said:

No, just one hook and a cron. The hook on InvoicePaid

Sadly not 🙁 as you can see from my first example we've two problems here: issue invoice correctly and charge the right amounts to end-customers. Having perfect invoices on an external system doesn't fix the problem with wrong amounts charged to customers.

1 hour ago, Remitur said:

Curiosity killed the cat but... what countries?!?  😵 

I remember India and Tunisia but I bet that there are more countries. I can't determine who is using it. Frankly I don't even know if it's true that they really need to use revenue stamps but customers asked to "unlock" this feature and I don't ask question. Italy and EU are enough for me. I don't need to find new problems.

 

Edited by Kian
Link to comment
Share on other sites

2 hours ago, Kian said:

At the end of the day the customer paid 144 euro instead of 122 and you stole 22 euro not from me or from my grandma but from State. 

No: you did not steal anything.
You simply get an higher payment: you can fix it two different ways:
1 - cash back the higher sum to the user (it's, i.e., what happens when any slovenian company goes to buy a chair in italian Ikea: they pay italian VAT, asks for the VIES invoice, Ikea issues the invoice and does a wire transfer of the VAT amount)
2 - bill the higher sum as "prepaid credit" (applying any VAT to it, if required), which the user will be free to use as usual (it's exactly what your module does when it find an overpayment) 

About your second example: a good thing of your module is the way it allows to manage the billing of prepaid credit (applying  the VAT to it).
If you pay TODAY 100 + IVA = 122 for 100 € of credit, both of us are fine, even if you are going to use that credit when the IVA will be rised to 35%... this because VAT has to be paid at the payment .
  

Link to comment
Share on other sites

39 minutes ago, Remitur said:

No: you did not steal anything.
You simply get an higher payment: you can fix it two different ways:

From my experience 99.99% of times PA refuses to pay and rejects the electronic invoice. Split Payment exists for a reason. Here is a very extreme example:

  • Italy: «I need to rent a datacenter for one of my universities»
  • You: «Sure, pay me 1.220.000 euro (1.000.000 + 220.000 VAT)»
  • Italy: «Done»
  • You: «Ops 🙁 my company is in bankruptcy. I'm out of business. I'm so unlucky!»
  • Italy: «I'm going to kill you!»
  • You: «You can't kill me, I'm an LTD! 😎»
  • Italy: «Damn it»
  • Public treasury: «Emh... what about my 220.000 euro? 😡»
  • You: «Bankruptcy»
  • Public treasury: «How dare you...»
  • You: «Bankruptcy»
  • Public treasury: «I know where you live...»
  • Public treasury: «BANKRUPTCY EVERYWHERE»
  • Italy: «Hey, Public treasury could you borrow me 1.220.000 euro?»
  • Public treasury: «Okay 😑»
  • Italy: «I need to rent a datacenter for one of my universities»
  • You: «Do you remember me? Let's do this again!»

Split Payment exists to avoid that Public Administrations pay VAT to a "man in the middle". You won't get any chance to refund VAT.

39 minutes ago, Remitur said:

If you pay TODAY 100 + IVA = 122 for 100 € of credit, both of us are fine, even if you are going to use that credit when the IVA will be rised to 35%... this because VAT has to be paid at the payment .

Yes, but it works because I fixed the whole thing (totals before the invoice is issued, the invoice itself and credit usage). You can't get it working just by creating the correct invoice on an external software. There's a lot to do both BEFORE and AFTER invoice issuing.

Edited by Kian
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • 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