I am having difficulty getting the {{this.priceWithTaxHtml}} to be rounded?
I have worked out how to round the attribute prices and add gst to them using {{x.priceValue| times: 1.1 | round}} but when they are added to the full product price this one won’t round.
Adding {{this.priceWithTaxHtml| round}} or {{this[‘priceWithTaxHtml’]|round}} gives you a “0” value.
See example here - [omitted]
@Adam.Wilson do you know a liquid work around for this?
Regarding the attribute pricing:
It seems that | round only rounds to the desired number of decimal places if there is that number or, more, of decimal places in the original number.
However, to appropriately format the attribute price you can use Treepl’s domain_money_format filter for this:
{{attrOption.priceValue | times: 1.1 | domain_money_format}}
Regarding the product price, if you are using the priceWithTaxHtml you’ll get HTML output so number filters on this will produce unexpected results.
I’d suggest reverting back to the raw value (priceWithTax) and using the above domain_money_format filter to format it.
(but you’ll need to recreate the HTML needed)
Oh, but the product price (formatted HTML) should already be correctly formatted/rounded, so I’d say once you resolve the attribute pricing issue, the dynamic product price change will be fine.
@Adam.Wilson I have added the domain_money_format to the attribute but if you try the second extras called ‘Drafting Kit’ which shows as $95 it still makes the price a decimal of @279.99 instead of $280 - https://www.hunterofficefurniture.com.au/computer-chairs/hofstp350-computer-chair
What does domain_money_format do?
That filter formats numbers to the country/culture format setup for the current domain.
https://docs.treepl.co/documentation_group/liquid-filters/treepl-cms-filters#secCurrencyDomainMoney
So the .00 decimals is correct, but if you don’t want this showing I guess you could use
| remove: '.00'.
In this instance though it needs to push through to being $280 instead of $279.99
Hmmm, looks like this might be one of those tax rounding issues.
Because if you add the ex tax prices and then add tax you get $279.994.
So technically this is correct and the ecommerce javascript must be using the ex tax values to calculate from. Which is the correct way to do it right?
I think BC had this same tax issue didn’t they?
@SiroccoDigital I see you’ve resolved this. What was the fix?
Did you adjust the product/attribute pricing to compensate?
@Adam.Wilson I have kept the priceWithTaxHtml and added the domain_money_format to attributes. Then I went to three decimal places (where required) on the attribute price and it is working.
So you mean in the actual admin you’ve entered a price with 3 decimal places to allow for more ‘accurate’ calculations?