Just simple FTP, typically secure though.
-----Original Message-----
From: Scott Klement [
mailto:midrange-l@xxxxxxxxxxxxxxxx]
Sent: Thursday, July 12, 2007 1:20 PM
To: Midrange Systems Technical Discussion
Subject: Re: EDI and Inovis from Library Data
hi Keith,
They probably get their fee most of the time as a lot of shops won't
want the hassle of changing software. You might consider keeping
your old 270 just for running Trustedlink. It could be the easiest
and cheapest solution.
That'll work as a temporary solution. It'll buy us time to switch to
another alternative.
However, it's not a viable long term solution. The reason we're
replacing this machine is that it's more than 6 years old, and it's a
little worn out. This is a fact in the computer industry: Computer
hardware isn't designed to run forever. (Even the System i!) It needs
to be replaced from time to time.
All we really want (with this particular project, anyway) is to put our
existing stuff on newer hardware because the old hardware is worn out.
The only reason that this machine is faster than the old one is that
technology has changed, and this is now the slowest/smallest machine
that IBM sells.
Yes, generating EDI data can be that simple. Processing (parsing)
incoming EDI data is more work.
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.
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.
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.
Yes, VANs will likely require contracts. I assume you are using
Inovis. Even if you drop TrustedLink, you should be able to continue
using them for their VAN service. Other VANs to consider are
Sterling Commerce and GXS.
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"?
midrange.com
