We're working on a quote template and trying to surface a modified Amount Total that includes a calculation using a tax rate that's a custom property on the deal. Currently only limited experience in working with HubL
I'm running into a syntax error, " Invalid argument in 'multiply': 1st argument with value '{{deal.tax_rate}}' must be a number"
I'm thinking that this wouldn't be an issue if it were publishable because deal.tax_rate is actually a number when it populates... but I can't publish with the syntax error.
End goal is multiplying the amount by 1.(tax_rate) to end up with a new total that reflects the previous total plus the appropriate tax, but I figure if I can get the variable to work in this multiple function then I can always pass 1.045 instead of 4.5 for example into the deal property, or do a calculated property.
That error means that the argument you passed to the multiply filter isn't a number.
If it looks like a number I would check for spaces or hidden characters.
It's important to know that Hubl / Jinja will attempt to coerce values to an appropriate primative in order to use them, but it won't remove the spaces locking the variable to a string class. This is alsp probably the reason the HS team didn't create a parse filter. See my example below:
"123" === 123, "12.3" == 12.3, and "1.23" === 1.23
A simple test (very simple) is to print the value with a character on either side of the expression. This will allow you to visually see if their are any spaces.
{% set your_variable = 23.4 %}
.{{ your_variable }}.
If it prints ". 23.4." or ".23.4 .", you can see the spaces.
Again very simple test.
@dennisedson suggestion of |int would work with one serious drawback. Integer refers to a whole number. That means the |int filter will strip any decimal point from the number. Not ideal when dealing with taxes!
Thanks Kevin! Does this work in a Quote template on your end? I still get an error thrown in Design Manager because the property token isn't a number (it doesn't look past the token to see what an example value would be as far as I can tell, it just says 'hey, you gotta pass a number here and that (the token) isn't a number)
I cannot test this ATM, not sure I can replicate your situatiom.
Have you tried using the "pprint" filter to get more info about the object? Ideally this will tell you what kind of object the property token is. That should reduce the number of situations you'll have to test.