un/edifact syntax, part 1, syntax rules common to all parts

TRADE/WP.4/R.1241page 1


ISO 9735-1

Release 21996-07-05

Electronic data interchange for administration,commerce and transport (EDIFACT) - Application levelsyntax rules

Part 1:Syntax rules common to all parts, together with syntaxservice directories for each of the parts


Contents

Page

Foreword 4

Introduction 5

1 Scope 7

2 Conformance 7

3 Normative references 7

4 Definitions 8

5 Service characters 8

6 Character repertoires 9

7 Syntax structures 9

8 Inclusion and exclusion 11

9 Suppression of characters within data elements 14

10 Representation of numeric data element values 15

11 Dependency notes 16

Annex A: Definitions 18

Annex B: UNA service string advice 23

Annex C: Syntax service directories (segments, composite dataelements and simple data elements) 24

Annex D: Syntax service code directory 63

Annex E: Order of segments and groups of segments within amessage 93


Foreword

(To be amended as necessary, according to ISO procedures)

ISO (the International Organization for Standardization) is a worldwide federation of nationalstandards bodies (ISO member bodies). The work of preparing International Standards isnormally carried out through ISO technical committees. Each member body interested in asubject for which a technical committee has been established has the right to be represented onthat committee. International organizations, governmental and non-governmental, in liaison withISO, also take part in the work. ISO collaborates closely with the International ElectrotechnicalCommission (IEC) on all matters of electrotechnical standardization.

Draft International Standards adopted by the technical committees are circulated to the memberbodies for approval before their acceptance as International Standards by the ISO Council. Theyare approved in accordance with ISO procedures requiring at least 75% approval by the memberbodies voting.

International Standard ISO 9735 Release 2 was prepared by the UN/ECE Trade Division (asUN/EDIFACT) and was adopted, under the "fast-track procedure" as an existing standard, byTechnical Committee ISO TC 154, Documents and data elements in administration; commerceand industry.

ISO/IEC 9735 consists (currently) of the following parts, under the general title Electronic datainterchange for administration, commerce and transport (EDIFACT) - Application level syntaxrules:

ISO 9735-1 - Syntax rules common to all parts, together with syntax service directoriesfor each of the parts

ISO 9735-2 - Syntax rules specific to batch EDI

ISO 9735-3 - Syntax rules specific to interactive EDI

ISO 9735-4 - Syntax and service report message for batch EDI (message type -CONTRL)

ISO 9735-5 - Security rules for batch EDI (authenticity, integrity and non-repudiation oforigin)

ISO 9735-6 - Secure authentication and acknowledgement message (message type -AUTACK)

ISO 9735-7 - Security rules for batch EDI (confidentiality)

ISO 9735-8 - Associated data in EDI

ISO 9735-9 - Security key and certificate management message (message type -KEYMAN)


Further parts may be added in the future.In this Part, annexes A, B and C form an integral part of this International Standard.Annexes D and E are for information only.

Introduction

This International Standard includes the rules at the application level forthe structuring of data in the interchange of electronic messages in anopen environment, based on the requirements of either batch orinteractive processing. These rules have been agreed by the UnitedNations Economic Commission for Europe (UN/ECE) as syntax rules forElectronic Data Interchange for Administration, Commerce and Transport(EDIFACT) and are part of the United Nations Trade Data InterchangeDirectory (UNTDID) which also includes both batch and interactiveMessage Design Guidelines.

These syntax rules may be used in any application, but messages usingthese rules may only be referred to as EDIFACT messages if they complywith other guidelines, rules and directories in the UNTDID. ForUN/EDIFACT, messages shall comply with the message design rules forbatch or interactive usage as applicable. These rules are maintained inthe UNTDID.

Communications specifications and protocols are outside the scope of thisstandard.

Previous versions of ISO 9735 were specified as a single part. Thisversion of ISO 9735 consists of multiple parts and incorporatesenhancements to extend the application of this International Standard.

This part of ISO 9735 is a re-draft of corresponding sections in theprevious version of ISO 9735. It consists of the rules common to all partsof ISO 9735, and includes the definitions and service directories for allparts.

The basic syntax rules specified in this part remain unchanged from theprevious version, with the exception that the coverage of characterrepertoires has been extended, and two new techniques have beenintroduced (the provision for 'dependency notes' and the introduction of aservice repetition character, to support the capability of permitting multipleoccurrences (repeats) of stand-alone and/or composite data elements).Both of these techniques are used in other parts of this version of ISO9735, and are available for specification in EDIFACT messages whichutilise this International Standard.

In addition, enhancements have been made to the batch interchange;group; and message header segments (UNB; UNG; and UNH).


Character repertoires: Because of the widening use of ISO 9735, it hasbecome necessary to extend its coverage to include all characterrepertoires covered by ISO 8859 Parts 1-9; the code extension techniquescovered by ISO 2022 (with certain restrictions on its use within aninterchange); and partial use of the techniques covered by ISO 10646-1.

Dependency notes: These provide a formal notation to expressrelationships in EDIFACT message, segment and composite data elementspecifications.

Repeating data elements: The specification of multiple occurrences of amessage within a group or within an interchange; a group within aninterchange; and a segment group and/or a segment within a message,which existed in the previous version of ISO 9735, has been extended inthis version. The additional capability for the specification of multipleoccurrences of a stand-alone data element and/or of a composite dataelement within a segment has been introduced.

UNB - Interchange header segment: This segment has been enhanced topermit the identification of the service code list directory version number;identification of the character encoding scheme; and internalsub-identification of the sender and recipient.

UNG - Group header segment: This segment has been re-named and itsfunction changed to permit one or more message types and/or packagesto be contained in the group. As a result, certain data elements which arenow redundant, have been marked for deletion.

UNH - Message header segment: This segment has been enhanced topermit the identification of a message subset; of a related messageimplementation guideline; and of a related scenario.

Electronic data interchange for administration, commerce andtransport (EDIFACT) - Application level syntax rules


Part 1:Syntax rules common to all parts, together with syntax servicedirectories for each of the parts

1 Scope

This part of ISO 9735 specifies common syntax rules for the formatting of batch and interactive messagesto be interchanged between computer application systems. It includes the definitions and service directoriesfor all parts comprising ISO 9735.

2 Conformance

Conformance to a standard means that all of its requirements, including all options, are supported. If alloptions are not supported, any claim of conformance shall include a statement which identifies those optionsto which conformance is claimed.

Data that is interchanged is in conformance if the structure and representation of the data conforms to thesyntax rules specified in this International Standard.

Devices supporting this International Standard are in conformance when they are capable of creating and/orinterpreting the data structured and represented in conformance with the standard.

Conformance shall be based on Part 1, and at least either Part 2 or Part 3 of this International Standard.

When identified in this International Standard, provisions defined in related standards shall form part of theconformance criteria.

3 Normative references

The following standards contain provisions which, through reference in this text, constitute provisions of thisInternational Standard. All standards are subject to revision, and parties to agreements based on thisInternational Standard are encouraged to investigate the possibility of applying the most recent editions ofthe standards listed below. Members of IEC and ISO maintain registers of currently valid InternationalStandards.

ISO 639 Codes for the representation of names of languages

ISO 646 Information processing - ISO 7-bit coded character set for informationinterchange

ISO 2022 Information technology - ISO 7-bit and 8-bit coded character sets - codeextension techniques

ISO 2382-1 Data processing - Vocabulary; Part 1: Fundamental terms

ISO 2382-4 Data processing - Vocabulary; Part 4: Organisation of data

ISO 6093 Information processing - Representation of numerical values in characterstrings for information interchange

ISO 6429 Information processing - Control functions for 7-bit and 8-bit coded charactersets

ISO 6523 Information technology - Structure for the identification of organizations andorganization parts


ISO 8601 Data elements and interchange formats - Information interchange -Representation of dates and times in information interchange

ISO 10646-1 Information technology - Universal Multiple-Octet Coded Character Set(UCS); Part 1: Architecture and basic multilingual plane

4 Definitions

For the purpose of this International Standard, the definitions in annex A apply.

5 Service characters

The service characters are the component data element separator, data element separator, releasecharacter, repetition separator, and segment terminator.

The component data element separator, data element separator, repetition separator, and segmentterminator delineate various syntax structures as defined in clause 7.

The purpose of the release character is to allow the use of a character that would otherwise be interpretedas a service character. The character immediately following the release character in a interchange shall notbe interpreted as a service character.

When used, the release character is not counted in the length of the data element value.

NOTE - Using default service characters shown below, 10?+10=20 appearing in a data transfer shall be interpreted onreceipt as 10+10=20. A question mark in a data element value is represented in transfer as ??.

5.1 Default service characters

The default service characters reserved for use in this International Standard are:

NameGraphic

Representation FunctionalityColon : component data element separatorPlus sign + data element separatorQuestion mark ? release characterAsterisk * repetition separatorApostrophe ' segment terminator


5.2 UNA, service string advice

The conditional service string advice (UNA) provides the capability to specify the service characters used inthe interchange (see annex B). The UNA service string advice shall be used if the service characters differfrom the defaults (see clause 5.1). Its use is optional if the default characters are used.

When used, the service string advice shall appear immediately before the interchange header segment, andapplies only to that interchange.

6 Character repertoires

The character encoding specified in basic code table of ISO 646 (7-bit coded character set for informationinterchange) shall be used for the interchange service string advice (if used) and up to and including thecomposite data element for the syntax identifier in the interchange header.

The character repertoire used (and the language covered) for the characters in an interchange shall beidentified from the code value of the data element for the syntax identifier in the interchange header.

The default encoding technique for a particular repertoire shall be the encoding technique defined by itsassociated character set specification.

If the default option is not used, a code value for the data element 'Character encoding' in the interchangeheader shall be used.

Code extension technique (ISO 2022) may only be used in an interchange after the composite data elementfor the syntax identifier in the interchange header.

The code extension technique and its target graphic characters shall only be used for:

- plain language (textual) data elements, with a representation of alphabetic or alphanumeric.

The technique shall not be used, for example, for any:

- segment tag, or- service character, or- data element with a representation of numeric.

Characters used to indicate code extension shall not be counted in the length of a data element, and shallnot be used as service characters.

In calculating data element length, one graphic character shall be counted as one character, irrespective ofthe number of bytes/octets required to encode it.

7 Syntax structures

The definitions in this clause specify logical syntax structures. Rules to be applied for their usage aredefined in clause 8.

7.1 Interchange structure

An interchange shall be started either by a service string advice or by an interchange header, shall beidentified by an interchange header, shall be terminated by an interchange trailer, and shall contain at leastone group, or one message or one package. There may be more than one group or message and/orpackage within an interchange, each identified by its own header and terminated by its own trailer.


An interchange shall contain only:• Messages, or• Packages, or• Messages and Packages, or• Groups containing messages, or• Groups containing packages, or• Groups containing messages and packages.

7.2 Group structure

A group is a conditional structure which is located between the interchange header and trailer and whichcomprises one or more messages and/or packages.

A group shall be started and identified by a group header, shall be terminated by a group trailer, and shallcontain at least one message or package.

7.3 Message structure

A message comprises an ordered set of segments (see annex E). Segments may be grouped. Eachsegment's position, status, and maximum number of occurrences shall be stated in the messagespecification.

A given segment within a message specification shall have a status of mandatory or conditional.

A message specification shall ensure unambiguous identification of each message segment upon receipt.Identification shall be possible on the basis of the segment tag and the segment’s position in the transferredmessage. Identification shall not depend on a segment’s status or maximum number of occurrences.

A message shall be started and identified by a message header, shall be terminated by a message trailer,and shall contain at least one additional segment.

7.4 Segment group structure

A segment group comprises an ordered set of segments: a trigger segment and at least one more segmentor segment group. The trigger segment shall be the first segment in the segment group, shall have a statusof mandatory and a maximum number of occurrences of one. Each segment group's position, status, andmaximum number of occurrences within the message structure shall be stated in the message specification.

A segment group may contain one or more dependent segment groups. When a segment group iscontained within and directly subordinate to another segment group, the subordinate segment group isreferred to as the child, and the other segment group is referred to as the parent.

A given segment group within a message specification shall have a status of mandatory or conditional.

7.5 Segment structure

A segment comprises an ordered set of stand-alone data elements and/or composite data elements, each ofwhich are permitted to repeat, if so stated in the segment specification. Each stand-alone or composite dataelement's position, status and maximum number of occurrences within the segment structure shall be statedin the segment specification. A segment shall be started and identified by a segment tag which references aspecific segment specification. A segment shall contain at least one data element in addition to thesegment tag.

A given data element within a segment specification shall have a status of mandatory or conditional.


7.6 Segment tag structure

A segment tag is a simple data element.

Segment tags starting with the letter "U" (e.g. UNB, UCS) shall be reserved for service segments.

7.7 Composite data element structure

A composite data element comprises an ordered set of two or more component data elements. Eachcomponent data element's position and status within the composite data element structure shall be stated inthe composite data element specification.A given component data element within a composite data element specification shall have a status ofmandatory or conditional.

7.8 Simple data element structure

A simple data element contains a single data element value.

A simple data element is used either as a stand-alone data element or as a component data element. Astand-alone data element occurs in a segment outside a composite data element. A component dataelement occurs within a composite data element.

Each simple data element's data value representation shall be stated in the data element specification.

7.9 Package structure

A package shall be started and identified by an object header, shall be terminated by an object trailer, andshall contain one object.

8 Inclusion and exclusion

The rules in this clause shall be applied when a message is prepared for transfer. Under these rules, certainsegment groups, segments, data elements, and characters within a data element value, shall be presentwhile others may be omitted.

8.1 Determination of presence

A simple data element is considered present if its data element value contains at least one character.

A composite data element is considered present if at least one of its component data elements is present.

A segment is considered present if its segment tag is present.

A segment group is considered present if its trigger segment is present.

8.2 Inclusion of segment groups

A mandatory segment group which is not contained within another segment group shall be present.

A mandatory child segment group shall be present if its parent segment group is present.

A single occurrence of a segment group having a status of mandatory is sufficient to satisfy the mandatoryrequirement.


8.3 Exclusion of segment groups

If a segment group is omitted, all of its segments and any dependent segment groups contained within it,regardless of their status, shall also be omitted.

8.4 Inclusion of segments

Segments shall appear in the order stated in the message specification.

A segment shall be terminated by a segment terminator.

A mandatory segment which is not in a segment group shall be present.

A mandatory segment contained in a segment group shall be present if the segment group is present.

A single occurrence of a segment having a status of mandatory is sufficient to satisfy the mandatoryrequirement.

Using a fictitious segment tag of ABC as an example, a mandatory segment defined as containing onlyconditional data elements for which no data is present at the time of transfer, shall be transferred in the formABC'.

8.5 Exclusion of segments

A conditional segment for which only the segment tag is present shall be omitted in its entirety.

8.6 Inclusion of data elements

Data elements shall appear in the order stated in the segment specification.

Adjacent non-repeating data elements in the same segment shall be separated by a data element separator.

Adjacent occurrences of the same repeating data element in a segment shall be separated by a repetitionseparator.

Adjacent component data elements in the same composite data element shall be separated by a componentdata element separator.

A mandatory stand-alone data element in a segment shall be present if the segment is present.

A mandatory composite data element in a segment shall be present if the segment is present.

A mandatory component data element in a composite data element shall be present if the composite dataelement is present.

A single occurrence of a repeating data element having a status of mandatory is sufficient to satisfy themandatory requirement.

8.7 Exclusion of data elements

In the figures in the following sub-clauses, "Tag" represents a segment tag, "DE" represents a compositedata element or stand-alone data element, and "CE" represents a component data element. The defaultservice characters are used.


8.7.1 Exclusion of non-repeating composite data elements and stand-alone data elements

If a non-repeating composite data element or stand-alone data element is omitted and is followed by aanother composite data element or stand-alone data element in the same segment, its position shall beindicated by retention of the data element separator which would normally follow it.

Tag+DE+DE+++DE+DE+DE'Two data elements have been omitted.

Figure 1 - Exclusion of non-repeating data elements within a segment

If one or more non-repeating composite data elements or stand-alone data elements at the end of asegment are omitted, the data element separators which would normally follow them shall also be omitted.

Tag+DE+DE+++DE'Using the example structure in figure 1, the lasttwo data elements have been omitted.

Figure 2 - Exclusion of non-repeating data elements at the end of a segment

8.7.2 Exclusion of component data elements

If a component data element is omitted and is followed by another component data element in the samecomposite data element, its position shall be indicated by retention of the component data elementseparator which would normally follow it.

Tag+DE+:CE:CE+CE:::CE'Two component data elements have been omitted.

One component data element has been omitted.

Figure 3 - Exclusion of component data elements within a composite data element

If one or more component data elements at the end of a composite data element are omitted, thecomponent data element separators which would normally follow them shall also be omitted.

Tag+DE+:CE+CE'Using the example structure in figure 3, the lastcomponent data element in the first compositedata element and the last component data elementin the last composite data element have beenomitted.

