EDI Mapping Notes
EDI 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 for EDI mapping. During the process of gathering requirements, the input data format and the output data format must be identified and understood by the mapper.
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.
While EDI mapping:
- 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).
EDI mapping is a very important process that requires lots of EDI knowledge. Connecting elements and segments, creating loops for further transactions delivery require special knowledge of partner guidelines and standards. EDI Academy provides sufficient information regarding EDI Mapping at Advanced EDI Training seminars.