EDI FACT

EDIFACT
 EDI standards facilitate electronic data
interchange (EDI) by providing:
 Rules of syntax
 Definition of the data organization
 Editing rules and conventions
 Published public documentation
 EDI standards:
 Allow an ‘open’ system
 Reduce implementation effort
 Provide ‘third-party interfaces’
What is EDIFACT?
 EDIFACT is an acronym for EDI For
Administration, Commerce and Transport. It
coordinates international standardization by
working through the UN/ECE (United
Nations/Economic Commission for Europe). It
provides:
 an international EDI standard
 a set of syntax rules
 data elements, segments and codes
 messages
 EDIFACT is the product of the evolution in
bringing the Proprietary Standards of the U.S.
and Europe together to form a single
international EDI standard.
In order to bring about the evolution of the EDIFACT standard, the UN has
created UN/ECE to coordinate this effort. The organizational structure of the
UN/ECE is made up of the following board
Message Definition
 A Message is a single business document. Each
message is identified by a six character name.
 From the buyer-side these include:
 ORDERS-Purchase Orders
 CUSDEC-Customs Declaration
 IFTMIN-Instruction Message
 REMADV-Remittance Advice
 PAYORD-Payment Order
 Seller-side messages include:
 IFTMAN-Arrival Notice
 CUSRES-Custom Response
 INVOIC-Invoices
Messages are made up of a collection of sequenced
segments within defined areas. Some segments may
be used in more than one area. The segments that can
be used in each area are defined by the EDIFACT
documentation. EDIFACT provides a hierarchical
structure for messages.

Messages begin with the Message Header (UNH)

Segment and end with the Message Trailer (UNT)

Segment. These two segments are the first, and

innermost, level of the three levels of “electronic
envelopes” within EDIFACT. Here is an example of an
Extended Payment Order (PAYEXT) message that
illustrates this structure:
Message Structure:
Segment Tables
 The message structure
is defined in segment
tables. These give the
‘rules’ of the message.
They also show which
segments are used in a
particular message and
the order in which the
segments must appear.
 Here is an example of a
segment table for the
Extended Payment
Order (PAYEXT):
Segment tables specify if a segment
must appear in a message. This is
done using the ‘Requirements
Designator’ field. Each segment in the
table is designated as either
Mandatory (M) or Conditional (C).
Mandatory means that at least one
occurrence of the segment must
appear in the message.
Conditional means a segment may be
used, if needed, but it is not required.
Segment tables also specify how many
times a particular segment may repeat.
This is called the ‘Repetition’ field.
Here is the requirements designators
and repetition in as displayed in the
table for the Extended Payment Order
(PAYEXT) message:
Message Structure:
Segment Groups
 When collections
of segments
repeat as a group,
they are called
segment groups.
Here is an
example of
segment groups
for the Extended
Payment Order
(PAYEXT):
Segment groups may
be ‘nested’. This
means that a segment
group is fully contained
within another
segment group.
Here is an example of
a Nested Segment
Group:

Both Segment Group 7 segments (CUX, DTM) and

Segment Group 8 segments (AJT, MOA, RFF) are within
Segment Group 6 (Document Details).
 Segments
A segment is a collection of logically related data elements in a fixed, defined
sequence. Segments contain:
 a three-character alphanumeric code that identifies the segment. This is called the
segment tag.
 variable length data elements. These can be either simple or composite.

Segments must be separated by a data element separator (data element

delimeter), which is normally + and :, and terminated by a segment
terminator, normally ‘.

All segments are fully documented in the United Nations Trade Data Interchange
Directory (UNTDID). These tables list the segment position, segment tag,
segment name. Segment tables also
 specify if a segment must appear in a message using the requirements
designator M (Mandatory) or C (Conditional), and how many times a
particular segment may repeat (repetition field).

In EDIFACT, there are two kinds of segments:

 Service Segments
 Generic Segments
Service & Generic
Segments
 Service Segments are:
 Envelopes (UNB-UNZ, UNG-UNE, UNH-UNT)
 Delimiter String Advice (UNA)
 Section Separator (UNS)

 Generic Segments are:

 DOC to identify and specify documents
 MOA for monetary amounts
 DTM for dates and times
 NAD for name and address data

 Here is a sample segment:

Segment Terminators and
Delimiters
 The end of each segment is
determined by the Data
Segment Terminator. In
EDIFACT the standard data
segment terminator is ‘.

 Optional or conditional data

elements that are not used
must be accounted for by
their position with the
segment.

 However, optional or
conditional data elements
without data that appear at
the end of a data segment
do not need additional data
element separators to
correctly position the data.
What is Mapping?
 There are almost as many business applications as there are
businesses. In the early days, each business had its own
applications for tracking merchandise, ordering, invoicing,
accounts payable, receivable, and other business needs. We soon
realized that:

1. The computer applications of one business couldn’t talk to

those of another. This meant re-entering all data that was
received.

2. The applications in one department of a business couldn’t talk

to those of another in the same business—order entry couldn’t
talk to invoicing which couldn’t talk to accounts receivable. This
meant re-entering required data multiple times.

 The solution was to standardize the data that was read by a

computer program so that the data could be read by all programs
with that standard.
 Data Elements: Simple and
Composite
 A simple data element contains one piece of information. The
composite data element contains more than one piece of
information, usually containing qualifiers.
 In EDIFACT all mandatory data elements must contain data.
Conditional data elements may or may not contain data,
depending on the requirements of the particular transmission.
 Since data elements must be accounted for by their position in
