Jump to content

1.6.0.10 - Testers Needed


Recommended Posts

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%)



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

 

post-360108-0-51967100-1408394764_thumb.png

  • Like 1
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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

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

  • Like 5
Link to comment
Share on other sites

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. 

  • Like 1
Link to comment
Share on other sites

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

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

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

  • Like 2
Link to comment
Share on other sites

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 by eleazar (see edit history)
  • Like 4
Link to comment
Share on other sites

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 by eleazar (see edit history)
Link to comment
Share on other sites

 

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 by PrestaShopaholic (see edit history)
Link to comment
Share on other sites

 

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

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

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 by eleazar (see edit history)
Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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

@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 by eleazar (see edit history)
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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  :unsure: 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!

  • Like 2
Link to comment
Share on other sites

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,

Link to comment
Share on other sites

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?

  • Like 1
Link to comment
Share on other sites

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?

  • Like 1
Link to comment
Share on other sites

Personally, and I am sure I speak for the vast majority of sellers ( :D ) 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

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

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 ( :D ) 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.

  • Like 4
Link to comment
Share on other sites

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 by parsifal (see edit history)
  • Like 1
Link to comment
Share on other sites

 

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

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

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

 

"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

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

  • Like 4
Link to comment
Share on other sites

@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:

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? ;)

cleardot.gif

 

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 by eleazar (see edit history)
Link to comment
Share on other sites

 

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

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

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 by eleazar (see edit history)
  • Like 2
Link to comment
Share on other sites

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

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 by eleazar (see edit history)
Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

 

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 ;)

  • Like 1
Link to comment
Share on other sites

@Xavier

:D 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

 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 by PrestaShopaholic (see edit history)
Link to comment
Share on other sites

For all the TL;DR short-attention-span crowd :P 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

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 by PrestaShopaholic (see edit history)
Link to comment
Share on other sites

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

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 by eleazar (see edit history)
Link to comment
Share on other sites

 

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

 

 

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

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 by frank de beer (see edit history)
  • Like 1
Link to comment
Share on other sites

 

 

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

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 by frank de beer (see edit history)
Link to comment
Share on other sites

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 by Stefand (see edit history)
Link to comment
Share on other sites