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?
EDI (electronic data interchange) works in minutes by using either a software system or an outsourced managed service to automatically send business documents and data between trading partners from computer to computer in EDI standard format, without humans.
Your EDI solution should include the following: A personalized on-boarding approach for your current, distinct supply chain processes. Dedicated project management or Supply Chain Consulting team. Vendor-friendly options that lessen launch time as well as complications and resistance.
The Function of EDIThe buyer creates a purchase order. The buyer prints the purchase order and then sends it to the supplier via the mail, fax, or email. The supplier receives the purchase order and manually enters it into its own order management system (Netsuite, Salesforce, Quickbooks, SAP, etc.)
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:
For customer facing EDI:
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With