Thanks George, very insightful. Norm On Fri, Jun 12, 2009 at 9:50 AM, George Gallen <[email protected]>wrote:
> Our EDI usage is fairly simple (850,855 and 810) right now. We are using > a provider, where we receive and transmit XML files, > > who then converts them into edi and drops them on the network. > > > > Whenever a new 850 comes in, the provider sends an email. > > we are running UV on unix, so the email is aliased/forwarded (appended) to > a file. > > In UV we have a process that monitors that file for changes. > > > > This triggers a program that then goes out to their ftp site, and reads any > new XML files. > > The XML is then converted into an internal format (From the 850). This > record then becomes the master record for that > > edi transaction. as it passes through our edi system, it's updated. Once > everything is approved, an internal 855 format > > is created, as well as an internal 810 format is created when the order > is processed/invoiced. > > > > I have a file of providers, which has in which format the 850 will be in, > the 855 and 810 needs to be (EDI or XML), > > depending on that value, I have subroutines that convert to/from the > internal format to either EDI or XML, and > > then if 855/810, the file is then uploaded to the providers ftp site. also > in the file, is the ftp site name, password > > any special ftp commands that have to be executed, and the drop folder > name. This way if there is more than one > > trading partner that needs to use different providers, the program will > automatically adjust to the format and/or > > the ftp site. > > > > The base programs are consistent, since they all work off the internal > format, then depending on the provider or > > the format, will run subroutines specific to each. This way if we add a new > provider or trading partner that needs > > something unique, it's just a matter of creating a new subroutine just for > them, and the base edi works the same. > > > > I'm fairly new to edi, and this was my first attempt at a "system" , my > next add-on will be to check the site every > > hour and download any 997's that have come in, and update the edi record > with that information as well. Since > > we are starting this from the ground up, it was fairly easy to integrate it > into our order entry, shipping fulfillment > > and accounts receivable systems. > > > > One thing I just don't understand….Why is it so freakin expensive to > transmit EDI transactions? in today's age > > of the internet and transmission speeds. > > > > If RECORD contains the EDI-formatted-data…. > > CONVERT "~" TO CHAR(254) IN RECORD > > CONVERT "*" TO CHAR(253) IN RECORD > > So if RECORD<1,1>="ST" then RECORD<1,2>="ST01", RECORD<1,3>="ST02" …etc > > > > you now have a mulitvalued record of the edidata (to some extent, doesn't > format > > loops). > > > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Norman Bauer > *Sent:* Friday, June 12, 2009 9:25 AM > *To:* U2 Users List > *Subject:* [U2] How do you do EDI? > > > > We have a very painful, labor intensive way that we do EDI. >From the way > we create the X12 documents to our users inputing information to be sent in > an EDI message. I would like to start evaluating alternative methods to our > current practices. All suggestions welcome. > > > > Norm > > _______________________________________________ > U2-Users mailing list > [email protected] > http://listserver.u2ug.org/mailman/listinfo/u2-users > >
_______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
