RE: is edi translator software difficult to write? was: edivendorcomplaining

One of the difficulties is interfacing into vendor software. The ERP
package we use (Vanguard) has built-in interfaces for both (old version)
native Gentran and native Extol EDI integrator. Using an unsupported
(from Vanguard's POV) translator may break many parts of Vanguard if one
tries to do their own interfacing.

In reality, it is the interfacing to vendor packages and systems/work
management, as well as configuration flexibility, that one pays for in
an EDI package.

For example, many here talk about ditching a native solution and going
to PC-based EDI. How will the documents get to/from the PC? Is that
built into the new package or does one have to build (yet) another
interface?

Do you depend on real-time document transmission? In the automotive
industry, the going standard is sending and confirming an EDI document
within twenty (20) minutes. What happens if there is a document
translation error? How often is polling?

I'm not trying to defend native translator vendors (especially the
pricing issues discussed), but it is very advantageous to running the
translator alongside your line-of-business package. Especially if you
have hard timing requirements from your customers.

Loyd Goodbar
Business Systems
BorgWarner Shared Services
662-473-5713

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steve Richter
Sent: Thursday, June 05, 2008 12:31 PM
To: Midrange Systems Technical Discussion
Subject: Re: is edi translator software difficult to write? was:
edivendorcomplaining

what is the difficulty in switching from one edi package to another?
presumably, they all map from and to these edi documents and
transactions. Are there EDI packages written in Java which can be
dropped on an i system and run as is?

basically, why cant customers remove Innovis and replace it with
another package that handles the same EDI specifications?