Jump to content
Esi

Problem VAT calculation on whmcs 7.4

Recommended Posts

let's take @Remitur's idea about nails at 0.01 each...

On 07/02/2018 at 12:59 AM, Remitur said:

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...

in the cart, it correctly shows the price including VAT...

rWnq4nt.png

yet when the invoice is generated, the VAT is 0.00... i've tested this on two v7.4.2 dev installations - one of mine and the Softaculous WHMCS Demo - both give the same error.

3Y1nD61.png

this is a 3-month old bug... I dread to think how many users are blissfully unaware of this occurring.... we can debate all day what features WHMCS should or should not have, but I would have thought the ability to calculate tax correctly and consistently isn't up for discussion. 49oa9Ad.gif

  • Like 1

Share this post


Link to post
Share on other sites

Hi all,

We appreciate that the change in the way the calculations are performed has caused some concern. Our team is reviewing the comments here regularly and will be continuing to evaluate the impacts of this change and any further changes that may be possible to ensure the accuracy and consistency of calculations.

The decision to change to calculating taxes per line item was made for a number of both technical and business reasons, as well as to bring parity to the way we calculate taxes and the way it is done by a number of leading accounting packages.  In addition this brings a level of consistency accross the various different areas of the product and gives us the foundation for more invoicing features and functionality we expect to introduce in the future for which this level of granularity will be important.

To address some of the points raised here directly:

@Esi and @brian!
When making this change, we evaluated the behaviour of a number of leading accounting packages. Having just re-created this scenario in two of those, I found it produced the same tax computation as you see in WHMCS. The taxes are calculated per line item, rounded on each item and then summed. This is what appears to be the established industry convention.

@J-B
We have been able to reproduce this rounding down issue when negative line items are manually added to an invoice. This has been assigned case CORE-11960 to ensure that it is rounded up when appropriate.
A hotfix has been produced and is available at: https://whmcs.community/topic/283901-core-11960-ensure-tax-is-rounded-up-for-negative-amount-line-items-when-applicable/
 
@Remitur and @brian!
I appreciate the point you are raising. However we feel the scenario of 100 line items of 0.01 each in reality is unlikely. Percentages of small numbers are always going to result in very small numbers. In such a scenario, what we would expect to see is a quantity configurable option used at the product level which would result in a single line item, with quantity 100, and value of $1.00, and the tax would then be calculated appropriately.

Please keep the feedback coming.
 

Share this post


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

In addition this brings a level of consistency across the various different areas of the product and gives us the foundation for more invoicing features and functionality we expect to introduce in the future for which this level of granularity will be important.

oh Lord... foundations built on quicksand never lead to solid buildings!

please get this stuff right now before you go any further with it.

40 minutes ago, WHMCS John said:

I appreciate the point you are raising. However we feel the scenario of 100 line items of 0.01 each in reality is unlikely. Percentages of small numbers are always going to result in very small numbers. In such a scenario, what we would expect to see is a quantity configurable option used at the product level which would result in a single line item, with quantity 100, and value of $1.00, and the tax would then be calculated appropriately.

I was doing that to save time and prove a point... i'm not going to sit here and test 101 permutations of line items to see if they all work correctly (especially when I can't see the code used) - I had assumed there were staff employed internally to do that sort of thing. :?:

I would have thought testing with unlikely events is perfectly legitimate and to be encouraged... you're not to know how others are using their WHMCS installs - they may be selling physical products and using quantities might seem a logical/simple solution... they're not necessarily going to know or want to use config options... least of all because they may naively assume that a billing solution could calculate VAT correctly under all circumstances - not just the "likely" ones. 9_9

let me repeat the example I gave you yesterday when I changed the product price to 1.01

QcJA2V3.png

4ugXBML.png

let's ignore for now that I think the VAT value shown in the cart is correct, why isn't the same VAT value used in the invoice?? all throughout this thread, you've been using the word CONSISTENCY, yet in an extreme case (apparently!), WHMCS is behaving in an inconsistent way.

if this glorious revolution of calculating the VAT is working correctly, shouldn't both values be the same ? you can argue they should be x or y - but they definitely shouldn't be both x AND y.

surely the only way they can be different is if they're being calculated using different methods... that's not consistency.... there shouldn't really be any scenarios where the price shown @ checkout is different from the invoice delivered just seconds later.

1 hour ago, WHMCS John said:

When making this change, we evaluated the behaviour of a number of leading accounting packages. Having just re-created this scenario in two of those, I found it produced the same tax computation as you see in WHMCS. The taxes are calculated per line item, rounded on each item and then summed. This is what appears to be the established industry convention.

out of curiosity, I quickly tried this on a leading online invoicing solution (which I can name if you want me to), and it calculates the VAT as it does in the WHMCS cart (correctly in my opinion), not the WHMCS invoice...

