GENERAL GUIDELINES FOR MESSAGE DESIGN

2. GENERAL GUIDELINES FOR MESSAGE DESIGN

2.1 The Building Blocks of Messages

2.1.1 The basic "building blocks" of messages are:

1) data elements for use in segments, or as

components of composite data elements;
2) composite data elements;
3) segments (which can be used individually, or as
part of segment groups within a message), and
4) the structure of the message itself, detailing the order of
segments and/or segment groups.

2.2 Design of New UN/EDIFACT Messages - UNSMS

2.2.1 The objective of the design process is to meet genuine data

interchange requirements with the minimum of complexity and
redundancy. The aim should be to:
- support a well-defined and understood business need;
- be comparatively simple (in terms of function and design), and
- avoid unnecessary emulation of paper-based procedures;
2.2.2 The current UN/EDIFACT Working Directory should be used to review
existing messages and segments, and utilised as a starting point in
developing a new message.
2.2.3 Messages and segments should allow for multi-sectoral
applications rather than a single, confined usage.
2.2.4 Simplicity is a major objective in message design. Over-
complication creates difficulties in comprehension, especially for new
users. Messages should not be made more complex to save a few
characters in transmission.

2.3 Requests for New UNSMS or for Changes to Existing UNSMS

2.3.1 If a group of users need an EDI message covering international
requirements, they should first check whether a UNSM exists which has
been designed for the function in question—perhaps from which a sub-set
can be taken.
2.3.2 If one does exist, they may then find that it does not totally
meet their requirements, in which case they can request a change
or addition to the relevant UNSM, which will be passed to the
appropriate message design group(s).
2.3.3 If no such message exists, they may then submit a "New UNSM
Request" covering the function they require, which must be
submitted to the local RT Secretariat for processing under RT
procedures.

2.4 Before Designing a New Message

2.4.1 The following describes a step by step approach to message

design.
Step Action
1. Analyse business requirements for all relevant
communications with business partners.
2. Model the key aspects of the business environment.
3. Identify the EDI messages which are needed to satisfy the required
business function. Verify if messages already exist in the current
UN/EDIFACT Working Directory which should be used or amended.
4. Select the highest priority message for development,and define the
"Business Function" for the message.

If at this stage it is decided that a new UNSM is

required, a "New UNSM Request" form must be prepared and submitted
immediately to the relevant RT Secretariat for expedient processing.
5. Determine the detailed business data needs.
6. Select segments from the current UN/EDIFACT Working
Directory and review segment groups already specified for use in other
UNSMs to meet the requirements for each entity identified.
7. i) Identify the data items not covered by existing UN/EDIFACT
segments;
ii) determine whether the requirements for these data items can be
met by requesting additional qualifier values for use in existing
generic segments. If not,check whether they are already defined in the
current UN/EDIFACT Working Data Elements Directory or in the Trade Data
Elements Directory (UNTDED). If not, then submit a Change Request for
a new data element;
iii) determine whether the requirements for these data items can
now be met by adding them to the end of an existing UN/EDIFACT segment
or composite having the correct function in the current Working
Directory;
iv) classify any remaining data items into conceptually related
sets, providing a functional description for each set for the creation
of a new segment to meet each function, and
v) determine the mandatory or conditional status for each data
element, composite, segment, segment group and the number of permitted
repeats.

SECTION 3

DESIGN OF THE COMPONENT PARTS OF A MESSAGE

3. DESIGN OF THE COMPONENT PARTS OF A MESSAGE

3.1 Interchange Structure & Directory Relationships

3.1.1 Informative Annex C demonstrates the hierarchical structure of

a UN/EDIFACT message.
3.1.2 To support this hierarchical structure, within the UN/EDIFACT
process, five directories are held in UNTDID between all of which there
is both an upward and downward hierarchical relationship.
| +----------------+ ^
| | MESSAGES | |
| +----------------+ |
| | Segments | |
| +----------------+ |
| | Composite Data | |
| | Elements | |
| +----------------+ |
| | Data Elements | |
 | +----------------+ |
