About us: Salto's platform helps you and your team deploy, track, and manage your NetSuite customizations effortlessly. Learn more here.

‍

Introduction

Let’s face it, we have all run a NetSuite CSV import at one point or another and held our breath as we wait for the import process to complete and hope that there are no errors to investigate/resolve.

The reality is that CSV import errors are unavoidable and will crop up from time to time, especially with new imports that are not tried and tested. In this blog post we will explore some best practices to adopt in order to minimize the risk of getting errors when running this key process in NetSuite.

‍

‍

Mistake 1 - Not understanding reporting segment access impact

Many objects in NetSuite have segmentation dependencies. For example, customer records (entity object) with primary subsidiary set to subsidiary A can only have transactions associated with it for subsidiary A. If you attempted to import a transaction for this customer with subsidiary B, the CSV import would fail and you would receive an error message along the lines of:

“Transaction subsidiary <subsidiary_name> is not valid for entity <customer_name>. Please choose a different entity.”

This holds true across other NetSuite reporting segmentation. Subsidiary, Department, Class and Location are some of the key ones. You will have to factor in any custom reporting segments in your own NetSuite environment.

Another common example is when a transaction is imported into NetSuite and the transaction department value is not valid - perhaps the department does not have access to the proposed transaction subsidiary. In such a case, expect to receive an error message along the lines of:

In short, it is important to understand your NetSuite environment reporting segmentation, especially where you have custom assignment of subsidiaries to departments, classes and locations. When I receive a NetSuite CSV import error for a transaction import, this is typically one of the first (if not the first) things I check .

‍

‍

Mistake 2 - Not understanding user role access impact

User role access is just as important as understanding your reporting segment access.

‍

‍

If a user role does not have the appropriate access to create/update specific records in NetSuite, then attempting to perform a CSV import to do the same thing will result in a failed import.

This does not only apply to subsidiary access on the user role, but also other reporting segments.

‍

‍

As such, user role access to reporting segments should be top of mind before performing a CSV import. That said, there are some CSV import errors that appear to be user role access related, but are not. Here is an example CSV import error message:

“You do not have permissions to edit this transaction” when using the Administrator Role.

This error typically occurs when the user attempts to update a transaction record when the corresponding accounting period is closed. With the period closed, the user is unable to edit the record, unless the “Allow Non-G/L Changes” checkbox on the period record is checked.

‍

Mistake 3 - Assigning incorrect field mapping

Completing the CSV import field mapping exercise is the most critical step in the process. It is all too easy to map the incorrect data to a NetSuite field, so make sure you take your time when working through this step. Field names can be similar, on both the NetSuite side and column headings in the source CSV import. As such, it is important to give each column a name that makes sense - sometimes that will mean not naming a column to directly match NetSuite e.g. so you don’t forget to update the mapping to use Internal ID vs Name.

‍

‍

Salto Tip: Some fields will need to be removed from the CSV import mapping step, even when using a saved CSV import. “Item” is a good example when importing certain transactions. If you are uploading directly to general ledger accounts, you will need to remove “Item” from the mapping.

‍

Mistake 4 - Using name references instead of Internal ID

It is definitely possible to use name references for CSV imports and not run into any issues, however you can reduce the risk of error by instead referencing the “Internal ID” of a record.

For example, if importing a list of sales orders you are able to use the customer “Name” reference to ensure the transactions are associated with the correct customer. Customer names change. The internal ID of the customer record does not change and is therefore a more reliable source of reference for a CSV import.

Another great example would be an import for an entity record such as a customer. You may receive an error confirming that the subsidiary is not valid for the associated entity record. This will typically occur when the subsidiary name is not formatted in the required manner and result in an error message along the lines of:

“Transaction subsidiary X is not valid for entity X. Please choose a different entity.”

In this case you have a couple of different options. You can restructure the “Name” reference to include the full subsidiary hierarchy, with colons as separators, or you can simply reference the internal ID of the entity record.

Salto Tip: The required format for subsidiary “Name” could look like: Consolidated Parent Subsidiary Name : Child Subsidiary Name : Grandchild Subsidiary Name. Avoid this complexity and use internal ID.

‍

‍

Mistake 5 - Avoiding CSV import templates

CSV imports can take time to build, especially when you have more than 5-10 columns to map. How many times have you created the same CSV import, from scratch, because it was only a handful of fields and shouldn’t be an issue (only to find out it has errors)? Don’t forget it is ok to create temporary saved CSV import templates - simply delete them after they have served their purpose.

If you are creating the same CSV import process more than once then you should be creating a template for it, so that the field mapping can be used again for future imports.

You should also take the time to have a consistent CSV import format for all key import types. That way, you do not end up with 50 different journal entry import templates and users struggle to find the one that they created 2 years ago, for example.

‍

‍

Salto Tip: After creating a saved CSV import template, don’t forget to modify the access accordingly, so that other users can utilize the template. If a user is unable to see the import template in the list it will be because the access has not been updated.

‍

‍

