Jump to content
Esi

Problem VAT calculation on whmcs 7.4

Recommended Posts

Hi,

i have seen a problem with VAT calculation in whmcs 7.4.1 version. As reported in image below, VATon 22% for this invoice need to be 3.54€ and not 3.53€ as reported becasue 16.07 x 22% = 3,5354 so ~ 3.54€ is correct as previous whmcs version. This kind of problem wasn't with last whmcs version 7.2.x .

Is it a bug? How is possible to solve it?

Thank you.

Regards

 

Schermata 2017-11-15 alle 11.50.57.png

Edited by Esi

Share this post


Link to post
Share on other sites

There's other problem, now all clients paid regularly 19.61€ for their all old invoices, have 0.01€ in their balance!

I need to solve it.
Thank you.
Regards

balance.png

Share this post


Link to post
Share on other sites
2 hours ago, Esi said:

Is it a bug? How is possible to solve it?

report it as a bug to WHMCS.

I can reproduce it locally (the first issue)...

9lOoGfG.png

I suppose it's possible it's calculating the VAT on each individual item, rounding and then totalling those rounded figures. :?:

6.11 x 22% = 1.3442 -> 1.34

9.96 x 22% = 2.1912 -> 2.19

2.19 + 1.34 = 3.53

but reporting it as a bug to WHMCS should tell you whether WHMCS consider it as an issue or not... if they do, they might release a hotfix for it, or add it to the next maintenance release.

Share this post


Link to post
Share on other sites

Hi and thank you for your answer. Normaly these items are both of them with vat to 22%, i think problema is caused with the approximation way. 22% of 16.07 is 3.5354 so till versione 7.2.x whmcs approximate it to 3.54 but now with 7.4.1 it changes to 3.53 and for me it is the real problem.

Share this post


Link to post
Share on other sites

Hi,

In version 7.4 the tax calculation route was refined somewhat. Whereas previously the tax was calculated on the sub-total, it is now calculated individually for on each line item and then added together to give the tax amount.

In this particular situation it does seem to result in a different result from previously. We have opened case #CORE-11833 for the development team to investigate this further.

  • Sad 1

Share this post


Link to post
Share on other sites
1 hour ago, WHMCS John said:

Hi,

In version 7.4 the tax calculation route was refined somewhat. Whereas previously the tax was calculated on the sub-total, it is now calculated individually for on each line item and then added together to give the tax amount.

In this particular situation it does seem to result in a different result from previously. We have opened case #CORE-11833 for the development team to investigate this further.

Hi,

i need to solve it immediately, can be modified only tax calculation route in my 7.4 whmcs version with older to solve it right now?

Thank you.

Share this post


Link to post
Share on other sites
19 hours ago, WHMCS John said:

In version 7.4 the tax calculation route was refined somewhat. Whereas previously the tax was calculated on the sub-total, it is now calculated individually for on each line item and then added together to give the tax amount.

and you didn't think to mention that in the v7.4 changelog or release notes?? how are we supposed to test these features when we don't even know they've been changed? :?:

17 hours ago, Esi said:

In this particular situation it does seem to result in a different result from previously.

err obviously it will - anyone vaguely familiar with maths will know it could introduce errors - i'm genuinely shocked this wasn't noticed during even the most rudimentary of development testing. :wall1:

18 hours ago, Esi said:

i need to solve it immediately, can be modified only tax calculation route in my 7.4 whmcs version with older to solve it right now?

WHMCS rarely exists on the "immediate" timescale - if they've opened a case, then they're likely looking at it, but no-one can tell you if a fix would be hours/days, weeks or months away... you won't know a fix is coming until it's released!

if you kept a copy of your files and database before upgrading to v7.4, you could downgrade back to v7.2 - but you may lose any new orders or changes since that database was backed up.

i'm reluctant to advise you to get a developer in to write an action hook to check/fix these tax values - frankly, you shouldn't need to... but I guess that depends on how long WHMCS are going to take to fix this issue.

Share this post


Link to post
Share on other sites

 

2 hours ago, brian! said:

and you didn't think to mention that in the v7.4 changelog or release notes?? how are we supposed to test these features when we don't even know they've been changed? :?:

If i haven't notice that they have changed their system tax calculation and they don't report it in changelog i can't invent it by my own.
 

2 hours ago, brian! said:

i'm reluctant to advise you to get a developer in to write an action hook to check/fix these tax values - frankly, you shouldn't need to... but I guess that depends on how long WHMCS are going to take to fix this issue.

Sure, but i don't know how could solve it....moreover whmcs have written me that don't think to change actual and newest their tax system!! But how many clients will be in the same my condition?

Share this post


Link to post
Share on other sites

Hi,

This change was introduced in case CORE-11500, this was in the initial beta release and therefore available during the entire testing cycle.

