https://netsuiteprofessionals.com logo
Join Slack
Powered by
if i'm reading the documentation correctly, `setTe...
# suitescript
k
if i'm reading the documentation correctly, 
setText
performs coercion/interpretation (and maybe lookup? such as item name -> internalid?), as though a user had typed something into an html text input and 
setValue
expects the "raw" value? (that is, whatever the result of `setText`'s conversion would have been?) -- is this a correct interpretation? in the records browser, there are a number of types listed but it's unclear to me what JS value will "work" with setValue. for example, does "currency" expect a string (
"1.23"
), a number (
1.23
), or accept either? do checkboxes need booleans or do they want "T"/"F", etc? is there some documentation page laying this out?
s
NS isn't entirely consistent around types but it is better in 2.1 that it has been in earlier versions. In general, checkboxes should be native booleans now.
k
is there a table documenting these inconsistencies, or some way to query the api as to what kind of data a field is expected to be?
woocommerce apparently is inconsistent too, it's returning some currency values as strings and some as numbers 😞
i think the problem i'm encountering is setting "amount" as a string, because that's what i received
n
k
yeah, my question was more like... how do i interpret what the records browser says so that i know what code to write
which seems to "kind of" spell it out enough, probably
n
Typically you only use getText on list fields, so that you get the text value rather than internal id. And on that basis setText too but there are caveats to using setText.
*and multiselect
Other than that you would typically use setValue unless my aging brain is failing me 🤭
k
list field = "select" field?
👍🏻 1
e.g. "item" on the "item" sublist
n
Yes sorry, it's a "select" field using list/record my bad I always call them list fields since the source is largely irrelevant and is a "list" to the user. 🙂
k
thanks for the guidance
it's very valuable to have this kind of feedback from someone with experience 🙂
s
Yes, prefer get/set Value over text when possible!
k
i wonder if this is a documentation error?
For rate and ratehighprecisionfields, use the Record.setText(options) method to set a string value with a "%".
record browser -> sales order -> sublist "item":
rate rate Unit Price false
unit price doesn't seem like it should be a rate / percentage?
or am i misreading what it's saying
seems like only "percent" values should have % - but perhaps "rate" means "float as a string so there's no floating point error concerns" and thus set it as a string so it can be parsed as a fixed point decimal
b
the setText and setValue are used when a field has multiple representations
the most obvious one are select fields
they have an internal id value, and a display text
with setValue using the internal id while setText using the display text
the least obvious being a date field, which uses a Date as a value and the date formatted as a string for the text
your choice, rate, is normally a number, but can be a percentage when used with discounts
for example, a 50% discount would go in the rate field, and in that case, you would use setText with "50%"
k
you wouldn't just use 
setValue
with 
.5
?
or can't use it?
b
thats the sort of question where its easier to just try it
n
set the rate field to .5 and you're staring down the barrel at a 50c/50p etc etc item
k
i'm probably not going to use it, but the general code i've put down i'd like to be correct as much as possible
ah sorry, context here is "setting a percent by value"
the docs say not to do it
but you've suggested many problems with setText so i'm wondering, if "50%" is what i'm supposed to use for setText, can i just use "0.5" for setValue?
n
To be fair that's fairly unusual. quantity * rate = amount you'll find I don't recall ever setting rate to a percent but that's probably using a price point from the item itself and applying a percentage to it.
setValue 0.5 not "0.5" but if you try "0.5" that may well work too 😄 (as currency value not %)
b
there is special behavior on the rate for a discount (or markup)
being that you can use a fixed rate of 50 to represent a increase in price of $50
or a percentage rate of 50% to represent an increase in price of 50%
k
haha yeah, sorry. i should have use 
"50%"
and 
0.50
but that's what i meant
b
if you used .5 for the value, thats a price increase of .5 dollars
k
anyway, 
rate
does seem to mean "Unit Price" in the context of a Sales Order item - i finally got a full api call to go through
i see
that's super weird behavior, good to know about
s
it's weird from a code mindset, but I certainly sympathize with users wanting to specify discounts easily as fixed amounts OR percentages. What's odd to me is NS shoehorning it into a single field.
k
yeah, something someone said recently improved my mental model a lot
i had been thinking about this as a code api, but it isn't really
it's more like the backend to a user-facing frontend that we get access to
they've maybe implemented things with a tighter coupling between the user-facing / presentation layer and the backend/behavior and that's how you get stuff like this
so thinking of this code, even though it's running in a backend context like an api, as more of a macro/scripting layer makes things make more sense
27 Views
Open in Slack
PreviousNext
Powered by