Figure 4 - Exclusion of component data elements at the end of a composite data element


8.7.3 Exclusion of occurrences of repeating data elements

The position of an occurrence of a repeating data element may be significant, for example, to transfer arraydata.

In such a case, if an occurrence of a repeating data element is omitted and is followed by anotheroccurrence of the same repeating data element, its position shall be indicated by retention of the repetitionseparator which would normally follow it.

Tag+DE+DE*DE***DE+DE*DE'Two occurrences of a repeating data element havebeen omitted.

Figure 5 - Exclusion of occurrences within a repeating data element

If one or more occurrences of a repeating data element at the end of a repeating data element are omitted,the repetition separators which would normally follow them shall also be omitted.

Tag+DE+DE*DE+DE'Using the example structure in figure 5, the lastoccurrence in the first repeating data element, andthe last occurrence in the last repeating dataelement have been omitted.

Figure 6 - Exclusion of occurrences at the end of a repeating data element

9 Suppression of characters within data elements

In variable length data elements, insignificant characters shall be suppressed (i.e. omitted from thetransfer), while significant characters shall be present.

9.1 Insignificant characters

In variable length numeric data elements, leading zeroes shall be suppressed. Nevertheless, a single zerobefore a decimal mark is allowed. In variable length alphabetic and alphanumeric data elements, trailingspaces shall be suppressed.

9.2 Significant zeroes

Significant zeroes shall not be suppressed. A single zero may be significant, for example, to indicate atemperature or tax rate. Trailing zeroes following the decimal mark may be significant to indicate precision.

9.3 Significant spaces

Significant spaces shall not be suppressed. Leading and embedded spaces may be significant.A data element value containing only space(s) shall not be allowed.


10 Representation of numeric data element values

For the purposes of this standard, the representation of numeric data element values shall be any of therepresentations as specified by ISO 6093 (which excludes the use of triad separators), with the followingexceptions:

- The encoding specified in ISO 646 shall not be required.

- For variable length numeric fields, the rules for suppression apply (see clause 9).

- The space character and plus sign shall not be allowed.

- The full stop and the comma are allowed to represent the decimal mark. Either orboth may be used within the same interchange.

- The length of a numeric data element value shall not include the minus sign (-),the decimal mark (. or ,), or the exponent mark (E or e).

- When a decimal mark is transferred, there shall be at least one digit after the decimalmark.

Examples using decimal marks:

Allowed (full stop): 2 and 2.00 and 0.5 and .5Not allowed (full stop): 1. and 0. and .

Allowed (comma): 2 and 2,00 and 0,5 and ,5Not allowed (comma): 1, and 0, and ,


11 Dependency notes

11.1 General

If required, dependency notes shall be used in the message or segment specification to expressrelationships.

In a dependency note, a list is defined as two or more entities (where an entity can be a segment group; asegment; a composite data element; or a component data element). Any entity may be subject to morethan one dependency note."

Any entity may be subject to more than one dependency note.

11.2 Dependency notes in the message specification

Dependency notes in the message specification are used to describe the relationship between segments,between segment groups, or between segments and segment groups. These entities shall be at the samehierarchical level and within the same parent structure.

Message level dependency notes shall be specified in the message segment table.

11.3 Dependency notes in the segment specification

Dependency notes in the segment specification are used to describe the relationship between stand-alonedata elements, between stand-alone data elements and composite data elements, or between compositedata elements. These entities shall be in the same segment.

Dependency notes shall not be used to describe a relationship between stand-alone data elements andcomponent data elements, or to describe a relationship between composite data elements and componentdata elements.

11.4 Dependency notes in the composite data element specification

Dependency notes in the composite data element specification are used to describe the relationshipbetween component data elements. These entities shall be in the same composite data element.

11.5 Notation for dependency notes

The notation for dependency notes comprise a dependency identifier followed by a list, in parenthesis, ofposition identifiers separated by commas e.g. D3(030, 060, 090). The position identifier identifies an entityby its position number in its parent entity. The dependency identifier identifies the type of dependencybetween the entities in the list.

A list shall contain at least two position identifiers. The order of position identifiers in a list may be differentfrom that implied by their value.

Dependency identifiers are described below.

D1 ONE AND ONLY ONEOne and only one of the entities in the list shall be present.

D2 ALL OR NONEIf one entity in the list is present, the rest shall be present.

D3 ONE OR MOREAt least one of the entities in the list shall be present.

D4 ONE OR NONENo more than one entity in the list shall be present.

D5 IF FIRST, THEN ALL


If the first entity in the list is present, then all of the others shall be present. It ispermissible that one or more of the entities not specified as the first entity in the list maybe present, without requiring the first entity to be present.

D6 IF FIRST, THEN AT LEAST ONE MOREIf the first entity in the list is present, then at least one more shall be present. It ispermissible that one or more of the entities not specified as the first entity in the list maybe present, without requiring the first entity to be present.

D7 IF FIRST, THEN NONE OF THE OTHERSIf the first entity in the list is present, then none of the others shall be present.


Annex A(normative)

Definitions

NOTES:

1. When a word or phrase appears in italics within a definition, this means that a definition exists in this annexfor this word or phrase.

2. The terms are classified alphabetically; an identifier is added at the end of each definition, in squarebrackets, to facilitate the comparison between different linguistic versions. For example the English term"Alphabetic character set" is called in French "Jeu de caracteres alphabetique", and will not appear at thesame alphabetic place in the two versions of the syntax; the identifier in brackets shall nevertheless remain "[1 ]".

3. Where ISO standards are referenced, the definitions have been taken from the referenced standard.

A.1 alphabetic character set: A character set that contains letters and/or ideograms, and may containother graphic characters except digits. [ 1 ]

A.2 alphanumeric character set: A character set that contains letters, digits and/or ideograms, andmay contain other graphic characters. [ 2 ]

A.3 attribute: A characteristic of an entity. [ 3 ]

A.4 batch EDI: electronic data interchange in which no strong requirements exist for formalisedtelecommunication association between the parties using query and response. [ 4 ]

A.5 business: A series of processes, each having a clearly understood purpose, involving more thanone organisation, realised through the exchange of information and directed towards some mutuallyagreed upon goal, extending over a period of time. [ 5 ]

A.6 character: A member of a set of elements used for the organisation, control, or representation ofdata. (ISO 10646-1) [ 6 ]

A.7 character repertoire: The set of graphic characters of a coded character set, consideredindependently of its encoding. [ 7 ]

A.8 code extension: The techniques for the encoding of characters that are not included in thecharacter repertoire of a given coded character set. [ 8 ]

A.9 code list: The complete set of data element values of a coded simple data element. [ 9 ]

A.10 code list directory: A listing of identified and specified code lists. [ 10 ]

A.11 coded character set: A set of unambiguous rules that establishes a character set and the one-to-one relationship between the characters of the set and their bit combinations. (ISO 6429) [ 11 ]

A.12 component data element: A simple data element used within a composite data element. [ 12 ]

A.13 component data element separator: A service character used to separate the component dataelements within a composite data element. [ 13 ]


A.14 composite data element: An identified, named and structured set of functionally relatedcomponent data elements, as described in a composite data element specification. In transfer, acomposite data element is a specific ordered set of one or more component data element(s) inconformance with a composite data element specification. [ 14 ]

A.15 composite data element directory: A listing of identified and named composite data elements withtheir composite data element specification. [ 15 ]

A.16 composite data element specification: The description of a composite data element in acomposite data element directory, including the specification of the position and status of thecomponent data elements constituting the composite data element. [ 16 ]

A.17 conditional: A type of status, used in a message specification, segment specification, or compositedata element specification, to specify that a segment group, segment, composite data element,stand-alone data element or component data element is used optionally or when the appropriateconditions occur. [ 17 ]

A.18 control character: A character whose occurrence in a particular context specifies a controlfunction. (ISO 2382-4) [ 18 ]

A.19 data: A representation of facts, concepts or instructions in a formalised manner suitable forcommunication, interpretation or processing by human beings or by automatic means. (ISO 2382-1)[ 19 ]

A.20 data element: A unit of data described in a data element specification. There are two classes ofdata element, simple data elements and composite data elements. [ 20 ]

A.21 data element directory: A listing of identified, named and specified simple data elements (simpledata element directory) or composite data elements (composite data element directory). [ 21 ]

A.22 data element separator: A service character used to separate non repeating stand-alone dataelements and/or composite data elements in a segment. [ 22 ]

A.23 data element specification: The specification of a composite data element in a composite dataelement directory (composite data element specification), or of a simple data element in a simpledata element directory (simple data element specification). [ 23 ]

A.24 data element value: A specific instance of a simple data element, represented as specified in asimple data element specification and, if the simple data element is coded, in a code list. [ 24 ]

A.25 data value representation: The types of characters allowed (e.g. alphabetic, numeric) andconditions of length relating to the data element values of a simple data element. [ 25 ]

A.26 decimal mark: The character that separates the digits forming the integral part of a number fromthose forming the fractional part. (ISO 6093) [ 26 ]

A.27 default service characters: The set of characters used as service characters in circumstanceswhere a different set is not defined in the service string advice. [ 27 ]

A.28 dependency identifier: An identifier used in a dependency note to specify the type of dependencybetween the entities listed in the dependency note. [ 28 ]

A.29 dependency note: A note used: i. in a message specification to express relationships betweensegment groups or between segments; ii. in a segment specification to express relationshipsbetween data elements; iii. in a composite data element specification to express relationshipsbetween component data elements. [ 29 ]

A.30 dialogue: A two-way conversation between an initiator and responder within an I-EDI transaction. Itis formally composed of a pair of interchanges. [ 30 ]

A.31 electronic data interchange (EDI): The electronic transfer from computer to computer ofcommercial or administrative transactions using an agreed standard to structure the transaction ormessage data. [ 31 ]

A.32 encoding: The representation of a character as a bit combination. [ 32 ]

A.33 exponent mark: A control character used to indicate that the character(s) that follow it are to beinterpreted as an exponent. E or e is the exponent mark. [ 33 ]


A.34 graphic character: A character, other than a control character, that has a visual representation andis normally produced by writing, printing or displaying. (ISO 2382-4) [ 34 ]

A.35 group: A group of messages (of one or more message types) and/or packages (each containing anobject), headed by a group header and ending with a group trailer. [ 35 ]

A.36 group header: The service segment heading and identifying a group. [ 36 ]

A.37 group trailer: The service segment ending a group. [ 37 ]

A.38 identifier: A character or group of characters used to identify or name an item of data and possiblyto indicate certain properties of that data. (ISO 2382-4) [ 38 ]

A.39 ideogram: In a natural language, a graphic character that represents a concept and associatedsound elements. Example; A Chinese ideogram or a Japanese Kanji. (ISO 2382-4) [ 39 ]

A.40 initiator: The application which starts the dialogue and/or I-EDI transaction. [ 40 ]

A.41 interactive EDI (I-EDI): The exchange of pre-defined and structured data within a dialogue, whichconforms to the syntax of Parts 1 and 3 of ISO 9735 for some business purpose, between a pair ofco-operating processes, in a timely manner. [ 41 ]

A.42 interchange: A sequence of messages, of the same or of different types, starting with theinterchange header (or with the service string advice if used), and ending with the interchange trailer.[ 42 ]

A.43 interchange header: The service segment starting and uniquely identifying an interchange. [ 43 ]

A.44 interchange trailer: The service segment ending an interchange. [ 44 ]

A.45 I-EDI transaction: An instance of a scenario. It consists of one or more dialogues. [ 45 ]

A.46 mandatory: A type of status, used in a message specification, segment specification, or compositedata element specification, to specify that a segment group, segment, composite data element,stand-alone data element or component data element shall be used at least one time. [ 46 ]

A.47 message: An identified, named and structured set of functionally related segments, covering therequirements for a specific type of transaction (e.g. invoice), as described in a messagespecification; a message starts with a message header and ends with a message trailer. In transfer,a message is a specific ordered set of segments in conformance with a message specification.[ 47 ]

A.48 message body: An identified, named and structured set of functionally related segments, coveringthe requirements for a specific type of transaction (e.g. invoice), as described in a messagespecification, excluding the message header and the message trailer. [ 48 ]

A.49 message directory: A listing of identified and named messages each with its messagespecification.[ 49 ]

A.50 message header: The service segment starting and uniquely identifying a message. [ 49 ]

A.51 message specification: The description of a message in a message directory, including thespecification of the position, status and maximum number of occurrences of the segments andsegment groups constituting the message. [ 51 ]

A.52 message trailer: The service segment ending a message. [ 52 ]

A.53 message type: Code identifying a type of message . [ 53 ]

A.54 numeric character set: A character set that contains digits and may contain control characters andspecial characters but not letters. (ISO 2382-4) [ 54 ]

A.55 object: A stream of octet bits (which may be associated with an EDIFACT message). [ 55 ]

A.56 object header: The service segment starting and uniquely identifying an object. [ 56 ]

A.57 object trailer: The service segment ending an object. [ 57 ]

A.58 organisation: A unique framework of authority within which a person or persons act, or aredesignated to act, towards some purpose. (ISO 6523) [ 58 ]


A.59 package: An object plus its associated header and trailer segments. [ 59 ]

A.60 parent-child relationship: A relationship between two entities, one ("child") being contained withinand directly subordinated to the other ("parent"). [ 60 ]

A.61 position identifier: An identifier used in a dependency note to identify an entity (segment group,segment, or data element) by its position in the parent entity. [ 61 ]

A.62 qualifier: A simple data element whose data element value, extracted from a code list, givesspecific meaning to the function of another data element or a segment. [ 62 ]

A.63 release character: A character indicating that the character immediately following it shall be passedto the application as received. [ 63 ]

A.64 repeating data element: A composite data element or stand-alone data element having amaximum occurrence of greater than one in the segment specification. [ 64 ]

A.65 repetition separator: A service character used to separate adjacent occurrences of a repeatingdata element. [ 65 ]

A.66 responder: An application replying to an initiator. [ 66 ]

A.67 scenario: A formal specification of a class of business activities having the same business goal[ 67 ]

A.68 segment: An identified, named and structured set of functionally related composite data elementsand/or stand-alone data elements, as described in a segment specification; a segment starts with thesegment tag and ends with the segment terminator. In transfer, a segment is a specific ordered setof one or more composite data element(s) and/or stand-alone data element(s) in conformance with asegment specification. [ 68 ]

A.69 segment directory: A listing of identified and named segments with their segment specification.[ 69 ]

A.70 segment group: An identified hierarchical set of segments and/or segment groups within amessage.[ 70 ]

A.71 segment specification: The description of a segment in a segment directory, including thespecification of the position, status and maximum number of occurrences of the data elementsconstituting the segment. [ 71 ]

A.72 segment tag: A simple data element uniquely identifying a segment, by reference to a segmentdirectory. [ 72 ]

A.73 segment terminator: A service character indicating the end of a segment. [ 73 ]

A.74 service character: A character reserved for syntactical use; the service characters are thecomponent data element separator, the data element separator, the release character, the repetitionseparator and the segment terminator. [ 74 ]

A.75 service composite data element: A composite data element used in service segments. A servicecomposite data element specification contains only service simple data elements. [ 75 ]

A.76 service data element: A service simple data element or a service composite data element. [ 76 ]

A.77 service message: A message used to exchange service information relating to the use ofEDIFACT syntax rules or security. A service message specification contains only service segments.[ 77 ]

A.78 service segment: A segment used i. in service messages; ii. to control the transfer of data. Aservice segment specification contains only service composite data elements and/or service simpledata elements. [ 78 ]

A.79 service simple data element: A simple data element used only in service segments and/or servicecomposite data elements. [ 79 ]

A.80 service string advice: An optional string of characters used at the beginning of an interchange tospecify the service characters used in the interchange. [ 80 ]


A.81 simple data element: A data element containing a single data element value. There are two usesof a simple data element: within a composite data element (component data element); and within asegment outside a composite data element (stand-alone data element). [ 81 ]

A.82 simple data element directory: A listing of identified and named simple data elements with theirsimple data element specification. [ 82 ]

A.83 simple data element specification: The set of attributes characterising a simple data element in asimple data element directory. [ 83 ]

A.84 special character: A graphic character that is not a letter, digit, or blank character, and usually notan ideogram. ( ISO 2382-4) [ 84 ]

A.85 stand-alone data element: A simple data element used within a segment without being in acomposite data element. [ 85 ]

A.86 status: An attribute of a segment, a composite data element or a simple data element identifyingthe rules for the presence or absence of the segment/data element in the usage of a message. Thetypes of status are conditional and mandatory. [ 86 ]

A.87 string: A sequence of elements of the same nature, such as characters, considered as a whole.(ISO 2382-4) [ 87 ]

A.88 transfer: The communication of information from one partner to another. [ 88 ]

A.89 trigger segment: The segment starting a segment group. [ 89 ]


Annex B(normative)

UNA service string advice

The service string advice shall begin with the upper case characters UNA immediately followed by sixcharacters in the order shown below. The space character shall not be used in positions 010, 020, 040, 050or 060. The same character shall not be used in more than one position of the UNA.

