Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

Reseller Description

Booking.com is basically a global online platform/website where Hotels can list their properties and guests can book them to book accommodation all over the globe. The general principle of Booking.com regarding private listings is that you create an account at their side, fill it with the necessary information/configuration and start posting your listings. As soon as your listing becomes publicly available, the guests may book your property.

The client can link with Booking.com in two ways, the 1st one is ‘Physical linking’ and another one is through “Booking.com Content API”. In ‘Physical linking’ the client needs to first create the location and its properties at Booking.com extranet by making sure that all the configuration is in place on the reseller side and then do the linking of those properties in MXTS by using the Booking.com Hotel, Room & Rate codes.
In ‘Booking.com Content API’ the client has to directly link properties in MXTS without entering Booking.com Hotel, Room & Rate codes, and then the system will auto-create the properties on Booking.com side and also auto-generate the Booking.com Hotel, Room & Rate codes. However, the user will have to make sure that all the necessary/mandatory configuration that is required for a property/acco-type to get created on Booking.com is correctly configured in MXTS, so that system can fetch those details and send them to Booking.com to create the property on their side.

Tasks supported by this connection

  1. Export Availabilities and LOS (Length of stay)
    For Booking.com connection, we link the Accommodation types on the type level. Units never come in picture to link, so the reservability which we send is always picked from type level. But we have 2 options to send the reservability to Booking.com:
    (a)    Type Level Reservability
    In this option, we send the reservability from type level along with the number of nights of longest duration unit available as max stay. The drawback of this is that we send the reservability without considering partial availability. To explain with example (refer below screenshot), dates from 22-04-2022 to 25-04-2022, the type-level reservability is 7, so we send 7 reservability to Booking.com, but due to partial availability of units, reservation request for 7 units will fail while importing the reservation in Maxxton. However, that booking can be possible when the shuffling of booking on Unit 3 & 4 is done to make one unit fully available for whole duration.


    (b)    Unit Level Reservability
    In this option, for each arrival day, we first get the longest duration unit available, and then we count the number of units available for that duration, and then that count is sent to Booking.com as reservability along with unit duration as max stay.
    For example: Take example shared in below screenshot, for arrival on 20-04-2022, longest unit available is Unit 1 for 14 nights, and then for same duration Unit 2 is also available, so the total count for 20-04-2022 will be 2. Another, for arrival on 22-04-2022, longest unit available is Unit 1 for 12 nights, and then for same duration Unit 2 & 10 are also available, so the total count for 22-04-2022 will be 3. The drawback of this is that for 20-04-2022 the count will be 2, but if you see that if someone wants to book for 3 nights in Maxxton, it is possible to book 6 units, but as we will be sending 2 as availability, so only 2 can be booked. But yes, if Unit 1 & 2 get booked, then in next upload the count will be 3 for 20-04-2022 as the longest unit available will be Unit 5, 7 & 9.


    However, please note that there are other factors that can even hamper the availability at Booking.com like:
    LOCK: User can add LOCK to the Acco-type/unit which will block the availability of that property for certain period for time for all the DC’s. That is no once could book that Acco-type/unit for the date on which LOCK is added. For such dates on which Lock is added, we send ‘Zero’ availability to the reseller.

    Stop-Sale: Another thing that can impact availability of the property is “Stop-Sale”. In ‘Stop-sale’ user can define blocking of Acco-type/Unit for a specific Reseller (i.e. for a specific DC used for the reseller). This will make sure that the property is blocked for booking for a specific DC (and not for all the DC’s). More information on the Stop-sale like how it is added and what are the different types of Stop-sale is defined at Reseller Configuration

  2. Export Prices(Multiple rate types)
    We have two types of Pricing 
    a) Per day pricing:
        Per Night prices are sent directly as they are configured in ‘Rates’.  Special Prices cannot be sent to Booking.com for ‘Per day’ prices as the price cache is not used for the same
    - Close room restrictions
    - Minimum Length of stay restrictions
    - Close to arrival restrictions
    - Close to Departure restrictions
    b) Length of stay pricing
        In length of stay pricing (LOS), for every Arrival Date Maximum stay Prices are sent. Firstly, the LOS Prices get uploaded on Price Cache where the final price is calculated by considering special and other factors and then from there the final Prices are sent to Booking.com. 
    Example:
    For 1st October,2022: 3 Nights Prices are configured as 350. So for 1st Oct Prices will be sent as:
    1 Night prices: 0
    2 Night Prices: 0
    3 Night prices: 350
    LOS prices take time to get reflected at Booking.com website as the prices will first get reflected on ‘Price cache’ and then those Prices are Exported to Booking.com

  3. Import Reservations (Multiple rate types)
    a) Confirmation(Reservation status to Provisional)
    b) Modification: The task that we support in modification request of reservation are
    - Arrival/departure dates change
    - Guest name change
    - Credit card details change
    - Room change
    - Guest number(Subjects) change
    - Add-ons change
    c) Cancellation (Reservation status to Cancelled OR Declined, as per client choice)

