Parsing the data is only part of the challenge. Another part is collecting
the data.
The most common data collection approach is to use an EDI service provider
as the collection point: In practice EDI partners send their data to an EDI
service provider who "sorts" the EDI data by trading partner then sends the
data to the trading partners' individual EDI service provider. You pick up
(download) all your EDI data from your service provider, parse it into your
transaction formats, process the transactions and send your outbound EDI
data (order acknowledgements, advance shipping notices, payments, invoices,
etc.) to your EDI service provider who sorts and distributes the data.
Some EDI service providers partner with EDI parsing package vendors, you pay
an additional fee to use the vendor's package. Other EDI service providers
include an EDI parsing package license in their monthly service fee.
You'll want to use the EDI parsing package approach because parsing is not a
one time event. The transaction standards are very flexible, consequently
each trading partner can and will send you a slightly different format for
the same transaction. The differences are at the field level - one trading
partner will send a field, another won't. In a roll-your-own situation you
have to accommodate each of those variants, parsing packages handle the
greater majority of the transaction variants.
The other parsing challenge is trading partners don't all use the same
transactions. For example, one may send invoices and expect payment
notification via EDI, another may send the invoice but have no expectations
when it comes to payments. These different EDI usages will impact your
parsing support requirements.
Last issue: if your current systems are interactive based, getting them to
accept batch (EDI) data is no small challenge. One approached used by small
companies is to have a third party create hard copy documents from the EDI
transactions. They then email or fax these documents to you for processing.
If you EDI trading partnerships are limited and the transactions they are
sending/expecting are also limited this approach may be a viable option.
Incidentally, I have no connection or affiliation with any EDI service
provider or Parsing package vendor. My comments are based on my experience
in a past life as an EDI implementor.
Roy Luce
Direct - 847-910-0884
833-937-8368
Email - lwl@xxxxxxxxxxxxx
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Art
Tostaine, Jr.
Sent: Tuesday, May 31, 2022 9:21 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Parse EDI?
I've done it. I created a data structure for each line type, ST, SE, N1, N2,
etc.
Then I just wrote a parser to look for the segment terminator and put the
data into those fields. I pass the data structure name and the data. I
don't have any code to share though sorry.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
As an Amazon Associate we earn from qualifying purchases.