Miva Connect consists of a group of pre-developed “Standard Flows” that represent the starting point for all integrations.
A flow can be described as a connection on the Miva side, a connection on the NetSuite side, and logic between them, built to satisfy a specific task. For example, “Miva Order to NetSuite Order” is a flow. The connectors themselves are fairly simple. What differentiates one integration from another is the quality and attention to detail of what is passed between them.
Many choose Miva and NetSuite because both offer customization possibilities and, as a result, one-size-fits-all “easy button” integrations don’t exist. It’s anticipated that customization will be necessary, and the standard flows and integration process have been created with that in mind.
Many Miva and NetSuite customizations, like custom fields, are achieved with a simple customization.
Other modifications, or custom specifications may require either complex modifications to a flow, or fully custom flows built from the ground up.
It’s easy to think that just because Miva and NetSuite both have the concept of an order, integration between the two is straight forward. The reality is that there are many nuances to an order, and many data elements hang off it; customers, products, product variations, discounts, sales tax, payments and more. While our standard Miva to NetSuite order flow supports all of these, anticipating all customer variations is impossible.
That’s why the details of this flow is important. This document lays out exactly what the standard flows do and provides insight into where something may “just work” for you, and where it may need customization.
The goal of an integration between Miva and NetSuite is to:
It is expected that if the product catalog originates in NetSuite, users will typically manage their product catalog in NetSuite, or have basic information about each product in NetSuite and layer in details using Miva Merchant Admin – such as categorization, adding images etc.
New products can be created active or inactive in a specific category. This makes them easy to find in Miva Merchant admin for processing. Matrix parent and child products can be treated differently in this regard.
Product creation sets the Miva Product SKU to the NetSuite unique product name, whether that be a simple inventory item mapped to a Miva Product SKU, or a matrix product child mapped to a Miva Product Variation.
The Miva Product Taxable Boolean can be automatically set. This requires that Miva Connect maintain a list of NetSuite tax schedules.
Custom NetSuite fields can be mapped directly to Miva Custom Product fields.
Flow 1: Non-Matrix Inventory Items from NetSuite to Miva
Included (fields are configurable, but typically include):
Additionally, Product Creation and Update flows can include different fields.
- Adding more custom item fields in NetSuite to map to Miva custom fields is a simple customization to the flow, assuming they are a direct map to a NetSuite Item field.
- Adding complex additional fields stored in NetSuite, steps requiring additional database lookups, or introducing rule-based values into Miva can be included as a complex customization.
- A NetSuite custom Boolean field can be used to control which products should be synced to the Miva Store. Alternatively, if products include match specific search criteria in NetSuite, this can be supported.
- Taxable status in Miva can be set to a default true/false or can automatically be set based on NetSuite Tax Schedules.
- Products can default to Active or Not Active.
Flow 2: Matrix Items from Miva to NetSuite
Configuration Items Needed:
- Adding custom item fields in NetSuite to map to Miva custom fields is a simple customization to the flow.
- Adding complex additional fields stored in NetSuite, or introducing rule-based values into Miva can be included as a complex customization.
- How the NetSuite Name and Miva Product Variant SKU is mapped is critical to matrix product syncing.
- Adding this flow to a populated Miva Store assumes an existing compatible naming convention-based mapping between NetSuite matrix items and Miva Products Variants. Incompatibility between NetSuite and Miva Product conventions may require complex customizations to this flow, or the build of a custom flow to satisfy matrix product syncing.
- It is a simple customization to add a custom yes/no field to NetSuite e.g. “Sync to Miva” to control which products should be included by this flow. Alternatively, if products to include match specific search criteria in NetSuite this can be added to the flow.
- Taxation rules are the same as non-matrix products.
- Matrix Parents and Children can be automatically assigned to different default categories.
- Matrix Parents can be created either active or non-active by default.
- Matrix Children can be created either active or non-active by default.
Configuration Items Needed
- Matrix item inventory is pushed to associated Miva product variant. Assumes that Matrix Items have been generated by the Miva Connect Matrix Item flow or adheres to its naming and mapping conventions.
An Order is a complex bundle of data, including not just product information, but also customer, shipping, payment, sales tax, discounts and more. Typically, orders created in Miva are synced to NetSuite, and specific changes/updates to those orders that the customer needs to be aware of are synced back to Miva.
Miva Order Products must exist in NetSuite, and Miva Connect must know how they are mapped.
Miva Connect uses the Workflow Queues feature to determine which orders are new, and to show in Miva Merchant which orders have been successfully added to NetSuite.
In summary, this flow:
- It is a simple customization to map Miva Extra Order Fields to NetSuite Sales Order Custom Fields.
- It is a simple customization to map Miva Extra Customer Fields to NetSuite Customer Custom Fields
- Miva Customers are synced to NetSuite customers by email address.
- Assumption that Miva is configured for Auth+Capture of payments using a Miva Pay payment method. Authorization details are transferred to NetSuite. Assumption that refunds are handled through NetSuite. A single Non Miva Pay payment methods require a simple customization. Additional payment methods such as gift cards, purchase orders, etc. require complex customizations or custom flows.
- A NetSuite Item must exist for each order item in the Miva Order where the Miva SKU matches the NetSuite Name. Customization needed if additional mapping logic is required.
- NetSuite Customer “Type” field is set to “Company” or “Individual” based on the contents of the “Miva Bill To Company” field.
- If a customer already exists in NetSuite a default can be set to either update their account with changed information from the new order, or to leave the NetSuite customer record untouched.
- Sales Tax Calculation must be configured in both Miva, and NetSuite and the same formulas or services should be used in both. NetSuite populates sales tax fields in Sales Orders based on the order contents and these cannot be overwritten with Miva values. For reference, Miva Sales Tax collected is stored in a NetSuite custom field to allow customers to report between NetSuite and Miva calculated values.
- All discount types supported by the Miva Marketing Module are transferred to NetSuite in the following way:
- Shipping method names must be IDENTICAL in Miva and NetSuite for shipping details to be synced automatically. If names cannot be identical, they need to be supplied to be manually mapped in Miva Connect.
Customizations added to NetSuite for this flow:
- RMA Completed can be synced to Miva by either “RMA Closed” or “RMA Refunded” to be determined during implementation.
- Where multiple packages are used for a shipment in the same NetSuite fulfilment record, with or without the same shipping method, tracking IDs will appear in Miva Merchant admin as a comma delimited list. This may create unexpected results in how Miva generates shipping links.