[Aleksey]

Hi guys,

I just published an update fixing this problem:

Quote

...to achieve the £9.99 figure. Which is fine until you click on 'checkout' then the totals inside those pages round to £10.

Please check it out.

Thank you

[fudge]

Yup works fine now

Thanks again!

[apepp]

...i don't know here, but i'm bang up to date on LS install...

...when I have a product at £8.33 base price (with tax @ 20% included turned on to display in the settings), the product still displays at £10.00...

...anyone else?

...this is the call I'm using here:

<td>
<span class="product_price" id="product_price"><?= format_currency($product->get_discounted_price()) ?></span> <?= tax_incl_label() ?>

...oddly when I add 2 x £10.00 items (that include the 20% tax) i get £19.99 in the cart...

This post has been edited by apepp: 21 February 2012 - 04:19 AM

[Aleksey]

Hi Andrew,

There are some threads on this forum where we discuss the rounding problem. Taxes are calculated on sub-totals of products and then rounded. You can read the discussion here: http://forum.lemonst...-in-lemonstand/

We believe that the current implementation is correct and it satisfies most of our customers. We can extend the tax engine with API so that you would be able to alter the tax calculation process to fit your needs. Please let me know if you want we to do it.

Thank you

[Andrew]

Hi Aleksey & Andrew,

Aleksey, on 21 February 2012 - 02:59 PM, said:

There are some threads on this forum where we discuss the rounding problem. Taxes are calculated on sub-totals of products and then rounded. You can read the discussion here: http://forum.lemonst...-in-lemonstand/

For tax inclusive environment the catalog price is also effectively being rounded (since the db only holds 2 decimal places) as well so that will bugger the maths up.

i.e.
8.33 * 1.2 = 9.996 (which rounds to $10)
2 * (8.33 * 1.2) = 19.99 (doh!)
10 * (8.33 * 1.2) = 99.96 (doh!)

I haven't tried this (since I'm fudging it with no tax and calculating it manually) but would having higher prescission for the catalog price fix this?

If the catalog price is 8.3333333 you'd get
8.3333333 * 1.2 = 9.99999996 (which rounds to $10)
2 * (8.33333333 * 1.2) = 19.9999999 (which rounds to $20)
10 * (8.33333333 * 1.2) = 99.9999996 (which rounds to $100)
100 * (8.33333333 * 1.2) = 999.999996 (which rounds to $1000)

I've got no idea if this would break other things though (i.e. does the rest of LS assume the catalog prices don't need rounding). I saw a thread elsewhere about updating the schema to do this but can't find it again.

Quote

We believe that the current implementation is correct and it satisfies most of our customers. We can extend the tax engine with API so that you would be able to alter the tax calculation process to fit your needs. Please let me know if you want we to do it.

Does this mean that the roadmap task to make LS work in tax inclusive environments will still have these kinds of rounding errors?

Thanks & cheers
Andrew

[Aleksey]

Hi Andrew,

We are planning to review the tax engine in the future, and take into consideration all complains and wishes of our clients.

Thank you

[apepp]

Hello Andrew & Aleksey,

Understandably this tax thing is breaking my very small pea brain...it's rattling away!

...this rounding thing is a bit of a brain ache.

...my pea brain is now mushy peas!