Execu/Tech Systems, Inc.
Knowledgebase
Search:
850-747-0581 Email Website
Contents
 
:
IndexBookmarkPrint This Article

Home > Interfaces > OTA / HTNG > OTA / HTNG Functions and Limitations

These are the major limitations  and unique behaviors of the interface and should be considered before purchasing. These lists change as the interface is modified and tweaked with each CRS vendor. Typically, a feature implemented for one vendor will apply to all vendors with just a little modification.

Limitations

If you have a one way interface, you are responsible for maintaining rates and availability through the CRS (Travelclick, Synxis, Windsurfer, etc.) 

Because a one way interface DOES NOT send rate or availability information to the CRS, rates and availability must be maintained by you, typically using a webpage that gives you access to a management console. You should carefully consider how many rooms you want to offer to the CRS so that you don't experience overbookings. This means you will likely need to adjust this number for expected busy seasons. Also, if your rates change you must remember to change them in the CRS. 

  1. If a reservation is open in the PMS, the CRS will not be able to modify or cancel it.

  2. We support Reservation Delivery from the CRS to the PMS, but not reservation Sync from the PMS to the CRS. This means that we import reservations from the CRS but we do not upload reservations or changes made in the PMS to the CRS.

  3. Modifications and cancellations performed on a reservation imported from the CRS must be performed in the CRS. If they are performed in the PMS, the changes will not be updated to the CRS. This update only occurs from the CRS to the PMS.

  4. Due to our internal PMS rate structure, we only support 5 Rate Plan Codes (numbered 1 - 5). If you build your CRS Rate Plans off of these 5 codes, you should have plenty of variety with a 2 way interface. We don't use rate codes for vendor, travel agent, corporate, etc. tracking. Use source of Business, Market Segments, Travel Agency or Corporate setup for this.

  5. If you wish to use these 5 Rate Plan Codes (Rate Codes in the PMS) then your PMS Season Record MUST NOT use rates 1 - 5. It must use the alpha (A - Z) seasons.

  6. When we receive a Rate Plan Code that doesn't match the 5 pre defined codes in the PMS this is how it's handled:
    • We compare it against the Packages in the PMS. If it exists, we post the package details, as they are configured in the PMS, to the reservation.
    • If there is no match, we post rate code 2 in the PMS, but we keep the rates sent by the CRS
    • In all cases, regardless of the rate or rate code, we will post the dollar amount provided by the CRS. This ensures that the guest will always be charged the rate they agreed to when booking even if there is a miss-match in the PMS.
    • In this image you can see the PMS rate remapping for the internal rates 1 - 5. In a 2 way interface we can send each of these 5 rates. The CRS should work with you to to ensure that these rates are mapped. At least one rate must be mapped for the rates to be uploaded.


  7. Package Setup
    Package details ARE NOT IMPORTED by the interface.

    If you choose to use packages these are important notes to consider.

    • The package will need to be configured in the PMS first. 

    • Since individual package items can't be imported, the package setup in the PMS must be correct because this is the rate that will be used. 

    • In the case of packages, the PMS package rate will be used, not the rate provided by the CRS. This is because the CRS rate is a composite of all individual package items.

    • Configure the packages in the CRS to work exactly like they do in the PMS. This is the only way to ensure that the package seen by the guest online is posted correctly by the PMS. The package code must match the RatePlanCode in the CRS because this is the code submitted to the PMS by the interface.

    • Calculated rates are not currently supported in the PMS package setup for CRS interfaces. The rate must be specified in the package setup to work with the interface.
  8. Taxes are handled by the PMS. Any taxes sent by the CRS will be ignored. 

  9. Tax Inclusive (using AmountAfterTax) rate plans are not supported.

  10. Only 1 room per reservation is supported. 

  11. PMS Rate, Market Segment and Source of Business codes are limited to 4 characters.

  12. PMS Group and Package codes are limited to 10 characters.

  13. Supported 1 way messages are:
    OTA_CancelRS
    OTA_HotelGetMsgRQ
    OTA_HotelResModifyNotifRQ
    OTA_HotelResNotifRQ

  14. Supported additional 2 way messages are:
    OTA_HotelAvailNotifRQ
    OTA_HotelInvCountNotifRQ
    OTA_HotelRatePlanNotifRQ

  15. The only restriction we support at this time is Minimum Length of Stay.

Functions

  1. The only restriction supported is Minimum Length of Stay

  2. Rates are only sent for adults (AgeQualifyingCode="10"). They contain:
    First Person Rate
    Second Person Rate
    Additional Person Rate

  3. When we receive a Rate Plan Code that doesn't match the 5 pre defined codes in the PMS this is how it's handled:
    1. We compare it against the Packages in the PMS. If it exists, we post the package details, as they are configured in the PMS, to the reservation.
    2. If there is no match, we post rate code 2 in the PMS, but we keep the rates sent by the CRS.
    3. In all cases, regardless of the rate or rate code, we will post the dollar amount provided by the CRS. This ensures that the guest will always be charged the rate they agreed to when booking even if there is a miss-match in the PMS.
    4. In this image you can see the PMS rate remapping for the internal rates 1 - 5. In a 2 way interface we can send each of these 5 rates. The CRS should work with you to to ensure that these rates are mapped. At least one rate must be mapped for the rates to be uploaded.

  4. When Travel Agent details are received in the reservation import, we will attempt to match the IATA number to an existing travel agent. If no match is found then we will create a new travel agent record with the details provided in the reservation record. 

  5. When using Synxis CRS, Packages on the Synxis side will be treated as Amenties by us and must be tied to an Auto Post code. 
      In order to maintain PCI compliance, we tokenize or mask all credit card information. If you use one of our PCI compliant credit card processing interfaces you have the option of tokenizing credit cards. No card numbers will ever be stored so if you don't use one of our credit card processing interfaces you will need to obtain guest payment information from the CRS.





Article ID
 ota___htng_limitations
Views
 4859
Last Modified
 11/30/2021 9:22 AM