| | Code Lists | |
V +----------------+ |

3.2 Design of Data Elements

3.2.1 Guidelines for data element design

3.2.1.1 If a new data element has to be designed it should be generic,

allowing for use across the widest possible number of applications.
3.2.1.2 Having identified all of the data elements required tosatisfy
the function of the message under development, designers need to
ascertain whether the required data elements are included in the
current UN/EDIFACT Working Directory, by taking the following steps:
Search the current UN/EDIFACT Working Directory:
1) If the required data element is found and exactly meets the user's
requirement, it should be specified for use;
2) If the required data element is found, but it appears that its
name, description and/or its format/representation does not exactly
meet the user's requirement, the Rappor-teur Change Request
procedures should be followed, to request an amendment to the
element in question, or
3) If the required data element is not found a "New Data Element
Request" must be submitted under the Rapporteur Change Request
procedures, with reference to UNTDED as necessary.
In the case of coded data elements:
1) If the required coded data element is found and the required code
value is present in its associated code list,then the element should be
specified for use;
2) If the required coded data element is found, but the required code
value is not present, a "New Code Request" should be submitted, or
3) If a "New Data Element Request" has been submitted for a coded
element, a code request for each code value required for the data
element must be submitted.

3.2.2 Data element types and categories

3.2.2.1 A data element is the smallest unit of information within the
structure of a message and there are two types, a simple data element,
and a component data element used in Composite Data

Elements (see Section 3.3)

3.2.2.2 A simple data element can be one of three categories:
1) Where it defines a precise business function, it is termed a
specific simple data element. In tag, name and format order, an example
could be:

Data Element Data element name Format tag

5284 Unit price basis n..9

(where n..9 means variable length numeric containing 1 to 9 digits)

2) Where it defines a global business function which could be used
across the widest range of functional/industry area, it is termed a
generic simple data element.
An example of such a generic simple data element could be:

Data Element Data element name Format tag

6064 Quantity difference n..15

(where n..15 means variable length numeric containing 1 to 15 digits)

On its own, "quantity difference" has no specific meaning. In order to

identify its precise business function, a data element qualifier is
associated with it.
3) Where it gives a generic simple data element a precise business
function, it is termed a data element qualifier.
An example of a data element qualifier could be:
Data Element Data element name Format tag

6063 Quantity qualifier an..3

where an..3 means variable length alphanumeric containing 1 to 3

characters)
The qualifier code values give precise meaning to the data being
qualified. For example, the list includes a code of "126" for
"Quantity of goods that disappeared in transport" which, combined with
the Quantity difference, gives explicit meaning to the number contained
in the Quantity difference.
3.2.2.3 A component data element is one which is used within acomposite
data element (see Section 3.3). A component element can be one of the
three categories defined above for simple data elements.

3.2.3 Rules for the design of new data elements

RULE 1: Existing qualified data elements shall always be used in

preference to creating new data elements.
RULE 2: The following naming and formatting conventions shall be
followed in the UN/EDIFACT data elements directory:
a) A data element which qualifies a generic simple data element,
composite, or segment shall end with the name "qualifier" (e.g.
"Currency qualifier"). The format of qualifiers shall be: an..3. The
code lists for quali-fiers shall be specified in EDCL only.
b) A non-qualifier coded data element name shall end with " , coded"
(e.g. "Currency, coded"). The format of non-qualifier coded data
elements shall be: an..3
c) Other coded data element names shall end with "identification" (e.g.
"Hazard code identification")
The format of other coded data elements shall be:

an..x (where x > 3)

d) Clear (plain language) data elements already specified in UNTDED

shall adopt the same name and format in UNTDID.
e) A new clear language data element not already specified in UNTDED
shall have a format of either an..17, an..35 or an..70, along with its
corresponding name, as dictated by business requirements.
f) The format and naming of other types of data elements shall be
specified to meet business requirements.

3.2.4 Coded data elements

3.2.4.1 A coded data element is an element which has as its value a
code, described in a Code Lists directory.
3.2.4.2 There are two types of UN/EDIFACT coded data elements: those
which are qualifiers; and other coded data elements.

