How should Ecotax work

[Prestaworks]

So, after some issues with a shop where some products had a mysterius additional cost, we discovered that this was from the field ecotax in ps_product being added.
The setting for "Use ecotax" was set to NO, but the value was still added.
Normaly this would probobly not be a problem, since the field is set to 0 when saving "No" on the setting, but this was an upgraded shop so that process had not happened.

Also, when setting this value to No, to just delete all data is not a good solution, it may be possible that a merchant want to suspend this feature temporarily, and to just lose all data is not that great.

I think that

1. Setting to No should not set all data to 0.
2. If the setting is No, ecotax should not be used in any calculations, even if 0.

[jeckyl]

In fact, when this option is deactivated, it should no longer be taken into account in the calculation or display, even if the product data is present.

[RosaBenouamer]

It make sens :-)

[jolelievre]

It's not that simple actually The problem is that when you start enabling the ecotax your product price is split into two parts:

• regular price
• ecotax value

The product price is the sum of these two parts and that's the beginning of troubles.

Let's take your example, ecotax is enabled you have product with regular price 8$ and ecotax is 2$ so your product is sold for 10$ (let's put the taxes out for now). You want to temporarily disable the ecotax feature, but as you said in a slack discussion when we do this we can't simply reset all the ecotax values to 0 (and if we did we'd actually need to add it to the regular price, because the total price shouldn't be impacted by this change in configuration).

So regular price is still 8, if we do as you suggest and simply ignore the ecotax value already set then the product price has been changed from 10 to 8. That's probably not what the merchant wishes, he simply doesn't want to display the ecotax part. I think that's why in the method computing the product price the ecotax part is ALWAYS added regardless of the ecotax configuration. And it also makes sense because keeping prices consistent should be the priority.

TLDR: the problem with ecotax is an old one, it was not designed efficiently and now it causes all these struggles and bugs, the ecotax value should be independent from the product price and only used as a displayed information it would solve many drawbacks in the price computing and also improve the general UX in back office.

[Prestaworks]

I agree with you that the ecotax should be separated and only for display, if not always, then atleast it should not be added to the price when the feature is turned off. It's like if you turn off tax in the shop, that will also change the prices of all products but it will not delete any information from the products, you can always re-activate it and everything goes back to how it was.

I can also add to this that the dream configuration for handling prices would be that all prices in PS is stored in cents as INT and incl tax.
(99 is stored as 9900). Tax % is then only used for displaying tax values on invoices and such.

The reason for this is that

1. storing as int and in cents, removes a few issues with float numbers.
2. storing as incl tax, makes it possible to have the same price to all countries. Most merchants do not like that the price is 99€ in one country and 98,65 in another and the third country has 101,18
   99 EUR is a nice even number that converts better, if there is a small difference in the profit due to tax being 25% or 24% that is second to having the nice looking price.

but I guess that is a bit off topic :)

[jolelievre]

I agree if ecotax was separated we could easily enable/disable the feature since there would be no impact on prices anyway.
But that's not how it works, since right now as soon as you define an ecotax on a product one part is in a column and another part in another column. So regardless fo the feature being turned on or not you still need to add those two values to keep the same product price.

That's why we can't just ignore this in price computing as long as the ecotax will be handled the way it is now.

[jolelievre]

About storing the value in cents although it reduces some problem it won't solve them all. Mostly because some merchants need to store more than two decimals (because the sell gears, gasoline or whatever). So we'd need to store both the price in integer and the required precision ideally, but it's a massive change in the DB.

And even if we do that it doesn't change the fact the in the end the post important is to stop using PHP floats, and prefer a library dedicated to computing like DecimalNumber that can handle any number of precision accurately. And it needs to be used along the whole chain and in all your code to be sure you never lose any precision.

Even then at some point, you need to round your values so there are always some risk of losing precision, the question is how accurate is the precision you accept to lose. Currently with float we do have 6 decimals which should be enough for 99% use cases, that's why I'd be in favor to keep them as is because the gain of switching to storing integers + precision compare to keeping current float may not outweight the database structure changes which would be massive.

[Prestaworks]

ok, so basicly eco tax is not added to the product price but included in it but today, Prestashop adds it to the price and the feature should really be rebuilt to just be used for display, but since that would mess up all prices, it's just very difficult to complete?