te-online

Thanks for your response. My opinion is unchanged, I’d rather have obfuscation than notification. It’s a core principle of GDPR –?don’t store plain personal data wherever possible.

That said, I appreciate it a lot you took the time to put out a dedicated FAQ that explains your reasoning.

–?Thomas

Good evening Frank!

Tried the master and it’s indeed fixed.
Thanks a lot once again for your prompt answer ??

Now we just need to wait for the next release.

–Thomas

Hi Frank,

Thank you so much for your quick reply ??
The filter is just what I was looking for!

Thomas

In my opinion, the first price on the page that is calculated from a price in the database and a tax rate, should be rounded to 2 digits precision. From there all prices on the page that refer to this price (e.g. multiple items prices, discounted prices) should be calculated from this rounded value. This would be the consistent way a user would expect it to work and also how it would work in a real life shop.

Unfortunately I haven’t. In theory it seems easy to do it right, but as we can see from the Pull Request there seem to be problems with discounts, once the issue we experience is fixed.

I guess it shouldn’t be too hard to apply a consistent rounding model in WooCommerce, but I have no motivation or time to look into this right now, sorry! ??

I’m a bit surprised though that this issue didn’t come up earlier and isn’t reported by more people. From my quick experiments a way to mitigate the effects of this a bit, could be to add prices to products excluding taxes and let WooCommerce do all the tax calculations.

Thanks for your reply! ??

Sorry, I was just trying to illustrate what I see is going on, no intention on throwing maths at you ??

Well, I’ll have a look at the PR, but I guess without a good understanding of the WooCommerce codebase I’ll only be able to contribute in describing how it should work, but not be able to implement the change right away.

Will follow up here, once some kind of solution came up.

Any news on this @mikejolley or @icaleb? ??

I’ve read through this thread and also the https://github.com/woothemes/woocommerce/wiki/How-Taxes-Work-in-WooCommerce Wiki entry. And it makes perfectly sense to me.

However, this issue is not about tax calculation but about when to round. And I have to admit that @scheichmanfred is right.

Let’s assume I have a shop that has stored all the product prices incl. taxes.
Furthermore, let’s assume I display the prices without taxes on all pages and also in the checkout process.

Now this works fine for single items. But whenever I add more than one of a kind to the cart, we might get a problem, because prices are not rounded at the time they are supposed be.

Let’s imagine the following situation:

Product #1
Stored price incl. tax: 25,00
Tax rate: 20% (=0.2)
Calculated price excl. tax: 20,83 (=25/1,2=20,833333333)
Displayed single unit price: 20,83

Everything fine so far, right?

But now let’s look at the calculation when we add multiple units to a cart.

4 x Product #1
Expected total price excl. tax: 83,32 (=4*20,83)
Displayed total price in cart excl. tax: 83,33 (=4*20,83333333333)

The cart now shows the single unit price correctly as rounded 20,83.
But the total price will be shown as 83,33, which is not correct in this context, since the rounded single unit price is indeed 20,83 and not 20,83333333333.

As a result, the cart will always display a wrong amount for multi unit items, since rounding doesn’t take place before multiplying the single price.

So, to correct this situation, we could either show the single price the calculation is based on (20,83333333333) or we could simply round the single unit price before multiplying it by the number of units.

Do you still think this is not a problem @icaleb?

Let me know if my thoughts are not correct and there already is a way to fix this issue.

Hi Mike,

It took a while for me to learn how the centralized translations process works. Thanks for the link ??

Thomas

I accidentally posted twice ??
(see below for message ??)

• This reply was modified 7 years, 11 months ago by te-online.

Is the wordpress-directory at the root of your git-repository?
Try omitting the slash in front of wp-content.

Okay, the solution to this was really simple. My hosting provider reinstalled/upgraded the package tzdata and everything works fine now! ??

–– Thomas

Thanks a lot for your answer!
I started to check back with my hosting provider, I’ll give them your info and report on the outcome.

–– Thomas

Okay, I explored this a bit further and want to update this thread for documentation and also to ask for help once again.

The main issue seems to be that when the timezone is set to a string (like ”Berlin“) in the settings, the post_date_gmt will be set to the same time as post_date which is not gmt in this case obviously. This is only true for the main post. The revisions strangely have the correct post_date_gmt.

When the timezone is set to UTC+2 in the settings, everything works as expected. The post_date_gmt will be set to two hours earlier than post_date. This would be the expected behaviour for the string setting as well.

I’ve seen this behaviour only on this configuration, but can’t find the failure or even the difference to another machine that is configured similarly.

I’m still hoping somebody with a lot of ”server experience“ could have a hint for me, where to look for a solution. ??

–– Thomas

Great!

Thank you very much for your quick reaction, P?r. ??