Execu/Tech Systems, Inc.
Knowledgebase
Search:
850-747-0581 Email Website
Contents
 
:
IndexBookmarkPrint This Article
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. 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.
      For Execu/Tech PMS to identify that this is a package, and not a standard rate
      • You must prepend "PKG-" to the RatePlanCode in the CRS setup.
        For example, the Execu/Tech PMS Package Code "WEDDING" will have a CRS RatePlanCode of "PKG-WEDDING".​
      • This is required to allow the PMS to properly calculate the room rate and individual package items. Often the CRS will send a total combined rate as the room rate and the PMS must subtract the package items, <Service Inclusive="true">, from the room rate for proper calculation of the package.

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

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

      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.