TBG1 Supply Chain
This specification provides the definition of the Repair call message (RPCALL) to be used in Electronic Data Interchange (EDI) between trading partners involved in administration, commerce and transport.
1.1 Functional definition
A message sent by a manufacturer or a call centre with information addressed to servicing and repair centres with details of appliances requiring repair or service. The information provided by the manufacturer or a call centre may include, details of the appliance, symptoms and faults, service history and previous repairs, parts already replaced, location where the appliance it is to be found as well as contact details.
1.2 Field of application
The Repair call 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 RPCALL message can be used to inform service and repair centres on one or more repair calls that are proposed by a manufacturer or a call centre.
The message may contain the following information relating to the appliance and its location:
- the appliance model number or type
- warranty details (as relevant)
- symptoms and defect codes
- repair history (as relevant)
- address where the appliance is to be found and contact details
- date and time requested for the visit
The PROSRV message may be used to respond to the manufacturer or call centre indicating the details of the interventions.
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 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'/'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, 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 a group.
Free text information within the message should be avoided as this inhibits automatic processing.