1.6.0.10 - Testers Needed

[benjamin utterback]

Hello everyone!

 

   We have been working hard to improve the way PrestaShop handles Tax calculation and Rounding of decimal places. 

 

  We have a package that we are offering the Community to test. If you have had any issues with Tax Calculation and Rounding of prices (decimal places) then please download the testing package to test the fixes. I will then send you the testing package.

 

Also, I will tell you this now so that there are no surprises, these fixes will only be implemented in 1.6. No previous versions will have these fixes. If you have tax and rounding issues on 1.4 or 1.5, you would need to upgrade to have these fixes take effect.

 

I know that these tax and rounding issues are important to many of you. If you could please take the time to download the testing package and test if these changes work for you, it would mean so much to us.

 

Thank you all for your continued support through the first 5 months of PrestaShop 1.6.

 

 

Best Regards,

 

Benjamin 

 

UPDATE: there is a new package (date: September 18th) available further down this thread: http://www.prestashop.com/forums/topic/350813-tax-and-rounding-fixes-testers-needed/?p=1803073

[benjamin utterback]

Hello,

 

  This post is meant to explain the changes in the Rounding system in PrestaShop 1.6.0.10 in Preferences>General

 

   You are now offered a choice of Rounding "Types" depending on your local preference. 

 

• ITEM - Tax is calculated and rounded for each item. If an item is in the basket 4 times the corresponding tax is equal to 4 times the rounded tax amount for an item. 
   
  This is the calculation currently used in PrestaShop by default. 
  Example: I have in my cart, 4 identical items at $ 1.05 per piece, with a 19.6% Tax. Tax for these articles is then 4*rounded(1.05 * 19.6%).
  
  
   

• LINE - NEW: - VAT is calculated for all identical items together and then rounded. If there is the same item 4 times in the cart, the corresponding VAT is calculated based on the amount of 4 times the article, then rounded. 
  
  Example: I have in my cart 4 identical items at € 1.05 per piece, with a 19.6% VAT. VAT for these articles is then rounded (4 * 1.05 * 19.6%)
  
  
   
• TOTAL - NEW: - Tax is calculated based on the total amount . If there are multiple rates are applicable to the order, aggregation is performed by the tax rate. 
   
  Example: I have an item in my cart at $1.05  and two articles $ 3.49 with a Tax rate of 19.6%. The Tax for these items is then rounded ((1.05 + 2 * 3.49) * 19.6%).

 

 

We also have included new rounding "Modes". 

 

• Round up away from zero, when it is half way there: The classical rounding method. 1.5 rounds up to 2. 1.49 rounds down to 1. In PrestaShop, this is considered the “classical” rounding method and the one used by default.
• Round down towards zero, when it is half way there: This is basically always rounding down if it's at the halfway. Example: If its 1.5 it will be rounded down to 1. However, if it is 1.6, it will be rounded up to 2.
  
   
• Round towards the next even value:  This is when you round .5 to the nearest even number. So if it’s 23.5, it rounds to 24(even number). If it is 24.5 it rounds down to 24 (closest even number). This is a popular method of rounding for accounting in certain European countries.
• Round towards the next odd value:  This is when you round .5 to the nearest odd number. So if it’s 23.5, it rounds to 23(odd number). If it is 24.5 it rounds up to 25 (closest odd number).

 

• Round up to the nearest whole number: This is when no matter what, it rounds up to the nearest whole number. If its 1.1, it rounds to 2. If it's 1.9, it still rounds to 2.
• Round down to the nearest whole number: This is when no matter what, it rounds down to the nearest whole number. If its 1.1, it rounds to 1. If it's 1.9, it still rounds to 1.

 

 

Bellow is a screenshot. The top image represents how it is right now. The bottom two images represent the changes we made.

 

[asgllccb]

I'm confused by the "testing".  Is there something we should be getting to upload and test on a 1.6X test version to see if it works right, or is this more of a question/feedback opportunity for the proposed changes you noted?

[nnab]

One more suggestion is to have a field to define the decimals for unit pricing and total. The default is 2 decimals and so the value rounds to 2 decimals.

We need the rounding for the total with no decimals and need 2 decimals for the subtotals and unit pricing. 

Currently we need to modify the core to remove the decimals in total but during upgrade the updated code gets lost.

[benjamin utterback]

I'm confused by the "testing".  Is there something we should be getting to upload and test on a 1.6X test version to see if it works right, or is this more of a question/feedback opportunity for the proposed changes you noted?

 

Well, if you like the post, I send you the testing package. It's a full PrestaShop package but its not considered stable. Obviously it shouldn't be used for a live installation. It's just for the community to test out different scenarios on their own servers. I have sent you the package as well. 

[scorpionsworld]

One point of feedback before I start pushing pull request on github, the same point I made at the PS1.5 improvement feedback round...It's not an issue on how to round values but where to round.

Currently, values are rounded to 2 decimals to early. Especially between cart and order (at the point of order creation), values are even saved to the database in a rounded form. As I mentioned at the 1.5 feedback, values should only be rounded on display (E.g. frontoffice and invoice).

[nnab]

One point of feedback before I start pushing pull request on github, the same point I made at the PS1.5 improvement feedback round...It's not an issue on how to round values but where to round.

Currently, values are rounded to 2 decimals to early. Especially between cart and order (at the point of order creation), values are even saved to the database in a rounded form. As I mentioned at the 1.5 feedback, values should only be rounded on display (E.g. frontoffice and invoice).

Yes saving the values without rounding in db is needed. We too enter base pricing with 4 decimals so when tax gets added, it rounds to the nearest whole number or two decimals correctly. By rounding a 4 decimal to 2 decimal, the obsolute value changes for sub total and total and tax value is wrong for all invoices. Rounding on display (FO theme, BO and Invoice) would be best option to avoid errors and compliance issues with multiple country requirements. 

[parsifal]

One point of feedback before I start pushing pull request on github, the same point I made at the PS1.5 improvement feedback round...It's not an issue on how to round values but where to round.

Currently, values are rounded to 2 decimals to early. Especially between cart and order (at the point of order creation), values are even saved to the database in a rounded form. As I mentioned at the 1.5 feedback, values should only be rounded on display (E.g. frontoffice and invoice).

Exactly on point, scorpionsworld!

 

This especially affects wholesalers that sell low-cost products in very large quantities.

[scorpionsworld]

Benjamin, should I use the taxes branch or the 1.6 branch on Github to commit changes on the tax calculation issue?

[benjamin utterback]

Benjamin, should I use the taxes branch or the 1.6 branch on Github to commit changes on the tax calculation issue?

 

Hi, you should do the PR's on the 1.6 branch of GitHub

[scorpionsworld]

Hi, you should do the PR's on the 1.6 branch of GitHub

allright, i'll have some updated files ready this week

[cedricfontaine]

Does it modify the way tax works for Canada ?

For example, we would like to have tax detail on the shopping cart, and also to apply provincial tax by default.

[Xavier du Tertre]

Hi everyone,

 

We're moving in the right direction. With your help, we've fixed several bugs and there a new package that we can share with you, still for testing purposes. Here's what's been fixed since the package that Ben sent you on August, 14th: 

 

[+] BO : Adding last employee connection date

[*] MO : Fix #PSCSX-2949, if $display_column_xx not found in DB, use module settings instead of theme default value

[*] BO : Fix #PSCSX-3001, Automatically assign shop id if employee has access to only one shop

[*] FO : Fix #PSCSX-3026, Handle specific price for only one currency (product.js)

[-] CORE : Fix bug #PSCSX-3124, duplicates in conf table

[-] CORE : FixBug #PSCSX-3058 - simulate PHP 5.3 Half Round Mode

[-] CORE : Fix group used by Price::getPriceStatic() when id_customer is provided

[-] BO : Fix bug #PSCSX-3143, List ordering in module page redirects to modules list

[-] BO : Fix bug #PSCFV-12472 do not use PS_PRODUCT_PICTURE_MAX_SIZE for product image upload

[-] BO : Fix bug #PSCFV-12193, live edit url with virtual url

[-] BO : Fix PSCSX-2998 category tree with product import

[-] BO : Fix PSCSX-2850 can't remove default order statuses

[-] BO : Fix bug #PSCSX-3049, filters on AdminTaxRulesGroup

[-] BO : Fix the mail sent by customer service tab with the right link to answer

[-] BO : Fix bug #PSCSX-2987, #PSCFV-11624 datepicker

[-] BO : Fix PSCSX-1360 root category where id_parent != 1

[-] BO : Handle combinated taxes on AdminProducts

[-] BO : shop main url update

[-] FO : Fix bug #PSCSX-3135, bad post cache on authentication.js

[-] FO : Fix uniform mobile issue #PSCSX-1632

[-] FO : Fix the value of the wholesale price with combinations on order_detail table #PSCFV-8506

[-] FO : Fix PSCSX-623 width in function of nb column diplayed

[-] FO : FixBug #PSCSX-2893 - Wrong rowspan in shopping cart summary

 

Here's the download link for this new package for v1.6.0.10 which, thanks to you, is going to be the version that fixes all roundings and taxes issues: http://www.prestashop.com/download/private/85ab9cfd7e69ad5f9b46.zip

 

If you are still having with this new package the issues that you were having with roundings and taxes before, we would really appreciate that you report it:

• on the Forge if you simply want to describe the symptoms to our developers so they can fix it
• on Github if you want to commit changes directly to the 1.6 branch

[Tomin]

Great to hear, that there is some test package available for testing purposes at least for ps1.6

 

As there are lot of 1.5 users because of unsupported or custom modules, themesetc etc.. You should give some solution for 1.5 as well.

 

Off for testing...

[scorpionsworld]

Github pull request with my suggestions have been posted (finally)

Hope it helps

Edited September 1, 2014 by scorpionsworld (see edit history)

[Shano]

yes also support a solution for the 1.5.  our tax display for logged in customer in california is very confusing. 

[eleazar]

I really wonder what all these new rounding options should be good for. Okay, now we can choose between more arithmetical rounding methods. But makes this really any sense for a shop system - to choose e.g. Round towards the next odd value?

 

I'm not sure if the developers team did realize to date that this isn't about rounding algorithms in general, and not a problem of arithmetical rounding at all. As correct computation is a crucial issue of shop systems, the tax computation should be treated as a problem of banker's rounding, which is not synonymous to arithmetical rounding.

Let's talk about rounding methods.

When rounding down or up by convention, it may happen that the resulting number is not necessarily the closest to the original number.So the half-way number is either rounded up or down.

