Best Practices for Mapping: Application Files and Fields
Please note: This post originally appeared on Extol.com (EXTOL has been acquired by Cleo).
Successful EDI implementations must begin with the development and employment of efficient object naming conventions using “best practices.” This will avoid aggravation and redevelopment at a later time. “Doing it correctly the first time” is a most-relevant piece of advice. This is of particular advantage when creating files (tables) to store EDI data (the implementation and deployment of EDI interface/staging files and in support of both inbound and outbound EDI transactions).
EDI interface files generally support both the Enterprise Resource Planning (ERP) applications and the EDI transactions exchanged with trading partners. The types of files used depend on business requirements and how you will process data within the ERP. Implementation could be affected by the degree of external programming, and how such custom programs are designed for interfacing with the EDI database files. Your choice should be based on “what you feel more comfortable working with” and “how easy changes can be made if needed in the future.” Regardless of outside influences, one thing is for certain, “do-overs” are not fun!
When creating your interface files, it is important to develop and standardize in-house naming conventions that can be used for all files. This will help to identify a file’s purpose and keep your files organized. Remember, you may not be the only source who must use or have access to these files. Below is a list (with examples) of items that should be considered when developing both a file and field naming scheme:
Direction Code: In, Out, Send, Receive
Map/Transaction Type: 810, 850, INV, PO
Structured Data Levels: Header, Detail, Address, Note
Segment Labels: BEG, IT1, N1, MSG
Element Labels: BEG01, IT102, N104
When identifying field (column) names, taking the time to include Element ID and Element Description detail will speak volumes when future technicians must figure out the data because the original file specs conveniently disappeared. One recommendation is to include all Segment and Element descriptions in the metadata. This also significantly simplifies field searching when building maps or developing programs.
Consider the following two examples:
Field Name: “PONUM” Description: “Purchase Order Number BEG03”
Field Name: “CSTORD” Description: “Cust Ord #”
A brief glance will quickly reveal how the simple use of common and consistent conventions can have a noticeable effect on interfaces (programs, maps, etc) that access data, by improving search functions and removing the possibility of field misuse and abuse.
By taking the time to define and apply best-practice naming conventions prior to any development, EDI interfaces can be built once and used many times. The alternative is to make customized changes until the interface (and the adding of new objects) grows out of control. Keeping your files and fields organized by using standards for naming and descriptions can make mapping a breeze. Above all, try to keep in mind that you may not be the only person who has to use these files. Long after you’ve moved on, somebody will either be cursing or praising you. Make it the latter!