Tax Issues with Products

I am having a lot of trouble with Tax on Products and really need help to navigate this.

We have gst which is 10% so have been added all product prices ex.gst and adding the 10% tax so it can be reported on in Invoices and in the Shopping Cart.

Im using {{this[‘priceWithTaxHtml’]}} which includes the tax but this is the ‘Sale Price’.
This doesn’t always round to the nearest whole number and you get $429.99 and you can’t add | round to it like this {{this[‘priceWithTaxHtml’]| round}} because you get a price of “$0”.
Sometimes it looks correct in the detail view i.e. $215 but if you select 2 of the items it says $429.99.
Then sometimes the products in the shopping look correct but then the Order Total has a .99 again.

As the client needs items on sale, I need to use {{this[‘RecommendedPrice’]}} as this is the RRP but it has no tax and if I add | times: 1.1 | round to it then I get no “.00” on the end of the dollar value ie. $173 instead of $173.00. There is no {{this[‘RecommendedPriceHtml’]}} version of this field.

To use RRP and Sell price for a product ‘OnSale’ then we need a way to consistently display prices that include GST and round correctly to the nearest whole number.

The only workaround I have found is to have three decimal points on the end of a price but as I can’t export all the products, make changes and upload them again this is not an option, plus it needs to be tested to work out exactly what it needs to be without going 1c over or under still.

Has anyone worked out a way around this as my client is struggling and the inconsistency in the pricing is hard to manage.

@Violetta.S do you know a work around for this?

Query - Should the price of a product be listed on the website as the RRP and then if you click the ‘On Sale’ checkbox the ‘Sell Price’ displays and that is the price that goes through to the shopping cart? At the moment by default the Sell Price is the one that is added to the Shopping cart whether ‘On Sale’ checkbox is selected or not. That doesn’t allow you to have a Sell Price that is only activated with the ‘On Sale’ checkbox is selected.

I’d agree that we need:

@SiroccoDigital the reason for all the price shifting when it’s recalculated due to an attribute selection, quantity change, etc. is because the ecommerce javascript is updating these prices in the DOM and therefore overrides any Liquid filtering applied. Plus, the JS is calculating from the raw values from the product data, not necessarily what’s displaying on page (due to filters, etc.).

The best current workaround I know of for the tax rounding issue is for 3 decimal prices, unfortunately.
But surely there is a mathematical solution to solve tax rounded issues that can be applied in the back-end here. How to other eCommerce systems do it?
Although, BC had this problem too I think…

I believe the “sell” price that the system uses should always be the “sell” price in the admin.
RRP is simply a display price, not used in any calculations. It’s a promotional value.
This is how it was in BC as well.
Otherwise, you wouldn’t be able to show an RRP price against a normal Sell Price (when products aren’t on sale or if you don’t have on-sale items).

@Adam.Wilson thanks for the clarification around the “sell price” being default I will just have to work with that as-is.

I could work around the decimal point issue if I had a way of exporting all products so this could be done at scale. This is a fiddly fix though and really we need a mathematical solution so clients aren’t having to wrestle with decimal points.

For the RRP it would be great to have this as {{this[‘RecommendedPriceWithTax’]}}
so we had a variation that is identical to the PriceWithTaxHtml functionality so that prices in layouts look and behave the same.