pmsXchange v2 pre-certification checklist

GENERAL

Linespacing

The entire message should be contained on one single line only:

SOAP header

All the highlighted attributes (see the below XML) need to be included.

WSSE namespace

As the soap:Header / Security element conveys authentication information, it should have its namespace declared as 'wsse', the standard schema for sensitive information and the 'wsse' tag should be applied for each element within the soap:Header

EchoToken

As unique as possible per request by following GUID standards.

TimeStamp

DateTime format requested: yyyy-MM-dd'T'HH:mm:ss+XX:XX, no milliseconds. If no timezone is declared, we assume the PMS is using UTC as this is the default timezone. If a timezone is declared, the time value should reflect the actual local time. The same goes for @CreateDateTime / @LastModifyDateTime.

UTC: “2018-06-20T08:32:52” value equals GMT+8: “2018-06-20T16:32:52+08:00”

Day Indicators

if using, make sure it doesn’t restrict updates from being applied. For instance, if the message contains a date range consisting of 2018-12-04 (Tuesday) and 2018-12-05 (Wednesday),Tue="0" and Weds="0" will block the update.

<soap:Envelope
	xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
	<soap:Header>
		<wsse:Security
			xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soap:mustUnderstand="1">
			<wsse:UsernameToken>
				<wsse:Username>USERNAME</wsse:Username>
				<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">SECRET</wsse:Password>
			</wsse:UsernameToken>
		</wsse:Security>
	</soap:Header>
	<soap:Body>
		<OTA_ReadRQ
			xmlns="http://www.opentravel.org/OTA/2003/05 " Version="1.0" EchoToken="64265f9f-5b82-409e-8d8d-058e04b6df40" TimeStamp="2018-06-20T16:32:52+08:00">
			<POS>
				<Source>
					<RequestorID Type="22" ID="PMS1"/>
				</Source>
			</POS>
			<ReadRequests>
				<HotelReadRequest HotelCode="ABC">
					<SelectionCriteria SelectionType="Undelivered" ResStatus="Book"/>
				</HotelReadRequest>
			</ReadRequests>
		</OTA_ReadRQ>
	</soap:Body>
</soap:Envelope>

ARI UPDATES

Data Bundling

Rate, Availability or Restriction updates must be bundled in instances where the values for consecutive dates are the same as well as the room / rate combination using @Start and @End attributes. An example of availability update of ‘15’ for 21st and 22nd November 2018 for Double Room (DBL) is the following:

<AvailStatusMessages HotelCode="ABC">
	<AvailStatusMessage BookingLimit="15">
		<StatusApplicationControl Start="2018-11-21" End="2018-11-22" InvTypeCode="DBL"/>
	</AvailStatusMessage>
</AvailStatusMessages>

This is NOT expected:

<AvailStatusMessages HotelCode="ABC">
	<AvailStatusMessage BookingLimit="15">
		<StatusApplicationControl Start="2018-11-21" End="2018-11-21" InvTypeCode="DBL"/>
	</AvailStatusMessage>
	<AvailStatusMessage BookingLimit="15">
		<StatusApplicationControl Start="2018-11-22" End="2018-11-22" InvTypeCode="DBL"/>
	</AvailStatusMessage>
</AvailStatusMessages>

Delta Updates

All the requests (Availability, Restrictions & Rates) must only contain data relevant to the action being performed in your PMS. In other words, we require the messages to be as small as possible, meaning that only the modifications should be sent. No unchanged dates should be included in these request messages. For instance, if in a certification scenario we ask you to update ‘Availability’ to ‘4’ for Double Room (DBL) - Best Available Rate (BAR) for the 8th of November 2018, we expect to receive one single request containing only one message exclusively consisting of Availability data and nothing else:

<AvailStatusMessages HotelCode="ABC">
	<AvailStatusMessage BookingLimit="4">
		<StatusApplicationControl Start="2018-11-08" End="2018-11-08" InvTypeCode="DBL" RatePlanCode="BAR"/>
	</AvailStatusMessage>
</AvailStatusMessages>

This is NOT expected:

3. Availability

• ROOM LEVEL: in the case your PMS operates on Room (Type) Level availability, please do NOT include @RatePlanCode to your availability messages. Therefore, it is advisable to push availability updates separately from restriction updates to avoid sending through the same information (@BookingLimit) in case there’s multiple rate plans linked to the same room type. This means we do not need to read and validate it multiple times as well.  

  Availability (no @RatePlanCode):

• RATE LEVEL : @RatePlanCode should only be contained in the availability updates if your PMS supports Rate (Plan) Level availability. In this particular case you can bundle together availability and restriction updates.

Availability and Restrictions bundled together into one message:

<AvailStatusMessages HotelCode="ABC">
    <AvailStatusMessage BookingLimit="14">
      <StatusApplicationControl Start="2018-07-20" End="2018-07-23" InvTypeCode="DBL" RatePlanCode="BAR"/>
      <LengthsOfStay>
        <LengthOfStay MinMaxMessageType="SetMinLOS" Time="2"/>
        <LengthOfStay MinMaxMessageType="SetMaxLOS" Time="7"/>
      </LengthsOfStay>
      <RestrictionStatus Status="Open" />
    </AvailStatusMessage>
  </AvailStatusMessages>

4. Min / Max LOS Restrictions

 If certifying for both, make sure to bundle Minimum and Maximum LOS where applicable:

<LengthsOfStay>
  <LengthOfStay MinMaxMessageType="SetMinLOS" Time="2"/>
  <LengthOfStay MinMaxMessageType="SetMaxLOS" Time="999"/>
</LengthsOfStay>

