BookingCenter works with revenue and yield management companies to allow external systems to publish rates inside of BookingCenter.  When theese external systems decide to alter rates, based on their business intelligence, they post new rates values per the OTA message OTA_HotelRatePlanNotif RQ/RS - (Update Rates in the BookingCenter CRS). These updates are immediate and change Property Management System, BookingEngine, and all GDS/Channels using the rates values updated. Rate updates occur usually as:

1. 'auto-pilot' meanong teh external system would make changes no more than every 6 hour to 24 hours (2-3 times day).
2. manually - meaning the customer can change rates when needed.  These changes can therefore occur quite often, but BookingCenter will enforce a reasonable minimum threshold to avoid dragging down our interfaces.  

When implementing the messages for Rate Updates, it is expected that consideration will be made to deploy the least number of XML messages to accomplish the business goals.  For example, a single message for each rate ID to be altered should be incremental and affect only changes to the rate needed for the specified time period needing changing.  Thus, only 'delta differences' - and not a blanket message to alter a rate for a year, for example - should be messaged.  Implementing smart coding from the developer will assure that BookingCenter can support the developer with use of the XML service ongoing.

It is also expected that any developer wishing to use an interface will first read the basic understanding of the XML Web Services from BookingCenter (posted here); then sign and return the NDA provided at that URL in order to gain credentials to a test system; and understand that BookingCenter will enforce a reasonable message threshold from any partner who abuses the update process to avoid dragging down our interfaces with other system (OTAs, GDS, PMS systems, etc).  If BookingCenter notices that a partner's implementation of the web service is causing harm, BookingCenter reseves the right to stop access at any time from a partner to avoid disrupting BookingCenter's business or that of our customers.  We will, however, attempt to work with any partner who is shut off from the web service to make sure proper feedback is provided to make the interface work efficiently for all parties. 

Implementation Help

• Make sure that each XML mesages carries with it proper authentication (what we call the Site ID and password) when posting rate mesages.  BookingCenter can not provide this ID to a developer, it must be provided by the property customer (the 'Site'). This is not the User account that a front desk or manager uses to login to MyPMS, for example, but the authentication for the Site.  Note that if the authentication were to change, then the Site would need to inform the developer, else authentication failures would entail.
  
  
• The developer would want to test to see their rates being stored properly. To do this, the customer would have to allow the developer to use a login and view the 'Setup | Rates | Rate Grid' area of MyPMS or the Members Area for access to view rate updates in 'real time'.  The developer can use the Site ID and password to access https://members.bookingcenter.com or https://members-test.bookingcenter.com (depending on whether checking test or production) to view rates and check for authentication status.  If the ID and password used can't auth https://members.bookingcenter.com, then it can't auth the messages.
  
  
• Tax Calculation Error (<Error Type="6" ShortText="Error: Tax Calculation Error"  Code="0" />)
  This a common issue when a property has a TAX VALUE and the developer didn't notice the 2 needed values - taxed and non-taxed.  Let's say, for example, that a sample property has a tax rate of 12.5%.  There are 2 values that need to be sent: AmountBeforeTax and AmountAfterTax.  In the example here, it would need to be reflecting this in your message as AmountBeforeTax="200.00" AmountAfterTax="225.00".  
  
  Note that this same logic is needed for tax-inclusive rates (such as VAT or GST rates) as well as tax-exclusive rates (such as seen in teh USA).  You can get the tax policies for a particular Site from the OTA_HotelDescriptiveContentNotifRQ/RS messages Occupancy Tax section, or by asking the property.
  
  
• Reduce Messages. Each XML message can contain multiple rates by repeating the <Rate PLan> section of the message with as many Rates as are needed to chnage.
  
  
• Use Dates Wisely.  Send the longest date range possible in the XML message in order to reduce the number of messages. If the rate does not need to change for a date(s) then it's best not to send a message at all.
  
  
• Closed to Arrivals.  BookingCenter supports Closed to Arrival for a single day or a comma separated string in the StayOverDate.  Thus, StayOverDate="Thu" will work to make the Thurs a 'closed date' as well as StayOverDate="Thu,Sat" will work.
  
  
• Opening and closing Rate Plans. If there is no StayOverDate specified in the message, then the days are opened up by default.  This is how a prior closed date for a rate could be 'opened up' again. But beware of a message that sets the CTA indicator, but then another series of messages with no StayOverDate - this will reset the CTA indicator.  Aalways send the StayOverDate unless you want the days to all be opened.