Page Comparison

1. GENERAL

1.1 - Linespacing

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

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

1.2 - SOAP header

All the highlighted attributes (see the below XML) 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

As unique as possible per request by following GUID standards.

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

...

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

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:

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

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:

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

<AvailStatusMessages HotelCode="ABC">
	<AvailStatusMessage BookingLimit="4">
		<StatusApplicationControl Start="2018-11-08" End="2018-11-08" InvTypeCode="DBL" RatePlanCode="BAR"/>
		<LengthsOfStay>
			<LengthOfStay MinMaxMessageType="SetMinLOS" Time="1"/>
			<LengthOfStay MinMaxMessageType="SetMaxLOS" Time="999"/>
		</LengthsOfStay>
		<RestrictionStatus Status="Open"/>
	</AvailStatusMessage>
</AvailStatusMessages>

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

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

Restrictions (@RatePlanCode but no @BookingLimit):

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

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

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

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

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:

<BaseByGuestAmts>
	<BaseByGuestAmt AmountAfterTax="156.00"/>
</BaseByGuestAmts>

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:

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

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>

3.4 - OTA_NotifReportRQ

Confirmation request specification:

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

<OTA_NotifReportRQ  xmlns="http://www.opentravel.org/OTA/2003/05 " Version="1.0" EchoToken="64265f9f-5b82-409e-8d8d-058e04b6df40" TimeStamp="2018-06-20T18:32:52+04:00">

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

<HotelNotifReport>
	<HotelReservations>
		<HotelReservation CreateDateTime="2018-06-20T18:32:20+04:00" ResStatus="Book">
			<UniqueID Type="16" ID="3123456"/>
			<ResGlobalInfo>
				<HotelReservationIDs>
					<HotelReservationID ResID_Type="14" ResID_Value="BDC-856972"/>
				</HotelReservationIDs>
			</ResGlobalInfo>
		</HotelReservation>
	</HotelReservations>
</HotelNotifReport>

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>

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.

...

...

1. GENERAL

1.1 - Linespacing

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

1.2 - SOAP header

All the

1.3 - WSSE namespace

As the soap:Header / Security element conveys authentication information, it should have its namespace declared as

1.4 - EchoToken

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” valueequals 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.

...

2. ARI UPDATES

2.1 - Data Bundling

Rate, Availability or Restriction updates must be