The above isn’t available for RestrictionStatus element as there can only be one RestrictionStatus element per AvailStatusMessage.

5. Stop Sell / CTA / CTD

Please note that StopSell, CTA and CTD are completely independent from each other. A room can be open  <RestrictionStatus Status="Open"/> while CTA (or CTD) being applied <RestrictionStatus Restriction="Arrival" (Restriction="Departure") Status="Close"/> at the same time, and vice versa. In other words - StopSell, CTA and CTD can be received separately so their status should be assumed as separate - for instance, a message which sets StopSell will not change the states of closed to arrival and departure.

Similarly, when removing CTA or CTD, @Restriction attribute has to be used as well:

6. Rates

Rate is a positive decimal value - a rate of 156 should be sent through as 156.00:

It is mandatory to specify the @CurrencyCode:

7. Rates / Restrictions per Booking Channel

Please make sure to bundle Booking Channels in instances where the date range, room and rate combination as well as the value being updated are identical.

NOTE : If you choose to utilise 'Rates Per Booking Channel', you must be able specify ALL channels the hotel has connected. We recommend having a seperate 'mode' that hotels switch to that allows them to then set a rate for each booking(s) agent. It is not acceptable to send room + rate level rate updates, then overlay with the Per Booking Agent exceptions.

NOTE : Availability per Booking Channel is not supported, only rates and restrictions.

3. RESERVATION SERVICE

1. Reservation polling interval - please ensure to pull reservations every 2-5 minutes. In other words, reservations / modifications / cancellations should never be requested more often than every 2 minutes and less often that every 5 minutes.

2. Steps involved - please make sure to cover all the steps involved in the Reservation API for each reservation / modification / cancellation (if applicable):

• Request Reservation = ReadRQ

• Confirm Reservation delivery upon the first delivery attempt = NotifReportRQ. Either with “Success” or “Error” response, ensure that every single reservation receives NotifReportRQ. More than 1 delivery attempt is considered as an issue.

• Send back the affected ‘Availability’ change (delta update) = HotelAvailNotifRQ

Please make sure to confirm the reservation delivery and send us back the affected availability as fast as possible, preferably under 1 minute.

3. Availability pass back request - this is a delta update meaning that only the affected availability should be sent through. Please note, The Channel Manager does NOT top up the availability after a modification / cancellation delivery. As a result, please ensure the following:

• Reservation - reduced availability (for the affected room and date) has to be pushed back to pmsXchange.

• Cancellation - once a cancellation has been confirmed, the availability affected by this cancelled reservation has to be topped up (it should NOT remain unchanged / being further reduced) and pushed to pmsXchange. 

• Modification - once a modified reservation has been delivered AND the check-in / check-out dates have changed, availability for dates that are not occupied anymore by this modified reservation have to be topped up. Availability covering dates that remain in the modified reservation shouldn’t change. Newly added dates must trigger an availability reduction.

Example

The initial availability of Double Room is “3” for the entire month of December 2018. A 3-night reservation BDC-856972 has been booked for Double Room: 

• Check-in: 12th of December 2018

• Check-out: 15th of December 2018

Expected - availability has dropped by one unit (from “3” to “2”) for the affected period, excluding the check-out date:

The reservation BDC-856972 has been modified, and the stay period has been moved forward by one day:

• Check-in: 13th of December 2018

• Check-out: 16th of December 2018

Expected - the availability has been topped up for the 12th of December as BDC-856972 modified reservation does NOT cover this date anymore, hence the availability goes back to “3”. However, there’s a new check-out date (16th of December 2018) and therefore 15th of December has to be reduced to “2”. There’s no change for the 13th and the 14th of December.

<AvailStatusMessages HotelCode="ABC">
    <AvailStatusMessage BookingLimit="3">
      <StatusApplicationControl Start="2018-12-12" End="2018-12-12" InvTypeCode="DBL"/>
    </AvailStatusMessage>

    <AvailStatusMessage BookingLimit="2">
      <StatusApplicationControl Start="2018-12-15" End="2018-12-15" InvTypeCode="DBL"/>
    </AvailStatusMessage>
</AvailStatusMessages>

The modified reservation BDC-856972 has been cancelled. 

Expected - availability top up back to “3” for all dates affected by this cancellation:

<AvailStatusMessages HotelCode="ABC">

    <AvailStatusMessage BookingLimit="3">
      <StatusApplicationControl Start="2018-12-13" End="2018-12-15" InvTypeCode="DBL"/>
    </AvailStatusMessage>
</AvailStatusMessages>

4. OTA_NotifReportRQ - confirmation request specification:

Make sure to include @TimeStamp, @EchoToken, @Version and xmlns namespace;

If ResStatus is “Book” - @CreateDateTime attribute should be used. The value should follow TimeStamp specification.

If ResStatus is “Modify” or “Cancel” - @LastModifyDateTime attribute should be used. The value should follow TimeStamp specification.

<HotelNotifReport>
      <HotelReservations>
        <HotelReservation LastModifyDateTime="2018-06-21T11:45:05+04:00" ResStatus="Modify">
          <UniqueID Type="16" ID="3123457"/>
          <ResGlobalInfo>
            <HotelReservationIDs>
              <HotelReservationID ResID_Type="14" ResID_Value="BDC-856972"/>
            </HotelReservationIDs>
          </ResGlobalInfo>
        </HotelReservation>
      </HotelReservations>
</HotelNotifReport>

5. Error handling - if a reservation cannot take place (for instance, your PMS doesn’t support overbookings and there’s no availability), please ensure to be as specific as possible in your error response. Hoteliers receive this message, so being as specific as possible in your error response will help them to troubleshoot without having go through our or your support teams.