Overview

Many merchants utilize Enterprise Resource Planning software to help manage their business. This type of software may sit “downstream” relative to the ecommerce platform within which orders are being created, and subsequently receive or ingest those orders.

In order to sell Extend warranties online one or more SKUs/products representing warranties may need to be created within your ERP. Without proper consideration, orders containing warranties may fail to integrate successfully into your ERP from your online store front.

This document will help you understand the ways Warranties are represented in your ecommerce platform (e.g. Shopify, BigCommerce, WooCommerce, etc.) and multiple design patterns to accommodate warranty sales flowing into your ERP

Warranties SKUs the Ecommerce Platform

The first consideration to make when planning for warranty sales that will integrate into your ERP is how this type of product is represented in your ecommerce platform. The quantity and pattern of warranty SKUs varies based on the ecommerce platform you use to sell your products

Shopify

Shopify requires the usage of many warranty product-variants as Shopify requires the price of every product being sold to be pre-defined.

• Extend will add a new product-variant for EITHER:
  1. All “price point” values, representing all possible warranty plan prices, equaling 250 warranty SKUs.
     OR
  2. Every combination of warrantable product-variant and warranty plan (e.g. you sell ten warrantable products, each one matched to three plans, resulting in the introduction of thirty warranty SKUs). This is known as “Direct Mapping”.
• The default is price points, but be sure to ask your Merchant Services Associate to confirm if you are unsure.
• The precise values of these warranty SKUs can be found in your Shopify store once your products have been mapped.
• Price Point format of SKUs: 'Extend-Protection-Plan-'+[price-point]
• Direct Mapping format of SKUs: [Extend plan-id]+'-'+[term]+'-'+[variant-id]

WooCommerce and Magento

Both of these platforms use a single warranty SKU:

• For WooCommerce, the SKU value is selected by the merchant when they create the warranty product during the integration process. Note that WooCommerce also maintains its own inventory management scheme of product IDs, and this might be an important attribute of product as they flow into an ERP.
• In our Magento integrations, the warranty product has a default value of ‘WARRANTY-1’.

BigCommerce

Within the BigCommerce platform integrations do not bring any warranty products into your catalog. Instead, the custom SKUs are created dynamically when a warranty is added to cart. The format for warranty line item custom SKUs is: [Extend plan-id] + ‘;xtd;’ + [warrantable SKU].

Modifying your ERP to handle Warranty Sales

For any downstream systems that ingest, or receive, orders from your e-commerce platform, modifications will likely need to be made so that future orders containing warranties are received without issue.

In many cases, this is done by adding one, few, or many new SKUs representing Extend warranties to your ERP system.

Subsequently, logic or a set of rules is created so that these warranty SKUs can be identified:

• E.g., Setting up 1:1 mapping of products between systems or some many M:1 (many to one) mapping that is capable of identifying an Extend warranty SKU.

ERP Design Patterns

1. Option A: Single Warranty SKU (Many to One)
   1. The preferred architecture when representing protection plans in an ERP software is to leverage a single distinct Non-Inventory, or virtual type SKU that represents all possible plan types and terms.
   2. This item should be configured and labeled accordingly and be configured so that pricing can be dynamic and based on the online order.
   3. As Sales Orders are manifested in the ERP, the integration should identify the Extend warranty via the eCommerce order payload and map it to the single Extend Protection Plan SKU when creating the Sales Order within the ERP. The line item should also inherit the price of the line from the eCommerce order payload.
2. Option B: Few SKUs (Many to Few)
   1. An alternative approach when representing Extend protection plans in an ERP software is to create representative SKUs for each term available for purchase. That is, if your products are mapped to plans with one, two and three year terms; create three SKUs in your ERP, one for each term-length.
   2. These items should be configured and labeled accordingly and be configured so that pricing can be dynamic and based on the online order.
   3. As Sales Orders are manifested in the ERP, the integration should identify the Extend warranty via the eCommerce order payload and map it to the single Extend Protection Plan SKU when creating the Sales Order within the ERP. The line item should also inherit the price of the line from the eCommerce order payload.
3. Option C: Many SKUs (One to One)
   1. Another approach is to create many SKUs, likely on a 1:1 basis with the ecommerce SKUs.
      • We do not recommend pursuing this option unless it is necessary. This method will require the most ongoing maintenance. This method requires additional work and planning in the event that new plans are mapped to your products or the pricing for the plans changes.
   2. If this is the selected pattern, please let Extend know so we can help plan for any changes that might impact this setup.

Additional Resources

If you are uncertain about how to proceed, Extend is happy to work with you to provide guidance. Merchant Services team can provide guidance upon request through the Merchant Portal.

We also recommend reaching out to the support resources provided for your ERP platform, who have unique and product specific knowledge