OrderFlow founder and MD, Charlie Armor, explains the process of integrating your e-commerce platform with your warehouse management system (WMS).
Most of the work necessary to deliver a robust, enterprise-strength integration between an e-commerce platform and a WMS will be specific to the two environments involved. However, the fundamentals aren’t platform specific. It’s worth thinking in general terms about what you’re trying to achieve and what integration options are available between the two platforms before diving too far into the detail.
The two platforms will typically each provide at least one integration option for exchanging data with third-party systems. If both are well-established, then there’s a good chance an existing solution is available to link the two.
For example, our own OrderFlow WMS platform supports e-commerce integration with Magento, Shopify, WooCommerce and Spree without requiring any bespoke development.
If an interface already exists between your two platforms it’s important to understand what it offers and to make sure it’s able to deliver all the functionality you require. If a solution doesn’t exist you will need to develop one yourself or have someone else do it for you.
Bear in mind that several of the most popular hosted e-commerce platforms impose API call limits that may require you throttle the rate you can exchange data.
Your design should allow for this, usually by prioritising inventory updates.
As an example, if the API limits calls to two every second and you despatch 5,000 orders a day, it will take the WMS over 40 minutes to push the despatch notifications to the e-commerce platform when your courier collects every evening.
Unless you lower the priority of the despatch updates, you may find you’re unable to receive any new orders for forty minutes.
This doesn’t matter a great deal if you’re only selling on one sales channel. However, it can be a major problem if you sell on multiple channels – delays in receiving new orders or updating the stock position on all the channels could cause them to oversell.
It’s also important to be aware that many integration options suitable for small sites don’t scale well.
Simple interfaces that allow the WMS to pull an entire product catalogue every night are fine if you need to support a couple of hundred stock keeping units (SKUs), but will be unworkable if you try to pull the details for twenty thousand SKUs in a single request.
The situation improves a little if the API allows you to request ‘x’ number of SKUs at a time, which is known as API pagination. The best approach is to use an API solution that allows you to pull just those products that have been created or updated since the last pull. A design that just pulls the products that have changed can be run more frequently that one which pulls the whole catalog. However, bear in mind that the e-commerce platform may support bulk product updates so the volumes can still be large.
If messages aren’t acknowledged by the receiving system the problem should be made visible to the appropriate users within the originating system. The integration design should be able to distinguish between application level errors and connectivity errors so that system resource isn’t wasted trying to resend messages that the receiving system has explicitly rejected. Instead the error should trigger whatever processes are needed to resolve the problem.
It’s important to design the integration to allow for the possibility that either of the systems or the network connectivity between them may occasionally be unavailable. This should be immediately visible to the system administrators, but the two systems should automatically catch-up with one another when connectivity is reestablished.
A sensible approach to retrying failed messages is also important. If the e-commerce environment is taken offline for maintenance, the WMS shouldn’t generate thousands of message retries that will flood the interface as soon as the e-commerce platform comes back up.
The integration should ensure that wherever possible the mandatory fields required by either system are contained in the data being exchanged. However, this shouldn’t be relied on. The receiving system should always validate the incoming data and either reject incomplete messages or deal with them appropriately, prompting a user within the WMS platform to add the missing information.
The sort of situations that your data validation should aim to avoid include:
The data validation processes should ensure that all the necessary information is available before the operational processes are started. Messages that fail validation should not fail silently – failures should be visible on dashboards that you know will be monitored, or should trigger an alert that’s pushed to the person best placed to investigate the failure.
There may be occasions when you want to give your warehouse users the discretion to edit some elements of the data received from the e-commerce platform. A typical example is the product weight; within the e-commerce platform the weight is often just the weight of the product, in the warehouse environment it’s more useful to know the combined weight of the product and its packaging. If your warehouse processes give users the ability to edit the product weights within the WMS, it’s important that your integration ensures that amended weights aren’t overwritten the next time an updated product definition is received from the e-commerce platform.
The technical team that looks at the requirement from a warehousing perspective will be used to the concept of SKUs – these are the uniquely identified items that correspond with physical stock. However. this is not always the case for e-commerce platforms where it’s often possible to create a ‘parent’ product definition and then define different colour and size variants.
The integration you put in place needs to be able to distinguish between physical SKUs that you can drop on your foot and logical ones that don’t physically exist. This is because the WMS platform is only interested in physical SKUs.
Unless they’re being used within a 3PL environment, WMS platforms should be configured to ensure that product SKU codes and product barcodes are unique. The WMS platform will then ensure the same SKU code or barcode isn’t used for multiple products. This may not be the case in e-commerce platforms where it’s often possible to create multiple products with the same SKU or the same barcode value. It’s well worth running a few database queries to check your assumptions about the e-commerce database values before finalising your design.
If you work in a sector where product ranges change quickly, it may be that only a small proportion of the product catalogue defined in the e-commerce platform is actually active. It’s worth considering whether old product definitions that will never be of interest to the WMS can be excluded and going forward, what mechanism can be used to retire old SKUs when they’re discontinued.
The basic dataflows that form part of most e-commerce platform and WMS integrations are:
The product catalogue is generally pulled into the WMS from either the primary e-commerce platform or the merchandising platform where new products are first defined. If the product is going to be sold on multiple sales channels it’s important to understand how the SKUs will be uniquely identified across all environments. The WMS will usually only require a small subset of the product data available.
Customer orders will be pulled from one or more e-commerce platforms, usually when the payment has been authorised. It shouldn’t be necessary for the WMS to receive any payment details beyond what is required to be printed on the customer paperwork that is despatched with the order.
The inventory level will be pushed to the e-commerce platform whenever stock levels change. The figure that is most relevant is the ‘available stock’ quantity, which is the unallocated stock available to fulfil future orders. It’s typically the e-commerce platform that decides whether to take a product off sale or change the customer’s expectation about lead times, the WMS simply pushes a stock quantity.
In multi-channel environments the WMS might be configured to push an available stock figure of zero to some channels before the product is actually out of stock. This approach can prevent overselling when working with sales platforms that impose a delay on API data transfers. (see Time lags and performance considerations section above).
The WMS will push back order updates to the relevant e-commerce environment. The most important update is usually the despatch confirmation, which will contain the courier service used and any available tracking reference. Other intermediate order updates might also be generated, but it’s often not clear how these should be mapped to the different order states supported within the e-commerce environment.
The e-commerce platform should be responsible for pushing despatch notification emails to your customers. This ensures they are in the same format as the original order confirmation email and reduces the number that will be wrongly identified as spam.
If the WMS needs to support split shipments, the updates will need to contain information about the line items and quantities despatched in each shipment rather than just confirming that the order has been processed. The e-commerce environment will then need to create multiple despatches against the original order and push appropriate email updates to the customer for every despatch.
More complete e-commerce integration might include some or all of the following elements; cancellations, RMAs, return confirmations, stock levels for composite products, payment requests and order modifications, batch tracking and batch specific stock levels.
Purchase order integration that links with the systems that place orders on suppliers can also offer significant benefits, particularly because it can provide the warehouse with a view of what stock is expected and can allow more efficient goods-inward processes to be supported.
These more complex dataflows are beyond the scope of this article but should follow the same general rules that are outlined above.
enquiries@orderflow-wms.co.uk
+44 (0)1249 750564