Jump to content

EDIFACT: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Importing Wikidata short description: "Technical standard"
 
(13 intermediate revisions by 13 users not shown)
Line 1: Line 1:
{{Short description|Technical standard}}
{{refimprove|date=April 2015}}
{{more citations needed|date=April 2015}}
'''United Nations/Electronic Data Interchange for Administration, Commerce and Transport''' ('''UN/EDIFACT''') is the international [[Electronic Data Interchange|EDI]] [[standardization|standard]] developed under the [[United Nations]].
'''United Nations/Electronic Data Interchange for Administration, Commerce and Transport''' ('''UN/EDIFACT''') is an international standard for [[electronic data interchange]] (EDI) developed for the [[United Nations]] and approved and published by [[UNECE]], the UN Economic Commission for Europe.<ref>UNECE, [https://www.unece.org/cefact/edifact/welcome.html Introducing UN/EDIFACT], accessed 27 September 2020</ref>


In 1987<ref>https://www.unece.org/trade/untdid/texts/old/d423.htm#p1</ref>, following the convergence of the UN and US/ANSI syntax proposals, the UN/EDIFACT Syntax Rules were approved as the ISO standard ISO 9735 by the [[International Organization for Standardization]].
In 1987, following the convergence of the UN and US/ANSI syntax proposals, the UN/EDIFACT Syntax Rules were approved as the ISO standard ISO 9735 by the [[International Organization for Standardization]].<ref>[https://www.unece.org/trade/untdid/texts/old/d423.htm#p1 UN/EDIFACT Syntax Implementation Guidelines], accessed 27 September 2020</ref>


The EDIFACT standard provides:
The EDIFACT standard provides:
Line 13: Line 14:
== Example ==
== Example ==
See below for an example of an EDIFACT message used to answer a flight ticket (FRA-JFK-MIA) availability request:
See below for an example of an EDIFACT message used to answer a flight ticket (FRA-JFK-MIA) availability request:
{{sxhl|2=unixconfig|
UNA:+.? '
UNA:+.? '
UNB+IATB:1+6XPPC:ZZ+LHPPC:ZZ+940101:0950+1'
UNB+IATB:1+6XPPC:ZZ+LHPPC:ZZ+940101:0950+1'
Line 29: Line 31:
UNT+13+1'
UNT+13+1'
UNZ+1+1'
UNZ+1+1'
}}

The UNA segment is optional. If present, it specifies the special characters that are to be used to interpret the remainder of the message. There are six characters following <code>UNA</code> in this order:
The UNA segment is optional. If present, it specifies the special characters that are to be used to interpret the remainder of the message. There are six characters following <code>UNA</code> in this order:
* component data element separator (: in this sample)
* component data element separator ({{char|:}} in this sample)
* data element separator (+ in this sample)
* data element separator ({{char|+}} in this sample)
* decimal mark (. in this sample)
* decimal mark ({{char|.}} in this sample)
* release character (? in this sample)
* release character ({{char|?}} in this sample)
* reserved, must be a space
* reserved, must be a space
* segment terminator (' in this sample)
* segment terminator ({{char|'}} in this sample)


With the exception of the decimal mark (see below), the special characters in the sample UNA segment above are also the default values.
With the exception of the decimal mark (see below), the special characters in the sample UNA segment above are also the default values.
Line 42: Line 44:
The component data element separator and data element separator are the "first level" and "second level" separators of data elements within a message segment. Referring to them as + and : for brevity, the + separates top-level or composite data elements, and : separates second-level data elements nested within composite data elements. Trailing empty (or null) data elements and their leading separators are omitted to reduce message size.
The component data element separator and data element separator are the "first level" and "second level" separators of data elements within a message segment. Referring to them as + and : for brevity, the + separates top-level or composite data elements, and : separates second-level data elements nested within composite data elements. Trailing empty (or null) data elements and their leading separators are omitted to reduce message size.


The decimal mark is used to separate the integer from the fractional part of non-integer numbers. The optional nature of the UNA segment and the initial choice of the comma (",") as the default decimal mark provide a source of common confusion. Versions 1 through 3 of the ISO 9735 syntax rules specify the comma as the default; version 4 states that the decimal mark position in the UNA segment is to be ignored and that the comma and the dot (".") may be used indifferently in numeric data values. The UNB segment indicates which version of the syntax rules is in effect.<ref>''ISO 9735: 1988'' and ''ISO 9735-1:2002''</ref>
The decimal mark is used to separate the integer from the fractional part of non-integer numbers. The optional nature of the UNA segment and the initial choice of the comma ("{{char|,}}") as the default decimal mark provide a source of common confusion. Versions 1 through 3 of the ISO 9735 syntax rules specify the comma as the default; version 4 states that the decimal mark position in the UNA segment is to be ignored and that the comma and the dot ("{{char|.}}") may be used indifferently in numeric data values. The UNB segment indicates which version of the syntax rules is in effect.<ref>''ISO 9735: 1988'' and ''ISO 9735-1:2002''</ref>


Release character (analogous to the \ in [[regular expression]]s) is used as a prefix to remove special meaning from the separator, segment termination, and release characters when they are used as plain text.
Release character (analogous to the {{char|\}} in [[regular expression]]s) is used as a prefix to remove special meaning from the separator, segment termination, and release characters when they are used as plain text ("Escape character" is the equivalent North American term).


Segment terminator indicates the end of a message segment.
Segment terminator indicates the end of a message segment.
Line 50: Line 52:
Note: The line breaks after each segment in this example have been added for readability. There are typically no line breaks in EDI data.
Note: The line breaks after each segment in this example have been added for readability. There are typically no line breaks in EDI data.


<code>UNH+1+PAORES:93:1:IA'</code>- This is the message header segment which is required at the start of every message. This code specifies that the message name and version is PAORES 93 revision 1 and it was defined by the organisation IA (IATA).
{{code|UNH+1+PAORES:93:1:IA'|unixconfig}}- This is the message header segment which is required at the start of every message. This code specifies that the message name and version is PAORES 93 revision 1 and it was defined by the organisation IA (IATA).


<code>IFT+3+NO MORE FLIGHTS'</code> - This is an "Interactive Free Text" segment containing the text "NO MORE FLIGHTS".
<code>IFT+3+NO MORE FLIGHTS'</code> - This is an "Interactive Free Text" segment containing the text "NO MORE FLIGHTS".
Line 57: Line 59:


== Structure ==
== Structure ==
EDIFACT has a hierarchical structure where the top level is referred to as an ''interchange'', and lower levels contain multiple ''messages'' which consist of ''segments'', which in turn consist of ''composites''. The final iteration is an ''element'' which is derived from the United Nations Trade Data Element Directory (UNTDED); these are normalised throughout the EDIFACT standard.
EDIFACT has a hierarchical structure where the top level is referred to as an ''interchange'', and lower levels contain multiple ''messages'' which consist of ''segments'', which in turn consist of ''composites''. The final iteration is an ''element'' which is derived from the United Nations Trade Data Element Directory (UNTDED); these are normalized throughout the EDIFACT standard.


A group or segment can be mandatory (M) or conditional (C) and can be specified to repeat.
A group or segment can be mandatory (M) or conditional (C) and can be specified to repeat.
Line 83: Line 85:


==References==
==References==
{{reflist}}
{{Reflist}}


==External links==
==External links==
* [https://www.unece.org/cefact/edifact/welcome.html UN/EDIFACT Main Page] - Welcome and News Page
* [https://unece.org/trade/uncefact/introducing-unedifact Introducing UN/EDIFACT]
** [http://www.unece.org/tradewelcome/areas-of-work/un-centre-for-trade-facilitation-and-e-business-uncefact/outputs/standards/unedifact/directories/2010-2012.html 2010-2012 - Trade - UNECE] - UN/EDIFACT Directories 2010-2012 (with syntax explanation/reference - latest version D12.A)
** [https://unece.org/uncefact/unedifact/2011-2020 2011-2020 - Trade - UNECE] - UN/EDIFACT Directories 2011–2020 (with syntax explanation/reference - latest version D.20B)
* [http://www.unece.org/trade/untdid/texts/unredi.htm UN/EDIFACT Rules] - Covers syntax, implementation, and message design.
** [https://unece.org/uncefact/unedifact/2021-2022 2021-Present - Trade - UNECE] - UN/EDIFACT Directories 2021–Present (with syntax explanation/reference - latest version D.22B)
* [https://unece.org/trade/uncefact/unedifact-introduction-and-rules Introduction and Rules] - Covers syntax, implementation, and message design.
** [http://www.unece.org/trade/untdid/texts/d422_d.htm UN/EDIFACT Syntax (ISO 9735, latest version)] - Explains EDIFACT syntax in detail.
** [https://unece.org/trade/uncefact/unedifact/part-4-chapter-22-syntax-rules UN/EDIFACT Syntax (ISO 9735, latest version)] - Explains EDIFACT syntax in detail.
* [https://github.com/DFDLSchemas/EDIFACT DFDL schemas for UN/EDIFACT] Data Format Description Language schemas for parsing and writing UN/EDIFACT interchanges
* [https://github.com/DFDLSchemas/EDIFACT DFDL schemas for UN/EDIFACT] Data Format Description Language schemas for parsing and writing UN/EDIFACT interchanges
* [https://www.edination.com/edi-models-edifact.html UN/EDIFACT JSON Models] Interactive UN/EDIFACT JSON models for parsing, generating, and validating UN/EDIFACT interchanges


{{Authority control}}
{{Data exchange}}


[[Category:Electronic data interchange]]
[[Category:Electronic data interchange]]

Latest revision as of 09:57, 24 December 2023

United Nations/Electronic Data Interchange for Administration, Commerce and Transport (UN/EDIFACT) is an international standard for electronic data interchange (EDI) developed for the United Nations and approved and published by UNECE, the UN Economic Commission for Europe.[1]

In 1987, following the convergence of the UN and US/ANSI syntax proposals, the UN/EDIFACT Syntax Rules were approved as the ISO standard ISO 9735 by the International Organization for Standardization.[2]

The EDIFACT standard provides:

  • a set of syntax rules to structure data
  • an interactive exchange protocol (I-EDI)
  • standard messages which allow multi-country and multi-industry exchange

The work of maintenance and further development of this standard is done through the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) under the UN Economic Commission for Europe, in the Finance Domain working group UN CEFACT TBG5.

Example

[edit]

See below for an example of an EDIFACT message used to answer a flight ticket (FRA-JFK-MIA) availability request:

 UNA:+.? '
 UNB+IATB:1+6XPPC:ZZ+LHPPC:ZZ+940101:0950+1'
 UNH+1+PAORES:93:1:IA'
 MSG+1:45'
 IFT+3+XYZCOMPANY AVAILABILITY'
 ERC+A7V:1:AMD'
 IFT+3+NO MORE FLIGHTS'
 ODI'
 TVL+240493:1000::1220+FRA+JFK+DL+400+C'
 PDI++C:3+Y::3+F::1'
 APD+74C:0:::6++++++6X'
 TVL+240493:1740::2030+JFK+MIA+DL+081+C'
 PDI++C:4'
 APD+EM2:0:1630::6+++++++DA'
 UNT+13+1'
 UNZ+1+1'

The UNA segment is optional. If present, it specifies the special characters that are to be used to interpret the remainder of the message. There are six characters following UNA in this order:

  • component data element separator (: in this sample)
  • data element separator (+ in this sample)
  • decimal mark (. in this sample)
  • release character (? in this sample)
  • reserved, must be a space
  • segment terminator (' in this sample)

With the exception of the decimal mark (see below), the special characters in the sample UNA segment above are also the default values.

The component data element separator and data element separator are the "first level" and "second level" separators of data elements within a message segment. Referring to them as + and : for brevity, the + separates top-level or composite data elements, and : separates second-level data elements nested within composite data elements. Trailing empty (or null) data elements and their leading separators are omitted to reduce message size.

The decimal mark is used to separate the integer from the fractional part of non-integer numbers. The optional nature of the UNA segment and the initial choice of the comma (",") as the default decimal mark provide a source of common confusion. Versions 1 through 3 of the ISO 9735 syntax rules specify the comma as the default; version 4 states that the decimal mark position in the UNA segment is to be ignored and that the comma and the dot (".") may be used indifferently in numeric data values. The UNB segment indicates which version of the syntax rules is in effect.[3]

Release character (analogous to the \ in regular expressions) is used as a prefix to remove special meaning from the separator, segment termination, and release characters when they are used as plain text ("Escape character" is the equivalent North American term).

Segment terminator indicates the end of a message segment.

Note: The line breaks after each segment in this example have been added for readability. There are typically no line breaks in EDI data.

UNH+1+PAORES:93:1:IA'- This is the message header segment which is required at the start of every message. This code specifies that the message name and version is PAORES 93 revision 1 and it was defined by the organisation IA (IATA).

IFT+3+NO MORE FLIGHTS' - This is an "Interactive Free Text" segment containing the text "NO MORE FLIGHTS".

UNT+13+1' - This is the message trailer segment. It indicated that the message sent contains 13 segments.

Structure

[edit]

EDIFACT has a hierarchical structure where the top level is referred to as an interchange, and lower levels contain multiple messages which consist of segments, which in turn consist of composites. The final iteration is an element which is derived from the United Nations Trade Data Element Directory (UNTDED); these are normalized throughout the EDIFACT standard.

A group or segment can be mandatory (M) or conditional (C) and can be specified to repeat. For example :

- C99 indicates between 0 and 99 repetitions of a segment or group
- M99 signifies between 1 and 99 repetitions of a segment or group

A group, like a message, is a sequence of segments or groups. The first segment or group beneath a group must be mandatory, and the group should be made conditional if the logic of the situation demands it.

 |_Service String Advice              UNA  Optional
 |____Interchange Header              UNB  Mandatory
 :    |___Functional Group Header     UNG  Conditional
 :    :   |___Message Header          UNH  Mandatory
 :    :   :   |__ User Data Segments          As required
 :    :   |__ Message Trailer         UNT  Mandatory
 :    |__ Functional Group Trailer    UNE  Conditional
 |___ Interchange Trailer             UNZ  Mandatory

See also

[edit]

References

[edit]
  1. ^ UNECE, Introducing UN/EDIFACT, accessed 27 September 2020
  2. ^ UN/EDIFACT Syntax Implementation Guidelines, accessed 27 September 2020
  3. ^ ISO 9735: 1988 and ISO 9735-1:2002
[edit]