This article is relevant if you are working with NetSuite’s OneWorld ERP system for order management and you are importing transaction data from a third party system.
Background
As discussed in my other posts, NetSuite is a powerful platform for integration. If you need to import order information from a third party system, you need to figure out your strategy for getting data into the environment. My general philosophy is to avoid integration where possible and use the built-in architecture of the system to avoid non-related third party applications. Yet, that premise is often not possible due to previous commitments to other business systems. So the need to get data to NetSuite becomes a conversation. NetSuite offers a built-in file import process based on comma separated values (CSV). The process works generally well. However, the way you import data may have implications on your subsequent transaction processing.
Ship To / Bill To Address Challenges
For a recent client that sought to quickly get data into their NetSuite environment from their proprietary eCommerce site, they didn’t want to invest in software integration. As such, NetSuite’s CSV file import was the low cost way to solve the problem.
The standard method to get orders to NetSuite is as follows:
- Customers: first import customer information to constitute the record. Be sure to use unique IDs so cusdtomers can referenced on Orders.
- Orders: next import order information with a pointer to the unique customer ID referenced in the previous step.
The quick way to build the data is to import the ship-to and bill-to information (street, city, zip, state) in the order file format. NetSuite will pull the address information right into a sales order without problem. However, we began to see some strange situation after the data was imported that took some time to diagnose.
We had intermittent issues where we created drop ship purchase orders as well as intercompany sales orders where the ship-to information was not copying over from the original order. Strange. We could read the address data without a problem both with saved searches and the SuiteScript API. We then started to see some funny built-in tax rate lookup issues that seem to point to the wrong address information in the state sales tax nexus cross references.
Optimized Order Import Practices for Sales Order Transaction Address Management
After some puzzling diagnostic attempts, we speculated that if we created an address record on the customer entity and then referenced it during the order import, it would solve issues. And indeed it did! It appears that NetSuite simply works better at having address information defined on the customer record and then used in subsequent transactions. Behind the scenes, when subsequent transactions are generated (technically, transformed) from the Sales Order, a pointer to the address record is more reliable than copying over transaction level fields from each document structure.
Example Order Import References
Below are two Excel files to help you see how to enhance your CSV imports to reference the address record. The trick is to create Address Labels as identifiers between customer records and order records. We came up with a way to uniquely identify these address records by using the order number to create a concatenated string. Click links to download the files.
- Customers: sample customer file with bill-to and ship-to labels
- Orders: sample order file that references the bill to and ship to labels
Summary
NetSuite is a powerful yet complex business system. Many times, trying a different approach to solve concerns pays off. If you would like help optimizing your NetSuite account,
contact us.