Syntax Standards

The middle level in our three layer EDI model is the Syntax Standard to be used.



Taking the analogy of a telephone call, it is no use if the call is connected but the remote party does not speak the same language as the caller; a few minutes will be lost whilst each side tries to understand the other but no meaningful information may be exchanged.

To avoid this problem, three main syntax standards are used for EDI. These are the American ANSI X12 standard, the European EDIFACT standard and an older European standard still very popular in some sectors such as the retail industry, UNGTDI (United Nations Guidelines for Trade Data Interchange). There is also the VDA syntax standard, used in Germany. Although not strictly EDI, VDA messages have been included under the EDI umbrella.

With the exception of VDA, no matter what standard is used, the same EDI terms and concepts apply. Let us now look at these terms and what they mean in more detail.

An EDI “Message” may be split up into a number of logical units. The message is itself a single document such as an invoice or an order, and is made up of a number of “Segments”. Each segment contains complete information about a part of the document. For example two segments that will be required in an invoice message are the buyer’s and seller’s details. Segments can themselves be split down into “Data Elements”. Data elements hold the actual information. Simple data elements hold only one item of information, such as a name or a value. Composite data elements hold one or more “Sub-Elements” of closely associated information such as the lines of an address.

EDI messages between two trading partners may be grouped together into an “interchange”. The interchange may contain messages of varying types, the only common factor being the sending and receiving parties. All EDI files must contain at least one interchange; this ensures that the interchange can be routed to the correct destination. Messages of the same type can be held together in a “group”. The functional group is not a very widely used vehicle, most partners considering that as the interchange is the main routing method and may contain many messages, then the group is somewhat superfluous. Different standards call the group different names. The group itself is an EDIFACT term, UNGTDI standards know it as a “batch” and ANSI X12 standards as a “document”. ANSI X12 also calls the message a “transaction”.

Service Segments

Interchanges, groups and messages are identified in an EDI file by special segments known as service segments. Service segments contain the information necessary to route the interchange towards its final destination, to identify the contents of the interchange, its date and time of production, standards used and much more. Remember that the interchange may be passing through several different routing agencies, just as a letter is passed to and through the post office before reaching its final destination. EDI is not always a point-to-point matter. The service segments act in the same way as the envelope and enclosed document headings used in paper correspondence.

Service segments enclose a block of segments that they are defining. In other words there will be service segments both at the start and end of each interchange, group and message. The service segment’s names are different for each syntax standard. The following is a list of service segment types and their equivalents for each of the common standards.

 

Segment Delineation Characters

Obviously some method is needed to indicate the end of one segment and the start of the next, and likewise for the end of one data element and the start of the next. The manner of achieving this is by segment delineation characters. These characters are used to split the EDI file up into its constituent parts. Each syntax has its own default delimiters, i.e. those that are used if no others are specified, but in most cases these can be overridden by special means if necessary.

The default segment delineation characters that are used for the main three EDI syntaxes that we are considering are given in the following table.
 

Streams of information

The use of service segments not only allows routing of EDI data between trading partners but also allows the concept of regular data “streams” to be implemented, allowing the trapping of missing data and regular activities to be performed on EDI interchanges.

Interchanges from each trading partner may be identified by the contents of the interchange control segment. A sequence number in the segment allows the receiver to check that this interchange is greater than the last one, avoiding possible duplication, and also allows for missing sequences and hence missing interchanges to be identified.

In real life these cases may be more complex. Routing via a VAN may cause some interchanges to be received out of sequence. This scenario would be similar to the post arriving at your premises. The post is dumped in an unsequenced pile in the mailbox and the letters are then opened in any sequence. There is no guarantee that the sequence of documents processed or “opened” is correct.

To solve this problem the concept of a sequence “window” is used. So long as the increase in the application reference number is not greater than the window size, then all is well and the sequence may then be checked for missing numbers at a later time when all the documents are expected to have been received.