Mistake 6 - Forcing all CSV imports into a single queue

Many NetSuite customers, even customers on the “Standard” Service Tier have access to all 5 CSV import queues. Make sure you use them!

If you are only using one CSV import queue, then each import must be processed sequentially, in the order they were uploaded. With 5 queues, you are able to process multiple CSV imports at the same time. This can be especially helpful during busy periods, such as month end close, when many teams are trying to get data into the system as quickly as possible.

e.g. You do not want your accounting team waiting to create journal entries records, because your accounts payable team is loading a batch of vendor bills into the system.

‍

‍

Note: This functionality is only available for customers with at least one SuiteCloud Plus license, else you will only have access to a single queue and single thread per queue, which is not ideal.

‍

Mistake 7 - Missing important data points for key objects

Each record in NetSuite will have some number of mandatory data points and for the most part these fields are mandatory before the record is able to be created or saved. When trying to import a record without mandatory custom fields the import will fail and the error message will confirm as such.

Note, you are able to override this behavior by unchecking the “Validate Mandatory Custom Fields” setting on the CSV import options page, under “Advanced Options”.

There are however some records that have mandatory data points despite those fields not actually being a mandatory field. A good example of this is the item record. Item records can be created in the system, saved and updated without populating a value for “Base Price”. If you attempt a transaction CSV import that references an item with no “Base Price” you will receive an error message. The error message never explicitly calls out the item as the root cause of the issue and it requires investigation.

As such, you should ensure the “Base Price” is set to zero. This will ensure future CSV imports will not result in an error, because the “Base Price” value was left blank - which NetSuite allows you to do.

‍

‍

Mistake 8 - Forgetting to leverage External ID

When importing transactions from an external system, such as a CRM application, it is important that a unique reference to the source system is maintained for ease of reconciliation between the two systems. You should capture that unique reference in the NetSuite External ID field.

External ID values also allow you to group lines in a CSV import that belong to the same record e.g. when creating a sales order record with multiple lines. This will help to ensure records with multiple lines do not end up as separate records in NetSuite.

Note: Each External ID value must be unique for each record type in the system (entity record vs transaction record). A CSV import file that attempts to create a new record with an External ID already in use will result in an error message along the lines of:

“This record already exists.”

‍

Mistake 9 - Not multi-threading on large import files (where possible)

The Multi-threading functionality allows NetSuite to process CSV imports more efficiently. When the function is enabled for a specific CSV import, NetSuite will process CSV import rows concurrently, across multiple threads. This functionality should only be used if the order or the lines being imported does not matter, which in many cases it will not.

A good use case for using multi-threading is the creation of a long list of new vendor records. The order in which each vendor is created is not important, as there are no dependencies between the records.

A bad use case for multi-threading is the creation of your chart of accounts in NetSuite, as some records will have a parent/child relationship and as a result the order in which the accounts are imported is imported. You run the risk of NetSuite attempting to create a child account before the parent account exists, which will result in a CSV import error.

‍

‍

Note: As for multiple CSV import queues, this functionality is only available for customers with at least one SuiteCloud Plus license, else you will only have access to a single queue and single thread per queue.

Best Practices for working with NetSuite CSV imports

1. Review your reporting segment access prior to importing data.
2. Review your user role access prior to importing data.
3. Double check your CSV import field mapping prior to importing data.
4. Use Internal ID references instead of Name references, as these will not change in the future.
5. Make use of CSV import templates wherever possible.
6. Leverage all 5 queues available for CSV imports (requires at least one SuiteCloud plus license).
7. Ensure all key objects have required data points populated (even if not mandatory) e.g. items should have “Base Price” populated, even if zero.
8. Leverage External ID for CSV imports to link records back to an external system for ease of reconciliation. As this is a unique value for each record it can be used for ease of reference within NetSuite.
9. Multi-thread wherever possible to improve the performance (processing speed) of your CSV imports.
10. Keep a centralized library of all CSV import errors and how they were solved. Each NetSuite environment has unique nuances to them. SuiteAnswers can be a great source of information, but sometimes you just need to dig deeper yourself and learn for next time around.

For more information on these best practices, check out Salto’s blog posts that explore some of the things that NetSuite Developers and NetSuite Administrators should consider when working within the NetSuite ecosystem. By following these best practices, you can manage your NetSuite CSV import processes efficiently and effectively.

‍

Final thoughts

The NetSuite CSV import tool is essential for any NetSuite Administrator or Developer. The tool is especially important when standing up a brand new NetSuite implementation and you need to create NetSuite records in bulk with data from an external source (legacy ERP). Don’t forget to test these imports in a Sandbox environment to iron out any CSV import errors before importing the data into the Production environment.

Without an appreciation for the inner dependencies within NetSuite, CSV import errors can be extremely frustrating and time consuming to resolve. With some appreciation for the points we discussed in this blog post, you will find that CSV imports are a game changer and that trouble shooting is not as difficult as it may seem to other users.

For more information about specific CSV import errors, check out the NetSuite documentation here for CSV Import Error Messages.