Overview of how EDI processing works - edi

I'm new to EDI and have to implement it in a legacy system.
I want to make sure I have the higher level overview correct:
1) Generate EDI file from my system for a given trading partner
2) Probably FTP it to them
3) response is ftp'd to me and I scrape that back into my system
Do I about have the concept down?
I understand most trading partners tweak the standards so there's quite a lot of work there?

You have the workflow down at a VERY high level
As always, the devil is in the details.
Terminology - segments / elements / delimiters
Enveloping the data (ISA / GS / SE segments)
Control numbers on the envelopes
Communication - is it really FTP? clear or secure? what about VAN or
AS2 protocols?
Business Logic - application side, or translation side? Which makes
more sense?
997 Reconciliation
Document Auditing (required? To what level?)
Partner testing protocols
Consider my environment for vendor facing EDI:
850 PO out
997 in to us
855 in to us
997 out from us
856 in to us
997 out from us
810 in to us
997 out from us
For customer facing EDI:
850 in to us
997 out from us
855 out from us
997 in to us
810 out from us
997 in to us
As you can see, a few documents in our life cycle for a transaction.
What documents are you working with? If it is an 837, generating an EDI file is not trivial. Even if it in an 856, you have to deal with hierarchical loops that you have to account for when translating (more so with the 837 though).
Are you planning on writing your own parser / translator? If so, why? Are you going to write your own acknowledgement reconciliation routine? Syntax validation? The best thing is to connect your legacy application with a commercial translator rather then reinvent the 30 year old wheel. Lots of drag / drop mappers that can connect to legacy systems (Delta is probably one of the best on the market, but there are some quality open source alternatives like BOTS) . The X12 standard has a little wiggle room for bastardization. I've seem some crazy implementations though. By and large, more partners conform rather than do what they want. The ones that have wild requirements usually opt for XML, as they have more range in the document structure and aren't limited by standard. If you have 4 partners and 2 are version 4010, and 2 are 5010, then you would have to code (or map) accordingly. There are tools out there to help, but again, the devil is in the details.

a good tutorial can be found at http://www.rdpcrystal.com/what-is-edi/
it shows the basic interaction between EDI parties as well as message information

Related

What is Needed at Receiver side for Receiving EDI documents?

I have Transport Management System. Now one of my carrier want to send me EDI document for Shipment Tracking. that document is EDI 214 (Transportation Carrier Shipment Status Message).Now I'm not clear what I'll need at receiving side. I did some search on google and there are lot's of information regarding EDI and it's workflow. But I'm not clear what should I need at Receiver Side.
Do I need to open any port at my side for receiving document ? Do I need EDI Translator software ? Please Help me as I'm new to EDI.
Thanks so much for any help.
The good news is that receiving X12 is typically easier than generating X12, so your use case is simple relative to bi-directional communication. You are receiving X12 EDI 214s, so it is a single flow in one direction.
The best way to think about this is to ask 1) what is my input I am receiving? and 2) what is the output I want to generate? You are receiving an EDI 214, so presumably you want to generate a JSON/XML/CSV object with just the tracking data that you ERP (system of record) can ingest.
So you need a few things in a typical "EDI architecture"
File transfer protocol (an SFTP is easiest) that you trading partner can connect to and send files to
You need to translate that X12 to JSON (you should check out www.stedi.com/docs/edi-core to do that)
You need to "Map" that file to your output schema (and perhaps convert it to XML/CSV)
You need to post that file to your ERP system
You need to send an EDI 997 (acknowledgement) back to the sender to say "I got it" (think of a read receipt on SMS). Note: some times this is optional
EDI is text, formatted a specific way (aligned to a published standard). To receive files, you have options (but also depends on what the sender supports). Everything from email to 3rd party value added networks, to signed/encrypted HTTP pushes (AS2).
You'll need to agree how you're trading these electronic documents. Once you receive it, then you'll need to parse it. This can be done using 3rd party translators, or you can write it yourself. If the partner requires a 997 (an acknowledgement you received the file), you'll have to generate that. Most 3rd party tools will do that for you. 3rd party tools typically consist of a mapper (drag and drop from source to target) as well as communication mechanisms. Some are cheap, some are expensive. It depends on what you and the sender agree upon to get to the level of effort that you have.
For simplicity sake, you could just set up FileZilla FTP and have the sender place the order there. Then have a process (script, program, etc) to pick up the file, parse it into something your ERP/WMS can understand (XML, JSON, CSV, etc). Again, that assumes the partner supports clear FTP. Some partners demand encryption.