You could avoid this by always rounding .5 in the same direction when adding rounded values together. But this would result in a bias that grows with the amount of numbers you add together. This means: you got to minimize this bias. Maybe this is why PrestaShop now allows to choose Round towards the next even value. And trust me, if you don't want to be frustrated, you should choose this option and not the first (recommended) way!

Technically speaking rouding to the nearest is not synonymous with rounding to even. Using arithmetic with floating point numbers, the arithmetical rounding (or so called 'geodetic' rounding), however, means using a different computation method: Here each number is rounded to the nearest even. If the last number to be kept is a 0, 1, 2, 3 or 4, it is rounded down. If the last number to be kept is a 9, 8, 7, 6 or 5, followed by additional numbers that are not all zero, it shall be rounded up. If the number falls midway (or 5, followed by only zeros) it is rounded to the nearest value with an even (zero), rounding is such that the last number to be kept gets even. This is clearly defined in the Standard for Floating-Point Arithmetic (IEEE 754), section 4.

But this is a shop system, folks!

 

We're not talking about the best arithmetical rounding method, where of course you can always increase the accuracy - we're talking about prices! In Germany e.g. the banker's rounding applies to the DIN 1333 standard (and not to IEEE like the mathematical rounding).
Banker's rounding works like this: If the number in the first decimal place to be dropped is 0,1,2,3 or 4, then it is rounded down. If the number in the first decimal place to be dropped is 5, 6, 7, 8, or 9, then it is rounded up. It is different, however, when rounding down in Switzerland: In contrast to the German method it's always the first 2 decimal places to be dropped that matter.

To cut it short: It seems that the main tax bugs are gone,  when choosing Round to the next even value and the rounding type On the total  - but that there's still a difference in total product price of {total_products} and {product_tax_infos.total_amount} in the pdf invoice.

I did just a few tests yet, but I've got a notion that the problems aren't fully solved yet.

Edited September 7, 2014 by eleazar (see edit history)

[eleazar]

For future versions of Prestashop that hopefully find a better approach to tax computation Michael Boone's contribution to solve this problem may be helpful:
 

function bround($dVal,$iDec) {
// banker's style rounding or round-half-even
// (round down when even number is left of 5, otherwise round up)
// $dVal is value to round
// $iDec specifies number of decimal places to retain
static $dFuzz=0.00001; // to deal with floating-point precision loss
$iRoundup=0; // amount to round up by
$iSign=($dVal!=0.0) ? intval($dVal/abs($dVal)) : 1;
$dVal=abs($dVal);
// get decimal digit in question and amount to right of it as a fraction
$dWorking=$dVal*pow(10.0,$iDec+1)-floor($dVal*pow(10.0,$iDec))*10.0;
$iEvenOddDigit=floor($dVal*pow(10.0,$iDec))-floor($dVal*pow(10.0,$iDec-1))*10.0;
if (abs($dWorking-5.0)<$dFuzz) $iRoundup=($iEvenOddDigit & 1) ? 1 : 0;
else $iRoundup=($dWorking>5.0) ? 1 : 0;
return $iSign*((floor($dVal*pow(10.0,$iDec))+$iRoundup)/pow(10.0,$iDec));
}

It was first published in 2006 here and in 2009 at Github: https://github.com/sitengine/sitengine/blob/master/_Contrib/bankers-rounding.php

 