3.2.5 Rules associated with the design of coded data elements

RULE 3: Coded data elements which are qualifiers shall not have data
elements 1131/3055 associated with them.
RULE 4: Generic coded simple data elements shall be specified in a
composite data element in conjunction with conditional data elements
1131/3055.

3.3 Design of Composite Data Elements

3.3.1 Guidelines for composite data element design

3.3.1.1 A composite data element is two or more component data ele-

ments grouped together to permit related information to be expressed in
a structured way.
3.3.1.2 The composite data element directory contained in the current
UN/EDIFACT Working directory should be studied to identify composite
specification/layout.
3.3.1.3 One type of design of composites is where the composite itself
is mandatory and all of its components are conditional. At least one
of the components must be present under ISO 9735 Syntax Rules.

3.3.1.4 When deciding on the composite data elements required in a

message under development, designers need to ascertain whether all of
the required composite data elements are already defined in the current
UN/EDIFACT Working Directory, by taking the following steps:
Search the current UN/EDIFACT Working Directory:
1) If the required composite data element is found and exactly meets
the user's requirement, it should be specified for use.
2) If the required composite data element is found, but it appears that
its name, description and/or its format/ epresentation does not exactly
meet the user's requirement, the Rapporteur Change Request procedures
should be followed, to request an amendment to the composite in
question.
3) If the required composite data element is not found in the current
Working Directory, then using the Rapporteur Change Request procedures,
a "New Composite Data Element Request" must be submitted.

3.3.2 Guidelines for the design of non-qualified and qualified

composites

3.3.2.1 A non-qualified composite is one which has a single function

needing no qualification.
Example:

Composite name : MOVEMENT TYPE

Function of composite : Description of type of service

for movement of cargo.

Components in the composite : Movement type, coded;

Movement type

The above composite could then take the form:

...+[Movement type, coded]:[Movement type]+...

3.3.2.2 A qualified composite is one which needs a qualifier to

identify its function.
Example:

Composite name : PERCENTAGE DETAILS

Function of composite : Identification of the usage

of a percentage

Components in the composite : Percentage qualifier;

 Percentage;

Percentage basis, coded

The specific percentage (and if appropriate,the percentage basis) is

identified according to the value of the composite qualifier
(Percentage qualifier.) The values of the "Percentage qualifier" are
listed in the UN/EDIFACT codes lists directory. For example:

1 - Allowance; 2 - Charge; etc.

A PERCENTAGE DETAILS composite carrying "Allowance"
percentage details would take the form:

+1:[Percentage]+

3.3.2.3 The use of qualified composites significantly reduces the

number of entries in the Composite Data Elements Directory,and provides
flexibility. For example, if the need for a new "percentage details"
composite function is identified, all that is required is the addition
of a further qualifier code in the relevant code list.

3.3.3 Rules for the design of composite data elements

RULE 5: Composite data element shall have a single function, with each
component data element relating directly to the function of the
composite.
RULE 6: A composite data element shall comprise two or more component
data elements. Pairs or triplets of associated components shall not be
repeated within a composite.
RULE 7: Composite data elements contained in the current UN/EDIFACT
Composite Data Elements Working Directory shall be used,unless it is
demonstrated that the required function cannot be achieved either by:
- the addition of a new qualifier value to an existing qualified
composite, or by the addition of a composite data element qualifier.
- the addition of a component data element at the end of an existing
composite (except as defined in Rule 16).
RULE 8: New composite data elements shall not contain the entire
contents of an existing composite, nor shall the function of an
existing composite be duplicated.
RULE 9: New composite data elements shall be designed to support the
widest possible number of applications.
RULE 10: A qualifier giving specific meaning to a generic simple data
element shall be placed directly after the data element. Both elements
then become component data elements of a composite data element.

The following examples explain the position and use of such a

qualifier within a composite:

...+QDE:Q+... where:

QDE - Qualified data element as a component in a composite

Q - Qualifier as a component in a composite