TBG1 Supply Chain
This specification provides the definition of the Safety and hazard data message (SAFHAZ) to be used in Electronic Data Interchange (EDI) between trading partners involved in administration, commerce and transport.
1.1 Functional definition
The Safety and hazard data message is to enable the communication of safety data and advice on relevant materials supplied to industrial customers so as to enable them to take measures to protect their employees and the environment from any potential harmful effects from these materials.
1.2 Field of application
The Safety and hazard data 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 Safety data message has been designed to meet the requirements of both: the ISO recommendations and the EC Directive on Safety Data Requirements.
The message incorporates all North American requirements as defined in the current ANSI transaction set.
The message has been specifically designed to enable structured, semi-structured and unstructured data to be specified and transmitted.
All future changes to the message must be checked against the various regional and national statutory requirements before the new version is published.
A Safety data message relates to one dangerous or hazardous substance.
A Safety data message is issued by the supplier of dangerous or hazardous substances.
New or amended information about dangerous or hazardous substances must be quickly provided to every industrial recipient who has been supplied within a proscribed timescale.
See UNTDID, Part 4, Chapter 2.3 UN/ECE UNSM - General Introduction, Section 1.
3. TERMS AND DEFINITIONS
3.1 Standard terms and definitions
See UNTDID, Part 4, Chapter 2.3 UN/ECE UNSM - General Introduction, Section 2.
4. MESSAGE DEFINITION
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' or '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 does not conflict with the segment qualifier of the trigger segment of the group.