We've struggled with this recently. We circulated the question pretty high up the support chain, but NetSuite engineers were unable to provide an answer. It *appears* to be a character count limit more than an actual quantity limit, which makes things interesting. You're going to have to trial & error it until you find…

There are reasons why this approach was necessary. And actually, surprisingly, the performance of the approach is surprisingly decent. I agree in general with the statement of "try to avoid doing it this way", but if for {reasons} you have to go this way, it can actually work.

Yeah we're doing the same. Give it a shot and catch the error. No, no ideal. "Not ideal" kind of sums up all of SS2.0 though.

Alright so I checked and we have quite a few scripts where we are tagging the transaction. I also checked an account where we have script running and confirmed the email was properly attached to the transactions, so fundamentally that seems to be working. I will say though that none of these were via a map/reduce, so if it…

This is a defect, contact NS to get in on it.

peterbell hmmm parseFloat didn't work either - however, on editing the record rather than creation it works fine... trouble is, we want it to work on create! Hmmm... what are you running this on, After Submit? Try loading the record and then read the values, rather than going with newRecord. Strongly suspect this isn't a…

What the heck... Can you add logging to output value before parseInt as well? Shot in the dark - try parseFloat() instead?? I've never seen parseInt blank out a value. At worst it should return NaN.

Hey Joe, Check out in the help: SuiteCloud (Customization, Scripting, and Web Services) / SuiteScript 2.0 / SuiteScript 2.0 API / SuiteScript 2.0 Modules / N/currentRecord Module / currentRecord.Field / Field.insertSelectOption(options) Brand spanking new: was released in late November.

Errr... that IS quite odd. parseInt as an optional secondary param, the base. Maybe trye fully writing parseInt(value,10) Otherwise, post your code snippet? Might just be some sort of easy mistake you need a second pair of eyes on

Hi Peter, Use parseInt(value) Cheers

Yeah you're right, could be a lot of things actually. It could be a defect, but could just be some bad code. NS seems to throw that particular error message a lot for different reasons. If you're seeing that error message when Web Services saves a record with scripting that otherwise runs fine via the UI, then that's…

The SO will not trigger upon its status change. This is common throughout NS object status changes. Scripting only triggers on the record where the action actually occured, not on any secondary record updates. You need to put your scripting on the record/event that causes the status change - in this case, the Invoice or…

We haven't had a chance to try the new 2.0 stuff, too recent.

So, sidestepping most of this and just answering the easy point: there is a search column for rate. It's programmatic ID is 'rate'. It is called 'Item Rate' if you are using the UI.

Well there is now the per-Import "trigger scripts" preference, so did you check if that was always ticked in? Otherwise, no, I haven't had the problem of CSV misbehaving like that.

Ohh, sorry, I see what you mean now. Yeah, looks like NS is dropping the info that this is a percentage. I would look at a solution where you divide the discount amount by the amount of the line above to determine the effective percentage. Looks like there is a flaw there where NS fails to capture the percentage anywhere…

I'd get NS Support involved. Should be an adequately patience-testing experience, but there doesn't seem to really be anything else obviously wrong.

Out of curiosity, what are the results of the getLineCount if you do isDynamic false?

We have this as Defect 367714

Yeah SS2.0 is whacky like that. I think you need to be in dynamic mode to getText, but I'm not clear on that. Anyway, yeah, you often cannot getText. Part of life under SS2.0.

Well, that's unpleasant. I don't have any further ideas

Hmm. Something must be failing in core NetSuite code. I'd file a defect (for what that's worth).

They released field.getSelectOptions() like 2 weeks ago, so haven't played with it to find out how it behaves.

Ouch. Using SS1.0 it is then...

Yeah that's annoying... try enableSourcing true on the save. Grasping at straws here, I know...

Hi John, Could be several things, but if I had to make a bet, I'd say that what might be happening is that when you submit the record, it triggers all existing scripting deployed on that record. So maybe another script is failing and the error is bubbling up to your submit. I would not rule out that, as all scripts are…

You don't need selectNewLine. Just set value on the next highest line index.

Yeah it's been a challenge trying to love SS2.0. I would not advocate strongly against ditching 2.0. I think we're going to stick with it, but I wouldn't fault anyone for abandoning it.

Have you tried switching from .setCurrentSublistValue to .setSublistValue, without the selectLine? Not saying that'll necessarerily work, but when one method doesn't work, usually the other does.

Yeah there is a defect that SS2.0 trigger for scriptable checkout if deployed to all roles. Such scripts immediately crash your website because they aren't supposed to run and NS is unable to load them properly. The workaround is exactly what you did, or to put an if(context=userinterface) kind of clause inside the script.