Some background to that case; in the past WHMCS used slightly different methods for handling tax calculations for orders with multiple taxable items. For the first order invoice we added all the taxable line items and then computed a single tax for that subtotal. For the recurring amount we computed the taxed amount for each taxable line item and then added this all together. Depending on the exact tax rates and item prices in some situation this could lead to a .01 difference between the two methods.

We decided that the more accurate method was to calculate the tax per line item, especially because this was the amount that was more visible to your customers and what they agreed to. We made the calculation consistent with purchase and renewal / recurring amounts. Therefore where WHMCS previous did two slightly different tax calculations in different places, it now does the same tax calculation in both.

As a result you will find that the tax calculation is more consistent throughout the WHMCS software. This is not something we intend to change again, so you can be confident that the calculations as they stand in 7.4 will continue to do so.

The issue here is that - in this particular edge case - where previously paid invoices are now displaying a different tax amount to that which was charged. Invoices generated after upgrading to 7.4 are not affected by this. The reason for this is that the calculation is done on the page load and displayed, rather than using the value stored in the tblinvoices record.

Therefore the tax amount which was charged is stored in the database and will be used in the generation of reports, so tax filings will continue to be accurate. However we certainly appropriate that invoice history should be accurate too, particularly if a tax investigation necessitated an individual review of each invoice.

This concludes the investigation work from case CORE-11833, so that has now been closed.

It is this display issue in such edge cases we intend to address, and as such have opened case CORE-11836 to scope, prioritise and implement a change to the way the tax amount is displayed on invoices in future.

Please stay tuned for updates.

 

  • Sad 1

Share this post


Link to post
Share on other sites

Hi John

On 17/11/2017 at 2:10 PM, WHMCS John said:

It is this display issue in such edge cases we intend to address, and as such have opened case CORE-11836 to scope, prioritise and implement a change to the way the tax amount is displayed on invoices in future.

 

do you have some news about it ? i can't see this case CORE-11836  in changelog.

 

thank you

Share this post


Link to post
Share on other sites

Same here!

 

Please release a Hotfix! The tax office has already warned me that i write wrong invoices. It threatens a penalty if I continue.

Share this post


Link to post
Share on other sites

A Fix for the Case CORE-11836 more than urgent. For Bugs like "GetProducts API does not return product data" or "Resend SSL Configuration Email email link incorrect" WHMCS is able to release a hotfix, but for a bug which can bring WHMCS's paying customers tax and possibly legal issues, nothing happens? That can not be serious!

@WHMCS John Is there any chance to get an fix or at least a news on the case? Or will WHMCS take our punishments if the tax office gets worse?

  • Like 2

Share this post


Link to post
Share on other sites

Hi @bady i don't know if whmcs will fix this our problem. Really i don't know it. Can you give me link to see that Case CORE-11836 is till open ? I don't find it.

 

Share this post


Link to post
Share on other sites
33 minutes ago, Esi said:

Can you give me link to see that Case CORE-11836 is till open ? I don't find it.

Only WHMCS can say if the case is still open or if the closed it without fixing. But I hope that WHMCS will fix it, a billing software which can't calc taxes correctly........ will lose clients.

Share this post


Link to post
Share on other sites

This is a critical bug, if WHMCS can not handle financial elements correctly, its not very good as a billing platform!

 

I also have this problem, but mine shows that invoice amount and the confirmation email amounts are different...

 

Share this post


Link to post
Share on other sites

Hi,

This was an intentional change made in response to reports by users that the invoice amount was different to that displayed on the order form summary. That in itself posed legal implications, as regulations in EU countries require the invoiced amount to match exactly the amount displayed during the order process. As such we switched from using two different methods to a single method in both places.

Due to these factors we do not currently intend to reverse this change or add the ability to choose between the two methods. However we are always open to user feedback, and if there was a demonstrable demand for this, then it's certainly something we could consider. I appreciate you reaching out in this thread, and I have noted your feedback on this matter. The best channel for us to judge wider demand for a change in the software's design is via our dedicated feature request website at http://requests.whmcs.com
I encourage you to suggest this as a new idea for comment and voting upon by other WHMCS users. The more popular a vote becomes, the more likely it is to be considered by our development team for potential inclusion in a future release.

  • Sad 1

Share this post


Link to post
Share on other sites

@WHMCS John We do not want the calculation to be reversed. We want to correct the incorrect calculation. WHMCS is a billing software and it may NOT be that the tax calculation has a cent difference to the actual amount.
And that's not the case for a request, this is a bug that needs to be fixed.

You wrote that is a EU regulation that the invoiced amount has to match the displayed amount of the order process, thats right. But it is also mandatory that the tax amount matches the total price, and WHMCS don't do this in some cases. If there are already legal changes then these should be completely implemented and not only half thought through.

  • Like 1

