Commission Regulation (EU) No 164/2010Show full title

1. PART I: MESSAGE IMPLEMENTATION MANUAL CONVENTION

1.1. Introduction

The technical specifications define the structure of four messages for electronic ship reporting in inland navigation, based on the UN/EDIFACT message structure (see also chapter 1.2) and customised, where required, for the purpose of inland navigation.

In the case that electronic ship reporting in inland navigation is required by national or international law, these technical specifications shall be applied.

The messages are:

1.

(Dangerous) goods reporting (IFTDGN) — ERINOT

2.

Passenger and crew lists (PAXLST)

3.

ERINOT response and receipt message (APERAK) — ERIRSP

4.

Berth management port notification (BERMAN)

In the Appendices (message implementation manuals) the exact use of the messages, data elements and codes is defined in order to ensure a common understanding and usage of the messages.

The use of XML technology is another possibility. The standardisation of XML message definition for the purpose of electronic ship reporting in inland navigation is dealt with by the relevant working group supporting the Committee established pursuant to Article 7 of Council Directive 91/672/EEC of 16 December 1991 on the reciprocal recognition of national boatmasters’ certificates for the carriage of goods and passenger.

1.2. UN/EDIFACT message structure

The following elaborations are based on ISO 9735.

UN/EDIFACT messages are composed of segments. The structure of a message is described in a branching diagram indicating the position and the mutual relationship of the segments and segment groups.

For each segment the data elements are defined which are to be used in a message. Some data elements are combined to form composite data elements. The messages follow a fixed syntax as defined in ISO 9735.

A segment and a data element within a segment are either mandatory or conditional. Mandatory segments and/or data elements contain important data for a receiving application and shall be filled with sensible, in other words valid data. Conditional elements need not to be present in a message.

Each message starts with two or three segments, the ‘interchange header’ (UNB) and the ‘message header’ (UNH). Where required also the ‘service string advice’ (UNA) is used as a first segment to define which character sets are used in the message. Each message finishes with the segments ‘message trailer’ (UNT) and ‘interchange trailer’ (UNZ). Thus each message is contained in one interchange, and an interchange contains only one single message.

1.2.1. Description of the segments and data elements

In the message descriptions the following indicators are used:

Column 1 contains the name in form of the acronym (TAG) of the segment group, represented by the hierarchy of segment names on higher levels. This indication is derived from the branching diagram.

Column 2 contains the name in form of the acronym (TAG) of the segment, the number of the composite data element and the number of the data element.

Column 3 indicates the level on which the segment is situated in the branching diagram.

Column 4 indicates whether the segment or data element is mandatory (M) or conditional (C).

Column 5 defines the format of the data element.

Column 6 gives the UN/EDIFACT name of the data element. The names of segments are written in bold upper cases, the names of composite data elements are written in normal upper cases and the names of data elements are written in normal lower cases.

Column 7 gives a description of the data elements (fields). If a fixed value is to be used, the value is indicated in quotes.

1.2.2. Syntax

The full description of the data elements in the service segments is part of ISO 7372 Trade Data Elements Directory.

1.2.2.1. Character sets

For the characters in the sets below, the 7-bit codes in the basic code table in ISO 646 shall be used, unless the corresponding 8-bit codes in ISO 6937 and ISO 8859 or other bit codes are specifically agreed between the interchanging partners through the usage of the UNA segment.

Level A character set:

Description	Code	Remarks
Letters	upper case A to Z
Numerals	0 to 9
Space character
Full stop	.
Comma	,
Hyphen/minus sign	—
Opening parenthesis	(
Closing parenthesis	)
Oblique stroke (slash)	/
Equals sign	=
Apostrophe	'	Reserved for use as segment terminator
Plus sign	+	Reserved for use as segment tag and data element separator
Colon	:	Reserved for use as component data element separator
Question mark	?	Reserved for use as release character? immediately preceding one of the characters ' + : ? restores their normal meaning. For example, 10? + 10 = 20 means 10 + 10 = 20. Question mark is represented by ??.

The following characters are also part of the level A character set.

Description	Code
Exclamation mark	!
Quotation mark	"
Percentage sign	%
Ampersand	&
Asterisk	*
Semi-colon	;
Less-than sign	<
Greater-than sign	>

1.2.2.2. Interchange structures

The service string advice, UNA, and the service segments UNB to UNZ shall appear in the order stated in an interchange. See chapter 1.2.2.3.

There may be several functional groups within an interchange.

A message consists of segments. The structures for segments and for data elements therein are shown in chapter 1.2.2.5.

1.2.2.3. Interchange

An interchanges consists of:

Service String Advice UNA Conditional

– – – – – – – – – – Interchange Header UNB Mandatory

| – – – – – – Message Header UNH Mandatory

| | User Data Segments described in the Annex implementation manual

| – – – – – – Message Trailer UNT Mandatory

– – – – – – – – – – Interchange Trailer UNZ Mandatory

1.2.2.4. Order of segments and groups of segments within a message

Message structure diagrams and the order of the segments following the processing rules can be found in the Appendices.

