Skip to content

4.4. Inventory: room category information

The Inventory request allows up to four values for the action parameter (depending on the server exposed capabilities):

  • OTA_HotelDescriptiveContentNotif:Inventory indicates the client wishes to define a room category, send its basic description and optionally provide a list of specific rooms for each category (see section Inventory/Basic (push)).

  • OTA_HotelDescriptiveInfo:Inventory indicates the client wishes to retrieve the information about room category, basic description and the list of specific rooms (see section Inventory/Basic (pull)).

  • OTA_HotelDescriptiveContentNotif:Info indicates the client wishes to send additional descriptive content (see section Inventory/HotelInfo (push)).

  • OTA_HotelDescriptiveInfo:Info indicates the client wishes to retrieve the additional descriptive content (see section Inventory/HotelInfo (pull)).

4.4.1. Inventory/Basic (push) client request

The parameter request contains an OTA_HotelDescriptiveContentNotifRQ document.

Each document contains one HotelDescriptiveContent element. For the attributes HotelCode and HotelName the rules are the same as for room availability notifications (section 4.1.1). Note that information about only one hotel per message can be transmitted.

Nested inside HotelDescriptiveContent, an FacilityInfo element contains a list of zero or more GuestRoom elements. There are two distinct kinds of GuestRoom elements:

  • The heading one is used to define a room category and its basic description (the category is identified by the attribute Code).

  • The following ones list specific rooms for each category (identified by the attribute Code).

More than one category can be transmitted. That means a category defining sequence of one-heading- GuestRoom-element plus zero or more following- GuestRoom-elements can be repeated for each category.

Sending zero GuestRoom elements (meaning an empty GuestRooms element) will remove all room categories for the given hotel.

Below is an example of the global structure of such a document:

<OTA_HotelDescriptiveContentNotifRQ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.opentravel.org/OTA/2003/05" xsi:schemaLocation="http://www.opentravel.org/OTA/2003/05 OTA_HotelDescriptiveContentNotifRQ.xsd" Version="8.000"> <HotelDescriptiveContents> <HotelDescriptiveContent HotelCode="123" HotelName="Frangart Inn"> <FacilityInfo> <GuestRooms> <!-- the heading GuestRoom element is used to define a category and its basic description -→ <GuestRoom Code="DZ" MaxOccupancy="2" MinOccupancy="1" MaxChildOccupancy="1"> </GuestRoom> <!-- the follow-up GuestRoom elements list the specific rooms in the category -→ <GuestRoom Code="DZ"> <TypeRoom RoomID="101"/> </GuestRoom> <GuestRoom Code="DZ"> <TypeRoom RoomID="102"/> </GuestRoom> </GuestRooms> </FacilityInfo> </HotelDescriptiveContent> </HotelDescriptiveContents> </OTA_HotelDescriptiveContentNotifRQ>

samples/Inventory/Inventory-Push-OTA_HotelDescriptiveContentNotifRQ-basic.xml - outer part

The heading GuestRoom element, used to define a room category and its basic description, contains the following attributes:

  • Code: mandatory, identifies the category.

  • MinOccupancy: mandatory, sets the minimum number of guests allowed for this room category.

  • MaxOccupancy: mandatory, sets the maximum number of guests allowed for this room category.

  • MaxChildOccupancy: optional, must be 0 ≤ MaxChildOccupancy ≤ MaxOccupancy. This attribute can be used to influence the computation of the total cost of the stay in the presence of children (see section 4.5 under "Computing the cost of a stay" for details). Note that this attribute cannot be used to disallow children in a stay. This attribute may only be used if the capability OTA_HotelDescriptiveContentNotif_Inventory_occupancy_children is announced by the server.

  • ID: optional, used for updating room category codes (see remarks at the end of this section)

The heading GuestRoom element also contains the following sub-elements:

  • TypeRoom: mandatory element with the attributes:

    • StandardOccupancy (mandatory)

    • RoomClassificationCode (mandatory) to classify the kind of guest room following the OTA list "Guest Room Info" (GRI) - 42 means just "Room", 13 means "Apartments", "5" means "Pitches", etc…​

    • RoomType (optional) to allow a more exact classification of the guest accommodation (see below)

    • Size (optional)

  • Amenities: optional element containing a list of Amenity elements, each indentified by the mandatory attribute RoomAmenityCode following the OTA list "Room Amenity Type" (RMA).

  • MultimediaDescription: one or more elements with an InfoCode attribute with certain values (a subset of the OTA list "Information type" (INF)):

    • Exactly one MultimediaDescription element with attribute InfoCode = 25 (Long name) indicating a title must be present.

    • At most one MultimediaDescription element with attribute InfoCode = 1 (Description) may be present.

    • At most one MultimediaDescription element with attribute InfoCode = 23 (Pictures) may be present.

