Message Data Elements for Marsha OXI

This topic contains the following Message Data Elements for Marsha:

RDR Message Format Description

RDR (Reservations Data Representation) messages provide the mechanism for exchanging data between the two systems. This document details the structure of the tagged sections and components that provide the basis for the RDR messages. The data definitions shown in this document should be used in conjunction with document MARSHA INTERFACE MESSAGE CONSTRUCTION that details how to construct messages using the components.

The basic concept behind the RDR data constructs is that related pieces of data will be represented as business entities.

Messages will be built from three structural levels

• Sections  - used to describe the main business entities (i.e. transaction, booking)
• Components - used to divide the business entities into the components used for a reservation (i.e., name or address).
• Elements - defining the individual fields that make up a component. i.e. first name, middle initial, last name and salutation.

Message Structure Diagram

Message Envelope:

All messages will be encapsulated by start and end messages tags. The following tags are used:

• MST. Start of message
• MEN. End of message

These tags are used solely to delineate the start and end of the data stream that comprises one message. Each of these tags will end with one element delimiter followed by one component delimiter (See later notes on delimiters).

Message Sections:

The message will be broken into sections corresponding to the basic business entities used in reservations applications. For any one application a message will be constructed from the Message Sections that convey the data required by that application.  Examples of message sections include:

• Product
• Guest
• GNR History
• Transaction

Message sections are intended to provide a method for representing relationships of data.  For example The Guest Section will represent the Guest name and all data associated with that name (i.e. contact number, address etc).

Sections will have both a start and end of section tags.  Within a section the data will be subdivided into components to describe the parts that make up that section.  The start and end of section tags will encapsulate the group of components that comprise a given section.

Message Components:

A component will be defined for each type of business data that builds up a section. For example, the product section will include components to describe the hotel, the reservation period and rate information.

As for the message sections the components will have a unique start of component tag. A delimiter will mark the end of a component. Within a component, delimiters will separate individual elements.

Within a section, a component may be repeated. If a guest has two phone numbers, the contact number field will be repeated.

Note:  A component may appear in more than one section. For example, the free format text component (TXT:) may appear in either the guest or booking sections.

Message Elements:

Components will be constructed from elements. The elements will be defined with standard lengths and content (i.e., alpha, numeric etc).  For transmission the elements will be condensed to remove leading or trailing blanks or fields that are not required for a given message.

The elements that build up a component will be defined and will always be mandatory. If an element does not apply for a given situation, it will still be included in the component but will be left empty.  For example, if a component has two elements

• TAG:REQUEST CODE:ELEMENT1:ELEMENT2:+. Example with both elements in use
• TAG:REQUEST CODE:ELEMENT1::+. Example with second element unused.

The following sections of this document detail the sections, components, and elements that are supported as part of the RDR message structure.

Request Code:

The first element in every component will be the request code. This element will be used to identify the action that should be taken using the data in the component. The request code will allow a user to request that the data component either be added or deleted from the receiving system. The request code element will support the following values;

• NN. Data should be added
• XX. Data should be deleted

Although in some cases a change may be required rather than a delete and an add a change will be represented using the NN and XX codes.

Coded Sets:

To enable information to be communicated between the PMS and MARSHA certain elements are defined as coded sets. Coded sets will be defined within the Data Dictionary.  Coded sets are information in the form of a code.  Examples of coded sets include error numbers, room request codes (i.e. K1 for King Bed) and system codes.

Element Delimiter/End of Line Marker:

To allow the system to isolate individual elements, delimiters will separate elements. An end of line marker will flag the end of each component (or section tag).

Two delimiters are used in the RDR message format.

• Section delimiter. A three-letter token followed by colon and plus ( :+ )
• Component delimiter. A three-letter token followed by single colon ( : )
• Element delimiter. a colon ( : ) within  the component
• The end of a component is indicated by a single plus ( + )
• The end of a section is indicated by its ending three-letter token followed by colon and plus ( :+ )

  Note: All examples in this document use a ( : ) as the element delimiter and a ( + ) as an end of line marker.

MESSAGE SECTION DEFINITIONS

RDR Sections are used to control relationships between pieces of data.  Sections have been defined to match the key objects used in a reservations application. New Sections will be defined as the use of the interface is expanded.

In addition certain section have been defined to aid communications and to pass instructions between the Peers (see Transaction and Request sections).

At this point the following sections have been defined within the RDR message:

