Olivier Gagnon NC Red Ribbon

No, that is not possible. Entity Status is controlled by the statuses being associated to a Customer, lead or prospect - that is all. You'll need scripting for different filtering rules.

parseInt() or parseFloat() ?

What you are trying to do is not possible in NS. For a PO to be "billed", you MUST raise the bill from the PO. You cannot attach the bill after creation.

You'll have unpredictable results. ONE of the functions will be the winner, the other will be ignored. Make sure that doesn't happen.

1. Create a button somewhere 2. On click of the button (which is client-side), use window.open() with nlapiRequestURL to trigger a suitelet. Pass as GET param whatever you need to pass 3. Code the suitelet to execute nlapiXmlToPdf() and return the object in its response.write() method.

You cannot use window.open in User Event. The window object exists only in a client-side environment. PDFs are typically generated by Suitelets, as the suitetelet can simply used it's response.write() method to output the PDF document.

Yes. You don't need to do anything special. Anything in a library file can be used just like if it was in your main file.

We spent some time looking at WYSIWYG editors to see if we could use them, take the generated HTML, and turn into into XML, but the differences between modern editors' generated HTML and the required XML is too great, it would not save any time. The idea was floated that a really old editor from the 90s might do the trick,…

Is the problem just that you're missing 10 units on your initial check?

Do you have any code in the recalc hook? Can you post your code?

Hi Jeff, You could call a search, joining on createdfrom and returning type. If you want to be a bit quick and dirty, you can try/catch loading one record type (salesorder) and if that fails, in the catch, try loading transferorder. The second option might sound sloppy, but metering-wise, you're actually better off with…

Mhm. Looking at this script I also come to the conclusion you are only using 12 units, so that's an extra 10 missing from somewhere. Double check, there must be another client-side script or Workflow somewhere eating up 10 units on field change or something like that.

Even if using nlapiGetNewRecord() for read-only activities, your use of the API is incorrect in the above code. nlapiGetNewRecord() does not take any parameters, it is used to return the current record being submitted, not any other record from the system. You definitely want to be using nlapiLoadRecord(). Check the API…

Or, actually, come to think of it, you can just add a hidden store value false field that sources the record type.

Web Services are much more solid for real integration work, yes. RESTlets are really only meant to pull light duty - simple queries and submits - and even there, in a low-volume environment (or else that 40 concurrent request limit is going to getcha). Can't go wrong with Web Services. Haven't met anything you couldn't do,…

Are you getting the Time Limit Exceeded in the RESTlet, or the call to the RESTLet (using nlapiRequestURL)? The nlapiRequestURL() has a fixed limit, so that is easier to debug. But if you're truly getting a time limit exceeded from the execution of the RESTlet itself, that is still possible, yes. The documentation is…

That action does not trigger scripts. you'll either have to forbid use of that screen, or use a daily Scheduled Script to pick up and process any Journal approved that way.

The deployment status really shouldn't have an impact. As the limit is in regards to execution time, this is indeed impacted by server conditions. I will occasionnaly see scripts that work fine every day pop time limit errors one one fine day because server usage is especially high that day. So in general terms, 5 minutes…

Are you doing Inline Editing? That would not indeed work in the below code. Otherwise, the below code looks like it would work, barring unhandled errors (such as the search finding no result.. it will presently crash in that situation)

FYI, we had to do this once, and what we did was erase the email address on the SO, save the fulfillment, and put the email back. This is the only way to selectively send/not send the Fulfillment confirmation email. The email takes its value from the SO "to be emailed" field.

I'm not sure I follow exactly how your process works, but if I focus on your immediate question - No, Web Services will not trigger client-side scripts.

Hello Netsuite does not have an API for dynamically hiding and showing fields based on other values. This can however be achieved by manipulating the DOM directly. Normally, this is a Very Bad Idea, but on a Suitelet, whose behaviour you control much more tightly than any other screen, the risks are reduced, so it should…

Hi Smitha, I would not use RESTlets, I would use Suitelets, as you are doing this within NS, RESTlets are more intended for external access. Since it's an internal process, you don't need the RESTlet's overhead of validating credentials. I would be very curious to see if this approach would work. My intuition says No, as…

A follow-up on this - I was intrigued by the idea, so I decided to run a little test to benchmark the performance of a Sscheduled Script straight processing, vs calling Suitelets. Well, the answer is simple - it doesn't work. Intuitively, one will understand that the only way the Suitelet method would be faster is if the…

Yes, switch to nlapiCreateSearch() so that you can take advantage of .runSearch().getResults(start, end) and bypass the 1000 result limit. The problem with your call here is, however, that you are using the 'internalid' filter, but need to use 'internalidnumber' fiilter when using a "greater than" sort of filter.

But... you can. You can run a search, build a big string by comma-seperating all the values returned from the search, and write it to a file OR serve it to the user as per Brett's method. Maybe I don't understand what you are saying the limitation is?

What is your error? searchResult = objSearchResult.getText('phone'); should be searchResult = objSearchResult.getValue('phone');

Is it deployed, and not in Testing mode? Is it deployed to all roles?

What do you mean by "can't get it to work if there aren't any"? What does not work, and how does it not work?

Well, you said you're already creating the file. So all you have to do is save the file to the cabinet and provide the link. Once downloaded, the user's system will decide if this should be opened using Excel or not (most likely yes, this is the default).