Re: EDI and Inovis from Library Data

Scott Klement wrote:

I understand where you're coming from with this statement. However,
I've written a lot of code over the years that generates and parses
delimited files. It's easy for me, even if it may seem difficult to
other people.

I agree it should be easy for you.

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.

Yes, it's basically the same thing.

When parsing EDI files, you should be able to identify the delimiters
from the end of the ISA segment. Don't assume any particular character.

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.

It probably isn't. But you might ask yourself should I be writing
something that I could buy instead.

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.

True. Which gets back to why we buy standards compliant software. You
could rely on your trading partners to validate your data and your VAN
will probably do some basic validation as well. The specs are not free,
but you can figure them out or get them from your partners. Buying them
from X12 might be justified in your case.

Alternatively, you might consider purchasing EDI documentation software.
We use EDIFECS SpecBuilder. It can generate specification
documentation, has a spec browser and data testing tool. Made producing
our trading partner documentation a lot easier.

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.

Yes, the algebra of counters isn't hard. I mentioned it only as
something that needs to be handled when generating documents. Since you
understand all this, you probably can probably accurately estimate the
work involved.

Yes, I understand that. Prior to this thread, I was under the
impression that EDI Vendors forced you to use "official EDI software" to
communicate with their VANs. So I guess what I'm looking for isn't info
on whether I need a contract or who the VANs are. I've worked with this
stuff for many years! I guess I was more interested in info about how I
do the communication myself -- when I sign a contract with a VAN, will
they give me that info? Or is it just as simple as "FTP the file,
that's it"?

The "supported software" stuff is just the VAN covering their end. They
won't know what generated the data. If your VAN supports FTP then you
should be able to use just about any FTP client you want. Our VAN
(Sterling) provides documentation on how files should be exchanged in
order to avoid contention (IIRC, either move or rename after upload).
Your VAN may offer the same.