|
ISO
TC154-UN/CEFACT Joint Syntax Working Group (JSWG):
6. TRANSMISSION COMPONENTS
An interchange of data in the context of EDIFACT, is composed of one or more messages containing segments which in turn are made up of data elements.
6.1 Data Elements
(NOTE: It is stressed that all the examples of data which follow in this paper are examples. UNTDED should be studied to obtain the current formats, code set and qualifier values, etc).
A data element may consist of a single data item, e.g. "2310 Delivery month" in which case it is called a simple data element, or it may consist of several data items, e.g. the composite data element "C198 PRODUCT IDENTIFICATION" which consists of two data elements, 7020 Article Number and 7823 Article Number Qualifier. In this case it is called a composite data element; each data item within a composite data element is called a component data element.
A component is identified by its position within a data element. For example, if a data element was required to express the cost of insurance, it would be defined as a composite data element with two component data elements. In the first position would be "5486 Insurance Cost", accompanied by "6345 Currency Code" as the second component.
The data elements referred to in the EDIFACT standard are either user data elements or service data elements.
User data elements contain the substantive data which are to be transmitted. They are outside the scope of the standard and should be defined and agreed (preferably based on the UN trade data element directory - TDED) between interchange partners, and specified in a user data element directory.
Service data elements contain data required for structuring the transmission. A list of the service data elements provided in this standard and their detailed descriptions are given in the UN Trade Data Element Directory (TDED), in the 'S' and the '000' series. They will also be found in ISO 9735.
Data elements can only be transmitted within a segment.
Each data element in TDED is allocated a unique 4-digit numeric tag. In addition, each data element is allocated a unique and mnemonic four-character data element identifier which must be alphabetic. These identifiers can be used in internal systems, e.g. for system and programming documentation.
6.2 Segments
There are two types of segments: User Data segments and Service segments. Conditional Segments containing no data must be omitted from the message in which they would normally appear.
User data segments contain data elements such as amounts, values, names, places and other data to be transmitted. The contents of user data segments are outside the scope of the UN/EDIFACT Syntax standard. User data segments must not be created with the first two letters of the tag "UN", as these are reserved for use in service segments.
Service segments contain service data elements such as sender of the transmission, syntax rules type and level, date of the preparation of the transmission, priority type, etc. and/or other specific data which are required for the transmission. All service segment tags start with the two letters "UN" which are reserved for this purpose. On no account should users change service segments. A "Change Request" procedure is described in the Message Design Guidelines for the purpose of proposing amendments. The following categories of service segments are provided in the UN/EDIFACT syntax standard:
Transmission structuring syntax segments, which are used to assemble transmissions in a standard way, e.g. to start and end each transmission, to start and end each message within a transmission, and to start and end functional groups of messages within a transmission (if this facility is required).
Segments used in the Service messages "CONTRL" & "APPLIC", which respectively are used for acknowledgements requests, for correction of syntax errors and rejections, and for confirmation of receipt or requests for correction of application errors. (The latter - APPLIC - is under development).
A segment used in the General Purpose Message "GENRAL", which is used to indicate the type, title and references for the message.
Segments are identified by a code which uniquely identifies each segment as specified in a segment directory.
A list of the service segments provided in the EDIFACT syntax standard, with detailed descriptions, is given in Annex B of ISO 9735.
6.3 Messages
A Message consists of a number of segments structured in accordance with the syntax rules. It must begin with the service segment "UNH -Message header" and end with the service segment "UNT - Message trailer". It must contain at least one user data segment, containing at least one user data element.
There are two classes of messages: User messages and EDIFACT Service messages.
User messages contain the user data segments required for the message in addition to the "Message header" and "Message trailer" segments.
There is an option to transfer a message progressively. At the time of the first transmission, it generally would not contain all of the information as defined in the interchange application message specifications, other than the data defined as being mandatory within the message. In this case, the originator may transmit a selection of the data elements at first, followed by a second (or successive) transmission(s), adding to or updating the data previously transmitted, the data being related by means of a structured, unique key.
(An example might be a Booking message, where the transport operator needs a rough estimate of the space required for the shipment as early as possible to facilitate his planning. The precise details may be supplied by the originator later as they become available, until finally the transport operator has sufficient data to create a bill of lading).
The use of the progressive message transfer technique is explained in more detail in Section 8.3.9 of this guide.
UN/EDIFACT Service messages contain service segments for error correction, either at the syntax protocol level, or at the application level, and service segments for general free text. Their use is explained in Section 10 of this guide.
Messages are uniquely identified by a message identifier field consisting of five component data elements, used to effect identification and control of messages, as explained in the next Section.
ANNEX C (Informative)
ORDER OF SEGMENTS AND GROUPS OF SEGMENTS WITHIN A MESSAGE The
segments used in a message shall appear in the sequence (top to bottom, left to
right) specified in the Message Diagram. Segments are indicated by their codes.
The requirement for their inclusion in the message, i.e. their status, is
indicated directly below the codes by the letter M for mandatory or C for
conditional. The number of times a segment may appear in each instance is
indicated directly thereafter. A mandatory segment shall appear at least once
but not more times than indicated. A conditional segment may be excluded or
appear up to the number of times indicated. When a segment nests in an other
segment, it shall be placed on the next lower level in the diagram. Segments in
level zero shall not be repeated and shall not contain nested segments. Two or
more segments can be grouped. This is indicated by a box in the diagram. The
group and the segments in the box can be mandatory or conditional and can appear
up to the number of times indicated. A group can contain another, lower level
group or groups (Gr.3 and Gr.4 in the example). A message shall begin with the
message header segment UNH and end with the message trailer segment UNT. EXAMPLE:
Parts of a fictitious message type:
Level
___________________________________________________________
| | | | | | | |
0 UNH AAA | | | | | UNT
M 1 M 1 | | _______________ | _______ | M 1
1 BBB CCC | DDD | HHH | III | LLL
C10 C10 | M 1 | C 5 | M 1 | C 5
| | | |__ __|
| ___________ | || | ||
| | | | | || | ||
2 |EEE FFF GGG| || | ||
|C10 C 5 C 5| ||JJJ||
|_____________| ||M 1||
|Group 1 C 200| || | ||
|_____________| || | ||
|| | ||
Segment Group 1 || | ||
3 Conditional ||KKK||
Repeatable up ||C 1||
to 200 times ||___||
||Gr3||
||C10||
||___||
|_____|
Segment Group 3 |Gr.4 |
inside Group 4 |C 10 |
|_____|
Segments may alternatively
be represented as follows:
_____
|UNH|
|___|
|M|1|
|___|
The processing/sequencing order of the segments is as follows
(Group 1 appearing twice, the other groups once and segments
not repeated):
UNH,AAA,BBB,CCC,DDD,EEE,FFF,GGG,DDD,EEE,FFF,GGG,HHH,..,III,JJJ,KKK,..
.,LLL,UNT
CHAPTER 2.4 - UN/EDIFACT Message Design Guidelines
http://www.unece.org/trade/untdid/texts/d424_d.htm
4.1.3 Branching diagrams and segment tables are graphic techniques
for indicating the logical structure of a message. Their func-
tion is to present a message diagramatically, from which the
order and relationship of segments and segment groups within
a message can be determined, including their mandatory or con-
ditional status. The diagram defines the transmission order
of the segments as top to bottom and left to right. The
following diagram is for illustration only, to explain the
basic concepts of a branching diagram and a segment table.
4.1.4 An example of a branching diagram is:
Level Message Type
_________________________________________
| | | | | | |
0 UNH AAA BBB | EEE | UNT
M 1 M 1 C 1 | C 1 | M 1
| |
| |
+----+ |
|Gp.1| |
|C 9| |
|____| |
1 |CCC | FFF
|M 1| C 9
+----+
|
|
2 DDD
C 9
4.1.5 As can be seen in the above diagram, "Levels" are shown for each
level of nesting of segments in a message. Segments appearing
at Level 0 shall not repeat. For each level of segment nesting,
the level numbers are incremented by 1.
4.1.6 Example of a segment table is:
TAG NAME S REPT S REPT
UNH Message header M 1
AAA Segment AAA M 1
BBB Segment BBB C 1
- Segment Group 1 ----------------------------- C 9 ---+
CCC Segment CCC M 1 |
DDD Segment DDD C 9 -----------------+
EEE Segment EEE C 1
FFF Segment FFF C 9
UNT Segment UNT M 1
4.1.7 For the above message structure, assuming that all of the
conditional segments in the diagram appear once, and that Group
1 appears twice, the processing sequence of the segments would
be as follows:
UNH, AAA, BBB, CCC, DDD, CCC, DDD, EEE, FFF, UNT.
4.1.8 In the above message structure, the first and last segments in
the message, UNH and UNT, are mandatory Service Segments, de-
fined in the UN/EDIFACT Syntax. UNH is the message header
segment, which includes the message type, version and release
number, while UNT is the message trailer segment. The remaining
segments (with segment codes AAA to FFF) are user data segments.
4.1.9 Associated with each segment tag in the examples is shown either
"M" (if the segment is Mandatory within the message), or "C" (if
the segment is Conditional), followed by a number, meaning the
following:
M l means that the segment must appear once only in
the message in the position shown in the diagram.
C l means the segment may appear once only in the
message in the position shown in the diagram
(dependent if necessary on a semantic note related
to the segment) or that it can be completely omitted.
M followed by a figure greater than 1 means that the
segment must appear at least once in the position shown,
but could repeat up to a maximum number of times equal to
the figure shown.
C followed by a figure greater than 1 means that the
segment may repeat in the position shown, up to a
maximum number of times equal to the figure shown,
OR--because of its Conditional status--that it may not
appear at all.
Exactly the same concept applies to segment groups in respect
to their status and their number of repeats.
4.2 Guidelines for the Design of Segment Groups
4.2.1 A study of Status 2 messages in UNTDID will show that messages
often contain a high proportion of conditional segment groups.
This decision is often taken by message designers to permit
flexibility of use.
4.2.2 Grouping of segments also permits information carried in
individual segments to be related in a structured way.
4.2.3 The first segment of a group must occur only once per occurrence
of the group. and is designated as the "trigger" segment for the
group which it heads. The trigger segment determines the func-
tion of the group.
4.2.4 Message designers should be aware, that a segment group which is
contained within another segment group cannot be entered, other
than via the segment group immediately before (its parent seg-
ment group). This means that at least the trigger segment for
the parent segment group must contain data when transmitted.
4.2.5 In the message example given in 4.1.4, Group 1 (containing
segments CCC and DDD) shows a simple repeating structure. Up to
a maximum of 9 occurrences of the group may appear, or the group
may be omitted since its is conditional. Within each occurrence
of the group, the trigger segment CCC must appear (since it is
mandatory). Segment DDD may be omitted since it is conditional,
or may repeat a maximum of 9 times. A group of segments can,
and often does, contain one or more lower level groups of
segments.
4.2.6 A fuller description of the hierarchical dependency of segments
in groups appearing at levels l, 2, 3, etc., repeating segments
and their representation implicitly or explicitly etc., can be
found in ISO 9735.
4.2.7 As draft messages are developed, designers may find that they
may have to amend some of their original thoughts on the struc-
ture and contents of the message as this can be an iterative
process.
4.2.8 A typical example of a segment group used in the same way across
many messages is the "Name and Address", segment group which
optionally includes segments to provide related "Contact" &
"Communication Number" data. This segment group normally
follows a structure where NAD is the trigger segment for group,
with the dependent CTA and COM segments below.
4.3 Rules for Segment Groups Design
RULE 30: Every group shall start with a non-repeating mandatory
segment.
RULE 31: A segment group nested within another segment group shall be
headed by its own trigger segment, and cannot be entered
other than via the group which precedes it.
|
|
|