Share this post


Link to post
Share on other sites
What please do you write there?

The tax calculation is wrong, that is fact and a urgent bug! You want to tell me the EU says to you that your customers should evade taxes?

Share this post


Link to post
Share on other sites
41 minutes ago, WHMCS John said:

Hi,

This was an intentional change made in response to reports by users that the invoice amount was different to that displayed on the order form summary. That in itself posed legal implications, as regulations in EU countries require the invoiced amount to match exactly the amount displayed during the order process. As such we switched from using two different methods to a single method in both places.

Due to these factors we do not currently intend to reverse this change or add the ability to choose between the two methods. However we are always open to user feedback, and if there was a demonstrable demand for this, then it's certainly something we could consider. I appreciate you reaching out in this thread, and I have noted your feedback on this matter. The best channel for us to judge wider demand for a change in the software's design is via our dedicated feature request website at http://requests.whmcs.com
I encourage you to suggest this as a new idea for comment and voting upon by other WHMCS users. The more popular a vote becomes, the more likely it is to be considered by our development team for potential inclusion in a future release.

John,

You say this change has been implemented?

Can you explain why I am still getting Invoices showing different amounts to the confirmation emails?

Would be useful to get explanation, so that I can screen shot and show the tax office if they then raise this issue with my company.

I'm updated with version 7.4.2

 

Share this post


Link to post
Share on other sites
5 hours ago, bady said:

We do not want the calculation to be reversed. We want to correct the incorrect calculation. WHMCS is a billing software and it may NOT be that the tax calculation has a cent difference to the actual amount.
And that's not the case for a request, this is a bug that needs to be fixed.

I simply can't see how this can be a feature request - the calculation is wrong. aaah.gif

  • Like 2

Share this post


Link to post
Share on other sites

@WHMCS John

 

you see any different in the tax with the same price?

 

whmcs-tax1.thumb.jpeg.24fb38177fae5c1932d601430e0d9d2a.jpegwhmcs-tax2.thumb.jpg.dedfaaf4ab8826b6c6cd6750f274447b.jpg

 

You see now the Bug? Same price 7.50 but different tax!

Share this post


Link to post
Share on other sites

In my experience: this bug involved two invoices during one month.

I lost half an hour to understand where those damn 2 cents were missing.

Then I lost another hour trying to understand why.

Then I discovered this thread.

Then I lost another half an hour explaing to my accountant the reason of the problem, and why it could not be fixed... :wall1:

Share this post


Link to post
Share on other sites
On 15/11/2017 at 8:04 PM, WHMCS John said:

Whereas previously the tax was calculated on the sub-total, it is now calculated individually for on each line item and then added together to give the tax amount.

 

Tax rules almost everywhere in the world specify different.

And it's easy to understand the reason.

Assume I'm selling nails, and the price is 0,01 each plus VAT (20%)

So, if I'm going to sell 100 nails to a customer:

  • according to tax office, final price is 0,01 x 100 + VAT = 1,20
    (of these, 20 cents are taxes)
     
  • according to you, final price is (0,01 + VAT) x 100 = 1,00
    (with zero taxes)
    Very happy the customer, very unhappy the tax office...

Share this post


Link to post
Share on other sites

@WHMCS John

please tell me, if whmcs want to fix this Bug or not.

I only want a simply answer, Yes or No. Not more ...

So I know then if I wait for a fix, or I have to search for a new Hosting software that calculate the tax corretly. 

