| Version: | D |
|---|---|
| Release: | 03A |
| Contr. Agency: | UN |
| Revision: | 1 |
| Date: | 2003-06-10 |
| SOURCE: | TBG1 Supply Chain |
|
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: D00B, D01A, D01B, D01C, D02A, D02B, D03A, D03B, D04A, D04B |
This specification provides the definition of the Infrastructure condition message (INFCON) to be used in Electronic Data Interchange (EDI) between trading partners involved in administration, commerce and transport.
The Infrastructure condition message is sent by a responsible party to other interested parties regarding the condition of a component in a commercial services or utilities infrastructure.
The Infrastructure condition 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.
An Infrastructure condition message concerning an infrastructure component may be sent:
The message may be an initial message and does not require a response.
The message contains condition, availability and other management information in coded or free text format.
This message is typically used in cases where a component in a network is taken down for repair or has broken down, for example in:
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.
Information to be provided in the Header section:
A service segment starting and uniquely identifying a message. The message type code for the Infrastructure condition message is INFCON.
Note: Infrastructure condition messages conforming to this document must contain the following data in segment UNH, composite S009:
| Data element | 0065 | INFCON |
| 0052 | D | |
| 0054 | 03A | |
| 0051 | UN |
A segment by which the sender uniquely identifies the Infrastructure condition message by means of its name and number and when necessary its function.
A segment specifying general dates and, when relevant, times related to the whole message. The segment must be specified at least once to specify the message date as allocated by the sender.
A segment with free text information, in coded or clear form, used when additional information is needed, which is relevant for all components described in the actual message but cannot be accommodated within other segments.
A group of segments for giving references and where necessary, their dates, relating to the whole message.
A segment identifying a reference by its type and number.
A segment specifying the date/time related to the referenced information.
A group of segments identifying the parties with associated information relevant to the whole message.
A segment identifying names and addresses of the parties, in coded or clear form, and their functions relevant to the message. At least one occurrence of the segment is required. This will normally be the party responsible for the component(s) described. It is recommended that, if possible, only the coded form of the party ID should be specified.
A group of segments giving contact details of a specific person and/or department within the party identified.
A segment to identify a person and/or department, and their function, to whom communications should be directed.
A segment to identify a communication type and number for the contact specified.
Information to be provided in the Detail section:
0130 Segment group 4: LOC-DTM-NAD-FTX-SG5-SG6-SG7 A group of segments identifying the component being reported. This includes the party responsible for the component, the physical characteristics of the component, the reason for the downtime and the scheduled downtime of the component.
A segment to identify the location of the component being reported. It is recommended that, where possible, codes should be used to identify the component to facilitate automatic processing.
A segment to specify dates associated with the downtime, availability or occurrence of an event connected to the component.
A segment to identify parties and/or addresses related to the component, such as installation address.
A segment with free text information, in coded or clear form, used when additional information on the downtime, availability or occurrence of an event connected to the component is needed but cannot be accommodated within other segments. In computer to computer exchanges such text will normally require the receiver to process this segment manually.
A group of segments providing characteristics and characteristic details of the component.
A segment to identify characteristic and/or the characteristic name and characteristic relevance for the component.
A segment to specify characteristic of the component, by value in either coded form or in free format.
A group of segments to provide quantity change or other relevant quantities for the specified component and, where relevant, related date and time information, for example indication of capacity within a given period.
A segment to specify quantities related to the component.
A segment indicating date or time details relating to the quantity, for example indication of capacity within a given period.
A group of segment specifying schedules related to the downtime, availability or occurrence of an event connected to the component.
A segment specifying the type and status of the schedule being given, and optionally defining a pattern to be established, such as estimated schedule for the downtime, availability or occurrence of an event connected to the component.
A segment indicating the date/time details relevant to the schedule details. This segment may be used to indicate date/time ranges.
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 | |
| CAV | Characteristic value | |
| CCI | Characteristic/class id | |
| COM | Communication contact | |
| CTA | Contact information | |
| DTM | Date/time/period | |
| FTX | Free text | |
| LOC | Place/location identification | |
| NAD | Name and address | |
| QTY | Quantity | |
| RFF | Reference | |
| SCC | Scheduling conditions | |
| UNH | Message header | |
| UNT | Message trailer |
| ├─UNH Message header | ×1 | (M) |
| ├─BGM Beginning of message | ×1 | (M) |
| ├─DTM Date/time/period | ×9 | (M) |
| ├─FTX Free text | ×9 | (C) |
| ├─Segment Group 1 | ×9 | (C) |
| │─├─RFF Reference | ×1 | (M) |
| │─└─DTM Date/time/period | ×9 | (C) |
| ├─Segment Group 2 | ×99 | (M) |
| │─├─NAD Name and address | ×1 | (M) |
| │─└─Segment Group 3 | ×9 | (C) |
| │───├─CTA Contact information | ×1 | (M) |
| │───└─COM Communication contact | ×9 | (C) |
| ├─Segment Group 4 | ×999 | (M) |
| │─├─LOC Place/location identification | ×1 | (M) |
| │─├─DTM Date/time/period | ×9 | (C) |
| │─├─NAD Name and address | ×9 | (C) |
| │─├─FTX Free text | ×9 | (C) |
| │─├─Segment Group 5 | ×9 | (C) |
| │─│─├─CCI Characteristic/class id | ×1 | (M) |
| │─│─└─CAV Characteristic value | ×9 | (C) |
| │─├─Segment Group 6 | ×9 | (C) |
| │─│─├─QTY Quantity | ×1 | (M) |
| │─│─└─DTM Date/time/period | ×9 | (C) |
| │─└─Segment Group 7 | ×9 | (C) |
| │───├─SCC Scheduling conditions | ×1 | (M) |
| │───└─DTM Date/time/period | ×9 | (C) |
| └─UNT Message trailer | ×1 | (M) |