Have you considered using SuiteFlow? It might accomplish what you're looking for.

Just keep in mind that fields added via script don't become part of the record type unless you specifically script them to do so, so I think it wouldn't save with the record without an extra step or two. So to store your selected value you might need an afterSubmit script as well to check the scripted dropdown and copy its…

Remember the poster said they ran out of time, not API usage units. All the things you all have said will help reduce the time it takes to execute, though so it's still good advice. Worst case scenario after all optimizations are done, if it still runs too long, you may have to launch a scheduled script from the suitelet…

That sounds tricky. Normally, lists are populated by a static list of values. I'm not sure where to start on this, but perhaps there is a way to do this in a suitescript API

So you were able to get the result you wanted?

Without seeing your code, I'd suggest first you do a quick double-check. Count your parameter positions in the nlapiSetFieldValue call, make sure you can call that function from a User Event Script(seems to me you should be able to), and if you're comparing the field values in suitescript, make sure you're using == or ===…

It sounds like you need a User Event Script, probably of the After Submit variety. That kind will run (server-side) upon creation/saving changes to a record.

I think getFieldText returns the text representation of a field that contains an ID. For instance, when you are looking at a dropdown List, then the Value is the internalID, but the Text is the Name (which is what the user sees). I think this method was invented so you could grab what the user sees (the Name) instead of…

In my short experience with suitescripting, the most common reason for the error SSS_NOT_YET_SUPPORTED is when I am trying to use an API that works great in scheduled scripts or suitelets, etc., but is not supported functionality at all in a Client Script for instance, and I'm calling it from a client side script. Can you…

I know very little about XML-driven NetSuite processes, and not much more about Workflows (although I did read the main chapters in the NS documentation about it). However, I can tell you that if all you need is to have the buttons appear in View, then you can add them using a User Event script, and make sure it runs on…

You can also include client-side script on you suitelet page using form.setScript()

Somehow the documentation didn't mention I needed macrolist and macro tags. Thanks for finding this. You helped me a lot by posting your answer.

I'm new to Workflows too but the first thing I'd check is if the NetSuite APIs I'm using are client-side-only or server-side-only. Many of them are.

Can you post more code? It's not clear what you're trying to do

For your other problem, you can get the same behavior as the "Use Expressions" mode of a saved search by using the undocumented setOr(), setLeftParens(), and setRightParens() functions. As for preventing duplicates either before OR after submission, I don't much trust fuzzy logic. Unique identifiers are the way to go, if…

Hmm, well not having used these APIs before, after reading about them, I would suggest trying to just comment out the nlapiInsertLineItem('custpage_orderlist', lineCount + 1); It seems like nlapiSelectNewLineItem('custpage_orderlist'); puts a line on the end of the list (without committing it) and then…

Not sure how to approach this, but I have an idea if you're doing this with just SuiteScript - maybe you could run some AJAX on the Suitelet's external URL and see what kind of error codes and content comes back. You could even send some parameters and use a specific kind of HTML verb (GET, POST, or others) so it only…

Sounds good. By the way, another way to get logical "OR" behavior is via Formula criteria and using SQL logical operators like the CASE statement (NetSuite MIGHT support SQL IF/THEN, but if it does, it's not documented, either). I haven't used the nlobjSearchFilter.setFormula method yet, but you might look that up and see…

Be aware that setOr, setLeftParens, and setRightParens are not necessarily supported, and are in Beta or something. But I never had trouble with them, personally.

I need this too

ironside, This is where I always go to find that list: https://system.sandbox.netsuite.com/app/help/helpcenter.nl?topic=CARD_-29 I'm not sure if it maps the same on your system, but the Help Center topic is nlobjForm.addField()

Also try this: https://system.netsuite.com/help/helpcenter/en_US/RecordsBrowser/2012_2/index.html

I think I found the problem. I've never used that API before, so when I went into the NetSuite documentation to find out about it, I found this line: "The nlapiGetLineItemCount API is available in Client and User Event scripts only. If you want to get the line count of a sublist in a Suitelet, see…

But before you go doing that, make sure it's necessary. There may be a server-side, more foolproof way to get the data fields before the page loads, or have the user submit those fields in an input form and read them that way.

When I want to work in the DOM like you're trying to do, I create a Client Script, and make sure it gets loaded into the page by adding a line like the following to my User Event beforeLoad Script or my Suitelet Script: var form = nlapiCreateForm('Title of my Suitelet');//just so you know what my form variable reference…

You probably know this by now, but just in case - if you need to check your variables on serverside scripts, use nlapiLogExecution(), not alert().

Another thing that can differ between accounts is the built-in fields "entityid" and "altname". A reference to one or the other can be incorrect or fail depending on how you have your Entity record types configured. I have resorted to nlapiGetContext().environment conditionals to address this, but that makes me design…

Actually I'm pretty sure re-constructing the whole list via an AJAX call will be much more complicated than passing parameters to a refresher request, because you'd have to destroy the list and re-build it using the same parameters you would've passed to the re-post anyway, so that's even more work. Of course I can't be…

Refreshing sounds like the easiest way. It is certainly doable to programmatically go through your entire sublist and wipe/recreate its contents via AJAX call, but that seems like more effort for no added value.

Did you ever figure it out?