netsuite The Client Script


Example

The Client Script is one of the more commonly used, and complex, script types available to you. As its name implies, the Client Script runs in the browser, i.e. on the client side. It is the only script type that runs on the client side; all others will execute on the server side of NetSuite.

The primary use of the Client Script is for responding to user interactions with record forms within the NetSuite UI.

As soon as the user loads a record form in Edit mode, a pageInit event is fired that we can use to run code as the form is initialized, before the user can interact with it.

Whenever the user then changes any field on the form, a series of events will fire:

  1. A validateField event fires that allows us to validate the value the user is trying to enter in the field. We can use this to either accept or prevent the change from taking place.
  2. A fieldChanged event then fires that allows us to respond to the new value in the field.
  3. Lastly, a postSourcing event fires after any and all dependent fields have also sourced in their values. This allows us to respond to the change and make sure we are working with all of the correct data.

This series of events fires no matter whether the user is changing a body field or a sublist field.

As the user does make changes to sublist lines, another series of events will be triggered:

  1. A lineInit event is fired whenever the user initially selects a new or existing line, before they are able to make any changes to the fields on the line.
  2. Whenever the user clicks the Add button to add a new line, a validateLine event is fired that allows us to verify that the entire line is valid and can be added to the record.
  3. Whenever the user clicks the Insert button to add a new line above an existing one, a validateInsert event is fired, which works exactly like the validateLine event.
  4. Similarly, whenever the user tries to remove a line, a validateDelete is fired that allows to either allow or deny the removal of the line.
  5. [SuiteScript 1.0 only] Lastly, after the appropriate validation event succeeds, if the change to the line also effected a change to the total amount of a transaction, then a recalc event is fired that allows us to respond to the change in amount of our transaction.
  6. [SuiteScript 2.0 only] Lastly, after the appropriate validation event succeeds, a sublistChanged event is fired to allow us to respond to the completed line change.

Finally, when the user clicks the Save button on the record, a saveRecord event is fired that allows us to validate whether the record is valid and can be saved. We can either prevent the save from occurring, or allow it to proceed with this event.

The Client script has by far the most events of any Script type, and the most complex relationship between those events.