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. All online rates that deviate from the PMS rates must be configured in the PMS prior to being offered online. Failure to do this will result in incorrect rates being imported into reservations.

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

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

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

  5. 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 can also map a CRS RatePlanCode to a package by using any text triggers in the reservation message, so you have nearly limitless rate possibilities.

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

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


  8. Package Setup
    Package details ARE NOT IMPORTED by the interface. The package must be configured in the PMS and CRS.

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

    • RatePlanCode requirements.
      RatePlanCode is the code configured in your CRS that is sent to Execu/Tech to identify the rate plan being used.

    • Even if your booking channel (Expedia, Hotels.com, etc.) uses the same RatePlanCode for all rates, you can map these to a package in the PMS using text triggers in the reservation message. 
      For example, the booking channel may send RatePlanCode BAR but it differs from the PMS BAR rate because it contains a discount or additional fees, like a meal. This can be configured in the PMS as a package to contain the fees and discount off of the actual BAR rate. When imported, the message will be scanned for text that contains an indication that there is a discount or additional fees, which is typically the case. 

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

    • Since individual package items aren't imported, the package setup in the PMS must be correct because this is the rate that will be used. 
  9. Taxes are handled by the PMS. Any taxes sent by the CRS will be ignored. 

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

  11. Only 1 room per reservation is supported. 

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

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

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

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

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

      5.  
  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
 6051
Last Modified
 12/11/2025 11:43 AM