the segment, if an optional or conditional data element does
not have data, that data element must still be accounted for in
its position within the segment by using the appropriate
number of data element separators to ‘skip over’ the empty
field. For example:
 Data element types:
Numeric
 A numeric segment may contain only digits, a
decimal point and, if negative, a minus sign.

• If the numeric is a given as a decimal, the number

must have a digit before and after the decimal point.
For example: 2.0 is correct (as is 2), however, 2. is
wrong. 0.50 is correct (as is 0.5), .50 is wrong.
Data element types:
Alphabetic
 An Alphabetic segment contains the specified
number of alpha characters, including imbedded
blanks. Leading spaces must be preserved.
Data element types:
Alphanumeric
 Alphanumeric segments contain the specified
number of alphanumeric characters (including
imbedded blanks). Leading spaces must be
preserved.

• Different types of data elements also have specific rules

they must follow. The data element dictionary usually
specifies the codes (Identifiers) by using the words
‘coded’ or ‘qualifier’ in the data element name:
Composite Data Elements:
Qualifier and Value
 In EDIFACT, the composite data element is made
up of 2 or more pieces of data (known as
components) which form a single date unit.
 Typically the first data element is the value, which is
being qualified.
 The second data element is typically the qualifier.
These are typically ID (code values) fields. The qualifier
gives additional definition to the value.
Here is an example of a
composite data element.
This data element is in
regard to financial
institution information. This
is the information provided
in the segment detail:

This is how the Party Qualifier data element (3035) is displayed in the message:

The composite data elements (C078 and C088) are made up of various conditional
components from the segment table. Because they are conditional not all of the data
elements are used. All components are separated by a sub-element qualifier (:).
Message Structure and
Electronic Enveloping
Envelope Architecture
 Levels and Character Sets
 In EDIFACT there are two levels in which messages may
be transmitted. The use of a particular level designates
which character set will be used:
 LEVEL A (UNA): only upper case; only printable characters
 LEVEL B (UNB): upper and lower case; includes non-
printing characters for delimiters
 The UNA Interchange is transmitted as a single string of
9 characters prior to the UNB Interchange segment.
UNA is optional, and if not used, the defaults shown
below apply:
Electronic Enveloping
EDIFACT has two required levels of envelopes:
 Interchange (UNB/UNZ): a set from one sender’s mailbox address to another
sender’s mailbox address
 Message (UNH/UNT): the envelope around one particular message
In addition, there is one optional envelope level: Functional Group
(UNG/UNE). It is used to group like messages together and for sub-
addressing within an organization. In the US ANSI X.12 standards this
group level is where the message format and version are specified. Use of
the UNG/UNE is mandatory to/from North America.
The following diagram illustrates Electronic Enveloping:
The Message Envelope
The innermost envelope level is around each message. It is
defined by the UNH/UNT segments.
The UNH segment has four Data Elements:
 Message Reference Number (M): assigned by the sender’s
computer and is part of the CONTROL mechanism.

Here is an
example of
how the
CONTROL
mechanism in
the UNH
element is
used to
validate
message data:
The Common Access Reference Number is used to identify a series of related
EDIFACT messages. For example, one purchase may involve a message
exchange that requires four messages to accomplish the complete business
transaction as given here:

For Message #1: UNH+2348+ORDERS:D:94B:UN+10381+1:C’

For Message #2: UNH+156009+DESADV:D:94B:UN+10381+2’
For Message #3: UNH+156078+INVOIC:D:94B:UN+10381+3’
For Message #4: UNH+2451+REMADV:D:94B:UN+10381+4:F’
The Functional
Group Envelope
Functional Group Envelope
The second (middle) envelope level is around each functional group. It is
defined by the UNG/UNE
segments. The use of the UNG and UNE envelopes is mandatory for EDI
to/from North America.

This envelope groups like types of messages within a transmission. Here are a
few examples of the data elements in the functional group envelope:
 Functional Group (M)
 Message Identifier (M)
 Date/Time Stamp (M): Relates multiple transactions together.
 Status of the Transfer (C): Sequences a series of related messages.
 Group Reference Number (M)
 Controlling Agency (M)
 Message Version (M)
 Application Password (C)

The UNE segment includes:

 Number of Segments in a Message (M)
 Message Reference Number (M)
The Functional
Group Envelope
Functional Group Sub-Addressing
Functional Group envelopes contain a sub-addressing capability. The
data that is sent to a particular receiver is addressed to the
mailbox address on the UNB.

Many companies want to route a group of data internally, so the UNG

segment has a provision for user defined addresses in the S006
and S007 elements.

Here is a diagram that illustrates the sub-addressing function:

The Interchange
Envelope
The outermost level of the message envelope structure is the interchange
envelope. It is defined by the UNA, UNB and UNZ segements.
This envelope is used to identify data sent from one sender to one receiver:

The UNA segment contains:

 Delimiter String Advice
 Examples of included data elements

The UNB segment contains:

 Date/Time Stamp (M)
 Interchange Control Numbers (M)\
 Password and Application Reference (C)
 Processing Priority Reference (C)
 Acknowledgment Request Indicators (C)
 Communications Agreement ID (C)
 Test Indicators (C)
The UNZ segment includes:

 Interchange Control Numbers (M)

 Counts of Messages or Groups in the Interchange (M)
 The CONTRL Message
It is the responsibility of
the receiver’s computer
to check the syntax and
control numbers of the
transmission and to
build and transmit back
to the sender this
Functional
Acknowledgment.

 The EDIFACT CONTRL

message will provide
this functionality.