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 2.2.4 users. Messages Simplicity Messages and is a segments major not should allow in more for multi-sectoral design. to save Overa few applications rather than a single, confined usage. objective be made message complex complication creates difficulties in comprehension, especially for new should 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 addition requirements, to the in which case they can request be passed a change to the relevant UNSM, which will

appropriate message design group(s). 2.3.3 If no such message exists, they may then submit a "New UNSM Request" submitted procedures. covering to the the local function RT they require, for which must under be RT Secretariat processing

2.4
2.4.1

Before Designing a New Message
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) segments; ii) determine whether the requirements for these data items can be met by requesting additional qualifier values for use in existing Identify the data items not covered by existing UN/EDIFACT

generic segments.

If not,check whether they are already defined in the If not, then submit a Change Request for

current UN/EDIFACT Working Data Elements Directory or in the Trade Data Elements Directory (UNTDED). 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) repeats. determine the mandatory or conditional status for each data element, composite, segment, segment group and the number of permitted

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

| | V

+----------------+ | Code Lists | +----------------+

| | |

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 the message under data development, elements designers included need in to the ascertain whether required are

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) meet If the required data element is found, but it appears that its the user's should requirement, be data followed, element the to is Rappor-teur request not the found an a Change amendment "New Data Request to the name, description and/or its format/representation does not exactly procedures 3) If the

element in question, or required be Element Request Request" must submitted under Rapporteur Change

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 5284 (where n..9 Data element name Unit price basis 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 6064 Data element name Quantity difference Format tag 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 6063 where an..3 means Data element name Quantity qualifier variable length Format tag an..3 containing 1 to 3

alphanumeric

characters)

The

qualifier

code For

values

give the

precise list

meaning a

to code

the of

data

being for

qualified.

example,

includes

"126"

"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 RULE a) A 1: 2: Existing The qualified data elements shall always be used shall in be

preference to creating new data elements. following naming and formatting a generic the conventions simple data followed in the UN/EDIFACT data elements directory: data element or which qualifies shall end element, (e.g. The composite, segment with name "qualifier"

"Currency qualifier").

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

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 Composite Data Element Request" must be submitted.

3.3.2

Guidelines composites

for

the

design

of

non-qualified

and

qualified

3.3.2.1 A non-qualified composite is one which has a single function needing no qualification. Example: Composite name : Function of composite : MOVEMENT TYPE 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 : Function of composite : PERCENTAGE DETAILS 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 For example: qualifier (Percentage qualifier.) The values of the "Percentage qualifier" are

listed in the UN/EDIFACT codes lists directory. 1 - Allowance; 2 - Charge; A PERCENTAGE DETAILS percentage details 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 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). data element relating directly to the function of each the

RULE

8:

New of

composite an

data

elements

shall nor

not

contain the

the

entire of an

contents

existing

composite,

shall

function

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

Sign up to vote on this title
UsefulNot useful