What Is EDI “Enveloping” All About?

The primary reasons for EDI “enveloping” are to manage EDI Interchange routing, and to enable your EDI system know how to process inbound transmissions (this also applies to the enveloping data you send to your trading partners). Your EDI software needs to know where a transaction (message) begins and ends. It also needs to determine which trading partner transmitted the data and what type of transactions were received, for example, Purchase Orders or Invoices.

When transmitting EDI data to trading partners, it is necessary to “wrap” the individual transactions using “envelopes”. There are various envelope types and each representing different levels.  Each “envelope” has one beginning and one ending segment that carries certain control information.  Generally, the EDI envelope structure is comprised of three levels (although in some instances only two are used).  The first (inner-most and lowest level) envelope wraps a single transaction, for example, a single Purchase Order or Invoice. The second (middle) envelope level wraps a group of “like” transaction types, for example, all Purchase Orders or Invoices (for the same partner). The third (outer-most) envelope is one interchange and wraps all transactions and groups for one trading partner, and carries the necessary routing information to ensure the interchange arrives successfully at its destination.

In the ANSI X12 standards, the first/inner-most (transaction) level of enveloping uses the ST (Transaction Set Header) and SE (Transaction Set Trailer) segments to identify the beginning and ending of each transaction.  Each individual transaction will be enclosed (wrapped) inside these two segments.

In the ANSI X12 standards, the second/middle (group) level of enveloping uses the GS (Functional Group Header) and GE (Functional Group Trailer) segments to identify the beginning and end of each group of “same” transaction types.  For example, in one transmission you may send multiple types of transactions, such as Invoices or Ship Notices to one trading partner. Each group of transaction types will be enclosed (wrapped) inside these two segments.

In the ANSI X12 standards, the third/outer-most (interchange) level of enveloping uses the ISA (Interchange Control Header) and the IEA (Interchange Control Trailer) segments to identify the sender and receiver (similar to addressing a physical envelope).  This level encompasses all transactions and groups for each trading partner.  The ISA is important as it also identifies critical control information such as the date, time, interchange tracking number, and others.  One transmission would consist of one or more interchanges (representing one or more trading partners, and each having one or more groups of transactions).

There is one additional level that does not include any particular envelope structures, but is a level of EDI separation critical for EDI transmission: the “communications” (connection) level.  When communicating directly with a trading partner, this is not an issue.  However, when using a Value Added Network (VAN) it is common for trading partners to be on a different VAN from your organization.  Prior to transmission, data is typically packaged to yet another (fourth) level to separate trading partners by destination.  For this, connections would be grouped together and sent in one transmission.  This is more efficient than sending each trading partner’s data to the VAN in a different transmission (*Note: VANs will commonly perform VAN “interconnects” making it possible to use a single VAN although your partners may be using different VANs – in this case the VAN will use the ISA (Interchange Envelope) to ensure VAN to VAN routing occurs.)

References above were specific to the ANSI X12 standard but other standards exist and have slightly different enveloping requirements.  Although the purpose and levels don’t change, the envelope segments do.  Another common standard is UN/EDIFACT.  The table below shows the cross-reference between ANSI X12 and UN/EDIFACT enveloping segments:

(*Note – In the UN/EDIFACT standard the UNA (Service String Advice) segment is not considered envelope information although, if used, it must precede the UNB to notify the receiver that standard delimiters are not used.  Also, many implementations of UN/EDIFACT will omit the group level UNG/UNE due to redundancy.)

One thought on “What Is EDI “Enveloping” All About?

  1. Jean Reksodiputro

    Quick question guys.
    We’re developing a new Message Class for a Trading Partner name: “TPA” (Msg Type 810)
    The problem here is that we already have one in production, with TP name “TPA”, with message class = “MC01”.
    How can we move our changes to Prod, by keeping TP Name = “TPA” but wih different mssage class = “MC02”?
    Will it override the “MC01″? We want to use Trading Partner name with possibility of using 2 Msg Class=”MC01” and “MC02” in prod. Is it possible?

    Thanks a lot!!

Leave a Reply

Your email address will not be published. Required fields are marked *