Step 5 - Internal Business Process Mapping and Data Analytics
During EDI implementation, it is smart to start with data analysis with the end goal in mind. For example, if you have your eye on using an EDI system for inbound purchase orders, then your EDI implementation team should start by analyzing system requirements of the ordering system.
Data analysis starts with the EDI implementation team comparing end goal data structure to current data structure. In-house ordering process may have designated data format names for Purchase Order (PO) data, such as "header", "detail", and "trailer". Another file in another department or with another trading partner, however, may call those same fields by a different name (i.e., "shipment header", "shipment detail", and "shipment trailer".
If there are discrepancies between the number and natures of the format data between different POs, a cross reference file can often make the field available. For instance, if a customer number is not usually sent, one may be built into the cross-reference file via an EDI Sender ID.
After all of the fields have been found, origin content and end goal content should be compared closely. 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 include:
• 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.
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 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 put into it.
| << Integrate | Pilot >> |
