EDI Mapping Approach: Why Direct Mappings Don’t Make Sense

Mapping data directly or canonically (indirectly) between various EDI formats and the necessary internal ERP formats poses an interesting conundrum. Here we discuss the reasons for considering the canonical approach over the direct approach to EDI mapping.

We all know that EDI is here to stay, but what also will stay is the complexity of EDI “standards”. Not only are there numerous EDI data structures, e.g. EDIFACT, ANSI X12, SWIFT, ODETTE, VDA and others. The real complexity comes with the fact that large companies (“hubs”) impose their specific interpretation of the standard, i.e. their specific EDI guideline to be used by all trading partners that connect with them. This makes life easy for these “hubs”, but for suppliers which need to setup EDI connectivity with many such hubs this can become a nightmare.

But you have to tackle this challenge so the decisive question is:

‘How does your IT department transform data between various EDI standards and your required own in-house formats (to satisfy the requirements of possibly hundreds of trading partners), so that your organisation can function most efficiently as a business’?

Consider the two approaches available to you:

Direct EDI Mapping Approach

The most common method is to map data between format a and format x, i.e. take a field from format a and map it directly to the corresponding field in format x.  This is seemingly the most simple, efficient, and expedient approach.

However this is NOT the most pragmatic approach, as the world of EDI becomes very complex, very quickly. Consider the situation where formats b and c also map directly to x, but then the format of x changes. The change to format x now has to be reflected in three mappings, i.e. a→x, b→x, c→x. Consider also the situation of having reverse mappings – this now means changes to a total of six transformations within a single trading partner relationship. Think not only of the time it takes to create the maps, but also the time it takes for updates and testing. There is obviously a scalability issue if there are more than just a few trading partners. This is shown in Figure 1.

The lack of scalability with this approach comes about by the effort required to implement and maintain changes. Every time something on the ERP system or a business process changes, there is a potential change in the data structure. If this happens every single map needs to accommodate the change. This might be acceptable with 5 or so trading partners connected over EDI, but what if you have 50 or 500?

Canonical (Indirect) EDI Mapping Approach

Consider the same scenario as above. This time the inbound data is firstly standardised into a canonical master format (we’ll call this ‘cmf’) before being mapped to the target format, i.e. a→cmf→x, b→cmf→x, c→cmf→x.  Now when the format of x changes, only one mapping (not three) has to reflect this change, i.e. cmf→x.  For the reverse, again only one mapping (not three) has to change, i.e. x→cmf.  This is known as canonical mapping and it carries with it the huge advantage of making EDI maps so much more manageable and accommodating to change.

A canonical mapping approach separates the map used for the EDI trading partner from the map used to connect the ERP system(s) as shown in Figure 2.

The ‘canonical master format’ we use is called SEEXML – an XML format developed by SEEBURGER based on our experience from working with ~10,000 customers and their trading partners. For each ERP-system and business process ONE process map is created, whereas on the partner side ONE map per partner and process is provided by SEEBURGER. SEEBURGER treats these partner maps as ‘product with version’. Any changes to the partners are handled by a partner map update under maintenance, whilst any changes to the backend simply requires a change to the process map.

With this approach, change and maintenance of the setup is much easier. Every time something on the ERP system or a business process changes, there is once again a potential change in the data structure. However, this time around only the process maps may need to be changed, not the partner maps. Therefore the canonical (indirect) approach is very scalable.

SEEBURGER have absorbed the cost of developing and providing an extensive repository of more than 13,000 off-the-shelf trading partner maps (including both common and specialised maps) across every industry. Updates to these trading partner maps are included as part of a standard maintenance & support agreement, whilst licensing new trading partner maps entails a very small fixed cost. In the rare case that a trading partner map is not yet existing then this is developed and provided at the same small fee like any map from the repository. This means that our clients never encounter ‘cost spikes’ when looking to grow their business by way of expanding their trading partner community. This approach can be used by all SEEBURGER customers either on-premises or in the Cloud.

Dive deeper into the EDI, in our Blog Top 6 EDI Challenges

Key Benefits of Indirect (Canonical) SEEXML Mapping approach:

• Simplicity – reduce the number of maps to a minimum
• Scalability (external) – when connecting a large number of EDI trading partners per EDI-process or…
• Scalability (internal) – when connecting more than one ERP system
• Flexibility – changes are much simpler and faster to implement
• Cost – reduction in both time and money needed to create, modify and test maps

To cut a long story short – with dozens of business critical trading partner connections where mappings need to be created and maintained, it is well worth considering a canonical (indirect) mapping approach.

With more than 30 years of EDI experience, SEEBURGER know a thing or two about mapping between the vast amounts of EDI formats. Pragmatically we keep things simple, efficient, and expedient by utilising a canonical (indirect) approach to mapping.