Skip to Content
EDI/B2B messages can not be implemented with a trading partner without knowing what data is going to be sent or received. If a trading partner sends you an EDI data file, it looks like a strange, cryptic message. You may see many different codes, numbers, separators and words. You have no idea what they mean. So how do you make something useful with it? Your trading partners must send you an “EDI Implementation Guide.”

An EDI Implementation Guide is a document that explains what is in the EDI data file. OK, now you have the secret decoder document. It identifies what each code and data element in the Implementation Guide means. It tells you the EDI standard, version and EDI transaction (e.g. 810 Inbound Vendor Invoice) that is being used. It tells you what subset of the 810 Inbound Vendor Invoice your trading partner uses. This is important since an 810 Inbound Vendor Invoice may have 300 possible data elements, of which you only need 62 for your SAP IDoc (just an example).

The EDI Implementation Guide is used to help you configure your EDI translator so it understands what to expect when it receives a message. Using the example above, you configure your EDI translator to expect the same file as is defined in the Implementation Guide. The configuration of your EDI translator is a slow manual process. Any typos or data entry errors makes the configuration invalid. Once the EDI translator is configured you can import a test file with valid and compliant data to test your configuration.

It sounds simple when I wrote you could import a test file, but trading partners hate making test files on new messages. It is just boring work. Someone has to read the new EDI Implementation Guideline and maually create a test file that exactly matches the implementation guide. If you create an invalid test file, the testing process gets all messed up.

Now, you as the recipient of the EDI message must ensure that the Implementation Guide, your trading partner sent you, contains the necessary data that your IDoc requires. If it doesn’t, you need to contact your trading partner and negotiate with them to edit their implementation guide, EDI message and data file to include the data you need. This is not always easy, since your trading partner may not want to bother. This is where the Dale Carnegie class you took 20 years ago pays off.

Here is where EDI implementations are just plain old fashion and silly. You ask the SAP support team to send you the IDoc documentation that identifies the data needed. You ask your trading partner for their EDI Implementation Guideline, then you make some popcorn, put on your reading glasses and start comparing them line by line. Doesn’t it seem like this could be done in a more automated fashion? Once you have completed the analysis, you must now understand what the IDoc means by Address Line 2, and compare it to the meaning of Address Line 2 in your EDI Implementation Guide. Perhaps your trading partner uses that element name to mean Suite #, but your IDoc uses it for the Building name (again just examples) but the point is you must also understand the semantics of each data element. Keep in mind, that your trading partner had to go through this same process at their end of the transaction.

Let’s consider the above scenario, and expand it to 3,400 trading partners using 55 different EDI messages in a wide range of different EDI standards, versions, message types, subset lists, languages, and custom configurations. Does this sound like fun? Is there any wonder that companies rarely can implement EDI with more than 10-20% of their trading partners? The process of automating and extending your business processes to your external business network is inhibited by the fact that implementing EDI/B2B is a slow, paper-based, hard and costly MANUAL process.

There are methodologies, tools and strategies that can be implemented to make EDI/B2B implementations easier, but they are usually only available to very large companies with giant EDI departments and budgets, or EDI/B2B managed services companies that can benefit from the economies of scale required to invest in them.

Let’s review the process:

  • Your trading partner must understand the data needs of their ERP
  • Your trading partner converts the needs of their ERP into the appropriate EDI message
  • Your trading partner writes an EDI Implementation Guide
  • The implementation guide must be written accurately
  • The meaning of the implementation guide must be understood
  • The information in the implementation guide must be used to accurately configure the EDI translator
  • Test data files that exactly match the implementation guide must be created
  • The IDoc requirements and definitions must be configured in the EDI translator accurately

What are the odds that all of these steps can be done accurately the first 6 or 7 times?

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Kevin Benedict Post author
    What is the solution for SMEs?  You can choose to enter data into your customer’s or supplier’s  web portal rather than automate with a full EDI system, or out-source your EDI/B2B to a managed service provider that SAP recommends, or ask if your partner’s can accept spreadsheets (.csv files) or other kind of custom B2B file. 

    IF you are using SAP, it may be best to start by outsourcing EDI/B2B and see if the volumes over time justify the internal investment of operating your own EDI/B2B department and system.

    (0) 

Leave a Reply