POS REP S Name Remarks

010 an1 M COMPONENT DATA ELEMENTSEPARATOR

020 an1 M DATA ELEMENT SEPARATOR

030 an1 M DECIMAL MARK The character transferred in thisposition shall be ignored by therecipient. Retained to maintainupward compatibility with earlierversions of the syntax.

040 an1 M RELEASE CHARACTER

050 an1 M REPETITION SEPARATOR

060 an1 M SEGMENT TERMINATOR

Legend:

POS The 3 numeric sequential number of the character in the service string

REP The representation of the service string characteran1 = 1 alphanumeric character

S The status of the service string characterM = Mandatory

Name Name of the service string advice character

Remarks Additional remarks

Annex C(normative)


Syntax service directories(segments, composite data elements and simple data elements)

C.1 Segment directory

C.1.1 Segment specification legend:

Function The function of the segment

POS The sequential position number of the stand-alone data element or composite data element inthe segment table

TAG The tag for the data elements contained in the segment. The tags of all service composite dataelements start with the letter "S", and the tags of all service simple data elements start with thefigure "0"

Name Name of a COMPOSITE DATA ELEMENT in capital lettersName of a STAND-ALONE DATA ELEMENT in capital lettersName of a component data element in small letters

S The status of the stand-alone data element or composite data element in the segment, or of thecomponents in the composite (where M = Mandatory and C = Conditional)

R The maximum number of occurrences of a stand-alone data element or composite dataelement in the segment

Repr. Data value representation of the stand-alone data element or component data elements in thecomposite.

a alphabetic charactersn numeric charactersan alphanumeric charactersa3 3 alphabetic characters, fixed lengthn3 3 numeric characters, fixed lengthan3 3 alphanumeric characters, fixed lengtha..3 up to 3 alphabetic charactersn..3 up to 3 numeric charactersan..3 up to 3 alphanumeric characters

Notes Segment note number(s)


C.1.2 Dependency note identifiers

Code Name

D1 One and only one

D2 All or none

D3 One or more

D4 One or none

D5 If first, then all

D6 If first, then at least one more

D7 If first, then none of the others

See clause 11.5 for the definition of the dependency note identifiers

C.1.3 Index of segments by tag

TAG Name

UIB Interactive interchange headerUIH Interactive message headerUIR Interactive statusUIT Interactive message trailerUIZ Interactive interchange trailerUNB Interchange headerUNE Group trailerUNG Group headerUNH Message headerUNO Object headerUNP Object trailerUNS Section controlUNT Message trailerUNZ Interchange trailer


C.1.4 Index of segments by name

TAG Name

UNG Group headerUNE Group trailerUIB Interactive interchange headerUIZ Interactive interchange trailerUIH Interactive message headerUIT Interactive message trailerUIR Interactive statusUNB Interchange headerUNZ Interchange trailerUNH Message headerUNT Message trailerUNO Object headerUNP Object trailerUNS Section control


C.1.5 Segment specifications

------------------------------------------------------------------------------- UIB INTERACTIVE INTERCHANGE HEADER

Function: To head and identify an interchange.

POS TAG Name S R Repr. Notes

010 S001 SYNTAX IDENTIFIER M 1 3 0001 Syntax identifier M a4 0002 Syntax version number M an1 0080 Service code list directory version number C an..6 0133 Character encoding, coded C an..3

020 S302 DIALOGUE REFERENCE C 1 1,2,4,5 8 0300 Initiator control reference M an..35 0303 Initiator reference identification C an..35 0051 Controlling agency, coded C an..3 0304 Responder control reference C an..35

030 S303 TRANSACTION REFERENCE C 1 1,8 0306 Transaction control reference M an..35 0303 Initiator reference identification C an..35 0051 Controlling agency, coded C an..3

040 S018 SCENARIO IDENTIFICATION C 1 0127 Scenario identification M an..14 0128 Scenario version number C an..3 0130 Scenario release number C an..3 0051 Controlling agency, coded C an..3

050 S305 DIALOGUE IDENTIFICATION C 1 2 0311 Dialogue identification M an..14 0342 Dialogue version number C an..3 0344 Dialogue release number C an..3 0051 Controlling agency, coded C an..3

060 S002 INTERCHANGE SENDER C 1 5 0004 Interchange sender identification M an..35 0007 Identification code qualifier C an..4 0008 Interchange sender internal identification C an..35 0042 Interchange sender internal sub-identification C an..35

070 S003 INTERCHANGE RECIPIENT C 1 0010 Interchange recipient identification M an..35 0007 Identification code qualifier C an..4 0014 Interchange recipient internal identification C an..35 0046 Interchange recipient internal sub-identification C an..35

080 S300 DATE AND/OR TIME OF INITIATION C 1 0338 Event date C n..8 0314 Event time C an..15 0336 Time offset C n4090 0325 DUPLICATE INDICATOR C 1 a1 6

100 0035 TEST INDICATOR C 1 n1 7


DEPENDENCY NOTES:

1. D5(030, 020) If first, then all


OTHER NOTES:

3. S001/0002, shall be '4' to indicate this version of the syntax.

4. S302/0304, when provided by the responder, shall be returned by the initiator throughout the dialogue.

5. S002/0004, may be same as S302/0303 for initiator of transaction.

6. 0325, only used if the interchange is a duplicate transfer.

7. 0035, set by the initiator if the dialogue is a test. Applies to every subsequent message and service segment in the dialogue. Otherwise not used.

8. Dialogue and transaction control can be accomplished through the dialogue (S302) and transaction (S303) references. Optionally, if another means of control is chosen, these two composite data elements need not be utilised.-------------------------------------------------------------------------------

UIH INTERACTIVE MESSAGE HEADER

Function: To head, identify and specify a message.


010 S306 INTERACTIVE MESSAGE IDENTIFIER M 1 0065 Message type M an..6 0052 Message version number M an..3 0054 Message release number M an..3 0113 Message type sub-function identification C an..6 0051 Controlling agency, coded C an..3 0057 Association assigned code C an..6

020 0340 INTERACTIVE MESSAGE REFERENCE NUMBER C 1 an..35 1,5

030 S302 DIALOGUE REFERENCE C 1 2,4,5 0300 Initiator control reference M an..35 0303 Initiator reference identification C an..35 0051 Controlling agency, coded C an..3 0304 Responder control reference C an..35

040 S301 STATUS OF TRANSFER - INTERACTIVE C 1 0320 Sender sequence number C n..6 0323 Transfer position, coded C a1 0325 Duplicate indicator C a1

050 S300 DATE AND/OR TIME OF INITIATION C 1 0338 Event date C n..8 0314 Event time C an..15 0336 Time offset C n4


NOTES:

1. The value in 0340 shall be unique within the interchange (except for a duplicate transfer).

2. The value(s) in S302 shall be identical to the value(s) in S302 in the preceding UIB.


3. 0035, when used, test applies to the message only.

4. Dialogue control can be accomplished through the dialogue reference (S302). Optionally, if another means of control is chosen, this composite data element need not be utilised.

5. A combination of 0340 and S302 may be used to identify uniquely a message.

-------------------------------------------------------------------------------

UIR INTERACTIVE STATUS

Function: To report the status of the dialogue.


010 0331 REPORT FUNCTION, CODED M 1 an..3

020 S307 REPORT REASON C 9 0333 Report reason, coded C an..3 0332 Report reason text C an..70 0335 Report language, coded C an..3

030 S302 DIALOGUE REFERENCE C 1 0300 Initiator control reference M an..35 0303 Initiator reference identification C an..35 0051 Controlling agency, coded C an..3 0304 Responder control reference C an..35040 S300 DATE AND/OR TIME OF INITIATION C 1 0338 Event date C n..8 0314 Event time C an..15 0336 Time offset C n4

050 0340 INTERACTIVE MESSAGE REFERENCE NUMBER C 1 an..35 1,2

060 0800 PACKAGE REFERENCE NUMBER C 1 an..35 1,3

DEPENDENCY NOTES:

1. D1(050, 060) One and only one

OTHER NOTES:

2. 0340, the value shall be identical to the value in 0340 in the UIH of a message received by the sender of the UIR within the same dialogue.3. 0800, the value shall be identical to the value in 0800 in the UNO received by the sender of the UIR within the same dialogue.

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

UIT INTERACTIVE MESSAGE TRAILER

Function: To end and check the completeness of a message.


010 0340 INTERACTIVE MESSAGE REFERENCE NUMBER C 1 an..35 1

020 0074 NUMBER OF SEGMENTS IN A MESSAGE C 1 n..10

NOTES:

1. 0340, the value shall be identical to the value in 0340 in the corresponding UIH segment.

-------------------------------------------------------------------------------

UIZ INTERACTIVE INTERCHANGE TRAILER

Function: To end and check the completeness of an interchange.


010 S302 DIALOGUE REFERENCE C 1 1 0300 Initiator control reference M an..35 0303 Initiator reference identification C an..35 0051 Controlling Agency, coded C an..3 0304 Responder control reference C an..35

020 0036 INTERCHANGE CONTROL COUNT C 1 n..6

030 0325 DUPLICATE INDICATOR C 1 a1 2

NOTES:

1. S302, the value shall be identical to the value in the responder's dialogue reference in S302 in the UIB segment.

2. 0325, only used if the interchange is a duplicate transfer.

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

UNB INTERCHANGE HEADER

Function: To identify an interchange.


010 S001 SYNTAX IDENTIFIER M 1 1 0001 Syntax identifier M a4 0002 Syntax version number M an1 0080 Service code list directory version number C an..6 0133 Character encoding, coded C an..3

020 S002 INTERCHANGE SENDER M 1 2 0004 Interchange sender identification M an..35 0007 Identification code qualifier C an..4 0008 Interchange sender internal identification C an..35 0042 Interchange sender internal sub-identification C an..35

030 S003 INTERCHANGE RECIPIENT M 1 2 0010 Interchange recipient identification M an..35 0007 Identification code qualifier C an..4 0014 Interchange recipient internal identification C an..35 0046 Interchange recipient internal sub-identification C an..35

040 S004 DATE AND TIME OF PREPARATION M 1 0017 Date M n6 0019 Time M n4

050 0020 INTERCHANGE CONTROL REFERENCE M 1 an..14 2

060 S005 RECIPIENT REFERENCE/PASSWORD DETAILS C 1 0022 Recipient reference/password M an..14 0025 Recipient reference/password qualifier C an2

070 0026 APPLICATION REFERENCE C 1 an..14

080 0029 PROCESSING PRIORITY CODE C 1 a1

090 0031 ACKNOWLEDGEMENT REQUEST C 1 n1

100 0032 INTERCHANGE AGREEMENT IDENTIFIER C 1 an..35

110 0035 TEST INDICATOR C 1 n1

NOTES:

1. S001/0002, shall be '4' to indicate this version of the syntax.

2. The combination of the values carried in data elements S002, S003 and 0020 shall be used to identify uniquely the interchange, for the purpose of acknowledgement.

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

UNE GROUP TRAILER

Function: To end and check the completeness of a group


010 0060 GROUP CONTROL COUNT M 1 n..6

020 0048 GROUP REFERENCE NUMBER M 1 an..14 1

NOTES:

1. 0048, the value shall be identical to the value in 0048 in the corresponding UNG segment.

-------------------------------------------------------------------------------

UNG GROUP HEADER

Function: To head, identify and specify a group of messages and/or packages, which may be used for internal routing and which may contain one or more message types and/or packages.


010 0038 MESSAGE GROUP IDENTIFICATION C 1 an..6 1,2,4

020 S006 APPLICATION SENDER IDENTIFICATION C 1 5 0040 Application sender identification M an..35 0007 Identification code qualifier C an..4

030 S007 APPLICATION RECIPIENT IDENTIFICATION C 1 5 0044 Application recipient identification M an..35 0007 Identification code qualifier C an..4

040 S004 DATE AND TIME OF PREPARATION C 1 3 0017 Date M n6 0019 Time M n4

050 0048 GROUP REFERENCE NUMBER M 1 an..14 5

060 0051 CONTROLLING AGENCY, CODED C 1 an..3 1,2,4

070 S008 MESSAGE VERSION C 1 1,2,4 0052 Message version number M an..3 0054 Message release number M an..3 0057 Association assigned code C an..6

080 0058 APPLICATION PASSWORD C 1 an..14

DEPENDENCY NOTES:

1. D2(010, 060, 070) All or none


OTHER NOTES:

2. This data element is only used if the following conditions apply: i) the group contains messages only, and ii) the messages are of a single message type.

3. S004, if S004 is not present in UNG, the date and time of preparation is the same as indicated for the interchange in S004 in UNB.

4. This data element will be deleted from the UNG segment in the next version of the standard. Therefore its use in UNG is not recommended.

5. The combination of the values carried in data elements S006, S007 and 0048 shall be used to identify uniquely the group within its interchange, for the purpose of acknowledgement.

-------------------------------------------------------------------------------

UNH MESSAGE HEADER

Function: To head, identify and specify a message.


010 0062 MESSAGE REFERENCE NUMBER M 1 an..14 2

020 S009 MESSAGE IDENTIFIER M 1 1,2 0065 Message type M an..6 0052 Message version number M an..3 0054 Message release number M an..3 0051 Controlling agency, coded M an..3 0057 Association assigned code C an..6 0110 Code list directory version number C an..6 0113 Message type sub-function identification C an..6

030 0068 COMMON ACCESS REFERENCE C 1 an..35

040 S010 STATUS OF THE TRANSFER C 1 0070 Sequence of transfers M n..2 0073 First and last transfer C a1050 S016 MESSAGE SUBSET IDENTIFICATION C 1 1 0115 Message subset identification M an..14 0116 Message subset version number C an..3 0118 Message subset release number C an..3 0051 Controlling agency, coded C an..3

060 S017 MESSAGE IMPLEMENTATION GUIDELINE IDENTIFICATION C 1 1 0121 Message implementation guideline identification M an..14 0122 Message implementation guideline version number C an..3 0124 Message implementation guideline release number C an..3 0051 Controlling agency, coded C an..3

070 S018 SCENARIO IDENTIFICATION C 1 0127 Scenario identification M an..14 0128 Scenario version number C an..3 0130 Scenario release number C an..3 0051 Controlling agency, coded C an..3


NOTES:

1. Data element S009/0057 is retained for upward compatibility. The use of S016 and/or S017 is encouraged in preference.

2. The combination of the values carried in data elements 0062 and S009 shall be used to identify uniquely the message within its group (if used) or if not used, within its interchange, for the purpose of acknowledgement.

-------------------------------------------------------------------------------

UNO OBJECT HEADER

Function: To head, identify and specify an object.


010 0800 PACKAGE REFERENCE NUMBER M 1 an..35 1

020 S020 REFERENCE IDENTIFICATION M 99 2 0813 Reference qualifier M an..3 0802 Reference identification number M an..35

030 S021 OBJECT TYPE IDENTIFICATION M 99 3 0805 Object type qualifier M an..3 0809 Object type attribute identification C an..256 0808 Object type attribute C an..256 0051 Controlling agency, coded C an..3

040 S022 STATUS OF THE OBJECT M 1 0810 Length of object in octet bits M n..18 0814 Number of segments before object C n..3 0070 Sequence of transfers C n..2 0073 First and last transfer C a1

050 S302 DIALOGUE REFERENCE C 1 4 0300 Initiator control reference M an..35 0303 Initiator reference identification C an..35 0051 Controlling agency, coded C an..3 0304 Responder control reference C an..35

060 S301 STATUS OF TRANSFER - INTERACTIVE C 1 4 0320 Sender sequence number C n..6 0323 Transfer position, coded C a1 0325 Duplicate indicator C a1

070 S300 DATE AND/OR TIME OF INITIATION C 1 4 0338 Event date C n..8 0314 Event time C an..15 0336 Time offset C n4


NOTES:

1. The value in 0800 shall be unique within the interchange (except for a duplicate transfer).2. One mandatory occurrence of S020 shall identify the Object Identification Number.

3. One occurrence of S021 is mandatory and shall be used for file format identification.

4. Data elements S302, S301, S300 and 0035 are for interactive EDI use only: - The value(s) in S302 shall be identical to the value(s) in S302 in the preceding UIB.


- 0035, when used, test applies to the message or package only.

-------------------------------------------------------------------------------

UNP OBJECT TRAILER

Function: To end and check the completeness of an object.


010 0810 LENGTH OF OBJECT IN OCTET BITS M 1 n..18 1

020 0800 PACKAGE REFERENCE NUMBER M 1 an..35 2

NOTES:

1. 0810, shall be identical to the value in data element 0810 in UNO.

2. 0800, shall be identical to the value in data element 0800 in UNO.

-------------------------------------------------------------------------------

UNS SECTION CONTROL

Function: To separate header, detail and summary sections of a message.

Note: To be used by message designers only when required to avoid ambiguities.


010 0081 SECTION IDENTIFICATION M 1 a1

-------------------------------------------------------------------------------

UNT MESSAGE TRAILER

