In this first installment of Cross Instance Script Configuration, I am going to go over some of the major benefits of designing a cross instance configurations as well as exploring some key design components of such an enhancement.
Let’s first get some background on why is this necessary. In Netsuite, there are two different classes of instances, Production and Sandbox. Production instances include your production account and any test account instances. The test account instances usually start with TSTDRV. These instances are created as a new blank instance. The big difference between production and Sandbox instances is that production instances can Not be copied from any other account. They can only be initialized. That is, recreated as a blank instance. Sandbox instances, on the other hand, must be created from a backup of your main production instance. Your production URL is usually in the form of https://{Your Netsuite Account Number}.app.netsuite.com/…
As updates are made to the different instances, the internal IDs assigned to custom objects are initialized. Typically, but not always, in numerical order. These numerical internal ids are system assigned and not allow to ever change (immutable). Examples of such objects are custom record types, custom fields, scripts, custom lists and saved searches to name a few.
*Note: All example scripts are using SuiteScript 2.1
Typically, a Netsuite programmer would write something like this.
// Fradgile, Instance specific code
customerRefundRecord.setFieldValue('account', '1033');
This is perfectly valid, but this code is not very durable across multiple environments. The ID of the GL Account will have to be updated in each instance. It also is not easy to interpret which GL Account is being used here. Sure, you could add a comment. But, wouldn’t it be much better to use the following?
customerRefundRecord.setFieldValue('account', config.AR_ACCOUNT);
In this example we are using a configuration setting for this Netsuite Instance instead of a hard coded value that may not point to the same GL Account in other instances. Using this approach, each instance will have its own copy of the configuration, holding the values for that instance. In this example, providing the configuration has been updated with the IDs for that instance, this code can be moved to any instance without breaking.
Never use numerical internal ids if there is text id available! Text Ids will be the same across all instances. Numerical Id will almost always be different.
In our next part, we will dive into the nuts and bolt of how to implement a robust solution to this problem. Stay Tuned…