RE: EDI and Inovis from Library Data

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Thursday, July 12, 2007 1:20 PM
To: Midrange Systems Technical Discussion
Subject: Re: EDI and Inovis from Library Data


My previous experience has been with comma delimited, tab
delimited and pipe delimited files -- but searching for an
asterisk instead of a comma isn't a major difference. And
searching for a tilde instead of a CRLF isn't a major
difference. And using a variable so I can search for any
character isn't a big difference.

For me, writing the data in EDI format isn't significantly
more difficult than what I'm doing already, and reading it in
EDI format isn't significantly different.

I actually wrote an X12 850 translator many years ago that is still in use,
though the company now has
Gentran Server for all of its other EDI.

The difference between reading EDI and "standard" delimited files is the
multiple segment "record"
formats, nested loops, and interdependency's between fields/segments. At least
I don't normally see
such requirements in standard delimited files.

Not saying you couldn't do it Scott, but I think there is a difference.

On the other hand, you've done XML parsers, an EDI parser wouldn't be much
different.

Speaking of XML, perhaps something to consider would be asking your VAN to
translate the EDI document
into an XML document. Given v5r4's XML capabilities, and your own port of
EXPAT, getting the data in
XML format instead of EDI might make life easier.

What I *am* missing, however is the "schema checking" that
the EDI translator provides. Other than manually testing my
software to verify that it works properly (as you do with any
programming project) there will be nothing that verifies that
my software conforms to the X.12 standards.

I'm going to guess you are using ANSI X12 850s for the

orders. If you

send them, then besides correctly formatted data, you'll need to
generate unique and consecutive control#s

We receive X.12 850, 855, 875 orders. We send 810 and 880
invoices and
856 advanced shipment notices. Plus, of course, 997 for
functional acknowledgements. We've been doing EDI for more
than 15 years now, and I'm familiar with the standards and
control numbers already. Generating control numbers myself
(by adding 1 to a field in a control file) doesn't seem like
a big deal to me.

The key thing here would be how many different maps/versions do you currently
need to handle those
documents from how many partners?

Do you create a parser for each version/map? Or create a parser that reads the
X12 specs and map
specs from a file like a commercial EDI package would?

Even if you've only got 1 850 map, you'd want to make sure your parser is
flexible enough to handle
any properly formatted 850; even if it's got data you don't need and you just
want to ignore it. I'd
say you'd definitely want a copy of the X12 specs for each version you intend
to receive.

Don't forget to think about new versions of the 850 spec. Sooner or later
you'll get a new partner
that doesn't support anything but the latest version.

I had it easier when I did my 850 translator, as there was an industry trade
group that defined a
subset of the full X12 850 spec for use in my industry. Which meant I had
considerably less to worry
about.

Have fun Scott!

Charles




This e-mail transmission contains information that is intended to be
confidential and privileged. If you receive this e-mail and you are not a
named addressee you are hereby notified that you are not authorized to read,
print, retain, copy or disseminate this communication without the consent of
the sender and that doing so is prohibited and may be unlawful. Please reply
to the message immediately by informing the sender that the message was
misdirected. After replying, please delete and otherwise erase it and any
attachments from your computer system. Your assistance in correcting this
error is appreciated.