TBG1 Supply Chain
This specification provides the definition of the General purpose message (GENRAL) to be used in Electronic Data Interchange (EDI) between trading partners involved in administration, commerce and transport.
1.1 Functional definition
A message to enable the transmission of textual information.
1.2 Field of application
The General purpose 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.
- may be used to send general application support information to one or multiple addresses.
- may be used to send required data for which there is no specific standard message.
- MUST not be used as a substitute for an existing UNSM under development, under trial or at approved status. Nor should it be used to avoid the development of a more specific application message.
- is not designed or intended to be used as a replacement for existing electronic mail systems.
The GENRAL message was designed primarily to
. facilitate early transmission testing between new EDI partners;
. broadcasting of known problem areas to EDI partners;
. transmission of text (preferably structured or coded) to supplement or further clarify previously transmitted EDI standard messages, e.g. to stress that provision data is for test purposes only contains known errors to test out error routines.
. transmission of small amounts of structured text where no existing messages exist, e.g. computer listings.
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 'yymmdd'/'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 to ensure 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.