EDIFACT Explained: Message Standards and Transaction Sets
Electronic Data Interchange (EDI) should be invisible to the business operations it facilitates. But this is far from true if you’re tasked with building and implementing an EDI system, or enabling your EDI architecture to translate messages from another EDI standard.
Although only one of many EDI standards, EDIFACT stands out as a comprehensive EDI methodology used by organisations across the globe.1
Here, we aim to provide practical guidance about the EDIFACT Transaction Sets (T-sets), syntax, and message construction to help you understand how to translate messages into EDIFACT and coordinate with supply chain partners.
What is EDIFACT?
EDIFACT, or ‘Electronic Data Interchange For Administration, Commerce, and Transport’, is a robust set of standards developed by the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT).
In essence, EDIFACT works by standardising the electronic data interchange between business partners. Created to serve any business transaction in any industry, it encompasses a wide range of document types (e.g. invoices, purchase orders, delivery notes, etc.), and has even spawned a number of industry-specific ‘subsets’ like EANCOM, which was created for the retail sector.
EDIFACT, like all EDI standards, was designed to facilitate the global and multi-industry exchange of electronic business documents in order to streamline the complexities inherent in global trade. However, this only works if you formulate your messages using the right codes, T-sets, and syntax.
Components of an EDIFACT message
An EDIFACT message is a complete, structured data sequence representing a single business transaction, such as an order, an invoice or a shipping notice. Each message begins with a ‘message header’ (UNH) segment and ends with a ‘message trailer’ (UNT) segment. For example, an invoice message (INVOIC) includes all the details related to invoicing a shipment or a service.
Each EDIFACT message is composed of logically related data elements assembled in a specific order. The building blocks of these data elements are codes, segments and T-sets, which are distinct but related concepts:
- EDIFACT Codes: Business documents are converted from internal formats (such as XML or CSV) into the standardised formats used in EDI, such as EDIFACT or X12. This transformation ensures that the data can be accurately interpreted and understood by the recipient’s systems.
- EDIFACT Segments: A collection of related data elements that together convey a distinct piece of information within a message. Each segment begins with a unique three-letter code that indicates the type of information contained in the segment.
- EDIFACT T-sets (Transaction Sets): A standardised collection of related data segments representing a specific type of business transaction. Each T-set is identified by a unique EDIFACT code.
Confusingly, a T-set can be considered a type of message. For example, the Transaction Set ‘ORDERS’ corresponds to the Purchase Order message type. However, the simplest way to understand this is that an EDIFACT message is the complete structured data representation of a business transaction, and a Transaction Set (T-set) is the type of business transaction that the message represents.
EDIFACT code list
EDIFACT has a more comprehensive set of codes than most EDI standards, resulting in more possible segments and T-sets. Understanding these codes simplifies the usage of the system and aids in its successful application. The most common examples of EDIFACT codes include:
|IFTMIN||Instructions for Transport|
|IFTMBF||Transport Booking Request|
|IFTMBC||Transport Booking Confirmation|
|MSCONS||Metered Services Consumption Report|
|UTILMD||Utilities Master Data|
|ORDCHG||Purchase Order Change Request|
|SLSRPT||Outgoing Sales Report|
|ORDRSP||Purchase Order Response|
How EDIFACT messages are constructed
The syntax rules of the EDIFACT standard are vital for constructing and interpreting EDIFACT messages by ensuring each message’s coherence and uniformity. Let’s deep-dive into those details.
Usable Characters: The language
EDIFACT has a specific set of characters that can be used within messages. These include:
- Alphabetic characters: A to Z (uppercase only)
- Numeric characters: 0 to 9
- Special characters: A set of special characters, such as . , – ( ) / = + : ? ‘ and spaces
These provide a range of options to construct all types of commercial, administrative, and transport messages.
Data Elements: The building blocks
Data Elements are the fundamental units in an EDIFACT message, encapsulating individual pieces of information analogous to words in a language. They can be either simple or composite and align within segments following a pre-defined sequence.
Key points about Data Elements:
- Simple Data Elements contain a single piece of data. For example, a specific price or date.
- Composite Data Elements hold multiple related pieces of data, or sub-elements. For instance, a composite data element could encapsulate a complete address.
- Each Data Element has a unique number as defined in the UNTDED (United Nations Trade Data Element Directory).2
Segments: The framework of EDIFACT
Segments function as containers for logically related data elements, akin to sentences in a language that convey a complete idea. They outline specific information, such as customer details or product information.
Key points about Segments:
- Standard segments like the ‘NAD’ and ‘DTM’ have specific purposes, providing name and address details or specifying a date or time.
- The segments in a message follow a definite sequence as defined in the ‘message structure diagram’ — the framework for each EDIFACT message type.
- A segment begins with a Segment tag, which is a three-letter code indicating the type of data contained in the segment.
Below is a table listing some common EDIFACT segments:
|Segment Code||Segment Name||Description|
|UNH||Message Header||Starts a message and assigns it a unique reference number.|
|BGM||Beginning of Message||Identifies the message type and function.|
|DTM||Date/Time/Period||Provides date and time information.|
|NAD||Name & Address||Specifies name and address details of parties involved.|
|LIN||Line Item||Identifies line items within a transaction.|
|UNT||Message Trailer||Marks the end of the message and counts the total number of segments.|
Each data element within the LIN segment holds a piece of information related to an item in an order, e.g. its identifier, the action required, item number, and any sub-line information.
T-sets: Groups of segments
EDIFACT segments group together to create T-sets, which represent a specific business transaction or unit of communication. For example, a T-set can represent a purchase order, invoice or logistics shipping instruction.
Key points about EDIFACT T-sets:
- Each T-set adheres to a standardised structure, prescribed by the EDIFACT standard. This ensures that irrespective of the parties involved, the T-set is consistently interpreted and processed.
- Every T-set has a unique EDIFACT code, ensuring that it can be universally recognised. For example, the code ‘ORDERS’ represents a Purchase Order T-set, and ‘INVOIC’ signifies an Invoice T-set.
- A T-set consists of multiple segments, each carrying a distinct piece of information relevant to the transaction. Segments in a T-set are organised in a specific, predefined order.
To illustrate this, here is an example of the LIN segment used to construct a T-set representing a line item in a purchase order, and a breakdown of data elements that might be included.
|Segment (T-Set)||Data Element||Description||Sample Value|
|LIN||1082||Line item identifier||1|
|C212||Item Number Identification|
|7143||Item number type, coded||IN|
Message: The complete EDIFACT transaction
A Message in the EDIFACT system is akin to a paragraph or a complete letter. It’s the assembled form of all related segments required to represent a business transaction.
Key points about Messages:
- Each message starts with a ‘message header’ (UNH) segment and ends with a ‘message trailer’ (UNT) segment, forming a self-contained data exchange unit.
- The messages depict specific transactions like invoices, purchase orders, or transport instructions.
Example of a Message:
- UNH — Message Header
- BGM — Beginning of Message (identifies the type and function of the message)
- DTM — Date/Time/Period (provides date and time information related to the transaction)
- NAD — Name and Address (provides name and address information related to parties involved in the transaction)
- LIN — Line Item (defines specific line items within the transaction)
- UNT — Message Trailer
To provide more detail, here are all the components that might go into an EDIFACT message representing a line item purchase order.
|Segment Code||Data Element||Description|
|ORDERS:D:96A:UN||Identifies the message type as a purchase order|
|BGM||220||Identifies the document/message name and function|
|BKOD99||Document/message identifier (e.g., order number)|
|DATE CODE||Date or time or period function code qualifier|
|DATE||Date or time or period text|
|NAD||C082||Party Identification Details|
|PARTY CODE||Party identifier|
|PARTY NAME||Code identifying a data element|
|LIN||1||Line item identifier|
|C212||Item Number Identification|
|7143||Item number type, coded|
When formulated as a real EDI message, this information would look like:
Although nearly incomprehensible for a human, this provides a universally intelligible representation of a business transaction optimised for electronic interchange.
Transmission Files: Groups of messages
Transmission files represent batches of messages. They are defined by the ‘interchange header’ (UNB) and ‘interchange trailer’ (UNZ) segments. A transmission file can contain one or more message groups or individual messages.
How an EDI Partner Can Help
Although the EDIFACT system is comprehensive and powerful, navigating its intricacies takes time, particularly for small to medium-sized enterprises operating within complex supply chains using multiple EDI standards. Translating EDI formats like ASNI or VDA into EDIFACT, or vice versa, presents a significant challenge requiring the complex use of EDI mapping software.
EDI via VAN (Value-Added Network) is a private network provider that hosts a secure platform for exchanging EDI or other electronic business documents amongst trading partners. VANs can handle any EDI standards (like X12, EDIFACT), and they ensure the safe and reliable transmission of data.
At Data Interchange, we provide flexible EDI services that make it simple for businesses who rely on EDI to do so without having to constantly re-configure their internal systems. Bridge the gap between the complexities of the EDIFACT format and the specific needs of your business to meet any supply chain partner’s EDI requirements with confidence.