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 OSTENQ
OSTENQ 3 Order status enquiry message  

TBG1 Supply Chain

This specification provides the definition of the Order status enquiry message (OSTENQ) to be used in Electronic Data Interchange (EDI) between trading partners involved in administration, commerce and transport.


1.1 Functional definition
A message between a buyer or buyer's agent and a seller or seller's agent for information on the current status of a previously sent order(s).

1.2 Field of application
The Order status enquiry 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 relate to:

- one type of enquiry

- one or more orders

- specific lines within orders

The order status enquiry can be sent as 'non-specific enquiries', i.e. asking for all outstanding orders, or as 'specific enquiries', i.e. asking for specific orders or order lines.

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.

- Data that is not necessary to meet the functional requirements of 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.

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