A short explanation for the so called Round-Half-Even (or Banker's Rounding) algorithm you will find in this clear introduction to rounding algorithms: http://www.clivemaxfield.com/diycalculator/popup-m-round.shtml#A1

Edited September 8, 2014 by eleazar (see edit history)

[PrestaShopaholic]

Is there an ETA for 1.6.0.10 Final?

[Lucas Cerdan]

Is there an ETA for 1.6.0.10 Final?

When we're confident the fixes won't break any store and solve most taxes related issues.

And that means we need your (the community's) feedback.

[PrestaShopaholic]

 

When we're confident the fixes won't break any store and solve most taxes related issues.

And that means we need your (the community's) feedback.

 

 

Aww, so no ETA.

 

Re the rounding discussion, I agree with eleazar when he says "but this is a shop system, folks!"

 

I'd opt to always round down prices & taxes, and round up discounts (perhaps not even to the nearest penny!). As for paying the correct amount of tax, I'd suggest to keep an automatic counter of the few (fractions of?) pennies you owe the taxman per transaction -- should be easy enough to program.

 

Your customers should always see you as a generous, fair business.

 

Thinking about it made me realize that I may wanna round down the invoice totals to .x5, maybe even round down cases like 9.96 -> 10.15 to 9.95 on total invoice amount (lower whole digit). For discounts, the opposite should occur. 9.86 -> 9.99 should be rounded up as $10.00 discount (for example), that way they see a bigger whole digit.

Edited September 9, 2014 by PrestaShopaholic (see edit history)

[tilkar9]

I ask for a solution for anterior versions too.

 

Thanks

[Guest]

 

I ask for a solution for anterior versions too.

 

Thanks

 

 

From the post post in this thread by Benjamin

 

Also, I will tell you this now so that there are no surprises, these fixes will only be implemented in 1.6. No previous versions will have these fixes. If you have tax and rounding issues on 1.4 or 1.5, you would need to upgrade to have these fixes take effect.

 

[Guest]

It is great to have these new features in the pipeline. However I would have thought that there is a standard "lawfull" way of calculating tax. Are we to have these options because there is no standard, or is it different in different countries?

[cedricfontaine]

It works for me for Canadian taxes.

 

But I'm still unable to have a payment with paypal usa module tax applied on the shipping. Please validate this commit 

https://github.com/PrestaShop/PrestaShop-modules/pull/359

[eleazar]

It is great to have these new features in the pipeline. However I would have thought that there is a standard "lawfull" way of calculating tax. Are we to have these options because there is no standard, or is it different in different countries?

 

There is of course a rounding standard - the financial rounding or Round-Half-Even method. In Germany we call this Kaufmännisches Runden (merchant's rounding), in English it is often called a bit unclear banker's rounding.The Excel method round(cell;dec) does e.g. commercial rounding.

 

We discussed this with one of the Prestashop developers two days ago at a Meetup in Cologne. I'm more then ever convinced these new options are needless and just confusing. You rather need an input field for the number of decimals to be rounded to. There are countries that don't need 2 decimals, but 0 or  1 decimal(s) e.g. are no option yet because 2 decimals are still hardcoded.

 

If the Prestashop 'think tank' in Paris will keep this new options feature, it'll be the best way to follow the suggestions in my previous post.

 

@Tomin, scorpionsworld, Shano, tilkar9

And what concerns a solution for anterior versions, did you know that this was one of the most wanted issues in voting to improve version 1.5 - and was moved on the quiet to votings for 1.6? (Honi soit qui mal y pense! ).

Anyway, I was involved in the development of a working solution for Prestashop 1.5x with correct tax computing. Have a look at the module GC German from the German developer Gurkcity that contains all the overrides for correct tax computing you need. And, most important, it alters the concerned database fields by increasing the number of decimals from .2 to .6 like it is done in the new beta. GC German is free and works like a charm.

 

 

I'd opt to always round down prices & taxes, and round up discounts (perhaps not even to the nearest penny!). As for paying the correct amount of tax, I'd suggest to keep an automatic counter of the few (fractions of?) pennies you owe the taxman per transaction -- should be easy enough to program.

 

Your customers should always see you as a generous, fair business.

 

Thinking about it made me realize that I may wanna round down the invoice totals to .x5, maybe even round down cases like 9.96 -> 10.15 to 9.95 on total invoice amount (lower whole digit). For discounts, the opposite should occur. 9.86 -> 9.99 should be rounded up as $10.00 discount (for example), that way they see a bigger whole digit.

 

 

Good idea, and I'd support this as Prestashop add-on. No offense, PrestaShopaholic, but this is no question of correct tax computing and shouldn't be mixed with this prob.

Edited September 12, 2014 by eleazar (see edit history)

[Guest]

Wish I understood this more fully. Just expected Prestashop to do what it should I suppose

 

Found this on the UK HMRC website, so what we need to know is does Prestashop comply with this now, or will it with these mods that are coming

 

http://customs.hmrc.gov.uk/channelsPortalWebApp/channelsPortalWebApp.portal?_nfpb=true&_pageLabel=pageVAT_ShowContent&id=HMCE_CL_001596&propertyType=document#P1493_117367

 

 

17.5 Calculation of VAT on invoices – rounding of amounts

Note: The concession in this paragraph to round down amounts of VAT is designed for invoice traders and applies only where the VAT charged to customers and the VAT paid to HMRC is the same. As a general rule, the concession to round down is not appropriate to retailers, who should see paragraph 17.6.

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.

17.5.1 Calculation based on lines of goods or services

If you wish to work out the VAT separately for a line of goods or services, which are included with other goods or services in the same invoice, you should calculate the separate amounts of VAT either by rounding:

• down to the nearest 0.1p - for example, 86.76p would be rounded down to 86.7p, or
• to the nearest 1p or 0.5p - for example, 86.76p would be rounded up to 87p.

Whatever you decide, you must be consistent.

The final total amount of VAT payable may be rounded down to the nearest whole penny.

 

[PrestaShopaholic]

No offense, PrestaShopaholic, but this is no question of correct tax computing and shouldn't be mixed with this prob.

 

Correct rounding isn't exclusive to tax computation. I stress again that if you opt to always round down taxes (as shown to be legal in the UK by haylau), then you should STILL round up your (percentage) discounts... In other words, the rounding shouldn't be a system-wide rounding selection. At the same time, if I'm the only one who thinks discounts should be rounded up, then yeah, everyone can ignore my suggestion. I like feeling special anyway.

[eleazar]

@PrestaShopaholic

Okaay , but this isn't the topic of this thread which deals with errors in the rounding methods of PrestaShop till this very day - and how to fix them.

 

I added a function yesterday to /classes/Tools.php at Github for more precision in tax computing when increasing quantity of products: https://github.com/Nobodaddy/PrestaShop/commit/7ed27fd1e47b2dac01f3e155656943e152c4eb35

Edited September 14, 2014 by eleazar (see edit history)

[Stefand]

@Prestashop

It's a shame that in version 1.5.x and 1.6.x this things happen. It saves prices with so much decimals in the database that it goes wrong. Product price x quantity  - quantity discount + tax = problem

I agree with scorpionsworld on this one. It's not only they way how to round, but where.

[PrestaShopaholic]

Is there a new test/beta version of 1.6.0.10, more recent than Benjamin Utterback's 8/27 test package? I dunno how to package these things myself directly from the source   but I believe more bugs were fixed these past few weeks.

[Xavier du Tertre]

Is there a new test/beta version of 1.6.0.10, more recent than Benjamin Utterback's 8/27 test package? I dunno how to package these things myself directly from the source   but I believe more bugs were fixed these past few weeks.

 

Here is an updated version of 1.6.0.10, from today 12pm.

http://www.prestashop.com/download/private/prestashop_1.6.0.10.zip

 

Thank you for testing!

[thepan]

Will the eu-payment api completely implemented with the next release? 

[PrestaShopaholic]

Here is an updated version of 1.6.0.10, from today 12pm.

 

Thanks for that! I'll give it a spin ASAP.

[pl.sabotinov]

Hello everybody,

 

( i am using ver. 1.5.4.1)

 

 i have read the topic and would like to ask few questions the presta team members regarding this new version.

1. Is this version going to support the work with 3 decimal places of the values for single price and also for additional shipping costs(it is important for me)? 

2. And if the version is going to support this, how will be solved the issue with the paypal module. I mean the paypal module (3.6.6) does require amounts with two decimal places. If the decimal places are more it returns error reports for invalid arguments(even if they are rounded to the second): row, total... So i suppose the paypal module should be modified to a new version for accepting this format of the numbers or the numbers should be formated before sending to it. So a new version is required. Are you going to make it. Or there is another option?

 

I am trying at the moment to do this, by changing the hardcode of the paypal files in paypal module for my version of presta. I have started also a topic for this issue: 

Sending 3 decimal places amount to Paypal module

So here comes my third question connected:

3. Is it possible to override the files in the modules/paypal/expresscheckout(sumbit.php, payment.php, process.php) in presta 1.5.4.1. So thus if i manage to find the solution it will be still possible to update the version in the future. I am asking it, because as far as i have read the convention for overriding - not all modules could be overriden in prestashop 1.5. Therefore if these files actually can not be, it is better for me to wait for the new version, and if this new version works with 3 decimal places and also Paypal does, to update my store and work with the new version, where the issue with 3 decimal places will be solved. 

So should i try further to change the code of the paypal files, or if they can not be overriden, it is better to wait for the update?

 

Excuse me if i haven't asked something correctly but as a newbie in prestashop, not all the functionality is completely clear to me at the moment?

 

regards,

[bellini13]

I'm lost here...  what is the point of asking for the community to test and provide feedback, and when they do there is not even a reply on the feedback or concerns.

 

It seems quite clear by reading this thread that the new 2 decimal rounding is not what is desired.  Yet there has not been a single response by Prestashop to that feedback. 

 

Is PS just going to ignore that feedback and release an 'enhanced' tax round system that no one wants?

[eleazar]

I'm lost here...  what is the point of asking for the community to test and provide feedback, and when they do there is not even a reply on the feedback or concerns.

 

It seems quite clear by reading this thread that the new 2 decimal rounding is not what is desired.  Yet there has not been a single response by Prestashop to that feedback. 

 

Is PS just going to ignore that feedback and release an 'enhanced' tax round system that no one wants?

 

 

Thumbs up!

 

However, it looks that way! Currently they seem to mark time. When comparing tools.php with respect to the rounding methods (previous and current version on github), you'll find out soon that they didn't change a single byte yet. Ok, one byte was changed in fact, but in function cleanNonUnicodeSupport.

I recently discussed this issue with one of the french developers and he told me, all these new rounding options were necessary 'to ensure backward compatibility'. Backward compatibility for what? Rounding to the next odd?

 

It's really frustrating! Don't get me wrong, I don't want to play improvements down, in cache management for instance. But there seems to be a lot of eye candy and step by step it's more difficult for me to find a clear rationale in the PrestaShop core development, except perhaps increasing bulky statistics and funny merchant expertise symbols - where you ask yourself, who needs this stuff anyway?

[eleazar]

Will the eu-payment api completely implemented with the next release? 

 

We didn't get a clear answer yet, but rather ... nope!

[Guest]

Personally, and I am sure I speak for the vast majority of sellers ( ) I do not care about rounding issues. I don't want options to change them because I would not know which to use. All I want is for one of the major players in e commerce software to calculate tax correctly!

 

I would have thought that is was a prerequisite for e commerce software. I am not a programmer, I am not an accountant, I am not a mathematician. I am a seller. 

 

Don't give me options, just give me a working system that calculates tax correctly and legally

[parsifal]

Don't give me options, just give me a working system that calculates tax correctly and legally

 

That's not so easily done, considering all the different countries and tax laws. Just saying...

[Guest]

That's not so easily done, considering all the different countries and tax laws. Just saying...

Hmm I fear you are correct. But I would have thought it should be part of the localisation packs.Surely if we import the "UK" localisation pack that includes the UK VAT rates then the least we can expect is for VAT to be calculated correctly

 

I love prestashop, but it does always seem that the only way it can work correctly is if you are also a programming wizard, and SEO specialist, and now an accountant all rolled into one. Whereas most of us are just sellers trusting that the package we have invested time and money on does what we expect it do do out of the box

 

Pipe dream, I know. 

[eleazar]

That's not so easily done, considering all the different countries and tax laws. Just saying...

 

Sorry for my persistance - but I'm afraid I can't agree with you.

 

It's clear as daylight that there are different countries with tax laws in the world. But what exactly do you mean by this statement? Maybe I'm wrong about it, but do you have any example for a country where the exact method of VAT computing itself is regulated by law? Or do you just mean the variety of tax rates?

 

As far as I understand this discussion, the issue isn't the variety of tax rates but rounding errors in Prestashop's computation methods. I suggest better not to mix errors in the calculation methods with different tax rates. You can easily calculate different vat with the same method, provided you have an input field for the decimal precision instead of defining a hardcoded 2-decimals solution which maybe ok for France, but is not even valid for all European countries, let alone global.

 

Can't help, but somehow I couldn't agree more to what haylau posted:

 

Personally, and I am sure I speak for the vast majority of sellers ( ) I do not care about rounding issues. I don't want options to change them because I would not know which to use. All I want is for one of the major players in e commerce software to calculate tax correctly!

 

I would have thought that is was a prerequisite for e commerce software. I am not a programmer, I am not an accountant, I am not a mathematician. I am a seller. 

 

Don't give me options, just give me a working system that calculates tax correctly and legally

 

I guess that most users believe that this should be the case.

[parsifal]

Sorry for my persistance - but I'm afraid I can't agree with you.

 

It's clear as daylight that there are different countries with tax laws in the world. But what exactly do you mean by this statement? Maybe I'm wrong about it, but do you have any example for a country where the exact method of VAT computing itself is regulated by law? Or do you just mean the variety of tax rates?

 

I think you missed my meaning. Although I do not claim to have extensive knowledge of tax systems around the world, it wouldn't strike me as odd if, for example, tax laws in a country stated that in an invoice, VAT should be calculated per line/SKU first and added in the end, whereas in another country you should add prices before tax and apply VAT in the end. Or if there should be differences in the rounding algorithm (or precision, as you hinted). Or if even inside the EU, transactions between VIES-registered businesses are handled differently in regards to tax charging.

 

Also, I don't agree with haylau's "figure it out for me automatically" mentality. Yes, PrestaShop should include all the necessary configurability to cater to the needs of as many tax scenarios as possible, and do it accurately according to the configuration I set. But I wouldn't seriously expect it nor rely on it to:

1. replace the advice of my accountant

2. reduce the complexity of running a business to "just selling"

Edited September 21, 2014 by parsifal (see edit history)

[Guest]

 

Also, I don't agree with haylau's "figure it out for me automatically" mentality. Yes, PrestaShop should include all the necessary configurability to cater to the needs of as many tax scenarios as possible, and do it accurately according to the configuration I set. But I wouldn't seriously expect it nor rely on it to:

1. replace the advice of my accountant

2. reduce the complexity of running a business to "just selling"

Looks like we will have to agree to disagree then.

 

Prestashop is an ecommerce system that pupports to deal with taxes. It does NOT say "we are an ecommerce system - but please be careful with our tax calculations as they may not be correct for your country, Even though we say you have a UK / USA / Greece / French localisation pack installed that gives you the options to select the VAT rates relevant to you,  we are not really sure how to calculate it in your country"

 

If we had that statement then YES we would expect to check it over, ask the accountants advice etc. 

 

But it does not. So surely we should take it as read that it is correct? 

 

Countries do have laws or specific ways to to calculate these things, certainly in the UK (http://www.prestashop.com/forums/topic/350813-16010-testers-needed/page-2?do=findComment&comment=1795779)

 

As there are specific rules I believe it should be possible as part of the localisation packs to include those rules

 

So then, instead of offering different rounding systems (or perhaps in addition to that - which is baffling to many users), when the localisation pack is installed it should be shown a statement such as

 

"UK localisation pack installed. This has two methods of calculating tax, Per line or per item). We have selected the more common per line method for you. Use the selector shown below to change this to per item if that is your preference"

 

I re-iterate that most users who install this software will TRUST that it is calculating tax correctly without question. Rightly or wrongly, that is the the way it is because most users are SELLERS, not accountants. They would only ask advise if they were not sure of something, but why would they doubt that tax was not being calculated correctly?

[bellini13]

At the end of the day though, you as the merchant and business owner are responsible and liable for doing business under the laws that govern you.  You should be responsible enough to know that the tools you are using actually work properly.

[eleazar]

I think you missed my meaning. Although I do not claim to have extensive knowledge of tax systems around the world, it wouldn't strike me as odd if, for example, tax laws in a country stated that in an invoice, VAT should be calculated per line/SKU first and added in the end, whereas in another country you should add prices before tax and apply VAT in the end. Or if there should be differences in the rounding algorithm (or precision, as you hinted). Or if even inside the EU, transactions between VIES-registered businesses are handled differently in regards to tax charging.

 

 

No offence, but it's a bit annoying to discuss problems with someone who on the one hand claims to be not well informed in particular and on the other hand doesn't get tired to put his beliefs forward as facts.

 

Anyway, it seems to me you still didn't get it. I did not talk about rounding types, but of computation errors in the rounding modes (or methods). If you don't understand the difference, please check the second post in this thread: http://www.prestashop.com/forums/topic/350813-16010-testers-needed/?do=findComment&comment=1768787

 

But the main point is:  Bugs in Prestashop have little to do with tax laws!

[parsifal]

I am truly sorry to have annoyed you.

 

You are right about the bugs of course, I wasn't arguing their existence or their nature. I was only voicing my skepticism about the expectation that PrestaShop should "automagically" (with minimal or no configuration by the user) handle tax calculations in many different scenarios and combinations.

[Tomin]

ok, lot of talking and no feedback on new version?

[PrestaShopaholic]

 

"UK localisation pack installed. This has two methods of calculating tax, Per line or per item). We have selected the more common per line method for you. Use the selector shown below to change this to per item if that is your preference"

 

I re-iterate that most users who install this software will TRUST that it is calculating tax correctly without question. Rightly or wrongly, that is the the way it is because most users are SELLERS, not accountants. They would only ask advise if they were not sure of something, but why would they doubt that tax was not being calculated correctly?

 

 

PrestaShop isn't QuickBooks, and certainly doesn't have the billions in cash that Intuit has to keep track of changing tax laws all over the world, nor to defend from damages caused by mistakenly picking the wrong tax calculation method for you. I, as a shop owner, don't even want them to bother trying, nor would I blindly trust what tax method they suggest ANYWAY (again, because they're not Intuit).

 

The most I'd want PrestaShop to do is send a link to some forum discussion where people say "I'm from country X, what should I pick?" and some other user responds the best he can, hopefully with a link to some non-stale official gov site. If they're both wrong, that's their problem for not googling enough or asking an accountant. Heck, I'd even prefer all users from country X to raise some fund (say $5 each) and buy an accountant's official statement (posted in the PrestaShop forum) on this and other matters that concern the users of country X...

 

Basically I prefer PrestaShop taking no risks, wasting no resources, and instead concentrate on fixing bugs and enhancing POWERFUL features.

[benjamin utterback]

Hello!

 

  Thank you all for testing out the new 1.6.0.10 taxing system. I know that we have been silent for a while, allowing you all to discuss ideas and possible solutions. We appreciate all the feedback you all have given us! Many of your ideas are along the same lines we have discussed internally. I will try and respond to most topics being discussed on this thread. 

 

First, there are a few suggestions about what we "should" be doing, when actually, it is exactly what we are doing. This is specifically regarding the options to choose at what step rounding is performed, at the item, line or total level.

 

1) --More Decimal Places

Many of you have asked for more decimal numbers for rounding. We heard you. We're implementing setting the number of decimals as a global preferences. For now, it will be a global setting. We may tie later to currency or country depending on your feedback. 

 

2) -- REMINDER These changes will not effect version 1.5

 

3) --We will gradually make changes to this tax system to better conform to various international law ie: EU, UK.

 

4) @eleazar, if you haven’t already, please make a Forge report detailing the precise test case regarding the different in total product price of {total_products} and{product_tax_infos.total_amount} in the pdf invoice.  Also, we will be comparing your other Banker’s rounding implementation with our implementation.

 