Function: To end and check the completeness of a message.


010 0074 NUMBER OF SEGMENTS IN A MESSAGE M 1 n..10

020 0062 MESSAGE REFERENCE NUMBER M 1 an..14 1

NOTES:

1. 0062, the value shall be identical to the value in 0062 in the corresponding UNH segment.

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

UNZ INTERCHANGE TRAILER

Function: To end and check the completeness of an interchange.


010 0036 INTERCHANGE CONTROL COUNT M 1 n..6

020 0020 INTERCHANGE CONTROL REFERENCE M 1 an..14 1

NOTES:

1. 0020, the value shall be identical to the value in 0020 in the corresponding UNB segment.

-------------------------------------------------------------------------------


C.2 Composite data element directory

C.2.1 Composite data element specification legend:

POS The sequential position number of the component data element in the composite data element

TAG The tag for the component data elements contained in the composite data element. The tagsof all service composite data elements start with the letter “S”, and the tags of all servicesimple data elements start with the figure "0"

Name Name of a component data element in small letters

S The status of the component data element in the composite data element(where M = Mandatory and C = Conditional)

Repr. Data value representation of the component data elements in the composite.


Notes Composite data element note number(s)

Desc. Description of the composite data element

C.2.2 Dependency note identifiers

Code Name

D1 One and only one

D2 All or none

D3 One or more

D4 One or none

D5 If first, then all

D6 If first, then at least one more

D7 If first, then none of the others

See clause 11.5 for the definition of the dependency note identifiers


C.2.3 Index of composite data elements by tag

TAG Name

S001 Syntax identifierS002 Interchange senderS003 Interchange recipientS004 Date and time of preparationS005 Recipient reference/password detailsS006 Application sender identificationS007 Application recipient identificationS008 Message versionS009 Message identifierS010 Status of the transferS016 Message subset identificationS017 Message implementation guideline identificationS018 Scenario identificationS020 Reference identificationS021 Object type identificationS022 Status of the objectS300 Date and/or time of initiationS301 Status of transfer - interactiveS302 Dialogue referenceS303 Transaction referenceS305 Dialogue identificationS306 Interactive message identifierS307 Report reason


C.2.4 Index of composite data elements by name

TAG Name

S007 Application recipient identificationS006 Application sender identificationS004 Date and time of preparationS300 Date and/or time of initiationS305 Dialogue identificationS302 Dialogue referenceS306 Interactive message identifierS003 Interchange recipientS002 Interchange senderS009 Message identifierS017 Message implementation guideline identificationS016 Message subset identificationS008 Message versionS021 Object type identificationS005 Recipient reference/password detailsS020 Reference identificationS307 Report reasonS018 Scenario identificationS022 Status of the objectS010 Status of the transferS301 Status of transfer - interactiveS001 Syntax identifierS303 Transaction reference

C.2.5 Composite data element specifications

-------------------------------------------------------------------------------

S001 SYNTAX IDENTIFIER

Desc: Identification of the agency controlling the syntax, the syntax level and version number, and the service code directory.

POS TAG Name S Repr. Notes

010 0001 Syntax identifier M a4020 0002 Syntax version number M an1030 0080 Service code list directory version number C an..6040 0133 Character encoding, coded C an..3

-------------------------------------------------------------------------------


--------------------------------------------------------------------------------

S002 INTERCHANGE SENDER

Desc: Identification of the sender of the interchange.


010 0004 Interchange sender identification M an..35020 0007 Identification code qualifier C an..4030 0008 Interchange sender internal identification C an..35040 0042 Interchange sender internal sub-identification C an..35

-------------------------------------------------------------------------------

S003 INTERCHANGE RECIPIENT

Desc: Identification of the recipient of the interchange.


010 0010 Interchange recipient identification M an..35020 0007 Identification code qualifier C an..4030 0014 Interchange recipient internal identification C an..35040 0046 Interchange recipient internal sub-identification C an..35

-------------------------------------------------------------------------------

S004 DATE AND TIME OF PREPARATION

Desc: Date and time of preparation of the interchange.


010 0017 Date M n6020 0019 Time M n4

-------------------------------------------------------------------------------

S005 RECIPIENT REFERENCE/PASSWORD DETAILS

Desc: Reference or password as agreed between the communicating partners.


010 0022 Recipient reference/password M an..14020 0025 Recipient reference/password qualifier C an2

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------

S006 APPLICATION SENDER IDENTIFICATION

Desc: Sender identification of for example a division, branch or application computer system/process.


010 0040 Application sender identification M an..35020 0007 Identification code qualifier C an..4

-------------------------------------------------------------------------------

S007 APPLICATION RECIPIENT IDENTIFICATION

Desc: Recipient identification of for example a division, branch or application computer system/process.


010 0044 Application recipient identification M an..35020 0007 Identification code qualifier C an..4

-------------------------------------------------------------------------------

S008 MESSAGE VERSION

Desc: Specification of the version and release numbers of all of the messages of a single type in the group.


010 0052 Message version number M an..3020 0054 Message release number M an..3030 0057 Association assigned code C an..6

-------------------------------------------------------------------------------

S009 MESSAGE IDENTIFIER

Desc: Identification of the type, version, etc. of the message being interchanged.


010 0065 Message type M an..6020 0052 Message version number M an..3030 0054 Message release number M an..3040 0051 Controlling agency, coded M an..3050 0057 Association assigned code C an..6060 0110 Code list directory version number C an..6070 0113 Message type sub-function identification C an..6

------------------------------------------------------------------------------


------------------------------------------------------------------------------

S010 STATUS OF THE TRANSFER

Desc: Statement that the message is one in a sequence of transfers relating to the same topic.


010 0070 Sequence of transfers M n..2020 0073 First and last transfer C a1

------------------------------------------------------------------------------

S016 MESSAGE SUBSET IDENTIFICATION

Desc: To identify a message subset by its identifier, version, release and source.


010 0115 Message subset identification M an..14020 0116 Message subset version number C an..3030 0118 Message subset release number C an..3040 0051 Controlling agency, coded C an..3

------------------------------------------------------------------------------

S017 MESSAGE IMPLEMENTATION GUIDELINE IDENTIFICATION

Desc: To identify a message implementation guideline by its identifier, version, release and source.


010 0121 Message implementation guideline identification M an..14020 0122 Message implementation guideline version number C an..3030 0124 Message implementation guideline release number C an..3040 0051 Controlling agency, coded C an..3------------------------------------------------------------------------------

S018 SCENARIO IDENTIFICATION

Desc: To identify a scenario.


010 0127 Scenario identification M an..14020 0128 Scenario version number C an..3030 0130 Scenario release number C an..3040 0051 Controlling agency, coded C an..3------------------------------------------------------------------------------


------------------------------------------------------------------------------

S020 REFERENCE IDENTIFICATION

Desc: To identify the reference relating to the object.


010 0813 Reference qualifier M an..3020 0802 Reference identification number M an..35

------------------------------------------------------------------------------

S021 OBJECT TYPE IDENTIFICATION

Desc: To identify the attribute related to the object type.


010 0805 Object type qualifier M an..3020 0809 Object type attribute identification C an..256 1030 0808 Object type attribute C an..256 1040 0051 Controlling agency, coded C an..3

DEPENDENCY NOTES:

1. D3(020, 030) One or more

------------------------------------------------------------------------------

S022 STATUS OF THE OBJECT

Desc: To identify the length and if required the transfer status of the object.


010 0810 Length of object in octet bits M n..18020 0814 Number of segments before object C n..3030 0070 Sequence of transfers C n..2040 0073 First and last transfer C a1

------------------------------------------------------------------------------

. S300 DATE AND/OR TIME OF INITIATION

Desc: Date and/or time of event initiation.


010 0338 Event date C n..8020 0314 Event time C an..15 1030 0336 Time offset C n4 1


DEPENDENCY NOTES:

1. D5(030, 020) If first, then all--------------------------------------------------------------------------------

S301 STATUS OF TRANSFER - INTERACTIVE

Desc: Identifies the sequence of the message/package within the sender's interchange and the position in a multi-message and/or package transfer.


010 0320 Sender sequence number C n..6 1020 0323 Transfer position, coded C a1 2030 0325 Duplicate indicator C a1 3

NOTES:

1. 0320, starts at 1 and is incremented by 1 for each message and package within an interchange.

2. 0323, only used where more than one message or package is contained in a single query or response.

3. 0325, only used if a duplicate transfer.

------------------------------------------------------------------------------

S302 DIALOGUE REFERENCE

Desc: Unique reference for the dialogue between co-operating parties within the interactive EDI transaction.


010 0300 Initiator control reference M an..35020 0303 Initiator reference identification C an..35 1030 0051 Controlling agency, coded C an..3 1040 0304 Responder control reference C an..35

DEPENDENCY NOTES:


------------------------------------------------------------------------------

S303 TRANSACTION REFERENCE

Desc: Unique reference for the business transaction to which the dialogue belongs.


010 0306 Transaction control reference M an..35020 0303 Initiator reference identification C an..35 1030 0051 Controlling agency, coded C an..3 1


DEPENDENCY NOTES:

1. D5(030, 020) If first, then all------------------------------------------------------------------------------

S305 DIALOGUE IDENTIFICATION

Desc: Identification of the dialogue type being used for the interactive EDI transaction.


010 0311 Dialogue identification M an..14020 0342 Dialogue version number C an..3030 0344 Dialogue release number C an..3040 0051 Controlling agency, coded C an..3

------------------------------------------------------------------------------

S306 INTERACTIVE MESSAGE IDENTIFIER

Desc: Identification of the type, version and details of the message being interchanged.


010 0065 Message type M an..6020 0052 Message version number M an..3030 0054 Message release number M an..3040 0113 Message type sub-function identification C an..6050 0051 Controlling agency, coded C an..3060 0057 Association assigned code C an..6

------------------------------------------------------------------------------

S307 REPORT REASON

Desc: Reason for status or error report.


010 0333 Report reason, coded C an..3020 0332 Report reason text C an..70 1,2030 0335 Report language, coded C an..3 1

DEPENDENCY NOTES:


OTHER NOTES:

2. 0332, defaults to English in the absence of a value in 0335.

------------------------------------------------------------------------------


C.3 Simple data element directory

The service code directory forms part the UN Trade Data Interchange Directory (UNTDID). The most recentUNTDID should be used to reference the code values for the coded data elements in the following simpledata element directory. Annex D within this Part, contains the service code directory as at date ofpublication.

C.3.1 Simple data element specification legend:

Name Name of a simple data element

Desc. Description of the simple data element

Repr. Data value representation of the simple data element:


C.3.2 Index of simple data elements by tag

TAG Name

0001 Syntax identifier0002 Syntax version number0004 Interchange sender identification0007 Identification code qualifier0008 Interchange sender internal identification0010 Interchange recipient identification0014 Interchange recipient internal identification0017 Date0019 Time0020 Interchange control reference0022 Recipient reference/password0025 Recipient reference/password qualifier0026 Application reference0029 Processing priority code0031 Acknowledgement request0032 Interchange agreement identifier0035 Test indicator0036 Interchange control count0038 Message group identification0040 Application sender identification0042 Interchange sender internal sub-identification0044 Application recipient identification0046 Interchange recipient internal sub-identification0048 Group reference number0051 Controlling agency, coded


0052 Message version number0054 Message release number0057 Association assigned code0058 Application password0060 Group control count0062 Message reference number0065 Message type0068 Common access reference0070 Sequence of transfers0073 First and last transfer0074 Number of segments in a message0080 Service code list directory version number0081 Section identification0110 Code list directory version number0113 Message type sub-function identification0115 Message subset identification0116 Message subset version number0118 Message subset release number0121 Message implementation guideline identification0122 Message implementation guideline version number0124 Message implementation guideline release number0127 Scenario identification0128 Scenario version number0130 Scenario release number0133 Character encoding, coded0135 Service segment tag, coded0300 Initiator control reference0303 Initiator reference identification0304 Responder control reference0306 Transaction control reference0311 Dialogue identification0314 Event time0320 Sender sequence number0323 Transfer position, coded0325 Duplicate indicator0331 Report function, coded0332 Report reason text0333 Report reason, coded0335 Report language, coded0336 Time offset0338 Event date0340 Interactive message reference number0342 Dialogue version number0344 Dialogue release number0800 Package reference number0802 Reference identification number0805 Object type qualifier0808 Object type attribute0809 Object type attribute identification


0810 Length of object in octet bits0813 Reference qualifier0814 Number of segments before object

C.3.3 Index of simple data elements by name

TAG Name

0031 Acknowledgement request0058 Application password0044 Application recipient identification0026 Application reference0040 Application sender identification0057 Association assigned code0133 Character encoding, coded0110 Code list directory version number0068 Common access reference0051 Controlling agency, coded0017 Date0311 Dialogue identification0344 Dialogue release number0342 Dialogue version number0325 Duplicate indicator0338 Event date0314 Event time0073 First and last transfer0060 Group control count0048 Group reference number0007 Identification code qualifier0300 Initiator control reference0303 Initiator reference identification0340 Interactive message reference number0032 Interchange agreement identifier0036 Interchange control count0020 Interchange control reference0010 Interchange recipient identification0014 Interchange recipient internal identification0046 Interchange recipient internal sub-identification0004 Interchange sender identification0008 Interchange sender internal identification0042 Interchange sender internal sub-identification0810 Length of object in octet bits0038 Message group identification0121 Message implementation guideline identification0124 Message implementation guideline release number0122 Message implementation guideline version number0062 Message reference number0054 Message release number0115 Message subset identification0118 Message subset release number


0116 Message subset version number0065 Message type0113 Message type sub-function identification0052 Message version number0814 Number of segments before object0074 Number of segments in a message0808 Object type attribute0809 Object type attribute identification0805 Object type qualifier0800 Package reference number0029 Processing priority code0022 Recipient reference/password0025 Recipient reference/password qualifier0802 Reference identification number0813 Reference qualifier0331 Report function, coded0335 Report language, coded0332 Report reason text0333 Report reason, coded0304 Responder control reference0127 Scenario identification0130 Scenario release number0128 Scenario version number0081 Section identification0320 Sender sequence number0070 Sequence of transfers0080 Service code list directory version number0135 Service segment tag, coded0001 Syntax identifier0002 Syntax version number0035 Test indicator0019 Time0336 Time offset0306 Transaction control reference0323 Transfer position, coded


C.3.4 Simple data element specifications

------------------------------------------------------------------------------

0001 SYNTAX IDENTIFIER

Desc: Coded identification of the agency controlling the syntax, and of the character repertoire used in an interchange.

Repr: a4

Note 1: The data value consists of the letters 'UN', upper case, identifying the syntax controlling agency, directly followed by an a2 code identifying the character repertoire used. Note 2: The character repertoire identified does not include objects and/or encrypted message bodies.

------------------------------------------------------------------------------

0002 SYNTAX VERSION NUMBER

Desc: Version number of the syntax.

Repr: an1

Note 1: Shall be '4' to indicate this version of the syntax.

------------------------------------------------------------------------------

0004 INTERCHANGE SENDER IDENTIFICATION

Desc: Name or coded identification of the sender of the interchange.

Repr: an..35

Note 1: Organisation code or name as agreed between interchange partners. Note 2: If coded representation is used, its source may be specified by the qualifier in data element 0007.

------------------------------------------------------------------------------

0007 IDENTIFICATION CODE QUALIFIER

Desc: Qualifier referring to the identification code.

Repr: an..4

Note 1: A qualifier code may refer to an organisation identification as in ISO 6523.

------------------------------------------------------------------------------


-------------------------------------------------------------------------------

0008 INTERCHANGE SENDER INTERNAL IDENTIFICATION

Desc: Identification (for example, a division, branch or computer system/process) specified by the sender of interchange, to be included if agreed, by the recipient in response interchanges, to facilitate internal routing. Repr: an..35

------------------------------------------------------------------------------

0010 INTERCHANGE RECIPIENT IDENTIFICATION

Desc: Name or coded identification of the recipient of the interchange.

Repr: an..35

Note 1: Organisation code or name as agreed between interchange partners. Note 2: If coded representation is used, its source may be specified by the qualifier in data element 0007.

------------------------------------------------------------------------------

0014 INTERCHANGE RECIPIENT INTERNAL IDENTIFICATION

Desc: Identification (for example, a division, branch or computer system/process) specified by the recipient of interchange, to be included if agreed, by the sender in response interchanges, to facilitate internal routing.

Repr: an..35

------------------------------------------------------------------------------

0017 DATE

Desc: Local date when an interchange or a group was prepared.

Repr: n6

Note 1: Format is YYMMDD.

------------------------------------------------------------------------------

0019 TIME

Desc: Local time of day when an interchange or a group was prepared.

Repr: n4

Note 1: Format is HHMM in 24 hour clock.

------------------------------------------------------------------------------


------------------------------------------------------------------------------

0020 INTERCHANGE CONTROL REFERENCE

Desc: Unique reference assigned by the sender to an interchange.

Repr: an..14

------------------------------------------------------------------------------

