Obstacles on the path to your own EDI interface Part II

Jul 15, 2022Vorbereitung ist der halbe Projekterfolg
After we had presented some ideas for the planning phase before the design of the EDI interface in part one, we turn this time to the actual practice of interface design. In doing so, we act on the assumption that you have already agreed upon all requirements with the particular business department and your next step is to design the document for the interchange itself.

Success by default

In many industrial sectors, the members have agreed upon common EDI standards over the years. By taking a gander at the guidelines, you will not only learn which content should be custom within your branch of industry, but also how the message has been composed structurally. If you do not have requirements that cannot be covered with the standard, it is advisable to construct the own message as a subset of such a standard. Your partners should be able to implement it timely and on top of that, you invigorate the standardization within your industrial sector. Please do not feel unsecure: Many standards contain quite a lot of information which you may not need. Most adopters therefore use only a portion of all possible content.
Standards make your live easier

Header or position?

If you do not want to use an industrial standard or you cannot do so, you have to design the structure of your message on your own. The most important question in this task is which information belongs to the header or summary part of a message and which into the positions. Here, you can use this rule of thumb: Information that may occur more than once (possibly in the future) should be settled in the positions while information that is not repeated may be placed in the header or summary part. Furthermore, you should make it clear in the guideline for your interface which information is optional and which is mandatory.

Less is more

To place more information in an interface may sound tempting in theory. In practice, you will realize however that your partners will be less able to provide data, the more unusual it is in the context of the interface. What this means in detail, depends on the particular interface type and your industrial sector. Therefore, you should investigate in the guidelines of other market participants before the mass rollout and also interview your most important partners, which information they typically provide. You can of course try to convince your partners to provide additional information. However, if your partners are not legally bound or depend on you economically, it will become difficult to accomplish this intention on a grand scale.

Agile and EDI interfaces - no perfect match

Incremental work is a standard method in many areas within software development. For EDI interfaces, a constant revision of the specifications is advisable only in rare cases. The reason: Your partners maintain either an EDI team on their own that is busy with a lot of requirements or they are a customer of a service provider and have to pay him for every adjustment of a mapping. Therefore, we recommend that you rather invest more time into the pilot phase and instead rework the interface later only in the most urgent cases.
Please find here part I and part III of our series.
Imprint / Data privacyDisclaimer