Regarding the optional attribute RoomType, the allowed values are defined by AlpineBits® as follows:

  • For rooms: RoomType value 1 (should only be used when RoomClassificationCode is 42).

  • For apartments: RoomType value 2 (should only be used when RoomClassificationCode is 13).

  • For mobile homes: RoomType value 3 (should only be used when RoomClassificationCode is 13).

  • For bungalows: RoomType value 4 (should only be used when RoomClassificationCode is 13).

  • For holiday homes: RoomType value 5 (should only be used when RoomClassificationCode is 13).

  • For camping grounds (place for vehicles in a camping): RoomType value 6 (should only be used when RoomClassificationCode is 5).

  • For pitches (place for tents in a camping): RoomType value 7 (should only be used when RoomClassificationCode is 5).

  • For camping grounds/pitches (place for either tents or vehicles in a camping): RoomType value 8 (should only be used when RoomClassificationCode is 5).

  • For resting places (beds in shared rooms, like hostels or mountain huts): RoomType value 9 (should only be used when RoomClassificationCode is 42).

Here is an example of such a heading GuestRoom element:

<GuestRoom Code="DZ" MaxOccupancy="2" MinOccupancy="1" MaxChildOccupancy="1"> <TypeRoom StandardOccupancy="2" RoomClassificationCode="42"/> <Amenities> <Amenity RoomAmenityCode="26"/> </Amenities> <MultimediaDescriptions> <MultimediaDescription InfoCode="25"> </MultimediaDescription> <MultimediaDescription InfoCode="1"> </MultimediaDescription> <MultimediaDescription InfoCode="23"> </MultimediaDescription> </MultimediaDescriptions> </GuestRoom>

samples/Inventory/Inventory-Push-OTA_HotelDescriptiveContentNotifRQ-basic.xml - a heading GuestRoom element

The MultimediaDescription elements follow these rules:

  • A MultimediaDescription element with attribute InfoCode = 25 or 1 must contain only a single TextItem element.

  • A MultimediaDescription element with attribute InfoCode = 23 contains only ImageItem elements (one or more).

Here is an example:

<MultimediaDescriptions> <MultimediaDescription InfoCode="25"> <TextItems> <TextItem> <Description TextFormat="PlainText" Language="en"> Double room</Description> <Description TextFormat="PlainText" Language="de"> Doppelzimmer</Description> <Description TextFormat="PlainText" Language="it"> Camera doppia</Description> </TextItem> </TextItems> </MultimediaDescription> <MultimediaDescription InfoCode="1"> <TextItems> <TextItem> <Description TextFormat="PlainText" Language="en"> Description of the double room.</Description> <Description TextFormat="PlainText" Language="de"> Doppelzimmer Beschreibung.</Description> <Description TextFormat="PlainText" Language="it"> Descrizione della camera doppia.</Description> </TextItem> </TextItems> </MultimediaDescription> <MultimediaDescription InfoCode="23"> <ImageItems> <ImageItem Category="6"> <ImageFormat CopyrightNotice="Copyright notice 2015"> <URL>http://www.example.com/image.jpg</URL> </ImageFormat> <Description TextFormat="PlainText" Language="en"> Picture of the room</Description> <Description TextFormat="PlainText" Language="de"> Zimmerbild</Description> <Description TextFormat="PlainText" Language="it"> Immagine della stanza</Description> </ImageItem> </ImageItems> </MultimediaDescription> <MultimediaDescriptions>

samples/Inventory/Inventory-Push-OTA_HotelDescriptiveContentNotifRQ-basic.xml - MultimediaDescription elements

TextItems contains a TextItem element, which must contain one or more Description elements, each with the mandatory attributes TextFormat and Language.

The following rules hold:

  • The attribute TextFormat is set to PlainText or HTML and the attribute Language is set to a two-letter lowercase language abbreviation according to ISO 639-1. At most one Text element is allowed for each combination of Language and TextFormat.

  • The presence of a TextItem element with TextFormat set to HTML is intended as a rich text alternative of a TextItem element with TextFormat set to PlainText of the same Language and makes the latter mandatory.

  • Please note that an AlpineBits® server is explicitly allowed to filter, shorten or even skip the HTML content, therefore the usage of TextItem elements with TextFormat set to HTML is not recommended but left as an option for implementers that absolutely need it.