1.2.2.5. Segment structure

Segment Tag: Mandatory

Segment Code: Mandatory component data element

Component D.E. separator: Conditional

Nesting and repeating indication: Conditional component data element(s)

Data element separator: Mandatory

Simple or composite data elements: Mandatory or Conditional as specified in the relevant segments directory and implementation manual

Segment Terminator: Mandatory

1.2.2.6. Data element structure

Simple Data Element:

Mandatory or Conditional as specified in the relevant implementation guideline.

Composite Data Element:

In accordance with segments directory and as specified in the implementation manual.

Component data elements and Component data element separators:

Mandatory (see restriction below)

Data element separator: Mandatory (see restriction below)

Restriction:

There shall be no component data element separator after the last component data element in a composite data element and no data element separator after the last data element in a segment.

1.2.2.7. Compressing

In data elements for which the Data Elements Directory specifies variable length and in the case that there are no other restrictions, insignificant character positions shall be suppressed. In the case of insignificant characters, leading zeroes and trailing spaces shall be suppressed.

However, a single zero before a decimal sign is significant and a zero may be significant (e.g. to indicate a temperature) if so stated in the data elements specification of the implementation manuals.

When compressing messages, the following rules shall be followed.

(a) Exclusion of segments

Conditional segments containing no data shall be omitted (including their segment tags).

(b) Exclusion of data elements by omission

Data elements are identified by their sequential positions within the segment as stated in the Segment Directory. If a conditional data element is omitted and if it is followed by another data element, its position shall be indicated by retention of its data element separator.

Tag+DE+DE+++DE+DE+DE’

|_|_______________ These two data elements are omitted

(c) Exclusion of data elements by truncation

If one or more conditional data elements at the end of a segment are omitted, the segment may be truncated by the segment terminator, i.e. contiguous trailing data element separators are not required to be transmitted.

Tag+DE+DE+++DE' Using the example from 2.2.7 b, the last two data elements have been omitted and by '|____ the segment has been truncated.

(d) Exclusion of component data elements by omission

Component data elements are identified by their given sequential positions within a composite data element. If a conditional component data element is omitted and is followed by another component data element, its given position shall be represented by its component data element separator.

Tag+DE+CE:CE+CE:::CE'

|_|_____ Two component data elements omitted in the last composite data element.

(e) Exclusion of component data elements by truncation

One or more conditional component data elements at the end of a composite data element may be excluded by truncation by the data element separator or, if at the end of a segment, by the segment terminator.

Tag+DE+CE+CE' The last component data element in the first composite data element |___|___ has been omitted and also three component data elements in the last composite data element. In both cases the composite data elements have been truncated, indicated in the first case by the data element separator and in the second case by the segment terminator.

1.2.2.8. Representation of numeric data element values

(a) Decimal sign

The ISO representation for a decimal sign is the comma (,) but a point on the line (.) is allowed (see ISO 31-0: 1981). Both these characters are part of the Level A and B sets. When the service string advice, UNA, is used, its third character specifies the character used in the interchange. It is however strongly recommended to use as a default the (,) to represent a decimal sign under all circumstances. The decimal sign shall not be counted as a character of the value when computing the maximum field length of a data element. However, allowance shall be made for the character in transmission and reception. When a decimal sign is transmitted, there shall be at least one digit before and after the decimal sign. For values represented by integers only, neither a decimal sign nor decimal zeroes are used unless there is a need to indicate the degree of precision.

Preferred: 0,5 and 2 and 2,0 Not allowed: ,5 or .5 or 2, or 2.

(b) Triad separator

Triad separators shall not be used in interchange.

Allowed: 2500000 Not allowed: 2,500,000 or 2.500.000 or 2 500 000

(c) Sign

Numeric data element values shall be regarded as positive. Although conceptually a deduction is negative, it shall be represented by a positive value and such cases shall be indicated in the data elements directory. lf a value is to be indicated as negative, it shall in transmission be immediately preceded by a minus sign, e.g. -112. The minus sign shall not be counted as a character of the value when computing the maximum field length of a data element. However, allowance shall be made for the character in transmission and reception.

Legend:

Ref.

The numeric reference tag for the data element as stated in ISO 7372 UNTDED and, when preceded by S, reference for a composite data element used in service segments.

Name

• Name of COMPOSITE DATA ELEMENT in capital letters

• Name of DATA ELEMENT in capital letters

• Name of Component data element in small letters

Repr.

• Data value representation:

• a — alphabetic characters

• n — numeric characters

• an — alphanumeric characters

• a3 — 3 alphabetic characters, fixed length

• n3 — 3 numeric characters, fixed length

• an3 — 3 alphanumeric characters, fixed length

• a..3 — up to 3 alphabetic characters

• n..3 — up to 3 numeric characters

• an..3 — up to 3 alphanumeric characters

• M — Mandatory element

• C — Conditional element.

When the composite data element is used, a mandatory component data element in a conditional composite data element shall appear.

If in the message implementation manuals a smaller number is used than the ISO standard requires, then this shall be indicated within brackets. The remaining space in a data element shall be filled with space characters.

