Business Rules for New Reservations to-from Marsha

New transient single reservation

New profile information is not uploaded to MARSHA, as no profile records are maintained in MARSHA.

• For a reservation change, any modified guest profile details are uploaded.
• On a reservation for a Pseudo room type or on a check-in, no message is send to MARSHA.
• When a new booking is uploaded, OXI converts the data using the conversion tables. Dates are converted into YYYYMMDD date format.

New company reservation with company profile attached

In addition to the business logic and conditions applying to an individual single reservation, company details are now linked to the reservation. The address location must be (C) to indicate a company booking.

Day use reservation

For Day Use reservations, the reservation type in PST / RAT will be shown as (NR) for day use reservation

Walk-in reservation

If the guest in already checked in, then (IH) is sent in the PST / ARS section of the message.

New contiguous reservation

• If a rate code or rate amount changes during the guest’s stay, the PMS user creates multiple rate codes in one reservation in PMS.
• The upload message will contain the details that are valid for the entire stay of the reservation and entered into the daily elements of the PMS reservation.
• All the rate codes, rate amounts, number of adults, market codes will be uploaded to MARSHA.
• These rate changes are reflected as multiple RAT components in the upload message.

Business Rules for New Reservations From Marsha

• With all new reservations, OXI checks if the reservation already exists in PMS. Check criteria is on the CRS confirmation number.
• The price calculation will take number of adults and the OXI parameter CRS_PRICE_CONTROL into consideration. The rate program is converted and the result written into the rate code and market segment fields.  
• The room pool conversion will take place as described under section Room pool conversion - Room Types and Request Codes  
• All RQS components are processed in a reservation file. In case the room request status is (HK), it is checked if it is a guarantee code and will be converted and written into the guarantee field, otherwise in the request field.  The current guarantee codes used are A5, K1, N3, D4, W4, W5, A8, C8, C9, G2, H2, I4, L5, M3, O2, P2, R7 and S7.
• If the room request status is (RD) or (NN) or (NO), the code will be converted and written to the request field. Marriott can add guarantee codes at any time, and this will not affect the interface.
• Marsha will send the latest accumulated stay information for a guest with each reservation download.
• Since Marsha will be the system with the more accurate history data, OXI will update the respective information in the OPERA tables each time a download is received. The data will consist of stay information for that particular property as well as the overall stay information for all Marriott/Ritz properties combined.
• The prerequisite for linking a travel agent profile is the address location (T) sent by MARSHA in the AD2 component. In this case, all following elements of the same AD2 component are written into the TA profile.
• An Agency profile is only accepted if the agency number IATA is sent by MARSHA. The IATA is the match criterion for the match and merge of existing Travel Agent profiles.
• In case the sent IATA number does not exist in PMS, then depending on OXI parameter CREATE_PROFILE = Y, a new TA profile with all the details sent is created and linked to the reservation.

New company reservation with Company profile attached

Based on Company/Travel Agency/Wholesaler profile functionality:

Profile linking/matching in OXI with an associated GNR/Reservation from MARSHA for Company, Travel Agency, or Wholesaler reservations will link the appropriate profile type regardless of the Market Code (in MARSHA) / Rate Code (in OPERA).

New reservation with multiple rate changes (contiguous booking)

• For multiple RAT components, OXI will create a contiguous booking: one reservation with multiple reservation details in the same record will be created for the changing rate, rate code, rate duration, and rate start date.
• This functionality replaces the action traces for rate changes in PMS V6.

New reservation with multiple stay dates (itinerary booking)

• For multiple PST sections, we will create an itinerary booking: several reservations with different dates for the same guest.
• All reservations will have the same CRS confirmation number.
• Only the reservations with current dates that are part of the itinerary booking are sent.
• If segments with dates that are further in the future are part of the booking, they will be downloaded at a later stage, once they fall into the correct date window.
• One guest profile is linked to all reservations.

Reservations Split in MARSHA (GNR’s made for multiple rooms)

MARSHA will continue to send split GNR’s/Reservations the same way it currently does, when PA’d:  force send from Marsha CRS. Then one profile will initially get created in OPERA.

• MARSHA will send a trigger or identifier with GNR/Reservation booking modifications (BKGMOD) that consist of name changes for split reservations.
• A (C) will be placed in the NAME QUALIFIER element in the NAM component sent from MARSHA for (name change) booking modifications made in MARSHA, to split reservations.  The interface should then recognize this identifier and then create a new profile for the reservation associated with that MARSHA confirmation number and link the new profile to that reservation (in Fidelio) only.  
• The new profile should write the Name addition only into the new profile.  In other words, the interface should take the new first and last name (from the BKGMOD) and create the new profile off of that, the address information from the original (split) profile should not be carried over.
• If an address change is sent along with the name change then that should populate in the new profile. The reason for this is so we do not create new profiles with incorrect address information.

Sample:  Below is a scenario for future changes to guest name

• A GNR is made in MARSHA for 5 rooms under then name John Smith.
• The reservations then gets PA’d at some point after.  
• Once PA’d, to the property (PMS system), the guest calls a central reservation office and changes the name for one of the reservations (which have now been split into 5 separate MARSHA reservations) to Brian Johnson.  
• After the change is made in MARSHA, a separate profile is created for Brian Johnson, and is attached to the appropriate reservation in OPERA.
• Brian Johnson’s profile will have the first and last name only unless an address change is sent along with the name change message.  The four (4) reservations would still be attached to the original guest profile.
• It is understood that if that same reservation has the name changed afterwards again that a separate profile would then be created again. The name change will come with the (C) qualifier.