ImageItems contains a list of one or more ImageItem elements with mandatory Category attribute following the OTA list "Picture Category Code" (PIC). Typical values are 6 (Guest Room) and 17 (Map) but the whole table is allowed. The ImageItem element contains a single, mandatory ImageFormat element with the optional attribute CopyrightNotice. Inside, a single mandatory element URL, holds the URL where the picture can be retrieved as its value. Zero or more Description elements follow, under the same rules outlined above for descriptions contained in the element TextItem. Images should be processed by the server in the order they are submitted (i.e. the order used to show the pictures the to end users should be consistent with the one sent by the client).

The following GuestRoom element lists all the rooms belonging to a category, as we’ve seen in the first code sample, repeated here:

<!-- the follow-up GuestRoom elements list the specific rooms in the category -→ <GuestRoom Code="DZ"> <TypeRoom RoomID="101"/> </GuestRoom> <GuestRoom Code="DZ"> <TypeRoom RoomID="102"/> </GuestRoom>

samples/Inventory/Inventory-Push-OTA_HotelDescriptiveContentNotifRQ-basic.xml - part showing follow-up GuestRoom elements

Following GuestRoom elements have a mandatory Code attribute that identifies the category the specific room belongs to. No further attributes are allowed.

They also have a mandatory sub-element TypeRoom with a mandatory attribute RoomID that identifies the specific room. No further elements or attributes are allowed, included (but not limited to) the MultimediaDescription element.

If a server sets the capability OTA_HotelDescriptiveContentNotif_Inventory_use_rooms, a client must send the full list of rooms and the server must store it.

Otherwise, if a server does not set that capability, a client might or might not send the room list. A server that has no use for the room list is then free to discard it upon receiving them, but must do so silently (i.e. without returning errors or warnings).

Some remarks.

Note that AlpineBits® does not support deltas for Inventory/Basic (push) requests. After successfully processing a request, any previous data sent via an Inventory/Basic (push) request (and only the data sent via an Inventory/Basic (push) request) must be removed.

Moreover, all Inventory/HotelInfo, FreeRooms or RatePlans data that refer to any now missing room categories must be considered outdated.

Also note that categories in inventories should refer to physical inventories. They must not be used as logical inventories. For example it is not allowed to introduce an inventory with code suite-x and one withcode suite-x-special-offer for the purpose of modeling two different products from the same inventory (RatePlans will take care of that).

It happens that hotels change room category codes (for whatever reason). It is therefore important that these changes are communicated to the server in order to avoid losing any data linked to the renamed categories. The old code of the room category can be transferred via the attribute ID of the heading GuestRoom elements.

Here is an example:

<HotelDescriptiveContent HotelCode="123" HotelName="Frangart Inn"> <FacilityInfo> <GuestRooms> <GuestRoom Code="single" MaxOccupancy="2" MinOccupancy="1" ID="EZ"> <TypeRoom StandardOccupancy="2" RoomClassificationCode="42"/> </GuestRoom> <GuestRoom Code="double" MaxOccupancy="2" MinOccupancy="1" ID="DZ"> <TypeRoom StandardOccupancy="2" RoomClassificationCode="42"/> </GuestRoom> </GuestRooms> </FacilityInfo> </HotelDescriptiveContent>

The server will first look for a category "single". If that’s found, the server will silently ignore the ID attribute and replace the data it had on record for "single".

If "single" is not found, the server will look for a category "EZ". If that’s found, the server must rename it to "single". If "EZ" is not found either, the server will just store the new category "single".

This makes sure that "EZ" is renamed to "single", without causing problems if "EZ" wasn’t known in the first place or in case the renaming has already happened.

The same procedure is to be applied for "DZ" renamed to "double".

4.4.2. Inventory/Basic (push) server response

The server will send a response indicating the outcome of the request. The response is a OTA_HotelDescriptiveContentNotifRS document. Any of the four possible AlpineBits® server response outcomes (success, advisory, warning or error) are allowed.

See Appendix A for details.

4.4.3. Inventory/Basic (pull) client request

The parameter request contains an OTA_HotelDescriptiveInfoRQ document.

