Introduction

Integrating any Warehouse Management System (WMS) or Third Party Logistics (3PL) with an ERP product such as Sage300, Sage200 or X3 is a complex task. Consideration needs to be given to a variety of issues such as:

• Synchronisation of stock systems
• Integration touch points
• Volume & frequency

This blog post draws on our experience of integrating a number of WMS systems with ERP products, and while not necessarily offering any definitive answers, hopes to highlight the potential questions and issues affecting most WMS integrations.

Stock system

Unless a WMS has been purpose built to utilise the ERP’s stock system, most WMSs maintain their own stock system, each affected by transactions. The transactional nature of the interaction means the two systems will have natural and unnatural differences brought about by the latency in processing transactions and processing errors.

The integrator’s job is to make the ERP and WMS stock systems as synchronised as possible, or at least highlight the possible points of difference.

Logical Partitioning

Segmenting a warehouse (or ERP) into areas such as the receipt dock, quarantine and pick face makes perfect sense in both the WMS and the ERP. There are two key integration questions which need answering:

• Mapping: how do the locations in the ERP and WMS map to each? How does this mapping affect the stock position and availability of stock in the ERP?
• Stock movements: when stock is moved in the WMS from one logical area to another, does the movement also need to be reflected on the ERP? Typically, ERPs treat a location as a boundary for sales and purchase order purposes, thus a movement from quarantine to the pick face will need to trigger a corresponding movement in the ERP.

Time sensitive

• Transactions should be processed in the order they were processed on the WMS. If batching groups of transactions for processing, an alternative is to process all the transactions that add stock to the ERP system before those that decrement stock which limits the scenario where a transaction removes stock required by another operation.
• Transactions such as P/O receipts can affect the available to sell value in your ERP, and thus affecting potential sales.

Decide the integration points

The obvious candidates for integration are:

• Item Master download to the WMS.
• Sales Order download, followed by the upload of picking information creating a shipment/invoice in the ERP. Consideration should also be given to the way back orders will be handled.
• Purchase Order download, followed by upload of receipt confirmation creating a purchase receipt in the ERP.
• Adjustment upload from the WMS to the ERP. Adjustments can take several from write-offs of damaged or end-of-life stock to adjustments made through cycle counts. Be prepared for some heavy debate around the ‘should cycle count adjustments be immediately uploaded/treated as gospel’ question. (They should, but some warehouse managers/business owners seem to have other ideas).

Less obvious or more exotic transactions need some thought:

• Transfers: if there are multiple warehouse(s) or the warehouse is partitioned (see logical locations above) a corresponding transfer in the ERP solution will need to be performed.
• Customer and supplier returns: typically these are handled manually as the volume and workflow complexity usually means the cost for integration outweighs the benefit.
• Kitting: kitting, or light manufacturing, can involve workflow, and the frequency may be too low to warrant integration.
• Packaging operations: anything to do with packaging is usually met with a degree of complexity. The purchasing process involves a PO, receiving is done typically at the warehouse door, but thereafter it becomes complex: the receipted goods are consumables, so they cannot be booked into stock, and because of this stock control and management can become more difficult.

Locking and recall

Consideration may be given to both the workflow of the WMS and ERP products. If for example a sales order starts to be picked in the WMS, does the change in status also need to affect the ERP preventing it from being modified?

Similar considerations need to be given to modifications made to, or deletions of sales and purchase orders in the ERP.

Inventory transactions

Inventory transactions by their very nature are more difficult to handle.

• Stock is sensitive: invalid stock levels can trigger exceptions, stock costs particularly for adjustments need to be considered.
• Shipments and receipt transactions need to be mapped back to their original order documents. That is, when a line is picked, the same line on the sales order needs to be affected.

Volume

Due to the volume and different types of the transactions, the integration must work! Attempting to unpick issues when things go wrong is time consuming, costly and sometimes impossible.

Batch and serial numbers

Batch and serial number integration adds complexity as they increase the number of reconciliation points between the WMS and the ERP solution, where each batch or serial number in the WMS must also be present in the ERP. For example, a warehouse managing 200 batch controlled items may be made of a 1000 discrete batches.

There are some variants on batch and serial number processing which can reduce complexity:

• Record batches and serials only on the WMS.
• Record only batches and serials only on some operations i.e. picking or goods out.

Methods to integrate

As described in a previous post, we recommend staging tables for data exchange. However, when integrating a 3PL, your method for exchange will be file exchange via FTP/SSH.

When using a staging table, you have the option of using a single table for all transactions or a table for each transaction type. A single table does introduce some degree of abstraction (each field needs to be named FIELD1, FIELD2, etc. which is then logically mapped depending on the transaction type), but it has the major advantage that it can be reconciled more easily and transactions can be easily ordered by date/time.

Reconciliation

The ability to reconcile the ERP and WMS stock systems is paramount. We would recommend creating a report which can be run daily, at a time when no-one is using either the WMS or the ERP, comparing the WMS & ERP stock levels.

Test, test, test

It goes without saying that all integrations should be tested, but WMS integrations more so. The number of transactions, the time sensitive nature, and the variety of transactions makes it a difficult beast. Try to cover the following when testing:

• Performance: try to mimic the load and volume of transactions performed throughout the day.
• Concurrency and multi-user environment: test for scenarios where transactions may be locked by the ERP or the WMS.
• Check your audit points and controls: if you need to unpick an error, ensure you’re capturing all the necessary data from the outset.

Conclusion

Integrating any WMS is not simple. Consideration needs to be given to a wide variety of issues and integration points where cost is often a factor. With careful planning however, it can be very rewarding: seeing all the transactions tick through is quite nice!