Integrate Magento to NetSuite: 5 Commonly Missed Requirements

As I've discussed in previous articles, the pairing of Magento and NetSuite for ecommerce and back office is one of the best dollar-for-dollar business systems investments a company can make. Magento (Magento Enterprise Solutions in particular) provides Enterprise Solutions quality features to maximize the value you can achieve from each site visitor. NetSuite provides a robust and flexible suite of tools for managing all of the events that happen after the sale, as well as, insights into your customers and business operations to continually evolve and improve the business. Whether your business is B2B or B2C focused, this combination can provide an excellent foundation for business growth.

The main stumbling block companies tend to encounter when using this combination is actually integrating the two systems. A common mistake when implementing one or both of these systems is to overlook the actual business requirements for what you want to accomplish by connecting the two systems, and precisely how these two systems need to communicate to accomplish those goals. There are a number of approaches, ranging from purely manual to fully automated, and the best approach for your business will depend on a number of factors. Beyond the B2B vs. B2C distinction (a big distinction as you consider integration options), other factors such as order volume, number of SKUs, and frequency of changes to data are all factors that should play into the decision. Knowing specifically what experience you want to create for your customers, and the information your business needs to successfully operate, are critical steps in planning your integration.

Assuming your business needs some degree of automation, the options break down into two categories:

1. Integration "connectors" can be a quick solution to get up and running. They're often programmed to sufficiently meet the most common 70% of business use cases, and are generally priced as a "monthly" fee, which spreads the cash flow over time (assuming you're actually allowed to pay monthly). As a general rule of thumb, consider pre-built connectors as a small house with a low mortgage payment: If your requirements fit in that house, it's a nice cozy home you can afford on a tight budget. If your requirements fall somewhat outside that home, it can be inconvenient, uncomfortable, or simply not a good fit at all, regardless of how cheap it is to maintain. The decision on whether or not to stay in that home becomes a factor of just how much pain it introduces to your life versus the benefit it provides.
2. Custom Built Integrations generally take longer to develop, and are thus more costly up front. However, they are tailored to your specific business requirements, which means they accomplish 100% of what you need to meet your business goals. Rather than living on a vendor's servers, they can co-exist on the same server as your Magento installation because you own the code base. To continue the analogy, a custom built integration is the home you've always wanted, where every room has a purpose and you've left yourself plenty of room for expansion on a big piece of property. The catch is that you had to pay for your house up front, but in exchange you own your home outright-- there's no monthly mortgage. The decision on whether or not to have the home of your dreams is similarly a factor of how much pain it alleviates as compared to the cost of alleviating that pain.

There are hundreds of factors to be considered in determining the business requirements surrounding a NetSuite Magento Integration. I've selected five below that are both common among ecommerce businesses and tend to be more tricky than they might appear at first blush.

Data to Move Between NetSuite and Magento

When most people look to integrate their website to their accounting system, they think of three things:

• New Customers should flow from Magento to NetSuite;
• Item Quantities should flow from NetSuite to Magento, and update as orders are placed in Magento; and
• Orders placed in Magento should flow into NetSuite, tied to the customer, referencing the items purchased.

While these certainly represent the core types of data, it leaves very large gaps both on the Magento side and on the NetSuite side. For example: If your customers are able to login and see their order history, should that history include any orders they placed via the phone directly with a support rep? If so, then you likely need an integration to push Order data from NetSuite to Magento, but only when that customer exists in both systems. Understanding the points at which you interact with your customers, and how you want your customers to experience those touch points, is very important to planning a successful integration.

As a best practice, I generally recommend starting by listing the different transaction and data types that are tied to a customer. In the B2C world, for example, Invoices may not apply but Return Authorizations may be heavily used. Similarly, in the B2B world, many customers won't check out with or store credit card information, whereas B2C customers may expect this functionality. Fundamentally, these decisions pivot on a detailed understanding of the experience you are trying to provide your customers, and making a plan that ensures they have the ability to create, access, and send data that makes their transaction with you as frictionless as possible.

As discussed above, pre-built connectors tend to be targeted at the most common business requirements. But each business has (and SHOULD have) a unique formula for customer interactions, transaction policies, and the ways in which they strive to make an excellent customer experience. Understanding and planning for the business goals driving your Magento NetSuite integration will serve as an excellent litmus test for evaluating whether a connector can be used or a custom integration is required.

How and When to Capture Funds

Working with credit cards can be fraught with complications. Leaving aside security concerns for the moment, think through the chain of events that are required to checkout with a credit card: The user inputs their card information to your site; your site transmits that card information via payment gateway to a merchant account; that merchant account facilitates communication with the issuing bank of the customer's credit card, ensuring funds move from their account to your account; the response from the customer's bank flows back up the chain to the merchant account, to the gateway, and to your website, where a success or rejection response is provided to the customer. All this happens nearly instantly.

