EDI Implementation Guidelines and Mapping Practice Notes
EDI Implementation Guidelines and Mapping instructions are very important issues to consider when starting EDI partnership. Keep in mind that EDI transaction sets are often general, vast, and broad in scope. One trading partner may require, for example, to use certain segments in the definite transaction, or to use particular ones in a certain way, within the specifications for that segment. That is why EDI Implementation Guidelines must be considered carefully.
There can be a lot of information in EDI Implementation Guidelines. The main components are EDI mapping specifications and business rules, EDI communications options (VAN, AS2, etc.) and sometimes label and packaging requirements. The party creating EDI Implementation Guidelines refers to the EDI standards manual (e.g. ASC X12 manual) to pick out the best segments and elements required for their business process.
Mapping Practice
EDI Implementation Guidelines also may include mapping guides. The mapping work should start long before opening the mapper feature of the EDI application. The mapper should have a business analyst role of gathering data requirements. During the process of learning EDI Implementation Guidelines and gathering requirements, the input data format and the output data format must be identified and understood by the mapper.
Mapping notes
- Connect elements/segments at the same hierarchal level. For example, connect header level segments on the input side to the header level segments on the output side, detail to detail, and summary to summary.
- Connect elements/segments with the same data type. For example, map the numeric fields to numeric fields, dates to dates, strings to strings. Make the data type in both the input and output section the same whenever possible.
- Set the same maximum usage (loops) on the input and output side of the map.
- Create all segments/elements in the map that will be in the file. For example, if in the CSV file a certain column is not being used, map it anyway. Some translators require all the fields be mapped and this is a good practice for troubleshooting.
- Use standards when possible (ASC X12, EDIFCAT, RosettaNet and etc).
The content of the data and the format of the data have to make sense to the mapper. If the mapper feels that the input or the output format of the data is unreasonable (e.g. too much unnecessary data) then the mapper should make the case for this concern and not simply map away with unreasonable data formats. This will help prevent troubleshooting and maintaining the map in the future and should make the data conversion process more efficient.