0022 RECIPIENT REFERENCE/PASSWORD

Desc: Reference or password to the recipient's system or to a third party network as specified in the partners' interchange agreement.

Repr: an..14

Note 1: To be used as specified in the partners' interchange agreement. It may be qualified by data element 0025.

------------------------------------------------------------------------------

0025 RECIPIENT REFERENCE/PASSWORD QUALIFIER

Desc: Qualifier for the recipient's reference or password.

Repr: an2

Note 1: To be used as specified in the partners' interchange agreement.

------------------------------------------------------------------------------

0026 APPLICATION REFERENCE

Desc: Identification of the application area assigned by the sender, to which the messages in the interchange relate e.g. the message type, if all the messages in the interchange are of the same type.

Repr: an..14

Note 1: Identification of the application area (e.g. accounting, purchasing) or of the message type, as applicable.

------------------------------------------------------------------------------

0029 PROCESSING PRIORITY CODE

Desc: Code determined by the sender requesting processing priority for the interchange.

Repr: a1

Note 1: To be used as specified in the partners' interchange agreement.

------------------------------------------------------------------------------


------------------------------------------------------------------------------

0031 ACKNOWLEDGEMENT REQUEST

Desc: Code requesting acknowledgement for the interchange.

Repr: n1

Note 1: Used if the sender requests that a message related to syntactical correctness be sent by the recipient in response. Note 2: For UN/EDIFACT a specific message (Syntax and service report - CONTRL) is defined for this purpose.

------------------------------------------------------------------------------

0032 INTERCHANGE AGREEMENT IDENTIFIER

Desc: Identification by name or code of the type of agreement under which the interchange takes place.

Repr: an..35

Note 1: Name or code to be specified in the partners' interchange agreement.

------------------------------------------------------------------------------

0035 TEST INDICATOR

Desc: Indication that the structural level containing the test indicator is a test.

Repr: n1

------------------------------------------------------------------------------

0036 INTERCHANGE CONTROL COUNT

Desc: The number of messages and packages in an interchange or, if used, the number of groups in an interchange.

Repr: n..6

------------------------------------------------------------------------------

0038 MESSAGE GROUP IDENTIFICATION

Desc: Identification of the single message type in the group.

Repr: an..6

Note 1: This data element will be deleted from the next version of the standard. Therefore its use is not recommended.

------------------------------------------------------------------------------


------------------------------------------------------------------------------

0040 APPLICATION SENDER IDENTIFICATION

Desc: Name or coded identification of the application sender (for example, a division, branch or computer system/process).

Repr: an..35

------------------------------------------------------------------------------

0042 INTERCHANGE SENDER INTERNAL SUB-IDENTIFICATION

Desc: Sub-level of sender internal identification, when further sub-level identification is required.

Repr: an..35

------------------------------------------------------------------------------

0044 APPLICATION RECIPIENT IDENTIFICATION

Desc: Name or coded identification of the application recipient (for example, a division, branch or computer system/process).

Repr: an..35

------------------------------------------------------------------------------

0046 INTERCHANGE RECIPIENT INTERNAL SUB-IDENTIFICATION

Desc: Sub-level of recipient internal identification, when further sub-level identification is required.

Repr: an..35

------------------------------------------------------------------------------

0048 GROUP REFERENCE NUMBER

Desc: Unique reference number for the group within an interchange.

Repr: an..14

------------------------------------------------------------------------------

0051 CONTROLLING AGENCY, CODED

Desc: Code identifying a controlling agency.

Repr: an..3

------------------------------------------------------------------------------

0052 MESSAGE VERSION NUMBER

Desc: Version number of a message type.

Repr: an..3------------------------------------------------------------------------------

------------------------------------------------------------------------------

0054 MESSAGE RELEASE NUMBER


Desc: Release number within the current message version number.

Repr: an..3

------------------------------------------------------------------------------

0057 ASSOCIATION ASSIGNED CODE

Desc: Code, assigned by the association responsible for the design and maintenance of the message type concerned, which further identifies the message.

Repr: an..6

------------------------------------------------------------------------------

0058 APPLICATION PASSWORD

Desc: Password to the recipient's division, department or sectional application system/process.

Repr: an..14

------------------------------------------------------------------------------

0060 GROUP CONTROL COUNT

Desc: The number of messages and packages in the group.

Repr: n..6

------------------------------------------------------------------------------

0062 MESSAGE REFERENCE NUMBER

Desc: Unique message reference assigned by the sender.

Repr: an..14

------------------------------------------------------------------------------

0065 MESSAGE TYPE

Desc: Code identifying a type of message and assigned by its controlling agency.

Repr: an..6

Note 1: In UNSMs (United Nations Standard Messages), the representation is a6.

------------------------------------------------------------------------------


-------------------------------------------------------------------------------

0068 COMMON ACCESS REFERENCE

Desc: Reference serving as a key to relate all subsequent transfers of data to the same business case or file.

Repr: an..35------------------------------------------------------------------------------

0070 SEQUENCE OF TRANSFERS

Desc: Number assigned by the sender indicating the transfer sequence of a message related to the same topic. The message could be an addition or a change to an earlier transfer related to the same topic.

Repr: n..2

Note 1: The first message in the sequence shall be assigned as number 1.

------------------------------------------------------------------------------

0073 FIRST AND LAST TRANSFER

Desc: Indication used for the first and last message in a sequence of messages related to the same topic.

Repr: a1

------------------------------------------------------------------------------

0074 NUMBER OF SEGMENTS IN A MESSAGE

Desc: The number of segments in a message, including the message header segment and message trailer segment.

Repr: n..10

------------------------------------------------------------------------------

0080 SERVICE CODE LIST DIRECTORY VERSION NUMBER

Desc: Version number of the service code list directory.

Repr: an..6

------------------------------------------------------------------------------

0081 SECTION IDENTIFICATION

Desc: To identify the separation of sections of a message.

Repr: a1

------------------------------------------------------------------------------


------------------------------------------------------------------------------

0110 CODE LIST DIRECTORY VERSION NUMBER

Desc: Version number of the code list directory.

Repr: an..6

------------------------------------------------------------------------------

0113 MESSAGE TYPE SUB-FUNCTION IDENTIFICATION

Desc: Code identifying a sub-function of a message type.

Repr: an..6

Note 1: The code qualifies the message type data element (0065) to allow the recipient to identify a specific sub-function of a message.

------------------------------------------------------------------------------

0115 MESSAGE SUBSET IDENTIFICATION

Desc: Coded identification of a message subset, assigned by its controlling agency.

Repr: an..14

------------------------------------------------------------------------------

0116 MESSAGE SUBSET VERSION NUMBER

Desc: Version number of the message subset.

Repr: an..3

------------------------------------------------------------------------------

0118 MESSAGE SUBSET RELEASE NUMBER

Desc: Release number within the message subset version number.

Repr: an..3

------------------------------------------------------------------------------

0121 MESSAGE IMPLEMENTATION GUIDELINE IDENTIFICATION

Desc: Coded identification of the message implementation guideline, assigned by its controlling agency.

Repr: an..14

------------------------------------------------------------------------------


------------------------------------------------------------------------------

0122 MESSAGE IMPLEMENTATION GUIDELINE VERSION NUMBER

Desc: Version number of the message implementation guideline.

Repr: an..3------------------------------------------------------------------------------

0124 MESSAGE IMPLEMENTATION GUIDELINE RELEASE NUMBER

Desc: Release number within the message implementation guideline version number.

Repr: an..3

------------------------------------------------------------------------------

0127 SCENARIO IDENTIFICATION

Desc: Code identifying scenario.

Repr: an..14

------------------------------------------------------------------------------

0128 SCENARIO VERSION NUMBER

Desc: Version number of a scenario.

Repr: an..3

------------------------------------------------------------------------------

0130 SCENARIO RELEASE NUMBER

Desc: Release number within the scenario version number.

Repr: an..3------------------------------------------------------------------------------

0133 CHARACTER ENCODING, CODED

Desc: Coded identification of the character encoding used in the interchange.

Repr: an..3

------------------------------------------------------------------------------

0135 SERVICE SEGMENT TAG, CODED

Desc: Code identifying a service segment.

Repr: an..3

------------------------------------------------------------------------------

------------------------------------------------------------------------------

0300 INITIATOR CONTROL REFERENCE


Desc: A reference assigned by the dialogue initiator.

Repr: an..35

------------------------------------------------------------------------------

0303 INITIATOR REFERENCE IDENTIFICATION

Desc: Organisation code or name assigned by the party that initiated the transaction or dialogue.

Repr: an..35

------------------------------------------------------------------------------

0304 RESPONDER CONTROL REFERENCE

Desc: A reference assigned by the dialogue responder.

Repr: an..35

------------------------------------------------------------------------------

0306 TRANSACTION CONTROL REFERENCE

Desc: A reference assigned by the transaction initiator.

Repr: an..35

------------------------------------------------------------------------------

0311 DIALOGUE IDENTIFICATION

Desc: Code identifying a dialogue.

Repr: an..14

------------------------------------------------------------------------------

0314 EVENT TIME

Desc: Time of event.

Repr: an..15

Note 1: Format is HHMMSS... with up to 9 more digits of precision. A 'Z' as the last character indicates UTC time. (ISO 8601)

------------------------------------------------------------------------------

0320 SENDER SEQUENCE NUMBER

Desc: Identifies the sequence number of the message or package within the sender interchange.

Repr: n..6------------------------------------------------------------------------------


------------------------------------------------------------------------------ 0323 TRANSFER POSITION, CODED

Desc: Indication of the position of a transfer.

Repr: a1

------------------------------------------------------------------------------

0325 DUPLICATE INDICATOR

Desc: Indication that the structure is a duplicate of a previously sent structure.

Repr: a1

------------------------------------------------------------------------------

0331 REPORT FUNCTION, CODED

Desc: Coded value identifying type of status or error report.

Repr: an..3

------------------------------------------------------------------------------

Desc: Textual explanation of the reason for the status or error report.

Repr: an..70

------------------------------------------------------------------------------

0333 REPORT REASON, CODED

Desc: Code identifying the reason for the status or error report.

Repr: an..3

------------------------------------------------------------------------------

0335 REPORT LANGUAGE, CODED

Desc: Coded identification of language.

Repr: an..3

Note 1: The code list for this data element is maintained by ISO (ISO 639).

------------------------------------------------------------------------------

0336 TIME OFFSET

Desc: UTC (Universal Co-ordinated Time) offset from event time.

Repr: n4

Note 1: Format is HHMM. Shall be prefixed with '-' for negative offsets. (ISO 8601)------------------------------------------------------------------------------


------------------------------------------------------------------------------

0332 REPORT REASON TEXT

0338 EVENT DATE

Desc: Date of event.

Repr: n..8

Note 1: Format is YYMMDD or CCYYMMDD.

------------------------------------------------------------------------------

0340 INTERACTIVE MESSAGE REFERENCE NUMBER

Desc: Unique interactive message reference assigned by the sender.

Repr: an..35

------------------------------------------------------------------------------

0342 DIALOGUE VERSION NUMBER

Desc: Version number of a dialogue.

Repr: an..3

------------------------------------------------------------------------------

0344 DIALOGUE RELEASE NUMBER

Desc: Release number of a dialogue.

Repr: an..3

------------------------------------------------------------------------------

0800 PACKAGE REFERENCE NUMBER

Desc: Unique package reference number assigned by the sender.

Repr: an..35

------------------------------------------------------------------------------

0802 REFERENCE IDENTIFICATION NUMBER

Desc: Reference number to identify a message, message group and/or interchange, which relates to the object.

Repr: an..35

------------------------------------------------------------------------------

0805 OBJECT TYPE QUALIFIER

Desc: Qualifier referring to the type of object.

Repr: an..3

------------------------------------------------------------------------------


------------------------------------------------------------------------------

0332 REPORT REASON TEXT

0808 OBJECT TYPE ATTRIBUTE

Desc: The attribute applying to the object type.

Repr: an..256

------------------------------------------------------------------------------

0809 OBJECT TYPE ATTRIBUTE IDENTIFICATION

Desc: Coded identification of the attribute applying to the object type.

Repr: an..256

------------------------------------------------------------------------------

0810 LENGTH OF OBJECT IN OCTET BITS

Desc: Count of the number of octet bits of the object.

Repr: n..18

Note 1: The count shall exclude the segment terminator of the preceding EDIFACT structured segment and the first character ('U') of the following EDIFACT structured segment.------------------------------------------------------------------------------

0813 REFERENCE QUALIFIER

Desc: Code giving specific meaning to a reference identification number.

Repr: an..3

------------------------------------------------------------------------------

0814 NUMBER OF SEGMENTS BEFORE OBJECT

Desc: A count of the number of segments appearing between the UNO segment and the start of the object.

Repr: n..3

------------------------------------------------------------------------------


Annex D(informative)

Syntax service code directory

The service code directory forms part the UN Trade Data Interchange Directory (UNTDID). The most recentUNTDID should be used to reference the code values for the coded data elements in the simple dataelement directory (see annex C within this part). This informative annex contains the service code directoryas at date of publication.

D.1 Syntax service code directory specification legend:

Name Name of a simple data element

Desc. Description of the simple data element

Repr. Data value representation of the simple data element:


D.2 Index of syntax service code directory simple data elements by tag

TAG Name

0001 Syntax identifier0002 Syntax version number0007 Identification code qualifier0025 Recipient reference/password qualifier0029 Processing priority code0031 Acknowledgement request0035 Test indicator0051 Controlling agency, coded0052 Message version number0054 Message release number0065 Message type0073 First and last transfer0081 Section identification0135 Service segment tag, coded0323 Transfer position, coded0325 Duplicate indicator0331 Report function, coded0333 Report reason, coded0805 Object type qualifier0813 Reference qualifier


D.3 Index of syntax service code directory simple data elements by name

TAG Name

0031 Acknowledgement request0051 Controlling agency, coded0325 Duplicate indicator0073 First and last transfer0007 Identification code qualifier0054 Message release number0065 Message type0052 Message version number0805 Object type qualifier0029 Processing priority code0025 Recipient reference/password qualifier0813 Reference qualifier0331 Report function, coded0333 Report reason, coded0081 Section identification0135 Service segment tag, coded0001 Syntax identifier0002 Syntax version number0035 Test indicator0323 Transfer position, coded


D.4 Code specifications

----------------------------------------------------------------------

0001 SYNTAX IDENTIFIER

Desc: Coded identification of the agency controlling the syntax, and of the character repertoire used in an interchange.

Repr: a4

UNOA UN/ECE level A As defined in ISO 646 (with the exception of letters, lower case a to z). UNOB UN/ECE level B As defined in ISO 646. UNOC UN/ECE level C As defined in ISO 8859-1 : Information processing - Part 1: Latin alphabet No. 1. UNOD UN/ECE level D As defined in ISO 8859-2 : Information processing - Part 2: Latin alphabet No. 2. UNOE UN/ECE level E As defined in ISO 8859-5 : Information processing - Part 5: Latin/Cyrillic alphabet. UNOF UN/ECE level F As defined in ISO 8859-7 : Information processing - Part 7: Latin/Greek alphabet. UNOG UN/ECE level G As defined in ISO 8859-3 : Information processing - Part 3: Latin alphabet. UNOH UN/ECE level H As defined in ISO 8859-4 : Information processing - Part 4: Latin alphabet. UNOI UN/ECE level I As defined in ISO 8859-6 : Information processing - Part 6: Latin/Arabic alphabet. UNOJ UN/ECE level J As defined in ISO 8859-8 : Information processing - Part 8: Latin/Hebrew alphabet. UNOK UN/ECE level K As defined in ISO 8859-9 : Information processing - Part 9: Latin alphabet. UNOX UN/ECE level X Code extension technique as defined by ISO 2022 utilising the escape techniques in accordance with ISO 2375. UNOY UN/ECE level Y ISO 10646-1 octet without code extension technique.

----------------------------------------------------------------------

0002 SYNTAX VERSION NUMBER

Desc: Version number of the syntax.

Repr: an1

1 Version 1 ISO 9735:1988. 2 Version 2 ISO 9735:1990. 3 Version 3 ISO 9735 Amendment 1:1992. 4 Version 4 ISO 9735:YYYY.-----------------------------------------------------------------------


----------------------------------------------------------------------

0007 IDENTIFICATION CODE QUALIFIER

Desc: Qualifier referring to the identification code.

Repr: an..4

