***
* The present document is reproduced in the form in
which it was received by the secretariat.
* * *
Submitted by the Chair of the group for revision of TRADE/WP,4/R.1023
Previous documentation:
TRADE/WP.4/R.635/Rev.3
TRADE/WP.4/R.1023
TRADE/WP.4/R.1023 Rev.1
This revision is issued following comments on revsion 1 from the
Directory Audit Team, the Directory Production Team and some
delegations. The modifications are essentially editorial in nature and
resolve ambiguities in the interpretation.
An Annex (currently for information only) outlines recommended changes
which require the approval of WP.4/GE.1 prior to detailed elaboration
and implementation. It is proposed that these changes be made in a
revision 3 of this document to be presented at the next meeting.
The D.95B directory is, to a large extent, in conformity with this
revision.
The Group of Experts and Working Party are invite to
-approve the main document
-review and submit somments, prior to 1 December 1995.
The present document is reproduced in the form in which is was
received by the secretariat.
CONTENTS
1 INTRODUCTION 3
1.1. FOREWORD AND SCOPE 4
1.2. CONVENTIONS AND FORMATS 4
2 GENERAL REQUIREMENTS 5
2.1. REQUIREMENTS FOR ALL TEXT IN ELECTRONIC OR PRINTED FORM 6
3. UN/EDIFACT DIRECTORIES 9
3.1. REQUIREMENTS FOR THE UN/EDIFACT DIRECTORIES 10
3.1.1. LAYOUT OF THE DRAFT DIRECTORY COVER PAGE. 11
3.1.2. LAYOUT OF THE STANDARD DIRECTORY COVER PAGE. 12
3.1.3. THE TABLE OF CONTENTS FOR THE UN/EDIFACT DIRECTORIES.13
3.1.4. INTRODUCTION TO PART 5 OF THE UN/EDIFACT DIRECTORIES.16
4. MESSAGE TYPE DIRECTORY 17
4.1. MESSAGE TYPE DIRECTORY INDEX. 18
4.2. REQUIREMENTS FOR ALL MESSAGE BOILERPLATE TEXT 20
4.3 MESSAGE BOILERPLATE COVER PAGES 21
4.3.1. STATUS 0 MESSAGES : 21
4.3.2. STATUS 1 AND STATUS 2 MESSAGES IN THE DRAFT DIRECTORY:
23
4.3.3. STATUS 2 MESSAGES IN THE STANDARDS DIRECTORY. 25
4.4. MESSAGE TABLE OF CONTENTS 27
4.4.1. STATUS 0 MESSAGE BOILERPLATE TABLE OF CONTENTS 27
4.4.2. STATUS 1 AND STATUS 2 MESSAGE BOILERPLATE TABLE OF CONTENTS
29
4.5. INTRODUCTION, SECTION 0 AND SECTION 1 OF THE MESSAGE BOILERPLATE.
31
4.6. SECTION 2 AND SECTION 3 OF THE MESSAGE BOILERPLATE. 32
4.7. SECTION 4 OF THE MESSAGE BOILERPLATE. 33
4.7.1. SECTION 4.1 (DATA SEGMENT CLARIFICATION) 33
4.7.2. SECTION 4.2 (DATA SEGMENT INDEX) 37
4.7.3. SECTION 4.3.1 (SEGMENT TABLE) 38
4.7.4. SECTION 4.3.2. (BRANCHING DIAGRAM) 40
4.7.5. SECTION 5 (STATUS 0 MESSAGES ONLY). 41
4.7.6. ANNEX (STATUS 0 MESSAGES ONLY). 41
5. SEGMENT DIRECTORY 42
5.1. SEGMENT DIRECTORY INDEX. 43
5.2. SEGMENT DIRECTORY SPECIFICATIONS 44
6. COMPOSITE DATA ELEMENT DIRECTORY 47
6.1. COMPOSITE DIRECTORY INDEX. 48
6.2. COMPOSITE DATA ELEMENT DIRECTORY SPECIFICATIONS 49
7. DATA ELEMENT DIRECTORY 52
7.1. DATA ELEMENT DIRECTORY INDEX. 53
7.2. DATA ELEMENT DIRECTORY SPECIFICATIONS 54
8. CODE LISTS 56
8.1. CODE LIST DIRECTORY SPECIFICATIONS 57
ANNEXES 59
ANNEX 1 ALLOWED CHARACTER SETS 60
ANNEX 2 DATA ELEMENTS USED IN LAYOUTS 62
ANNEX 3 RECOMMENDED EVOLUTIONS. 63
1 INTRODUCTION
1.1. FOREWORD AND SCOPE
The requirements for the data transfer of information and the
requirements for documentary layout of such information are not the
same. This is the case for the UN/EDIFACT set of directories which
uses the UN/EDIFACT DIRDEF message for the transfer of the directories
and which takes a different form for the transfer of the equivalent
information in readable form on magnetic media.
The layout specified in this document may be used for submissions of
human readable message documentation to the UN/ECE Secretariat via
magnetic media wherever the DIRDEF message is not used.
It shall be used by the UN/ECE Secretariat when publishing message
boilerplates and their supporting directories in human-readable format
via magnetic media and in producing the printed documentation.
This document shall be applied to the documentation of UN/EDIFACT
messages and their supporting directories (Data element, data element
code list, composite data element, and segment documentation).
1.2. CONVENTIONS AND FORMATS
In this documentation, the following conventions are defined:
a) variable fields that correspond to values maintained by a standard
code list have their data element tag identified within the brackets [
]. For example, [0065] refers to the relevant content of data element
0065.
b) other variable fields which are used in the document layouts are
identified by {} and their content is explained at the appropriate
place.
c) The use of the version and release data elements for UN/EDIFACT
messages is described in document TRADE/WP.4/R.982.
2 GENERAL REQUIREMENTS
2.1. REQUIREMENTS FOR ALL TEXT IN ELECTRONIC OR PRINTED FORM
a) The number of printable characters per line shall be up to 70
characters. On magnetic media, each line shall be followed by
the non printable characters "Carriage Return" (ISO 8859
magnetic 13) immediately followed by "Form Feed" (ISO 8859
magnetic 10).
b) The number of printable lines per page shall be 50 in order to
permit compatibility between the US letter (8.5' * 11') format
and the ISO A4 standard format.
c) The permitted character set shall be taken from ISO 8859-1 (G0
graphic set only) plus certain IBM graphic characters (see
Annex 1). All characters including the space character shall be
fixed pitched.
d) Character and line spacing shall be based on ISO 3535 which
specifies basic spacing measurements of 1/6 inch or 4.233 mm
for line spacing and 1/10 inch or 2.54 mm for character
spacing.
e) The type font shall be Courier 10.
f) No tabulation characters shall be used for magnetic media.
Instead, where indention occur, each indention shall be
represented by 3 space characters.
g) No page breaks shall be provided in the documents supplied on
magnetic media.
h) Printed documents shall have a top and bottom margin of 3 line
spaces for page headings and footings.
i) Printed documents shall have a left margin of a Minimum of 2.8
cm (13 char. pos.).
j) No right justification of text is allowed(i.e. no insertion of
extra space characters between words).
k) Printed documents shall have no bold, underlined or italic
text.
l) Capital letters shall be used only in the following situations:
- at the beginning of a sentence,
- as first letter of a name or a heading,
- main title headings,
- and in codes, tags and acronyms.
m) Horizontal and vertical starting positions of data items shall
be as specified in the layouts and examples given in Part 3 and
Part 4 of this document. These examples exclude the spacing
required for page headings and for right and left margins which
are not provided on electronic media.
n) documents which are printed recto-verso shall have in the top
margin of the page the TRADE document number and page number
which shall be right adjusted on odd numbered pages and left
adjusted on even numbered pages.
UN/EDIFACT {directory type}[0052].[0054]
TRADE/WP.4/R.XXXX
Page NNN
70 characters
___________________________________________________________________
{Directory name}
o) All printed pages of the supporting directories shall have the
following format :
where : xxxx is the document number assigned to the directory
by the UN.
NNN is the sequential page number
{directory type} is either "Standard directory" or "Draft
directory".
{Directory name} is one of the following :
Segment directory
Data element directory
Composite data element directory
Code directory
Service code directory
TRADE/WP.4/R.XXXX
Page NNN
__________________________________________________________________
70 characters
___________________________________________________________________
Message type specification, [0065]
p) All printed pages of message boilerplates shall have the
following format :
where : xxxx is the document number assigned to the directory
by the UN.
NNN is the sequential page number
3. UN/EDIFACT DIRECTORIES
3.1. REQUIREMENTS FOR THE UN/EDIFACT DIRECTORIES
The UN/EDIFACT directories and accompanying information are published
in a single document. On magnetic media this document is divided into
a series of separate files. The content and name of the different
files can be obtained from the table of contents of the directory. For
convenience this is provided on a specific file with the name
"CONTENTx.yyy" where "x" represents the letter "D" for a draft
directory or the letter "S" for a standard directory. The letters
"yyy" represent the version of the supporting directory (i.e. 95A).
3.1.1. Layout of the Draft directory cover page.
1 4 17 70
UNITED NATIONS DIRECTORIES FOR ELECTRONIC DATA INTERCHANGE FOR
ADMINISTRATION, COMMERCE AND TRANSPORT
UN/EDIFACT
DRAFT DIRECTORY
D.[0054]
{YYYY-MM-DD}
Approved by UN/ECE Working Party on Facilitation of International
Trade Procedures (WP.4), {XX MM..MM YYYY}
Copyright {YYYY} United Nations, all rights reserved
The cover page of the supporting draft directory has the following
format :
The value of data element [0054] corresponds to the release of the
supporting directory (i.e. 95A).
The date {YYYY-MM-DD} in line 27 corresponds to the date of
preparation of the supporting directories by the UN Secretariat.
The date of approval on line 42 {XX MM..MM YYYY} corresponds to the
date of approval of the supporting directories by the Working Party 4.
The date {YYYY} in line 44 corresponds to the year of publication.
3.1.2. Layout of the Standard directory cover page.
1 4 17 70
UNITED NATIONS DIRECTORIES FOR ELECTRONIC DATA INTERCHANGE FOR
ADMINISTRATION, COMMERCE AND TRANSPORT
UN/EDIFACT
STANDARD DIRECTORY
UNITED NATIONS TRADE DATA INTERCHANGE DIRECTORY
(UNTDID)
S.[0054]
{YYYY-MM-DD}
Approved by UN/ECE Working Party on Facilitation of International
Trade Procedures (WP.4), {XX MM..MM YYYY}
Copyright {YYYY} United Nations, all rights reserved
The cover page of the supporting standard directory has the following
format :
The value of data element [0054] corresponds to the release of the
supporting directory (i.e. 95A).
The date {YYYY-MM-DD} in line 27 corresponds to the date of
preparation of the supporting directories by the UN Secretariat.
The date of approval on line 42 {XX MM..MM YYYY} corresponds to the
date of approval of the supporting directories by the Working Party 4.
The date {YYYY} in line 44 corresponds to the year of publication.
3.1.3. The table of contents for the UN/EDIFACT directories.
The UN/EDIFACT directories have a table of contents and standard
notes. This information is set out in the following diagrams.
1 6 9 11 28 52 70
TABLE OF CONTENTS
DESCRIPTION DISKETTE FILE
PART 1 INTRODUCTION D100_{T}.{YY}{V}
PART 2 UNIFORM RULES OF CONDUCT FOR INTERCHANGE PART2_{T}.ZIP(1)
OF TRADE DATA BY TELETRANSMISSION (UNCID)
Chapter 1 Introductory note D210_{T}.{YY}{V}
Chapter 2 Text of the uniform rules of conduct D220_{T}.{YY}{V}
Chapter 3 Guide for users (2)
Chapter 4 Interchange Agreement D240_{T}.{YY}{V}
PART 3 TERMS AND DEFINITIONS(2) PART3_{T}.ZIP(1)
Glossary D300_{T}.{YY}{V}
PART 4 UNITED NATIONS RULES FOR ELECTRONIC DATA PART4_{T}.ZIP(1)
INTERCHANGE FOR ADMINISTRATION,
COMMERCE AND TRANSPORT
Chapter 1 Introduction D410_{T}.{YY}{V}
Chapter 2 General information
2.1 Establishment of United Nations Standard D421_{T}.{YY}{V}
Message types (UNSMs)
2.2 UN/EDIFACT syntax Rules D422_{T}.{YY}{V}
(ISO 9735-latest version)
2.3 UN/EDIFACT syntax implementation
guidelines D4231_{T}.{YY}{V}
D4232_{T}.{YY}{V}
D4232A_{T}.{YY}{V}
D4233_{T}.{YY}{V}
2.4 UN/EDIFACT message design guidelines D424_{T}.{YY}{V}
2.5 Version/release
2.6 General introduction to UNSM
descriptions D425_{T}.{YY}{V}
This document describes the rules of presentation for the
information/files/data listed under part 5 of the table of contents.
It does not cover the presentation of information/files/data found in
parts 1 through 4.
The value {XX} shall be replaced with the characters "ED" for standard
directories and with the characters "TR" for draft directories.
The value {T} shall be replaced by the character "S" for standard
directories and the character "D" for draft directories.
The value {YY} shall be replaced with the year of the directory
revision.
The value {V} shall be replaced by the alphabetic sequential value
assigned to the revision by the UN Secretariat.
1 6 9 11 52 70
PART 5 UNITED NATIONS DIRECTORIES FOR ELECTRONIC DATA INTERCHANGE
FOR ADMINISTRATION, COMMERCE AND TRANSPORT
Chapter 1 Introduction CONTENT{T}.{YY}{V}
Chapter 2 Message type directory (XXMD) {XX}MD.ZIP(l)
1. Indexes
l.l Index of message types by code {XX}MDIl.{YY}{V}
1.2 Index of message types by name {XX}MDI2.{YY}{V}
2. Message type specifications xxxxxx_{T}.{YY}{V}
(xxxxxx = message type; for example,
INVOIC {T}.{YY}{V} contains the
specification for the invoice message)
Chapter 3 Message frameworks(XXFR) {XX}FR.ZIP(l)
1. Indexes
1.1 Index of framework types by code {XX}FRIl.{YY}{V}
1.2 Index of framework types by name {XX}FRI2.{YY}{V}
2. Framework type specifications
Chapter 4 Segment directory (XXSD) {XX}SD.ZIP(1)(3)
1. Indexes
l.l Index of segments by tag {XX}SDIl.{YY}{V}
1.2 Index of segments by name {XX}SDI2.{YY}{V}
2. Segment specifications {XX}SD.{YY}{V}
Chapter 5 Composite data element directory (XXCD) {XX}CD.ZIP(1)(4)
1. Indexes
1.1 Index of composites by tag {XX}CDIl.{YY}{V}
1.2 Index of composites by name {XX}CDI2.{YY}{V}
2. Composite specifications {XX}CD.{YY}{V}
Chapter 6 Data element directory (XXED) {XX}ED.ZIP(1)(5)
1. Indexes
1.1 Index of data elements by tag {XX}EDIl.{YY}{V}
1.2 Index of data elements by name {XX}EDI2.{YY}{V}
2. Data element specifications {XX}ED.{YY}{V}
Chapter 7 Code lists (UNCL) UNCL.ZIP(1)
1. Code lists UNCL-1.{YY}{V}
UNCL-2.{YY}{V}
2. Service code lists UNSL.ZIP(1)
UNSL.{YY}{V}
The second page of the table of contents contains the following
information :
The values to be replaced are the same as for the first page of the
table of contents.
After the table of contents, there follows a page of standard text
which contains the notes referring to the numbers found in brackets
against certain sections of the table of contents.
1 70
NOTES:
(1) Each .ZIP file expands when "unzipped" (following the instructions
in the README.TXT file) to become the files listed underneath with the
exception of all CONTENT{T}.{YY}{V} references. These are found in
this file (below).
(2) Under development.
(3) Chapter 4 of Part 5 does not include service segments (tags
beginning with UN) defined in ISO 9735 (the EDIFACT syntax). Version
control of these service control segments is reflected in data element
0002 in segment UNB and is based on changes to ISO 9735. Therefore the
usual UN/EDIFACT directory version/release control for UN/EDIFACT
messages (using data elements 0052 and 0054 in segments UNH and UNG)
is NOT applicable to those segments.
(4) Chapter 5 of Part 5 does not include service composite data
elements (the "Sxxx" series) which are defined in ISO 9735 (the
EDIFACT syntax). Version control for these data components is
reflected in data element 0002 in segment UNB and is based on changes
to ISO 9735. Therefore the usual UN/EDIFACT directory version/release
control for UN/EDIFACT messages (using data elements 0052 and 0054 in
composites S008 and S009) is NOT applicable to those composite data
elements.
(5) Chapter 6 of Part 5 does not include service data elements (the
"0xxx" series) which are defined in ISO 9735 (the EDIFACT syntax).
Version control for these data elements is reflected in data element
0002 in segment UNB and is based on changes to ISO 9735. Therefore the
usual UN/EDIFACT directory version/release control for UN/EDIFACT
messages (using data elements 0052 and 0054) is NOT applicable to
those data elements.
UNSL.{YY}{V}
The standard text is shown in the following diagram :
The fields {T}, {YY} and {V} contain the values as described on the
first page of the table of contents.
3.1.4. Introduction to PART 5 of the UN/EDIFACT directories.
1 70
PART 5 UNITED NATIONS DIRECTORIES FOR ELECTRONIC DATA INTERCHANGE
FOR ADMINISTRATION, COMMERCE AND TRANSPORT
CHAPTER 1 Introduction
This Part 5 of the UN/EDIFACT directories shall in each successive
issue include: For Standard directories:
all unchanged, changed and new UN Standard Message Types (UNSMs
and UNSM Frameworks and their supporting directories agreed for
public use by UN/ECE/TRADE/Working Party 4.
For Draft directories:
all unchanged, changed and new UN Standard Message Types (UNSMs
and UNSM Frameworks and their supporting directories agreed for
public use by UN/ECE/TRADE/Working Party 4
plus
all new, unchanged and changed UN message types and frameworks
with a status of Draft Recommendation as well as their
supporting directories, as approved by WP.4.
In the Standard Directories, UNSMs are specified in the chapter EDMD,
supporting segments in EDSD, composite data elements in EDCD, data
elements in EDED and code lists in UNCL.
In the Draft Directories, UNSMs (Status 2) and Draft Recommendation
messages(Status 1) are specified in chapter TRMD, supporting segments
in TRSD, composite data elements in TRCD, data elements in TRED and
code lists in UNCL.
Additions, changes and deletions in a new issue will be marked in
reference to the previous issue for the type of directory in question.
For example: additions in a Standard directory will be marked in
reference to the last Standard directory.
The data element part of the UN Trade Data Element Directory (UNTDED),
of which EDED (the Data element directory within the Standard
directory) is an excerpt in condensed form, is also ISO standard 7372
for which there is a UN/ECE-ISO agreement for the Maintenance Agency,
ISO 7372 MA.
The complete contents of the current directory, as well as the
diskette files in which this information can be found, are listed in
the table of contents in the diskette file CONTENT{T}.{YY}{V}.
The standard text for the introduction to part 5 of the UN/EDIFACT
directories is shown in the following diagram :
The fields {T}, {YY} and {V} contain the values as described on the
first page of the table of contents.
4. MESSAGE TYPE DIRECTORY
4.1. Message type directory index.
The message type directory index comes in two forms which have exactly
the same layout. One index is sorted by message type and the other is
sorted by message name. The layout for the index is as follows :
1 4 6 11 25 58 67 70
PART 5 UNITED NATIONS DIRECTORIES FOR ELECTRONIC DATA INTERCHANGE
FOR ADMINISTRATION, COMMERCE AND TRANSPORT
CHAPTER 2 Message type directory ({xx}MD)
1. Indexes
1.{S}Index of message types by {sort criteria}
Change indicators
a plus sign (+) for an addition
an asterisk (*) for an amendment to structure
a vertical bar (|) for changes to text for descriptions,
notes and functions
a minus sign (-) for a deletion
a X sign (X) for marked for deletion
Code Name Status Rev
+ APERAK Application error and acknowledgement message 1 1
* AUTHOR Authorization message 1 2
* BANSTA Banking status message 1 2
BAPLIE Bayplan/stowage plan occupied and empty 2 2
locations message
BAPLTE Bayplan/stowage plan total numbers message 2 2
BOPBNK Bank transactions and portfolio transactions 1 1
report message
BOPCUS Balance of payment customer transaction 1 2
report message
BOPDIR Direct balance of payment declaration message 1 1
BOPINF Balance of payment information from customer 1 1
message
+ CALINF Call info message 1 1
The value for {xx} shall be "TR" for the draft directory and "ED" for
the standard directory.
The value for {sort criteria} shall be "code" when the index is sorted
by the message type and shall be "name" when the index is sorted by
message name.
The value for {S} is "1" for the index sorted by code and "2" for the
index sorted by name.
A change indicator may be provided in column one opposite the message
it affects.
On magnetic media the index which is sorted by name is placed on a
separate file. This file does not contain the title information which
are shown at the top of the sample page. It starts with the title "1.2
Index of message types by name" beginning in column 1 of the first
line.
The rules for the change indicators are as follows:
"+" New message added in this release.
"*" Message structure changed in this release. A change to
the message structure is defined as any change which has
been made to the segment table.
"|" Changes have been made to sections 1, 2, 3, and 4.1 in
this release based on textual change requested by a DMR
and which does not affect the segment table.
"-" Message has been deleted in this release.
"X" The message has been marked for deletion.
4.2. REQUIREMENTS FOR ALL MESSAGE BOILERPLATE TEXT
Every UN/EDIFACT message is published as a separate document.
On magnetic media each message can be found on a separate file which
shall be identified by its message type, the underline character
("_"), followed by "D" for a draft directory message or "S" for a
standard directory message, followed by a file extension which
indicates the version number (e.g. 95A). An example of a complete
message file name is "INVOIC_D.95A".
4.3 Message boilerplate cover pages
4.3.1. Status 0 messages :
On the cover page of a status O message boilerplate, the following
information shall be supplied :
1) The message name shall correspond to that submitted for the
code list of Data Element 1000.
2) The message type shall correspond to that submitted for the
code list of Data Element 0065.
3) The value after "Release" {N} is a sequential number beginning
with 1 and corresponding to the number of times this status 0
documentation has been revised. See TRADE/WP.4/R.982 for
further explanation.
4) after "Date", the YY-MM-DD shall be replaced with the date of
preparation by the UN Secretariat.
5) after "SOURCE", the field {FTX} shall be replaced with:
the name of Rapporteurs Board eventually followed by the
identification of specific message design group
responsible for the message (example : "Western Europe
EDIFACT Board - MD1").
4.3.2. Status 1 and status 2 messages in the draft directory:
On the cover page of the message boilerplate, the following
information shall be supplied :
1) The message name corresponds to that of Data Element 1000.
2) The message type corresponds to that of Data Element 0065.
3) The version (data element 0052) and release (data element 0054)
contents are to be determined based on the version/release
procedures approved by WP.4.
4) The value of the status {S} shall be 1 for a status 1 message
and 2 for a status 2 message.
5) The revision number {X} is a number incremented in conformance
with TRADE/WP.4/R.982 by the UN Secretariat.
6) after "Date", the YY-MM-DD shall be replaced with the date of
preparation.
7) after "SOURCE", the field {FTX} shall be replaced with:
for joint development:
"Joint Rapporteurs Message Design Group JMXXX", where XXX
is the number of the joint development team,
for non-joint development:
the name of Rapporteurs Board eventually followed by the
identification of specific message design group
responsible for the message (example : "Western Europe
EDIFACT Board - MD1").
4.3.3. Status 2 messages in the standards directory.
On the cover page of the message boilerplate, the following
information shall be supplied :
1) The message name corresponds to that of Data Element 1000.
2) The message type corresponds to that of Data Element 0065.
3) The version (data element 0052) and release (data element 0054)
contents are to be determined based on the version/release
procedures approved by WP.4.
4) The revision number {X} is a number incremented in conformance
with TRADE/WP.4/R.982 by the UN Secretariat.
5) after "Date", the YY-MM-DD shall be replaced with the date of
preparation.
6) after "SOURCE", the field {FTX} shall be replaced with:
for joint development:
"Joint Rapporteurs Message Design Group JMXX", where XX is
the number of the joint development team,
for non-joint development:
the name of Rapporteurs Board eventually followed by the
identification of specific message design group
responsible for the message (example : "Western Europe
EDIFACT Board - MD1").
7) Status 2 messages only may appear in a Standard directory
4.4. Message table of contents
4.4.1. Status 0 message boilerplate table of contents
All the sections outlined in the table of contents shall be used with
the exception of the following :
1. Sections 4.1.1, 4.1.2, and 4.1.3 only appear in the table of
contents if an equivalent header, detail or summary section
appear in the message design.
2. If a header, detail, summary breakdown is not used in the
message design then no sub-division of section 4.1 shall occur.
3. Section 4.3.2 shall be used only if a branching diagram has
been produced in the printed documentation.
4. Sections 5.2.1, 5.2.2, and 5.2.3 shall be provided only if a
change is required to the segment, composite or data element
directories for the message.
5. Any changes which are required in the supporting directories
shall be individually requested on separate Data Maintenance
Requests.
6. The Annex shall be used only if supporting examples of the
messages are provided.
4.4.2. Status 1 and status 2 message boilerplate table of contents
All the sections outlined in the table of contents shall be used with
the exception of the following :
1. Sections 4.1.1, 4.1.2, and 4.1.3 only appear in the table of
contents if an equivalent header, detail or summary section
appear in the message design.
2. If a header, detail, summary breakdown is not used in the
message design then no sub-division of section 4.1 shall occur.
3. Section 4.3.2 shall be used only if a branching diagram has
been produced in the printed documentation.
4.5. Introduction, section 0 and section 1 of the message boilerplate.
1. All section numbers shall begin in column 1.
2. Column 6 may contain the change indicator "|" to indicate a change
in the content of a section. It can only appear in column 6 of the
lines containing the section numbers "0", "1.1", "1.2", and "1.3".
It should be noted that currently sections "0" and "1.2" may not
be changed.
3. All text for each of the above sections shall begin in column 8
and may continue on a line up to and including column 70.
4. All text indicated in these sections, other than those contained
between "[]" and "{}" is mandatory and shall not be modified.
5. [1000] shall be replaced by the name of the message as found in
the EDIFACT code list for data element 1000.
6. [0065] shall be replaced by the six character acronym for the
message as found in the EDIFACT code list for data element 0065.
7. {text supplied by the user} in section 1.1 provides the functional
definition of the message as provided by the message designers.
8. {text supplied by the user} in section 1.3 provides the principles
by which the message is to be used as supplied by the message
designers.
4.6. Section 2 and section 3 of the message boilerplate.
1 6 8 70
2. REFERENCES
See UNTDID, Part 4, Chapter 2.6 UN/ECE UNSM - General
Introduction, Section 1.
3. TERMS AND DEFINITIONS
See UNTDID, Part 4, Chapter 2.6 UN/ECE UNSM - General
Introduction, Section 2.
1. All section numbers shall begin in column 1.
2. Column 6 may contain a change indicator "|" to indicate a change
in the textual content of the sections. It can only be placed in
column 6 of the line containing the text "2. REFERENCES" or the
line containing the text "3. TERMS AND DEFINITIONS". It should be
noted that currently these sections may not be changed.
3. All text for each of the above sections shall begin in column 8
and may continue on a line up to and including column 70.
4. All text indicated in these sections is mandatory and may not be
modified.
4.7. Section 4 of the message boilerplate.
1 6 8 70
4. MESSAGE DEFINITION
4.1 Data Segment Clarification
This section should be read in conjunction with the Branching
Diagram and the Segment Table which indicate mandatory,
conditional and repeating requirements.
{text supplied by the user}
4.1.1 Header section
Information to be provided in the Header section:
0010 UNH, Message header
A service segment starting and uniquely identifying a message.
The message type code for the [1000] is '[0065]'.
Note: [l000]s conforming to this document must contain the
following data in segment UNH, composite S009:
Data element 0065 [0065]
0052 [0052]
0054 [0054]
0051 [0051]
{segment and segment group clarification supplied by the user}
4.1.2 Detail Section
Information to be provided in the Detail section:
{segment and segment group clarification supplied by the user}
4.1.3 Summary section
Information to be provided in the Summary section:
{segment and segment group clarification supplied by the user}
AAAA UNT, Message trailer
A service segment ending a message, giving the total number of
segments in the message and the control reference number of the
message.
4.7.1. Section 4.1 (Data segment clarification)
The following list of requirements shall be considered as a generic
implementation guideline:
A) For each segment, the line identifying the segment shall respect
the following format:
AAAA C STG, DDD..DD
1 6 8 13
Where:
AAAA is the segment position indicator, and shall
always begin in column 1. The segment position
indicator shall begin with the value "0010"
against the "UNH" segment clarification section.
It shall be incremented by 10 for each of the
following segments or segment groups.
C is a permitted change indicator, which is provided
when required. It shall always begin in column 6.
STG is the segment tag, level 0 segment tags shall
begin in column 8. Segment tags which are
contained in a segment group shall be indented 3
spaces from the start position of the segment
group tag. The Segment tag is always followed
immediately by a comma.
DDD..DD is the segment name and shall begin in the
sixth character position after the start position
of the segment tag.
(refer to the UNH segment definition in the diagram for
a model).
B) For each segment group, the line identifying the segment group
shall respect the following format in a similar manner to the segment
identification line :
AAAA C Segment Group EE: SSS-...-SSS-SGhh-...-SGhh
Where:
AAAAis the segment group position indicator, and shall
always begin in column 1. Its value depends on the
relative position of the segment group from the
UNH segment.
C is a permitted change indicator, which is provided
when required. It shall always begin in column 6.
Segment Group EE is the segment group identification,
where "EE" corresponds to the segment group
number. Level 1 segment groups shall always begin
in column 8. All dependent segment groups shall be
indented 3 spaces from the start position of the
parent segment group identification. The segment
group identification is always immediately
followed by a colon.
SSS-...-SSS is the list of the segment tags immediately
dependent on the segment group. The list respects
the order in which the segments appear. Each
segment tag is separated by a hyphen.
SGhh-...-SGhh is the list of segment groups immediately
dependent on the segment group being described.
Each segment group shall be identified with the
characters "SGhh" where "hh" represent the number
of the segment group in question. The list
respects the order in which the segment groups
appear. Each segment group is separated by a
hyphen.
The segment list and segment group list may be
intermingled as dictated by the message structure.
Segment tags are separated from segment group tags
by a hyphen.
If the list of segments and segment groups exceeds
the 70th character in a line, it shall be
terminated by a hyphen and the list continued on
the following line directly under the list on the
preceding line.
C) The use of all segments and segment groups shall be explained in
the order they appear in the message;
D) The explanatory text for a segment or a segment group shall begin
on a new line directly under the start position of the segment or
segment group tag to which it refers.
E) The explanation of a segment or segment group contained within a
parent segment group shall be indented by three space characters from
the start position of its parent segment group.
F) Before each segment there shall be 1 blank line and before each
Segment group there shall be 2 blank lines.
G) The text for the service segments UNH and UNT is standard.
H) The values of data elements 1000 and 0065 which apply to the
message being described shall be used in the standard explanation of
the UNH segment.
I) The values for data elements 0065, 0052, 0054 and 0051 in the note
under the UNH segment explanation shall be assigned according to the
message status (0, 1 or 2) and in conformity with TRADE/WP.4/R.982.
J) The introductory text for sections 4.1.1, 4.1.2, and 4.1.3 shall be
used whenever a message is designed using header, detail or summary
sections.
Please refer to the following example for further clarification of the
above mentioned rules.
1 6 8 11 70
0040 + BUS, Business function
A segment identifying certain characteristics of the Banking
Status message, such as its business function.
0050 | Segment group 1: RFF-DTM
A group of segments identifying a previously-sent message,
and/or customer to customer reference and related dates.
0060 RFF, Reference
A segment specifying the reference of the previously-sent
message.
0070 DTM, Date/time/period
A segment identifying the creation date of the referenced
message.
0080 + Segment group 2: FII-CTA-COM
A group of segments identifying the financial institutions
involved in the Banking Status message, routing functions and
contacts.
0090 + FII, Financial institution information
A segment identifying the financial institution(s)
associated with the transaction, in coded or uncoded form
and their function.
0100 + CTA, Contact information
A segment identifying a person or a department for the party
specified in the leading FII segment to whom communication
should be directed.
0110 + COM, Communication contact
A segment identifying communication type(s) and number(s) of
person(s) or department(s) specified in the associated CTA
segment.
Changes to the documentation section 4.1 of a message shall use the
following indications in column 6 :
a plus sign (+) to indicate the addition of a segment or a
segment group to the segment table.
a vertical bar (3) to indicate a change to the explanatory
text of a segment or of a segment group or
to indicate a change in the content of a
segment group (i.e. the addition or
deletion of a segment or a segment group
within the segment group in question).
The indicators are placed in column 6
immediately before the segment tag or the
segment group tag concerned by the change.
4.7.2. Section 4.2 (Data segment index)
The list of segments shall show all the segments used in the message
sorted alphabetically by tag.
1 8 11 15 70
4.2 Data segment index (Alphabetical sequence by tag)
AUT Authentication result
BGM Beginning of message
BUS Business function
CNT Control total
COM Communication contact
CTA Contact information
CUX Currencies
DOC Document/message details
DTM Date/time/period
FII Financial institution information
FTX Free text
GIS General indicator
+ LIN Line item
MOA Monetary amount
NAD Name and address
PCD Percentage details
RFF Reference
SEQ Sequence details
UNH Message header
UNT Message trailer
In this section, the only indicator which may be used is the plus sign
(+) to indicate the addition of a segment to the segment list which
did not previously figure in the list.
4.7.3. Section 4.3.1 (Segment table)
All layouts for the Segment table shall correspond to the following
example :
1 6 8 12 18 54 58 70 Column
numbers
A) The status of segment or a segment group shall be either "C" for
conditional, or "M" for mandatory.
B) The number of repetitions shall be left justified beginning in
column 58.
C) The only indicators which may be used are :
ú The plus sign (+) to indicate the addition of a segment
or segment group.
ú The asterisk (*) to indicate a change in the structure
of a segment group or a change in the status or the number of
repetitions of a segment or a segment group.
A change in the structure of a segment group is defined as the
addition or suppression of a segment or a segment group, the
modification in the number of repetitions or status of the segment
group itself, or a modification in the number of repetitions or status
of a directly dependent segment or segment group.
4.7.4. Section 4.3.2. (Branching diagram)
The UN currently has not the capability to reproduce branching
diagrams. They consequently will be treated as optional, and will not
be included in any versions of the directories distributed on
electronic media. If they are to be presented in the paper
documentation they must be supplied in camera ready copy.
Branching diagrams shall conform to the presentation provided in ISO
9735.
4.7.5. Section 5 (Status 0 messages only).
1 8 70
5. DIRECTORIES
5.1 Directory references
{XXXXXXXX} directory [0052].[0054]
5.2 Explanation of directory variations
5.2.1 Segment variations
{new or modified segment definitions}
5.2.2 Composite variations
{new or modified composite data elements}
5.2.3 Data element variations
{new or modified data element requests}
A) {XXXXXX} shall be replaced with the words "Standard" or "Draft" in
conformity with the value entered in [0052] which indicates the status
of the directory set used as reference.
B) The value [0054] will comply with the revision of the directory set
used as reference.
C) Sections 5.2.1, 5.2.2 and 5.2.3 shall be formatted in compliance
with the format of the segment, composite and data element supporting
directories respectively. (Refer to sections 5, 6, and 7).
4.7.6. Annex (Status 0 messages only).
The Annex shall only be used for status 0 messages to contain an
example of the proposed message. Its structure shall be defined by the
message designers.
5. SEGMENT DIRECTORY
.
5.1. Segment directory index.
The segment directory index comes in two forms which have exactly the
same layout. One index is sorted by segment tag and the other is
sorted by segment name. The layout for the index is as follows :
1 4 6 10 11 25 70
PART 5 UNITED NATIONS DIRECTORIES FOR ELECTRONIC DATA INTERCHANGE
FOR ADMINISTRATION, COMMERCE AND TRANSPORT
CHAPTER 4 Segment directory ({XX}SD)
1. Indexes
1.{S} index of segments by {sort criteria}
Change indicators
a plus sign (+) for an addition
an asterisk (*) for an amendment to structure
a hash sign (#) for changes to names
a vertical bar (|) for changes to text for descriptions,
notes and functions
a minus sign (-) for a deletion
a X sign (X) for marked for deletion
Tag Name
AGR Agreement identification
AJT Adjustment details
ALC Allowance or charge
ALI Additional information
- API Additional price information
| APR Additional price information
ARD Amounts relationship details
+ ARR Array information
+ ASI Array structure identification
The value for {xx} shall be "TR" for the draft directory and "ED" for
the standard directory.
The value for {sort criteria} shall be "tag" when the index is sorted
by the segment tag and shall be "name" when the index is sorted by
segment name.
The value for {S} is "1" for the index sorted by tag and "2" for the
index sorted by name.
Up to two change indicators may be provided in columns one and two
respectively against a segment. The change indicators that figure in
this list correspond to those which figure against the segments in the
segment directory. There is only one exception to this rule and that
concerns a segment which has been deleted from the segment directory.
It no longer figures in the directory but it is flagged with the
change indicator "-" in the index.
On magnetic media the index which is sorted by name is placed on a
separate file. This file does not contain the title information which
are shown at the top of the sample page. It starts with the title "1.2
Index of segments by name" beginning in column 1 of the first line.
5.2. Segment directory specifications
The segment specification for each segment shall be defined in the
following manner :
1 5 6 7 14 25 60 63 70
2. Segment specifications
Change indicators
a plus sign (+) for an addition
an asterisk (*) for an amendment to structure
a hash sign (#) for changes to names
a vertical bar (|) for changes to text for descriptions,
notes and functions
a minus sign (-) for a deletion
a X sign (X) for marked for deletion
ŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽ
| AGR AGREEMENT IDENTIFICATION
Function: To specify the agreement details.
010 C543 AGREEMENT TYPE IDENTIFICATION C
7431 Agreement type qualifier M an..3
7433 Agreement type, coded C an..3
1131 Code list qualifier C an..3
3055 Code list responsible agency, coded C an..3
7434 Agreement type description C an..70
020 9419 SERVICE LAYER, CODED C an..3
AJT ADJUSTMENT DETAILS
Function: To identify the reason for an adjustment.
Note: This is a note on a specific requirement of a segment.
010 4465 ADJUSTMENT REASON, CODED M an..3
020 1082 LINE ITEM NUMBER C n..6
The change indicator is placed in column 5 if there is only one. For
two change indicators columns 4 and 5 shall be used. The change
indicators may appear against the segment tag, the function, any
eventual note, and the composite or elementary data elements.(Note :
these indications, with the exception of the indication "marked for
deletion", are kept local to the directory and do not permiate
throughout the directories).
The specific meaning of the change indicators within the segment
directory is as follows :
"+" :This signifies that a segment has been added to the directory
and is indicated immediately before the segment tag. It can also
be used to indicate the addition of an simple data element or a
composite data element to an existing segment in which case it
is indicated immediately before the data element tag which has
been added.
"*" :This sign is used to indicate that a data element (simple or
composite) has been added to or suppressed from the segment. It
is also used if a data element within the segment has been
marked for deletion or if the status of a data element within
the segment has changed. The sign is marked immediately before
the segment tag and immediately before the simple or composite
data elements if there is a change of status.
"|" :This sign is used to indicate changes in the functional
description and note sections of a segment. If such a case
occurs then the vertical bar is marked immediately before the
segment tag as well as immediately before the section modified.
"#" :The hash sign is used to indicate a change in the name of the
segment. If such a case occurs then the hash sign is marked
immediately before the segment tag.
"X" :The X sign is used to indicate segments which have been marked
for deletion after an interval of three years. At the end of the
three year period, the segments so marked will be automatically
deleted from the directories. (The X sign should be permiated
throughout the different directories to ensure that all effected
information is identified) The X is marked immediately before
the segment tag.
If a data element has been marked for deletion in the ED or CD
an X sign shall be marked before the data element tag in the
segment.
The position indicator in column 1 starts at 10 and is incremented by
10 for every composite and simple data element in the segment.
The status shall be "M" for mandatory components of the segment and
"C" for conditional components of the segment. The component data
elements within a composite must indicate the same status as found in
the composite directory.
The format representation shall conform to the specification in ISO
9735.
The segment, data element and composite data element names shall use
only capital letters. Component data element names shall only have the
first letter of the name in capitals.
There should be one blank line between each data element and composite
data element, but no blank lines between component data elements or
between a component data element and the composite data element to
which it belongs.
If the functional description exceeds 53 characters then it should be
continued on the following line in column 17.
In a similar manner if a note exceeds 63 characters then it should be
continued on the following line in column 17.
If the names of the data elements in the segment exceed 46 characters
they shall be continued on the following line in column 14.
6. COMPOSITE DATA ELEMENT DIRECTORY
6.1. Composite directory index.
The composite directory index comes in two forms which have exactly
the same layout. One index is sorted by composite tag and the other is
sorted by composite name. The layout for the index is as follows :
1 4 6 10 11 25 70
PART 5 UNITED NATIONS DIRECTORIES FOR ELECTRONIC DATA INTERCHANGE
FOR ADMINISTRATION, COMMERCE AND TRANSPORT
CHAPTER 5 Composite data element directory ({XX}CD)
1. Indexes
1.{S}Index of composites by {sort criteria}
Change indicators
a plus sign (+) for an addition
an asterisk (*) for an amendment to structure
a hash sign (#) for changes to names
a vertical bar (|) for changes to text for descriptions,
notes and functions
a minus sign (-) for a deletion
a X sign (X) for marked for deletion
Tag Name
C002 Document/message name
C040 Carrier
C045 Bill level identification
C056 Department or employee details
C058 Name and address
C059 Street
C076 Communication contact
+ C077 File identification
C078 Account identification
+ C079 Computer environment identification
C080 Party name
The value for {xx} shall be "TR" for the draft directory and "ED" for
the standard directory.
The value for {sort criteria} shall be "tag" when the index is sorted
by the composite tag and shall be "name" when the index is sorted by
composite name.
The value for {S} is "1" for the index sorted by tag and "2" for the
index sorted by name.
Up to two change indicators may be provided in columns one and two
respectively against a composite data element. The change indicators
that figure in this list correspond to those which figure against the
composites in the composite data element directory. There is only one
exception to this rule and that concerns a composite which has been
deleted from the composite data element directory. It no longer
figures in the directory but it is flagged with the change indicator "-
" in the index.
On magnetic media the index which is sorted by name is placed on a
separate file. This file does not contain the title information which
are shown at the top of the sample page. It starts with the title "1.2
Index of composites by name" beginning in column 1 of the first line.
6.2. Composite data element directory specifications
The composite specification for each composite data element shall be
defined in the following layout and content :
1 5 6 7 14 25 60 63 70
2. Composite specifications
Change indicators
a plus sign (+) for an addition
an asterisk (*) for an amendment to structure
a hash sign (#) for changes to names
a vertical bar (|) for changes to text for descriptions,
notes and functions
a minus sign (-) for a deletion
a X sign (X) for marked for deletion
* C002 DOCUMENT/MESSAGE NAME
Desc: Identification of a type of document/message by code or
name. Code preferred.
010 1001 Document/message name, coded C an..3
020 1131 Code list qualifier C an..3
030 3055 Code list responsible agency, coded C an..3
040 1000 Document/message name C an..35
C040 CARRIER
Desc: Identification of a carrier by code and/or by name. Code
preferred.
Note: This is a specific note for the composite.
010 3127 Carrier identification C an..17
020 1131 Code list qualifier C an..3
030 3055 Code list responsible agency, coded C an..3
040 3128 Carrier name C an..35
The change indicator is placed in column 5 if there is only one. For
two change indicators columns 4 and 5 shall be used. The change
indicators may appear against the composite tag, the description, any
eventual note, and the component data elements.(Note : these
indications, with the exception of the indication "marked for
deletion", are kept local to the directory and do not permiate
throughout the directories).
The specific meaning of the change indicators within the composite
directory is as follows :
"+" :This signifies that a composite data element has been added to
the directory and is indicated immediately before the composite
data element tag. It can also be used to indicate the addition
of a component data element to an existing composite data
element in which case it is indicated immediately before the
component data element tag which has been added.
"*" :This sign is used to indicate that a component data element has
been added to or suppressed from the composite data element . It
is also used if a component data element within the composite
data element has been marked for deletion or if the status of a
component data element within the composite data element has
changed. The sign is marked immediately before the composite
data element tag and before the component data element tag if
there is change of status.
"|" :This sign is used to indicate changes in the description and
note sections of a composite data element. If such a case occurs
then the vertical bar is marked immediately before the composite
data element tag as well as immediately before the section
modified.
"#" :The hash sign is used to indicate a change in the name of the
composite data element. If such a case occurs then the hash sign
is marked immediately before the composite data element tag or
before the component data element tag if it changes status.
"X" :The X sign is used to indicate composite data elements which
have been marked for deletion after an interval of three years.
At the end of the three year period, the composite data elements
so marked will be automatically deleted from the directories.
(The X sign should be permiated throughout the different
directories to ensure that all effected information is
identified) The X is marked immediately before the composite
data element tag.
If a component data element has been marked for deletion in the
ED an X sign shall be marked immediately before the component
data element tag in the composite.
The position indicator in column 1 starts at 10 and is incremented by
10 for every component data element in the composite.
The status shall be "M" for mandatory components of the composite and
"C" for conditional components of the composite.
The format representation shall conform to the specification in ISO
9735.
If the names of the component data elements in the composite exceed 46
characters they shall be continued on the following line in column 14.
The composite data element name shall use only capital letters.
Component data element names shall only have the first letter of the
name in capitals.
If the functional description exceeds 57 characters then it should be
continued on the following line in column 13.
In a similar manner if a note exceeds 57 characters then it should be
continued on the following line in column 13.
7. DATA ELEMENT DIRECTORY
7.1. Data element directory index.
The data element directory index comes in two forms which have exactly
the same layout. One index is sorted by data element tag and the other
is sorted by data element name. The layout for the index is as follows
:
1 4 6 10 11 25 70
PART 5 UNITED NATIONS DIRECTORIES FOR ELECTRONIC DATA INTERCHANGE
FOR ADMINISTRATION, COMMERCE AND TRANSPORT
CHAPTER 6 Data element directory ({XX}ED)
1. Indexes
1.{S}Index of data elements by {sort criteria}
Change indicators
a plus sign (+) for an addition
an asterisk (*) for an amendment to structure
a hash sign (#) for changes to names
a vertical bar (|) for changes to text for descriptions,
notes and functions
a minus sign (-) for a deletion
a X sign (X) for marked for deletion
Tag Name
1000 Document/message name
| 1001 Document/message name, coded
1004 Document/message number
1049 Message section, coded
1050 Sequence number
1052 Message item number
1054 Message sub-item number
+ 1056 Version
+ 1058 Release
+ 1060 Revision number
The value for {xx} shall be "TR" for the draft directory and "ED" for
the standard directory.
The value for {sort criteria} shall be "tag" when the index is sorted
by the data element tag and shall be "name" when the index is sorted
by data element name.
The value for {S} is "1" for the index sorted by tag and "2" for the
index sorted by name.
Up to two change indicators may be provided in columns one and two
respectively against a data element. The change indicators that figure
in this list correspond to those which figure against the data
elements in the data element directory. There is only one exception to
this rule and that concerns a data element which has been deleted from
the data element directory. It no longer figures in the directory but
it is flagged with the change indicator "-" in the index.
On magnetic media the index which is sorted by name is placed on a
separate file. This file does not contain the title information which
are shown at the top of the sample page. It starts with the title "1.2
Index of data elements by name" beginning in column 1 of the first
line.
7.2. Data element directory specifications
The data element specification for each data element shall be defined
in the following layout and content :
1 4 6 10 25 70
2. Data element specifications
Change indicators
a plus sign (+) for an addition
an asterisk (*) for an amendment to structure
a hash sign (#) for changes to names
a vertical bar (|) for changes to text for descriptions,
notes and functions
a minus sign (-) for a deletion
a X sign (X) for marked for deletion
1000 Document/message name
Desc: Plain language identifier specifying the function of a
document/message.
Repr: an..35
| 1001 Document/message name, coded
Desc: Document/message identifier expressed in code.
Repr: an..3
| Note: Users should note that code values marked as additions or
changes are included pending approval by the 1001 Maintenance
Agency and may be dissaproved or changed. The results of this
review will be reflected in a future version of the draft
directory.
The change indicator is placed in column 1. For successive change
indicators columns 2 and 3 shall be used. The change indicators may
appear against the data element tag, the description, any eventual
note, and the representation of the data element.(Note : these
indications, with the exception of the indication "marked for
deletion", are kept local to the directory and do not permiate
throughout the directories).
The specific meaning of the change indicators within the data element
directory is as follows :
"+" :This sign signifies that a data element has been added to the ED
directory and is placed immediately before the data element tag.
"*" :This sign is used to indicate that a change has occurred in the
representation of the data element and is placed immediately
before the data element tag.
"|" This sign is used to identify changes in the description and
note sections of a data element. If such a case occurs then the
vertical bar is marked immediately before the data element tag
as well as immediately before the section changed.
"#" The hash sign is used to indicate a change in the name of the
data element. If such a case occurs then the hash sign is marked
immediately before the data element tag.
"X" The X sign is used to indicate data elements which have been
marked for deletion after an interval of three years. At the end
of the three year period, the data elements so marked will be
automatically deleted from the directories. (The X sign should
be permiated throughout the different directories to ensure that
all effected information is identified) The X is marked
immediately before the data element tag.
The format representation shall conform to the specification in ISO
9735.
The data element name shall use only capital letters.
If the name of the data element or the functional description exceeds
60 characters then it should be continued on the following line in
column 10.
In a similar manner if a note exceeds 60 characters then it should be
continued on the following line in column 10.
8. CODE LISTS
8.1. Code list directory specifications
The code list specification for each data element shall be defined in
the following layout and content :
1 3 6 9 11 25 70
PART 5 UNITED NATIONS DIRECTORIES FOR ELECTRONIC DATA INTERCHANGE
FOR ADMINISTRATION, COMMERCE AND TRANSPORT
CHAPTER 7 Code lists (UNCL and UNSL)
1. Code lists
Change indicators
a plus sign (+) for an addition
an asterisk (*) for an addition/subtraction/change to a entry
for a particular data element
a hash sign (#) for changes to names
a vertical bar (|) for changes to text for descriptions,
notes and functions
a minus sign (-) for a deletion
a X sign (X) for marked for deletion
* 1001 Document/message name, coded
Desc: Document/message identifier expressed in code.
Repr: an..3
1 Certificate of analysis
Certificate providing the values of an analysis.
2 Certificate of conformity
Certificate certifying the conformity to predefined
definitions.
3 Certificate of quality
Certificate certifying the quality of goods, services
etc.
4 9
* 1153 Reference qualifier
Desc: Code giving specific meaning to a reference segment or a
reference number.
Repr: an..3
AAA Acknowledgement of order number
[1018] Reference number assigned by the seller to his
acknowledgement of an order.
AAB Proforma invoice number
[1088] Reference number assigned by the seller to a
Proforma Invoice.
AAC Documentary credit number
[1172] Reference number assigned by issuing bank to a
Documentary credit.
AAD Contract addendum number
[1318] Reference number assigned by the issuer to a
Contract Addendum.
AAE Goods declaration number
Reference number assigned to a goods declaration.
The change indicator is placed in column 1. For successive change
indicators columns 2 and 3 shall be used. The change indicators may
appear against the data element tag and the code value of the data
element.(Note : these indications, with the exception of the
indication "marked for deletion", are kept local to the directory and
do not permiate throughout the directories).
The specific meaning of the change indicators within the code list
directory is as follows :
"+" :This sign is used to indicate the addition of a coded data
element to the directory and is marked immediately before the
coded data element tag. it may also be used to indicate the
addition of a coded value to an existing coded data element in
which case the sign is marked immediately before the coded value
added.
"*" :This sign is used to indicate that a coded value has been added
to or suppressed from the coded data element. It is also used if
a coded value within the coded data element has been marked for
deletion or the name or description of the a coded value has
been changed. The sign is marked immediately before the coded
data element tag.
"|" :This sign is used to indicate a change in the text of a
description of a coded value. It is marked immediately before
the coded value tag in question.
"#" :The hash sign is used to indicate a modification to the name of
a coded value. The sign is marked immediately before the coded
value tag in question.
"-" :The minus sign is not used in this directory.
"X" :The X is used to indicate coded values which have been marked
for deletion after an interval of three years. At the end of the
three year period the coded values so marked will be
automatically deleted from the directory. The X marker should
only appear immediately before the coded value tag to be
deleted.
Numeric codes in a code list shall be right aligned from column 9 all
other codes shall left aligned from column 4.
Code lists published by UN/EDIFACT using this layout cannot be more
than 6 characters in length.
A coded data element which does not have a code list shall not appear
in the code list directory.
Note :
The service code lists shall respect exactly the same layout rules as
the UN/EDIFACT code lists.
ANNEXES
Annex 1 Allowed character sets
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII¯
§ 3 ! 3 " 3 # 3 $ 3 % §
§ 32 3 33 3 34 3 35 3 36 3 37 §
§ŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽ§
§ 3 ! 3 " 3 ) 3 * 3 + §
§ 38 3 39 3 40 3 41 3 42 3 43 §
§ŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽ§
§ , 3 - 3 . 3 / 3 0 3 1 §
§ 44 3 45 3 46 3 47 3 48 3 49 §
§ŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽ§
§ 2 3 3 3 4 3 5 3 6 3 7 §
§ 50 3 51 3 52 3 53 3 54 3 55 §
§ŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽ§
§ 8 3 9 3 : 3 ; 3 < 3 = §
§ 56 3 57 3 58 3 59 3 60 3 61 §
§ŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽ§
§ > 3 ? 3 @ 3 A 3 B 3 C §
§ 62 3 63 3 64 3 65 3 66 3 67 §
§ŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽ§
§ D 3 E 3 F 3 G 3 H 3 I §
§ 68 3 69 3 70 3 71 3 72 3 73 §
§ŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽ§
§ J 3 K 3 L 3 M 3 N 3 O §
§ 74 3 75 3 76 3 77 3 78 3 79 §
§ŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽ§
§ P 3 Q 3 R 3 S 3 T 3 U §
§ 80 3 81 3 82 3 83 3 84 3 85 §
§ŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽ§
§ V 3 W 3 X 3 Y 3 Z 3 [ §
§ 86 3 87 3 88 3 89 3 90 3 91 §
§ŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽ§
§ \ 3 ] 3 ^ 3 _ 3 ` 3 a §
§ 92 3 93 3 94 3 95 3 96 3 97 §
§ŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽ§
§ b 3 c 3 d 3 e 3 f 3 g §
§ 98 3 99 3 100 3 101 3 102 3 103 §
§ŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽ§
§ h 3 i 3 j 3 k 3 l 3 m §
§ 104 3 105 3 106 3 107 3 108 3 109 §
§ŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽ§
§ n 3 o 3 p 3 q 3 r 3 s §
§ 110 3 111 3 112 3 113 3 114 3 115 §
§ŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽ§
§ t 3 u 3 v 3 w 3 x 3 y §
§ 116 3 117 3 118 3 119 3 120 3 121 §
§ŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽŽ§
§ z 3 { 3 | 3 ) 3 ~ 3 _ §
§ 122 3 123 3 124 3 125 3 126 3 127 §
EIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII¬
ISO 8859-1 G0 set
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII¯
§ 3 3 ¨ 3 U 3 A 3 Ž §
§ 179 3 191 3 217 3 193 3 196 §
EIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII¬
Allowed IBM graphic characters
NOTE : such characters can be printed from the WINDOWS environment
using the MS-Linedraw fonte.
Annex 2 Data elements used in layouts
TAG NAME FORMAT
0051 Controlling agency an..2
0052 Message version number an..3
0054 Message release number an..3
0065 Message type an..6
1000 Document, message name an..35
Annex 3 Recommended evolutions.
The following evolutions have been identified and have not been
examined in detail :
1. R1023 specifies uniquely an annex which may contain an example for
status 0 messages. This annex is apparently not allowed for status
1 and 2 messages. Currently annexes appear in the messages
containing such things as syntactic notes, informative information
on message structure evolution, etc...
No rules exist for these annexes and consequently they cannot be
verified.
It is proposed to address this problem and suggest evolutions in
this area to bring some coherence into the message boilerplates in
this area.
2. It is necessary to review the method employed in identifying
message evolution. Currently, no satisfactory method exists in
this area and it is necessary to examine in a serial manner each
directory index in order to determine the evolution of a given
directory. For example, one cannot determine the evolution which
occurred between the directory D.93A and the directory D.95B
without going through each intermediate directory.
3. The use of the change indicators for section 4.3 of the message
boilerplate is unsatisfactory. It is proposed to identify an
evolution in this area which will enable easier manipulation and
readability.
4. It is proposed to rationalise the change indicators throughout the
directories so that only one indicator can be found against an
element at any given time. This is connected to point 2 and will
be rationalised within that context.
5. A method will have to be found to eliminate the use of the five
IBM characters which cause interoperability problems.
6. It is proposed to incorporate the conventions for assigning new
code values into the document in order to permit an easy means of
bringing together everything which is used to control DPT and DAT
validations. Other documents or usages might be brought in at this
level in order to formalise their use.
7. It appears that branching diagrams find favour with most message
designers. We recommend studying the possibility of incorporating
these into messages as a standard feature.
8. It is proposed to study the possibility of evolving the magnetic
media support to more uptodate techniques.
9. It is proposed to study the evolution of this document towards
becoming the implementation guidelines for the DIRDEF message in
order to ensure the unicity of maintanance of both documents.
|
