Step 5—Internal Business Process Mapping and Data Analytics
During EDI implementation, start with data analysis and the end goal in mind. For example, if the first planned transaction is the inbound purchase order (PO), 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 about the application.
Data analysis starts with a comparison of the end goal data structure to current data structure. After all of the fields have been identified, origin content and end goal content should be compared closely. If there are discrepancies between the number and nature of the format data, a cross reference file can often make the field(s) available.
For example, the major groups of records in the original purchase order in the X12 format are header, detail, and trailer. An outbound invoice in X12 also has header, detail, and trailer as major groups of records. 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. If a customer number is not usually sent, one may be built into the cross-reference file via an EDI Sender ID.
Special attention should be paid to primary keys such as customer PO, PRO number, claim number, invoice number, and so on. Secondary key data can include customer department number, service provider ID, carrier code, store number, and the like. Industry-wide codes make EDI implementation easier and are suggested for EDI implementation if such usages are currently being used minimally or not at all. Examples of valuable industry-wide numbers are below:
- Dun and Bradstreet (DUNS)
- Standard Carrier Alpha Code (SCAC)
- Health Industry Number (HIN)
- Universal Product Code (UPC)
- National Drug Code (NDC)
Business Process Mapping: Defining to the EDI Software
After data analysis has been completed for EDI system implementation, the resultant map is defined to the EDI translation software. Most comprehensive EDI software systems let the EDI implementation coordinator define the map, which is similar to a basic database definition.
After the information has been mapped, the EDI software stores that map. When an appropriate transaction reaches the EDI translation section, the mapped data is used to determine if and how to reformat the data.
Development of Custom EDI 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.
View logic to convert particular fields 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 CCYYMMDD format.
Also to be 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 JCPenney quickly comes to the attention of the EDI coordinator, but should be addressed further upstream. If a warehouse is incorrectly submitting charges, the warehouse software must have additional edits made.