Best Of

Hey @Jet Zhang,

That's a known limitation, and you need a script for that.

Here is the related article: https://suiteanswers.custhelp.com/app/answers/detail/a_id/79644/loc/en_US

Thank you for your guidance.

Here is the reply from the case:

Currently, the feature you are requesting is not available in NetSuite application services. We have a recorded enhancement request for this feature, which has been updated with information and comments from your account. Our product management team regularly reviews these enhancement requests, and they may be available in a future release.
Enhancement No.: 15971
Summary: Allow more than 2 decimal places for the amount in transactions

Regards,

Zeynep

Thanks @GauravAgrawal

This has been logged as defect by NetSuite support.

I believe this is a setting only NetSuite support can adjust for you. I'd advise opening a ticket with your specific NetSuite instance so they can make that change.

Hi @Meherin,

This is actually an interesting scenario you brought up. And I agree with Angela that there are NO stupid questions here.😉

Anyway, I tried it on my account and was able to reproduce the behavior. Basically, the system is correctly sorting the data since the values of the "month" is numeric.

Good news is that I was able to figure out a an easy solution to this sorting issue.

To ensure your data is sorted chronologically by month and year, we need to include both the month and year in the X-axis of the chart:

Simply add the same Date field to the X-axis part of the chart, then select Year in the Date Hierarchy option.

Hope this helps! 😊

Hi @Elina Kourouzidou

This insight for data migration of 5years data will help you!

Migrating five years of historical transactional data (2021–2026) from one NetSuite environment to another—especially with Multi-Book and Multi-Currency enabled—is one of the most complex ERP projects you can undertake.

Because of NetSuite’s rigid double-entry accounting architecture and system-generated GL impacts, a "lift and shift" of historical transactions is fraught with challenges. Here is a comprehensive guide on strategy, extraction, tooling, and critical "gotchas" based on NetSuite best practices.

1. The Strategy / Approach

In the NetSuite ecosystem, there are two primary approaches to historical data migration.

Approach A: Trial Balance + Open Items (Highly Recommended)
Industry best practice strongly discourages migrating years of closed transactional data (like paid bills and closed invoices). The recommended approach is:

1. Historical GL: Import monthly Trial Balances (as Journal Entries) for the historical periods (2021–2025). This preserves full financial reporting and comparative analytics.
2. Open Transactions Only: Only migrate Open AR (Invoices) and Open AP (Bills/Credits) as of your cutover date (e.g., Dec 31, 2025).
3. Current Year Transactions: Migrate full transactional data only for the current fiscal year (2026 to date).
   Why? This avoids the nightmare of applying historical payments, triggering unmatching Realized Gains/Losses, and recalculating COGS.

Approach B: Full Transactional Migration (If absolutely required)
If you must migrate every single Invoice, Bill, and Payment from 2021 to 2026, you must enforce a strict Order of Operations:

1. Classifications (Subsidiaries, Dept, Class, Location).
2. Master Data (Chart of Accounts, Items, Customers, Vendors).
3. Historical Exchange Rates (crucial for Multi-Currency).
4. Transactions (in exact chronological order: POs -> Receipts -> Bills -> Bill Payments).

2. Critical "Gotchas" & Cautions (From Experience)

Since you are dealing with Multi-Currency and Multi-Book, you must be hyper-aware of system-generated GL impacts:

• Currency Revaluations (As you suspected): You cannot import Currency Revaluation transactions via CSV or API—it is not an exposed transaction type.
  • Workaround: You must either import them as standard Journal Entries (which makes them look different in reports) OR, the better method, import your open foreign currency balances at their historical rates, open the historical accounting periods, and re-run the native Month-End Revaluation process in the new system to let NetSuite generate them natively.
• Realized Exchange Gains/Losses: If you import a historical Invoice and a historical Customer Payment, NetSuite will automatically calculate the Realized Gain/Loss upon applying the payment. If the exchange rates on the imported records are off by even a fraction of a cent compared to the old environment, the Realized Gain/Loss will not match your old GL, throwing your retained earnings out of balance.
• Cost of Goods Sold (COGS): When you import historical Item Fulfillments, NetSuite will generate COGS based on the current item cost logic in the new system. If your historical inventory costing (Average Cost, FIFO) does not match perfectly, your historical margins will be wrong.
• Multi-Book Journal Entries: Standard CSV imports only hit the Primary Book. If your secondary books require different accounting treatments, you must utilize the Book Specific Journal Entry (or Multi-Book Journal Entry) import to adjust the secondary books.
• Legacy Tax vs. SuiteTax: If the old environment uses Legacy Tax and the new one uses SuiteTax (or vice versa), historical tax lines will not map 1:1. You may have to import historical tax amounts as forced line items or journals.