0DFmYgm.png

now it's probably pointless getting into a debate about which is the "correct" method (as I don't think we'll agree) - but surely whatever the circumstances, the values needs to be the same in both cart and invoice.

Share this post


Link to post
Share on other sites

Hi @brian!,

Thanks for your response. I've opened case #CORE-12008 to investigate the discrepancy between the order summary and invoices in this particular case.

Share this post


Link to post
Share on other sites

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.

Share this post


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

The decision to change to calculating taxes per line item was made for a number of both technical and business reasons, as well as to bring parity to the way we calculate taxes and the way it is done by a number of leading accounting packages.

Can you please specify what would be these "leading accounting packages"?
I've worked with a number of different accounting software, but never met anyone doing so...

About official rules on VAT calculation and rounding: each country has its own rules, but they're roughly consistent.

A brief reference:  http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A62007CJ0302

report that:

Quote

You may round down the total VAT payable on all goods and services shown on a VAT invoice to a whole penny. You can ignore any fraction of a penny.

That's to say: rounding has to be done only at invoice-evel, not to row-level.

But, if you want an (very unusual) rounding at row level. the same document specify that it's possible: but each row's VAT has to be rounded to 1/10 of penny. and the total amount in invoice may be later rounded to the nearest whole penny.

So, if you want keep WHMCS calculating VAT at row level, it can be done... but you need to modify the process in order to calculate one more decimal position for every single VAT amount: that's to say, not penny, but tenth of a penny; not cents, but tenth of a cent. 

Is it worthwhile?

I, as WHMCS user, never felt such a need...

Share this post


Link to post
Share on other sites
4 hours ago, Remitur said:

But, if you want an (very unusual) rounding at row level. the same document specify that it's possible: but each row's VAT has to be rounded to 1/10 of penny. and the total amount in invoice may be later rounded to the nearest whole penny.

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?

Share this post


Link to post
Share on other sites

Hi all,

Thanks for your continued feedback and discussion on this matter.

We understand this is an important issue for some users, and as such I'm pleased to advise that in version 7.5 RC1, a new option has been added to the Tax Rules page which will allow you to choose how tax is calculated by WHMCS throughout:

  • (Default)
  • Calculate based on collective sum of the taxable line items

The documentation for this is located at: https://docs.whmcs.com/Tax/VAT#Tax_Calculation_Method

 

This is a non-trivial change, so whilst 7.5 is in the pre-release testing phase we are keen to get as many people as possible to test out both modes, and ensure everything is working as you expect.

Therefore I invite all participants in this thread to install WHMCS 7.5 RC1 in a test environment and give it a thorough testing before stable release:

The pre-release testing phase is always your best opportunity to provide feedback for quick iteration before everything is locked in for the stable release, so please let us know!

 

  • Thanks 1

Share this post


Link to post
Share on other sites

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!

  • Thanks 1

Share this post


Link to post
Share on other sites

Dear WHMCS

Can you tell us when this fix will go live please?

A client just advised us that their invoice had calculated differently to usual by several pence.  When I checked I found that a number of our invoices this month are incorrect - whereas they've always calculated just fine.  There is now a discrepancy between what WHMCS calculates and what our accounting package calculates (FreeAgent - fairly mainstream!). 

It was very wrong of you to mess with the calculation unexpectedly on what is our live client-facing system.  It's also wrong to say that the change corrects things for us in the EU.  It's wrong for us too.  Who calculates the tax on a line by line basis?

Thought I was going mad until I discovered this thread.

Arrrgh!

Share this post


Link to post
Share on other sites

@wellend the changes for Tax Calculation option are part of the changes introduced in WHMCS 7.5.0 which is currently in RC status I don't have an exact stable release date at this time however it shouldn't be too far away.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

In his line as always WHMCS. When an error is involved, since time immemorial, its developer and CEO currently, it seems that he does not care much.

A question that is not tribal, as it is that an accounting program, made in Europe, does not even comply with European regulations, but not only that, it does not even comply with the most basic rules of rounding, and that provokes not a little problems, it is a question, to move forward in future versions.

The problem is that above, prices rise as if it were a super-pro software, and does not measure up. The pity, is that many of us have been years and years, and to migrate is complicated, but sooner or later, many of us will migrate.

Hopefully they solve this, and many other flaws in their wonderful system de-normalized databases.

  • Like 1

Share this post


Link to post
Share on other sites

@iserver I agree in that this was a real problem for us too.  But v7.5 is out now and does resolve this issue.  Since we upgraded we can now set the option correctly.

So sometimes people do care and things do get resolved!  
:o)

I'd like WHMCS to think harder about implementing alterations to financial calculations in the future though.  This particular problem was very foreseeable by anyone with a bit of basic accounts knowledge.

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