Know your system, know your data
To make your Electronic Data Integrations (EDI) fly, you need to understand how your Enterprise Resource Planning (ERP) system works and the data required at a transactional level for your EDI rollout to succeed.
Referring to the picture above, my focus is on processing the transactional data into the ERP system, the Warehouse Management System (WMS) and the Business Intelligence (BI) system, as applicable.
My thoughts are to consider a small or medium-sized business starting on their journey into EDI. It can be quite daunting with some of the technical documents that your trading partner provides, and you have to understand the finer details immediately and agreeing that you will support their requirements.
Many companies have started on the wrong footing and created quite a monster. How often do you hear of a person complaining about EDI or their EDI Managed Service Provider? Get the process right from day one, and you will fully embrace the benefits that you will get from a fully connected and automated solution.
Message Implementation Guides (MIG)
When you first connect to a trading partner, you should be presented with the MIG.
This document or documents should describe the file format by the transaction.
You, therefore, need to understand how to read the MIG to confirm that you will receive the data you require to populate your ERP. You will also need to understand what information the trading partner requires for outbound transactions.
Transactional data
When setting up your system, you will need to define the data you need for each transaction you will support.
When considering that data to be processed, you will also need to consider the systems that will be consuming the data, such as your WMS or BI systems. There might also be data in the order that you need to pass through to your WMS to populate delivery notes and or labels.
If you have each transaction documented for your ERP, you can then compare the data requirements found in the trading partners MIG. Once you have performed that gap analysis you can then start a discussion with the trading partner, if there are gaps. Not all data will be mandatory so hopefully you will be able to support the transactional data being processed both inbound and outbound.
Stuff happens
When setting up your solution you need to consider what happens when things are not as expected and there are data and or system failures. How will you recover from this situation?
You will also need to consider how you will support any data issues for your outbound transactions. I can cite an example where the largest online retailer rejected many files due to issues with the API. I did not have to do anything other than resend the transactions that had been incorrectly rejected by the online retailer.
Connectivity to your EDI Managed Service Provider
My blogs are written to aid a business that is just starting out in their EDI journey. Bearing this in mind, I would advocate a simple sFTP connection in which you have folders that support the various transactions.
I have been in a situation where all outbound transactions were in one folder and file naming convention was basic.
I would advocate having folders set up with the sFTP connection with sub folders set up by transaction. I would then have a file naming convention that states the account name/number, the transaction type and date and time of generation. This will make it easier to find a transaction should you have an issue.
Embrace EDI
Yes, EDI can be big and scary. If you set the solution up correctly you will greatly benefit from supporting this functionality.
An automated process can do a lot of the “heavy lifting” so reducing the need for Full Time Employees (FTE) to key orders into an ERP system.
If you then look at the other activity such as confirming that the order has been received and processed again you can keep all this activity within your ERP with a file being sent out to your trading partner.
If you are looking to trade on a marketplace or ecommerce space then you need a solution that works out of office hours so that you can acknowledge orders, ship orders, if your warehouse operates extended hours, and update the external systems with your stock holding.
I have written several blogs discussing all these aspects. There are some that go into detail with mapping documents provided. Please feel free to read through these or reach out to discuss further.