The usage indicators in the message implementation manuals are as follows:

UNSM Usage	Usage	Indicator in this message implementation manual
Mandatory (M)	Mandatory (M)	mandatory (M)
Conditional (C)	Required (R)	always required (M)
Conditional (C)	Advised (A)	usage of e.g. a certain code set is strongly advised
Conditional (C)	Dependent (D)	usage of the entity depends upon well defined conditions
Conditional (C)	Optional (O)	usage is at the need or discretion of the sender of the message
Conditional (C)	Not Used (X)	not to be used (n. a.)

In the implementation manuals of the messages the usage indicators are used explicitly to ensure a uniform use within electronic ship reporting in inland navigation. Throughout the document reference is made to indicators (M, R, A, D, O and X) which are shown adjacent to data items and which dictate for the message the agreed usage of the entities.

In the following table the indicators and their respective uses are set out:

Status (S) Value	Description	Remark
M	Mandatory	Indicates that this item is mandatory in the standard message.
R	Required	Indicates that this entity shall be sent in this message implementation and use is here mandatory.
A	Advised	Indicates that a recognised international code-set i.e. UN, ISO or ERI code set is highly recommended for use in this implementation over any local codes.
D	Dependent	Indicates that the use of the entity depends upon a well-defined condition or set of conditions. These conditions shall be clearly specified in the relevant implementation guideline.
O	Optional	Indicates that this entity is at the need or discretion of the sender of the message.
X		Not to be used in this message implementation (n. a.).

1.3. Messages

1.3.1. ERINOT

The ERI notification message (ERINOT) shall be used for the reporting of voyage related information and of information on dangerous and non-dangerous cargo carried on-board vessels sailing on inland waterways. The ERINOT message is a specific use of the UN/EDIFACT ‘International Forwarding and Transport Dangerous Goods Notification (IFTDGN)’ message as it has been developed within the PROTECT(1) organisation. The ERINOT message is based on the EDIFACT directory 98.B and the PROTECT implementation version 1.0.

For the data and codes contained in the message applications based on these message specifications, use has been made of the UN Directory D98B.

The ERINOT message encompasses the following types:

• transport notification from vessel to authority (identifier ‘VES’), from ship to shore;

• transport notification from carrier to authority (identifier ‘CAR’), from shore to shore;

• passage notification (identifier ‘PAS’), from authority to authority.

The following message functions show what sort of message can be expected:

• new message (identifier ‘9’);

• modification of message (identifier ‘5’);

• cancellation of message (identifier ‘1’).

1.3.2. PAXLST

The PAXLST message is based on the UN/EDIFACT message PAXLST. It shall be used for the exchange of data in inland navigation between the captain/skipper or carrier and designated authorities such as ISPS terminals, customs, immigration, police.

The message shall be also used to transfer passenger/crew data from a designated authority in the country of departure to the appropriate authorities in the country of arrival of the means of transport.

1.3.3. ERIRSP

The ERI response message (ERIRSP) is derived from the UN/EDIFACT APERAK message. It may be generated by for instance a RIS centre. The response messages with respect to the different functions (new, modification or cancellation) of the ERINOT message have all the same structure. The response to a ‘modification’ or a ‘cancellation’ contains information whether or not the ‘modification’ or ‘cancellation’ has been processed by the receiving system.

1.3.4. BERMAN

The Berth Management (BERMAN) message combines the pre-arrival notification respectively general declaration into one single notification which is based on the EDIFACT message BERMAN from the UN/EDIFACT D04B directory. The implementation manual is based on the guidelines as defined by the PROTECT group.

The BERMAN message shall be sent by vessels sailing on inland waterways before arriving at or departing from a berth or a port and provides information about the time of arrival and the services required to ensure a prompt handling, to support procedures and to facilitate controls.

The message incorporates the legal requirements regarding the notification of a ship to a port. It supports one request for the ship — be it for entering the port, berthing on arrival of the ship, leaving the berth on departure of the ship or shifting of berths for the ship within the port or for transiting only through the port area. The arrival and transit notification contains all details regarding the movement of the ship from outside the port area to the first berth in the port area or in case of transit to the point where the vessel is leaving.

Required additional services to be arranged for arrival at a berth can be specified. The estimated time of arrival (ETA) at the entry point and where required leaving point and previous place of call of the ship are required information elements.

1.4. Amendment procedures

Proposals for amendments to the message implementation manuals shall be sent together with an explanation, why the amendment is needed to the chairperson of the Electronic Reporting expert group.

The chairperson shall distribute the proposal to the members of the expert group as well as to the European Commission.

As regards the expert group, the relevant procedures as defined in the Terms of Reference for the Electronic Reporting expert group shall apply.

The European Commission will proceed with any amendment in accordance with the procedures established in the RIS Directive. In this context, due account shall be taken of the work of the expert group.

(1)

PROTECT: An organisation of a number of European seaports which have developed common implementation guidelines for standard messages. These guidelines form the basis of the implementation manuals in the technical specifications for electronic reporting.