1 DUNS (Dun & Bradstreet) Self explanatory. 4 IATA (International Air Transport Association) Self explanatory. 5 INSEE (Institut National de la Statistique et des Etudes Economiques) - SIRET French national statistics institute. SIRET means Systeme Informatique du Repertoire des entreprises et de leurs ETablissements. 8 UCC Communications ID (Uniform Code Council Communications Identifier) The Uniform Code Council Communications Identifier is a ten digit code used to uniquely identify physical and logical locations. 9 DUNS (Dun & Bradstreet) with 4 digit suffix Self explanatory. 12 Telephone number Self explanatory. 14 EAN (European Article Numbering Association) Self explanatory. 18 AIAG (Automotive Industry Action Group) Self explanatory. 22 INSEE (Institut National de la Statistique et des Etudes Economiques) - SIREN French national statistics institute. SIREN means Systeme Informatique du Repertoire des ENtreprises (et de leurs etablissements). 30 ISO 6523: Organization identification Self explanatory. 31 DIN (Deutsches Institut fuer Normung) German standardization institute. 33 BfA (Bundesversicherungsanstalt fuer Angestellte) German social security association. 34 National Statistical Agency Self explanatory. 51 GEIS (General Electric Information Services) Self explanatory. 52 INS (IBM Network Services) Self explanatory. 54 Bundesverband der Deutschen Baustoffhaendler German building material trade association. 55 Bank identifier code Self explanatory. 57 KTNet (Korea Trade Network Services) Self explanatory. 58 UPU (Universal Postal Union) Self explanatory. 59 ODETTE (Organization for Data Exchange through Tele-Transmission in Europe) European automotive industry project. 61 SCAC (Standard Carrier Alpha Code) Directory of standard multimodal carriers and tariff agent codes. The SCAC lists and codes transportation companies. 63 ECA (Electronic Commerce Australia) Australian association for electronic commerce. 65 TELEBOX 400 (Deutsche Telekom) German telecommunications service.


80 NHS (National Health Service) United Kingdom National Health Service. 82 Statens Teleforvaltning Norwegian telecommunications regulatory authority (NTRA). 84 Athens Chamber of Commerce Greek Chamber of Commerce. 85 Swiss Chamber of Commerce Swiss Chamber of Commerce. 86 US Council for International Business United States Council for International Business. 87 National Federation of Chambers of Commerce and Industry Belgium National Federation of Chambers of Commerce and Industry. 89 Association of British Chambers of Commerce Association of British Chambers of Commerce. 90 SITA (Societe Internationale de Telecommunications Aeronautiques) SITA (Societe Internationale de Telecommunications Aeronautiques). 91 Assigned by seller or seller's agent Self explanatory. 92 Assigned by buyer or buyer's agent Self explanatory. ZZZ Mutually defined Self explanatory.--------------------------------------------------------------------------

0025 RECIPIENT REFERENCE/PASSWORD QUALIFIER

Desc: Qualifier for the recipient's reference or password.

Repr: an2

AA Reference Self explanatory. BB Password Self explanatory.

----------------------------------------------------------------------

0029 PROCESSING PRIORITY CODE

Desc: Code determined by the sender requesting processing priority for the interchange. Repr: a1

A Highest priority Self explanatory.

----------------------------------------------------------------------

0031 ACKNOWLEDGEMENT REQUEST

Desc: Code requesting acknowledgement for the interchange.

Repr: n1

1 Requested Acknowledgement is requested.

----------------------------------------------------------------------


---------------------------------------------------------------------- 0035 TEST INDICATOR

Desc: Indication that the structural level containing the test indicator is a test.

Repr: n1

1 General test A test transfer. 2 Syntax only test Test only syntax of structure. 3 Echo request To be returned without change, except for this data element to have the value 4. 4 Echo response Returned without change except for this data element changing from 3 to 4.

----------------------------------------------------------------------

0051 CONTROLLING AGENCY, CODED

Desc: Code identifying a controlling agency.

Repr: an..3

AA EDICONSTRUCT French construction project. AB DIN (Deutsches Institut fuer Normung) German standardization institute. AC ICS (International Chamber of Shipping) Self explanatory. AD UPU (Union Postale Universelle) Universal Postal Union. CC CCC (Customs Co-operation Council) Self explanatory. CE CEFIC (Conseil Europeen des Federations de l'Industrie Chimique) EDI project for chemical industry. EC EDICON UK Construction project. ED EDIFICE (Electronic industries project) EDI Forum for companies with Interest in Computing and Electronics (EDI project for EDP/ADP sector). EE EC + EFTA (European Communities and European Free Trade Association) Self explanatory. EN EAN (European Article Numbering Association) Self explanatory. ER UIC (International Union of railways) European railways. EU European Union Self explanatory. EX IECC (International Express Carriers Conference) Self explanatory. IA IATA (International Air Transport Association) Self explanatory. KE KEC (Korea EDIFACT Committee) Self explanatory. LI LIMNET UK Insurance project. OD ODETTE (Organization for Data Exchange through Tele-Transmission in Europe) European automotive industry project.


RI RINET (Reinsurance and Insurance Network) Self explanatory. RT UN/ECE/TRADE/WP.4/GE.1/EDIFACT Rapporteurs' Teams Self explanatory. UN UN/ECE/TRADE/WP.4 United Nations Economic UN Economic Commission for Europe (UN/ECE), Committee on the development of trade (TRADE), Working Party on facilitation of international trade procedures (WP.4).

----------------------------------------------------------------------

0052 MESSAGE VERSION NUMBER

Desc: Version number of a message type.

Repr: an..3

1 Status 1 version Message approved and issued as a status 1 (trial) message. (Valid for directories published after March 1990 and prior to March 1993) 2 Status 2 version Message approved and issued as a status 2 (formal recommendation) message. (Valid for directories published after March 1990 and prior to March 1993) 88 1988 version Message approved and issued in the 1988 release of the UNTDID (United Nations Trade Data Interchange Directory) as a status 2 (formal recommendation) message. 89 1989 version Message approved and issued in the 1989 release of the UNTDID (United Nations Trade Data Interchange Directory) as a status 2 (formal recommendation) message. 90 1990 version Message approved and issued in the 1990 release of the UNTDID (United Nations Trade Data Interchange Directory) as a status 2 (formal recommendation) message. D Draft version Message approved and issued as a draft message. (Valid for directories published after March 1993) S Standard version Message approved and issued as a standard message. (Valid for directories published after March 1993)

----------------------------------------------------------------------

0054 MESSAGE RELEASE NUMBER

Desc: Release number within the current message version number.

Repr: an..3

1 First release Message approved and issued in the first release of the year of the UNTDID (United Nations Trade Data Interchange Directory). (Valid for directories published prior to March 1990) 2 Second release Message approved and issued in the second release of the year of the UNTDID (United Nations Trade Data Interchange Directory) (Valid for directories published prior to March 1990). 902 Trial release 1990 Message approved and issued in the 1990 status 1 (trial) release of the UNTDID (United Nations Trade Data Interchange Directory).


911 Trial release 1991 Message approved and issued in the 1991 status 1 (trial) release of the UNTDID (United Nations Trade Data Interchange Directory). 912 Standard release 1991 Message approved and issued in the 1991 status 2 (standard) release of the UNTDID (United Nations Trade Data Interchange Directory). 921 Trial release 1992 Message approved and issued in the 1992 status 1 (trial) release of the UNTDID (United Nations Trade Data Interchange Directory). 932 Standard release 1993 Message approved and issued in the 1993 status 2 (standard) release of the UNTDID (United Nations Trade Data Interchange Directory). 93A Release 1993 - A Message approved and issued in the 1993 release of the UNTDID (United Nations Trade Data Interchange Directory). 94A Release 1994 - A Message approved and issued in the first 1994 release of the UNTDID (United Nations Trade Data Interchange Directory). 94B Release 1994 - B Message approved and issued in the second 1994 release of the UNTDID (United Nations Trade Data Interchange Directory). 95A Release 1995 - A Message approved and issued in the first 1995 release of the UNTDID (United Nations Trade Data Interchange Directory). 95B Release 1995 - B Message approved and issued in the second 1995 release of the UNTDID (United Nations Trade Data Interchange Directory). 96A Release 1996 - A Message approved and issued in the first 1996 release of the UNTDID (United Nations Trade Data Interchange Directory). 96B Release 1996 - B Message approved and issued in the second 1996 release of the UNTDID (United Nations Trade Data Interchange Directory).

----------------------------------------------------------------------

0065 MESSAGE TYPE

Desc: Code identifying a type of message and assigned by its controlling agency.

Repr: an..6

APERAK Application error and acknowledgement message The function of this message is: a) to inform a message issuer that his message has been received by the addressee's application and has been rejected due to errors encountered during its processing in the application. b) to acknowledge to a message issuer the receipt of his message by the addressee's application.