What's the difference between EDI, AS2 and GS1 and how do they work together?

I'm learning about EDI and there are many acronyms and standards that seem to overlap.
What is the difference between EDI (and a EDI translator) and AS2 (which seem to be EDI over HTTP)? Then there is GS1, whith it's own subsets (GS1 EANCOM GS1 XML
GS1 UN/CEFACT XML) and EDIFACT.
Why would one use an EDI translator like BOTS together with an AS2 server ? Are they complementary?
Is there a map, a guide or explanation of how do all theese standars work together in the context of supply chain ? (i.e: a warehouse which ships to client's own warehouses or stores).
Thanks
From Walmart Getting Started with EDI
Implementation Guide ( http://cdn.corporate.walmart.com/5d/8d/897b4bb84a95bb05214bf897cee3/edi-getting-started-guide.pdf )
What is EDI?
a. Simply stated, EDI (Electronic Data Interchange) is the
electronic exchange of business documents between suppliers and retailers.
b. EDI is comprised of two components: translation and communication.
i. During translation, a business document is changed—or “translated”—into
a standardized EDI format.
c. There are various EDI standards (or formats) that a company may use.
i. Please view “How is EDI data formatted?” for more information about the
EDI standards that we support.
d. Once a business document is translated into an EDI format it is communicated—
or electronically sent—to the intended recipient.
e. There are several methods of EDI communications available, but the method
utilized by Walmart and our suppliers is AS2.
What is EDIINT AS2?
a. EDIINT (EDI over the Internet) is a set of communication protocols, introduced by
the IETF (Internet Engineering Task Force) in 1995, used to securely transmit data
over the Internet.
i. Although EDIINT was initially designed to transport EDI data, it may also be
used to transfer non-EDI data.
b. One version of EDIINT is AS2 or Applicability Statement 2.
i. The UCC (Uniform Code Council) has facilitated the development and
interoperability testing of the AS2 standard.
ii. AS2 supports EDI or other data file transmissions over the Internet using
HTTP/HTTPS.
c. AS2 is a specification about how to transport data, not how to validate or process
the content of the data.
d. AS2 specifies the means to connect, deliver and receive data in a secure and
reliable way.
e. AS2 is not an asynchronous or FTP solution; it is an Internet Protocol based solution
that uses standard HTTP/HTTPS communications to transmit data.
f. For more information on EDIINT AS2, or for a list of interoperable-tested AS2
software providers, visit http://www.drummondgroup.com.
Getting Started with EDI – Implementation Guide
Last Modified On: 4/14/2014 Wal-Mart Confidential 5
g. For additional information see the EDIINT FAQ’s within Retail Link™ on the ECommerce/EDI
page.
How is EDI data formatted?
a. The information is formatted using EDI standards.
b. Walmart currently supports:
i. ANSI X12 (American National Standards Institute)
UCS (Uniform Communications Standards)
VICS (Voluntary Inter-industry Commerce Standard)
ii. EDIFACT (Electronic Data Interchange For Administration, Commerce and
T+ransport)
c. Walmart stays within the VICS and UCS guidelines for our major documents within
the United States and Canada. EDIFACT is only used for suppliers outside of the
U+S and Canada and those that will be directly importing merchandise for our
company.

lookin' for a source to understand/learn EDI messages at spanish

Well, does anybody know about an good source to learn about EDI messages? (by example the message 856 (ASN)). I would like a source in spanish language, but english it's acceptable too, something for dummys,blog,book/ebook,documentation,etc... step by step, we're probably starting to work with them in a few months, and we are really lost, we have documentation from our client, but if you know a good source a walk through, where to start, it will be welcome.
I just found the FrameworkEDI www.edidev.co
Any recommendation ? Somebody has worked with it ?
My regards.
I'm confused: you tagged edifact, but you reference an ANSI X12 document (856). Which standard are you working with?
A to Z of EDI:
http://www.amazon.com/EDI-Its-Role-E-Commerce/dp/1882419162/ref=sr_1_2?ie=UTF8&qid=1341941255&sr=8-2&keywords=EDI+A+to+Z
You can usually get manuals on how to translate the data when you select a translator. Perhaps you are looking for a commercial grade translator product that can help. There are hundreds on the market. Try this: http://liaison.com/products/transform/delta
Download EDI Notepad from Liaison (http://liaison.com/products/integrate/edi-notepad)
This tool will help you look at EDI data and understand it.
The EDIFACT wiki might be of some help, since it talks in terms of segments and elements: http://en.wikipedia.org/wiki/EDIFACT
http://ediacademy.com/EdiQuiz.html

Where could one find a 820 & 827 implementation guide and sample data files?

Im looking for a 820 & 827 implementation guide (ASC X12) standard. (not for a particular company).
Im also looking for a sample data file of each. (this could or could not be for a particular company)
Does anyone know where both of these could be located?
Check out this site: http://www.faima.com/edi_4010/tsindex.htm
No sample files, but some nice transaction guidelines.
for specs see: http://www.disa.org/
the x12 specs are not for free.
You can purchase the specifications from http://www.disa.org. There is a cost associated with them, however. It will most likely be < $1000, and you'll get all of the messages. However, you do need to know the version, which will be a number like 004010 or 006020.
The specifications do not come with a lot of examples. But examples can be found all over the internet. For example, if you Google 820 004010 example (the message, the version, and "example"), you get quite a few links, one of which leads you to a nice little sample page like https://www.emedny.org/hipaa/emedny_transactions/820/820_sample_files.aspx and another to http://www.cokeconsolidatededi.com/EDISetups/Forms/CCBCC%20Inbound%20820%20Payments%20004010%20Ex.pdf (those are just the first two that came up for me).

Still a future (and a present) for 6502, VIC and SID?

As a derivative of my previous curiosity question I had a followup curiosity. Is there a future and/or an application for the 6502, the VIC and the SID chips ? I know they are still produced, and used. For example, I remember the 6502 makes a perfect controller chip for small appliances. the SID for sure is still present in some "retro" sound synthesizer, although my guess is that it's just emulated. What about the VIC ?
Community wiki question as there's no correct answer.
I would look at 6502.org, including its list of commercial support and list of projects.
For example, I remember the 6502 makes a perfect controller chip for small appliances.
I dunno about the VIC and SID chips (special purpose video / audio chips are different than a CPU), but I don't see any reason to use a 6502. There are tons of cheap low-power microcontrollers (e.g. Microchip PIC, Atmel, TI MSP430, etc) that are readily available, have more CPU horsepower than a 6502, have useful peripherals (ADCs, UARTs, built-in oscillator, etc), and have real-time debugging features. Why use a 30-year-old microcontroller?
I would think their future is limited. I don't know what kind of quantities are still being produced but you have to figure even the 486 is probably being produced in far greater quantities than the 6502. So even though the 486 might be overkill for some applications its availability determines its price thus making it more attractive to device manufacturers.
Then, as you say, the functionality of the 6502, VIC, and SID chips are easily emulated these days--even in software. So that might drive the demand for those chips down since its probably cheaper to emulate.
Cost means it still sells millions of units each year. 6502 is cheapest 8 bit CPU; doesn't have 6 month lead time like Stm8, braindead memory model like pic or 8051 or overpriced like avr, pic, msp430. To go cheaper you have to go 4 bit which is very limited. Admitedly arm chips like stm32f030 are only a few cents more but there is a company called Walmart that asks for products to be as cheap as possible so manufacturers cut cents of costs.

Resources