Analogous to the Inventory/Basic (push) request, a client can send a pull request to query the basic data the server has stored about a hotel.

Here is such a client request:

<OTA_HotelDescriptiveInfoRQ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.opentravel.org/OTA/2003/05" Version="3.000"> <HotelDescriptiveInfos> <HotelDescriptiveInfo HotelCode="123" HotelName="Frangart Inn"/> </HotelDescriptiveInfos> </OTA_HotelDescriptiveInfoRQ>

samples/Inventory/Inventory-Pull-OTA_HotelDescriptiveInfoRQ-basic.xml

As expected, the document must contain one HotelDescriptiveInfo element with attributes HotelCode and HotelName that follow the same rules as for room availability notifications (section 4.1.1). Again, information about only one hotel per message can be queried.

Please note that the content of the XML message is identical, both for Inventory/Basic (pull) and Inventory/HotelInfo (pull), but the action is used by the server to distinguish the two requests.

4.4.4. Inventory/Basic (pull) server response

The server will send a response indicating the outcome of the request. The response is a OTA_HotelDescriptiveInfoRS document. Any of the four possible AlpineBits® server response outcomes (success, advisory, warning or error) are allowed. See Appendix A for details.

In case of a successful outcome, the Success element is followed by a HotelDescriptiveContent element with the information about the hotel.

Here is such a server response. The complete file is in the developer kit.

<OTA_HotelDescriptiveInfoRS xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.opentravel.org/OTA/2003/05" Version="3.000"> <Success/> <HotelDescriptiveContents> <HotelDescriptiveContent HotelCode="123" HotelName="Frangart Inn"> </HotelDescriptiveContents> </HotelDescriptiveContents> </OTA_HotelDescriptiveInfoRS>

samples/InventoryInventory-Pull-OTA_HotelDescriptiveInfoRS-basic.xml - outer part

4.4.5. Inventory/HotelInfo (push) client request

The Inventory/HotelInfo message is used to exchange detailed descriptive information about a property such as:

  • Property name / type / category

  • Short/long descriptions

  • Logos, seasonal pictures, gallery pictures, videos

  • City id, latitude, longitude and elevation

  • Property amenities

  • Review ranking

  • Address info and contact info: telephone, email, urls

and descriptive policies info:

  • Cancellation

  • Extra charges

  • Pets

  • City tax

  • Guarantee and accepted payment methods

  • Check-in and check-out range

All policies information is intended for descriptive purposes only and do not alter room availability and price calculation.

Every transmission must be considered as a CompleteSet and will overwrite all previous Inventory/HotelInfo data (although the server will of course not replace any Inventory/Basic (push) data it has on record).

The client sends everything it wants to share with the server.

The server decides what to save and what to ignore of the Inventory/HotelInfo message, depending on the permissions dictated by the server business logic associated with the client account.

Consider the outer part of the OTA_HotelDescriptiveContentNotifRQ document:

<OTA_HotelDescriptiveContentNotifRQ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.opentravel.org/OTA/2003/05" xsi:schemaLocation="http://www.opentravel.org/OTA/2003/05 OTA_HotelDescriptiveContentNotifRQ.xsd" Version="8.000"> <HotelDescriptiveContents> <HotelDescriptiveContent HotelCode="123" HotelName="Frangart Inn" AreaID="3181913"> <HotelInfo> <CategoryCodes> …​ </CategoryCodes> <Descriptions> …​ </Descriptions> <Position/> <Services> …​ </Services> </HotelInfo> <Policies> …​ </Policies> <AffiliationInfo> …​ </AffiliationInfo> <ContactInfos> …​ </ContactInfos> </HotelDescriptiveContent> </HotelDescriptiveContents> </OTA_HotelDescriptiveContentNotifRQ>

samples/Inventory/Inventory-Push-OTA_HotelDescriptiveContentNotifRQ-hotelInfo.xml - outer part

Structure of HotelDescriptiveContent.

HotelDescriptiveContent element must have an HotelCode attribute with a unique property ID and an HotelName attribute with the property name. AlpineBits® allows the following child-element right below HotelDescriptiveContent:

Part I: HotelInfo element

At most one HotelInfo element which contain property classifications and multimedia information. If present, HotelInfo holds at least one of these elements:

CategoryCodes at most one element, if present hold one HotelCategory element. CategoryCodes element contain information about the property type and category. HotelCategory has one CodeDetail attribute used to identify the property type and class value.

