We have an integer number field on sales order, th...
# suitescript
r
We have an integer number field on sales order, that we set on before submit. type of for the variable we are using in setValue is giving number While edit and saving the order the value gets set to 2. and we do not receive any error. But if we click on the approve button it gives invalid field value 2.0 Has any1 encountered this?
m
you've got something trying to set it to
2.0
instead of
2
could be sourcing applied to the field under the right conditions, could be the same script, could be a different script or workflow
identify what's setting the value and sanitize the data
a
i had something similar in a custom record field being set from a WFA script... it was intermittent, which was infuriating, I ended up just adding a parseInt(x,10) to force the random .0 decimal back into an int (it was the internal id of the workflow that I need to reference back to later )
image.png
r
I checked all the workflows, client and UE script. Also checked we have no calculation/sourcing at custom fields itself. It's pretty crazy to me.
a
... this was also pretty crazy to me... it was MY custom field, on MY custom record nothing else was ever touching this record but this WFA script and later a suitelet... it was just something insane NS was doing... was that not coming across in the way I explained it? 😄 and the fact that I gave up with no explanation and just forced the issue with a parseInt?
this was also related to approvals and since you also mentioned that maybe is something weird that only happens in the approve context??? that would explain the intermittentness I was seeing
b
it makes sense if you believe that netsuite is storing the field as a string
or at the very least processing it as one
your number 2 is being converted into a string. And whatever internal function netsuite uses ultimately chooses to convert it into the string '2.0'
do the easy workaround and convert it into a string yourself. dont use a number in your variable, use a string
r
That was not working either. Ended up using parseInt on something that was already passed through math.round(). Kinda crazy to me.