What is EDI mapping?
EDI mapping is a process of conversion in which EDI data is translated into a format that is better used in a new technical environment, such as an ERP system.
During an EDI mapping event, data structures are translated from an EDI standard format (EDIFACT, ANSI X12, OFTP2, etc.) to a proprietary file that can be easily ingested into a back end system (CSV format, txt, SAP IDoc, Flat File, or another ERP specific format).
It is important to note that EDI mapping occurs in both directions, originating from an ERP, or originating from a trading partner. So, IDoc to EDI mapping is the reverse of EDI mapping to IDoc.
The diagram below illustrates one of many EDI mapping examples:
In this example, the SAP ERP system on the lefthand side uses an IDoc internal format. To communicate a message to a trading partner, that IDoc file needs to be converted into an EDI transaction and sent to a trading partner using a standardized EDI Format like ANSI X12 or EDIFACT. Because the trading partner's ERP (Acumatica) uses JSON for its internal format, the EDI file is converted into a JSON file before being ingested into Acumatica ERP on the righthand side.
Again, it is important to note that this EDI mapping is bilateral, so our explanation is not limited to a left to right workflow. EDI maps flow in both directions.
3 benefits of EDI mapping
Automation – EDI mapping automatically sends external data to critical internal systems, creating a repeatable process.
Accuracy – EDI mapping eliminates manual processes, eliminating the risk for user error, and ensuring EDI data is accurately imported into back end systems.
Connection – EDI mapping allows for the creation of formats like XML or flat file that can easily be used to communicate EDI data to business trading partners.
Successful EDI implementations must begin with the development and employment of efficient object naming conventions using “best practices,” to avoid aggravation and redevelopment at a later time.
This is of particular advantage when creating files (tables) to store EDI data.
File tables are created during the implementation and deployment of EDI interface/staging files and in support of both inbound and outbound EDI transactions.
EDI mapping Best Practices - Files and Fields
EDI map development involves the creation of interface files to translate one form of data into another.
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 much custom programs are designed for interfacing with the EDI database files.
When creating EDI 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 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 before 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.
EDI Mapping for Modern Businesses
EDI mapping is critical to meeting trading partner demands, eliminating manual entry, and streamlining the movement of data from front-end to back-end systems.
A well-constructed EDI mapping solution or process will deliver complete control over business data, as well as enhanced visibility through the delivery of accurate and automated EDI data to the back-end systems.
The creation and maintenance of one or two EDI maps can be done in-house, but as standards change, certificates expire, and trading partner demands grow, companies are increasingly likely to adopt a managed services approach to EDI mapping.
Cleo offers a bit of everything to meet your EDI needs, from automated EDI mapping tools for faster trading partner onboarding, to self-managed EDI integration processes for greater internal integration control and agility.
Because Cleo has become an industry leader in the EDI software space, we offer out-of-the-box EDI maps for connecting to major companies across the supply chain.
With Cleo, EDI mapping is taken care of and you can focus on what's most important to your business: your customers.
Cleo automates EDI mapping processes that connect, transform, and route EDI and non-EDI documents between internal and business partner applications, without the need for custom code.