Popular Post benjamin utterback Posted August 14, 2014 Popular Post Share Posted August 14, 2014 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 37 Link to comment Share on other sites More sharing options...
benjamin utterback Posted August 18, 2014 Author Share Posted August 18, 2014 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. 1 Link to comment Share on other sites More sharing options...
asgllccb Posted August 20, 2014 Share Posted August 20, 2014 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? Link to comment Share on other sites More sharing options...
nnab Posted August 21, 2014 Share Posted August 21, 2014 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. 2 Link to comment Share on other sites More sharing options...
benjamin utterback Posted August 21, 2014 Author Share Posted August 21, 2014 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. Link to comment Share on other sites More sharing options...
scorpionsworld Posted August 22, 2014 Share Posted August 22, 2014 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). 5 Link to comment Share on other sites More sharing options...
nnab Posted August 23, 2014 Share Posted August 23, 2014 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. 1 Link to comment Share on other sites More sharing options...
parsifal Posted August 23, 2014 Share Posted August 23, 2014 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. Link to comment Share on other sites More sharing options...
scorpionsworld Posted August 23, 2014 Share Posted August 23, 2014 Benjamin, should I use the taxes branch or the 1.6 branch on Github to commit changes on the tax calculation issue? 1 Link to comment Share on other sites More sharing options...
benjamin utterback Posted August 25, 2014 Author Share Posted August 25, 2014 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 1 Link to comment Share on other sites More sharing options...
scorpionsworld Posted August 25, 2014 Share Posted August 25, 2014 Hi, you should do the PR's on the 1.6 branch of GitHuballright, i'll have some updated files ready this week 1 Link to comment Share on other sites More sharing options...
cedricfontaine Posted August 27, 2014 Share Posted August 27, 2014 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. Link to comment Share on other sites More sharing options...
Xavier du Tertre Posted August 27, 2014 Share Posted August 27, 2014 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 Link to comment Share on other sites More sharing options...
Tomin Posted August 29, 2014 Share Posted August 29, 2014 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... 2 Link to comment Share on other sites More sharing options...
scorpionsworld Posted September 1, 2014 Share Posted September 1, 2014 (edited) Github pull request with my suggestions have been posted (finally) Hope it helps Edited September 1, 2014 by scorpionsworld (see edit history) 3 Link to comment Share on other sites More sharing options...
Shano Posted September 5, 2014 Share Posted September 5, 2014 yes also support a solution for the 1.5. our tax display for logged in customer in california is very confusing. Link to comment Share on other sites More sharing options...
eleazar Posted September 7, 2014 Share Posted September 7, 2014 (edited) 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) 4 Link to comment Share on other sites More sharing options...
eleazar Posted September 8, 2014 Share Posted September 8, 2014 (edited) 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) Link to comment Share on other sites More sharing options...
PrestaShopaholic Posted September 9, 2014 Share Posted September 9, 2014 Is there an ETA for 1.6.0.10 Final? Link to comment Share on other sites More sharing options...
Lucas Cerdan Posted September 9, 2014 Share Posted September 9, 2014 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. 2 Link to comment Share on other sites More sharing options...
PrestaShopaholic Posted September 9, 2014 Share Posted September 9, 2014 (edited) 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) Link to comment Share on other sites More sharing options...
tilkar9 Posted September 10, 2014 Share Posted September 10, 2014 I ask for a solution for anterior versions too. Thanks Link to comment Share on other sites More sharing options...
Guest Posted September 11, 2014 Share Posted September 11, 2014 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. Link to comment Share on other sites More sharing options...
Guest Posted September 11, 2014 Share Posted September 11, 2014 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? Link to comment Share on other sites More sharing options...
cedricfontaine Posted September 11, 2014 Share Posted September 11, 2014 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 1 Link to comment Share on other sites More sharing options...
eleazar Posted September 12, 2014 Share Posted September 12, 2014 (edited) 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) Link to comment Share on other sites More sharing options...
Guest Posted September 12, 2014 Share Posted September 12, 2014 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 amountsNote: 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 servicesIf 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. Link to comment Share on other sites More sharing options...
PrestaShopaholic Posted September 12, 2014 Share Posted September 12, 2014 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. Link to comment Share on other sites More sharing options...
eleazar Posted September 12, 2014 Share Posted September 12, 2014 (edited) @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) Link to comment Share on other sites More sharing options...
Stefand Posted September 16, 2014 Share Posted September 16, 2014 @PrestashopIt'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 = problemI agree with scorpionsworld on this one. It's not only they way how to round, but where. Link to comment Share on other sites More sharing options...
PrestaShopaholic Posted September 17, 2014 Share Posted September 17, 2014 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. 1 Link to comment Share on other sites More sharing options...
Xavier du Tertre Posted September 18, 2014 Share Posted September 18, 2014 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! 2 Link to comment Share on other sites More sharing options...
thepan Posted September 18, 2014 Share Posted September 18, 2014 Will the eu-payment api completely implemented with the next release? Link to comment Share on other sites More sharing options...
PrestaShopaholic Posted September 18, 2014 Share Posted September 18, 2014 Here is an updated version of 1.6.0.10, from today 12pm. Thanks for that! I'll give it a spin ASAP. Link to comment Share on other sites More sharing options...
pl.sabotinov Posted September 18, 2014 Share Posted September 18, 2014 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 moduleSo 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, Link to comment Share on other sites More sharing options...
bellini13 Posted September 20, 2014 Share Posted September 20, 2014 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? 1 Link to comment Share on other sites More sharing options...
eleazar Posted September 21, 2014 Share Posted September 21, 2014 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? 1 Link to comment Share on other sites More sharing options...
eleazar Posted September 21, 2014 Share Posted September 21, 2014 Will the eu-payment api completely implemented with the next release? We didn't get a clear answer yet, but rather ... nope! Link to comment Share on other sites More sharing options...
Guest Posted September 21, 2014 Share Posted September 21, 2014 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 Link to comment Share on other sites More sharing options...
parsifal Posted September 21, 2014 Share Posted September 21, 2014 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... 2 Link to comment Share on other sites More sharing options...
Guest Posted September 21, 2014 Share Posted September 21, 2014 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. Link to comment Share on other sites More sharing options...
eleazar Posted September 21, 2014 Share Posted September 21, 2014 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. 4 Link to comment Share on other sites More sharing options...
parsifal Posted September 21, 2014 Share Posted September 21, 2014 (edited) 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) 1 Link to comment Share on other sites More sharing options...
Guest Posted September 21, 2014 Share Posted September 21, 2014 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? Link to comment Share on other sites More sharing options...
bellini13 Posted September 22, 2014 Share Posted September 22, 2014 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. Link to comment Share on other sites More sharing options...
eleazar Posted September 22, 2014 Share Posted September 22, 2014 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! Link to comment Share on other sites More sharing options...
parsifal Posted September 22, 2014 Share Posted September 22, 2014 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. Link to comment Share on other sites More sharing options...
Tomin Posted September 22, 2014 Share Posted September 22, 2014 ok, lot of talking and no feedback on new version? Link to comment Share on other sites More sharing options...
PrestaShopaholic Posted September 23, 2014 Share Posted September 23, 2014 "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. Link to comment Share on other sites More sharing options...
benjamin utterback Posted September 25, 2014 Author Share Posted September 25, 2014 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 4 Link to comment Share on other sites More sharing options...
eleazar Posted September 26, 2014 Share Posted September 26, 2014 (edited) @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) Link to comment Share on other sites More sharing options...
PrestaShopaholic Posted September 26, 2014 Share Posted September 26, 2014 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 Link to comment Share on other sites More sharing options...
eleazar Posted September 26, 2014 Share Posted September 26, 2014 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. Link to comment Share on other sites More sharing options...
PrestaShopaholic Posted September 27, 2014 Share Posted September 27, 2014 So you ARE saying that nowhere in the world they round (tax owed) 12.451 upwards to 12.46, for example... Link to comment Share on other sites More sharing options...
eleazar Posted September 27, 2014 Share Posted September 27, 2014 (edited) 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) 2 Link to comment Share on other sites More sharing options...
thepan Posted September 28, 2014 Share Posted September 28, 2014 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. Link to comment Share on other sites More sharing options...
eleazar Posted September 28, 2014 Share Posted September 28, 2014 (edited) 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) Link to comment Share on other sites More sharing options...
djfm Posted September 29, 2014 Share Posted September 29, 2014 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. 3 Link to comment Share on other sites More sharing options...
Xavier du Tertre Posted September 29, 2014 Share Posted September 29, 2014 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 1 Link to comment Share on other sites More sharing options...
eleazar Posted September 29, 2014 Share Posted September 29, 2014 @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. Link to comment Share on other sites More sharing options...
PrestaShopaholic Posted September 29, 2014 Share Posted September 29, 2014 (edited) 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) Link to comment Share on other sites More sharing options...
Stefand Posted October 5, 2014 Share Posted October 5, 2014 Is there any sight on the release date for 1.6.0.10 and if it solved the rounding issues? Link to comment Share on other sites More sharing options...
Lucas Cerdan Posted October 6, 2014 Share Posted October 6, 2014 Hi Stefand, We're still working on some issues that have been reported by the community. No ETA yet. Thanks, 1 Link to comment Share on other sites More sharing options...
PrestaShopaholic Posted October 6, 2014 Share Posted October 6, 2014 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. Link to comment Share on other sites More sharing options...
eleazar Posted October 7, 2014 Share Posted October 7, 2014 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. Link to comment Share on other sites More sharing options...
PrestaShopaholic Posted October 7, 2014 Share Posted October 7, 2014 (edited) 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) Link to comment Share on other sites More sharing options...
eleazar Posted October 7, 2014 Share Posted October 7, 2014 (edited) 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) Link to comment Share on other sites More sharing options...
PrestaShopaholic Posted October 7, 2014 Share Posted October 7, 2014 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... Link to comment Share on other sites More sharing options...
frank de beer Posted October 8, 2014 Share Posted October 8, 2014 (edited) 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) 1 Link to comment Share on other sites More sharing options...
Guest Posted October 8, 2014 Share Posted October 8, 2014 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 Link to comment Share on other sites More sharing options...
frank de beer Posted October 8, 2014 Share Posted October 8, 2014 (edited) 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) Link to comment Share on other sites More sharing options...
Stefand Posted October 8, 2014 Share Posted October 8, 2014 (edited) 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) Link to comment Share on other sites
Recommended Posts