3. Data Preparation & Export Guidance

If you are exporting via Saved Searches to prepare CSVs, you need highly specific criteria to avoid duplicating lines or missing GL impacts.

For Transaction Headers (To create the parent record):

• Main Line = True
• Results: Internal ID, Date, Entity, Currency, Exchange Rate, Posting Period, Memo, etc.

For Transaction Lines (To create the items/expenses):

• Main Line = False
• Tax Line = False
• COGS Line = False
• Shipping Line = False
• Results: Item/Account, Quantity, Rate, Amount, Tax Code, Class/Dept/Location.

Pro-Tip for Data Extraction:
For 5 years of data across multiple subsidiaries, NetSuite Saved Searches will likely time out or hit row limits. Instead of Saved Searches, highly consider using SuiteAnalytics Connect (ODBC/JDBC) or SuiteQL. This allows you to run SQL queries directly against the NetSuite database to extract massive, clean tables of your historical data.

4. Helpful SuiteApps, Bundles, and Tools

NetSuite does not have a native "Account-to-Account Transaction Copy" bundle. (The native Copy to Account feature is strictly for metadata/configuration, not data). However, the following tools are standard for this scenario:

1. Celigo (integrator.io): Celigo is the gold standard for NetSuite integrations and has pre-built "NetSuite to NetSuite" connector templates. It handles the API mappings much better than manual CSVs and can dynamically look up Internal IDs (e.g., matching Customer Internal ID "123" in the old system to "456" in the new system).
2. Boomi / Jitterbit: Similar to Celigo, these iPaaS platforms are highly recommended if you are attempting a full transactional migration. They allow you to build logic to say, "Import the Invoice, then import the Payment, then apply the Payment to the Invoice."
3. Salto or Strongpoint: While these do not migrate transactional data, they are incredible tools for migrating configuration (Custom Fields, Scripts, Workflows, Chart of Accounts). You should use these to ensure the new environment's architecture identically matches the old one before you push data.
4. NetSuite CSV Import Assistant: If you decide to go the "Trial Balance + Open AR/AP" route, the native CSV import is perfectly sufficient. Ensure you map the Internal ID from the old system into a custom field called Old System Internal ID in the new system so you have a traceable audit trail.

Hi @Audrey G.

You can change it by going to the script record itself then go to Unhandled Errors.

Instead of checking the Notify Script Owner, input the email addresses you prefer to send the errors (make sure to unmark the Notify Script Owner if you don't want the owner to be notified).

If you need to send it to multiple emails, list the emails separated by comma

e.g: abc@company.com,xyz@company.com

You can refer to Item 12 of this article: https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_4489062315.html#procedure_4489062240

This is the only way you can change how that script sends unhandled errors during its execution.

However, you cannot change the settings if the script is locked (which is most likely the case since the email you showed came from AvidXChange script).

You can reach out to the bundle owner if you have questions related to their script.

Hi, @User_WA9MO

Please check the Custom Form for that transaction, and check the Rate field if there is no rate in that transaction. This is similar to the "Requisition" feature; unchecking the "Rate" field will impact the purchase order generation.

Hi @Dext3r!

Good day!

You’re correct! After Field Edit is a client-side trigger, meaning it runs in the browser before the record is saved. Because of this, NetSuite’s standard workflow execution logs only capture server-side events. As a result, you won’t see any execution history in the record’s History tab, and the workflow instance log won’t record those client-side actions.

To troubleshoot, you can temporarily change the trigger to Before Record Load or Before Record Submit to confirm that the condition and action are working. If you have SuiteScript access, using the Script Debugger can also help you debug the client-side behavior.

Additionally, you may submit an enhancement request for this so it can help users in the future who may encounter the same issue.

As for the workflow, can you try to do the following:

1. Select Customer for the Triggering Client Field

When you use the After Field Edit trigger for an action, you must also identify the name of the client field in the Client Fields multi-select box for the action. This identifies the fields that, if changed, change the values of other fields. (SuiteAnswer 40493)

2. For the condition, make sure it is matching the internal ID and not the display name.

3. Temporarily also check "On View or Update" on the workflow state with a Before Record Submit action, this will show in logs after save, confirming your condition works. Once confirmed working, revert to After Field Edit.

Kindly let us know how it goes, thank you!