5)--Debate about the role of PrestaShop in choosing the computation method. Why have so many options?’

Indeed, there are many ways to do this. There are many lawful ways to compete taxes depending on the merchant. There is not one magic rule.

We do agree that having localization packs set up automatically is a good idea, we are looking into this. This will be a new feature and some sort of localization checklist.

 

6) Additional points

To the fine people willing to test the new tax system. We need bug reports if you find bugs. Anything else is purely speculative.

A bug report about the tax system must contain at least :

·         the details of the order

o    product prices

o    tax rates applied

o    product quantities ordered

o    discounts (if any), and type of discount

·         the result the merchant expects to see (for instance: X€ total tax at 19%, Y€ total tax at 5%, Z€ total tax, T€ total to pay tax included)

·         the result the merchant actually sees 

 

 

 

Thank you all for testing and continuing the discussion. Cheers

[eleazar]

@eleazar, if you haven’t already, please make a Forge report detailing the precise test case regarding the different in total product price of {total_products} and{product_tax_infos.total_amount} in the pdf invoice.  Also, we will be comparing your other Banker’s rounding implementation with our implementation.

 

Had a look at the test scores already that were made in Paris to compare both methods.

My feedback here and to the Prestashop team is: I don't hold that It makes sense, like it was performed, to compare rounding differences with test scripts containing numbers ranging from 1.99 to -1.99.

In my view this is unimportant. I guess that purely academic value comparing like this inhibited for years that the Prestashop team even realized that something went wrong.

You should always use a realistic test environment that takes into account real orders, which means higher quantities of items as a multiplicator for the unit price. Because this is where the rounding errors appear in everyday business.

 

Pars pro toto two invoices generated with 1.6.0.10, from my thread in the German forum where we discuss this issue. The first is generated using PrestaShop's original implementation, the second with overwritten function. Though this is a German language invoice you will realize the different values. You should focus on the values for total tax and total products (tax excl.). (Note that the shipping tax 1.90 € is not displayed in tax details, for some reason I don't know. If you add it to the value in tax details, it'll match the total tax in invoice #2.)

 

Prestashop 1.6.0.10 with original implementation of round-half-even method:

Rechnung ohne Fix.pdf

Prestashop 1.6.0.10 using override with bankers_round implementation:

Rechnung mit Fix.pdf

 

1) --More Decimal Places

Many of you have asked for more decimal numbers for rounding. We heard you. We're implementing setting the number of decimals as a global preferences. For now, it will be a global setting. We may tie later to currency or country depending on your feedback.

 

Just for the record: This wasn't a kind request to respond to but a crucial issue to avoid computation errors for the future!

 

3) --We will gradually make changes to this tax system to better conform to various international law ie: EU, UK.

 

For Europe (UK btw is a member of the EU ) we don't need 'gradually changes' but changes on the spot, because the European law that Prestashop doesn't conforms to became effective this June and it was well known since more than one year that this would come.

But nothing happened!

Quite the contrary: We currently have to adapt Prestashop to European law with overides because the deadline for a European law API was postponed again! And I understand your wording as a message that we cannot count on radical changes in release 1.6.1.

 

5)--Debate about the role of PrestaShop in choosing the computation method. Why have so many options?’

Indeed, there are many ways to do this. There are many lawful ways to compete taxes depending on the merchant. There is not one magic rule.

 

As I already posted here, it's not helpful to mix rounding types and rounding modes (or methods).

 

We do agree that having localization packs set up automatically is a good idea, we are looking into this. This will be a new feature and some sort of localization checklist.

 

Perfect! Is there already a deadline for this feature?

 

+++++++++++++++++++++++++++++++++++++++++

Off topic: Wouldn't it make sense to set a good example if the community manager follows his own forum rules?

 

Don’t yell

Yelling is painful to the ear, caps lock is painful to the eye. Use capital letters with moderation.

 

No offense, but I guess this rule includes a mix of bold face type and increased font size, doesn't it?

Edited September 26, 2014 by eleazar (see edit history)

[PrestaShopaholic]

 

As I already posted here, it's not helpful to mix rounding types and rounding modes (or methods).

 

 

I know the difference between rounding types and methods but your stand is still unclear to me. Are you saying only one rounding method is needed? If so, are you absolutely sure no country in the world mandates that tax owed at 12.451 must be rounded up to 12.46, for example? I

[eleazar]

Yes - and no.

 

I am pretty sure that you won't need but one rounding method for financial purposes in PrestaShop, the banker's rounding which I explained in this post. But you have to provide different rounding types, that's right.

 