CodeDetail attribute is a string composed by two elements separated by colon: <CustomPropertyTypeTable_Value>:<ClassValue>.

  • CustomPropertyTypeTable_Value substring is a composition of 'CustomPropertyTypeTable' intended as the name of a custom property type table, the _ char used as separator and the value of the table that identify the property type. Partners are free to adopt their own custom tables.

  • ClassValue substring is intended as the property class value. Es. 4 for 4 stars or 4s for 4 stars superior properties.

Two examples of CodeDetail attribute content may be:

  • PCT2017_20:4s where PCT2017_20 is the reference to OTA (PCT) Property Class Type Codes (Version 2017) and its relative value, in this case 20 means Hotel. The string 4s after the colon character is the class value of the property.

  • ASTAT2020_11:4s where ASTAT2020_11 is the custom reference property type table name and its relative value. The string 4s after the colon character is the class value of the property. (In this example, ASTAT2020 is intended as the property type table defined by the Provincial Statistical Institute of the Autonomous Province of Bolzano for the year 2020).

At most one Descriptions element which contains descriptive information like long/short property description, photos and videos. If Descriptions element is present, hold one MultimediaDescriptions element, which contain one or more MultimediaDescription element. MultimediaDescription element must have an InfoCode attribute with a subset value of Information Type Code (INF):

  • 1 for a long description

  • 17 for a short description

  • 23 for pictures

  • 24 for videos

If InfoCode attribute is set to 1 or 17, the inner element must be one TextItems.

TextItems must have one or more TextItem with SourceID and CopyrightNotice attributes which are optionals.

CopyrightNotice attributes is optional and is used to transmit Copyright information.

TextItem element must contain one or more Description elements, each with the mandatory attributes TextFormat and Language.

The following rules hold:

  • The attribute TextFormat is set to PlainText or HTML and the attribute Language is set to a two-letter lowercase language abbreviation according to ISO 639-1. At most one Text element is allowed for each combination of Language and TextFormat.

  • The presence of a TextItem element with TextFormat set to HTML is intended as rich text alternative of a TextItem element with TextFormat set to PlainText of the same Language and makes the latter mandatory.

  • Please note that an AlpineBits® server is explicitly allowed to filter, shorten or even skip the HTML content, therefore the usage of TextItem elements with TextFormat set to HTML is not recommended but left as an option for implementers that absolutely need it.

If InfoCode attribute is set to 23, the inner element must be one ImageItems which contains one or more ImageItem elements. ImageItem elements have a mandatory Category attribute that explain the nature of the image. The value of this attribute is a subset of Picture Category Code (PIC).

  • 1 for an exterior view

  • 2 for a lobby view

  • 4 for a restaurant

  • 12 for a spa

  • 15 for a logo

  • 22 for a property amenity

Inside of ImageItem element must be present one ImageFormat element and zero or more Description elements. ImageFormat element could have four optional attributes:

  • CopyrightNotice attribute describe the copyright informations about the image.

  • SourceID attribute is an unique identifier that may be used by reciever to verify with the sender if there is the need to download the image.

  • ApplicableStart and ApplicableEnd attributes are used to suggest the seasonality of images. The format is --MM-DD, where MM is the month (01-12) and DD is the day (01-31).

Inside of ImageFormat one URL element is present with the reference to the image to download. The Description element follows the same rules of Description elements described in the long/short description case (InfoCode = 1 or 17).

If InfoCode attribute is set to 24, the inner element must be one VideoItems which contains one or more VideoItem elements. VideoItem elements have a mandatory Category attribute that explain the nature of the video. The value of this attribute is a subset of Picture Category Code (PIC).

  • 1 for exterior view

  • 2 for lobby view

  • 4 for restaurant

  • 12 for spa

  • 20 for Miscellaneous

  • 22 for property amenity

Inside of VideoItem element there must be one VideoFormat element present and zero or more Description elements. The VideoFormat element follows the same rules as the ImageFormat elements.

At most one Position element which contains geographic coordinates and elevation information of the property. If Position element is present it’s mandatory to have at least one of these couple of attributes:

  • Latitude and Longitude coordinates expressed in decimal degrees. The decimal separator is the point symbol.

  • Altitude and AltitudeUnitOfMeasureCode. Where AltitudeUnitOfMeasureCode attribute describe the unit of measure. See Unit of Measure Code (UOM) for reference. For Meters use code 3.