Credit card security (generally lumped into the category of PCI Compliance) adds another dimension. Not only must we pass data across multiple links in this chain, but it must be done securely, and the timing and information must conform to particular guidelines.

In a typical ecommerce flow, the customer's credit card is authorized at the time the order is placed. This Authorization ensures the card is valid and has sufficient funds for the transaction, and generally places a "hold" on those funds. The key here is that authorizations are valid for a finite number of days, for a fixed dollar amount, and are tied to a specific authorization token. This is all in place to help prevent fraudulent activities.

But what if your business doesn't conform exactly to traditional ecommerce processes?

Scenario 1: A company sells customized furniture online, which generally has an 8-10 week build time. By the time the furniture is ready to ship, the authorization would have long since expired. As a result, the company's process needs to be different in that they both authorize AND capture funds from the Customer credit card at the time of purchase. This mitigates the risk of the customer placing an order for custom furniture and then refusing to pay 8 weeks later when it's complete.

In this scenario, Magento needs to initiate both the authorization and funds capture. The data pushed via your integration to NetSuite will contain a slightly different set of information. Additionally, there are settings on the sales order that must be set to prevent NetSuite from attempting to re-charge the card on fulfillment.

Free tip: In this case, the "Get Authorization" field must be set to FALSE and the Credit Card Approved field set to TRUE on the Sales Order. When the Sales Order is billed and transformed to a Cash Sale to record the accounting impact of the revenue, this combination will tell the system to set the "Charge Credit Card" field on the Cash Sale to FALSE, and the Credit Card Approved field to TRUE, and ensure the system merely posts the Cash Sale as Revenue, and does not attempt to recharge the customer credit card.

Scenario 2: Some businesses need to store credit card information for subsequent transactions. It could be the business will ship an order in multiple installments, only charging the card when items have shipped. If they are performing funds capture as the items ship over time, likely the original authorization has expired, requiring they have the card on-file to charge the next increment. Alternatively, a company may sell a product that also has a recurring subscription component. This may involve a recurring monthly charge for months or years into the future, which requires the card to be stored and accessible. This second scenario introduces data integration questions regarding both the secure passing and storage of credit card data.

A business cannot assume that either a pre-built connector or a custom integration will simply be setup to do these types of activities. These are generally detailed conversations in the solution planning phase of a project to ensure the underlying business requirements are well defined, the spectrum of data to be passed related to credit cards is well understood, a secure method of transmission and storage is in place, and the configurations of NetSuite are such that they will support the ongoing nature of these transactions.

Handling Sales Discounts and Promotion Codes

For all the things NetSuite does really well, Promotion Codes and Sales Discounts have not traditionally been included in that list. NetSuite's promotion codes are stored at the header level of the Sales Order transaction. The promotion code contains rules for when it will or will not apply, and is tied to a discount item that actually dictates the dollar or percent discount to be applied to the order. This model has some limitations:

• There is only ONE field for tracking the Promotion Code used, meaning a customer cannot use multiple promotion codes on the same order.
• The application of a promotion code is limited by the rules specified by NetSuite. If your rules involve discounts for some items, BOGOs for others, or are linked by other relationship logic, NetSuite's promo codes may not natively work.

Most integration connectors assume your use of Promotion Codes in Magento follows one of two approaches:

1. You will limit your use of Magento to match the capabilities of NetSuite, meaning less robust capabilities for customer discounts in your webstore; OR
2. You will only pass the net transaction amount (original less the discount to be applied) into NetSuite. In this scenario, you can do whatever you want for promotion codes in Magento, but you have to live with less reporting visibility in NetSuite when those discount codes are applied.

Obviously both of these are undesirable options. Part of the reason companies implement Magento is to leverage the more sophisticated toolset it provides. Similarly, passing only the net transaction amounts negates much of the reporting natively found in NetSuite when using promotion codes and discount items. It's important, therefore, to build a detailed understanding of both sides of this fence before planning your integration so that you maintain flexibility in your use of Promotion Codes in Magento without risking a loss of reporting data and visibility into customer behaviors in NetSuite.

Handling Sales Tax

Beyond being a boring subject, Sales Tax collection has the additional distinction of being a very difficult subject. The landscape is complex, and is currently in a state of flux. As of the writing of this entry, there are changes taking place at both the state and federal levels to attempt to restructure the ways in which sales tax is collected on internet sales.

Limiting our discussion here to purely domestic (US) ecommerce, most states have a patchwork of tax rules by jurisdiction, generally rolling up separate district, city, county, and state tax rates into a combined "rate" for a particular address. Unfortunately, the details determining which rate to use are often more granular than zip code or state, sometimes changing house-by-house in some jurisdictions. Strict compliance is challenging to say the least, and businesses often need to make a materiality decision on how best to approach the problem. Moreover, a business likely does not have a tax nexus in every state. As a VERY general rule (please please please consult your CPA) an operational presence in a state, such as an office, remote employees based in that state, or a distribution center, will establish a nexus in that state. Businesses beware: As mentioned above, this environment is changing. Washington State, for example, has in the past few years become very aggressive in determining a business has a nexus in their state. One of my clients participated once a year in a 4-day consumer show held at a Washington State fairground. The state of Washington determined this established a business nexus in the state at the same level as having a physical store in the state, and demanded they remit sales tax for ALL orders they had shipped to Washington State via their ecommerce site (not just sales from the show) for all the years they had participated in the show, resulting in a tax bill of tens of thousands of dollars.

