Good morning group,

We finally have to bit the bullet and add EDI capabilities to our software.
We are looking for suggestions on how to accomplish this. Your help is
greatly appreciated (in advance). Please consider that all or our customers
are running on D/Linux or D3/AIX.

Jeff

--
Jeffrey Kaufman
Key Data Systems Group
www.keydata.us
1111 Grizzly Peak Blvd.
Berkeley, CA 94708
510-486-9015 office
510-486-9016 fax
559-432-3832 cell

"Jeffrey Kaufman" wrote:
Jeff, I've done a lot of EDI in the past. Surprised?

The first thing to note is that EDI is not a technical problem, it's a
technical means of implementing a business solution, and there is
often as much business discussion and negotiation over how to
implement the standards as there is coding and technical effort.

Secondly, many companies purchase big and expensive EDI packages that
claim to do a lot of stuff. To get your data into these packages you
need to format your data carefully. Well, if you're going to do that,
why do you need a package? If you do decide to evaluate commercial
packages, you will find that they do data validation, handle
functional acknowledgements, and provide for some form of guaranteed
delivery. Personally I think we can do all of this with custom code
but it's worth looking at some of these offerings.

Many people write code to support a single EDI document (810, 850...)
for a single trading partner, and then copy that code to support other
documents and/or other partners. The code looks absolutely awful when
this process starts. Learn how the documents work and try to work out
some plan for a more table driven approach. As with any project
involving a user interface (and that's all an EDI doc is, except that
it's a human readable machine interface) try to separate business
rules from the code that generates the actual document. Your code
will be much cleaner and can serve as a template for similar projects.

Dave Taylor at SysMark here in southern California has software for MV
that does some of the EDI leg-work. I recommend you check with him as
one of your options:
davet@ removethispartSysmarkInfo.com

HTH bud,
T

"Aren't standards wonderful? And so many to choose from." - unknown

I've written a few programs to read and create EDI documents. I know what a
hassle it is to try to accommodate each trading partner. That is why I am
searching for a package that has built in mapping capabilities. An MV
solution is preferred.

Thanks for the info Tony. I'll give Dave a ping.
Jeff

"Tony Gravagno" <address.is.in.posts (AT) removethis (DOT) com.invalid> wrote in
message news6a943p91f1c58l57mqg2hct817k4ecm5l (AT) 4ax (DOT) com...

"Jeffrey Kaufman" <jkaufman (AT) keydata (DOT) us> wrote

right now. It's a simple, straight forward shipping manifest. We ship
their product, we notify them when we do it with a standard 856 transaction.
The specs are very clear and completely ambiguous.

Their PO is our Bill of Lading; our PO is their MOI; what they call Lot # is
in the field we call Dimensions.

And that ST* transaction at the end; is that a count of lines inclusive or
exclusive; the spec doesn't say.

So we test; send them the results; they send back that it's wrong, but won't
tell us what the right answer is.

I hope your EDI partner at least speaks the same language you do.


Mark

The reason they won't tell you the right answer is because they don't know.


"Mark Brown" <mbrown (AT) drexelmgt (DOT) com> wrote

"Jeffrey Kaufman" <jkaufman (AT) keydata (DOT) us> wrote

Jeff,

Could be. What's Japanese for "Huh?"

Mark

"Mark Brown" <mbrown (AT) drexelmgt (DOT) com> wrote

If EDI is a standard, then why does each trading partner need a unique
manual that is over 150 pages long? With one of kind comments every
5 or 10 fields/attributes?

rog

"rog" <rglenospamfld (AT) optonospamline (DOT) net> wrote

Sarcasm, right?

HL7 (transmission of health records), too.

Mark, the problems you're citing explain exactly why I've said EDI
involves a lot of upfront discussion about what goes into the fields.
The coding is simple once the agreements are in place. I've sat at
the round table with Sears (Catalog/Retail), Wards, JCPenny, Dell, and
consulted for others, to ensure that we all understand the business
use of the documents which are intentionally ambiguous to allow
companies to use them as they wish. Discussion happens first, then
the coding and testing begin. The people involved frequently include
IT, accounting, shipping/receiving, and at least one business manager.
Get one person on both sides to ask and answer questions after the
meetings. Establish a cordial working relationship to ensure that the
contact on both sides is aggressive about getting the right answers
fast, without anyone feeling like they're being pestered. Don't take
answers from anyone else. Get everything in writing. This protocol
is not optional, this is how the process of EDI development works - or
you will find how it does not work...

I have and can consult with companies looking to enter into agreements
with other companies, and can serve as the contact as described above.
The first time you do this it might be helpful to have someone at the
table with you who has already been through the process.

TG@ electronic.dont.mean.people.shouldnt.talkNebula-RnD.com

"Mark Brown" wrote: