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.