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 RETANN
RETANN 4 Announcement for returns message  

TBG1 Supply Chain

This specification provides the definition of the Announcement for returns message (RETANN) to be used in Electronic Data Interchange (EDI) between trading partners involved in administration, commerce and transport.


1.1 Functional definition
A message by which a party announces to another party details of goods for return due to specified reasons (e.g. returns for repair, returns at end of leasing period, returns because of damage).

1.2 Field of application
The Announcement for returns 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
This message may be used by the message sender to request credit for goods, or the replacement of goods from the message recipient.

This message should stimulate the message recipient to instruct on how the named goods should be returned, destroyed, or disposed of.

In the case where the recipient of the announcement refuses to accept the return of goods the sender would expect to receive notification of this decision and also instructions on what should happen instead of the return. This process will usually be handled using the Instruction for Return message.

The announcement for returns can be used by a party to inform another party on the requested return of:

-    goods received in bad condition;
-    goods received but not ordered;
-    goods for repair;
-    goods which have to be returned due to the end of a leasing contract;
-    goods which have exceeded their expiry date without being sold;
-    goods on commission;
-    goods from sale on approval;
-    sale or return goods;
-    returnable transport or packaging containers;
-    obsolete goods.

The announcement for returns may be used to return received goods for which receipt of delivery may already have been acknowledged by way of the Receiving Advice message (where this message is being used), e.g., the faulty goods are only discovered on opening a container for which a receiving advice has been issued.

The announcement for returns may also be used to specify additional information regarding the return of goods such as handling instructions or hazardous material information.

The recipient of the announcement for returns is requested to decide the final disposition of the goods for return:

-    whether the goods shall be returned, repaired, destroyed, or disposed of;
-    which transport means and mode should be used;
-    on or by which date the return should take place;
-    which party is responsible for the cost of return.

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.

Conditional data that is not required in the message should not be included.

Care must be taken that the segment qualifier in dependent segments do not conflict with the segment qualifier of the trigger segment of a group.

Free text information within the message should be avoided as this inhibits automatic processing. It is only used when additional information that cannot be accommodated within the other segments is required.
  Generated by GEFEG.FX