The record has changed error is thrown because of the following sequence of events: Process A loads Record 123 Process B changes Record 123 Process A submits Record 123 The process could be a script, web services call, user's web browser, etc. There's no one catch-all solution, but following some best practices can help:…

Absolutely, with our SuiteApp Assertology, you can record a user performing a critical business process. The process could be the creation of a single sales order with a certain number of lines or it could be a more complex process including a series of records such creating and invoicing that sales order. The process is…

It sounds like you've tried a bunch. I don't have personal experience with it, but among NetSuite customers 8x8 is a popular choice.

Have you considered restricting each role to an appropriate custom form where only the desired fields are visible?

Using a mass update script is a quick way to delete a lot of records. Create a script as follows and deploy it to the record types you'd like to mass delete. Then run it as a custom mass update. function delRecord(type, id) { try { nlapiDeleteRecord(type, id); } catch(err) { nlapiLogExecution('Error', 'Error Deleting',…

See https://usergroup.netsuite.com/users/forum/platform-areas/customization/suitescript-custom-code/301970-is-it-possible-to-trigger-a-script-by-sandbox-refresh

Confused here, according to NS, the "Netsuite Sales tax table" is FROM Avalara. How does this table differ? see "importing the tax table" answer id:8045 I work with the Thomson Reuters tax team so I can illuminate some of the shortcomings of NetSuite's sales tax tables and the enhancements that a third party tax engine can…

The easiest way to replicate your NetSuite data locally would be via ODBC. After the first pass, you could have a scheduled job that queries for updates based on last modified date. You would need the advanced reporting module to accomplish this. I've used this approach to speed up read-access to NetSuite data. As Oliver…

You could accomplish this with a grouped saved search that is configured to send an email only when there are results, but scheduled saved searches only run once per day so you would have to create 24 of them for the system to check hourly. Aside from that, I think it would require a script or workflow.

I believe that CSV imports and custom mass update scripts are options for updaing mult-select fields.

If you already sent the email and want to recall it, unfortunately you're out of luck. If you'd like to set up a system where you can send recall-able emails, there are options. For instance, an externally referenced email can be pulled from the server making the email appear blank when opened afterwards.

When transforming (i.e. sales order into invoice) an open transaction, you will get a warning that the transaction has inactive departments and that you should remove them if you don't want the balances to change. You still have the option of disregarding the warning and saving as-is.

It is scriptable, and you can distinguish it from other invoices by looking at a checkbox on the record - I think the script ID was finchrg or something like that. But while they are scriptable, keep in mind that user event scripts are not triggered upon their creation. So you will need to use a scheduled script instead.

Thanks pcutler, Were you ever able to create one using script? I see that an nlapiGetFieldValue('finchrg') gives back a value of "T" while in the UI but when I create an invoice using nlapiCreate/CopyRecord I can't set the field on the nlobjrecord object. No, I don't believe you can create one via SuiteScript. You might…

The error message appears to indicate an error in the postsourcing function of a form-level (as opposed to record-level) script. Have you checked the form to see if you've removed the script from the custom code tab of the custom form definition?

A long time ago, using the SuiteScript 1.0 API, I appended the job ID that is returned by nlapiSubmitCSVImport at the end of the CSV response URL (/app/setup/upload/csv/uploadlogcsv.nl?wqid=) and downloaded that file using an NL auth header with a username and password to log in. Then I parsed the CSV file for all the…

Thanks for chiming in. Since scheduled workflows don't trigger user events for us to test and check the context, the only indicator of the context I'm aware of is the system notes. In the system notes, the context is reported as "Scheduled Workflow." I'd expect that user event scripts would be triggered from within that…

You should be able to check [h=1]runtime.executionContext[/h]

If you need a work-around, you could try using one line of SuiteScript 1.0 in your script as follows: window.nlapiGetRecordId()

JohnCCole has the correct answer above, and that's what I'd recommend. However, if for some reason you did need to have a global client side variable, window.myGlobalVariable = 'hello world' would work.

You can write a client script that calls window.setInterval in its page init event to periodically check if the file is available, and display a message when it's available. Be careful not to exceed NetSuite's API governance limits though.

A before load user event script can change the label of a field if you need the label to be dynamic. With that approach, to see the label change you would have to refresh the page. I don't believe there's a supported API method to change a field label immediately based on a user selection on a form.

Let's say you have a form with a client script that searches if a name is unique after a value is entered in the name field. When you use currentRecord.setValue to set the name field, your client script will run the search. This parameter specifies whether you want the following JavaScript statement to run immediately or…

I haven't encountered this use case myself, but have you tried using a formula text search column to look up the unrounded database value if NetSuite's JavaScript APIs are rounding the numeric value?

A vendor can be linked to multiple subsidiaries, so make sure you select the same subsidiary as the checking account if that subsidiary is not the vendor's default. Also, I'd try setting dynamic mode to true to see if that makes a difference.

Hubert, the validation & defaulting section is the right location for that. To offer one other option, if you're using saved searches to display data you can also bold/highlight fields on the highlighting tab of the saved search.

Here's a quick script I threw together. You may need to adjust for your needs. I haven't tested it, so there could be some typos/bugs. Good luck! require(['N/search', 'N/currentRecord', 'N/email'], function(search, currentRecord, email) { //get the shipping method from the appropriate field var SHIPPING_METHOD =…

I haven't seen any updated documentation on this for SuiteScript 2.0, but if I recall correctly SuiteScript 1.0 truncated search results at 4,000 characters. The only way to access the full data element was to load the record. I imagine this behavior would persist in SuiteScript 2.0 unless there have been any announcements…

You're correct, the highlighting feature would highlight the whole row. If you need to highlight a single field, you can use Veda's approach from above in a "Formula Text" search column field.

You can use the address pseudo-fields from SuiteScript 1.0 as a workaround, i.e. nlapiSetCurrentLineItemValue('addressbook', 'city', 'San Francisco'); From NetSuite Help: [h=3]To Create Addresses, You Must Use Subrecord Methods[/h] The address subrecord was introduced in version 2014.2. Prior to that time, each address was…