TBG1 Supply Chain
This specification provides the definition of the Purchase order change request message (ORDCHG) to be used in Electronic Data Interchange (EDI) between trading partners involved in administration, commerce and transport.
1.1 Functional definition
A message from the buyer to the seller, specifying details of the buyer's request to change a purchase order.
1.2 Field of application
The Purchase order change request 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.
A buyer may request to change, or eventually cancel one or more goods items or services.
A purchase order change request may refer to goods items or services related to one or more delivery schedules, call-offs, etc.
A purchase order change request for cross-border transactions may contain additional information for customs and/or statistical purposes.
A purchase order change request may contain details for transport and destination as well as delivery patterns.
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.
For guidance, the following principles serve to remove ambiguity in the application of an EDI Purchase Order Change.
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.
Conditional data that is not required in 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 of a group.
Free text information within the message should be avoided as this inhibits automatic processing.