1.6.0.10 - Testers Needed

[eleazar]

@djfm

 

 

Hi Stefand,

 

How do you find 6.20?

 

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

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

 

Hi François,

 

depends on the way you do it.

In this case both results are possible depending on decimal precision and calculation method.

• Base is tax excl. value € 0.21

  21% tax = € 0.0441

  = € 0.2541 tax incl.

  x 30 = € 6.30

   

• Base is tax incl. value € 0.25

  = € 0.2066 tax excl.

  21% tax = € 0.043388

  x 30 = € 6.20

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

[djfm]

Ok thanks eleazar, I see!

 

But why take only 4 decimals if the result wanted is 0.25 post tax?

 

Contrary to seemingly popular beliefs you can have up to 6 decimals in pre-tax prices

 

With 0.206612 pre-tax, the invoice is still correct (1.2 tax, 6.3 products pre tax, 7.5 total).

 

Prices are stored with 6 decimals, and PrestaShop chooses 0.206612 as pre-tax price when writing 0.25 post tax with a 21% tax (btw, I'd advise to always input prices pre-tax and not let PrestaShop to do the conversion from the post tax price on its own, as it might be slightly different from what you expect - for a number of reasons that are not bugs).

 

So, I'm getting a bit lost here - Stefand, is there still something that needs solving with your example?

 

To anyone reporting bugs in this thread: please specify your products' pre-tax prices as you read them on the product sheet in the back-office, with all the decimals - NOT the figures you see on the invoice in the Unit Price column.

The latter are rounded, so not a proper basis for discussion of test scenrios!

[eleazar]

I'd advise to always input prices pre-tax and not let PrestaShop to do the conversion from the post tax price on its own, as it might be slightly different from what you expect - for a number of reasons that are not bugs).

That's the problem! What do you think a normal shop owner would answer if you ask him to enter his pre-tax prices with 6 decimals precision to avoid rounding errors.

 

Make an educated guess.

 

And if you'd do it the way the majority of shop owners would probably act, you would enter a 2-decimal digit as pre-tax price - which would result in exact the difference that stefand reported.

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

[PrestaShopaholic]

Maybe this is because you round down in any case though this isn't necessary in UK as far as I know the legal practice.

 

It makes absolutely no sense to round up when you can legally round down the tax (UK), just as it doesn't make sense to round-half-to-closest-even when it legally requires you to round-up-always (Florida), and round-half-up (most other US states). 

 

And if you'd do it the way the majority of shop owners would probably act, you would enter a 2-decimal digit as pre-tax price

 

Shop owners should be taught to input their advertised prices, which in Stefand's case is the 2-decimal post-tax price. Internally, of course, just the 6-decimal pre-tax price needs to be stored in the database.

 

(btw, I'd advise to always input prices pre-tax and not let PrestaShop to do the conversion from the post tax price on its own, as it might be slightly different from what you expect - for a number of reasons that are not bugs).

 

I can see your point. But I would consider it a bug if PrestaShop always calculates 0.206612 to be the pre-tax price when the user enters 0.25 post-tax.

 

If the user happens to choose the rounding mode "round up to the nearest whole number", for example, then 0.206612 pre-tax is incorrect because adding 21% yields 0.25000052 which will be rounded up to 0.250001 (and consequently to the much worse 0.26) while the user explicitly entered 0.25. In that case, PrestaShop should convert 0.25 post-tax to 0.206611. Adding 21% to that yields 0.24999931 which would be rounded up to what the user initially entered: 0.250000.

 

But even in extreme cases, where auto-calculated pretax price + tax could never reach the explicitly entered post-tax price, PrestaShop can still do the intelligent thing and make sure the post-tax price doesn't go over 0.250000 in this scenario. (It should of course warn the user of what's going on first). In other words even 0.249623 post-tax would be much better than 0.250001 (which will end up showing on invoices as 0.26). The number 0.249623 would show up as 0.25 on invoices anyway with "round up to the nearest whole number" and 2-decimal (or 3-decimal -- 0.250) invoice display precision.

 

Basically PrestaShop needs to ensure it converts back to the exact amount the user enters (whenever possible), obviously while using the rounding mode he selected.

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

[PrestaShopaholic]

[deleted - combined]

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

[PxlTech]

i want to download prestashop dev version from github but there i see 2 version 1.6 and 1.6.0.10 and i dont understand which is new version and last changes updated inside.  they both updated everday both v ersions. what differences and which one i can download ?

[thepan]

1.6 is the main development branch where as 1.6.0.10 the branch for tax related fixes is. Means if you would like to try the latest development version regarding tax issues download 1.6.0.10. 1.6 wont include all those tax related changes. I guess they gonna merge both branches once the tax issues are fixed and tested.

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

[PxlTech]

it means 1.6 has still isues for tax , any tax releated fixes on it ,

 

so maybe it will be 2 release   first 1.6.0.10 and after 1.6 final release ?  or all fix will be applied in one ?

[thepan]

That is a question for the Prestashop team . I think they will make sure the tax issues are fixed, then merge with main branch and make a release including all latest fixes. And yes it means that the 1.6 branch is missing commits that already got applied to 1.6.0.10 but as i said they most likely gonna merge both together once testing is completed.

 

Btw: When you select 1.6.0.10 on github it tells you how many commits its ahead and behind of 1.6. Ahead means commits that are not applied to 1.6 yet and behind means commits applied to 1.6 but not to 1.6.0.10. I hope you can understand this.

[djfm]

@PrestaShopaholic yes you're right I too believe that inputting post tax prices should just "do the right thing" and make sure you end up with the post tax price you had in mind. However it doesnt quite do it yet, because this right thing is not that easy to determine (besides rounding, another complication is: which country should have your round post tax prices if you sell to countries with different VAT rates?). But we'll sure consider this as an improvement. Until then the developer in me says, if you have an issue with prices then input prices pre tax

@thepan the 1.6.0.10 branch is still there for internal reasons, but everything was already merged into branch 1.6, so if you want to test the new tax system, please use branch 1.6!

[PrestaHeroes USA]

having product tax included/excluded at group level is really difficult for multi-country shop managers.  my advice when you can, set visitor to 'tax excluded' (preferably all groups this way).  Otherwise for multi-country shops are not really manageable at product price/tax level.  my two cents

[PrestaShopaholic]

another complication is: which country should have your round post tax prices if you sell to countries with different VAT rates?

 

I think it's great that you guys are thinking of all these different things that can happen!

 

For multi-country scenarios, it could work like this:

If you enter 0.25 (to be interpreted as 0.250000) as post-tax price, then you'd also need to enter (or just confirm the default) tax rate and rounding mode. Last-used-values could be the default values for tax rate and rounding mode. That way PrestaShop doesn't need to guess and the pre-tax price could be calculated on per-item basis. Perhaps certain items are sold predominantly in a country that has a unique tax rate and rounding mode, and you want the "pretty round prices" to show there.

 

But anyway, mathematically, it shouldn't be too difficult to make "post-tax to pre-tax" auto-conversion that's right 99.99%+ of the time.

 

 

Until then the developer in me says, if you have an issue with prices then input prices pre tax 

 

Until then, the (lazy) developer in me would probably just add a line of code to offset the bug as a (very) temporary solution, something like drop the post-price entered by 0.001 (0.25 -> 0.249) or 0.0001 (0.25 -> 0.2499). It's still easier than doing math for every single item...

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

[eleazar]

my advice when you can, set visitor to 'tax excluded' (preferably all groups this way). 

 

Do you mean this as a proposal to stop Prestashop distribution in Europe? I'm not sure if the French developers will appreciate this.

Ok, kidding! But really not recommendable. With regard to B2C it's inconsistent to European law.

[PrestaHeroes USA]

Do you mean this as a proposal to stop Prestashop distribution in Europe? I'm not sure if the French developers will appreciate this.

Ok, kidding! But really not recommendable. With regard to B2C it's inconsistent to European law.

 

what I am saying is that once you set group to tax included, and you do business where that is not 'common' and or 'required' and tax not even required, then you lose sales.  There then is no realistic way to say '0.00' in taxes properly later in the process....and for those not expecting a tax, they won't make it that far anyway.

[djfm]

 

16-10-2014 10-35-28.jpg

 

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

 

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

 

Tax is 20%

 

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

 

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

 

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

 

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

 

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

 

 

Hi haylau,

 

I believe the specific issues you referred to in the above quoted post are now solved!

Please see the attached invoice that is currently generated by PrestaShop for your case.

 

I have assumed that your pre-tax product price is 3.5 and that you applied a 1% discount to it using a specific price.

 

I've set rounding to "Line / Half Up". I get 8.32 for the product tax, and everything adds up correctly.

 

Please let me know if this invoice seems correct to you!

specific-price.pdf

[wakabayashi]

Hello

 

To be honest I haven't had time to test the new version, but I read in this thread and could nothing find about voucher. We are already online with 1.6 and have a lot of tax problems. But the biggest is voucher. When customer uses voucher or we add it, than tax is completly wrong!? I talk about this in pdf: {displayPrice currency=$order->id_currency price=($order_invoice->total_paid_tax_incl - $order_invoice->total_paid_tax_excl)}

 

Does nobody else have problems with it? Is it resolved?

[Guest]

Hi haylau,

 

I believe the specific issues you referred to in the above quoted post are now solved!

Please see the attached invoice that is currently generated by PrestaShop for your case.

 

I have assumed that your pre-tax product price is 3.5 and that you applied a 1% discount to it using a specific price.

 

I've set rounding to "Line / Half Up". I get 8.32 for the product tax, and everything adds up correctly.

 

Please let me know if this invoice seems correct to you!

 

Do you mean fixed in 1.6.0.9 or fixed in the test version 1.6.0.10?

 

Also you say rounding set to "Line / Half Up"?  However HMRC in the UK state

 

"

VATREC12030 - Rounding on invoices and rounding at retailers: 

The rules for this are simple:

• If the VAT on any transaction comes to less than 0.5 of one penny, it should be rounded down.
• If the VAT comes to 0.5 of one penny or more, it should be rounded up.

This is the same system as that outlined in EU Council Regulation 1103/97, which sets out the rules for converting national currency values into Euro.

However, if a trader proposes an alternative rounding method then it should be considered and allowed if it produces a fair and reasonable result.

So you can see they will allow other methods, but 0.5 should be rounded up, less than 0.5 rounded down. Is prestashop now (or with 1.6.0.10) compliant with that?

[PrestaShopaholic]

 

Do you mean fixed in 1.6.0.9 or fixed in the test version 1.6.0.10?

 

Since this whole topic is discussing testing 1.6.0.10 for rounding issues, I'd say 1.6.0.10

 

 

Also you say rounding set to "Line / Half Up"?  However HMRC in the UK state

 

I'm not an accountant nor do I live in Europe,   but my understanding from reading the stuff you previously quoted leads me to believe you have to "Round Half Up" if you use Line or Item rounding types. You can use "Round Down" mode for Total rounding type.

 

So you can see they will allow other methods, but 0.5 should be rounded up, less than 0.5 rounded down. Is prestashop now (or with 1.6.0.10) compliant with that?

 

0.5 rounded up is exactly Round Half Up which is considered the "classical" rounding method (see below), so I'd say it has always existed in PrestaShop, though with calculation errors (reportedly).

 

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

 

1.6.0.10 Final (whenever it comes out) should be solving every situation mentioned in this discussion. It probably still won't solve some weird error/scenarios that aren't anticipated right now. That means that whomever wants to see his rounding/tax issues fixed, should speak up now or forever hold your peace.

 

OK maybe not forever. 

[ZikmaSolutions]

Do you need help from East Europe?

[parsifal]

There is a special test build posted by Xavier in this topic, you must have missed it. See post #33...

[thepan]

The Version 1.6.0.10 in not final yet. This is mainly because there might be still issues related to the tax calculation in Prestashop.

Since tax calculation is a very complex thing, the team just cant try every possible combination of "country" "tax" "products" and other settings. So they simply ask us, to download the work in progress version, setup the shop and see if we still experience wrong tax calculation in our own setup constellation.

 

 

EDIT:

I got a question. I downloaded the latest state from github, and when I install it gives me now the option to choose if I want to install the demo content. Is this gonna be part of the next release or is it only available for the work in progress version?(EDIT2: Its just the   "define('_PS_MODE_DEV_', true);" option set to true before starting installation).

 

Also I like to mention that I tested the performance, and I am quite pleased how fast it is compared to 1.6.0.9 on same server same settings.

Edited October 24, 2014 by thepan (see edit history)

[PxlTech]

what is difference in github prestashop branches between  1.6  and 1.6.0.10 ? 

[djfm]

what is difference in github prestashop branches between  1.6  and 1.6.0.10 ? 

 

Hi PxlTech, current development happens on branch 1.6.

You might see some activity on branch 1.6.0.10, but that's for internal reasons that are of no real interest here, don't worry about it

 

@haylau: "Do you mean fixed in 1.6.0.9 or fixed in the test version 1.6.0.10?"

 

I mean it is fixed on the 1.6 branch on GitHub. Well at least it was at the time of writing It's broken again because we're implementing the feature that allows to choose the number of decimals and it had a few negative side effects.

But this regression is temporary, don't worry about it. Comprehensive automated functional tests are here to prevent us from going backwards.

 

For those who don't like testing off GitHub, we should have an improved testing package to distribute soon, which will include the possibility to choose the number of decimals and other tax fixes.

[PxlTech]

thank you for your answer ,so we can download from github only 1.6 version for test and no need care about 1.6.0.10 version. last updated version is 1.6 and all new changes and updates already added to 1.6 also ?

[roband]

thank you for your answer ,so we can download from github only 1.6 version for test and no need care about 1.6.0.10 version. last updated version is 1.6 and all new changes and updates already added to 1.6 also ?

 

Unfortunately it looks like all the changes on the 1.6.0.10 branch have not been merged back to the 1.6 branch.

 

So right now it's pretty confusing.

[falhassan]

If you disable Tax, you still get the tax fields all over the shop.

I hope you can fix this, so when I disable taxes, all tax related fields will be hidden, including the cart, and pdf invoices.

 

Thanks

[djfm]

Unfortunately it looks like all the changes on the 1.6.0.10 branch have not been merged back to the 1.6 branch.

 

So right now it's pretty confusing.

 

No no they are merged, I don't know git well enough to explain why when you compare both branches you see so many differences (https://github.com/PrestaShop/PrestaShop/compare/1.6...1.6.0.10), but the developers assure me that everything is merged. Branch 1.6 should only have additional stuff, not less.

 

So, @PxlTech "last updated version is 1.6 and all new changes and updates already added to 1.6 also ?", then answer is yes!

 

Furthermore, the regressions I was speaking about yesterday are fixed, so feel free to keep testing

[roband]

No no they are merged, I don't know git well enough to explain why when you compare both branches you see so many differences (https://github.com/PrestaShop/PrestaShop/compare/1.6...1.6.0.10), but the developers assure me that everything is merged. Branch 1.6 should only have additional stuff, not less.

 

So, @PxlTech "last updated version is 1.6 and all new changes and updates already added to 1.6 also ?", then answer is yes!

 

Furthermore, the regressions I was speaking about yesterday are fixed, so feel free to keep testing

 

Thanks, you're indeed right. I was also fooled by the git diff. I did some checks and all the 1.6.0.10 stuff is included in 1.6.

All is good 

[PrestaShopaholic]

And I say Aron1986 is a spam-bot. Quoting some random line from some random post in this thread... C'mon...

 

Update: Yep, it was the same spammer I reported earlier. What they do is abuse the liberal Edit-timeframe policy: they post some random thing, then come back 2 days later and edit the post to include their spammy link.

Edited November 5, 2014 by PrestaShopaholic (see edit history)

[invpts3]

Tested this new update 1.6.0.10 on a testdomain because we had rouding issues.

With this update they are solved! Any idea when this update is going te be final so we can update our shop?

[rawad00]

Hello, could you help please?

 

  I set prestashop 1.6 and having a problem in the stats dashboard, the total sales doesn't take in consideration returns & refunds. Calculations for my customer are all wrong. Total Sales = all sales and not all sales - refunds

Have you provided any fix for this? Do you have an idea how and where I can fix it?

 

Thank you in advance

[pwizzard]

Any news on the stable release of 1.6.0.10?

 

My client is suggesting I rebuild his shop on a different platform, with the amount of time and money spent developing his site on Prestashop this is not an option I want to visit.

Edited November 3, 2014 by pwizzard (see edit history)

[PxlTech]

i think next release will be 1.6    and not 1.6.0.10 , because they already said they merged all changes from 1.6.0.10 to 1.6 version already and 1.6 is more ehead compare 1.6.0.10 , better you can download and develop site on 1.6 from github

[thepan]

i think next release will be 1.6    and not 1.6.0.10 , because they already said they merged all changes from 1.6.0.10 to 1.6 version already and 1.6 is more ehead compare 1.6.0.10 , better you can download and develop site on 1.6 from github

 

They wont release a version with the number "1.6" since that would be a lower number then 1.6.0.9. Does not make any sense.

 

Branch wise they use the "1.6" branch on github as main development branch.  The "master" branch is last stable release and the rest of the branches are just dedicated to some certain developments that will be merged. And the "1.6.0.10" branch is kind of duplicate. Just my thoughts on this.

The next release cant be to far, since there is already a "release" branch on github.

Edited November 4, 2014 by thepan (see edit history)

[parsifal]

PxlTech, you might be confused with the naming of the branches in Github and the nature of git: the main development branch may be named "1.6", but this doesn't mean that the next official release will have a version number of "1.6". Most probably, it will be released as "version 1.6.0.10", regardless of the existence of an experimental "1.6.0.10" branch.

[PxlTech]

 

No no they are merged, I don't know git well enough to explain why when you compare both branches you see so many differences (https://github.com/P.../1.6...1.6.0.10), but the developers assure me that everything is merged. Branch 1.6 should only have additional stuff, not less.

 

So, @PxlTech "last updated version is 1.6 and all new changes and updates already added to 1.6 also ?", then answer is yes!

 

what this here ? prestashop team already said ? they say 1.6.0.10 is just some internal tests but mainly all changes merged on master 1.6 and when you check in github also 1.6 is many changes ahead from 1.6.0.10

Edited November 5, 2014 by PxlTech (see edit history)

[thepan]

what this here ? prestashop team already said ? they say 1.6.0.10 is just some internal tests but mainly all changes merged on master 1.6 and when you check in github also 1.6 is many changes ahead from 1.6.0.10

Yes but as parsifal said, the github branch names are not equal to the release version numbers. The next version will be called 1.6.0.10.

[PxlTech]

i dont ask about the version name i ask about the github branch names 1.6.0.10 version is 916 commits behind 1.6  

it means it is old compare 1.6 version and i still dont understand why github has 2 branch ?  if we want to develop our web site which version we must download and follow from guthub ? which version is updated and fixed bugs and isues ? when i check github everyday each versions has new commits and changes

[thepan]

Prestashops Github has 7 branches right now. Anyway, if you want to develop for the next release I would work with the "release" or "1.6" branch. But as you know they both not frozen and still will get changes before next stable release. A PS Dev might answer this questions more precisely.

[roband]

i dont ask about the version name i ask about the github branch names 1.6.0.10 version is 916 commits behind 1.6  

it means it is old compare 1.6 version and i still dont understand why github has 2 branch ?  if we want to develop our web site which version we must download and follow from guthub ? which version is updated and fixed bugs and isues ? when i check github everyday each versions has new commits and changes

 

I'm not working for Prestashop, but my understanding of this is:

 

Branch 1.6.0.10 was created for test purposes.

A public release will not be made from this branch.

All changes that were done in branch 1.6.0.10 were merged back to branch 1.6 some time ago.

For all practical purposes, just forget branch 1.6.0.10, pretend it's not there.

 

Branch 1.6 is where all new stuff is committed.

New stuff is either committed directly if it's small in size, or merged from a temporary dev-branch with a descriptive name for bigger changes.

 

When Prestashop decides a release is near, branch 1.6 is copied into branch release.

During a stabilization period you will see commits both in branch 1.6 and in branch release.

For branch 1.6 just like described above.

For branch release cherrypicking of important changes from branch 1.6, or quickfixes and release-specific stuff that only go into branch release.

 

At some point in time Prestashop decices the release branch is ready.

Branch release is merged into branch master.

Branch release is merge into branch 1.6.

Branch release is removed.

The release is made from branch master.

 

By the way, about the name of the next release. Looking inside branch release it's currently not clear if the release will be named 1.6.0.10 or 1.6.0.11 or something else. My guess is 1.6.0.11.

 

Cheers, Robert.

[PrestaShopaholic]

 

For all practical purposes, just forget branch 1.6.0.10, pretend it's not there.

 

It's a recipe for disaster IMO. If some poor guy wants to get the latest changes and isn't aware of this discussion, he's gonna do the logical thing and get 1.6.0.10 from GitHub. They really need to put a message in very big letters whenever you stumble upon 1.6.0.10 in GitHub that it's NOT what you want to download. Otherwise we're gonna be rehashing this discussion every single minor version increase...

 

By the way, about the name of the next release. Looking inside branch release it's currently not clear if the release will be named 1.6.0.10 or 1.6.0.11 or something else. My guess is 1.6.0.11.

 

Going straight from 1.6.0.9 Release to 1.6.0.11 Release would be somewhat silly. Not sure what you're seeing inside the branch release, but I'm placing my bets that the next release will be the usual 1.6.0.10.

[MacRoy]

Hi!

 

When I go to Location / Tax Rules I get this error.

 

Incorrect SQL query 

Unknown column 'a.deleted' in 'Where clause'

 

I have installed the latest package from Github

 

It is also missing two buttons, see picture.

 

I must say that it does not appear any VAT in either price or at the Checkout, even though it is enabled.

 

I'm using the latest version of PS 1.6.0.10

 

Is there any fix for this?

 

Best regards

 

MacRoy

 

Edited November 5, 2014 by MacRoy (see edit history)

[Stefand]

When is 1.6.0.10 coming? We are already halfway november!!

My customer is very angry to wait so long on this version / update.

[wakabayashi]

When is 1.6.0.10 coming? We are already halfway november!!

My customer is very angry to wait so long on this version / update.

 

Yeah I am also a bit confused that it takes now that long. I hope they will at least resolve a lot of bugs

 

We shouldn't forget that Prestashop is free... So we aren't allowed to complain that much

[the.rampage.rado]

I see it's available as 'stable' on github for 5 days but probably they are testing this release now and will release it publicly shortly.

[lordspark80]

There's still something wrong in last 1.6.0.10 .

I've tested with this data:

 

I've insert Product price with tax: € 35.00

and the system has calculated Product price without tax : € 28.688525

Tax 22%

If I order 10 products:
Product with tax € 35.00 x 10 pieces = € 350.00 total.
And it's all ok.
 

But if I look at total taxes on the invoice i see:

Products Tax Rate 22%

Total without tax: € 286.89 (As required by law the amount of line shall be rounded to two decimal places)

Total tax: € 63.11

 

But if I calculate the taxes with total:

€ 286.89 x 0.22 = € 63.1158

and if i round as required by law total taxes should be : € 63.12.

Tax laws in italy are very strict and we can't reduce tax or would be treat as fiscal evasion.

 

So the smart solution and that is what I would expect is that the total amount without tax should be always  rounded down, and total taxes always rounded up.

 

That's what i expect:

Product with tax € 35.00 x 10 pieces = € 350.00

Products Tax Rate 22%

Total without tax: € 350.00 / ( 1 + 0.22 ) = € 286.885245... = € 286.88 (rounded down)

Total tax: €286.88 x 0.22 = € 63.1136 = € 63.12 (rounded up)

 

Correct me if I'm wrong.

[MacRoy]

Hi!

 

Have you made any error reporting to PrestaShop?

 

You can do it here: http://forge.prestashop.com/secure/Dashboard.jspa

 

Regards

 

MacRoy

[BJng]

Hi to all,

I've got a problem with tax calculation in products tax breakdown at the bottom of the invoice when there is a voucher/discount in the order.

Can someone tell me how and where is calculate "$product_tax_infos.total_amount" in invoice.tax-tab.tpl?

Thanks to all

Stefano

 

ps 1.6.0.9

[BWT]

Version 1.6.0.9 fresh install has issues with adding video & images to the description section of a product and CMS pages. It would be nice to figure this out, ive posted a topic and i know other topics have been posted about this issue in version 1.6 

Thanks

[MacRoy]

Hi!

 

1.6.0.10 released this week?

 

 

Regards

 

MacRoy

[tuk66]

+1

 

Is there anyone from PrestaShop team? It is not too trustworthy to post this request for help and being silent nearly 4 months.

 

You should regularly communicate with community, and this includes the publication of the final date for v1.6.0.10.

 

Uncertainty does not lead to anything.

 

[MacRoy]

Hi!

 

I totally agree!

 

PrestaShop is losing confidence completely.

 

If you ask for help with testing, you can after all answer questions, it's not too much to ask?

 

But they have been well busy with their Cloud Service so they must think that we can fend for ourselves?

 

I have sent requests to Benjamin, but you have Never get an answer!

 

They may think that we should feel sorry for them because they have not had time with us?

 

Regards

 

MacRoy

 

 

Edited December 3, 2014 by MacRoy (see edit history)

[parsifal]

I have sent requests to Benjamin, but you have Never get an answer!

 

http://www.prestashop.com/forums/topic/343406-new-terms-conditions-in-english-please/page-2?do=findComment&comment=1880947

[Xavier du Tertre]

Hi Tuk66, hi MacRoy,

 

You're 100% right, you've been left without updates on this topic for too long. I sincerely apologize.

 

I have some good news though, 2 minutes from now I'll be entering a meeting to discuss the next 1.6.0.x release and I'll be able to answer your questions in the afternoon.

Again, I'm sorry it's taken so long.

 

Be back soon! 

[Xavier du Tertre]

Hi again,

 

As many of you Beta testers noticed, the cloud version of PrestaShop runs on v1.6.0.10. When we launched this beta program on the cloud, there had been many improvements to the 1.6 branch of PrestaShop since 1.6.0.9. It seemed natural that we would merge them and have this new program run on the latest version of PrestaShop, which we identified as 1.6.0.10 and which is very close to the package members of the Community on this thread have been testing for 3 months.

 

Since then, we’ve fixed many bugs and improved many features. Which is why next version of PrestaShop is going to be version 1.6.0.11, for both projects.

 

The skipping of version 1.6.0.10 for the PrestaShop software was first mentionned a month ago, when we realized that we were fixing bugs on the 1.6.0.10, which we were using for the Beta program. However, we did not want to rush it and it was important that our technical team came to a definitive decision before we explained the reasoning behind this unusual versioning of PrestaShop.

 

The testing you did on version 1.6.0.10 was incredibly useful and it brought up so many questions to answer, so many improvements to fine tune, that we now have a version 1.6.0.11 ready to share with you for official Community tests!

 

We'll be posting it tomorrow, stay tuned!

 

Thanks again to everyone in the Community, you are truly amazing.

 

Xavier

[MacRoy]

Hi!

 

Thank you so much Xavier du Tertre for this valuable information!

 

I, or rather we are all looking forward to it.

 

Many thanks for taking the time to answer our questions!

 

 

Best regards

 

MacRoy

[moy2010]

Yep, I've been stucked with 1.6.0.9 for almost 4 months by now >.<. Hoefully the improvements in Prestashop 1.6.0.11 will let me continue with the development of my store .

[MacRoy]

 

http://www.prestashop.com/forums/topic/343406-new-terms-conditions-in-english-please/page-2?do=findComment&comment=1880947

Hi!

 

Thanks I did not know!

 

That explains why I have not received any response from him.

 

Regards

 

MacRoy

[magali ferber]

Hi Everyone!!

 

We have just released the new package for the newest version of PrestaShop: version 1.6.0.11 !!!!

 

Please see release thread: http://www.prestashop.com/forums/topic/385845-16011-upcoming-release/

 

Thank you for everything you have done to make this possible.

 

Cheeers!!

 

Maggie

[lasseboy]

HI sorry to ask here!

 

Is this tax problem in 1.6.0.9 version?

 

I can se prices with tax when i not logged in as a customer, but when i loggin and look at my products it´s without tax.

 

cant find any were to change to always show price with tax!

[CorwinOfAmber]

ready to test it hard..
Selling products to French Overseas territories (DOM-TOM) and French Africa...
Taxes/rules/customs.. I want to test this 1.6.0.10. Where to find it ?

[tuk66]

https://github.com/PrestaShop/PrestaShop

[doekia]

Still some important issues

 

On this invoice #9, price are in the 1cts discrepancy (as expected, in the accepted range), but invoice looks weird to customer with the 1% discounted up-front

 

On this invoice #10, the discrepancy is 10cts, hence the math goes really bad.

 

Doing a partial refund per quantity (5/10) + restock product - succeed at doing nothing

Edit quantity 10 -> 5 then 5 to 10 issue a warning Total paid 107,37 paid does not match 107.37 total

 

http://store.enter-solutions.com/upload/000009.pdf

http://store.enter-solutions.com/upload/000010.pdf

[djfm]

Hi doekia,

 

Thanks for reporting this.

 

I'm afraid I cannot reproduce your issue exactly, can you please provide more details on how you obtained invoice 10?

 

I attach the invoice I got when trying to reproduce the issue.

 

The settings I have are as follows:

- "Produit à 4.95 TTC": pre-tax retail price = 4.125000, retail price with tax = 4.95 (VAT = 20%)

- "Produit à 4.95 TTC avec 1% remise": pre-tax retail price = 4.125000, retail price with tax = 4.95 (VAT = 20%), specific price = -1%

 

In my invoice the specific price is correctly applied, but it doesn't seem to be in yours, I don't understand why.

Maybe you created the 1% discount using another method?

IN0000010 - kind of.pdf

[doekia]

The first product is at 4.95€ VAT included (tax = 20%), hence 4.125 w/o taxes

The second product is at 5€ VAT included (tax = 20%), with 1% discount using specific price for everyone.

I choosed this price on purpose since they require rounding on tax excluded amount

 

I did try the 1.6.0.10 and the 1.6.0.11, both gives the same result.

On purpose I used a different tax rate for shipping in order to have a split at the end to help figure out which portion does what.

 

The 1cts discrepancy is expected on the first order since 4.125 need rounding that makes the delta.

 

But 10cts on the second one means the rounding is done per product rather that per order. This makes the basic arithmetic totally wrong at the end. 16.60 VAT should have been 16.50 (82.50 x .2) and this time no rounding is needed.

Edited December 22, 2014 by doekia (see edit history)

[doekia]

Found the reason of the discrepancy in between our test.

Settings in Preferences > General Preferences was wrong for me (using the default from install)

 

Now I have setup as "Round toward next even value", btw translation does not quite match what we have in french (Bank alike rounding)

And round on Total

 

This should be emphazed somewhere and probably make those the recommended default.

 

BTW 2: Changing the settings does not fix order processed with previous settings - should be also explained before we get screams from accounting people about their balanced still be wrong even after correct settings.

[djfm]

Glad it's working as you expected using "round on total"

 

BTW 2: Changing the settings does not fix order processed with previous settings - should be also explained before we get screams from accounting people about their balanced still be wrong even after correct settings.

 

This one is on purpose: it should be impossible for an invoice to change after it has been generated once, otherwise you risk getting into even worse accounting issues

[doekia]

I agree with this "on purpose behaviour", but Prestashop been so wrong from so long time - shop owner/accounter imagine something like a magic wand with this settings/fixes - I think you need to make it clear in the doc, the tab, during the change, ... that this will only affect future order and that probably during the transition things can look even worst for a few ongoing order

[CorwinOfAmber]

ok to test.

[PrestaHeroes USA]

Hi!

 

I am using PrestaShop 1.6.0.9.

 

I have added a tax rule for our local Spanish Sales tax rate at 21%. All of my products have this listed as the tax rule to follow. In our area I am required to charge this flat tax rate to all purchases regardless of the shipping destination. when I enter the prices for the products the tax rule is not showing directly I have to click 2-3 times on save and stay button then it shows in the back office and then it comes and I have to select it every time and the separate line of tax is showing in the shopping cart but tax is always showing 0. I have changed all the things but unable to show the tax in the shopping cart. I am also required to show the amount of tax on a separate line in the checkout process.

 

Currently I have the settings as follows.

 

Product set up: Tax Rule is set to my special tax rule added as an additional option in the state taxes.

 

Tax Options:

Enable Tax: Yes

Display Taxes in Cart: Yes

Base on: Invoice Address

Use EcoTax: No

 

The taxes are not being caculated nor are they being displayed in the shopping cart or during the checkout process. Is there something I need to be doing differently?

 

This is the last thing to do before I go live and if I can't get it fixed.

my all work stopped here. I am so worried if it will resolve or not.

Thank you for your assistance in advance!

 

PARRY

 

Please don't spam the board with this post.  Please open a new topic and refrain from copying and pasting this post into non-related topics.

[newbie87]

Is it possible to stop Prestashop from rounding product prices and specific prices/discounts? If so, how?

Thanks in advance for a reply.

[doekia]

3.141592653589793

 

Bear in mind that although this thread is not officially closed, de facto it is since the 1.6.0.10 test period is now closed, not to mention that 1.6.0.10 has never existed.

 

Short answer is no, long answer is nooo not possible.

[xlinkinfocom]

 

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: 

 

 

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

 

Hi,

 

I created a tax rule called “Output Tax” I then added CST tax (all states in India other than West Benal) at 5% to this rule. I also added VAT (Only for west bengal state) at 5% to this rule.

 

All products have “Output” set as the tax Rule on the prices tag. Dependent on customers’ location either 20%, 5% or no tax is charged.

 

But the problem is that, when I selected tax rule as "Output-tax", the "Pre tax retail price" and "Retail price with tax" remain same.

 

Like, if my pretax retail price is Rs. 100/- and I choose Output tax as tax rule then my retail price with tax should be 105/-. But it remains same.

 

Any help will be appreciated. Thanks in advance.

 

[selectshop.at]

Hi,

 

I created a tax rule called “Output Tax” I then added CST tax (all states in India other than West Benal) at 5% to this rule. I also added VAT (Only for west bengal state) at 5% to this rule.

 

All products have “Output” set as the tax Rule on the prices tag. Dependent on customers’ location either 20%, 5% or no tax is charged.

 

But the problem is that, when I selected tax rule as "Output-tax", the "Pre tax retail price" and "Retail price with tax" remain same.

 

Like, if my pretax retail price is Rs. 100/- and I choose Output tax as tax rule then my retail price with tax should be 105/-. But it remains same.

 

Any help will be appreciated. Thanks in advance.

 

tax rule.png

This thread is outdated. Why to test in PS 1.6.010, If PS 14 is releasead ? If you only need help on a problem, so please open a sole new topic instead to add your problem to an outdated topic version. But from what I've seen you already opened two other topics with your question ? Please be patient for to receive an answer. This is a forum not a direct support. If you need direct support, please feel free to book a ticket on the addons site...