EDI Translation Map File for Multi-Format Output

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional approaches for translating EDI transactions to forms compatible with multiple trading partners are cumbersome, time-consuming, and inefficient, particularly when different organizations support different EDI standards or versions.

Innovation Solution

A system and method that utilize a map file to translate inbound EDI transactions to multiple outputs by defining mappings between inbound and outbound EDI transactions, including non-EDI formats like text files and XML, using a graphical user interface to generate the map file, which specifies the outputs and mapping rules.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If conventional approaches are used to translate EDI transactions to multiple trading partner formats, then translation capability is provided, but the process becomes cumbersome and time-consuming

Engineering Contradiction:
Improvetranslation efficiencyVSAvoidtranslation time
Core Design Contradiction:
ProductivityVSLoss of time

Solution Approach 1:

The system performs preliminary action by pre-defining translation maps that specify how inbound EDI transactions should be translated to various outbound formats for different trading partners. These maps are created in advance and stored in a database, allowing the translation process to simply retrieve and execute predefined rules rather than creating translations from scratch each time, thereby significantly reducing translation time and improving efficiency

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system introduces an intermediary translation map as a mediator between the inbound EDI transaction and the multiple outbound formats. The translation map serves as an intermediate layer that contains the translation rules and logic, decoupling the translation process from both the input transaction structure and the output format requirements, which simplifies the overall translation operation and improves processing efficiency

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If translation maps are created for each trading partner, then compatibility is improved, but system complexity increases

Engineering Contradiction:
Improvetrading partner compatibilityVSAvoidmap file complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system applies segmentation by breaking down the translation process into distinct, manageable components: inbound transaction definitions, outbound transaction definitions, translation maps linking them, and trading partner-specific configurations. Each component is stored separately in the database and can be independently modified, allowing the system to handle multiple trading partners with different requirements without creating an unmanageably complex monolithic translation system

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The translation map structure is designed with universality to handle multiple trading partners and various EDI formats through a common framework. The same translation map infrastructure can accommodate different EDI standards (X12, EDIFACT, HL7) and can be configured for any number of trading partners by simply adding or modifying map definitions in the database, rather than requiring separate translation systems for each partner

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentUS9002870B2System, method and computer program product for EDI-to-EDI translations
Publication Date: 2015.04.07 SYBASE INC
  • US9002870B2 patent drawing
  • US9002870B2 patent drawing
  • US9002870B2 patent drawing

AI summary

For the purpose of mapping an inbound Electronic Data Interchange (EDI) transaction to one or more outputs there are operations comprising receiving an inbound EDI transaction, and translating the inbound EDI transaction to any combination of EDI outbound transactions and non-EDI outbound transactions. Such translation is performed according to a map file, which is generated as follows. The inbound and any outbound EDI transactions are defined, and templates of the inbound and outbound EDI transactions are also defined. Then, mappings between the template of the inbound EDI transaction and the templates of the outbound EDI transactions are defined. A mapping between the inbound EDI transaction and application data may also be defined, where the application data may include a text file, a XML file, and/or a table of a database. Rules relating to or governing the mapping of the inbound EDI transaction to outputs may also be created. These definitions, mappings and rules are stored in the map file.