And most important more decimal precision, like it is provided now in Prestashop where the concerned database fields were increased from 17.2 to 20.6 (I'm not sure if you will ever need 20 digits, but to avoid errors you need 6 instead of the former 2 decimals).

 

And there's urgent need for an additional input field for the number of decimals to round to instead of the hardcoded 2 decimals currently in Prestashop. Btw in Canada you need 3 decimals, the actual rate is 9.975%.

 

But all this doesn't affect the rounding method itself. The round-half-even or banker's rounding is the approved standard for financial rounding.

[PrestaShopaholic]

So you ARE saying that nowhere in the world they round (tax owed) 12.451 upwards to 12.46, for example...  

[eleazar]

So you ARE saying that nowhere in the world they round (tax owed) 12.451 upwards to 12.46, for example...

 

Depends if you round to tenth or round to hundredth and if you use the method og rounding up in any case. Look, we're talking at cross-purpose: You talk about the rounding rule, I talk about more accuracy in tax calculation.

 

For tax calculation you need minimum three parameters:

• The minimum accountable unit: the smallest unit a tax amount can have.
• The rounding rule: the method to use to round off taxes to the minimum accountable unit.
• The tax precision: a one-digit number that indicates the number of decimal places to which to calculate tax (A precision of 0 would indicate to round to a whole currency unit)

For example, to round off a calculated tax amount of 12.451 to 12.46, you would have to define a tax precision of 2, a rounding rule of Up, and a minimum accountable unit of .01.

 

Let's talk about real things. If you have any example of a country where currently decimals in sales taxes are always rounded up, then you should quote them. Just wildcatting isn't helpful in this case.

 

Sometimes it's just the other way round. In the USA there are a few states (like e.g. Alaska, Delaware, Montana, New Hampshire and Oregon) where the tax authorities do not allow to round the sales tax to the nearest penny. In this case you would define a tax precision of 2 and a minimum accountable unit of .00.

 

And btw one example for rounding up in any case was the US state Ohio. I said 'was' because this was abolished at the end of 2005! Currently they demand a tax precision of 3 digits:

 

 

"On and after January 1, 2006, a vendor shall compute the tax on each sale by multiplying the price by the aggregate rate of taxes in effect under sections 5739.02 and 5741.02, and sections 5739.021, 5739.023, 5739.026, 5741.021, 5741.022, and 5741.023 of the Revised Code. The computation shall be carried out to three decimal places. If the result is a fractional amount of a cent, the calculated tax shall be rounded to a whole cent using a method that rounds up to the next cent whenever the third decimal place is greater than four. A vendor may elect to compute the tax due on a transaction on an item or an invoice basis.

 

This change uses more traditional arithmetic rounding than the previous tax calculation method.  Instead of always rounding up in any case where the tax calculation yielded any fractional amount over a whole cent, the new method will round the calculation either up or down to the nearest whole cent based on the third decimal place.

 

Examples:

•  Sale amount $12.95, the tax rate 6.25%. The tax calculation would be $0.809375.  The third decimal place is greater than four so the tax would be rounded up to the next cent and would be $0.81.     
• Sale amount $14.35, the tax rate 6.5%.  The tax calculation would be $0.93275.  The third decimal place is less than four so the tax would be rounded to the nearest whole cent and would be $0.93.
• Sale amount $14.38, the tax rate 6.5%.  The tax calculation would be $0.9347.  The third decimal place is four so the tax would be rounded to the nearest whole cent and would be $.93.  (Note that the calculation is not to be rounded at the third decimal place, which in this case would have resulted in a calculation of $0.935 and a tax of $0.94.)"

http://www.tax.ohio.gov/sales_and_use/information_releases/st200505.aspx

 

Edited September 27, 2014 by eleazar (see edit history)

[thepan]

At the moment I am collecting scenarios that got calculated wrong in the past and check them against the latest changes in prestashop. I gonna create a check list that I plan to post here and keep up to date. If anyone would like to contribute that would be awesome.

[eleazar]

While we're at it ... in addition to my last post I just hope that everybody got the subtext, I mean the consequences:

 

The parameters minimum accountable unit, tax precision and rounding type may be different from one country to another (and in the USA do not even prevail for each state!), not to mention the rounding method, which may differ from common practice in European countries (though I'm not convinced it really does).

 

For example in the USA there are 10 tax exemption states (AK, AL, AR, AZ, CA, CO, CT, DC, DE and ... yes! ... Florida ). But for all other states and Canada the rule is: The taxes charged are based on the jurisdiction where the destination of the goods are delivered. And this includes the tax calculation!

 

And don't even think that this is totally different in Europe! If you overun a certain sales limit (between €35000 € and €100000 per year and country), B2C in Europe follows the same rule: taxes charged depend on the delivery address.

Anyway, considering all this the conclusion is that the current Prestashop 1.6.0.10 way of changes in tax calculation leads to a blind alley.

 

It's not only characterized by missing important configuration options, but in my view also implements the new feature at the wrong place. It would only make sense to implement a feature like this for countries or even states, but by no means as general preference, unless Prestashop abandons its highly ambitious claim to be a shop system for use in any country of the world.

Edited September 29, 2014 by eleazar (see edit history)

[djfm]

At the moment I am collecting scenarios that got calculated wrong in the past and check them against the latest changes in prestashop. I gonna create a check list that I plan to post here and keep up to date. If anyone would like to contribute that would be awesome.

 

That would be perfect!

 

Fore anyone interested, we're rolling out an automated testing framework: https://github.com/PrestaShop/PrestaShopAutomationFramework

 

It is still under development, but you can already have a look at what we can do in terms of invoice testing:

https://github.com/PrestaShop/PrestaShopAutomationFramework/tree/master/tests-available/InvoiceTest/examples

 

Each JSON file represents a scenario, and the engine is able to do the full order process as a customer would do, and check the results.

So if you can write examples that have the same structure we can include them in the automated testing process.

[Xavier du Tertre]

 

Off topic: Wouldn't it make sense to set a good example if the community manager follows his own forum rules?

 

No offense, but I guess this rule includes a mix of bold face type and increased font size, doesn't it?

 

Are you serious? Ben had quite a few questions to answer and points to address. He structured his post, that's it.

 

If your message was just off-beat humor, then don't mind my post

[eleazar]

@Xavier

However, this was the most unimportant issues of my posts. I'd prefer a feedback on the serious parts.

 

@fram

Hi François,

 

good job!

Currently free shipping seems to be fixed included by function getCarrierManager() - or did I get it wrong? Is there a possibility yet to calculate shipping costs and tax to the product amount and taxes?

And I guess a list of parameters (possible rounding types and modes) would be helpful as well as an option for defining the rounding precision which is currently hardcoded.

[PrestaShopaholic]

 Let's talk about real things. If you have any example of a country where currently decimals in sales taxes are always rounded up, then you should quote them. Just wildcatting isn't helpful in this case.

 

I didn't have an example then, because I went on a hunch that some places in the world will NOT give up on that fraction of a cent, and will want that extra penny (times tens of millions of transactions a day).

 

This link,

http://dor.myflorida.com/dor/taxes/sales_tax.html

sends you to this table:

http://dor.myflorida.com/dor/forms/current/dr2x.pdf

 

Straight off the bat, the second line on that table is for a $0.17 purchase at 6% sales tax, $0.0102 was rounded up to $0.02 in tax. 

 

For example in the USA there are 10 tax exemption states (AK, AL, AR, AZ, CA, CO, CT, DC, DE and ... yes! ... Florida ). 

 

Florida has a sales tax.

 

The following table is a little stale (2002), but I'm pretty sure some of the info there is still relevant to prove "rounding up" method needs to stay an option in PrestaShop....

 

http://www.streamlinedsalestax.org/uploads/downloads/IP%20Issue%20Papers/IP02007%20Rounding%20Rule.pdf

 

Ohio, Maryland, Vermont rounded up cent-fractions back in 2002. Other states that are listed in this table as using "a bracket system" naturally may also be inclined to round up, as was Florida's case.

 

My bottom line is this: you need MORE than just the banker's rounding contrary to what several of your posts suggest. But I agree with your notion that leaving options that aren't the law in any known place in the world will just confuse PS users and inevitably lead them to mistakes, even if warned.

 

Can anyone tell me in which place in the world these two options can be legally used?

* Round down towards zero, when it is half way there.

* Round towards the next odd value.

 

BTW, I consider myself pretty knowledgable and only today did I learn that in my state (Florida) we currently round up cent-fractions. I'm willing to bet the vast majority here don't know this either. The point? If I saw/"caught" some small merchant rounding up tax ($4.121 -> $4.13) I'd get the (unjustified) feeling he's cheating me a little.

 

Thus I still maintain that your customers should always see rounded-down fractions of cents for taxes ($4.129 -> $4.12), and you should make sure you keep a count on how much you legally still owe the taxman -- probably no more than a penny per order, if tax is calculated on total invoice amount.

Edited September 29, 2014 by PrestaShopaholic (see edit history)

[Stefand]

Is there any sight on the release date for 1.6.0.10 and if it solved the rounding issues?

[Lucas Cerdan]

Hi Stefand,

 

We're still working on some issues that have been reported by the community. No ETA yet.

Thanks,

[PrestaShopaholic]

For all the TL;DR short-attention-span crowd  I still wanted to know:

 

Can anyone tell me in which place in the world these two options can be legally used for sales tax/VAT purposes?

* Round down towards zero, when it is half way there.

* Round towards the next odd value.

 

Thanks.

[eleazar]

For all the TL;DR short-attention-span crowd  I still wanted to know:

 

Can anyone tell me in which place in the world these two options can be legally used for sales tax/VAT purposes?

* Round down towards zero, when it is half way there.

* Round towards the next odd value.

 

Thanks.

I guess your question is more than legitimate, PrestaShopaholic.

 

Just a side note to the topic:

 

Round up away from zero, when it is half way there (better known as Round half away from zero)

This method is often used for currency conversions and price roundings (when the amount is first converted into the smallest significant subdivision of the currency, such as cents of a dollar or euro).

 

But it's not used for tax calculation.

 

Round down towards zero, when it is half way there (better known as Round half towards zero)

This method treats positive and negative values symmetrically. Therefore it'ss free of overall bias if the original numbers are positive or negative with equal probability.

 

It's neither used for tax calculation.

 

Round towards the next odd value (better known as Round half to odd)

For a better understanding you first have to ignore Benjamin Utterback's as much simplified as misleading explanations and examples.

The mathematical formula is: If the fraction of y is 0.5, then q is the odd integer nearest to y.

Which means e.g., +23.5 becomes +23, as does +22.5; while −23.5 becomes −23, as does −22.5.

 

This variant is almost never used in computations, let alone in tax calculations.

 

Not to mention that the community manager's explanation for the most important of the new methods, Round towards the next even value, is unfortunately not correct as well:

 

Round towards the next even value: This is when you round .5 to the nearest even number. So if it’s 23.5, it rounds to 24(even number). If it is 24.5 it rounds down to 24 (closest even number). This is a popular method of rounding for accounting in certain European countries.

 

Don't get me wrong! I don't mean this statement as an explanation for a mathematical method normally called Round to nearest even - this is ok.

 

But is this an explanation for what Prestashop really does at this point? -  Nope!

 

Round down towards zero, Round towards the next even value, Round towards the next odd value - whatever option you choose here, when you check the Prestashop core of classes/Tools.php the bottom line is that all of them are processed the same way!

 

This process is what you are referring to when you speak of unbiased rounding, Gaussian Rounding or Banker's rounding. Like the previous method this method too treats positive and negative values symmetrically, there's no sign bias. But during the processing another function is called: function round_helper, where every digit >=  .5 is ceiled, and every digit < .5 is floored.

This rounding method is widely used in bookkeeping and hence important for tax calculation.

And the correct name is Round half even (in Prestashop core called PS_ROUND_HALF_EVEN).

 

This is why the real issue here should be how to optimize this PS_ROUND_HALF_EVEN method.

[PrestaShopaholic]

Round up away from zero, when it is half way there (better known as Round half away from zero)

This method is often used for currency conversions and price roundings (when the amount is first converted into the smallest significant subdivision of the currency, such as cents of a dollar or euro).

 

But it's not used for tax calculation.

 

 

It's used for tax calculation in the majority of states in the United States and I'd wager that also in at least a third of countries around the world.

 

Again, your stand that only one rounding method is needed is inconsistent with tax law around the world. It may feel unnatural to someone who's learnt in elementary school that proper rounding is "to the next even number", but to Americans (and many others) the ONLY rounding we'll EVER encounter in our lives here is "round half up" (as we call it).

 

The fact that there are PrestaShop bugs in the comprehensive implementation of specific rounding method is a completely different subject matter.

Edited October 7, 2014 by PrestaShopaholic (see edit history)

[eleazar]

It's used for tax calculation in the majority of states in the United States and I'd wager that also in at least a third of countries around the world. (...)

It may feel unnatural to someone who's learnt in elementary school that proper rounding is "to the next even number", but to Americans (and many others) the ONLY rounding we'll EVER encounter in our lives here is "round half up" (as we call it).

 

Ok, then feel free to use a tax calculation method that always rounds up. Your tax authority will rejoice.

In Europe where I live this isn't possible. And btw it makes no sense because as a merchant I'd loose money that way. This is why  merchants should know a bit more about cost accounting than they learned at elementary school.

 

Again, your stand that only one rounding method is needed ...

 

Nope, you should carefully read my post. I said that in fact Prestashop does primarily apply this method when you check the exact programmers' coding.

Edited October 7, 2014 by eleazar (see edit history)

[PrestaShopaholic]

 

Ok, then feel free to use a tax calculation method that always rounds up. Your tax authority will rejoice.

 

 

Your arguments have just left the realm of sanity. Are you saying that because in Europe you use Rounding Method 1 for VAT, then we in the USA should also use that rounding method for sales tax even though it'll be illegal to do so in every single state in the USA? 

 

I highly doubt you could find an American state where sales tax of $13.425000 is allowed to be "rounded to closest even" and collect & give the taxman only $13.42...

 

Hint:

http://www.streamlinedsalestax.org/uploads/downloads/IP%20Issue%20Papers/IP02007%20Rounding%20Rule.pdf

 

Luckily, the PrestaShop development team will most probably do what I do -- take all your suggestions with a 10-lbs box of salt.  

 

Re the code -- I don't care about the code ATM. Before you go code something, you first have to figure out which methods need to be supported in PrestaShop. You say just one rounding method (Utterback's "round towards the next even value"), while I say exactly four are needed (you could do it with three but for clarification it's better to use four). The other two ("round down towards zero, when it is half way there" and "round towards the next odd value") are most probably a waste of programming/support resources until proven otherwise. Still, I proved why your one method isn't enough with hard cold evidence...

[frank de beer]

I could be very wrong, so please dont flame me if so...

When i go to a supermarket and buy 10 cans of beer for 1,26 each, i pay 12.60. on the reciept it says 21% VAT = 2.19

at a wholesale the price is without 21% tax. 1 can of beer cost there 1.04. 10 cans = 10.40. I pay 12.58 incl 21% VAT (VAT is 2,18) on my invoice there. This is because they calculate the tax on the total amount of the invoice, and not on every article seperate, and the same in a store. 

For the tax authorities i only use the total tax-values on the invoices. these are the values i add up and sent to them 4 times a year. Not the taxes over every individual article i sell. 

so when i can deduct the VAT, i deduct 2.19 when i buy at a supermarket, and 2,18 when i buy at the wholesale, because these are the values on the reciept. This difference is caused by roundingeffects, but for the taxauthorities these differences are of no concern, because only the invoice counts.

I think this is a method most countries use. please tell me if i'm wrong.

 

so my conclusion is; calculate the taxes on the invoice over the total amount of the invoice, depending is it is a wholesale B2B store (articles calculated without VAT) or a B2C store (articles calculated including VAT) 

 

 

a thought about the discussion on rounding; if you dont need a method, dont use it. it's harmless if it's there but not used...

Edited October 8, 2014 by frank de beer (see edit history)

[Guest]

 

 

so my conclusion is; calculate the taxes on the invoice over the total amount of the invoice, depending is it is a wholesale B2B store (articles calculated without VAT) or a B2C store (articles calculated including VAT) 

 

 

 

That would not work for many people. For example, we use Royal mail and couriers for shipping. If we use ROyal Mail we cannot charge VAT, couriers we do charge VAT

 

Also there could be multiple types of products on the same invoice, some may attract VAT, others not

[frank de beer]

That would not work for many people. For example, we use Royal mail and couriers for shipping. If we use ROyal Mail we cannot charge VAT, couriers we do charge VAT

Almost the same in the netherlands, only we have to calculate BTW (VAT) over the whole amount including shippingcosts. even if they charge no BTW, like our PostNL. 

 

Also there could be multiple types of products on the same invoice, some may attract VAT, others not

 

Then stil it is possible to calculate the tax over the total amount.

add all products with 0%, all products with A%  and all products with B%, calculate the taxes for each group and add it all together on the invoice. 

 

 

I also think that the whole tax-calculation is solved when the prices are not rounded on 2 digits in the system, but on 4 digits or more. only for displaypurposes on the frontend and on the final invoice prices can be rounded on 2 digits

Edited October 8, 2014 by frank de beer (see edit history)

[Stefand]

Hi Prestashop team,

 

It is still a mess. It is still not working good with low price products and 21% tax situation here in the Netherlands. I will post my results here for the test that I run:

 

Product without tax: € 0.21

+ Tax 21%

Product with tax: € 0.25

 

Product with tax € 0.25 x 30 pieces = € 7.50 total.

That's good. Let's have a look on the invoice then, where the real problem appears:

 

It says:

Products without tax: € 6.30

Total tax 21%: € 1.20

Total: € 7.50

 

But that incorrect. It must be this:

Products without tax: € 6.20

Total tax 21%: € 1.30

Total: € 7.50

 

You see it's a difference of 0.10 !!!

I have tried the new rounding and counting methods in this 1.6.0.10 version, no method improved the situation in 1.6.

Edited October 8, 2014 by Stefand (see edit history)

[Pronux]

I think it is very difficult for the Prestashop team to understand / analyze the test results reported by us, because there is no standardized process. I would be very useful if we had some exactly defined test cases (sample orders) which we can reproduce in our localized stores and report back the errors (expected result / current test result).

[PrestaShopaholic]

but for the taxauthorities these differences are of no concern, because only the invoice counts.

 

If you (legally) collect tax on some invoice per item (your customer usually pays slightly more total in tax) then obviously you have to pass on that slightly higher amount to the taxman. If you (legally) collect tax to some other customer per total invoice then you'll need to pass on THAT more fair amount to the taxman since that's the amount you "borrowed" from your customer.

 

I think this is a method most countries use. please tell me if i'm wrong.

 

Some places allow you to choose per invoice (all taxable items) or per item tax calculation, some require one or the other exclusively (see my link for how different US states handle this differently).

 

If you have the choice, obviously you should use the cheapest one for your customers, which would normally be tax calculation on total invoice (all taxable items). If your locale allows you to always round down and calculate tax per item (UK?), then you should choose that one since it'll yield the lowest (legal) amount of tax collected from your customers.

 

a thought about the discussion on rounding; if you dont need a method, dont use it. it's harmless if it's there but not used...

 

It's not harmless to support rounding methods that cannot be legally used anywhere in the world -- in my opinion it's stupidity on numerous grounds (waste of coding time, support, testing, confusing merchants and their customers, wasting time for the community explaining to people why they shouldn't pick those useless options, etc). It's the same as suggesting that PrestaShop should allow the harmless option to display prices in hexadecimal format because maybe in some place across the universe some alien lifeform would select that option.

 

But that incorrect. It must be this:

Products without tax: € 6.20

 

How did your item price of € 0.21 all of a sudden drop to € 0.206666? If you calculate tax per item, don't show "total tax 21%", because it'll (almost) never be exactly 21%... You can't have it both ways.

 

If you insist on that "total tax" line, it should be something like "total item-by-item tax approx. 21%:  € 1.20" or "total line-item tax:  € 1.20". Or modify the code yourself to introduce that item price inconsistency because most people probably would prefer to keep things as they are, unless the law requires otherwise.

Edited October 9, 2014 by PrestaShopaholic (see edit history)

[Pronux]

21% on 12.60 is 2.646 so it should say 2.65 in most of the world (2.64 in the UK)

 

The difference between 2.65 and 2.18 isn't caused by rounding, but by the fact you paid less at wholesale.

 

I think 12.60 = 121% because the prices are always inclusive sales tax in the UK .... and also in the rest of the world..... yes, except in the US 

[PrestaShopaholic]

I think 12.60 = 121% because the prices are always inclusive sales tax in the UK .... and also in the rest of the world..... yes, except in the US 

 

Ahh! Makes much more sense now. Thanks for the correction.    I cut off just that part from my orig post.

 

But this poses an interesting problem.

 

If 10 beercans would have cost 12.59, then one beercan pre-tax is 12.59 / 1.21 / 10 = 1.0405 which is higher than 1.0400 and still results in a one cent lower after-tax price.

 

So lets find out the real price per beercan, pre-tax.

 

Range of after-tax total for 10 beercans: 12.595000 to 12.604999 -- any number in this range will round to 12.60

Lowest price for a pre-taxed can is 1.040910

Highest price for a pre-taxed can is 1.041735

 

Thus, it's very likely that the price of a pre-taxed beercan is, in fact, exactly 1.041, which is just one additional decimal necessary.

 

But this conflicts with the amount supposedly charged at wholesale for 10 beercans = 10.40, and not 10.41 like I've shown. That, to me, means only one thing: there's a bug in the system. It's either you use 1.041 per-unit-pre-tax for all calculations or you don't.

Edited October 9, 2014 by PrestaShopaholic (see edit history)

[eleazar]

I think it is very difficult for the Prestashop team to understand / analyze the test results reported by us, because there is no standardized process. I would be very useful if we had some exactly defined test cases (sample orders) which we can reproduce in our localized stores and report back the errors (expected result / current test result).

Perfect! Thumbs up! You should forward your suggestion to F. M. de Jouvencel. He's currently working on this issue. I guess he will appreciate your proposal. Though I suppose that he's watching this thread anyway ... better safe than sorry!

[frank de beer]

But this conflicts with the amount supposedly charged at wholesale for 10 beercans = 10.40, and not 10.41 like I've shown. That, to me, means only one thing: there's a bug in the system. It's either you use 1.041 per-unit-pre-tax for all calculations or you don't.

It's not the price of a product that is the problem here, but the rounding of the prices. With any x% of tax, you almost never get a nice rounded amount after calculation. consumer articles are mostley priced with a nice number, like 4.99 (looks cheaper then 5,-) and the price ex xx% VAT is calculated accordingly. (4,99 / 1,xx) where xx is the amount of VAT 

in this way you always get roundingdifferences like in my example. 

when you buy 1 can for 4,99, with 21% VAT, the price without VAT is 4.99/1.21=4.1239, rounded 4.12

when you buy 2 cans, 9.98 with 21% VAT, the price without VAT is 9.98/1.21=8.2479, rounded 8.25 (but 2 times 4.12 is 8,24)

difference is 0.01 ct

but when i calculete with 4 digits, like 4.1239 *2= 8.2478, you see the difference is only 0.0001 ct

you can buy many articles before you see a pricedifference of 1 ct now, and how higher the number of digits after the dot, the less the differences

 

This is the problem with prestashop and the TAX-calculation. is't not the method of rounding, tax-differences in every country or wathever is discussed here in this tread, it's the number of digits used in the calculations.

Now everything is rounded at 2 digits, but it should be at least 4 digits

Edited October 9, 2014 by frank de beer (see edit history)

[PrestaShopaholic]

when you buy 1 can for 4,99, with 21% VAT, the price without VAT is 4.99/1.21=4.1239, rounded 4.12

when you buy 2 cans, 9.98 with 21% VAT, the price without VAT is 9.98/1.21=8.2479, rounded 8.25

 

Doing math this way means a changing pre-tax per-unit value and that makes no sense to me. If that's how you have to do this BY LAW, then fine. But if it can be done legally in a more accurate and logical way, I'd opt for that.

 

If your after-tax unit price is 4.99, then your pre-tax unit price can be anywhere from 4.120 (4.985 / 1.21) to 4.128 (~4.995 / 1.21). Pick some value per your consistent preference (4.120 - always lowest, 4.128 always highest, 4.124 always average pre-tax unit price) and stick with it in all your future calculations.

 

but when i calculete with 4 digits, like 4.1239 *2= 8.2478, you see the difference is only 0.0001 ct

 

I don't understand why it matters if you calculate with 4 digits or not if you anyway first take the after-tax unit-price and multiply it. If your calculations are based on a possibly-rounded-after-tax-value which you blindly multiply to amplify the "error", then it makes no sense to now try and get an accurate per-unit pre-tax value after the fact...

Edited October 9, 2014 by PrestaShopaholic (see edit history)

[frank de beer]

I don't understand why it matters if you calculate with 4 digits or not if you anyway first take the after-tax unit-price and multiply it. If your calculations are based on a possibly-rounded-after-tax-value which you blindly multiply to amplify the "error", then it makes no sense to now try and get an accurate per-unit pre-tax value after the fact...

It matters a lot, if you want your invoice to be correct.

calculating with % almost always results in rounding to get 2 digits, but as you see in my example with the beercans, when you calculate with only 2 digits, you get differences in your invoice. in this case 1 ct to much tax. when you do this with many items, you can end up with a much larger difference. And this is wat happens with the tax-calculatings in prestashop. I had many invoices with wrong tax-calculations. Prestashop rounds to 2 digits through the whole system, but for acurate calculations it should be at least 4 digits

 

But this conflicts with the amount supposedly charged at wholesale for 10 beercans = 10.40, and not 10.41 like I've shown. That, to me, means only one thing: there's a bug in the system. It's either you use 1.041 per-unit-pre-tax for all calculations or you don't.

wrong here. 10.40 + 21% = 12.584 10.41+21%=12.5961, when rounded to 2 digits is becomes 12.58 and 12.60 this is a 2 ct difference!! but it is a bug yes

 

wholesale prices and consumerprices are 2 different things. the first is without salestax and the 2nd is with salestax, and they should be treated different for taxcalculations. there are a lot of wholesale shops who price their products with 3 or 4 digits, special the small priced products. On my shop i sell things for 0.03 ct a pc. and i would love to be able to price it with 0.029 or 0,031 so it wil be easier to give a discount on larger numbers.

Edited October 9, 2014 by frank de beer (see edit history)

[Perla2018]

There are also problems with smarty cacha index.php and smarty e compike which disappears

[PrestaShopaholic]

 

but for acurate calculations it should be at least 4 digits

 

No doubt there, in general all calculations should include at least 6 digits, which (in PHP/programming world) would mean using the standard floating point variable type which is commonly 14 total decimal digits with a decimal point someplace. But my point was that if you're using high accuracy on already rounded values (from "unknown" original values), then you're missing the point of high accuracy IMHO...

 

 

wholesale prices and consumerprices are 2 different things. the first is without salestax and the 2nd is with salestax, and they should be treated different for taxcalculations.

 

If you spoke about two different stores then OK. But from your example I gathered that the SAME STORE sold the SAME ITEM to customer A with VAT included, and to wholesale customer B with VAT excluded. If I'm right about that assumption, then 10 items at wholesale should never show as 10.40. They need to appear as 10.41...

 

On my shop i sell things for 0.03 ct a pc. and i would love to be able to price it with 0.029 or 0,031 so it wil be easier to give a discount on larger numbers.

 

Yes, I support that notion too. Internally (or visibly - per choice) prices should be stored with 4 decimal points: 0.0290 instead of 0.03. Anyone who's following this discussion will realize it's good not only for more granular discounts on small items, but also so that with-or-without VAT individual and total prices can be consistent throughout the calculations and invoice...

Edited October 10, 2014 by PrestaShopaholic (see edit history)

[frank de beer]

No doubt there, in general all calculations should include at least 6 digits, which (in PHP/programming world) would mean using the standard floating point variable type which is commonly 14 total decimal digits with a decimal point someplace. But my point was that if you're using high accuracy on already rounded values (from "unknown" original values), then you're missing the point of high accuracy IMHO...

 

Dont know what you mean here.. I think you're missing the point of the problem with prestashop. Prestashop does a terrible job in calculating prices, and this has to do with the way it rouds the prices. and in prestashop there are no 'unknown' values. you give the price of an article incl tax and prestashop calculates the price excl tax. and there it goes wrong.

 

 

 

If you spoke about two different stores then OK. But from your example I gathered that the SAME STORE sold the SAME ITEM to customer A with VAT included, and to wholesale customer B with VAT excluded. If I'm right about that assumption, then 10 items at wholesale should never show as 10.40. They need to appear as 10.41...

wrong, as i calculated in my last example. the final price still comes wrong. the price in this example should be 10,406

 

Yes, I support that notion too. Internally (or visibly - per choice) prices should be stored with 4 decimal points: 0.0290 instead of 0.03. Anyone who's following this discussion will realize it's good not only for more granular discounts on small items, but also so that with-or-without VAT individual and total prices can be consistent throughout the calculations and invoice...

and here we agree totaly

[PrestaShopaholic]

 

 in prestashop there are no 'unknown' values. you give the price of an article incl tax and prestashop calculates the price excl tax. and there it goes wrong.

 

If you start out with a 2-decimal price which includes tax (1.26), then the precise price excluding the tax is unknown. It can be a whole range. Unless there's a universal tax/consumer law that states 1.26 is the same as 1.2600 and can never be 1.2644 shown on signs and on receipts as 1.26 (for example), then 1.26 cannot automatically (always) be treated as 1.2600. As you can probably tell by my intensive discussions with eleazar  , I somewhat doubt there is such universal law, even in countries that mandate showing prices that include tax. I've got a hunch that there's some place in the world that mandates showing 1.26, but lets you arrive at that "posted legal price" by taking 1.045 unit price and adding 21% tax, then rounding down 1.26445 to 1.26...

 

On the other hand, if you start out with a 4-decimal price which includes tax (1.2600), then the precise price excluding the tax is very clear -- exactly 1.0413. It's not 1.0412 (+tax = 1.2599) and it's not 1.0414 (+tax = 1.2601)... So as long as your prices have 4+ decimals, then you're right, there are no unknowns.

 

 

 wrong, as i calculated in my last example. the final price still comes wrong. the price in this example should be 10,406

 

You're right that the unit-price (with or without tax) should indeed be 4-decimals so 10x unit-price should indeed have 3-decimals. But if 1 beer is 1.2600 incl tax, then 1 beer is 1.0413 excl tax, and 10 units at wholesale should be 10.413 (not 10.406). However, in my opinion you can show this weird-looking price on the invoice as the rounded 10.41 as long as in your invoice you show the full 4-decimal price (1.2600) the first time it's mentioned or used in calculations. This way anyone doing calculations will not be able to dispute your math, have some doubts about ranges, find inconsistencies etc. The rest of the numbers on the invoice (related to this item) can be shown rounded as they're based on that precise 4-decimal price.

 

Bottom line: PrestaShop should simply tell the merchants: "Enter before-tax or after-tax price with upto 4-decimals (xx -> xx.xxxx) -- e.g. you enter 299.99, it's stored and considered as 299.9900 in all calculations. You enter 42, it's stored as 42.0000". That way, Stefand will enter "0.2500" or just "0.25" for after-tax unit price as is customary in his locale to show tax-included prices and get the invoice to show just what he wanted:

 

 

Product without tax: € 0.21 (internally calculated and permanently stored as 0.2066 in database)

+ Tax 21%

Product with tax: € 0.2500 (not the ambiguous 0.25; no need to permanently store this value in database, it should always be calculated as 0.2066 + tax)

Product with tax: € 0.25 x 30 pieces = € 7.50 total (per-item rounding)

OR... Product with tax: € 0.2066 x 30 pieces + 1.30 = € 7.50 total (per-line rounding)

Total tax 21%: € 1.30

^ per-line rounding = rounded(30 * 0.2066 * 21%) = 1.30

OR... Total tax: € 1.20 (not 21%!!!)

^ per-item rounding = 30 * rounded(0.2066 * 21%) = 30 * 0.04 = 1.20

Products without tax: € 6.20 (per-line) or € 6.30 (per-item)

Total: € 7.50 (per-line and per-item)

[my modifications in bold]

 

Someone in another country will enter "0.2100" or "0.21" for before-tax unit price as is customary in their locale to show prices without tax, and they'll get the invoice to show exactly what they want:

 

 

Product without tax: € 0.2100 (not the ambiguous 0.21)

+ Tax 21%

Product with tax: € 0.25 (no need to permanently store the more precise 0.2541 value in database)

Product with tax: € 0.25 x 30 pieces = € 7.50 total (per-item rounding)

OR... Product with tax: € 0.2100 x 30 pieces + 1.32 = € 7.62 total (per-line rounding)

Total tax 21%: € 1.32

^ per-line rounding = rounded(30 * 0.2100 * 21%) = 1.32

OR... Total tax: € 1.20 (not 21%!!!)

^ per-item rounding = 30 * rounded(0.2100 * 21%) = 30 * 0.04 = 1.20

Products without tax: € 6.30 (per-line and per-item)

Total: € 7.62 (per-line) or € 7.50 (per-item)

[my modifications in bold]

 

Now again, if PrestaShop currently doesn't do the math correctly it's a whole different story. But before you even start with the math, you can't expect PrestaShop to know to pick 0.2100 or 0.2500 as the starting point for calculations. It's essential for PrestaShop to first and foremost know the full 4-decimal before-tax unit price (be it 0.2100 or 0.2066) in order to accurately perform all calculations (tax, discounts, same-item volume prices, multi-item grouping promotions, etc).

Edited October 10, 2014 by PrestaShopaholic (see edit history)

[Stefand]

@PrestaShopaholic Thanks for the reply. But I don't understand everything, because the replies talks about 2 examples I guess.

 

With my example, it can be solved by doing what?
Fill every product price (without tax) like: € 0.2100 ?

If that is the solution, if the customers has the price: € 0.21 in the input, why put the Prestashop software not the 00 behind it?

[frank de beer]

@ PrestaShopaholic,

have you ever tried to fill in a price for a product in Prestashop like 1,0413 in the ex-tax field? and did prestashop fill in the price incl tax of 1.2599 in the incl-tax field? (with 21% tax)

i think when you do so, you'll notice prestashop only accepts 2-digit prices. And this is why prestashop calculates the taxes wrong, and this is what this discussion is all about.

Edited October 12, 2014 by frank de beer (see edit history)

[frank de beer]

@PrestaShopaholic Thanks for the reply. But I don't understand everything, because the replies talks about 2 examples I guess.

 

With my example, it can be solved by doing what?

Fill every product price (without tax) like: € 0.2100 ?

If that is the solution, if the customers has the price: € 0.21 in the input, why put the Prestashop software not the 00 behind it?

At this moment, there is no solution for this problem in prestashop, but they are working on it. I hope they solve it with the next release.

no mather what price you fill in, the problem is that prestashop rounds at 2 digits. in the calculating examples you can see that this results in wrong calculations of the taxes

Edited October 12, 2014 by frank de beer (see edit history)

[PrestaShopaholic]

With my example, it can be solved by doing what?

Fill every product price (without tax) like: € 0.2100 ?

If that is the solution, if the customers has the price: € 0.21 in the input, why put the Prestashop software not the 00 behind it?

 

Definitely not enter price without tax as 0.2100, as that'll always give you an invoice that states "products without tax: 6.30" which you specifically don't want to see. Look at my post; it shows what'll happen (mathematically) if you start with 0.21 (0.2100) excl tax or 0.25 (0.2500) incl tax with all the rounding types.

 

For your solution, PrestaShop should be fixed to allow you to enter a price without tax of 0.2066, or it should make it easier for you and allow you to enter a price with tax of 0.25 (understood to be 0.2500) and PrestaShop will auto-calculate the before tax to be 0.2066 (not 0.21 or 0.2100).

 

 

have you ever tried to fill in a price for a product in Prestashop like 1,0413 in the ex-tax field? and did prestashop fill in the price incl tax of 1.2599 in the incl-tax field? (with 21% tax)

 

1.0413 + 21% = 1.259973 = 1.2600 rounded in most countries. I guess in the UK (and other always-round-down places) 1.2600 incl-tax should be calculated and stored in database as 1.0414 excl tax.

 

But yes, I know PrestaShop isn't storing prices with enough precision (4-decimals) and that's the first step to solve everyone's tax-math problems. Only then we can start talking about testing each (useful) rounding method with each rounding type. Without STORED 4-decimals for excl-tax prices, we'll be wasting time expecting reasonably accurate invoices.

Edited October 12, 2014 by PrestaShopaholic (see edit history)

[eleazar]

Definitely not enter price without tax as 0.2100, as that'll always give you an invoice that states "products without tax: 6.30" which you specifically don't want to see. ???

(...)

1.0413 + 21% = 1.259973 = 1.2600 rounded in most countries.   I guess in the UK (and other always-round-down places) ???

(...)

But yes, I know PrestaShop isn't storing prices with enough precision (4-decimals)  Really? As far as I know Prestashop does!

 

O! My! God!

 

This guy is unbelievable! Endless bla bla bla, absolutely unteachable, permanent unscrutinized conjectures, the main issues seem to deep for him - and he doesn't even realize it!

 

Please do me a favour, PrestaShopaholic: Do anything else. Go out playing in your elementary school yard and leave the adults alone. Whatever! But please ... please ... stop it!

 

In this thread you are a real pain in the neck!

[Stefand]

Sorry, maybe everyone is just searching for a solution. I'm just post here my results to solve this huge tax/rounding problem with Prestashop. I have already 1 client that will leave soon, because of this issue.

[PrestaShopaholic]

 

Definitely not enter price without tax as 0.2100, as that'll always give you an invoice that states "products without tax: 6.30" which you specifically don't want to see. ???

 

How about you do the math and show me how a unit price without tax of 0.2100 can show an invoice of "products without tax: 6.20" for 30 units sold which is Stefand's request...

 

I guess in the UK (and other always-round-down places) ???"

 

Read Haylau's post #27 in this discussion. In the UK, 1.260094 (1.0414 + 21%) is rounded to 1.2600. That's always-round-down.

 

But yes, I know PrestaShop isn't storing prices with enough precision (4-decimals)  Really? As far as I know Prestashop does!

 

See Frank's post from today about 2-decimal input. If you can enter only 0.21 and it's stored as 0.2100, or when you enter 0.25 with tax it's stored as 0.2100 without tax, instead of what you really need, 0.2066 without tax, then there's still a problem with properly storing the price...

 

Re the obnoxious tone of your post. I'm not gonna be like parsifal and let you scare me away from this discussion (or anywhere else). As long as people respond intelligently to my posts, or the developers use some of my researched material (which happens to contradicts most of your narrow-minded views), then I'm gonna keep on posting. So instead of wasting your time asking me to stop, ask others to stop responding to me. Good luck with that...

Edited October 13, 2014 by PrestaShopaholic (see edit history)

[desmowow]

what is the v1.6.0.10 release's date ?

[Guest]

 

Perhaps this shows the issue if not the fix. And why we just need a system that works - and is consistent

 

The image shows an invoice raised this morning. A customer has bought 12 discounted items, and which ever way you calculate it, the figures do not add up

 

Tax is 20%

 

So if the Product total excluding tax is £41.64 then the VAT is 20% of that, £8.328 added together comes to £49.968 > So why is £50.04  showing?

 

Oh I know, product price including VAT is £4.17 *12  = £50.04

 

But surely which ever way you get to it, the figures should be the same?

 

In the summary table it shows total excluding tax = £41.64. but the tax is £8.28 - that is just not right, it should be £8.328

 

So is this "just" rounding issues? that will be sorted in the update? or is it that prestashop is calculating things differently at different times - even on the same invoice

[PrestaShopaholic]

Aside of the rounding issues, IANAL but it looks to me like this invoice may have some legal issues. I'm not sure about your locale, but in the USA, you'd (almost) never be allowed to lower the tax rate itself in order to give your retail customer a discount. In the USA, you could lower your excl-tax unit price, or incl-tax price, or any other combination that doesn't touch the percentage tax rate.

 

So if your excl-tax unit price is $3.47 and sales tax is 21%, then in the States you could give 1% discount this way:

$3.47 - 1% = $3.44 discounted price     + 21% sales tax [$0.72]= $4.16

$3.47 + 21% [$0.73] = $4.20     - 1% discount = $4.16

But not: $3.47 + 20% [$0.69]= $4.16

 

Taxman always wants his full 21% ($0.72 or $0.73, but not $0.69).

 

Of course, if you sell to another retail customer and his local sales tax is 20%, then sales tax needs to be shown as 20% throughout the invoice. That customer shouldn't see 21% - 1%. The 21% figure is meaningless to that customer.

 

So in other words your invoice complicates the rounding matter further by introducing discounts -- and that's a good thing, since it looks like discounting may be done differently in different places, too...

Edited October 16, 2014 by PrestaShopaholic (see edit history)

[desmowow]

The problem is the moment in which is performed the rounding.

 

3,47 * 20% is 4,164 but presashop round this at 4,17

than 

the correct calculation is 4,164*12 =  49,968.......for prestashop is 4,17*12 = 50,04 (there is 0,072 of difference)

 

Should be done before the multiplication and, in the end, rounding

[PrestaShopaholic]

3,47 * 20% is 4,164 but presashop round this at 4,17

 

In general, it could be 4.17, if your locale mandates always rounding up the tax (i.e. Florida). 3.4700 + 20% = 4.1640. That's not the case for Haylau though (UK).

It can be also be 4.1700 to begin with (unit price incl tax), with excl-tax price of 3.475 rounded down to 3.47 by picking the wrong rounding type (round half to nearest odd, or just rounding half down), or with the right rounding type for the UK (always round down).

 

the correct calculation is 4,164*12 =  49,968.......for prestashop is 4,17*12 = 50,04 (there is 0,072 of difference)

 

If you calculate tax per-item, then the calculation is done based on the item calculations, so it COULD BE:

For one item: 3.47 + 20% [0.70] = 4.17

For twelve items: 3.47 * 12 + 0.70 * 12 = 41.64 + 8.40 = 50.04

 

So what needs to be done first and foremost is tell us what rounding methods and types are being used, and what's the legal tax rate in the place, how you're applying discounts, and what are your expected results. Of course it'd also help telling us what precise build of PrestaShop was used since giving us bug reports when the latest builds resolve the issue already is quite pointless.

Edited October 16, 2014 by PrestaShopaholic (see edit history)

[djfm]

Hi Prestashop team,

 

It is still a mess. It is still not working good with low price products and 21% tax situation here in the Netherlands. I will post my results here for the test that I run:

 

Product without tax: € 0.21

+ Tax 21%

Product with tax: € 0.25

 

Product with tax € 0.25 x 30 pieces = € 7.50 total.

That's good. Let's have a look on the invoice then, where the real problem appears:

 

It says:

Products without tax: € 6.30

Total tax 21%: € 1.20

Total: € 7.50

 

But that incorrect. It must be this:

Products without tax: € 6.20

Total tax 21%: € 1.30

Total: € 7.50

 

You see it's a difference of 0.10 !!!

I have tried the new rounding and counting methods in this 1.6.0.10 version, no method improved the situation in 1.6.

 

Hi Stefand,

 

How do you find 6.20?

 

Seems to me that the total pre tax is right in PrestaShop: 6.30 = 0.21 * 30

As for the tax, setting rounding to "Item + Half Up", I get 0.04 * 30 = 1.20, which sounds correct to me and is the result reported by PrestaShop.

[djfm]

I think it is very difficult for the Prestashop team to understand / analyze the test results reported by us, because there is no standardized process. I would be very useful if we had some exactly defined test cases (sample orders) which we can reproduce in our localized stores and report back the errors (expected result / current test result).

 

Indeed it's hard

 

That's why we have this: https://github.com/PrestaShop/PrestaShopAutomationFramework

Still a work in progress, but already able to run precise invoice tests: https://github.com/PrestaShop/PrestaShopAutomationFramework/tree/master/tests-available/InvoiceTest/examples

[eleazar]

@Haylau

 

Hi Ron,

 

which Prestashop 1.6 version exactly do you run? I suppose it's 1.6..0.9.

 

Though I know these errors well, they seem very peculiar in this invoice because it's just a minor quantity and no really huge amounts. Maybe this is because you round down in any case though this isn't necessary in UK as far as I know the legal practice.

Maybe the values on your invoices would already be more precise if you'd choose "Round towards the next even value" as rounding mode and "Round on the total" as rounding type.
(Note that this wouldn't affect orders with already generated invoice, because the values aren't generated each time on the fly but are stored in the database table ps_order_invoice.)

 

And btw:

 

or is it that prestashop is calculating things differently at different times - even on the same invoice

 

This indeed is the other problem in addition to the rounding errors.

 

As a workaround you may install the free module EU legal we developed in Germany, you can download it here or here or at Prestashop Addons. This module does not only adapt Prestashop to European Law, but also corrects the major rounding errors with overrides and by increasing the decimal precision in the database from .2 to .6. The latter is standard from 1.6.0.10 on. We still hope that we may do it without the overrides from 1.6.1 on, but we're not sure if we can trust in this.

 

Regards,

eleazar

[PrestaShopaholic]

How do you find 6.20?

 

My comprehensive analysis of his scenario tells you what he wants: per-line tax calc when the item costs 0.25 incl tax (0.2066 excl tax).

Edited October 16, 2014 by PrestaShopaholic (see edit history)