Steps to connect with Booking.com - Physical Linking

  1. Client gets in touch with Booking.com to create hotels and rooms at their side and do necessary configuration.

  2. Simultaneously client is requested to create the Booking.com reseller in MXTS. The steps to create/activate a new connection are shown on Reseller Configuration

  3. Above step will create the Booking.com reseller in MXTS and the system will auto add mandatory settings, however, the remaining configuration related to linking of properties needs to be taken care of by the user

  4. Client is requested to create a JIRA ticket with a heading like “Connection with Booking.com” and add all important information in the same and assign the ticket to support-connection@maxxton.com so the connection team is aware of your interest in connecting with the reseller and they can assist you with all the queries you post in this ticket

  5. Create a new DC for the reseller Booking.com and make sure that all the identified resources should have that DC selected/added in their representation

  6. Create an employee if not present and make sure that the AO (Admin Organization) & all the Resorts are linked to the newly created employee

  7. Create the linking for Booking.com hotel/room with MXTS properties in Linked Accommodation Types card. Please click on Reseller Configuration to see steps on how it is done.

  8. Once the above process is done, please contact Booking.com to open/add that specific property/location for Maxxton and then inform support connection team about the same through the JIRA ticket

  9. support connection team will complete a few final steps and make price & availability uploads for the linked properties to Booking.com

  10. You can then monitor the reseller Booking.com from the /wiki/spaces/TP/pages/13699583

Steps to connect with Booking.com through ‘Content API’

  1. If no property of client has been listed on Booking.com yet then Client has to register on Booking.com first as an agency by contacting Booking.com. Once its done Booking.com will assign a Legal entity id(Unique id for the client) to the Client which will be used to configure property on Booking.com using content API.

  2. Simultaneously client is requested to create the Booking.com reseller in MXTS by following Reseller Configuration and also requested to create Jira ticket through which they can communicate with support-connection@maxxton.com

  3. In “Booking.com Content API” client does not have to manually create any location/properties at Booking.com side as same is created by MXTS. There is a list of mandatory configuration that needs to be in place at Location & Acco-type level so that system can fetch all those configuration and create the property at Booking.com side. The list of all the prerequisite mandatory configuration defined by Booking.com is listed in the following attached document

    User needs to make sure all these configuration is in place before making linking ‘Active’ for the Acco-type.

  4. Once the user is sure that all the mandatory configuration, please use following steps to do the linking of the Acco-type

  5. support connection team will complete a few final steps and make price & availability uploads for the linked properties to Booking.com

  6. You can then monitor the reseller Booking.com from the /wiki/spaces/TP/pages/13699583

Supported settings/features

There are a lot of supported settings/features that Maxxton offers to their customers which adds value to their connection with Booking.com. Few of the settings are mandatory settings related to the endpoints, etc, which get added by the system automatically when user create the Booking.com reseller in MXTS. However, a few other feature settings can give you much-needed convenience in setting up certain things your way.

Booking.com specific settings are mentioned below

  1. Special Genius Code
    We also support Genius Booker functionality of Booking.com where in 10 % discount is provided. To handle this user needs to create a special/extra (For Genius booker) in MXTS and need add the code of that special/extra as a value of this setting.

