Olivier Gagnon NC Red Ribbon

Hey Smitha, You can do nlapiGetContext().getExecutionContext() != 'userevent' There is an example of this in EPI_SUE_SO_Misc.js, should be the first line of beforeLoad_SOMisc().

Since 2012.1 there are now APIs that allow you to programatically create a search and save it, thus making accessible through the UI. That might be an avenue that you could explore.

What is the trigger for this script? Did you check that custcol_item_type is returning what you think it's returning? Stick an alert a the gets to make sure. I don't understand what the logic with the loop checking against the current line is... why do you need to do that? Don't you just check when the user tries to save…

nlapiGetNewRecord().getFieldValue('customform'); works for non-View mode, var thisRecord = nlapiLoadRecord(nlapiGetRecordType(), nlapiGetRecordId()); var thisForm = thisRecord.getFieldValue('customform'); works for View mode

Can you post your code?

Yes it does :cool:

What do you mean by "template"?

Are you making a scratch-built HTML suitelet or is this a nlapiCreateForm() suitelet? Not that I have an answer for you, just curious to know in what situation this happens.

It's worth mentionning that many "commercial" libraries (like JQuery) won't work server-side, only client-side.

I don't think WHAT is returned in the columns is as import as how many columns... but that might be better answered by someone at Netsuite. In my experience I can say for sure if you pull 100 columns, it's a much longer search.

Here is an enlightening post by Evan listing some indexed fields - https://usergroup.netsuite.com/users/showthread.php?t=25490&highlight=indexed Note that, as he says, this is not a complete list. When you call the NS Support Performance group to discuss the speed of a saved search, they will have access to more detailed…

Your first line is bad. var proSupportMail = custscript_val_proSupport; You probably mean var proSupportMail = 'custscript_val_proSupport'; Huge difference bertween the two... Make sure you read up on the concept of variables versus strings. Because javascript is a very loose language, this won't actually give you an error…

Ok, maybe then verify the value of "copyFrom". You can get that invalid record type error if the internal id doesn't make sense for the provided record type (in other words, it's an invalid internal id).

I would look towards optimizing the search speeds as much as possible before coding caching techniques. You can basically optimize a search by filtering as much as possible and returning the bare minimum of columns required. You should also filter on indexed fields, such as Date, as much as possible, rather than non-index…

In my opinion, the more steps you introduce between running the saved search and consumming the results, the more changes there are that something will break. You may gain speed by "caching" the results in some way, but you'll be increasing the maintenance and risk of the solution. You'll also be reducing the "freshness"…

'customrecordcustrecord_new_contract' doesn't look valid to me. You probably meant 'customrecord_new_contract'

Yes, I am glad to see this kind of post. It's good to see the overall scripting maturity of the Netuite Community growing. I think one of the "problems" with Netsuite is that many people see the word "scripting" (as opposed to "programming") and somewhat assume that means something quick and dirty, not too formal - just…

I believe that happens due to the usage of a bundle.

I hadn't really read your code up until now since your initial question was very specific. I'm not exactly sure what all the logic is for, but going by the script description of identifying the location with the most stock, I would pretty much rewrite the whole thing, using nlapiSearchRecord() to fetch the inventory…

Easy peasy. See additions in bold, and check the documention from further details on the type parameter function customBeforeSubmit(type) { if(type=='create') { debug('Before Submit is called'); return chooseLocation(); } }

Edit your UE script and add a check on nlapiGetContext().getExecutionContext() and do not run if the context is 'suitelet'

Er.. the function name is called "customBeforeSubmit()", which I assumed meant you were running as a Before Submit User Event. It sounds like you're in fact running this as a Client-side On Save event. If this is the case, modify the code to function customBeforeSubmit(type) { if(type=='create') { debug('Before Submit is…

Can you post your code snippet? Something is triggering my spider senses

The problem here is that you use up 10 units of metering on each validate line, which causes a risk you might run out of units. It will also slow down the sublist. To avoid this, you should create 3 store value false custom column fields and simply source these field values into them. These custom fields can be hidden by…

What you are trying to do is not supported. Income account comes from the Item record, period. You can't change it at transaction level.

Might be a NS limitation. Try filing a case - you'll either get an explanation or an Enhancement Request number.

In this case I would recommend you simply optimize your logic. Cycle though your members, grab their internal IDs, then call a single Item search to return all the data you want. 10 units is all this will cost you.

As of 2012.1 there is no longer any limit.

You must use nlapiTransformRecord() to instantiate one record from another. You can check the documentation for details.

Eyeing that code, it looks like it should work. Let's go over a few possibilities: a. Are you sure the code is correctly depoloyed? Stick an alert('hi') as the first line of your function. Do you see alerts come up when you change something? b. Are you sure you got the internal IDs right? Those are all AR accounts? c. What…