Message Design

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 redundancy.

requirements

with

the

minimum

of

complexity

and

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 or

their

requirements,

addition

to

the

in

which

relevant

case

UNSM,

they

which

can

will

request be

a

passed

change to

the

appropriate message design group(s). 2.3.3 If no such message exists, they may then submit a "New UNSM Request"

covering

submitted

to

the

the

function

local

RT

they

require,

Secretariat

for

which

must

be

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. |

+----------------+

^

|

|

|

|

|

+----------------+

|

|

|

|

|

|

+----------------+

|

|

| Composite Data |

|

|

|

|

|

|

+----------------+

|

|

| Data Elements

|

MESSAGES Segments

Elements

|

|

+----------------+

|

|

|

|

|

V

+----------------+

|

3.2

Code Lists

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

ascertain

of

whether

the

message

the

under

required

development,

data

elements

designers

are

included

need

to

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

procedures

user's should

requirement, be

the

followed,

to

Rappor-teur request

an

Change amendment

Request to

the

element in question, or 3)

If

the

Request"

required

must

be

data

element

submitted

is

under

not

found

a

"New

the

Rapporteur

Data

Change

Element 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

5284

Unit price basis

(where n..9

Format tag 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:

where

Data Element

Data element name

Format tag

6063

Quantity qualifier

an..3

an..3

characters)

means

variable

length

alphanumeric

containing

1

to

3

The

qualifier

qualified.

code For

values

give

example,

the

precise list

meaning

includes

a

to

the

code

data

of

being

"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

shall

be

preference to creating new data elements. RULE

2:

The

following

naming

and

formatting

conventions

followed in the UN/EDIFACT data elements directory: a)

A

data

composite,

element or

which

segment

"Currency qualifier").

qualifies shall

end

a

generic

with

the

simple

name

data

element,

"qualifier"

The format of qualifiers shall be: an..3.

(e.g. 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 elements 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

3.3.2

Composite Data Element Request" must be submitted.

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

Description of type of service

of composite :

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

identify its function. Example: Composite name :

PERCENTAGE DETAILS

Function of composite :

Identification of the usage of a percentage

Components in the composite : Percentage qualifier;

to

Percentage; Percentage basis, coded The specific percentage (and if appropriate,the percentage basis) is identified

according

to

(Percentage qualifier.)

the

value

of

the

1 - Allowance; 2 - Charge; PERCENTAGE

percentage details

qualifier

The values of the "Percentage qualifier" are

listed in the UN/EDIFACT codes lists directory.

A

composite

DETAILS

For example:

etc. composite

carrying

"Allowance"

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 component

data

element

relating

directly

to

the

function

each

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:

contents

New of

composite an

data

existing

elements

composite,

shall nor

not

shall

contain the

the

function

entire 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