At most one Services element which contain a list of property amenities. If the Services element is present, must contain one or more Service elements. Each Service element has two mandatory attributes:

  • Code attribute identifies the facility code. See Hotel Amenity Codes (HAC) for reference.

  • ProximityCode attribute identifies where the service is located. See Proximity code (PRX) for reference.

Inside of Service with Code attribute set to 47, may be present at most one Features element that may contain zero or more Feature elements. Each Feature elements must have an AccessibleCode attribute which contain a Disability Feature Code (PHY) value.

There is another special case where half board needs to be seen as ¾ board when defining Service element with Code attribute set to 342 (Snack bar) in combination with MealPlanCode attribute set to 12 and Included attribute set to true.

Example of HotelInfo element:

<HotelInfo> <CategoryCodes> <HotelCategory CodeDetail="ASTAT2020_11:4s"/> </CategoryCodes> <Descriptions> <MultimediaDescriptions> <MultimediaDescription InfoCode="1"> <TextItems> <TextItem CopyrightNotice="Other copyright"> <Description Language="en" TextFormat="PlainText">A long description</Description> </TextItem> <TextItem CopyrightNotice="Other copyright"> <Description Language="de" TextFormat="PlainText">erweiterte Beschreibung</Description> </TextItem> <TextItem CopyrightNotice="Other copyright"> <Description Language="it" TextFormat="PlainText">Descrizione lunga</Description> </TextItem> </TextItems> </MultimediaDescription> <MultimediaDescription InfoCode="23"> <ImageItems> <ImageItem Category="1"> <ImageFormat CopyrightNotice="Image copyright" SourceID="56757e0211440d37910f407fb6f657fb" ApplicableStart="--09-30" ApplicableEnd="--03-30"> <URL>https://…​./HotelExteriorWinterView.jpg</URL> </ImageFormat> <Description TextFormat="PlainText" Language="en">Image description</Description> </ImageItem> </ImageItems> </MultimediaDescription> </MultimediaDescriptions> </Descriptions> <Position Altitude="200" AltitudeUnitOfMeasureCode="3" Latitude="46.1372647" Longitude="12.2011353"/> <Services> <Service Code="68" ProximityCode="2"/> <Service Code="47" ProximityCode="3"> <Features> <Feature AccessibleCode="8"/> </Features> </Service> </Services> </HotelInfo>

samples/Inventory/Inventory-Push-OTA_HotelDescriptiveContentNotifRQ-hotelInfo.xml - outer part

Part II: Policies element

At most one Policies element which contain all the property policies. If present, Policies hold one or more Policy child-elements which in turn contain exactly one of these elements:

At most one CancelPolicy element which contain descriptive information about cancellation policies. If present, CancelPolicy element must contain one CancelPenalty element. CancelPenalty element contain one PenaltyDescription element which contain one or more Text elements. Each Text element contain a cancellation description for a specific language. Text elements must have TextFormat and Language attributes.

The following rules hold:

  • The attribute TextFormat is set to PlainText or HTML and the attribute Language is set to a two-letter lowercase language abbreviation according to ISO 639-1. At most one Text element is allowed for each combination of Language and TextFormat.

  • The presence of a Text element with TextFormat set to HTML is intended as a rich text alternative of a Text element with TextFormat set to PlainText of the same Language and makes the latter mandatory.

  • Please note that an AlpineBits® server is explicitly allowed to filter, shorten or even skip the HTML content, therefore the usage of Text elements with TextFormat set to HTML is not recommended but left as an option for implementers that absolutely need it.

At most one CheckoutCharges element containing descriptive information about check-out charge policies. If present, the CheckoutCharges element must contain one CheckoutCharge element. CheckoutCharge element may have an optional Amount attribute. If the Amount attribute is present, then the CurrencyCode must be present too. The CheckoutCharge element contains one Description element which contains one or more Text elements. Every Text element contains check-out descriptive information for a specific language. Text elements follow the same rules of Text elements described in CancelPolicy case.

At most one PetsPolicies element which contain descriptive information about pet policies. If present, PetsPolicies element must contain one PetsPolicy element. PetsPolicy element may have an optional MaxPetQuantity attribute and NonRefundableFee. If NonRefundableFee attribute is present, then the CurrencyCode must be present too. The PetsPolicy element contains one Description element which contains one or more Text elements. Every Text element contains pets policies descriptive information for a specific language. The Text elements follow the same rules of Text elements described in CancelPolicy case.

