EDI management: tracking partner relationships and functions
EDI management keeps track of the attributes that differ from one trading partner to the next. The following are some examples of EDI management:
• Contact information for the business person responsible for EDI.
• Contact information for the technical person responsible for EDI.
• Data transport method used, and account information to connect to a VAN or Point-to-Point.
• The severity level (critical or warning) if control numbers are out of sequence.
• E-mail address of the person to alert when errors are found.
• EDI standards version number being used.
EDI management tracking and auditing
Problems will arise no matter which form of electronic commerce is used. With EDI management, trading partners have the ability to track the whereabouts of an EDI transaction that did not make it to the business application. EDI translation software provides various logs and reports to trace a transaction throughout the process. An inherent audit feature in EDI translation software is the functional acknowledgement, which is known as the 997 transaction. Every EDI transaction that is sent by a trading partner requires an acknowledgment of receipt from the other trading partner via the 997. A positive 997 means the original transaction was received and passed EDI translation. A negative 997 means the original transaction failed translation. Not receiving a 997 means there was a transmission problem between the two trading partners.
A document repository is a place to store all incoming and outgoing EDI and non-EDI transactions. Transactions are stored in a database in their original form, and all activity against each transaction is logged. This makes is possible to trace a transaction from all points between Data Transport and Data Integration into the business application. When it becomes necessary to re-send a transaction due to operational problems, the original can be retrieved from the repository.
Another function of the document repository is to facilitate an EDI document ‘turnaround.’ Many business applications do not have a home in their database for fields that arrive on an incoming EDI document. The trading partner expects the data in those fields to later be sent back in another EDI document. An example is a purchase order (850) that is ‘turned around’ into a purchase order acknowledgement (855). Since the business application does not store some of the EDI data, the original 850 document can be retrieved from the repository to select data to place into the 855.