% Response.CharSet="utf-8" %>
|SOURCE:||D7 Architecture, Engineering and Construction (SWG)|
For general information on UN standard message types see UN Trade Data Interchange Directory, UNTDID, Part 4, Section 2.3, UN/ECE UNSM General Introduction
This message also occurs in the following versions of this standard:|
D95A, D95B, D96A, D96B, D97A, D97B, D98A, D98B, D99A, D99B, D00A, D00B, D01A, D01B, D01C, D02A, D02B, D03A, D03B, D04A, D04B
This specification provides the definition of the Drawing administration message (CONDRA) to be used in Electronic Data Interchange (EDI) between trading partners involved in administration, commerce and transport.
The message will be used for the administration of each exchange of a set of engineering/CAD files. It will give additional information about the files; for example, their nature, a list of their contents and technical information necessary to interpret them.
The whole process of exchanging engineering or CAD (Computer Aided Design) files between different parties within projects will be supported by EDIFACT messages. The message CONDRA is one of these messages.
The Drawing administration 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.
The following descriptions refer to the exchange of engineering/CAD files, but do not exclude any other type of "native" files, e.g. files originating from software packages and tools like word-processing, spreadsheet, DTP (Desk Top Publishing), graphics and so on.
CONDRA is the EDIFACT message to administer the exchange of engineering/CAD files. The message itself does not consist of any engineering or graphical information. This information will be transferred within files written in existing standard graphical exchange formats or native formats, referred to within the message as external file reference to identify each of these files. The nature of the engineering files and its content is not relevant for the syntax of the EDIFACT message.
All types of engineering/CAD files may be exchanged during a project's life cycle. The naming/structuring conventions, including project organisation and system environments can be defined in the EDIFACT message CONDRO (Drawing Organisation).
CONDRA will refer to the message CONDRO, previously received by the business parties, if there is additional information required about the project organisation, system environment and naming/structuring convention.
See UNTDID, Part 4, Chapter 2.3 UN/ECE UNSM - General Introduction, Section 1.
See UNTDID, Part 4, Chapter 2.3 UN/ECE UNSM - General Introduction, Section 2.
This section should be read in conjunction with the segment table which indicates mandatory, conditional and repeating requirements.
A service segment starting and uniquely identifying a message. The message type code for the Drawing administration message is CONDRA.
Note: Drawing administration messages conforming to this document must contain the following data in segment UNH, composite S009:
A segment for unique identification of the Drawing administration document name, number and function.
A segment specifying the dates relevant to this document; e.g. the date, when the drawing administration in this message has been defined.
A segment used to authenticate the message by exchanging a password or some other form of identification agreed between the business partners.
A segment will be used to identify the type of agreement that apply to the information given by this message.
A segment with free text information, in coded or clear form, used for any textual information. In computer to computer exchanges, such text will require the receiver to process this segment manually.
This segment conveys exchange information like the number of engineering/CAD files and their total size (volume) that form part of the exchange of this message and to which this message refers.
A group of segments used for quoting references and their relevant dates applicable to the message. For the building industry the following recommendation is given: in the first occurrence of this segment group the project references, if relevant, can be given, in order to identify the project to which this message relates. In any subsequent recurrence of this segment group, references to other messages (e.g. the original CONDRO when it is an update) or documents, relevant to this message, may be quoted.
A segment for quoting the unique references which can be the project number to which this message is relevant, or, in the case of a reference to another message or document, that message or document's unique identifier.
Document details of the reference quoted in the previous RFF segment.
Date of a reference quoted in the previous RFF segment, e.g. project date or message/document date.
This segment can contain any textual information relevant to the reference quoted in the previous RFF segment, e.g. a small project or message/document description and/or other narrative, for additional information.
A group of segments identifying all the relevant parties with specific information about them that other business partner should know.
A segment identifying name and address of a party, in coded or clear form, and its function relevant to the Message. It is recommended that where possible only the coded form of the party ID should be specified.
A segment giving more specific location information of the party specified in the NAD segment e.g. internal site/building number.
This segment allows any narrative that may be needed to accompany the party name and address information specified in the previous NAD segment.
A segment that gives each of the receivers their specific instructions for what they should do with this message and the files to which this message refers.
A segment that gives specific requirements to each of the receivers of this message, e.g. action request.
This segment group can be used to quote specific references for each partner, that may be needed for internal use. Examples of references that a partner may require are internal project number.
In this segment specific internal references will be quoted, as and when required.
A segment specifying the date and/or time details related to the party's specific internal references.
A group of segments giving contact details of the specific person or department within the party identified in the NAD segment.
A segment to identify a person or department, and their function, to whom communications should be directed.
A segment to identify a communication type and number for the contact specified in the CTA segment.
This segment specifies the location of the contact specified in the previous CTA segment. In large organisations and construction projects it is possible that persons are not necessarily on the same internal site or construction site specified in the previous LOC segment in segment group 2. This segment also enables the specification of a more accurate internal site location.
A group of segments that refers through an external file identification to each of the external engineering/CAD files and giving additional information about each of the files.
This segment will identify the external files by indicating the file name, file number and its sequence number in an exchange.
A segment that gives details of a computer or software environment.
A segment giving reference related to the file, identified by the previous EFI segment. This reference number is specific to the sender, and the receivers may be informed about its full meaning through another message (e.g. for the building industry message CONDRO) if this feature is used.
This segment will convey the date/time details of the external engineering/CAD file.
The size/volume of the external engineering/CAD file identified in the previous EFI segment.
LOC-DIM-MEA-SG7 A group of segments that records more detailed information about the contents of the external engineering/CAD file is identified in the previous EFI segment. This information is organised hierarchically. First, each hierarchy is identified, followed by the type of hierarchy.
This segment will, through a structured index code, uniquely identify the level described in the following segments.
This segment is used to define the level type identified by the previous BII segment, like, for example, drawing sheet, view, layer group, and layer, but also phase etc.
Date and time details of the level identified in the previous BII segment.
This segment contains the name of the level that is identified in the previous BII segment.
This segment conveys quantity details of the level identified in the previous BII segment. This quantity details concern the precision or the number of objects in the lower level, e.g. number of drawing views.
The person or department responsible (author) of this specific part (level) of the contents is recorded in this segment.
A segment used to authenticate the part of the message identified in the previous BII segment by exchanging a password or some other form of identification agreed between the business partners.
This segment will be used to identify the "type of agreement" that applies to the information defined in the previous BII segment.
Instructions for the receiver for this specific part (level) of the contents are recorded in this segment.
Requirements for the receiver for this specific part (level) of the contents are recorded in this segment.
This location of the level (e.g. layer) in a co-ordinate system is given in this segment.
Dimensions (like size, unit of measurements) are given in this segment.
The scale used can be quoted in this segment.
For each of the levels that are identified in the previous BII segment it is possible to refer to other messages/documents on other levels of the structure of the engineering/CAD file identified in the previous EFI segment. It is also possible to refer to other levels which are part of a different engineering/CAD file than the one identified in the previous EFI segment. If needed, here should also be made a reference to a contractual document or to a revision number.
An ID number will be used to refer to either another message/document or to another engineering/CAD file. If needed, here should also be made a reference to a contractual document or to a revision number.
If the reference number quoted in the previous RFF segment is a reference to another message/document, this segment group is used to give more details about this message/document.
The details of the message/document referred to are quoted in this segment.
Date/time details of the message/document referred to are quoted in this segment.
This segment group will be used when a reference is made to another specific level in the structure of an engineering/CAD file. If in the previous RFF segment a standard dummy value is quoted, the level referred to is part of the engineering/CAD file identified in the previous EFI segment. If, however, in the previous RFF segment any other value is quoted, the level described in the following BII segment is part of the engineering/CAD file identified by the ID number.
A segment identifying the beginning of a CAD-file by a sequential number.
This segment will through a structured index code uniquely identify the level referred to.
Through an "index system", updates (versions) can be recorded in a reference number. In this segment the version of the level referred to can be quoted.
This segment is used to define the level type identified in the previous BII segment; like, for example, drawing sheet, view, layer group and layer.
Date/time details of the level that is referred to are quoted here.
A detailed description of the level referred to can be quoted in this segment.
A service segment ending a message, giving the total number of segments in the message (including the UNH & UNT) and the control reference number of the message.
|BGM||Beginning of message|
|CED||Computer environment details|
|EFI||External file link identification|
|INP||Parties and instruction|
|NAD||Name and address|
|RCS||Requirements and conditions|
|├─UNH Message header||×1||(M)|
|├─BGM Beginning of message||×1||(M)|
|├─AUT Authentication result||×2||(C)|
|├─AGR Agreement identification||×2||(C)|
|├─FTX Free text||×10||(C)|
|├─Segment Group 1||×10||(M)|
|│─├─DOC Document/message details||×1||(C)|
|│─└─FTX Free text||×5||(C)|
|├─Segment Group 2||×999||(M)|
|│─├─NAD Name and address||×1||(M)|
|│─├─LOC Place/location identification||×99||(C)|
|│─├─FTX Free text||×10||(C)|
|│─├─INP Parties and instruction||×10||(C)|
|│─├─RCS Requirements and conditions||×10||(C)|
|│─├─Segment Group 3||×5||(C)|
|│─└─Segment Group 4||×10||(C)|
|│───├─CTA Contact information||×1||(M)|
|│───├─COM Communication contact||×5||(C)|
|│───└─LOC Place/location identification||×1||(C)|
|├─Segment Group 5||×99||(C)|
|│─├─EFI External file link identification||×1||(M)|
|│─├─CED Computer environment details||×10||(M)|
|│─└─Segment Group 6||×10000||(C)|
|│───├─BII Structure identification||×1||(M)|
|│───├─GIS General indicator||×5||(C)|
|│───├─IMD Item description||×1||(C)|
|│───├─CTA Contact information||×1||(C)|
|│───├─AUT Authentication result||×2||(C)|
|│───├─AGR Agreement identification||×2||(C)|
|│───├─INP Parties and instruction||×10||(C)|
|│───├─RCS Requirements and conditions||×10||(C)|
|│───├─LOC Place/location identification||×5||(C)|
|│───└─Segment Group 7||×99||(C)|
|│─────├─Segment Group 8||×1||(C)|
|│─────│─├─DOC Document/message details||×1||(M)|
|│─────└─Segment Group 9||×999||(C)|
|│───────├─SEQ Sequence details||×1||(M)|
|│───────├─BII Structure identification||×1||(M)|
|│───────├─GIS General indicator||×5||(M)|
|│───────└─IMD Item description||×1||(C)|
|└─UNT Message trailer||×1||(M)|
|plus sign||An addition.|
|asterisk||Addition/substraction/change to a code entry for a particular data element.|
|hash or pound sign||Changes to names.|
|vertical bar||Changes to text for descriptions, notes and functions.|
|minus sign||A deletion.|
|letter X||Marked for deletion.|