Edited by J-B

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

  • Similar Content

    • By Brandwise
      I am new to WHMCS and so I am not sure I have the same problem via installation, but I am having the Blank Screen when I try to place/complete an order to for domain names. I am using OpenSRS' Domain Pro module to connect to OpenSRS. When I try to add OpenSRSPro or complete and order it just hangs and I am told this blank screen is a PHP issue. I am wondering if deleting the above php files will help me or if the above advice is only good for the upgrade mentioned above.

      I tried to turn on error reporting and reproduce the error so I can get a better idea what the error is, but it still is going to blank screen. I am not getting any error reporting in the module either. I am not sure what else to check. Any tips would be appreciated.
    • By HarryAdney
      I've just noticed there are two VAT boxes in the client area (see image)
      I did have the EU VAT module installed, but after removing, they are both still showing.
      The client involved is marked as tax exempt.
      If I try to update any of the details on the my details page an error message is displayed:
      The following errors occurred:
      VAT is required VAT is required Any ideas?
      Thanks.
    • By xyzulu
      Just a small issue I noted with the upgrade.. /downloads.php wasn't updated during the auto upgrade.. the file that remained wasn't encoded with the newer ioncube loaders so I had to replace it with the downloads.php file from the full install before I could use php 7.1/7/2
       
      Apart from that, so far so good.
      Good work WHMCS and all the testers!
    • By linux4me
      I just did the upgrade from 7.4.2 to 7.5 on a system running PHP 7.0 and Ioncube Loader 10.1.0-22.17. I did have to upgrade Ioncube Loader prior to running the automatic upgrade, because I was using an older version. The upgrade said it completed successfully, and there were no error messages; however, now when I try to log on to WHMCS, I get a white screen with only this:
      Starting
      Loaded English Language File
      Loaded Other Language Files
      and then nothing. There are no error messages in the error logs, and no errors in the file where WHMCS is installed. Naturally, since I get nothing when I log in, I can't go into Setup -> General -> Other, and tick the box to display errors. I've tried clearing my cache, closed my browser completely and restarted, but all I can do is log in and then get the same screen.
      I used phpMyAdmin to go into tblconfiguration and set DisplayErrors to 1, but I don't get any error output on the page.
      I've gone through the list of articles on the troubleshooting page, and none seem to apply.
    • By LukeDouglas
      When attempting to upgrade WHMCS 7.0.1 to 7.4.2, I get this error message:
      Update Failed An error occurred that prevented the update from completing successfully. Unable to complete incremental updates: Unable to import the 7.1.0 Beta1 database file. Unable to import /home/xxxxxxxx/public_html/billing/resources/sql/upgrade710beta1.sql: SQLSTATE[42000]: Syntax error or access violation: 1044 Access denied for user 'xxxxxxxx_xxxxxxx'@'localhost' to database 'xxxxxxxx_whmcs_xxxxxxxxxx' Please try again and if the issue persists, please contact support. If I click the Configure Settings on the update page, I get this error:
       
      An error occurred while communicating with the server. Please try again.  
      PHPINFO - core:
      Core PHP Version 7.0.27 Directive Local Value Master Value allow_url_fopen On On allow_url_include On On arg_separator.input & & arg_separator.output & & auto_append_file no value no value auto_globals_jit On On auto_prepend_file no value no value browscap no value no value default_charset UTF-8 UTF-8 default_mimetype text/html text/html disable_classes no value no value disable_functions no value no value display_errors On Off display_startup_errors Off Off doc_root no value no value docref_ext no value no value docref_root no value no value enable_dl Off Off enable_post_data_reading On On error_append_string no value no value error_log error_log error_log error_prepend_string no value no value error_reporting 32759 32759 exit_on_timeout Off Off expose_php Off Off extension_dir /opt/cpanel/ea-php70/root/usr/lib64/php/modules /opt/cpanel/ea-php70/root/usr/lib64/php/modules file_uploads On On highlight.comment #FF8000 #FF8000 highlight.default #0000BB #0000BB highlight.html #000000 #000000 highlight.keyword #007700 #007700 highlight.string #DD0000 #DD0000 html_errors On On ignore_repeated_errors Off Off ignore_repeated_source Off Off ignore_user_abort Off Off implicit_flush Off Off include_path .:/opt/cpanel/ea-php70/root/usr/share/pear .:/opt/cpanel/ea-php70/root/usr/share/pear input_encoding no value no value internal_encoding no value no value log_errors On On log_errors_max_len 1024 1024 mail.add_x_header On On mail.force_extra_parameters no value no value mail.log no value no value max_execution_time 90 30 max_file_uploads 20 20 max_input_nesting_level 64 64 max_input_time 60 60 max_input_vars 1000 1000 memory_limit 384M 64M open_basedir no value no value output_buffering no value no value output_encoding no value no value output_handler no value no value post_max_size 64M 10M precision 14 14 realpath_cache_size 4096K 4096K realpath_cache_ttl 120 120 register_argc_argv On On report_memleaks On On report_zend_debug On On request_order GP GP sendmail_from no value no value sendmail_path /usr/sbin/sendmail -t -i /usr/sbin/sendmail -t -i serialize_precision 100 100 short_open_tag On On SMTP localhost localhost smtp_port 25 25 sql.safe_mode Off Off sys_temp_dir no value no value track_errors Off Off unserialize_callback_func no value no value upload_max_filesize 63M 10M upload_tmp_dir no value no value user_dir no value no value user_ini.cache_ttl 300 300 user_ini.filename .user.ini .user.ini variables_order GPCS GPCS xmlrpc_error_number 0 0 xmlrpc_errors Off Off zend.assertions -1 -1 zend.detect_unicode On On zend.enable_gc On On zend.multibyte Off Off zend.script_encoding no value no value This is an AutoSSL secured site.  I'm not sure if that is the issue.
      I need some feedback on what is the issue.
       
  • Recently Browsing   0 members

    No registered users viewing this page.

×

Important Information

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