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 ITRRPT
ITRRPT 4 In transit report detail message  

TBG1 Supply Chain

This specification provides the definition of the In transit report detail message (ITRRPT) to be used in Electronic Data Interchange (EDI) between trading partners involved in administration, commerce and transport.


1.1 Functional definition
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 be provided by the third party at the same location along with the Grouping service.

1.2 Field of application
The In transit report detail 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
An In Transit Report Detail message always relates to one or many Despatch Advice messages sent to the parties concerned.
This message refers to the goods identified in the referenced Despatch Advice messages

When the recipient of the message is a grouping centre the message allows the grouping centre to consolidate consignments received from one or more original consignors or other grouping centres and despatch them to another grouping centre or to the consignee.

When the recipient of the message is the consignee, it allows the consignee to match this message with the corresponding Despatch Advice messages already received from the consignor(s). In case of differences, the message allows the consignee to identify variances caused by a split consignment or by missing goods.

The Cargo/goods handling and movement message (HANMOV) has been designed to identify additional handling services related to the despatched goods, such as storage or (re-)packaging.

An ITRRPT message specifies the details of despatched goods (possibly re-grouped), corresponding to one or more original despatch advices; the references to the consignment(s) by which they transported can be included (the seller's and buyer's perspective). The message does not necessarily provide full consignment details as required for transport purposes ( the carrier's perspective).

The message refers to goods despatched on a single unit of transport (e.g. a single truck, a single railway wagon etc.).

The sender of the message may be:

. The consignor; in this case the message may refer to several buyers and consignees, but to only one seller.

. A grouping centre; in this case the message may refer to several buyers, consignors, consignees and sellers.

The recipient of the message may be:

. A grouping centre; in this case the message may refer to several sellers, consignors, consignees and buyers.

. The consignee; in this case the message may refer to several sellers, but only one buyer and one consignee.

The following diagram illustrates the information flows.

                        INFORMATION FLOWS

| DESADV 1                                                    |
|                                 DESADV 2                    |
|                   +---------->----------------------------+ |
|                   |   -----------------------------------+| |
|                   |   |  DESADV 3       +---------->----+|| |
|                   |   |                 |  DESADV 4     ||| |
+------------+  +---|---|----+        +------------+      ||| |
| consignor 1|  | consignor 2|     +--| consignor 3|      ||| |
+------------+  +------------+     |  +------------+      ||| |
     |                 |           |         |            ||| |
   ITRRPT a        ITRRPT b    ITRRPT c   DESADV 5        ||| |
     |                 |           |         |            ||| |
  (DESADV1)        (DESADV2+3) (DESADV4+5)   |            ||| |
     |                  | +---<----+         |            ||| |
     |   +-----------------+           +-----------+      ||| |
     |   |GROUPING CENTER 1|           |CONSIGNEE  |      ||| |
     |   +-----------------+           |FACTORY 1  |      ||| |
     V         |         |             +-----------+      ||| |
     |         |         |               |                ||| |
     |      ITRRPT d     +-------------->+                ||| |
     |     (DES|ADV2+3+4)    ITRRPT e                     ||| |
     |         V            (DESADV 5)                    ||| |
+-----------------+                    +------------+     ||| |
|GROUPING CENTER 2|--------------->----|  CONSIGNEE |--<--+|| |
+-----------------+    ITRRPT f        | FACTORY 2  |--<---+| |
     |                 (DESADV3+4)     +------------+       | |
     |                                                      | |
     |                                 +-------------+      | |
     +------------------->-------------|CONSIGNEE    |      | |
           ITRRPT a                    |ADVANCED     |--<---+ |
           (DESADV1+2)                 |WAREHOUSE 3  |--<-----+

- The indication (DESADVn) below ITRRPT n indicates that the ITRRPT message match the corresponding DESADV directly sent to the consignee.
- The material flow corresponds to the ITRRPT message flow.

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


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


4.1 Data segment clarification
This section should be read in conjunction with the segment table which indicates mandatory, conditional and repeating requirements.

The following guidelines and principles apply to the whole message and are intended to facilitate the understanding and implementation of the message:

All specified dates/times should be in the format 'ccyymmdd'/'hhmm' unless all parties involved in the transaction agree that there is a functional requirement for an alternative format.
Periods should be specified as whole numbers representing the required period as indicated in the format qualifier (weeks, months, etc.)

Where a choice of code or text is given only the code element should be used wherever possible.

Care must be taken to avoid the conflicting use of qualifiers.

Free text information within the message should be avoided as this inhibits automatic processing.
  Generated by GEFEG.FX