Best Practices for Order Sync
The following discusses the details of best practices for order syncs.
Customers
Customer Matching
When an order sync runs, the customer is synced first, so that the order can post against that customer. NetSuite Connector matches customers on orders to existing customer records in NetSuite by company name or name and email. This ensures that NetSuite Connector does not match to the incorrect customer record. If NetSuite Connector finds multiple customers that match by both company name and name and email, NetSuite Connector will match to the oldest (by date created) customer record. It is important to ensure that your company must not have duplicate customer records in NetSuite to avoid confusion regarding which customer NetSuite Connector will post against.
For orders that do not have an email address, a commonly observed practice is to add a default email address on the orders at the storefront. This creates a customer record with that email address in NetSuite. New customer addresses are added to the address list of the customer record when orders that use the default email addresses are received. The amount of addresses in the customer record will increase over time. You can manually delete addresses from the customer record to keep it below 1000 lines. Alternatively, you can create an order mapping that prevents orders from adding new address lines to the customer record. For more information, see Preventing Addition of Address Lines to Customer Record.
Address Forms
NetSuite Connector supports the use of only the default NetSuite address form when syncing customer address information. The default form provides the fields for the required address information and accept values that various storefronts provide for that information.
Taxes
Tax Rates
The best practice for taxes is to have NetSuite calculate the correct tax code and rate for an order based on that order’s shipping address. Then, allow NetSuite Connector to overwrite the tax rate with the rate that was charged on the marketplace or cart. NetSuite does not allow explicitly overwriting the tax amounts, but only the rates. This is the reason that this is the best practice.
Tax rates in your marketplace or cart and in NetSuite on synced orders will always match.
There can be situations where your marketplace or cart charges a slightly different rate than NetSuite does, but even in this case, or if your marketplace or cart’s calculation is incorrect, the order totals in NetSuite (including taxes, discounts, and others) should match what your customer paid. This is the reason that this is the leading practice.
Taxability
All customers, items, and shipping items should be assigned to a taxable tax schedule. This allows NetSuite Connector to tax or not tax orders, and the items in them, in a way that matches the order on the storefront. Whether an order or item should be taxable has already been determined by the time NetSuite Connector retrieves the order. Therefore, NetSuite Connector must have the ability to import the order as both taxable and non-taxable to match the storefront.
Marketplace Remittance
For marketplaces that remit tax on your behalf (Amazon, Walmart, and others) the best practice is for NetSuite Connector to omit the tax from the orders when they import to NetSuite. This functionality is enabled by default. The tax is omitted because the marketplace never provides the tax revenue to you, but instead remits the tax directly to the tax authority on your behalf.
VAT
For storefronts that charge Value Added Tax (VAT), the best practice is for NetSuite Connector to subtract the VAT amount from the item before syncing the order since NetSuite will assign tax to the item upon import. If NetSuite Connector does not subtract the VAT from the item, then NetSuite will add an additional VAT to the item resulting in an overtaxing of the item.
Setup
For information about the best practice in setting up taxes in NetSuite and NetSuite Connector, see Setting Up NetSuite Connector Order Sync.
Discounts
The best practice for discounts is to post all discount, promotion, or coupon amounts to a generic discount item. In most cases, the discount will be posted at the order header in NetSuite. But certain connectors will default to the line level because of specific differences for the storefront. Using this approach ensures that the discount total on the order will post to NetSuite resulting in the NetSuite order total matching the marketplace or cart order total. Posting the discount to the order header allows the discount total to show up in NetSuite order summary, on which you can easily view the discount on the order.
When you install the NetSuite Connector, the generic discount item will be created for you and configured in NetSuite Connector automatically.
For information about the best practice for setting up discount items, see Managing Order Discounts in NetSuite Connector.
Payments
Payment Methods
NetSuite Connector allows a translation mapping between the storefront payment methods and NetSuite payment methods. Then, your orders in NetSuite can have a payment method, and potentially, tokenization data.
Capturing Payment
The best practice is to capture payment in your marketplace or cart at the time of order (most are either preconfigured to do this and many do not have an option to do external capture). NetSuite Connector will import the tokenized credit card data on orders to NetSuite when such data is available in the storefront (if the mapped NetSuite payment method makes those fields available). The credit card data can later be used to refund orders in NetSuite. It data can also be used to capture payment in NetSuite if the state you sell in requires that you capture payment after fulfillment and not at the time of the order. The following information will be populated on the order:
-
P/N Ref.
-
Auth. Code
-
Credit Card Approved - This field ensures payment that is not captured in NetSuite.
This approach may not fully apply if the Payment Instruments feature is enabled in NetSuite. Changes with that feature require special handling.
Payment Processors or Gateways
NetSuite Connector does not integrate to payment gateways or processors, which means that any data related to the payment must arrive directly from the storefront. NetSuite Connector does not authorize or capture payments, it only syncs available payment data from the storefront to NetSuite. This allows you to use any payment processor or gateway in your storefront that the host platform supports.
Shipment Methods
The best practice for shipment methods is to map the storefront shipment method to a NetSuite shipment method so that the shipping cost and (if applicable) shipping tax can be properly accounted for on the synced order. Without a shipping method, NetSuite will not accept a shipping cost. If shipping was paid on the order in the storefront, but no shipping cost is imported to the order in NetSuite, then a variance in the order total between the storefront and NetSuite will result. For this reason, it is important to map a shipping method on your orders.
Shipping methods or items must be configured in a taxable tax schedule in NetSuite so that NetSuite Connector can assign a tax rate to the shipment method if the storefront charged tax on the shipping cost. Assigning a shipping method to nontaxable tax schedule creates a order total variance between your storefront and NetSuite when the storefront charges tax on the shipping cost. For this reason, it is important to place the shipping method or item in a taxable tax schedule.
For more information about setting up Shipping Methods or Items, see Configuring Shipping for NetSuite Connector.
Mapping Logic
All complex logic for determining the field values on the order in NetSuite must be handled in NetSuite using a formula field, script, or some other automation. NetSuite Connector works best when mappings are relatively simple. NetSuite Connector either directly syncs data from the storefront to a field in NetSuite, or uses a simple translation mapping to produce a NetSuite field output. Constructing complex mapping logic directly in NetSuite Connector complicates troubleshooting, makes issues unclear, and renders some mappings only editable at the backend, which then requires you to rely on support for editing or even viewing your mapping. Keeping complex logic in NetSuite allows you to have full control and visibility into such logic. If an unexpected value is written to a field on the order in NetSuite, determining where the unexpected data came from is greatly simplified.
Order Items
SKU Field
Storefronts identify items on orders by an SKU value. NetSuite connector uses this value as a unique identifier to match to an existing item in NetSuite. A field on the NetSuite item record containing the SKU value is designated in the Order Settings (configurable by connector and account). NetSuite Connector searches NetSuite for an item record with a value in the designated SKU field that matches the SKU value on the item from the storefront. When it finds a match, it uses that matched item on the order in NetSuite. This requires the SKU values to uniquely match, one-to-one, between the storefront and NetSuite.
Consider the following:
-
The best practice is to use the Item Name/Number field as the SKU field.
-
The NetSuite Connector requirement for unique SKUs applies to all storefronts even if the storefront allows duplicate SKU values.
-
NetSuite SKU values must be unique across all item types and across both active and inactive items.
-
SKU values are case-sensitive.
-
If you are using Product Sync, the same SKU field must be used for both Order Sync and Product Sync, otherwise you would be syncing products that are not selling in orders.
Price Level
The best practice is for NetSuite Connector to sync the price level on order items to the Custom price level in NetSuite. This allows NetSuite Connector to set the price of the item to the same price that was charged on the storefront regardless of what the price may be in NetSuite. This ensures that the tax for that item and the order total match the storefront.
Price, Quantity, and Tax
NetSuite Connector syncs the price, quantity, and tax rate that appears on the order in the storefront to the order in NetSuite. You must not modify any of these values as it alters the order total to create a variance, which can cause problems with other syncs like refund sync or settlement sync.
POS (Point of Sale) and FBA (Fulfilled By Amazon) Orders
The best practice for orders that are already paid and fulfilled when they are received by NetSuite Connector such as POS and FBA orders, is to sync them as Cash Sales. Since payment has already been collected and fulfillment has already taken place before the sync, no Sales Order or Item Fulfillment is necessary. Therefore, skipping to the Cash Sale record eliminates unnecessary records and work in NetSuite. Additionally, since customer information is typically not provided by the storefront with POS and FBA orders, a fixed customer is used for all such orders. NetSuite requires a customer for all orders and without customer data, neither existing customer match will be found nor can a new customer be created. Using a fixed customer allows NetSuite Connector to meet the NetSuite requirement that the order must have a customer without having customer data provided by the storefront.
Unit of Measure
NetSuite Connector does not sync the Unit of Measure for items because the storefront does not provide the unit of measure when the item is sold. The reason for this is that NetSuite has internal logic built around properly identifying the various unit of measure types on a particular item that should not, and often cannot, be overwritten during order sync. NetSuite will automatically populate the unit of measure on your line items on the order with the unit that you have specified on the item record for that particular item as the Primary Sale Unit type. Therefore, if you are using Units of Measure in NetSuite, it is important that you properly configure the item's Primary Sale Unit type with the the unit type you sell in your storefront. The Base Unit should be set for each item (which is essentially a single unit).
For example, if you sell water bottles in cases of 24, the base unit should be 'each' and the sale unit should be 'Case of 24'. This way, when you receive an order for 1 of the 24 case, your inventory will properly decrement 24 units. If your sales unit is incorrect and set to 'each' even though you sell cases; for example, when the order comes in, only one unit will be decremented leaving 23 single water bottles in stock that have already been sold.