Effective EDI Mapping allows data exchange between your business and its partners and clients with measurably improved efficiency, elevating profitability, customer relationships and long-term success. In contrast, ineffective EDI mapping ties up resources and creates problems that affect your entire organization. Our team has put together some EDI Mapping best practices for you to consider when taking next steps.
Mapping has changed considerably since the early days of EDI. While the basic concept of mapping remains the same, for many years now EDI mapping tools have been characterized as “any-to-any” mappers. Long gone are the days when you simply took a proprietary format and mapped it to an X12 transaction format and vice versa. Companies today have to deal with a multitude of standards and versions, some industry specific and some international standards, or even standards specific to a country other than the U.S.
In addition to the well known X12 and EDIFACT standards, we now see many flavors of XML needing mapping to/from other formats. We still have RosettaNet and foreign standards like Odette, which require specialized mapping knowledge. Then we also have csv files and ODBC mapping. HIPAA transactions, though based on X12, require another level of mapping expertise.
“Mapping should not include application logic. Many companies make the mistake of putting application logic in maps when, if fact, that logic should be inherent in the application itself. Rules and tables are fine within the mapping process but application logic has no place in a map. Mapping should be seen as the transformation of one format to another format – and not much more.
When application logic is included in the mapping process, any migration to another EDI platform can become a nightmare and cost far more than it otherwise should”. – Wayne Marshall, Vice President, Professional Services
“If possible, always get valid source and target data. If you are building a map with test source data, you may develop something that only works with that test data, and doesn’t take into account actual formatting of real data (such as date formats, lookup values, etc.) If you are building a map without valid target data to compare against, you may end up with results that look good, but you won’t know that the data is invalid until you are in the test phase. You will save yourself immense time and development effort if you know what your source and target data look like”. – Mark Beckner, EDI Staffing Top Consultant
“It’s important to understand the client’s situation, requirements and expectations before you even begin mapping. What has brought about the need for this project? How will the data be used? Is this a new or existing transaction for them? What is their trading partner’s level of EDI expertise? These are merely a few of the questions you should discuss with your client. You’re being engaged as a professional, come into the relationship as if you were supporting this map long-term, because your client will certainly be in that role.” – Mike Forrester , EDI Staffing Top Consultant
Leave a Reply