pmsXchange v2 Pre-Certification Checklist

1. GENERAL

1.1 - Linespacing

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

1.2 - SOAP header

All the highlighted attributes need to be included.

1.3 - 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

1.4 - EchoToken

EchoToken as unique as possible per request by following GUID standards.

1.5 - 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”

1.6 - 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.

Open

2. ARI UPDATES

2.1 - 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:

Open

This is NOT expected:

2.2 - 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:

This is NOT expected:

2.3 - Availability

• Room Level: in the case your PMS operates on Room (Type) Level availability, 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):

Restrictions (@RatePlanCode but no @BookingLimit):

• Room 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:

2.4 - Min / Max LOS Restrictions

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

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

2.5 - Stop Sell / CTA / CTD

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:

<RestrictionStatus Restriction="Arrival" Status="Open"/>
<RestrictionStatus Restriction="Departure" Status="Open"/>

2.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:

<Rate CurrencyCode="AUD" Start="2019-01-01" End="2019-01-14">

3. RESERVATION SERVICE

3.1 - Reservation polling interval

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.

3.2 - Steps involved

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

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

3.3 - Availability pass back request

This is a delta update meaning that only the affected availability should be sent through. Note, The Channel Manager does NOT top up the availability after a modification / cancellation delivery. As a result, 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.

The modified reservation BDC-856972 has been cancelled. 

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

3.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.

3.5 - Error handling

If a reservation cannot take place (for instance, your PMS doesn’t support overbookings and there’s no availability), 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.