AUTACK Secure authentication and acknowledgement message Message authenticating sent messages, or providing secure acknowledgement of received interchanges, groups, messages or packages. A secure authentication and acknowledgement message can be used to: a) give secure authentication or non-repudiation of origin to messages, packages, groups or interchanges. b) give secure acknowledgement or non-repudiation of receipt to secured messages, packages, groups or interchanges. AUTHOR Authorization message Message sent by the Ordering Customer (or Payor or Agent on behalf of the Ordering Customer) or by a third party having authority on the Ordering Customer's payments to the Ordered Bank, to authorize the Ordered Bank to execute a given financial transaction. This financial transaction might relate to both: multiple messages like PAYMUL and DIRDEB and single instruction messages like PAYORD and PAYEXT. An Authorisation Message could also be sent from the Ordered Bank to the Ordering Customer or its Authorisation Authority to request authorisation for a given financial transaction. BANSTA Banking status message Message sent by the receiver of a previously sent-message to report on the status of processing of this original message. It indicates, at the application level, the acceptance or rejection of the message or the ability for the receiver of the message to execute or not the instructions received. BAPLIE Bayplan/stowage plan occupied and empty locations message Message to transmit information about equipment and goods on a means of transport, including their location on the means of transport. The message can be exchanged between (liner's) agents, tonnage centers, stevedores and ships masters/operators. BAPLTE Bayplan/stowage plan total numbers message Message to transmit information about the total numbers of equipment and quantity of goods on a means of transport. The message can be exchanged between (liner's) agents, tonnage centers, stevedores and ships masters/operators. BOPBNK Bank transactions and portfolio transactions report message Message sent by banks to the Balance of Payment (BOP) compiler for reporting of the banks' own transactions, aggregated individual customer transactions and portfolio transactions. The message could also be used for reporting the assets and liabilities positions of the banks. BOPCUS Balance of payment customer transaction report message Message sent by banks to the Balance of Payment (BOP) compiler for reporting - one by one - individual customer transactions (debit and credit) processed during a specific time period. Actually, this transaction information can be distilled - one by one- from PAYORD / PAYMUL / PAYEXT and BOPINF messages respectively. BOPDIR Direct balance of payment declaration message Message sent by non-bank residents to report directly to the Balance of Payment (BOP) compiler on: transactions via bank accounts held at a resident bank, transactions via bank accounts held at a non-resident bank, transactions and clearing via accounts with non-bank non- residents, foreign assets and liabilities, information in the context of a BOP-related survey (stocks and flows); for those countries which base their compilation of the BOP on surveys.


BOPINF Balance of payment information from customer message Message sent by a payee to its bank on receipt of one specified amount as a settlement of a transaction with a non-resident. The Balance of Payment (BOP) compiler has to be informed of the transaction via the payee's bank. CALINF Vessel call information message Notice from a liner agent to a stevedore providing information concerning the expected arrival of a vessel and the expected cargo operations. CASINT Request for legal administration action in civil proceedings message A request for lodgment of data to commence or enforce a civil proceeding. CASRES Legal administration response in civil proceedings message A legal response (CASRES) to a request for lodgement of data to commence or enforce a civil proceeding. COARRI Container discharge/loading report message A message by which the container terminal reports that the containers specified have been discharged from a seagoing vessel (discharged as ordered, overlanded or shortlanded), or have been loaded into a seagoing vessel. CODECO Container gate-in/gate-out report message A message by which a terminal, depot, etc. confirms that the containers specified have been delivered or picked up by the inland carrier (road, rail or barge). This message can also be used to report internal terminal container movements (excluding loading and discharging the vessel). CODENO Permit expiration/clearance ready notice message Notice specifying the cargo for which either the validity of the permits/Customs documents expires at short notice or for which regulatory Customs clearance has taken place. COEDOR Container stock report message A message to report containers that are in stock of the sending party (i.e., a terminal, depot or container freight station). COHAOR Container special handling order message Order to perform a specified special handling and/or service on containers. COMDIS Commercial dispute message Message providing notice of commercial dispute against one or more invoices is usually raised by the buyer to notify the seller that something was found wrong with the goods delivered or the services rendered (goods damaged, delivery incomplete, delivery late, etc.). The dispute must be resolved before the related invoice can be settled. The message will be used to: - notify a dispute; - correspond about an existing dispute (structured information); - notify the settlement of a dispute. The message will serve at the same time as the dispute notice and as the dispute answer. CONAPW Advice on pending works message Message to enable a contractor who intends to start works to advise public authorities and water, gas, telephone, electricity distributors of his intention and to request them to send back plans or information under any form concerning existing networks. CONDPV Direct payment valuation message Message of instruction sent by the contractor to the party responsible for payments, to pay the subcontractors for work completed.


CONDRA Drawing administration message The message will be used for the administration of each exchange of a set of engineering/CAD files. It will give additional information about the files; for example, their nature, a list of their contents and technical information necessary to interpret them. The whole process of exchanging engineering or CAD (Computer Aided Design) files between different parties within projects will be supported by EDIFACT messages. The message CONDRA is one of these messages. CONDRO Drawing organisation message The message CONDRO is intended to describe the general (project) organisation and structure, valid for a whole project or environment. The whole process of exchanging engineering or CAD (Computer Aided Design) files between different parties within one project will be supported by EDIFACT messages. The message CONDRO is one of these messages. CONEST Establishment of contract message Message to formally establish and issue the contractual Bill of Quantities (BoQ). This documentation becomes the contractual basis for all future work and payment for the project. CONITT Invitation to tender message At the pre-construction stage of a construction project, the Client will wish to appoint a contractor to execute the works. The first step in this appointment process is to issue an invitation to tender (ITT) to contractors this will require a commercial offer to be made by the contractor to the client. CONPVA Payment valuation message Message used between a contractor and the client's representative, during the process of approving the value and payment for work completed for a given period of time. CONQVA Quantity valuation message Message used by a contractor to submit progress details to a client or his representative. The message may be used also for subsets of the project where work has been contracted out to other parties. In these cases the exchange would be between the subcontractor and the party that subcontracted the work. CONRPW Response of pending works message Message to reply to a CONAPW message and to enable service providers to respond to a contractor giving details of any services and networks in the location where construction work is to be undertaken. CONTEN Tender message Message sent by main contractor or subcontractor for the purposes of submitting a tender which is a commercial offer to execute the project work defined in the bill of quantities within the invitation to tender. CONTRL Syntax and service report message Message syntactically acknowledging or rejecting, with error indication, a received interchange, functional group or message. CONWQD Work item quantity determination message Message used between a contractor and the client's representative or other partners within the construction process, for justifying the work item quantities given in messages that describe the work items or their progress valuations.


COPARN Container announcement message The message contains an order to release, to make available, to accept or to call down containers or to announce the impending arrival of containers. This message is part of a total set of container-related messages. These messages serve to facilitate the intermodal handling of containers by streamlining the information exchange. The business scenario for the container messages is clarified in a separate document, called: 'Guide to the scenario of EDIFACT container messages'. The order may pertain to cargo related containers (full container load and less than container load), the arrangement of empty containers prior to loading and after stripping, as well as the arrangements for leasing the empty containers (on-hire and off-hire of containers). COPINO Container pre-notification message A message by which an inland carrier notifies of the delivery or pick-up of containers. COPRAR Container discharge/loading order message A message to order to the container terminal that the containers specified have to be discharged from a seagoing vessel or have to be loaded into a seagoing vessel. COREOR Container release order message Order to release containers, and giving permission for them to be picked up by or on behalf of a specified party. COSTCO Container stuffing/stripping confirmation message Confirmation that specified goods/consignments have been stuffed into or stripped from LCL-containers. COSTOR Container stuffing/stripping order message Order that specified goods/consignments are to be stuffed into (already or still to be delivered) or stripped from LCL-containers. CREADV Credit advice message Message sent by the account servicing financial institution to the account owner to inform the account owner that its account has been or will be credited for a specified amount on the date indicated, in settlement of the referenced business transaction(s). CREEXT Extended credit advice message Message sent by the account servicing financial institution to the account owner to inform the account owner that its account has been or will be credited for a specified amount on the date indicated, in settlement of the referenced business transaction(s), and to provide to the payee full details of the transactions to which the extended credit advice relates. CREMUL Multiple credit advice message A Multiple Credit Advice message is sent by an Account Servicing Financial Institution to the Account Owner or to a third party, which has agreed bilaterally in advance, that its account(s) has been or will be credited for specified amount(s) on the date(s) indicated, in settlement of the referenced business transaction(s). CUSCAR Customs cargo report message Message to permit the transfer of data from a carrier to a Customs administration for the purpose of meeting Customs cargo reporting requirements. CUSDEC Customs declaration message Message to permit the transfer of data from a declarant to a Customs administration for the purpose of meeting legislative and/or operational requirements in respect of the declaration of goods for import, export or transit.


CUSEXP Customs express consignment declaration message Message to permit the transfer of data from an express carrier to a Customs administration for the purpose of meeting Customs cargo reporting and/or clearance requirements. CUSREP Customs conveyance report message Message to permit the transfer of data from a carrier to a Customs administration for the purpose of meeting Customs reporting requirements in respect of the means of transport on which the cargo is carried. CUSRES Customs response message This Customs Response Message (CUSRES) permits the transfer of data from a customs administration: - to acknowledge the receipt of the message - to indicate whether the information received is correct or if there are errors (i.e. accepted without errors, accepted with errors, rejected, etc.) - to inform the sender of the status of the customs declaration (i.e. goods released, goods for examination, documents required, etc.) - to transmit additional information as agreed between parties (i.e. tax information, quantity information, etc.) - to respond to batched messages (i.e. CUSDEC, CUSCAR, CUSREP, CUSEXP). DEBADV Debit advice message Message sent by the account servicing financial institution to the account owner to inform the account owner that its account has been or will be debited for a specified amount on the date indicated, in settlement of the referenced business transaction(s). DEBMUL Multiple debit advice message A DEBMUL message is sent by an Account Servicing Financial Institution to the Account Owner or to a third party, which has agreed bilaterally in advance, that its account(s) has been or will be debited for specified amount(s) on the date(s) indicated, in settlement of the referenced business transaction(s). DELFOR Delivery schedule message DELFOR is a message which is sent from a party who is planning the use or consumption of products to a party who has to plan for the supply of the products. The message gives the requirements regarding details for short term delivery and/or medium to long scheduling for products. The scheduling can be used to authorize manufacturing and or the provision of materials. This is based on the terms and conditions defined in a purchase order or contract. DELJIT Delivery just in time message Message providing the ability for a customer to convey precise delivery sequence and just-in-time schedule requirements to a supplier, and is intended to supplement the delivery schedule message (DELFOR). DESADV Despatch advice message A message specifying details for goods despatched or ready for despatch under agreed conditions. The United Nations Despatch Advice Message serves both as a specification for Delivery Despatch Advice and also as a Returns Despatch Advice message.


DESTIM Equipment damage and repair estimate message A message for use by the container repair, shipping and leasing industry. It may be used by a container equipment repair depot to send an owner or user a description of damages to the equipment, as an estimate of the repair actions and costs needed to rectify such damages. A recipient owner may forward the estimate to a lessee. The message may also be used by an owner or lessee as an authorization message to the repair depot to perform the repairs indicated in the estimate, and as an acknowledgment of his willingness to pay for those repairs indicated in the estimate for his account. DIRDEB Direct debit message Message sent by the creditor to the creditor's bank instructing it to claim specified amounts from the debtor(s) and to credit these amounts to a single account it services for the creditor in settlement of the referenced transaction(s). DIRDEF Directory definition message The Directory definition message (DIRDEF) permits the transfer of the contents of a UN/EDIFACT Directory set or parts thereof. DOCADV Documentary credit advice message Message to indicate to the beneficiary the terms and conditions of a documentary credit that has been originated by the issuing bank and received by the advising bank (or an intermediary advising bank). DOCAMA Advice of an amendment of a documentary credit message The Advice of an Amendment of a Documentary Credit message is originated by the Advising Bank, or Intermediary Advising Bank, and sent to the Beneficiary. It is used to inform the Beneficiary of the terms and conditions of an amendment to a documentary credit requested by the Applicant. DOCAMI Documentary credit amendment information message The Documentary Credit Amendment Information message is used to indicate the terms and conditions of an amended documentary credit from the Issuing Bank to the Applicant and/or Applicant's Bank. DOCAMR Request for an amendment of a documentary credit message The Request for an Amendment of a Documentary Credit originated by the Applicant, or Applicant's Bank, and sent to the Issuing Bank. It is issued to request the Issuing Bank to amend the terms and conditions of an issued Documentary Credit or to cancel the Documentary Credit. DOCAPP Documentary credit application message Message from a party requesting the issuance of a documentary credit to the party providing such service. In this message, the conditions under which the sender of the message requires the documentary credit to be issued are given. DOCARE Response to an amendment of a documentary credit message The Response to an Amendment of a Documentary Credit originated by the Beneficiary and sent to the parties involved in the documentary credit. It is issued to advise the acceptance or non acceptance of an amendment. DOCINF Documentary credit issuance information message Message to indicate the terms and conditions of an issued documentary credit from the issuing Bank to the applicant and/or the applicant's bank.


FINCAN Financial cancellation message A Financial Cancellation Message is sent by the Ordering Customer (or Payor or Agent on behalf of the Ordering Customer)or by a third party having authority on the Ordering Customer's payments to the Ordered Bank to request cancellation of a given financial message or transaction. FINSTA Financial statement of an account message This message can be used to cater for various communication functions between financial institutions and their customers. The most frequent function is to provide a statement of booked items confirming entries on a customer's account. The message type may contain several accounts (quoted in the B-level). GENRAL General purpose message A message to enable the transmission of textual information. GESMES Generic statistical message The compilation of statistics is a continuous chain starting with raw data collection, followed by a number of harmonization and aggregation processes leading to aggregated statistical data. Raw data collection is realized by means of surveys, sampling, direct reporting from individuals, economic operators. Harmonization and aggregation processes are very often handled by statistical bodies or authorized economic operators in case of direct reporting. A Generic Statistical Message (GESMES) is used by an organisation involved in this elaboration process to transmit a statistical data set. It permits the transmission of the following, either in the same and/or different messages: -the statistical concepts comprising the data set and their structure -if required, all related information ( code sets, labels, methodological notes, footnotes, etc.), -the statistical figures of the data set. This message could be used by producers and users of statistical information such as: National Statistical Offices, ministries, private and public administrations, private companies etc. HANMOV Cargo/goods handling and movement message Message from a party to a warehouse/distribution centre identifying the handling services and where required the movement of specified goods, limited to warehouses within the jurisdiction of the distribution centre. IFCSUM Forwarding and consolidation summary message Message used for consolidation purposes from a party arranging forwarding and transport services to the party for which the transport of the consolidated cargo is destined. The message can be used to exchange information concerning the consolidated cargo between forwarders, carriers and agents enabling those parties to handle the consignments included in the consolidation. In addition it can be used for a collection of consignments originating from one shipper for forwarding and transport services. IFTCCA Forwarding and transport shipment charge calculation message Message to request the calculation of the transport charges of a specific shipment and to answer to such a request.


IFTDGN Dangerous goods notification message Message from the party responsible to declare the dangerous goods (e.g. carrier's agent, freight forwarder) to the party acting on behalf of the local authority performing the checks on conformance with the legal requirements on the control of dangerous goods, normally Port Authority, conveying the information relating to one conveyance/voyage of a means of transport such as a vessel, train, truck or barge, on the dangerous goods being loaded, unloaded, and/or in transit. IFTFCC International transport freight costs and other charges message A message specifying freight, handling and transport costs and other related charges between transport service providers and their customers. IFTIAG Dangerous cargo list message The International Forwarding and Transport Dangerous Cargo List Message is a message: - from the party acting on behalf of the carrier for the gathering of the dangerous goods information of the cargo in a certain port or place of call or loading, - to the party acting on behalf of the carrier in the next port or place of call or discharge, conveying the information relating to one conveyance or voyage of a means of transport such as a vessel, train, truck or barge, on the dangerous goods being carried on board - irrespective of the operations that will take place in the next port of call. This message provides the basic information by which the message recipient can notify to the local authorities about the loading, unloading and transit-related operations, by means of the International forwarding and transport dangerous goods notification message (IFTDGN). IFTMAN Arrival notice message Message from the party providing forwarding and/or transport services to the party such as has been indicated in the contract, giving notice and details of the arrival of the consignment. IFTMBC Booking confirmation message Message from the party providing forwarding and/or transport services to the party booking those services giving the confirmation information to the booking of the consignment concerned. A confirmation might read that the booking of a consignment is accepted, pending, conditionally accepted or rejected. The conditions under which requested services take place may be given in this message. IFTMBF Firm booking message Message from a party definitely booking forwarding and/or transport services for a consignment to the party providing those services. The message will contain the conditions under which the sender of the messages requires the services to take place. IFTMBP Provisional booking message Message from a party requesting space and/or giving brief details of a planned consignment for forwarding and/or transport services to the party providing those services. In this message, the conditions under which the planned transport should take place can be given. IFTMCS Instruction contract status message Message from the party providing the transport/forwarding services to the party that issued the instructions for those services stating the actual details, terms and conditions (charges when applicable) of the service and of the consignment involved. In addition it can be used for the exchange of contract information between carriers mutually.


IFTMIN Instruction message Message from the party issuing an instruction regarding forwarding/transport services for a consignment under conditions agreed, to the party arranging the forwarding and/or transport services. IFTRIN Forwarding and transport rate information message Message to request transport rate information and to answer to such a message. IFTSAI Forwarding and transport schedule and availability information message Message to request transport schedule or availability information and to answer such a request. IFTSTA International multimodal status report message Message to report the transport status and/or a change in the transport status (i.e. event) between agreed parties. IFTSTQ International multimodal status request message Message to request an international multimodal status report message (IFTSTA) in order to provide details relating to transport status and/or a change in the transport status between agreed parties. INSPRE Insurance premium message Message used by communicating parties to notify the recipient about premiums due from a client. All information needed to produce a detailed request for payment can be sent. INVOIC Invoice message Message claiming payment for goods or services supplied under conditions agreed between the seller and the buyer. The UNSM invoice message, with correct data qualification, serves also as the specification for debit note and credit note messages. INVRPT Inventory report message Message specifying information relating to held inventories. The inventory report message is intended to be used in either direction between trading partners. ITRRPT In transit report detail message A message specifying to a delivery party, the details of goods within grouped consignments despatched by the delivering party. This message is used in a multi-step transportation process involving only consignors, grouping centres and consignees. A grouping centre (consolidation point) is a logistic point where goods are moved from one means of transport to another, to optimize transport cost. This message is not to be used to identify additional services related to the despatched goods (warehousing, packaging, etc.) which may provided by the third party at the same location along with the Grouping service. JAPRES Job application result message Message specifying decisions of an employer related to job applications and interviews and employment or rejections and, when necessary, reasons for the decisions or rejections. The message is transmitted from an employer or employment agency to an employment agency. JINFDE Job information demand message Message sent by a governmental agency to an employer in response to a work grant request. This message asks for specific additional information (e.g. visa) for further processing of the work grant request. JOBAPP Job application proposal message Message specifying detailed information of proposals for one or more job applicants from an employment agency to an employer. The detailed information is related to profession, occupation, age, education, experiences, salaries, other benefits, requested location of the job, work and contract conditions.


JOBCON Job order confirmation message The message intent is to confirm the receipt of information of a Job Order Message related to a vacancy or vacancies. The message is transmitted from an employment agency to an employer. The information is related to age, sex, profession, salaries, experiences, education, work and contract conditions. JOBMOD Job order modification message A message specifying modifications of a previously sent Job Order Message of one or more offered jobs or vacancies in an enterprise or organization. The Job Order Modification Message is transmitted from an employer or employment agency to an employment office. The information and the changes detailed in the message are related to profession, experiences, salaries, education, work and contract conditions. JOBOFF Job order message A message specifying details for one or more vacancies (occupation, salaries, experiences, work and contract conditions) for an employer to the employment agency. MEDPID Person identification message The message is used to pass detailed information on persons from, for instance, health insurance agencies to local government in order to verify, add, change or delete person related data in information systems. The message may also be used to transfer person information between various application systems within one organisation (i.e hospital). MEDREQ Medical service request message A Medical Service Request message is sent from a service requester to the service provider to order investigations, to modify a previous order or ordered investigation or to cancel a previous order. MEDRPT Medical service report message A Medical Service Report message is sent from a service provider to the service requester to report new results on performed investigations, to modify a previous result item or a complete result report or to cancel a previous result report. MOVINS Stowage instruction message Message containing details of one means of transport vehicle, giving instructions regarding the loading, discharging and restowage of equipment and/or cargoes and the location on the means of transport where the operation must take place. ORDCHG Purchase order change request message Message from the buyer to the seller, specifying details of the buyer's request to change a purchase order. ORDERS Purchase order message Message specifying details for goods or services ordered under conditions agreed between the seller and the buyer. ORDRSP Purchase order response message Message from the seller to the buyer, responding to a purchase order message or a purchase order change request message. PARTIN Party information message Message to enable the transmission of basic information regarding locations and the related operational, administrative, financial, manufacturing and trading data. PAXLST Passenger list message Message to permit the transfer of passenger/crew data (where national privacy legislation permits and with agreement of all parties involved) from a customs, immigration or other designated authority in the country of departure to the appropriate authorities in the country of arrival of the means of transport.


PAYDUC Payroll deductions advice message Message sent by a party to a service providing organisation, to detail payments by payroll deductions, on behalf of employees, made to the service providing organisation. PAYEXT Extended payment order message Message sent by the ordering customer (or payor or agent on behalf of the ordering customer) to the ordered bank, to instruct the ordered bank to debit an account it services for the ordering customer, and to arrange for the payment of a specified amount to the beneficiary (or payee or agent in favour of beneficiary) in settlement of the referenced business transaction(s), and to provide to the payee full details of the transactions to which the extended payment order relates. PAYMUL Multiple payment order message Message sent by the ordering customer (or payor or agent on behalf of the ordering customer) to the ordered bank, to instruct the ordered bank to debit an account it services for the ordering customer, and to arrange for the payment of specified amounts to several beneficiaries (or payees) in settlement of the referenced business transaction(s). PAYORD Payment order message Message sent by the ordering customer (or payor or agent on behalf of the ordering customer) to the ordered bank, to instruct the ordered bank to debit an account it services for the ordering customer, and to arrange for the payment of a specified amount to the beneficiary (or payee or agent in favour of beneficiary) in settlement of the referenced business transaction(s). PRICAT Price/sales catalogue message Message to enable the transmission of information regarding pricing and catalogue details for goods and services offered by a seller to a buyer. PRODAT Product data message A message to submit master data - a set of data that is rarely changed - to identify and describe products a supplier offers to his (potential) customer or buyer. This information of long validity includes technical and functional product description but not commercial terms and conditions. This message can be used as well to update the information on a previously sent PRODAT message. PRODEX Product exchange reconciliation message Message used as a communication between two trading partners with agreements for the loan of products to each other, to provide information about movements of products from and to various locations on particular dates. PRPAID Insurance premium payment message Message used by communicating parties to notify the recipient about premiums to be collected, paid, not paid or partly paid, either individually or in series via bordereaux or statements. QALITY Quality data message Message to enable the transmission of the results of tests performed to satisfy a specified product or process requirement. The content includes, but it is not limited to, test data and measurements, statistical information, and the testing methods employed. QUOTES Quote message Message which provides potential sellers with the ability to provide price, delivery schedule, and other conditions for potential sales of goods or services.


RDRMES Raw data reporting message A Raw data reporting message (RDRMES) is sent in response to predefined and identified questions. Raw data are collected by numerous offices in the public and private sectors. Much of the data is predefined and repetitious. The data are often codified such that their description has been pre-set and meets the criteria of the collector. REBORD Reinsurance bordereau message A reinsurance bordereau message is made of individual policy data and their impact on a reinsurance contract. More specifically, the REBORD can be used to report how the reinsurance premiums or claims figures are built up, or to report individual cessions affecting a reinsurance contract. RECADV Receiving advice message This message is to address the business needs related to the goods receipt. This message is used to report the physical receipt of goods. The message allows for the reporting of discrepancies in products, quantities, terms, packages, etc. RECALC Reinsurance calculation message RECALC is a generic message used in reinsurance environment to show various types of calculation that are either based on the loss ratio or on the technical result of a reinsurance contract or program, mainly in the area of commissions and commission adjustments and in stop loss claims. This message supports results shown in the RETACC message. RECECO Credit risk cover message Message to apply for preliminary credit assessment (used during negotiation with prospective clients); apply for credit protection; reply to credit requests; revise amount and expiry date of credit protection and terms; cancel credit protection. The message will serve at the same time as the request for credit risk cover and as the answer (approval or rejection to that request). RECLAM Reinsurance claims message A reinsurance claims message is exchanged between insurers, professional intermediaries, reinsurers to send information concerning a loss and/or to request settlement (payment or refund) concerning the loss. REMADV Remittance advice message Message which provides a detailed accounting relative to a payment, or other form of financial settlement, on a specified date for the provision of goods and/or services as detailed in the advice. REPREM Reinsurance premium message The Reinsurance Premium Message (REPREM) allows to support the technical entries for any premium or brokerage adjustment amount. For this purpose, it enables to render all the relevant data (mainly amounts and the way they are built up) used in the actual calculation of the adjustment, as well as the other relevant elements used in the specific formula. REQDOC Request for document message Message to enable a party to request the sending, or re- sending, of data, either as a document or message, or in some other agreed form. REQOTE Request for quote message Message which provides potential buyers with the ability to solicit price, delivery schedule, and other conditions from potential sellers of goods or services.


RESETT Reinsurance settlement message A reinsurance settlement message is exchanged by insurers, reinsurers, bureaux, brokers and professional reinsurance intermediaries to send all information that enables to identify, reconcile and set-off technical accounts. RESMSG Reservation message A Reservation message is sent by a tourism operator to one or more service providers in order to request desired services. These services may be subject to confirmation by any of the parties concerned. RESREQ Reservation request - interactive message An interactive Travel, Tourism and Leisure Reservations Request is sent by a customer or his agent, to a service provider to reserve, modify or cancel a Travel, Tourism and Leisure service. The Travel, Tourism and Leisure Reservation Response - Interactive message (RESRSP) is utilised to provide an interactive response to the interactive service request. RESRSP Reservation response - interactive message An interactive Travel, Tourism and Leisure Reservations Response is sent by a customer or his agent, to convey the results of a reservations request for a Travel, Tourism and Leisure service. The Travel, Tourism and Leisure Reservation Request - Interactive message (RESREQ) is utilised to provide the interactive request to which the RESRSP is used to respond. RETACC Reinsurance technical account message The RETACC is used by the sender to report to the receiver the latter's position in the sender's books with respect to one single reinsurance contract. It is in this sense a type of account for services rendered, and may initiate a payment flow either directly or via a periodical overview statement. SAFHAZ Safety and hazard data message The Safety and hazard data message is to enable the communication of safety data and advice on relevant materials supplied to industrial customers so as to enable them to take measures to protect their employees and the environment from any potential harmful effects from these materials. SANCRT International movement of goods governmental regulatory message The SANCRT message permits a commercial operator to apply to a national agency for the issue of a certificate, permit, authorization etc. in respect of products to be imported or exported. It further permits the issuing authority to transmit to the applicant and to the exporting or importing country's relevant national authority, (e.g. Customs, Agriculture etc.) the details of the certificate, permit or authorization in respect of those products thus facilitating the import/export clearance of the consignment whilst ensuring that all certificate, permit, authorization requirements are met. SLSFCT Sales forecast message Message to enable the transmission of forecast data related to products or services, such as corresponding location, period, product identification, pricing, monetary amount, quantity, market sector information, sales parties. It enables the recipient to process the information automatically and use it for production, planning, marketing, statistical purposes, etc.


SLSRPT Sales data report message Message to enable the transmission of sales data related to products or services, such as corresponding location, period, product identification, pricing, monetary amount, quantity, market sector information, sales parties. It enables the recipient to process the information automatically and use it for production, planning, marketing, statistical purposes, etc. SSIMOD Modification of identity details message The SSIMOD message is sent to communicate to the country of first registration the modification of identity details which took place since the last transmission related to the worker. SSRECH Worker's insurance history message The SSRECH message is sent by a designated body in one State to the equivalent body in another State giving details of a worker's Social Security insurance history as requested by the latter State. SSREGW Notification of registration of a worker message The SSREGW message is exchanged between designated bodies to enable interchange and registration of a worker's social security number. The message is also exchanged by designated bodies to request and compile details of worker's social security insurance record. STATAC Statement of account message Message from a seller or his agent to a buyer or his agent, providing information about the status of the account at a specific point in time. It is used as an aid to reconciliation. At the same time it may be a reminder of payment due. SUPCOT Superannuation contributions advice message Message sent by a party to an organisation administering a superannuation scheme, to detail contribution payments made for members of the superannuation scheme. SUPMAN Superannuation maintenance message Message sent by a party to an organisation administering a superannuation scheme, to specify membership maintenance information about superannuation scheme members. SUPRES Supplier response message A Reservation message is sent by a tourism operator to one or more service providers in order to request desired services. These services may be subject to confirmation by any of the parties concerned. The Supplier response presented herein is the response to the Reservation message (RESMSG). TANSTA Tank status report message A message from a vessel to the shipplanning department of a shipping line and vice versa (e.g. via satellite), giving details about the contents of ballast tanks, fuel tanks, water tanks and other figures necessary for the calculation of the stability of the vessel.


VATDEC Value added tax message This VAT Declaration Message (VATDEC) permits the transfer of data from a declarant to a national VAT collecting authority for the purpose of meeting legislative and/or operational requirements in respect of the declarations of VAT. The declarant may be a taxpayer who is obliged to send VAT returns the authorities, or an accountant or others who on behalf of one several taxpayers send VAT returns to the authorities and who is mandated to do so by the authorities and the taxpayer. The declaration may contain one or several returns. The message may also be used, for example: - within the European Union, to transmit VAT summary information for the Value Added Tax Information Exchange System (VIES) from a declarant to the relevant national VIES collecting authorities. - to transmit other related or comparable VAT information from a declarant to the relevant authorities. VESDEP Vessel departure message A message from a stevedore to a liner agent or from a liner agent to a local authority (e.g. port authority) to inform the latter party of the departure of a vessel and giving information on the actual container or cargo operations. WKGRDC Work grant decision message Message specifying details of decisions of the governmental agency to an employer relating to a work grant request or permit for one or more workers. WKGRRE Work grant request message Message specifying details of requests to a governmental authority from an employer for workers who need a work grant or permit.

----------------------------------------------------------------------

0073 FIRST AND LAST TRANSFER

Desc: Indication used for the first and last message in a sequence of messages related to the same topic.

Repr: a1

C Creation First transmission of a number of transfers of the same message.

F Final Last transmission of a number of transfers of the same message.

----------------------------------------------------------------------


---------------------------------------------------------------------- 0081 SECTION IDENTIFICATION

Desc: To identify the separation of sections of a message.

Repr: a1

D Header/detail section separation To qualify the segment UNS, when separating the header from the detail section of a message. S Detail/summary section separation To qualify the segment UNS, when separating the detail from the summary section of a message.

----------------------------------------------------------------------

0135 SERVICE SEGMENT TAG, CODED

Desc: Code identifying a service segment.

Repr: an..3

UIB Interactive interchange header To head and identify an interchange. UIH Interactive message header To head, identify and specify a message. UIR Interactive status To report the status of the dialogue. UIT Interactive message trailer To end and check the completeness of a message. UIZ Interactive interchange trailer To end and check the completeness of an interchange. UNB Interchange header To identify an interchange. UNE Group trailer To end and check the completeness of a group UNG Group header To head, identify and specify a group of messages and/or packages, which may be used for internal routing and which may contain one or more message types and/or packages. UNH Message header To head, identify and specify a message. UNO Object header To head, identify and specify an object. UNP Object trailer To end and check the completeness of an object. UNS Section control To separate header, detail and summary sections of a message. UNT Message trailer To end and check the completeness of a message. UNZ Interchange trailer To end and check the completeness of an interchange.

----------------------------------------------------------------------


---------------------------------------------------------------------- 0323 TRANSFER POSITION, CODED

Desc: Indication of the position of a transfer.

Repr: a1

F First message First message in sequence. Can only appear once at the start of the sequence. I Intermediate Intermediate message in sequence. May appear zero or more times within the sequence. L Last message Last message in sequence. Can appear only once at the end the sequence.

----------------------------------------------------------------------

0325 DUPLICATE INDICATOR

Desc: Indication that the structure is a duplicate of a previously sent structure.

Repr: a1

D Duplicate A Duplicate transfer.

----------------------------------------------------------------------

0331 REPORT FUNCTION, CODED

Desc: Coded value identifying type of status or error report.

Repr: an..3

1 Information Non Error information, e.g. acknowledgement that party is still operational. 2 Warning Warning, e.g. resources getting low. 3 Non-fatal error Non-fatal error detected by party sending the UIR. Dialogue integrity may be compromised. 4 Fatal Established dialogue cannot continue. 5 Query status Request for a status report from other party. Should be answered with a 'Status report' (see code value '6' below). 6 Status report Reporting status of dialogue as perceived by sending party. 7 Pause Dialogue Advise other party to stop transferring data within this dialogue until a 'Continue dialogue' is received. 8 Continue Dialogue Advise that data flow may continue after being 'Paused' (see code value '7' above). 9 Dialogue reject Dialogue cannot be initiated.

----------------------------------------------------------------------


---------------------------------------------------------------------- 0333 REPORT REASON, CODED

Desc: Code identifying the reason for the status or error report.

Repr: an..3

1 OK response No further information. 2 Syntax error Error detected in syntax. 3 Invalid header Invalid header segment received. 4 Invalid trailer segment Invalid trailer segment received. 5 Unsupported syntax Syntax version/release not supported. 6 Unsupported scenario type Scenario type not supported. 7 Unsupported scenario version Scenario version/release not supported. 8 Unsupported dialogue type Dialogue type not supported for this scenario. 9 Unsupported dialogue version Dialogue type version/release not supported. 10 Unauthorised sender Sender not authorised. 11 Sender rejected Sender rejected for administrative reasons. 12 Multiple transactions unsupported Multiple parallel transactions not supported. 13 Multiple dialogues unsupported Multiple parallel dialogues not supported. 14 Resources unavailable Resources unavailable for requested function. 15 Unknown transaction Referenced transaction does not exist. 16 Unknown dialogue Referenced dialogue does not exist. 17 Invalid function Function invalid for current dialogue state. 18 Service unavailable Requested service is unavailable. 19 Application unavailable Requested application not available. 20 Time-out Response not received within expected time.

----------------------------------------------------------------------


---------------------------------------------------------------------- 0805 OBJECT TYPE QUALIFIER

Desc: Qualifier referring to the type of object.

Repr: an..3

1 Computer environment type Specification of the type of computer environment for which the object is intended. 2 Computer environment version Specification of the version of the computer environment for which the object is intended. 3 Computer environment release Specification of the release of the computer environment for which the object is intended. 5 Computer environment name Specification of the name of the computer environment for which the object is intended. 6 Non-EDIFACT security level code Specification of the level such as interchange, group or message at which non-EDIFACT security is applied to the data constituting the object. 7 Non-EDIFACT security version Specification of the version of the non-EDIFACT security technique applied to the data constituting the object. 8 Non-EDIFACT security release Specification of the release of the non-EDIFACT security technique applied to the data constituting the object. 9 Non-EDIFACT security technique Specification of the non-EDIFACT security technique applied to the data constituting the object. 10 Non-EDIFACT security free text information Free form description of the non-EDIFACT security technique applied to the data constituting the object. 11 File identification by number Identification number assigned to the file constituting the object. 12 File identification by name Name assigned to the file constituting the object. 13 File format Specification of the format of the file constituting the object. 14 File version Specification of the version of the file constituting the object. 15 File release Specification of the release of the file constituting the object. 16 File status Specification of the status of the file constituting the object. 17 File size Specification of the size of the file constituting the object in bytes. 18 File description Free form description of the file constituting the object. 19 File block type Specification of the type of blocking used to partition the file constituting the object. 20 File block length Specification of the length of the blocks used to partition the file constituting the object.


21 File record length Specification of the length of the records contained in the file constituting the object expressed as the number of character positions. 22 Program identification by number Identification number assigned to the program constituting the object. 23 Program identification by name Name assigned to the program constituting the object. 24 Program type Specification of the type of program constituting the object. 25 Program version Specification of the version of the program constituting the object. 26 Program release Specification of the release of the program constituting the object. 27 Program status Specification of the status of the program constituting the object. 28 Program description Free form description of the program constituting the object. 29 Program size Specification of the size of the program constituting the object in bytes. 30 Interchange format Specification of the format of the interchange constituting the object. 31 Interchange version Specification of the version of the interchange constituting the object. 32 Interchange release Specification of the release of the interchange constituting the object. 33 Interchange status Specification of the status of the interchange constituting the object. 34 Interchange identification Identification number assigned to the interchange constituting the object. 35 Compression technique identification An identification assigned to the compression technique applied to the object. 36 Compression technique version Specification of the version of the compression technique applied to the object. 37 Compression technique release Specification of the release of the compression technique applied to the object. 38 Drawing identification by name Name assigned to the drawing constituting the object. 39 Drawing identification by number Identification number assigned to the drawing constituting the object. 40 Drawing type Specification of the type of drawing constituting the object. 41 Drawing format Specification of the format of the drawing constituting the object. 42 Drawing version Specification of the version of the drawing constituting the object.


43 Drawing release Specification of the release of the drawing constituting the object. 44 Drawing status Specification of the status of the drawing constituting the object. 45 Drawing size Specification of the size of the drawing constituting the object in bytes. 46 Drawing description Free form description of the drawing constituting the object. 48 Filter type Specification of the type of filtering technique applied to the object. 49 Filter version Specification of the version of the filtering technique applied to the object. 50 Filter code page Specification of the code page used for the filtering technique applied to the object. 51 Filter technique Specification of the filtering technique applied to the object. 52 Character set repertoire identification Identification of the character set repertoire used for the object. 53 Character set encoding technique Specification of the character set encoding technique used for the object. 54 Character set encoding technique code page Specification of the code page used for the character set encoding technique used for the object. 55 Certificate type Specification of the type of certificate constituting the object. 56 Certificate version Specification of the version of the certificate constituting the object. 57 Certificate release Specification of the release of the certificate constituting the object. 58 Certificate status Specification of the status of the certificate constituting the object. 60 Certificate identification by name Name assigned to the certificate constituting the object. 61 Certificate identification by number Identification number assigned to the certificate constituting the object. 62 Certificate format Specification of the format of the certificate constituting the object. 63 Certificate code page Specification of the code page used when generating the certificate constituting the object.

----------------------------------------------------------------------


---------------------------------------------------------------------- 0813 REFERENCE QUALIFIER

Desc: Code giving specific meaning to a reference identification number.

Repr: an..3

1 Object identification number Identification number assigned to an object. 2 Application message reference number Reference number assigned to a message by a computer application.

------------------------------------------------------------------------------


Annex E(informative)

Order of segments and groups of segments within a message

E.1 General

Segments used in a message appear in the sequence (top to bottom) specified in the message segmenttable.

In the message segment table, segments are indicated by their tags. The requirement for their inclusion inthe message i.e. their status, is indicated by the letter M for mandatory or C for conditional. The number oftimes a segment may occur in each instance is indicated directly thereafter. This may be followed by anyassociated dependency note identifier(s).

In the message segment table, segment groups are indicated by their segment group number. Therequirement for their inclusion in the message i.e. their status, is indicated by the letter M for mandatory orC for conditional. The number of times a segment group may occur in each instance is indicated directlythereafter. This may be followed by any associated dependency note identifier(s).

E.2 Segment groups

Two or more segments can be grouped, as shown in figure 1. The trigger segment of each segment groupappears in the message segment table immediately following the segment group identification (i.e. segmentgroup 1, 2 etc.). All other segments within the segment group follow in sequence, with the last segment inthe group identified by the boundary lines specifying the extent of the segment group.

A segment group can contain another dependent segment group or groups (e.g. segment group 2 contains adependent segment group 3 in the figure), and, as can be seen in the figure, a segment can terminate two(or more) segment groups, as indicated by the segment group boundary lines (segment LLL in the figure.)

In the figure, segment group 2 is the parent of segment group 3, and segment group 3 is the parent ofsegment group 4.


E.2.1 Figure 1

-----------------------------------------------------------------------------

POS TAG Name S R Notes

0010 Uxx Message header M 10020 AAA Segment AAA name M 10030 BBB Segment BBB name C 90040 CCC Segment CCC name C 90050 ---------- Segment group 1 ------------------ C 999 -------+0060 DDD Segment DDD name M 1 |0070 EEE Segment EEE name C 9 |0080 FFF Segment FFF name C 9 |0090 GGG Segment GGG name C 1 -------+0100 ---------- Segment group 2 ------------------ C 9 -------+0110 HHH Segment HHH name M 1 | |0120 ---------- Segment group 3 ------------------ C 9 ------++0130 III Segment III name M 1 ||0140 JJJ Segment JJJ name C 9 || ||0150 ---------- Segment group 4 ------------------ C 9 -----+||0160 KKK Segment KKK name M 1 |||0170 LLL Segment LLL name C 9 -----+++ . . . .nnnn Uxx Message trailer M 1

-----------------------------------------------------------------------------

Figure 1 - Example message segment table

Legend

POS The sequential position number of the segment or segment group in the message(in steps of 10 to permit later amendment to message structures)

TAG The tag of the segment in the message

Name The name of the segment in the message

S The status (of the segment or segment group) i.e. M = Mandatory, C = Conditional

R The maximum number of occurrences of the segment or segment group

Notes The note number


E.2.2 Figure 1 Notes

1. An example of the processing/sequencing order of the segments (using the segment tags only) is asfollows (with segment group 1 appearing twice, the other groups once, and with repeating segmentsshown as appearing once only):

Uxx,AAA,BBB,CCC,DDD,EEE,FFF,GGG,DDD,EEE,FFF,GGG,HHH,III,JJJ,KKK,LLL,...Uxx

2. In the segment table and in the segment string shown above, the first "Uxx Message Header" wouldbe "UNH" for batch EDI, and "UIH" for interactive EDI; the second "Uxx Message trailer" would be"UNT" for batch EDI and "UIT" for interactive EDI.

____________________