• Booking
• Guests
• Product
• Agent (Not Used)
• Client (Not Used)
• GNR History (Not used
• Brochure (Not used)
• Request
• Transaction

Booking Section. A booking section represents all data used to tie a guest (see Guest Section) to what that guest has purchased (see Product Section). The Booking Section represents a single reservation and will contain data used to reference a reservation (i.e., the Confirmation number and From field information) as well as the point of sale information (i.e., booking source and Travel agency details).

Booking Section content:

• BST:+ - Start of point of sale data (booking data)
• CRR: - Central res system reference number
• BSC: - Booking source
• AGT: - Booking agent data
• VBR: - Vendor booking reference
• ADR: - Business origin address
• CON: - Business origin contact number
• SPL: - Related GNR pointer (split GNR details)
• PEO: - Number in party/Number of children
• SER: - Special service request
• TXT: - Free format text
• FRM: - From field
• PMR: - Property level reference number
• ERC: - Error code
• BEN:+

See component section for details of components used to construct each section.

Guest Section. A Guest section represents the person who has purchased a product from Marriott International. The Guest Section will include all data that relates to that Guest. Some of this data is permanent data (i.e. Name and Marquis membership number) other components relate to a given stay only (i.e. Estimated time of arrival - ETA).

Guest Section Content:

• GST:+ - Start of guest data

Permanent guest data entities-

• NAM: - Guest  name
• GPD: - Guest personal details
• GLH: - Guest lodging history
• CON: - Contact numbers
• ADR: - Address
• GID - Guest Identifier
• CLB - Club Membership Information
• FQF: - Frequent flier club

Start of guest reservation data-

• ETA: - Estimated time of arrival
• PAY: - Payment type
• PMR: - Property level reference number
• ERC: - Error code
• GEN:+

Product Section. The Product Section represents what was sold to Guests. The Product section will contain all data that relates to a single contiguous stay in the same room pool.  This includes all stay, pricing, guarantee and booking rule information.

Product Section Content:

• PST:+ - Start of product information
• ACM: - Hotel information
• RAT: - Pricing information
• RQS: - Room type Service requests
• ARS - Arrival status/Room guarantee status
• RUL: - Booking rules and restrictions text
• REL: - Special religious requirement
• GEP: - Guest experience information
• NET: - Net rate data
• RPS: - Rate program substitute
• CRS: - Cross-sell information
• PMR: - Property level reference number
• ERC: - Error code
• OGR: - Guaranteed Room Type Status
• RTD: - Room type (room pool) description
• PEN:+

  Note: A room and connecting room type situation booked in separate room pools would be represented as two separate product sections.  The ACM component includes a flag that indicates if a given Product is a multi-product.  This flag is set if a room and connecting room scenario is being represented (see ACM component definition).

Request Section. The Request Section does not relate to a specific Business Object in the Reservations Application.  The Request Section is used to pass an instruction or command between the Peers.  The Action Identifier component (ACT) is used to specify which action is required.  The Argument (ARG) component specifies the argument or parameters that should be used when executing the request action.

For example one Peer may request the other Peer to print a confirmation letter.

Request Section Content:

• RST:+ - Start of generalized request section
• ACT: - Action identifier
• REN:+

Transaction Section. As with the Request Section, the Transaction Section does not relate to a specific Business Object in the Reservations Application.  The Transaction Section is generated at execution time when a message is passed between systems.  The section is used to control the address of the originating and destination peers as well as other data used to control the passing of information.  

Transaction Section Content:

• TST:+ - Start of transaction data
• INT : - Interchange descriptor
• TOL: - Transaction origin location
• ERC: - Error code
• TEN:+

Mapping Table Data Elements for Download

Section	Section Description	Components	Component Description
TST	Transaction Section	INT	Interchange Descriptor
		TOL	Transaction Origin Location
		ERC	Error Code
RST	Request Section	ACT	Action Identifier
BST	Booking Section	CRR	CRS reference number
		BSC	Booking source
		PEO	Number in party/children
		SER	Special service request
		TXT	Free format text
		FRM	From field
		ERC	Error code
PST	Product Section	ACM	Hotel information
		RAT	Pricing Information
		RQS	Room type Service requests
		ARS	Arrival status/Room guarantee status
		RUL	Booking rules and restrictions text
		REL	Special religious requirements
		GEP	Guest experience info
		NET	Net rate data
		RPS	Rate program substitution
		CRS	Cross sell information
		ERC	Error code
GST	Guest Section	NAM	Guest name
		GPD	Guest personal details
		GLH	Guest lodging history
		CON	Contact numbers
		AD2	Address
		GID	Guest identifier
		CLB	Club membership info
		FQF	Frequent flyer club
		RPD	N/A
		ETA	Estimated time of arrival
		PAY	Payment type
		ERC	Error Code
		ATS	Address test string