Functionality for Holidex OXI
This topic outlines the following functionality for HOLIDEX OXI:
The AIB Utility is a new inventory balancing tool designed to complement the Reservation Comparison Utility. See the topic Running and Maintaining Custom Interfaces for a further explanation of this functionality.
Party Split functionality has been available for system users but now is enhanced to attach Traces to each new booking split off the original source reservation. This will include an updated Trace for the original source booking.
When this function is used all reservations will be split off at one time.
When this function is used each reservation is split off one at a time; not necessarily within close time frame.
Example: of "Party Split All" Traces for the Original and the Split off bookings.
Example: of "Party Split" Traces for the Original and the Split off bookings.
The communication method changed from PL/SQL cartridge to J2EE Servlet. Holidex now uses a URL provided by opera to post messages to the PMS property. This change has been implemented to accommodate 32k (or greater) messages.
Strategy updates will be sent from HOLIDEX to PMS only. Strategies will affect how the hotel displays and sells their inventory and is easily accessible. Brand Strategies will not be viewable but directly affect the sequencing of rate codes in OPERA. Sell Strategies will be viewable and some fields are editable in OPERA PMS. In OXI these strategies will be labeled as BRAND-STRATEGY and SELL-STRATEGY in the Message Status screen.
When a Sell Strategy is not available the Brand Strategy will take over until the next available Sell Strategy kicks in or is downloaded to the hotel. Rate Query using the (F5 key), during any time frame and rates will be displayed according to prevailing Sell or Brand strategies. All rates will be displayed according to the sequence setup in HOLIDEX with Negotiated rates following.
Go to Setup>Configuration>Rate Management>Property Calendar.
Go to Setup>Configuration>Rate Management>Property Calendar>Day Types.
Go to Setup>Configuration>Rate Management>Rate Classifications>Rate Codes.
Out Of Order Messages are accepted by the CRS to assist in inventory balancing. Business Events are required to have the OOO messages go. Out of Order inventory can be Resynched to CRS. All messages will be sent labeled as 'New Out Of Order', 'Update Out of Order' and in some cases 'Update Out of Service'. The 'Update Out of Service' will be in the scenario of when an OOO has been updated to be OOS instead, thus allowing the inventory to be updated correctly in HOLIDEX Plus.
A Business Event for ROOM TYPE OUT OF ORDER is available under the Housekeeping module. Data elements include Resort, Room Type, and Number of OOO Rooms. This process will consolidate messages by room type. When subscribed to, OPERA will trigger a consolidated Business Event of the total count of Out of Order rooms, per room type. Any action by the user which would affect the room type count of Out of Order rooms will generate a Business Event, including using the functionality of New, Edit, Delete and Copy from the Out of Order/Service screen. This type of Business Event will not affect the existing Out of Order Business Events. However, with this feature, if multiple room types were modified in OPERA in one operation, one OXI message may contain more than one room type and may contain at the most 50 detail entries. The OOO Resynch using the OXI Utility will generate messages containing only one room type per message.
New Out of Order messages will be created in PMS, and then sent to the HOLIDEX Plus system.
Create range of dates to exceed 20 days, there are to be multiple messages sent that will carry 20 days worth of data each, and then a second message with the remaining days of the OOO set in the PMS.
For example: if you have a Party of John Smith for 5 rooms and all split out; and add email to Mr. Smith's profile then there will be 5 records sent to update each reservation in CRS.
Sample: TPI Message with Email segment included. Existing reservation and profile is updated with New Email address.
Sample: TPI Message with Email segment included. New reservation and profile created together and includes New Email address.
Sample: TPI Message with Email segment included. Existing reservation and profile Email is updated.
Sample: TPI Message with Email segment deleted. Existing reservation and profile Email is deleted.
|
The original functionality of TPI Messages for Blocks called for the translation/conversion of special characters. It is now possible, however, to exclude numeric characters (1, 2, 3, 4 etc.) from this translation in the Allotment Name field of the block header. All fields other than Allotment Name will still follow the originally implemented translation logic. While the Allotment Name will still translate as special characters, numeric characters are passed without conversion.
The CS:F message is used to exchange the HOLIDEX Plus Group Block Security settings. The last five segments of the message display sets in Holidex which determine what info is exposed to the user. Security Messages have no functional impact in OPERA and are only Y or N fields that are stored and displayed when the screen is viewed again.
For Example:
SECURED FROM "DI" DISPLAY: N
ALL DESCRIPTION "DD" SECURED: N
RATES SECURED FROM GNR: N
RATES SECURED FROM ALL DISPLAYS: N
HOUSING INFORMATION SECURED: N
The CS:F message format is as follows:
CS:F/echo field/HHHHH/CCC/DDMMMYY/X/X/X/X/X<
1 2 3 4 5 6 7 8 9 10 11
|
HOLIDEX TPI |
Length / Values |
# |
Notes/Comments |
1 |
CS: |
Data Element Identifier |
3 |
|
2 |
F |
Flag A = Add
|
1 |
|
|
/ |
Delimiter |
1 |
|
3 |
Echo field |
Maximum 20 characters – Optional Field (Alpha (A-Z), Numeric (0-9) Field defined in the PMS system). |
20 |
|
|
/ |
Delimiter |
1 |
|
4 |
HHHHH |
Five character Inn Code as defined in HOLIDEX
|
5 |
(Five-character alpha (A - Z) as defined in HOLIDEX) |
|
/ |
Delimiter |
1 |
|
5 |
CCC |
Convention/Group Code 3 character |
3 |
This code can be a combination of alphanumeric characters, but the 1st character must always be alpha. If this field is populated, this GNR is part of a Convention Group block. And will be tracked as part of the Convention group block. |
|
/ |
Delimiter |
1 |
|
6 |
DDMMMYY |
Convention Start Date
|
1 |
|
|
/ |
Delimiter |
1 |
|
7 |
X |
Secured from “DI” Display Y = Yes N = No |
1 |
HOLIDEX Plus Group Information Screen Security setting |
|
/ |
Delimiter |
1 |
|
8 |
X |
All Description “DD” Secured Y = Yes N = No |
1 |
HOLIDEX Plus Group Information Screen Security setting |
|
/ |
Delimiter |
1 |
|
9 |
X |
Rates Secured From GNR Y = Yes N = No |
1 |
HOLIDEX Plus Group Information Screen Security setting |
|
/ |
Delimiter |
1 |
|
10 |
X |
Rates Secured From All Displays Y = Yes N = No |
1 |
HOLIDEX Plus Group Information Screen Security setting |
|
/ |
Delimiter |
1 |
|
11 |
X |
Housing Information Secured Y = Yes N = No |
1
|
HOLIDEX Plus Group Information Screen Security setting |
|
< |
End of Message |
|
|
Security messages (CS:F) sent in conjunction with allotment messages are processed inbound from Holidex as well as outbound. When OXI receives an inbound security message from Holidex, OXI will update the Holidex security flags stored in allotment$header with the values received in Holidex CS:F message.
A new flag has been created for the AC: segment. This flag, M, will identify the updated Accommodation In-House Change Segment and allows both the updated message and the original message to exist simultaneously while all property management systems are updated to use the new segment.
The Group Code field was added to the segment in the 6th position (between the Inn Code and the Rate Category in the current message). All subsequent fields have been moved forward one position. This field is delimited as are all other fields in this message.
Sample AC:M Segment Message
|
Message Details
|
HOLIDEX TPI |
Length/Values |
# |
Comments/Notes |
1 |
AC: |
Data element identifier |
3 |
|
2 |
M |
Flag M= Modify |
1 |
|
|
/ |
Delimiter |
1 |
|
3 |
Echo Field |
Maximum 20 characters – Optional Field (Alpha (A-Z), Numeric (0-9) Field defined in the PMS system). |
0- 20 |
|
|
/ |
Delimiter |
1 |
|
4 |
9999 |
Accommodation Segment’s Sequence Number (4 digit, numeric) |
4 |
This sequence number will match to the associated AR: (Arrival) Segment. |
|
/ |
Delimiter |
1 |
|
5 |
HHHHH |
Five character Inn Code as defined in HOLIDEX (Five-character alpha (A - Z) as defined in HOLIDEX) |
5 |
|
|
/ |
Delimiter |
1 |
|
6 |
CCC |
Convention/Group Code (3 alpha/numeric characters) |
3 |
Optional Field |
|
/ |
Delimiter |
1 |
|
7 |
XXXXXXXX |
Rate Category - (8 alpha / numeric characters) |
8 |
Rate Categories with less than 8 characters will be blank filled. |
|
/ |
Delimiter |
1 |
|
8 |
99 |
Number of Rooms (Numeric 01-99) |
2 |
|
|
/ |
Delimiter |
1 |
|
9 |
RRRR |
Room Type 4 character, alpha-numeric |
4 |
|
|
/ |
Delimiter |
1 |
|
10 |
DDMMMYY |
Arrival Date |
7 |
|
|
/ |
Delimiter |
1 |
|
11 |
99 |
Number of Nights (Numeric 01-99) |
2 |
|
|
/ |
Delimiter |
1 |
|
12 |
9999999 |
Arrival Rate |
7 |
|
|
/ |
Delimiter (Optional - only present if the following date field is present) |
0-7 |
|
13 |
DDMMMYY |
Start Date of Rate Change (Optional) |
0-7 |
|
|
/ |
Delimiter (Optional - only present if the previous date field is present) |
0-1 |
|
14 |
9999999 |
Rate 2 (Optional - only present if the previous delimiter is present) |
0-7 |
|
|
< |
End of Message |
|
|
During the process of a Rate Refresh from the HOLIDEX system, OXI now has the ability to parse rate messages in excess of 32k.
A new TPI message (IR:R) has been created to exchange room rate changes for a specific date or date range within an existing group. This message will contain the room type being modified, the rate amount and the date range the rate applies. The new TPI message will be generated by both OPERA and HOLIDEX to transmit the hotel code, group code, start date, end date, room type and rate changes made by either system in both directions.
Usage Notes
New fields have been added to the Business Block (that will be exchanged) as well as a new button (Security) to Business Block Options so that users will not have to make manual updates in HOLIDEX. The Business Block Options feature will only be available in SCH mode (refer to the OPERA Chain Specifics documentation for further details). OXI will add support for the additional segment to be added to the existing Convention: Group Create (CA:F) message, as well as the introduction of a new TPI message Convention: Group Security (CS:F).
Nine additional fields required in Allotment Header are as follows:
Note: Fields 1-4 will be made available through the Screen Painter and can be painted on the booking screen.
In the instance where there is an apostrophe present in the First or Last Name fields of the Reservation Edit screen in PMs and the record is processed in OXI; when the TPI message is built the apostrophe values are no longer striped from the NM:A segment of the reservation message.
Masked Credit Card Numbers
All displayed Credit Card numbers in TPI Messages are masked, save for the last four digits. This affects only the display and extract of the TPI messages in OXI message status, but does not impact the actual message exchanged and/or stored in the OXI tables and queues are. Message types where cc numbers will be masked are:
Additional Segments for the CA:F TPI Message
Additional segments have been added to the existing CA:F TPI message. The segments are appended to the end of the existing message. Following is an example of the modified CA:F message as well as an explanation of the new segments:
|
Message Details
14 |
99 |
Days Deposit |
2 |
Number of Days Deposit due to guarantee the guest booking. |
|
/ |
Delimiter |
1 |
|
15 |
99 |
Cancellation Notice |
2 |
Number of days before the arrival date a reservation can be canceled without losing the deposit |
|
/ |
Delimiter |
1 |
|
16 |
X |
Return One Day at A Time Y = Yes N = No |
1 |
|
|
/ |
Delimiter |
1 |
|
17 |
X |
Commisionable Y = Yes N = No |
|
Determines whether or not Travel Agent commission will be paid on reservations booked through the HOLIDEX Plus TACP program. |
|
< |
End of Message |
|
|
A new message has been created for the conveyance of HOLIDEX Plus Group Block Security information. The message format is as follows:
|
Message Details
HOLIDEX TPI |
Length/Value |
# |
Notes/Comments |
|
1 |
CS: |
Data Element Identifier |
3 |
|
2 |
F |
Flag A = Add |
1 |
|
|
/ |
Delimiter |
1 |
|
3 |
Echo Field |
Maximum 20 characters - Optional Field (Alpha (A-Z), Numeric (0-9) Field defined in the PMS system). |
2 0 |
|
|
/ |
Delimiter |
1 |
|
4 |
HHHHH |
Five Character Inn Code as defined in HOLIDEX |
5 |
(Five-character alpha (A - Z) as defined in HOLIDEX) |
|
/ |
Delimter |
1 |
|
5 |
CCC |
Convention/Group Code 3 Character |
3 |
|
|
/ |
Delimiter |
|
|
6 |
DDMMMYY |
Convention Start Date |
1 |
|
|
/ |
Delimiter |
1 |
|
7 |
X |
Secured from "DI" Display Y = Yes N = No |
1 |
HOLIDEX Plus Group Information Screen Security setting. |
|
/ |
Delimiter |
1 |
|
8 |
X |
All Description "DD" Secured Y = Yes N = No |
1 |
HOLIDEX Plus Group Information Screen Security setting |
|
/ |
Delimiter |
1 |
|
9 |
X |
Rates Secured From GNR Y = Yes N = No |
1 |
HOLIDEX Plus Group Information Screen Security setting |
|
/ |
Delimiter |
1 |
|
10 |
X |
Rates Secured From All Displays Y = Yes N = No |
1 |
HOLIDEX Plus Group Information Screen Security setting |
|
/ |
Delimiter |
1 |
|
11 |
X |
Housing Information Secured Y = Yes N = No |
1 |
HOLIDEX Plus Group Information Screen Security setting |
|
/ |
Delimiter |
1 |
|
|
< |
End of Message |
|
|
Inbound Message Priorities for TPI Messages
The following table shows the priority in which OXI will process inbound TPI messages from Holidex.
TPI Message Prefix |
Priority |
OXI Message Type |
CR |
1 |
(HX_MEMBERSHIP_TYPE) |
AD |
2 |
(HX_AVAILABILITY_TYPE) |
ID |
3 |
(HX_GROUP_INV_TYPE) |
GD |
3 |
(HX_GROUP_TYPE) |
ND |
3 |
(HX_AIB_GROUP_TYPE) |
RD |
4 |
(HX_RESERVATION_TYPE) |
ER |
4 |
(HX_ERROR_TYPE) |
HD |
5 |
(HX_HIRO_TYPE) |
SD |
6 |
(HX_RATE_TYPE) |
BD |
7 |
(HX_AIB_TYPE) |
Shoulder Date functionality will depend on OPERA application parameter called SHOULDER DATE. When this is active the on-screen parameter Elastic will display Shoulder Start and End dates on the header.
The following example is a screen capture of a Block Header where Shoulder Dates display.
Business Block setup with Shoulder Dates.
As long as no block with same block code overlaps in the same week a block can be extended into shoulder dates.
PMS Application Settings has parameter to set the limit on how many shoulder days can be added beginning/end of original block. See Setup>Application Settings>Blocks>MAX SHOULDER DAYS.
OXI HOLIDEX Share handling provides a method for PRISM agents and IHG partners via external connections, to trigger the PMS to identify reservations with multiple guest names as Shares rather than just multi-name reservations. This allows PMS to automatically establish each guest as a share, without a manual process being performed after the reservation is created.
In HOLIDEX Plus, the following service codes have been designated to indicate Share reservations.
For reservations received from HOLIDEX Plus for one room and more than one guest name, the following scenarios will apply:
If neither the SW nor SP Service Code is included, the current functionality of creating an Accompany shall remain in place. Uploading the SW or SP for shares created in OPERA is not required unless entered on the reservation by the user.
Modifications received in a download from HOLIDEX Plus to reservations that exist in OPERA as Shares, regardless of the original booking source, shall be applied if all guests are still in reserved status as follows:
Changes to the Arrival and/or Departure date of the HOLIDEX Plus reservation shall be applied to all guests on the shared reservation, even if the original arrival and/or departure dates were different for any guest.
Rate Changes will be applied to all guests if Split (split rate evenly) had been applied on the existing reservation. Rate Changes will be applied only to the primary guest if Entire had been applied on the existing reservation.
All other guests on the shared reservation shall remain at a zero rate. If a rate had manually been applied to each guest, the new rate shall be applied to the primary guest and all other guests on the shared reservation shall be set to a zero rate.
Modifications received in a download from HOLIDEX Plus to reservations that exist in OPERA as Shares will not be applied if any of the guests on the shared reservation are checked in.
Modifications received in a download from HOLIDEX Plus to reservations that exist in OPERA as Accompany, regardless of the original booking source, shall be applied if all guests are still in reserved status as follows:
An example of Sell Limit setting in OPERA PMS and the effect of Group details is displayed in the AIB Utility screen. See the first example below. When AIB is requested and groups that have Sell Limit setting for non-deductible inventory days will not show corresponding grid inventory details when reviewed. See the second screen shot following for this example.
The following screen shot is an example of a Group Header with the Elastic field checked so that Shoulder Dates and Sell Limits are available.
This next screen shot is of the AIB Utility Group Details screen. The group below is showing no inventory details on the HOLIDEX side as the value of the Sell Limit is a non- deduct type of inventory and will not be included in the count of inventory.
Note: The Start Date must equal the current business date or a date in the future. Users attempting to enter a date in the past, by either entering the date manually or using the Calendar option, will receive the message: "Please select current business date or future date." Select OK to re-enter a current or future date.
OXI Cutoff Date Handling follows the subsequent logic:
For example, note the following CA:M message:
CA:M/EchoField/FILHH/ABC/01DEC08/03DEC08/08DEC08/TEST GROUP/Y/
08DEC08
/Y/0000000
The last date of the group is highlighted in red. At the time of the message, the last date of the group was December 8, 2008. No cutoff date was present in OPERA and Cutoff Days were used.
Previously the Group Notes were limited to General Note group and no new notes could be entered from PMS to update the CRS.
Sample: TPI Message with Note segment included
|
Previous rate changes in reservations were limited to only one change in HOLIDEX messages. The 'AC' accommodation segment of the TPI message displays the initial rate code, room type and rate amount with one rate change indicated. Now OXI has been enhanced to allow up to 20 rate changes to be accounted for in the TPI message. The changes will be reflected in the 'AC' accommodation segment with date and rate amount of the change. (Available as of V4.0.4.02).
Sample: TPI Message with multiple rates indicated in the AC segment
|
If a default currency code (Interface Configuration>Interface Defaults>Reservation tab>Currency) has been set for HOLIDEX, OXI will upload the code found in that field. When this field is populated it will be included at the end of every AC:A segment uploaded to HOLIDEX Plus, if not populated, then no default currency code is included in the AC:A segment. See Reservation Defaults for OXI for more details.
In OPERA, any block that has a null value for the HOLIDEX original begin date and shows in AIB as not exchanged with the external systems, will be uploaded to (and the block will be created in) the system. The HOLIDEX original begin date will also be updated in the ALLOTMENT_HEADER table for the record in OPERA. (Available as of V4.0.4.02).
The Automatic Reconciliation Utility has been modified to find bookings that fall outside of the requested range, compare and if need be, balance. Previously, reservations that exceeded the snapshot time-span for an AIB request were excluded from comparison and leaving inventory imbalance in the external system. These reservations can now be included in the AIB request.
The synchronous request to retrieve a CRS number for a new reservation has been modified to use the presence of a CRS number in a reservation to determine whether (or not) to reject the NEW RESERVATION business event rather than relying upon the presence of a synchronous record in the message status table.
If the TA (Travel Agent) profile has been validated successfully against the HOLIDEX system, the TA number gets included in the reservation message even if the commission related configuration on the OPERA Travel Agent profile is incorrect or missing. Profile subscription is used to indicate whether the TA profile has been successfully validated against HOLIDEX or not. Once the TA Profile is successfully validated, a HOLIDEX profile subscription record is created (if it does not already exist) for the OPERA profile without an external name ID. If the validation of Travel Agent profile against HOLIDEX is unsuccessful, the HOLIDEX profile subscription record is removed from the OPERA profile. The update reservation messages do not carry Travel Agent numbers, even if the TA number has been validated, unless the TA is being added or modified during the reservation. When building the reservation TPI message, the presence of a HOLIDEX subscription is checked to verify if the TA number is good.
As HOLIDEX Plus exchanges rate messages with the use of delta handling and only downloading the modified date ranges, the overall size of rate modification messages is greatly reduced which allows for an increase in the performance of the network, or networks, being used.
With the Delta Handling, the RU: Message Type will be used for Rate Download Changes, but does not include any subsequent RT: (Individual Rate Codes) segments so the entire details of the date ranges, room types, and rate amounts are not included, and is sent if any of the following fields are updated at the Rate Category Level:
The download will only include those fields that were updated, and all of the fields that were updated will be grouped together in one message. Changes to the Start Date, End Date, or Currency Code of the Rate Category will trigger a Full Rate Refresh (RC: message type).
Sample: RU: Message Type for Rate Header Update Original Message
Updated Message
Only the Booking Message (BM:) will be updated based on the Delta Handling as this is the only details that were updated. |
Sample: RU: Message Type for Rate Details Update Note that in this following samples, Rate Tiers are active and are configured as 1=1-5, 2=6-8, 3=9-9999. Sample 1 This message creates the addition of a new rate set.
Sample 2 This message creates 3 new rate sets for Tier 2 (6-8) for the same dates and room types.
Sample 3 This message changes the rate details for Tier 1.
|
The RN: Message Type reflects the Rate Code (Non-Date and Rate Dependent Details) that are passed with the RT: Message Type and contains the following fields:
If the value of one of the above fields is updated, then only the RN: Message Type will be sent instead of the whole RT: Message Type being sent for updating the information.
Sample: RN: Message Type for Rate Details Update Sample 1 This message updates the Transaction Tax Inclusion Flag and the Extra Person In Rate calculation to 25.
Sample 2 This message removes all Tiered Rate Sets and updates the Extra Person In Rate calculation to 12.
|