Magento's out-of-the-box tax calculation rules are fairly straightforward, and as a result are not generally sophisticated enough to meet actual statutory regulations. They simply aim to get close and make a good faith effort. Additional add-on services are available to attempt to make this more accurate, but they typically are no more accurate than capabilities in NetSuite. However, NetSuite by no means makes the solution easy. There are three separate tax configurations in NetSuite (Tax, Advanced Taxes, Per-Line Tax) that build on each other to provide increasingly specific levels of control. At the end of the day, the tax is still only calculated to the Zip Code level of granularity, meaning jurisdictions with more fine-grain tax rules will still be inaccurate.

There are many approaches to solving these problems. Some common approaches include integrating to NetSuite's tax tables to augment Magento and get a much more accurate (but still imprecise) calculation; always charge the highest tax rate per jurisdiction to be "safe," knowing you will overpay by a fraction of a percent but avoid legal issues; or integrating to more sophisticated third party software that better manages tax liability.

Obviously, all three of these approaches will impact your integration plans. If, for example, the business decides to leverage the tools it has and integrate NetSuite Advanced Tax tables to Magento, most likely the pre-built connector does not have a pre-built solution for this data set, and Magneto's tax tables will need to be augmented to accommodate the richer data set from NetSuite. Suddenly the goal of saving money by avoiding a third party service means paying for one integration, custom building a second integration, modifying Magento, and still having a less than perfect solution to tax. Similarly, integrating to a third party service means there is an additional data call to an external source that has to take place as a part of checkout, which means orchestrating two integration services around the same checkout action.

It's not an easy problem to solve, and, as mentioned above, there is a cost-benefit analysis on the materiality of just how precise one needs to be, as the additional cost of precise compliance may exceed the benefits of achieving compliance. But understanding the legal and business framework in which your ecommerce site is going to operate is an incredibly important step on the path to a successful NetSuite Magento integration.

Impact of Specific Magento or NetSuite Configurations

NetSuite and Magento are two sophisticated platforms. They offer a wide range of features that are more configuration than customization, allowing the tools to be molded to your business, rather than molding your business to fit the tools. An unintended consequence of this flexibility is that settings between systems can be setup to conflict with each other, and sometimes pre-built integration connectors aren't capable of resolving the conflict or gracefully failing in a way that allows you to resolve the issue.

Given the depth and breadth of both systems, I'll limit the discussion here to just a couple common issues:

1. Multi-Location Inventory: This is an easy one, since most pre-built connectors WILL have a configuration option to accommodate. Multi-Location Inventory in NetSuite (MLI) allows the business to track items in different Locations, typically representing physical warehouses. The attribute is configured just like Departments or Classes, but has a more ubiquitous impact on the system in that every transaction requires a Location designation. For an integrated ecommerce site, this means making sure the integration is looking at the proper location (or locations) when determining available inventory quantities, and submitting the order to the appropriate location for fulfillment.
2. NetSuite Custom Form Configurations: NetSuite allows users to configure different forms for different purposes. For example, a Customer Support Sales Order form may have basic order details, but not allow edits and hide credit card information. Custom forms can be configured such that fields are required or disabled when using that form, but are enabled and optional when using other forms, and vice versa. When integrating customer and order data from Magento to NetSuite, it's important to understand your NetSuite configurations and how they may impact the successful transmission of data to the system. If a field is required or disabled on the UI form in NetSuite, but the integration has not been setup to capture and pass that info, submitting that record may fail.
3. Workflows (SuiteFlow): The SuiteFlow/Workflows tool is an excellent mechanism for users to create custom business rules and processes without the need to write code. However, these will often include rules setup for users operating through the NetSuite User Interface, and not be configured to operate for orders being created via an integration with Magento. Ensuring the execution context is either limited to the user interface, or includes web services integrations (based on whether or not you want the Workflows to execute on Magento-originating data) is an important review step in successfully integrating the two systems.

Integrating two systems is a complicated business. Different software is built by different teams, with different goals, and under differing levels of planning. Fortunately, NetSuite and Magento are both built on a foundation that assumes they will be integrating with other systems. As such, the bulk of time spent in an integration between these two systems should be spend in mapping the business processes and touch points between the two systems to ensure the two end points can successfully communicate. While there are certainly challenges, and a long list of potential gotchas to avoid, it's not a unique problem, and it has been solved for many businesses in the past. The key is understanding your business requirements and understanding the deep capabilities and features of these two systems.