3 methods to do a WMS - ERP integration

3 methods to do a WMS - ERP integration

Method 1: ?Flat File Integration

This type of integration occurs when third-party software need to read from, or write to, tables in the ERP. How does it work? The files needed are uploaded to an FTP site by a consultant or middleman; normally these files include customer products, prices, sales reps and, in general, everything needed in the core data for the WMS to generate or execute transactions. Once the transactions are generated, the updated data is uploaded to the FTP site and from there written into the ERP.

The main advantage of this method is security: operating the data outside the ERP structure gives you a layer of security, especially if you don't know what will be done. But the main downside is that flat file Integrations happen in a batch process: they are not live and they take some time to run and, by doing things in a batch, you don't get a live transfer of information in real-time from a system to the other.

Method 2: ?WMS - ERP integration via API

The API (Application Program Interface) is a program written by a software provider that sits atop their ERP system, so that third-party developers like us can read and write and has a set of validation rules for validation that determine whether or not the data we are sending to the API is correct or wrong. If it is successful, the API Imports the data; if it is incorrect, it rejects the data.

The beauty of the API is that normally all the big ERP systems in the world have well documented APIs. So, instead of the flat file having to wait for the consultant to upload the file, I can access the API whenever I want and get real-time data whenever I want. So I can run the transactions on our system and immediately access the API, pass the transaction to the API; it makes its validation rules and imports the transaction to the ERP system.

Method 3: ?Accessing directly the data base

This method is probably the most popular, used especially within the smaller ERP system community. ?Reading directly from the database is fairly straightforward, but it does require work on your side. Whereas in an API you have documentation telling you which requests to make to retrieve the data, when you read from a database directly you need instructions from the database administrator or the developer who designed it, to know where the data is. So, getting data from the database involves the following:

·????????You have to write your own queries.

·????????Extract the data

·????????Export it to a temporary table

·????????Read from that temporary table

·????????Import it to your tables.

The writing process is more complicated because, in most ERP systems, the only way to write to them is by going directly to the database. But this is problematic because every program in the world has a set of validation rules before entering data into a database and, if you don't go through those same validation rules and go directly to the data, you might insert the wrong data in the wrong places and this can generate a lot of issues in the interface of the program you are dealing with.

Summary

In order of favorites, I would go to the API first because it is the cheapest to maintain, the most effective and the safest. I would rate flat file second solely because, while it works, it is slower and requires a middleman to maintain. ?The last range I sorted went straight to the database due to the safest issue; go with it only when there is no other option available.