|
|
United
Nation's Directories for Electronic Data Interchange for Administration,
Commerce and Transport. They comprise a set of internationally agreed
standards, directories and guidelines for the electronic interchange of
structured data, particular as related to trade in goods and services, between
independent, computerised information systems.
Recommended
within the framework of the United Nations, the rules are approved and
published by the UN/CEFACT (United Nations Centre for Trade Facilitation and
Electronic business) in the United Nations Trade Data Interchange Directory
(UNTDID) and are maintained under agreed procedures.
UNTDID includes:
- EDIFACT – Application level syntax rules (Syntax version: 4);
- Message design guidelines;
- Syntax implementation guidelines;
- EDIFACT Data Elements Directory, EDED (a subset of UNTDED);
- EDIFACT Code list, EDCL;
- EDIFACT Composite data elements Directory, EDCD;
- EDIFACT standard Segments Directory, EDSD;
- EDIFACT United Nations Standard Messages Directory, EDMD;
- Uniform Rules of Conduct for the Interchange of Trade Data by Tele-transmission (UNCID);
- Explanatory material, as appropriate.
Actual information is available at www.unece.org/trade/untdid.
5.2 UN/EDIFACT syntax version 4
overview
This section
is a summary of the document: "EDIFACT - Application level syntax rules
(Syntax version: 4)". Actual information is available at www.unece.org/cefact.
The EDIFACT
syntax rules set the rules for structuring data into segments, segments into
messages, and messages into an interchange.
5.2.1 Interchange Structure
An
interchange may consist of the following segments:
Segments
starting with "UN" are called service segments. They constitute the
envelope or the "packaging" of the UN/EDIFACT messages.
User data
segments contain the information itself, in a format specific to each message
type.
5.2.2 Message Structure
Each data
segment has a specific place within the sequence of segments in the message.
They may occur in any of the following three sections of the message:
a.
Heading section
- A segment occurring in this section relates to the entire message.
b. Detail
section
- A segment occurring in this section relates to the detail information only.
c.
Summary section
- Only segments containing totals or control information may occur in
the summary section, e.g. invoice total amount, number of lines in a purchase
order, etc.
The sequence
of the three message sections can be represented by the following simple
example:
The same
segment type may occur in more than one of the message sections, for example in
the header and in the detail section, and/or more than once in the same
section.
Some
segments may be repeated a certain number of times at their specific location
in the message. The status, Mandatory or Conditional, and the maximum number of
repetitions of segment types are indicated in the message structure.
Within a
message, specific groups of functionally related segments may be repeated;
these groups are referred to as "segment groups". The maximum number
of repetitions of a particular segment group at a specific location is included
in the message definition.
A segment
group may be nested within other segment groups, provided that the inner
segment group terminates before any outer segment group terminates.
5.2.3 Segment structure
A segment
consists of:
- A
segment tag: identifies the segment type,
- Data
element separators,
- Simple
and/or composite data elements,
- A
segment terminator.
Data
elements can be defined as having a fixed or variable length.
A composite
data element contains two or more component data elements.
A component
data element is a simple data element used in a composite data element.
A data
element can be qualified by another data element, the value of which is
expressed as a code that gives specific meaning to the data. The data value of
a qualifier is a code taken from an agreed set of code values.
Within
Syntax 4 it is also possible to repeat data elements or data element groups
according to the possible repetitions stated in the standard. The asterisk ( *
) is used as a repetition separator. This feature is only used within the
KEYMAN message (USA, S503) This feature is NOT used in any other messages or
segments within EANCOM® 2002 syntax 4.
Multiple
occurrences of stand-alone simple or composite data elements is permitted.
5.2.4 Service characters
In EANCOM®
five service characters, taken from character set level A, have a special
meaning and act as the default separators for EANCOM®.
|
Colon |
: |
= |
component data element separator |
|
Plus sign |
+ |
= |
segment tag and data element
separator |
|
Question Mark |
? |
= |
release character; immediately
preceding one of the service characters, restores that character’s
normal meaning. For example, 10?+10=20 appearing in a data transfer is
interpreted on receipt as 10+10=20. A question mark is represented by ?? When
used, the release character is not counted in the length of the data element
value. |
|
Asterisk |
* |
= |
repetition separator |
|
Apostrophe |
' |
= |
segment terminator |
Within
EANCOM® 2002 syntax 4 the use of UNA is mandatory.
Should
trading partners agree to use any of the character sets from B to F (inclusive)
and the default separators from UNOA, then the UNA segment must be provided to
explicitly state the default separator values.
Example
of an UN/EDIFACT segment:
DTM+137:20020101:102'
|
DTM |
= |
Tag of the
"Date/Time/Period" segment; |
|
+ |
= |
Data element separator; |
|
137 |
= |
Qualifier to indicate the date is
the Document/Message Date/Time; |
|
: |
= |
Component data element separator
(separating the date qualifier and the date); |
|
20020101 |
= |
Date; |
|
: |
= |
Component data element separator
(separating the date and the date format qualifier); |
|
102 |
= |
Qualifier to indicate the format of
the date (CCYYMMDD); |
|
' |
= |
Segment terminator. |
5.2.5 Compression of data
In data
elements for which the Trade Data Elements Directory specifies variable length
and no other restrictions, non-significant character positions, (i.e. leading
zeroes and trailing spaces) should be suppressed.
TAG =
segment tag; DE = data element; CE = component data element.
|
- |
Exclusion of segments. Conditional segments containing no data should be omitted
(including their segment tags). |
|
|
- |
Exclusion of data elements by
omission. Data elements are identified by
their sequential position within the segments as stated in the Segment
Directory. If a conditional data element is omitted and followed by another
data element, its position should be indicated by retention of its data
element separator. |
|
|
Example: |
TAG+DE+DE+DE+CE:CE:CE'
complete segment including all data elements TAG+DE++DE+CE:CE:CE' |
|
|
- |
Exclusion of data elements by
truncation. If one or more conditional data
elements at the end of a segment are omitted, the segment may be truncated by
the segment terminator. |
|
|
Example: |
TAG+DE+DE+DE+DE' Original
including all data elements TAG+DE+DE' |
|
|
- |
Exclusion of component data
elements by omission. If a
conditional CE is omitted and followed by another CE, its given position must
be represented by its CE separator. |
|
|
Example: |
TAG+DE++DE+CE:CE:CE'
Original including all CE's TAG+DE++DE+CE::CE' |
|
|
- |
Exclusion of component data
elements by truncation. One or more
conditional CE’s at the end of a composite DE may be excluded by truncation
by the DE separator or, if at the end of a segment, by the segment
terminator. |
|
|
Example: |
TAG+DE++DE+CE:CE:CE'
Original including last CE
|
|
|
- |
Exclusion of occurrences of
repeating data elements by omission. The
position of an occurrence of a repeating data element may be significant in
some cases (e.g., transfer array data). In such a case, if an occurrence of a
repeating data element is omitted and is followed by another occurrence of
the same repeating data element, its position shall be indicated by retention
of the repetition separator which would normally follow it. |
|
|
Example: |
TAG+DE+DE*DE*DE*DE+DE’ Original including all DEs |
|
|
- |
Exclusion of occurrences of
repeating data elements by truncation. If one or more occurrences of possible repeating data element(s)
at the end of a repeating data element are omitted, the repetition separators
which would normally follow them shall also be omitted. |
|
|
Example: |
TAG+DE1+DE2*DE2*DE2
+DE3*DE3’ Original including all DEs |
|
5.2.6 Representation of numeric values
|
- |
Decimal sign. The representation for decimal sign is the point on the
line (.). The decimal sign should not be counted as a character when
computing the maximum field length of a data element. When a decimal sign is
transmitted, there should be at least one digit before and after the decimal
sign. To assist in-house file designers and data interchange partners, the following lengths may be used as a guideline:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
- |
Triad separator. Triad separators should not be used in the interchange.
(Allowed: 2500000; Not allowed: 2,500,000 or 2.500.000 or 2 500 000). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
- |
Sign. Numeric data element values should be regarded as
positive. Although a deduction is conceptually negative, it should be
represented by a positive value, (e.g. in a credit note all values are
positive, the application software uses the message name coded (DE 1001) to
convert all values into negative). In addition, some data elements and code
combinations will lead to implied negative values, (e.g. data element 5463
with code value ‘A, Allowance’ in an ALC segment in an invoice). If a value is to be represented as negative, in transmission it should be immediately preceded by a minus sign (e.g., –112). The minus sign shall not be counted as a character when computing the maximum field length of a data element. |
Example 1
(INVOIC)
...
BGM+381+CN52+9' INVOIC message is used as a credit note
...
LIN+1++4000862141404:SRV' Line item 1 identified by GTIN 4000862141404.
...
QTY+61:2' Return quantity is 2.
MOA+203:200' Line item amount is 200.
PRI+AAA:100:CA' Net price from the catalogue is 100.
As DE 1001
in the header contains code value 381, the numeric values in MOA and QTY should
be interpreted as negative by the inhouse application.
In addition,
some data element and code combinations will lead to implied negative values
(e.g., data element 5463 with code value 'A, Allowance' in an ALC segment in an
invoice).
Example 2
(INVOIC)
...
BGM+380+IN42652+9' Commercial invoice number IN42652.
...
LIN+1++4000862141404:SRV' Line item 1 identified by GTIN 4000862141404.
...
MOA+203:200' Line item amount is 200.
...
ALC+A' Allowances
MOA+204:12' The numeric value is 12.
...
As DE 5463
in the ALC segment contains code value A, the numeric values in MOA below
should be interpreted as negative by the in-house application.
It is
recommended to create one message for the invoice and one message for the
credit note. As this is not always possible (e.g., an invoice for drinks with a
negative deposit balance at detail level) the minus sign can be used in DE 6060
of the QTY segment and in DE 5004 of the MOA segment.
This rule is
applicable for debit lines in credit notes and for credit lines in
invoices/debit notes.
If
allowances or charges are calculated backwards (credit note for a previously
sent invoice) the code value in ALC DE 5463 is not changed.
5.2.7 Character sets and syntax
identifiers
Supported
character sets
In syntax
version 4 character sets level A, B, C, D, E, F, G, H, I, J, K, X and Y are
supported. Also supported are the code extension techniques covered by ISO 2022
(with certain restrictions on its use within an interchange), and the partial
use of the techniques covered by ISO/IEC 10646-1.
Within
EANCOM® the use of character set level A is recommended. Any user,
wishing to use a character set level other than A, should first obtain
agreement from the intended trading partner in order to ensure correct
processing by the receiving application.
Character
set level A
Character
set level A (ISO 646 7-bit single byte code, with the exception of lower case
letters and certain graphic character allocations) contains the following
characters:
|
Letters,
upper case Numerals Space
character Full
stop Comma Hyphen/minus
sign Opening
parentheses Closing
parentheses Oblique
stroke (slash) Equal sign Exclamation
mark Quotation
mark Percentage
sign Ampersand Asterisk Semi-colon Less-than
sign Greater-than sign |
A to Z 0 to 9 . , - ( ) / = ! " % & * ; < > |
Character
set level B
Character
set level B (ISO 646 7-bit single byte code, with the exception of certain
graphic character allocations) contains the same characters as character set
level A plus lower case letters ‘a’ to ‘z’.
Character
sets level C to K
Character
sets level C to K (ISO 8859 - 1,2,5,7,3,4,6,8,9 8-bit single byte coded graphic
character sets) cover the Latin 1 - 5, Cyrillic, Arabic, Greek and Hebrew
alphabets.
It is
important to note that EANCOM® users often need, in addition to the
recommended character set level A, the following sub-set of supplementary
characters taken from ISO 8859 - 1:
|
Number sign
Commercial
at Left
square bracket Reverse
solidus Right
square bracket Circumflex
accent Grave
accent Left curly
bracket Vertical
line Right curly bracket |
# @ [ \ ] ^ ` { | } |
Character
set level X
Character
repertoire resulting from the application of the code extension technique as
defined by ISO 2022, utilising the escape sequence technique in accordance with
ISO 2375. For more details see ISO/ICE International Register of Coded
Character Sets to be used with Escape Sequences.
Character
set level Y
Character
repertoire taken from ISO 10646 – 1 octet without the application of a
code extension technique. See the appropriate details in ISO 10646 –1.
Syntax
identifier, ISO standard and supported languages
The
following table contains the code values for the syntax identifier and explains
which languages are catered for in which ISO standard.
Note that
the last character of the syntax identifier (data element 0001) identifies the
character set level used.
|
Syntax Identifier |
ISO standard |
Languages |
|
UNOA |
646 |
. |
|
UNOB |
646 |
. |
|
UNOC |
8859 - 1 |
Danish, Dutch, English, Faeroese, Finnish, French, German, Icelandic, Irish, Italian, Norwegian, Portuguese, Spanish, Swedish |
|
UNOD |
8859 - 2 |
Albanian, Czech, English, Hungarian, Polish, Romanian, Serbo-Croatian, Slovak, Slovene |
|
UNOE |
8859 - 5 |
Bulgarian, Byelorussian, English, Macedonian, Russian, Serbo-Croatian, Ukrainian |
|
UNOF |
8859 - 7 |
Greek |
|
UNOG |
8859 - 3 |
Maltese |
|
UNOH |
8859 - 4 |
Estonian, Latvian, Lithuanian, Greenlandic, Lappish |
|
UNOI |
8859 - 6 |
Arabic |
|
UNOJ |
8859 - 8 |
Hebrew, Yiddish |
|
UNOK |
8859 - 9 |
Turkish |
|
UNOX |
2022 2375 |
Character sets level C to K
supported languages, Asian (e.g. Japanese, traditional Chinese language, …)
and other languages that are based on character sets compliant with ISO 2022
and ISO 2375. |
|
UNOY |
10646 - 1 |
Aimed to cover all written
languages of the world. |
5.3 Directory status, version and
release
All EANCOM®
2002 messages are based on the UN/EDIFACT directory D.01B which was released by
UN/CEFACT in 2001. All messages contained in this directory are approved as
United Nations Standard Messages (UNSM).
Each EANCOM®
message carries its own subset version number, which allows the unambiguous
identification of different versions of the same EANCOM® message.
The EANCOM® subset version number is indicated in data element 0057
in the UNG and UNH segments. It is structured as follows:
GS1nnn
where: GS1 = Indicates GS1 as the agency controlling the subset.
nnn = Three-digit version number of the EANCOM® subset.
Subset
version numbers for formally released EANCOM® messages start at the
number ‘001’ and are incremented by one for each subsequent version
of the message.
5.5.1 Format of data elements
The
following conventions apply in the present documentation:
Character
type:
a :alphabetic characters
n :numeric characters
an :alpha-numeric characters
Size:
Fixed : all positions must be used
Variable : positions may be used up to a specified maximum
Examples:
a3 :3 alphabetic characters, fixed length
n3 :3 numeric characters, fixed length
an3 :3 alpha-numeric characters, fixed length
a..3 :up to 3 alphabetic characters
n..3 :up to 3 numeric characters
an..3 :up to 3 alpha-numeric characters
5.5.2 Indicators
This section
describes the layout of segments used in the EANCOM® messages. The
original UN/EDIFACT segment layout is listed. The appropriate comments relevant
to the EANCOM® subset are indicated.
The segments
are presented in the sequence in which they appear in the message. The segment
or segment group tag is followed by the (M)andatory / (C)onditional indicator,
the maximum number of occurrences and the segment description.
Reading from
left to right, in column one, the data element tags and descriptions are shown,
followed by in the second column the UN/EDIFACT status (M or C), the field
format, and the picture of the data elements. These first pieces of information
constitute the original UN/EDIFACT segment layout.
Following
the UN/EDIFACT information, EANCOM® specific information is provided
in the third, fourth, and fifth columns. In the third column a status indicator
for the use of (C)onditional UN/EDIFACT data elements (see description below),
in the fourth column the restriction indicator, and in the fifth column notes
and code values used for specific data elements in the message.
Status
indicators
(M)andatory
data elements or composites in UN/EDIFACT segments retain their status in
EANCOM®.
Additionally,
there are five types of status with a (C)onditional UN/EDIFACT status, whether
for simple, component or composite data elements. They are listed below and can
be identified when relevant by the abbreviations.
|
- REQUIRED |
R |
Indicates that the entity is
required and must be sent. |
|
- ADVISED |
A |
Indicates that the entity is
advised or recommended. |
|
- DEPENDENT |
D |
Indicates that the entity must be
sent in certain conditions, as defined by the relevant explanatory note. |
|
- OPTIONAL |
O |
Indicates that the entity is
optional and may be sent at the discretion of the user. |
|
- NOT USED |
N |
Indicates that the entity is not
used and should be omitted. |
If a
composite is flagged as N, NOT USED, all data elements within that composite
will have blank status indicators assigned to them.
Restriction
indicators
|
- |
Restricted (*) A data element marked with an asterisk (*) in the fourth
column of the segment details of a message indicates that the listed codes in
column five are the only codes available for use with the data element at the
same level as the asterisk, in the current segment, in the current message. |
|
- |
Open. All data elements in which coded representation of data
is possible, and in which a restricted set of code values is not indicated,
are open. The available codes are listed in the Data Elements and Code Sets
Directory (Part III of this manual). Code values may be given as examples or
there may be a note on the format or type of code to be used. |
Different
colours are used for the code values in the HTML segment details: restricted
codes are in red and open codes in blue.
5.6 Message structure charts and
branching diagrams
Within every
EANCOM® message two diagrams are presented which explain the
structure and sequence of the message. These diagrams are known as the Message
Structure Chart and the Message Branching Diagram.
The message
structure chart is a sequential chart which presents the message in the
sequence in which it must be formatted for transmission. Every message is
structured and consists of three sections; a header, detail, and summary
section. An example of a message structure chart follows:
The
structure chart should always be read from top down and left to right (please
note that the message detailed is simply an example message and does not bear
any relevance to real EANCOM® messages).
A message
branching diagram is a pictorial representation (in flow chart style) which
presents the logical sequence and relationships contained within a message.
Branching
diagrams should be read, starting at the UNH segment, from left to right and
top to bottom. The lines contained within a branching diagram should be
considered as guides which must be followed in order to progress through the
message.
5.7 Interchange structure and
service segments
The
interchange structure in an UN/EDIFACT transmission is organised through
several grouping levels. The service segments are the envelope of the groups.
The first
service segment possible in an interchange is the ‘UNA’ segment which
defines the service characters being used in the interchange.
The second
service segment, ‘UNB’, indicates the beginning of the interchange.
The next
one, ‘UNG’, indicates the beginning of a group of messages of the same type,
for example invoices.
The last
service segment, ‘UNH’, indicates the beginning of a given message.
Each
beginning service segment corresponds to an ending service segment (note: UNA
is not a beginning segment).
Service string advice: UNA
Interchange envelope: UNB .... UNZ
Group envelope: UNG .... UNE
Message envelope: UNH .... UNT
The
interchange can thus be represented like this:
Within
the syntax 4 version of EANCOM® the use of the UNA segment is not
required.
Segment UNA
is dependent on the character set being used. If the EANCOM® default
character set A is being used then the UNA segment is not required.
Segments
UNB..UNZ and UNH..UNT are mandatory.
Segments
UNG..UNE are conditional. Within EANCOM® the use of the UNG..UNE
segments is not recommended, as the grouping of identical message types is not
considered to add significant value to an interchange, (i.e., between
UNB..UNZ).
If the
UNG..UNE segments are used, then it should be noted that it is not possible in
the EANCOM® CONTRL message to report syntactically on a functional
group.
The message
itself is structured with a Header, a Detail and a Summary section. In messages
where there may be ambiguity between the sections, the UNS segment may be used
as a separator.
The layout
of the service segments UNA, UNB - UNZ, UNG - UNE, and UNH - UNT is presented
in this section.
The Section
control segment (UNS), Anti-collision segment group header (UGH) and
Anti-collision segment group trailer (UGT) are not shown here. Their usage is
defined in those EANCOM® messages where the segments are actually
used.
Segment
Layout - UNA segment
|
UNA - C 1 - |
Service string advice |
|||||
|
Function : |
The
service string advice shall begin with the upper case characters UNA immediately
followed by six characters in the order shown below. The space character
shall not be used in positions UNA1, UNA2, UNA4, UNA5 or UNA6. The same
character shall not be used in more than one position of the UNA. |
|||||
|
Segment number : |
|
|||||
|
|
EDIFACT |
GS1 |
* |
Description |
||
|
UNA1 |
Component
data element separator |
M an1 |
M |
* |
Used as a separator between component data elements contained within a composite data element (value ":" ). |
|
|
UNA2 |
Data element separator |
M an1 |
M |
* |
Used to
separate two simple or composite
data elements (value: "+" ). |
|
|
UNA3 |
Decimal mark |
M an1 |
M |
* |
Used to
indicate the character used for decimal notation (value: "."
). |
|
|
UNA4 |
Release character |
M an1 |
M |
* |
Used to restore any service character to its original specification (value: "?" ). |
|
|
UNA5 |
Repetition separator |
M an1 |
M |
* |
Used to
indicate the character used for repetition separation (value: " *
" ). |
|
|
UNA6 |
Segment terminator |
M an1 |
M |
* |
Used to
indicate the end of segment data (value: " ' "). |
|
|
Segment Notes: This segment is used to inform the receiver of the interchange about the set of service characters (and decimal mark) which are being used. It must immediately precede the UNB segment and contains the five service characters (positions UNA1, UNA2, UNA4, UNA5 and UNA6) selected by the interchange sender. When expressing the service characters in the UNA segment, it is not necessary to include any element separators. Within EANCOM®, using the default set of service characters, the use of the UNA segment is not required. Example: |
||||||
Segment
Layout - UNB segment
|
UNB - M 1 - |
Interchange header |
||||||
|
Function : |
To identify an interchange. |
||||||
|
Segment number : |
|
||||||
|
|
EDIFACT |
GS1 |
* |
Description |
|||
|
S001 |
SYNTAX IDENTIFIER |
M |
M |
. |
See Part I chapter 5.2.7 and segment notes. |
||
|
0001 |
Syntax identifier |
M a4 |
M |
* |
UNOA =
UN/ECE level A |
||
|
0002 |
Syntax version number |
M an1 |
M |
* |
4 = Version 4 |
||
|
0080 |
Service
code list directory |
C an..6 |
N |
. |
|
||
|
0133 |
Character encoding, coded |
C an..3 |
N |
. |
|
||
|
S002 |
INTERCHANGE SENDER |
M |
M |
. |
|
||
|
0004 |
Interchange sender identification |
M an..35 |
M |
. |
GLN (n13) |
||
|
0007 |
Identification code qualifier |
C an..4 |
R |
* |
14
= GS1 |
||
|
0008 |
Interchange
sender internal identification |
C an..35 |
O |
. |
|
||
|
0042 |
Interchange sender internal sub-identification |
C an..35 |
N |
. |
|
||
|
S003 |
INTERCHANGE RECIPIENT |
M |
M |
. |
|
||
|
0010 |
Interchange recipient identification |
M an..35 |
M |
. |
GLN (n13) |
||
|
0007 |
Identification code qualifier |
C an..4 |
R |
* |
14 = GS1 |
||
|
0014 |
Interchange
recipient internal |
C an..35 |
O |
. |
|
||
|
0046 |
Interchange
recipient internal |
C an..35 |
N |
. |
|
||
|
S004 |
DATE
AND TIME OF |
M |
M |
. |
|
||
|
0017 |
Date |
M n8 |
M |
. |
CCYYMMDD |
||
|
0019 |
Time |
M n4 |
M |
. |
HHMM |
||
|
0020 |
Interchange control reference |
M an..14 |
M |
. |
Unique reference identifying the
interchange. Created by the interchange sender. |
||
|
S005 |
RECIPIENT
REFERENCE/ PASSWORD DETAILS |
C |
O |
. |
|
||
|
0022 |
Recipient reference/password |
M an..14 |
M |
. |
|
||
|
0025 |
Recipient
reference/password qualifier |
C an2 |
O |
. |
|
||
|
0026 |
Application reference |
C an..14 |
O |
. |
Message identification if the
interchange contains only one type of message. |
||
|
0029 |
Processing priority code |
C a1 |
O |
. |
A = Highest priority |
||
|
0031 |
Acknowledgement request |
C n1 |
O |
. |
1 = Requested |
||
|
0032 |
Interchange
agreement |
C an..35 |
O |
* |
EANCOM...... |
||
|
0035 |
Test indicator |
C n1 |
O |
. |
1 = Interchange is a test |
||
|
Segment notes: This segment is used to envelope the interchange, as well as to identify both, the party to whom the interchange is sent and the party who has sent the interchange. The principle of the UNB segment is the same as a physical envelope which covers one or more letters or documents, and which details, both the address where delivery is to take place and the address from where the envelope has come. S001: The character encoding specified in basic code table of ISO/IEC 646 (7-bit coded character set for information interchange) shall be used for the interchange service string advice (if used) and up to and including the composite data element S001 'Syntax identifier' in the interchange header. The character repertoire used for the characters in an interchange shall be identified from the code value of data element 0001 in S001 'Syntax identifier' in the interchange header. The character repertoire identifieddoes not apply to objects and/or encrypted data. The
default encoding technique for a particular repertoire shall be the encoding
technique defined by its associated character set specification. DE 0001:
The recommended (default) character set for use in EANCOM® for
international exchanges is character set A (UNOA). Should users wish to use
character sets other than A, an agreement on which set to use should be
reached on a bilateral basis before communications begin. DE 0004, 0008, 0010, 0014, 0042 and 0046: Within EANCOM® the use of the Global Location Number (GLN) is recommended for the identification of the interchange sender and recipient. DE 0008:
Identification (e.g. a division) specified by the sender of the interchange,
to be included if agreed, by the recipient in response interchanges, to
facilitate internal routing. DE 0042:
Sub-level of sender internal identification, when further sub-level
identification is required. DE 0014: The address for routing, provided beforehand by the interchange recipient, is used by the interchange sender to inform the recipient of the internal address, within the latter's systems, to which the interchange should be routed. It is recommended that the GLN be used for this purpose. DE 0007:
Identification (e.g. a division) specified by the recipient of the
interchange, to be included if agreed, by the sender in response
interchanges, to facilitate internal routing. DE 0046:
Sub-level of recipient internal identification, when further sub-level
identification is required. DE S004: The date and time specified in this composite should be the date and time at which the interchange sender prepared the interchange. This date and time may not necessarily be the same as the date and time of contained messages. DE 0020: The interchange control reference number is generated by the interchange sender and is used to identify uniquely each interchange. Should the interchange sender wish to re-use interchange control reference numbers, it is recommended that each number be preserved for at least a period of three months before being re-used. In order to guarantee uniqueness, the interchange control reference number should always be linked to the interchange sender's identification (DE 0004). DE S005: The use of passwords must first be agreed bilaterally by the parties exchanging the interchange. DE 0026: This data element is used to identify the application, on the interchange recipient's system, to which the interchange is directed. This data element may only be used if the interchange contains only one type of message, (e.g. only invoices). The reference used in this data element is assigned by the interchange sender. DE 0031:
This data element is used to indicate whether an acknowledgement to the
interchange is required. The EANCOM® APERAK or CONTRL message
should be used to provide acknowledgement of interchange receipt. In
addition, the EANCOM® CONTRL message may be used to indicate when
an interchange has been rejected due to syntax errors. DE 0032:
This data element is used to identify any underlying agreements which control
the exchange of data. Within EANCOM® , the identity of such
agreements must start with the letters 'EANCOM', the remaining characters
within the data element being filled according to bilateral agreements.
|
|||||||
Segment
Layout - UNG segment
|
UNG - C 200000 - |
Group header |
|||||
|
Function : |
To head,
identify and specify a group of messages and/or packages, which may be used for
internal routing and which may contain one or more message types and/or
packages. |
|||||
|
Segment number : |
|
|||||
|
|
EDIFACT |
GS1 |
* |
Description |
||
|
0038 |
Message
group identification |
C an..6 |
R |
. |
Identification
of a message contained in the functional group, e.g. INVOIC. |
|
|
S006 |
APPLICATION SENDER IDENTIFICATION |
C |
R |
. |
|
|
|
0040 |
Application sender identification |
M an..35 |
M |
. |
GLN (n13) |
|
|
0007 |
Identification code qualifier |
C an..4 |
R |
* |
14 = GS1 |
|
|
S007 |
APPLICATION
RECIPIENT |
C |
R |
. |
|
|
|
0044 |
Application recipient identification |
M an..35 |
M |
. |
GLN (n13) |
|
|
0007 |
Identification code qualifier |
C an..4 |
R |
* |
14 = GS1
Association) |
|
|
S004 |
DATE
AND TIME OF |
C |
R |
. |
|
|
|
0017 |
Date |
M n8 |
M |
. |
CCYYMMDD |
|
|
0019 |
Time |
M n4 |
M |
. |
HHMM |
|
|
0048 |
Group
reference number |
M
an..14 |
M |
. |
Unique
reference identifying the functional group. Created by the
interchange sender. |
|
|
0051 |
Controlling
agency, coded |
C
an..3 |
N |
. |
|
|
|
S008 |
MESSAGE
VERSION |
C |
R |
. |
|
|
|
0052 |
Message
version number |
M
an..3 |
M |
* |
D =
UN/EDIFACT Directory |
|
|
0054 |
Message
release number |
M
an..3 |
M |
. |
The
value of this data element depends on the message
type. |
|
|
0057 |
Association
assigned code |
C
an..6 |
R |
. |
The
value of this data element depends on the message type. |
|
|
0058 |
Application
password |
C
an..14 |
D |
. |
The
use of this data element depends on agreements between the trading
partners. |
|
|
Segment
Notes: Within EANCOM® the use of the UNG - UNE segments is not recommended as the grouping of identical message types is not considered to add significant value to an interchange, (i.e., between UNB - UNZ). |
||||||
Segment
Layout - UNH segment
|
UNH - M 1 - |
Message header |
|||||
|
Function : |
To head, identify and specify a message. |
|||||
|
Segment number : |
|
|||||
|
|
EDIFACT |
GS1 |
* |
Description |
||
|
0062 |
Message
reference number |
M
an..14 |
M |
|
Unique reference number assigned to a message within an interchange by the sender. Same reference number as in DE 0062 of the UNT segment of the message. |
|
|
S009 |
MESSAGE
IDENTIFIER |
M |
M |
|
|
|
|
0065 |
Message
type |
M
an..6 |
M |
* |
Identification
of a message. |
|
|
0052 |
Message
version number |
M
an..3 |
M |
* |
D =
UN/EDIFACT Directory |
|
|
0054 |
Message
release number |
M
an..3 |
M |
* |
01B
= Release 2001 - B |
|
|
0051 |
Controlling
agency |
M
an..2 |
M |
* |
UN =
UN/CEFACT |
|
|
0057 |
Association
assigned code |
C
an..6 |
R |
* |
GS1nnn
= EANCOM® subset version. ‘GS1’ represents GS1
International. |
|
|
0110 |
Code
list directory version number |
C
an..6 |
O |
|
E4yyyy
= EANCOM® code list version number. |
|
|
0113 |
Message
type sub-function |
C
an..6 |
N |
|
|
|
|
0068 |
Common
access reference |
C
an..35 |
N |
|
|
|
|
S010 |
STATUS
OF THE |
C |
N |
|
|
|
|
0070 |
Sequence
of transfers |
M
n..2 |
|
|
|
|
|
0073 |
First
and last transfer |
C a1 |
|
|
|
|
|
S016 |
MESSAGE
SUBSET |
C |
N |
|
|
|
|
0115 |
Message
subset identification |
M an..14 |
|
|
|
|
|
0116 |
Message
subset version |
C an..3 |
|
|
|
|
|
0118 |
Message
subset release |
C an..3 |
|
|
|
|
|
0051 |
Controlling
agency, coded |
C an..3 |
|
|
|
|
|
S017 |
MESSAGE
IMPLEMENTATION |
C |
N |
|
|
|
|
0121 |
Message
implementation |
M an..14 |
|
|
|
|
|
0122 |
Message
implementation |
C an..3 |
|
|
|
|
|
0124 |
Message
implementation |
C an..3 |
|
|
|
|
|
0051 |
Controlling
agency, coded |
C an..3 |
|
|
|
|
|
S018 |
SCENARIO
IDENTIFICATION |
C |
N |
|
|
|
|
0127 |
Scenario
identification |
M an..14 |
|
|
|
|
|
0128 |
Scenario
version number |
C an..3 |
|
|
|
|
|
0130 |
Scenario
release number |
C an..3 |
|
|
|
|
|
0051 |
Controlling
agency, coded |
C an..3 |
|
|
|
|
|
Segment
Notes: This
segment is used to head and uniquely identify a message in an interchange. DE 0062:
It is good practice to have the message reference number both unique and
incremental. S009:
Identification of an EANCOM® message. The
content of data elements 0065, 0052, 0054 and 0051 must be taken from the
related UN/EDIFACT standard message. The
content of data element 0057 is assigned by GS1 as part of the EANCOM®
maintenance process. DE 0065:
Data element 0065 identifies a UN/EDIFACT message whereas the exact usage of
the message is specified in BGM data element 1001. E.g. UN/EDIFACT invoice
message serving as a credit note: UNH DE 0065 = INVOIC, BGM DE 1001 = 381. DE 0110:
This data element can be used by the trading partners to identify an EANCOM®
code list, different from the code list published as an integral part of
EANCOM® syntax version 4, 2002 release, they have mutually agreed
to use when interchanging a message. The
combination of the values carried in the data elements 0062 and S009 shall be
used to uniquely identify the message within the interchange for the purpose
of acknowledgement (ref. UNB – data element 0031). Example: |
||||||
Segment
Layout - UNT segment
|
UNT - M 1 - |
Message trailer |
|||||
|
Function : |
To end and
check the completeness of a message. |
|||||
|
Segment number : |
|
|||||
|
|
EDIFACT |
GS1 |
* |
Description |
||
|
0074 |
Number_of_segments
in the message |
M n..6 |
M |
. |
Total
number of segments in a message. |
|
|
0062 |
Message_reference_number |
M
an..14 |
M |
. |
Same
reference number as in DE 0062 of the UNH segment of the message. |
|
|
Segment
Notes: This
segment is used to end and provide information for checking the completeness
of a message. The
segment number shows the position of the segment in a message. It must always
be the last segment in a message. DE 0074:
Count of all segments in a message, UNH and UNT included. Example: |
||||||
Segment
Layout - UNE segment
|
UNE - C 1 - |
Group trailer |
|||||
|
Function : |
To end and check the completeness of a group. |
|||||
|
Segment number : |
|
|||||
|
|
EDIFACT |
GS1 |
* |
Description |
||
|
0060 |
Group
control count |
M n..6 |
M |
_ |
Number
of messages in a group. |
|
|
0048 |
Group_reference_number |
M
an..14 |
M |
_ |
Identical
to DE 0048 in UNG segment. |
|
|
Segment
Notes: Within
EANCOM® the use of the UNG - UNE segments is not recommended as
the grouping of identical message types is not considered to add significant
value to an interchange, (i.e., between UNB - UNZ). |
||||||
Segment
Layout - UNZ segment
|
UNZ - M 1 - |
Interchange trailer |
|||||
|
Function : |
To end and check the completeness of an interchange. |
|||||
|
Segment number : |
|
|||||
|
|
EDIFACT |
GS1 |
* |
Description |
||
|
0036 |
Interchange
control count |
M n..6 |
M |
. |
Number
of messages or functional groups
within an interchange. |
|
|
0020 |
Interchange
control reference |
M
an..14 |
M |
. |
Identical
to DE 0020 in UNB segment. |
|
|
Segment Notes: This segment is used to provide the trailer of an interchange. DE 0036: If functional groups are used, this is the number of functional groups within the interchange. If functional groups are not used, this is the number of messages within the interchange. Example: |
||||||
|
|
|
A comprehensive description and Implementation Guidelines of EANCOM Digital Signature is freely available at http://www.gs1.org/docs/ecom/eancom/eancom_Digital_Signature.pdf. |
|
|
|