Directory   Messages   Segments   Composites   Data elements   Codes Meaning of the change indicators
  UN/EDIFACT  D.03A (Batch) Syntax version 3 Issue date 2003-06-23  
  Message type specification COREOR
 
 
COREOR 10 Container release order message  
  Date:
2003-06-10

Source:
TBG3 Transport

0. INTRODUCTION
This specification provides the definition of the Container release order message (COREOR) to be used in Electronic Data Interchange (EDI) between trading partners involved in administration, commerce and transport.

1. SCOPE

1.1 Functional definition
Order to release containers, and giving permission for them to be picked up by or on behalf of a specified party.
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'.

1.2 Field of application
The Container release order message may be used for both national and international applications. It is based on universal practice related to administration, commerce and transport, and is not dependent on the type of business or industry.

1.3 Principles
Business area:
Pre- and on-carriage transport of containers/equipment

Sending functions include:
Shipping agent, Logistic center, Freight forwarder, Inland carrier (copy)

Receiving functions include:
Container depot, Inland terminal, Container freight station, Freight forwarder (copy), Inland carrier (copy)

In the context of the 'Guide to the scenario of EDIFACT container messages' (as referred to at the start of section 1) the following guidelines, rules and functionality apply to this Container release order message:

*   The message contents can be uniquely identified by a combination of the following data elements:
- ordering customer, coded (NAD)
- ordering customer agent, coded (NAD)
- container release reference number (RFF)
The ordering customer agent, coded is needed to supplement the unique identification only in the next situation: the agent acts on behalf of several ordering customers issuing the same range of reference numbers for each customer.
E.g. the ship's agent acts on behalf of several shipping lines issuing for each shipping line the same range of numbers.

*   One shipping line, one seagoing vessel, one sea voyage number and one shipping agent can be specified on message top level.

*   An indicator for the transport status (i.e., export, import, transhipment or continental) can be completed on container level (EQD-segment).

*   One message may contain several containers identified by their prefix and number or several equipment guidelines for groups of (empty) containers.

*   Inland transport details can be specified for each individual container or can be specified on message level (for all containers in the message); the two options must not be used simultaneously.

*   An inland transport charges reference or a sea booking reference can be specified either on message level (related to all containers in the message) or for each individual container; the two options must not be used simultaneously.

*   The final place of positioning can be included in case of routing via an inland terminal or several container freight stations (for stacking purposes).

*   For each container up to 3 communication addresses can be specified to which a copy of the Container gate-in/gate-out report message is to be sent.

*   For each container details can be specified such as container prefix and number, size/type, loading instructions, special instructions, seals, temperature, dangerous goods and off-dimensions details.

*   A goods item may be detailed, such as number and type of packages, goods description, gross weight, dangerous goods information and special instruction.

*   Goods item information can be related to the corresponding containers by linking the goods item group (GID) to the container details group(s) (EQD) by means of the SGP-segment.

The transport sub-working group (D4) has developed recommendations for a harmonised implementation of this message through its subgroup ITIGG (International Transport Implementation Guidelines Group).
Users implementing the message are strongly advised to apply these recommendations, which may be obtained from the D4 secretariat.

2. REFERENCES
See UNTDID, Part 4, Chapter 2.3 UN/ECE UNSM - General Introduction, Section 1.

3. TERMS AND DEFINITIONS

3.1 Standard terms and definitions
See UNTDID, Part 4, Chapter 2.3 UN/ECE UNSM - General Introduction, Section 2.

4. MESSAGE DEFINITION

4.1 Data segment clarification
This section should be read in conjunction with the segment table which indicates mandatory, conditional and repeating requirements.
 
  Generated by GEFEG.FX  
  http://www.gefeg.com