When suppliers and retailers agree to establish a business relationship, you will inevitably hear something along the lines of “send me your EDI requirements document”.
Everyone starts somewhere, and typically before you even have a sense of what your EDI requirements actually are, it can be hard to share technical documentation about them.
What people are really asking for is a document that outlines the unique requirements you have when integrating with your trading partners and the scope of the integration. EDI may be a fairly strictly defined standard, but the documents you use and the way you use them can vary tremendously. Some people want to send changes back and forth via EDI, others want to handle that manually through customer service. Some people want to format item codes in a certain way, others would not be able to understand it unless it matches their internal format.
EDI can be about preference, which creates complexity. So, an EDI requirements document is a way to clarify those preferences at the beginning of the relationship so you and your trading partner(s) can get things in order. An EDI requirements document would typically contain information about the following:
- How do you want to receive inbound documents? Which tech is used?
- In what ways are you capable of sending documents? Which tech is used? Which is preferred?
- What documents do you require? What documents are optional?
- Do you have any custom mapping requirements?
- What is the format of the documents? Is it North American standard (X12), European (EDIFACT) or somewhere else (ERP, region or industry specific?)
- What is the procedure for testing to make sure things are working?
- What is the penalty or potential impact if something goes wrong?
- Who is the main point of contact for this project? Can I call them if something breaks?
- Do I have an option of connecting directly or using a service provider?
- Anything else that will affect our ability to integrate with each other?
The document would typically answer the above questions.
Basically, to integrate with your trading partner, you need a good sense of the scope, tech, information, and the procedures involved. Without this, there is no consistent way to make sure you can integrate with your partner without an excessive amount of back and forth. Standardizing the approach to the extent possible will make it easier to manage bringing many trading partners on board.
Before approaching EDI or trading partner integration, consider at a high level what you would like the approach to be. Consider what tech might be needed to make sure you can continue using your system of record (ecommerce or ERP system) to manage your business, while being able to speak the same language as your supplier or retail trading partners. And don’t be afraid to ask for a requirements document from a proposed partner, to get a good sense of what their needs are and what will be involved if you want to automate your trading relationship with them.
Subscribe to Convictional Blog
Get the latest posts delivered right to your inbox