Olivier Gagnon NC Red Ribbon

You must declare a script to be SuiteScript 2.0, otherwise all scripts continue to follow all the existing rules and APIs.

To set a parent, you would need to edit the child and set it's parent field to the correct value. Assuming you are in beforeSubmit execution of the child record being saved, then it would be: nlapiSetFieldValue('[name of parent field]',idOfParentValue); If you're not in a beforeSubmit context, then it would be either…

Well, you can select the Drop Ship Vendor to use on the SO line. The rest of that stuff - figuring out which Vendor to us - you can do outside the system, though you might be able to script that all up. The key is that you need to select the vendor on the SO, so you need to know at that time.

You can create a Suitelet and a Menu item. The menu item triggers the URL of the Suitelet. The Suitelet can have a button that when pressed triggers the process.

It is impossible to fully replicate NetSuite Drop Ship's functionality via scripting. What problems did you face that made you unable to use the native Netsuite functionality?

Ah ha. Well, you have all the pieces, they just aren't in the right order :) Try this: childRecord = nlapiCreateRecord('customrecord_af_shipment_rate') ; childRecordId = nlapiSubmitRecord(rateRecord, true); var parentRecord = nlapiCreateRecord('customrecord_af_shipment'); parentRecord.setFieldValue('custrecord_af_shipment…

This is not possible, by script or by any means. You will need to create a Journal Entry to make the adjustment. If you do that, remember to code a synch module in your script, so that if ever the Credit Memo is edited, the Journal will be as well. And, you may want to script the JE to prevent it from being edited.…

A Suitelet sounds like the right thing. You can create a Suitelet with output scratch built HTML, and being a Suitelet, you'll still have access to all the NS APIs. If you truly insist on using an actual HTML file, then you can essentially have that html page submit to a Suitelet or RESTlet for back-end processing only.…

"Huge number of custom fields" is your most likely culprit...

Do you have script or workflows on the record type in question? How many fields are on the record? How many fields that use sourcing are on the record? Are you loading in dynamic mode?

The size is the size of all your script's variable and stuff, and it has a 5MB limit. Thus to lessen the load, just set all unnecessary variable to null. Obviosuly, the biggest memory eater will be the storage of large arrays, like search results, and variable containing loaded NS objects. There is also absolutely no point…

Hmm. That doesn't look right at all. You may need to contact NS Support.

Just call a search rather than loading

User Event scripts do not trigger scripting on submitted records. You will need to rethink your design.

Journals support User Events. You probably mis-deployed your script or something. Double check the deployment settings

BeforeLoad scripts can set the value of fields when the record is very first being created. After that, they cannot set any field values. That being said, you can use something like nlapiSubtmitField() in beforeLoad to affect a value to a field.

No, indeed, you can't print a Report and attach it, that's just not possible. Closest you could get would be to try to reproduce the report as a search, run the search, cycle through results and output to a CSV (or HTML, or something text-based) and then attach it to the record. All that being said, I don't think that…

Laura, are you testing in a Sandbox? Sandboxes don't send emails. Otherwise, stepping this script through the Debugger is your best bet to figure out what's going on.

That's a pretty ugly scenario. You'd have to verify if beforeLoad would trigger from the mass printing screen, it might not. That would make the printing completely undectable, so then you'd be looking at a change in business rules to accomodate. Otherwise, assuming you can accurately detect someone attempting to print the…

Hi Laura, Scheduled script is indeed way to go. To get the email, I would merge with an email template. This will give you much more flexibility. I would not try to determine time since last email.I would do a Transaction search that looks for MAX of Overdue days, and then send the email on 30,60,90, etc, whatever you…

No this is expected behaviour. Page Init "keeps" some values because they are being passed by URL parameter. You can do the same for SOME fields (Customer mainly comes to mind), but largely, everything will reset. If you really want you can serialize your data in JSON, store it in a file, and then pass the file ID to you…

In other words, don't use a scheduled script. Your user isn't going to sit around 15 minutes while his PDFs are generated. If you do go with a scheduled script, have the script actually generate the PDFs and store them in a file cabinet, then email the user to tell him to go get them. You'll get bloat with this approach…

If you've done a Suitelet, you'll be ok with RESTlets. They are basically Suitelets that cannot have a UI component, but essentially function the same way.

Libraries are not mandatory.

Before Submit user event script with nalpiGetFieldValue('externalid'). You can check context object to confirm it's web services submitting the record.

A script can only run on one record type. You will either be running on the customer OR the job. There are exactly zero situations where a record may have two external IDs. Perhaps you are thinking about parent/child relationship? In such an event, if you run the script on the Job, you would get the Job's External ID. If…

I would modify your existing automated process so it doesn't create the error in the first place. That beign said, if you really want to add a patch layer on top of that, a beforeSubmit script is most likely your best option.

Passing the information as a JSON string to a script param would work. If the string is too big, save the JSON into a file and pass the file internal id to the script. That being said, make sure your design can survive X amount of simultaneous suitelet submissions. At its crudest form, you'll need X number of available…

Well if if you want it to trigger on copy, you would probably do well to remove the condition that specifically causes this script to not fire if it's a copy... In fact, since you don't want to clear fields under any other condition, you want to change that to if(type=='copy')

Looks good!