For a better understanding of our documents regarding Travel Automation, we have categorized and listed definitions for key words/phrases used.

Professional Figures of the Tourism Industry

The above, can be subdivided into the following groups/functions:

• Traveller, the entity that benefits of the travel services provided.
• Producer/Manager/Owner, the entity that creates/manages a single travel service, or that binds a group of travel services, so as to create a larger tourist service body (package).
• Product Aggregator (Wholesaler), the entity that creates an inventory of tourist services offered by a variable number of producers (PAg)
  
• Demand Aggregators, the entity that facilitates the access of a variety of tourism products to travellers (in this category we may recognize many well known methods that simplify research in a generic manner, such as Google, or others that compare specific fields of research like Trivago, or even IDSs(Internet Distribution Systems) that directly actualizes the reservation (DAg).

In the tourism industry, there are many entities that cover more than one of these functions in one body. For example the DMC (Destination Management Corporation) that acts as a Product and a Demand Aggregator for specific/local tourist areas.

Application Program Interface (API)

These interfaces, allow local applications to operate with other external applications, in other words M2M (Machine to Machine) Interaction, and their individual characteristics are described with the following definitions:

• Synchronized/ Asynchronous
  • Synchronized: communication method between two machines, where the sender waits for a reply from the receiver.
  • Asynchronous: communication method between two machines, where the sender does not wait for a reply from the receiver.
• Local/Remote
  • Local (internal): by this we mean, in a communication across a networks, the network closest to the one we are taking into consideration.
  • Remote (external): by this we mean, in a communication across a networks, the network opposite to the one we are taking into consideration.
• Client/Server
  • Client: the machine that generates a request of data transfer.
  • Server: the machine that waits and serves data transfer requests.
• Consumer/Producer
  • Consumer: the entity that, given a service demand, uses (buys/borrows) a product that may satisfy it’s demand.
  • Producer: the entity that, given a service demand, delivers (creates/sells/lends) a product that may satisfy the demand.

Given the definitions listed above, it is feasible to develop different types of interfaces, that differ one from another by:

• Transport Protocol (for example, webservices like HTTP, SOAP in document mode)
• Processes (client/server) specific to each side of the interface (local/remote), given that some interfaces allow only one process execution on each end (client or server), and others that require both ends to have both client and server processes.
• Data Flow (a sequence of message exchanges M2M):
  • Data flow direction
    • Distributed when data flows from the local network, meaning the CRSEngine is serving data requests (for example availabilities, prices, statistics, etc.)
    • Procured when data flows from a remote network towards the local network, where the CRSEngine collects the incoming flow of data (for example, for price list recovery from the PMS).
  • Data flow applicant (entity that sends the data request )
    • Client Pull (pull mode) client sends data request to the server, to receive desired information.
    • Server Push (push mode) server sends data to client without having received a data request (in OTA Terminology, this means all the messages with “Notify” written in the heading.
  • Data Flow timing (temporal correlations between RQ/RS messages)
    • Synchronized when the data applicant waits for a reply, therefore the information is supplied when requested.
    • Asynchronous when the data applicant DOESN’T wait for a reply.

The applications connected to each end of the interface(channel) may utilize caching, allowing the information received by the “producer” to be saved by the “consumer”, and subsequently used in case of necessity without the need to send another data request along the channel. This behaviour would require transparency in Data Flow timing between consumer and producer. But this would consequently involve dealing with problems like overbooking.

Below we have listed the main interfaces used, based on combinations of the differences explained above:

• One Way Interface where the applications on each end of the channel are always, client or server processes. In this case it is always the client to generate the data request, and does not replicate the received information.
• Two Way Interface where both applications cover client and server roles. This means that the role played, depends on the what information is exchanged (for example, in a “Distributed Data Flow” the CRSEngine is the server for price and availability information, whilst it is also the client for booking information received from an external application). In this type of interface, the client saves the information received from the server (for example, if we still consider the “Distributed Data Flow”, the external applications saves the price and availability information received by the CRSEngine), and it is always the server to generate the first message request.
• Two Way Interface (Emulated Push) is an interface configuration that achieves the same data flow the Two Way Interface offers, but it is the client that sends data requests cyclically to the server, so to inquire if there are any information updates. Theoretically, this behavior could be implemented on each side of the interface, but this wouldn’t lead to any improvements. The fact that is works on one side at a time, allows a “Two Way Interface” where each side is either client or server.

Allotment, Release Period, Freesale

With the term “Allotment” we mean the assignment of “exclusive” availabilities (generally linked to a contract) for resales actuated by a wholesaler or by a “Tour Operator” to which is given a “Release Period” (see also wikipedia – Allotment) that allows for unsold rooms to return to the owner a couple of days prior to carrier departure/hotel “check-in” if such agreement exists between the two parties.

If case the “Release Period” is set to 0 (“zero”), an “empty for full” type contract is implied, meaning that the tour operator buys some rooms in hotel for the entire season and he will provide to sale them, wherelse if the “Release Period” is set to 1 (“one”), this means he is free to allocate the unsold ones on the check-in date, and so forth.

With the term “Freesale” we mean the allocation of availabilities “non exclusive”, so a certain number of rooms is notified to the wholesalers, and as they carry on with the bookings the number of available rooms gets gradually smaller for every subject of the “Freesale”.

Guest Profile

Participants are classified based on their age into the following categories:

• Adult
• Child
• Infant

Every single residential unit (Hotel, B&B, etc.) may decide whether to differentiate Adults and Children, and the age threshold. On the other hand, the Infant age is prefixed (from 0 yrs to 2 yrs of age).

Adults and Children may use the same type of bed, whilst Infants require a Crib. For this reason Infant management and pricing is managed separately from other participants, requiring a fixed daily deposit for the Crib.

Every room is characterized by the number of guests that it can host by means of:

• “MaxAC” (Adults+Children) determines the maximum number of beds (cribs not taken into consideration)
• “MinAC” (Adults+Children) is necessary when the base price of a room depends on the number of guests (Adults/Children).
• “StdAC” (Adults+Children) is necessary when the base price depends on the room, regardless of the number of guests (valid when the number of guests is less or equal to the StdAC). When the number of guests is larger than the StdAC, eventual extra costs may come into play.
• “MaxCrib” (maximum number of infants)

Though, when the “Occupancy Business Rule” is in play, even if the “Daily Base Price” (DBP) implies “per room” a DBP is determined “per guest”(StdAC), and the participants (Adults+Children) are subdivided into their groups (Normal & Extra) depending on where the StdAC falls, after Adults and Children are ordered as displayed below

0----------<Adults> -------- <Children> -----------"MaxAC"

so that we may speak of Adults or Children that require an “ExtraBed”, instead of a “NormalBed”.

The “Occupancy Business Rule” allows us to define how to vary the DBP in function of only Adults and Children, in case of the DBP intended “per participant” and also as a function of “Extra Adults” and “Extra Children”, in case of DBP intended “per room” and a larger number participants than StdAC standards.

The estimation regulations stated in the “Occupancy Business Rule” may:

1. determine a price by summing or subtracting a value from the DBP.
2. determine a price summing or subtracting a certain percentage of the DBP from itself.
3. set a value (irrespective of the “Daily Base Price”)

The “Daily Price of Crib” is defined in the “Crib” chapter of the “Occupancy Business Rule” and allows for a single case “c” as an independent value aside from the DBP.

Extra (ancillaries)

The extras may be subdivided into the following categories:

• Offline goods and services that do not require an “online” availability check, therefore eliminates the need for the interoperability of the CRSEngine system with an external application that manages the availability of these goods.
• Online goods and services that require an “online” check to be sold simultaneous to the room.

The CRSEngine allows for direct management of “Offline” extras, consenting guests to define the following characteristics:

• the traveller during the booking may
  • write a review on his/her experience
• the manager during the configuration of the Extras, may specify
  • restrictions on the daily supply (check-in date, check-out date, # days of stay)
  • if part of the package
  • the exclusion/inclusion of the room price
    • and if included, whether the price is displayed or not
  • if mandatory/optional
  • if the payment is to be made “on booking”, or “on arrival” at the hotel
  • the type of recurrence (per person, per night, per stay, per use, per person/night)
  • how to differentiate the Adult and Child prices
  • the time frame in which resources are providable and which days of the weeks.

Of course, not all the combinations are reasonable, like for example:

• if an extra is included, it cannot be optional or paid in hotel.
• if an is part of the package, then it is automatically included, with added difference that:
  The price of the room (for who manages the User Interface) is not shown as a separate invoice item, but as a whole, determinable only at the end of deciding the extras to be added to the package.

In the case of “Online” Extras, they have all the characteristics listed above, to which we must add an “Online” check of the Extra’s availability. Therefore the CRSEngine must cooperate with the “Extras” management system (For example, with the Extras involved in flight, Travel XML Proxy is used).