>>We had a fairly good discussion over on the fox.wikis a while back about EDI. Here's the link --> http://fox.wikis.com/wc.dll?Wiki~EDI~softwareEng which should take you to the article. Perhaps this can help.
>
>Thanks! I won't have a chance to read all the discussion and articles until later... Quick question - Is there actual an interface/program that handles EDI or is it more a matter of standards/procedures or language? Renoir
<<<<


Renoir,

Any larger package "ready for interfacing" (f.e. ERP) has or should have standards for inward and outward EDI-interfacing, but will be part of the package. The EDI-provider however will have these standard-like-programs, ans just anticipate on your wishes for the output-data and the input-data.
Please note that just because of this a standard like EDIFACT isn't so much of a standard, since all *users* can do what they want (ie deliver / receive data in any liked format), and the Providers make f.e. EDIFACT of it.

When you wish to do things 100 %, you can send EDICAT (etc.) yourself, but be prepared of many 100 pages describing this standard, which anticipates on just all messages which might exist. I.e. this is far too much for any business, just needing parts of it. I mean, steel is very different from food, and medicine is a complete other world, which for overhere doesn't comply to normal standards, but to their own only; looking at declaration-types only, there are many many forms of this, and interchanging this electronically is what it says. But, this is not "formal" EDI which complies to general standards.

If you are wbout to begin such a traject, it is nothing to be afraid of, but please depend on customers who already know, and you learn from them (c.q. their messages). Don't let you be manouvred the other way around, because it 'll bring you close to dead (as how your experienced customer just kept alive).

Once you know how outward- and inward-messages look like, you can imagine it is not so much more than keeping track on what's already been sent / received, and the only additonal stuff lies in the need of EAN-codes (or whatever it's called at your's -> unique item-codes and address-codes for various objectives, like -invoice -deliver, etc) defined by a higher organization).

Once you have the experience, you may be able to define a complete new inward interface within a day, and when you make things generic, you can let the user define the outward-interfaces (which are always many more than inward). The latter can easuly be done by a reporting-mechanism.

HTH,