Examples of Customizations Affected by Terminological Changes

Saved Search Definitions

• In Saved searches, the formula definition may be affected by the translation update. To limit the number of issues, try to avoid formula definitions containing translation string values, if you can. If you cannot avoid using formula definitions with translation string values, try to avoid dependency on capital letters in string values.

• In Saved searches, you can only use field values directly. You cannot use IDs to reference field values.

• In Saved searches, formulas could use a translated string value. This value can change during the planned language update and the search would not function properly.

• If you use values directly, mere switching to another language will cause your searches to fail. For example, if you search specifically for strings containing "Bill" and switch into Czech, the search will return no results, because "Bill" is not a word in Czech.

Impact: The search will not behave as expected – it will not malfunction, but the results may be incorrect.

Saved Searches in Scripts

Saved searches can be accessed from SuiteScript. Please note that if your saved searches provide incorrect results due to non-functional references, your scripts may not function correctly.

For more information, see Use getValue Function in SuiteScript to Get Value of a Formula Text Field from a Saved Search

SuiteScripts

• Any decision logic based on a comparison of a hard-coded string against a translatable field will be impacted.

• The preferred way is to use string IDs instead of values.

• During the language updates, values of some translatable fields may change.

Impacts:

• The script will probably fail without displaying an error.

• Consequently, the business logic will not be executed as intended and customer's business might be affected.

• Good Practice — using transaction status ID:

                  /** * @NApiVersion 2.x */ require(['N/search'], function(search) { var mySearch = search.create({ type: search.Type.TRANSACTION, columns: ['statusref', 'internalid'], }); var myResultSet = mySearch.run(); var resultRange = myResultSet.getRange({ start: 0, end: 50 }); var counter = 0; for (var i = 0; i < resultRange.length; i++) { var statusValue = resultRange[i].getValue(myResultSet.columns[0]) if (statusValue == 'approved') { counter++; } } log.debug(counter); }) 
  
                

• Bad Practice — using transaction status value:

                  /** * @NApiVersion 2.x */ require(['N/search'], function(search) { var mySearch = search.create({ type: search.Type.TRANSACTION, columns: ['statusref', 'internalid'], }); var myResultSet = mySearch.run(); var resultRange = myResultSet.getRange({ start: 0, end: 50 }); var counter = 0; for (var i = 0; i < resultRange.length; i++) { var statusText = resultRange[i].getText(myResultSet.columns[0]) if (statusText == 'Approved for Posting') { counter++; } } log.debug(counter); }) 
  
                

External Integrations

• Values of translatable fields may change when exported (through CSV, SOAP, ODBC, REST).

• Issues with external Business integration tools represent a known complication among external integrations. You should check your tools and verify that your BI tools are dependent on IDs. If they cannot depend on IDs (for example in ODBC), you should check them after the update and make sure that they work correctly.

• The customer will have to check that their integrations are dependent on IDs, and if they are not, the customer should check all integrations and make sure that they function properly after the language update.

In SOAP:

Use references to IDs in case of translation strings which are to be exported using SOAP.

See the following screenshots for examples of reference to ID (green rectangle) and value (red rectangle):

• Sales Order — Status:

  • The status can be referenced by enum values, for example “_pendingApproval”.

    Get Sales Order — response:

    

  • Update Sales Order status — request:

    

• Purchase Order – Status:

  In this case, the value is used directly.

  

In ODBC:

In ODBC, you cannot acquire and work with IDs, which means that you are forced to use translation strings values directly. Do not use any capitalization in those references to limit the number of potential issues. After the language update, you should check all your ODBC exports and make sure that they work correctly.

• ODBC transaction status example:

  

In REST:

In REST, you can use both ID references and translation string values. The preferred way is to use IDs references wherever possible to limit the number of potential integration issues. Examples: The following examples show use of value (status field) and ID (orderStatus field):

• Purchase Order JSON screenshot — status field:

  

• Purchase Order JSON screenshot – orderStatus field:

  

In CSV:

In case of CSV exports, the mapping is most often dependent on column header or row values. This means that if a column header value changes, the mapping will be incorrect. You should make your mappings dependent on IDs, if possible. If you cannot do so, please use values without any capitalization.

• Example – Header values

  

• Example – Row values

  

SuiteFlow

• Saved Searches can be used in SuiteFlow, and if the Saved Searches don't function properly due to the changes mentioned above, incorrect Saved Search results may appear in SuiteFlow or affect its behavior.

• Formula definitions can also be used and defined in SuiteFlow. Same as in Saved Searches, formula definitions in SuiteFlow may use values, which in turn may be subject to change.

• Similarly to other sections of NetSuite, the preferred way is to use references to IDs instead of translation string values.

• Example:

  • Custom Formula value {approvalstatus}='Pending Approval' will not work in UK English if the status text changes to 'Pending approval'.

  • The right approach is to use ID for the reference, for example: {‌approvalstatus.id}=1

Related Topics:

• Best Practices for Working with Translations

General Notices