At most one TaxPolicies element which contains descriptive information about tax policies. If present, the TaxPolicies element must contain one TaxPolicy element. The TaxPolicy element has the following attributes:

  • Must have a Code attribute with value 3 = City Tax. (See Fee Tax Type FTT CodeList).

  • May have an optional Amount attribute. If the Amount attribute is present,the ChargeFrequency attribute with value 1 = Daily (See CHG Charge Type Codes) and the ChargeUnit attribute with value 21 = Per Person/night (See CHG Charge Type Codes) as well as the CurrencyCode must be present too.

For example, in case of a 2€ daily city tax per person, TaxPolicy attributes are: Code = 3, Amount = 200, ChargeFrequency = 1, ChargeUnit = 21.

The TaxPolicy element contains one TaxDescription element which contains one or more Text elements. Every Text element contains tax descriptive information for a specific language. Text elements follow the same rules of Text elements described in CancelPolicy case.

At most one GuaranteePaymentPolicy element which contains descriptive information about payment methods and guarantee policies. If present, GuaranteePaymentPolicy element must contain one GuaranteePayment element. GuaranteePayment element contain at most one AcceptedPayments element which contain one or more AcceptedPayment elements.

Each AcceptedPayment element contain one of these elements:

  • BankAcct which must contain BankAcctName for the name of the bank, BankAcctNumber with sub element PlainText where insert IBAN number and finally the BankID element with sub element PlainText for the SWIFT field.

  • Cash element with a mandatory CashIndicator attribute with value true or false.

  • PaymentCard element with a mandatory CardCode attribute with an OTA Payment Card Code Type.

    • At most one AmountPercent element. If present, AmountPercent element must have a Percent attribute set.

    • At most one Deadline element which defines the timeout for confirming the booking via deposit. If Deadline element is present, OffsetDropTime, OffsetTimeUnit and OffsetUnitMultiplier attributes are mandatory.

At most one StayRequirements element which contains descriptive information about check-in and check-out policies. If present, StayRequirements element must contain one or two StayRequirement elements. StayRequirement must have three attributes:

  • StayContext must be Checkin for check-in information or Checkout for check-out info.

  • Start must be a time e.g. 15:00:00.

  • End must be a time e.g. 20:00:00.

Example of Policies element:

<Policies> <Policy> <StayRequirements> <StayRequirement StayContext="Checkin" Start="15:00:00" End="20:00:00"/> <StayRequirement StayContext="Checkout" Start="06:00:00" End="10:00:00"/> </StayRequirements> </Policy> </Policies>

samples/Inventory/Inventory-Push-OTA_HotelDescriptiveContentNotifRQ-hotelInfo.xml - outer part

Part III: The AffiliationInfo element

At most one AffiliationInfo element which contains aggregate review information. If present, AffiliationInfo holds one Awards element which contains one or more Award elements. Each Award elements must have the following attributes:

  • Rating is mandatory and provide the rating value of the aggregate review.

  • Provider is mandatory and provide the review provider.

  • OfficialAppointmentInd is optional and when it’s true indicate that the receiver has received official permission from the review provider to publish review info. If this attribute is not present it must be considered false.

Please note:

  • The review scale for Rating depends by the service provider specified by Provider attribute.

  • The transmitter must send the Rating as it is sent by the service provider.

  • The receiver must read the documentation of the service provider to know the scale value.

  • The Provider attribute value must be all uppercase. e.g. TRUSTYOU, TRIPADVISOR, TRUSTPILOT

Example of AffiliationInfo element:

<AffiliationInfo> <Awards> <Award Rating="95" Provider="TRUSTYOU" OfficialAppointmentInd="false"/> </Awards> </AffiliationInfo>

samples/Inventory/Inventory-Push-OTA_HotelDescriptiveContentNotifRQ-hotelInfo.xml - outer part

Part IV: ContactInfos element

At most one ContactInfos element which contains contact information of the property. e.g. address, email, phone numbers, urls. If present, the ContactInfos holds one ContactInfo element with the attribute Location that must have value 6 ("Hotel direct contact" according to CON codelist) which contain at least one of these child elements:

At most one Addresses element which contains one or more Address elements. Each Address element must have a different Language attribute. If present, Address must contain at least following attributes: AddressLine, CityName, PostalCode and CountryName fields.

At most one Phones element which contains one or more Phone elements. Each Phone element has a mandatory PhoneTechType attribute and a mandatory PhoneNumber attribute.