Few other common settings that are used by all the resellers can be viewed at Reseller Configuration

Booking.com Content API specific settings are mentioned below 

  1. Amenity Features
    a) Amenity Bedroom Codes
    If some amenity is specifically defined for Booking.com to represent different beds, then we need to store the code of that amenity which is linked with Booking.com amenity codes using the reseller-addon dropdown. Booking.com has its own set of codes for different bedding type

    b) Amenity Group Codes
    There are add-ons in MXTS that are to be displayed at Booking.com, these add-ons belong to certain Amenity group code in MXTS, and codes of those group needs to be mentioned in this setting so the system will fetch the amenities and send them to Booking.com

    c) Hotel Amenity Codes
    To specify which all amenities are listed at the Resort level at, the amenity group code of those add-on/amenities needs to be entered in this setting.

    d) Roomsize Amenity CodeC
    ode of amenity if any defined for adding the room size at accommodation type to create room on Booking.com in square meter.

  2. Dynamic Field Features
    a) Description Code
    Code of dynamic field which is used on accommodation type or resort depend on what has been considered for creating property and that dynamic field will have the description which will be Booking.com specific.

    b) Hotel Checkin Code
    If setting "reseller.checkin.time" is not defined then it means every resort which will be linked and used to create a property on Booking.com should have the dynamic field which will have the checkin time defined for every resort. We can also create a dynamic field if we want to set check-in time differently only for a few resorts and other resorts having same check-in time will get the value from setting "reseller.checkin.time". So keep this setting to store that dynamic field code along with the setting "reseller.checkin.time".

    c) Hotel Checkout Code
    If setting "reseller.checkout.time" is not defined then it means every resort which we are going to link and used to create property on Booking.com should have the dynamic field created which will have a unique value for every resort. We can also create a dynamic field if we want to set check-in time differently only for a few resorts and other resorts having the same checkout time will get the value from setting "reseller.checkout.time". So we can keep this setting to store that dynamic field code along with the setting "reseller.checkout.time".

    d) Hotel Roomcount Code
    Store the code of the dynamic field to add the count that how many rooms are configured under the particular property. This setting is required only if a resort has been considered to create the property on Booking.com, if accommodation type has been considered then it will be done automatically by counting the object under that accommodation type.

    e) Hotel Star Rating Code
    At the property level, it is mandatory to send ratings starting from 1 to 5. So, a dynamic field needs to be created on accommodation type or resort level to store that rating. The code of this dynamic field needs to be entered in this setting so the rating can be sent to Booking.com

    f) Property Type
    This is the code of dynamic field that will be used to store the value of Booking.com Property type code that represents what kind of rooms the properties are offering. Is it offering a hotel, condo, or apartment? Booking.com has a unique code for every type.

    g) Room Name Code
    When properties/Acco-type are to be linked through Booking.com content API, we cannot send any (MXTS) Acco-type name to them, we need to make sure that only ‘Booking.com English standard’ names are specified at the Acco-type level in a dynamic field, and then we need to mention the Code of that dynamic field in this setting. We need to also make sure that the ‘No’ Acco-types of the same Location should have the same ‘Booking.com English standard’ name. The same names can be differentiated by appending numeric values in front of them.
    For example One of the accommodation types can be called ‘Tent 1’ and then the other one can be named as ‘Tent 2’.

  3. Fees & Taxes Features
    a) Content Api Fees Codes
    To send fees supported by Booking.com link them with the products or extra using the reseller addon dropdown, by that linking we would be able to send the fees code which Booking.com support. Then add the codes of that product/extra in this setting to identify the resources to consider by the system.

    b) Content Api Tax Codes
    To send Tax supported by Booking.com either link them with the products or extra using the reseller addon dropdown (or can be picked directly from the Tax or Vat module), by that linking we would be able to send the Tax code which Booking.com support. We need to make sure that we add the code(s) of that product/extra in this setting to identify the resources to be considered.

    c) Enable Bookable Visible Check
    To identify accommodations on the basis of enable /visible bookable check of the particular representation in which our reseller DC is added and if its off then we disable the linking of that Acco-type

Important things to be noted


 

  • No labels