1. Globalization
  2. Manage Translations
  3. Examples of Customizations Affected by Terminological Changes

Examples of Customizations Affected by Terminological Changes

Saved Search Definitions

  • In Saved searches, translation updates can affect formula definitions. To avoid problems, don't use translation string values in formulas. If you have to, avoid relying on capital letters in those values.

  • In Saved searches, you can only use field values directly—you can't use IDs to reference them.

  • Formulas in Saved searches might use a translated string value, but that value can change during a language update and break your search.

  • If you use values directly, switching to another language can make your searches to fail. For example, if you search for "Bill" and switch into Spanish, you won't get results, because "Bill" isn't a word in Spanish. The search won't break, but the results might be wrong.

Saved Searches in Scripts

Saved searches can be accessed from SuiteScript. If your saved searches give wrong results because of broken references, your scripts might not work.

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 that compares a hard-coded string to a translatable field will be affected.

  • It's better to use string IDs instead of values.

  • During the language updates, some translatable field values might change.

Impacts:

  • The script will probably fail without showing an error.

  • Consequently, the business logic won't run as intended and the 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

  • Translatable field values might change when exported (using CSV, SOAP, ODBC, or REST).

  • Issues with external business integration tools can happen. Make sure your BI tools use IDs. If they can't (like with ODBC), check them after the update to make sure they still work.

  • Customers need to check that their integrations use IDs. If not, they should review all integrations after language update to make sure everything works.

In SOAP:

Use ID references for translation strings you want to export with SOAP.

See screen-shots below for examples of reference an ID (green box) and a value (red box):

  • Sales Order — Status:

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

      Get Sales Order — response:

      SOAP Sales Order response.

    • Update Sales Order status—request example:

      SOAP Sales Order status updated.

  • Purchase Order – Status:

    Here, the value is used directly.

    SOAP Purchase Order status.

In ODBC:

In ODBC, you can't get or use IDs, so you have to use translation string values directly. Don't use capitalization in those references to help avoid issues. After the language update, check all your ODBC exports to make sure that they still work.

ODBC transaction status example:

ODBC transaction status example.

In REST:

In REST, you can use either ID references or translation string values, but it's best to use IDs whenever you can to avoid integration issues. Here are examples showing a value (status field) and an ID (orderStatus field):

  • Purchase Order JSON screenshot — status field:

    Purchase Order JSON Status field.

  • Purchase Order JSON screenshot – orderStatus field example:

    Purchase Order JSON order status field.

In CSV:

With CSV exports, mapping usually depends on column headers and row values. If a header value changes, the mapping will be wrong. Try to base your mappings on IDs if you can. If not, use values without any capitalization.

  • Example – Header values

    CSV Header values example.

  • Example — Row values

    CSV Row values example.

SuiteFlow

  • You can use Saved Searches in SuiteFlow, but if they don't work right because of the changes above, you might see incorrect results or SuiteFlow might not behave as expected.

  • You can also use formula definitions in SuiteFlow. Like in Saved Searches, if those formulas use values, those values might change.

  • Like in other parts of NetSuite, it's best to use ID references instead of translation string values.

  • Example:

    • For example, a custom formula like {approvalstatus}='Pending Approval' won't work in UK English if the status text changes to 'Pending approval'.

    • The right way is to use the ID for the reference, like: {approvalstatus.id}=1

General Notices