Whether your company is integrating with a licensed package or a custom inhouse system, it is always wise to begin data analysis at the ultimate destination. If, for example, the first planned transaction is the inbound purchase order, the EDI team begins with analysis of the order processing system’s requirements. For this portion of the project the team must include the person most knowledgeable of the application.

To begin the data analysis , the EDI team compares the structure of the data at the ultimate destination with the structure of the original data. An in-house order processing system might have header records and detail records. The major groups of ‘records’ in the original purchase order in the X12 format are header, detail and trailer. An outbound invoice in X12 has similar major groups of ‘records’ :header, detail and trailer. However the invoice may originate in an accounts receivable system that has shipment header, shipment detail , order header, order detail and a customer master file.

Once the structures have been compared, the analysis moves to each field required at the ultimate destination. Most fields that are required by most order processing systems are present in most X12 based Purchase Orders (Pos), although they may have different field names. If a required field appears to be missing, it may be made available by building a cross reference file. For example, customer number is not usually sent (or even known) by the customer. It may be built into a cross-reference by EDI Sender ID.

Once each field has been found , its destination content and format need to be compared carefully with it’s origin. The in-house order processing system’s field for customer department may be a 4-position numeric. The department number is an example of a secondary key needing special attention. Additional examples are store number, service provider ID, carrier code, name, product code etc. Surprisingly, primary keys usually need less attention, since MIS departments have learned to honour the primary keys of their trading partners. Examples of primary keys are:

• Customer PO
• PRO Number
• Invoice Number
• Bill of Lading Number
• Claim Number

If industry wide codes exist, they will greatly facilitate the use of EDI. If the application is using an industrywide code in a minimal way, the time of EDI development may be the time to fully adopt such a code. An example of minimal adoption is a Drug Enforcement Agency (DEA) number used by pharmaceutical manufacturer as a customer cross-reference. The building of a cross reference is an ongoing, effort intensive, error prone process. It may be erroneously viewed as a responsibility of the EDI team and may be a high pressure, high profile activity when any imperfections stops a pharmaceutical order or charge back. It is a pharmaceutical industry best practice to use the DEA number as the customer number itself. Other examples of valuable industry wide numbers are Dun and Bradstreet (DUNS), Standard Carrier Alpha Code (SCAC), the Health Industry Number (HIN), Universal Product Code (UPC) and National Drug Code (NDC).

Mapping, Defining to the EDI Software

Once the data analysis portion of the mapping is complete, the ‘map’ is defined to the EDI translation software. Unless a ‘budget priced’ EDI package was licensed (for a quick implementation) the package will allow the EDI co-ordinator to define the map. The map may be likened to a database definition. When the EDI co-ordinator ‘maps’, the EDI software stores the map, usually in tabular form. Later, when a transaction comes into the translation portion of the EDI package, it uses the map to determine where each incoming field goes and whether to re-format.

The ‘mappers’ that are more user friendly tend to be less robust, software developers intend for mappers to be capable of being used by user-oriented EDI co-ordinators. Yet the developers also want the mappers to be capable of doing everything every thing possible to avoid custom intefaces.

Developing Custom Interfaces

EDI interfaces occasionally require logic that is beyond the capabilities of the most robust EDI mappers. The somewhat complex structure of the accounts receivable databases, might call for a selection or pre-processing program. This program could build outbound header , detail, and trailer records for example, a structure similar in nature to X12.

Logic to convert particular fields may be viewed with suspicion, for example is it wise to remove the DUNS prefix from a WALMART store number?, Is it wise to extract the size of a garment from positions 7 through 12 of the manufacturer’s ‘intelligent’ product code? Occasionally a field conversion may be necessary. Such conversion may be done in a pre or post processing program or in a user exit callable by the EDI program. An example is conversion of a date in century, month, year, day format to X12’s YYMMDD format.

Also viewed with suspicion would be custom edits per trading partner, for example it is not the responsibility of an outbound EDI interface or translator to avoid JCPenney freight charges. Rejection of such charges by Penney quickly comes to the attention of the EDI co-ordinator, but should be addressed further upstream. If a ware house is incorrectly submitting charges, the warehouse software must have additional edits put into it.

print this page