At most one Emails element which contains one or more Email elements. Each Email element has a mandatory EmailType attribute.

At most one URLs element which contain one or more URL elements. Each URL element, if the ID attribute is specified it must follow rules described below. The content of the URL element must be a valid URI * despite its name, the content of URL may be any URI, so besides http(s) urls, also other schemes might be specified. URNs are allowed as well and in this case the schema must be id.

AlpineBits® defines some values for the ID attribute that should be recognized by servers and clients:

  • WEBSITE: for the lodging structure’s official website

  • TRUSTYOU: for the lodging structure’s presence on trustyou.com

  • TRIPADVISOR: for the lodging structure’s presence on tripadvisor.com

  • TWITTER: for the lodging structure’s presence on twitter.com

  • FACEBOOK: for the lodging structure’s presence on facebook.com

  • INSTAGRAM: for the lodging structure’s presence on instagram.com

  • YOUTUBE: for the lodging structure’s presence on youtube.com

Partners are allowed to define further values but the value of the attribute must be all uppercase. Lodging’s official website url must be free of referral parameters. The server can delete any parameters not allowed.

At most one CompanyName element which contains the name of the company.

Example of ContactInfos element:

<ContactInfos> <ContactInfo Location="6"> <Addresses> <Address Language="it"> <AddressLine>Via Bolzano 63/A</AddressLine> <CityName>Bolzano</CityName> <PostalCode>39057</PostalCode> <StateProv StateCode="BZ"/> <CountryName Code="IT"/> </Address> </Addresses> <Phones> <Phone PhoneTechType="1" PhoneNumber="+3903720000000"/> </Phones> <Emails> <Email EmailType="5">info@alpinebits.org</Email> </Emails> <URLs> <URL ID="WEBSITE">https://www.alpinebits.org/</URL> <URL ID="FACEBOOK">https://www.facebook.com/alpinebits/</URL> </URLs> </ContactInfo> </ContactInfos>

samples/Inventory/Inventory-Push-OTA_HotelDescriptiveContentNotifRQ-hotelInfo.xml - outer part

4.4.6. Inventory/HotelInfo (push) server response

The server will send a response indicating the outcome of the request. The response is a OTA_HotelDescriptiveContentNotifRS document. Any of the four possible AlpineBits® server response outcomes (success, advisory, warning or error) are allowed.

See Appendix A for details.

4.4.7. Inventory/HotelInfo (pull) client request

The request parameter contains an OTA_HotelDescriptiveInfoRQ document.

Analogous to the Inventory/HotelInfo (push) request, a client can send a pull request to query the additional data the server has stored about a hotel.

Here is such a client request:

<OTA_HotelDescriptiveInfoRQ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.opentravel.org/OTA/2003/05" Version="3.000"> <HotelDescriptiveInfos> <HotelDescriptiveInfo HotelCode="123" HotelName="Frangart Inn"/> </HotelDescriptiveInfos> </OTA_HotelDescriptiveInfoRQ>

samples/Inventory/Inventory-Pull-OTA_HotelDescriptiveInfoRQ-hotelinfo.xml

As expected, the document must contain one HotelDescriptiveInfo element with attributes HotelCode and HotelName that follow the same rules as for room availability notifications (section 4.1.1). Again, information about only one hotel per message can be queried.

Please note that the content of the XML message is identical both for Inventory/Basic (pull) and Inventory/HotelInfo (pull), but the action is different and is used to distinguish the two requests.

4.4.8. Inventory/HotelInfo (pull) server response

The server will send a response indicating the outcome of the request. The response is a OTA_HotelDescriptiveInfoRS document. Any of the four possible AlpineBits® server response outcomes (success, advisory, warning or error) are allowed. See Appendix A for details.

In case of a successful outcome, the Success element is followed by a HotelDescriptiveContent element with the information about the hotel.

<OTA_HotelDescriptiveInfoRS xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.opentravel.org/OTA/2003/05" Version="3.000"> <Success/> <HotelDescriptiveContents> <HotelDescriptiveContent HotelCode="123" HotelName="Frangart Inn"> </HotelDescriptiveContents> </HotelDescriptiveContents> </OTA_HotelDescriptiveInfoRS>

samples/Inventory/Inventory-Pull-OTA_HotelDescriptiveInfoRS-hotelinfo.xml - outer part

4.4.9. Implementation tips and best practice

Please note that section 4.4 has been changed multiple times since its creation. See appendix C for compatibility information.