I am stuck with PDF Monkey formatting of numbers, I created a template via HTML CSS. Now when I generate PDF I get endless digits after decimal. I tried toFixed() method of JavaScript. It worked for me but my partner who is based in Europe getting error. ( Liquid error: invalid value for float(): “272,586”). If it not a valid value then how it is working on my system. I am now really frustrated about this.
Then I used " format: “%.2f” " which again works for me but not for him, Can you guys please guide me what is wrong am I doing. Just to show you please see the attach screenshot. And 1 thing to note is my partner is from Europe and I am from Asia, Can it be the issues with formatting of their numbers format of Europe.
Thanks for replying. Yes it may be the regional issue. Here I am sending the image where first image is value which we are using for input. second is the computed ITE column which I am passing as value to the PDF monkey. I tried to manipulate group separator, precision through glide but nothing works.
hmm, I suspect the if-then-else column might be the culprit here. There is a known issue where dates and numbers will lose their formatting when passed through an if-then-else column.
Try this: create a math column that takes the value returned by the if-then-else column and re-applies the formatting - specifically, without the group separator. And then pass that to the PDF Monkey integration.
Ok I will try this and let you know, Do you think If then else depends on region. Because it works when I trigger PDF monkey, But It does not work when my partner trigger. And the error occur only on the values which have some digits after decimal for example ( 52.134). If it is a straight value for example (52) then it works fine and display as 52.00 on PDF monkey.
Some regions use a period . as a decimal separator, and some use a comma ,.
And it appears that PDF Monkey can’t handle the latter.
It works for you, because you are sending a value with a period separator.
The idea of adding the math column is to remove the separator altogether, so it isn’t a factor.
Where the if-then-else comes into the picture is that it doesn’t respect any previously applied display formatting, and just returns the default (which presumably includes the separator). So the idea of the math column is to over-ride that behaviour.
It may or may not solve your problem, but is worth a try.
I think this is not possible because the value which is passed through glide to PDF monkey should be number , Then from PDF monkey I am using {{total1 | format: “%.2f” }}. total1 in this case is variable which is coming from glide then " format: “%.2f” " is function I tried in PDF monkey template for keeping that total1 variable till 2 decimals. And this works for me but not for my partner.
Thanks Darren, I tried to pass the value as math computed value but still it is not working. I tried different methods of JAVA script as well in the HTML template to convert string into numbers.
I used
parseFloat(num) method
num*1 (Multiply variable with 1 to convert string into number)
Number(num) method
then I used
Math.floor(num_1*100)/100 2)
Math.ceil(num_*100)/100
num.toFixed(2)
methods to make this number to 2 decimal places.
NOTE: (num) is variable. Every solution is working for me but nor for my partner.
If I do not use any method and simply put the variable which is coming from glide to the pdf monkey. It is working for both of us as you can see in the image. But it is endless digits after decimal.
Yes ThinhDinh this is an option . But I have like 44 columns, And it will be too much computation within glide. Thats why I wanted to do this inside PDF monkey. Thanks for your guidance
Hi Darren, Its working. Is it possible if the digit has no number after decimal for example if it is 64, I wanted to make it 64.00. Now if it is 64.33356 —> it is rounding up 64.34 which is fine. But if it is full number like 64 , I want to make it 64.00. Is there any way ?
The only thing I can think of off the top of my head is to use a Template column to “lock” the formatting.
But, that would be converting the number to a string, so it could cause problems upstream.
