1. 'auto-pilot' meaning the 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 API 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 APIs 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 the USA).  You can get the tax policies for a particular Site from the OTA_HotelDescriptiveContentNotifRQ/RS messages Occupancy Tax section.
  
  
• 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 change.
  
  
• 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.  Always send the StayOverDate unless you want the days to all be opened.

• Cancellation Number: (you can define your own number or let the system auto-generate one)
• Cancellation Fee: (you can set a fee, thought this has no bearing on any PMS product.
• Message: You can save a message about the cabncellation, such as: "guest cancelled by phone call".
• Phone: You can place a phoine number to call someone back or refer to the person recording teh cancellation.
• Cancelled By: Insert a valid PMS user name to record who did the cancellation.  If you have no idea whu to place here, use 'xml' so it's clear.

If a developer wished to MODIFY an existing booking, then they have two choices:

1. Either send the Rate and Availaility query to find out rate and avail for the new desired dates, and then cancel the existing booking make a New Booking.  This assures they get the rates desired for the modification, but doesn't guarantee accurate availability, based on the cancellation they are about to perform.  It could be a false positive.  
   
   For example, if there was no availabiity for a date range because the existing booking is still blocking the availability, the developer could receive a false positive that the modification wasn't possible due to no availability.
   
   
2. Or the developer could  and then send the Rate and Availaility query to find out rate and avail for the new desired dates, and make a New Booking.  This assures they get the accurate availability, based on the cancellation, but they won't know the actual rates for the modification until after they cancelled the booking. 
   
   Thus they could have cancelled a booking they wanted to save because it was priced better.  There is no perfect solution to this dilema, so choose your preferred option, but there is no solution for a direct 'modification' message.

However, since most developers would use Inventory Items already set in the PMS (with proper description, cost, etc) this should not be a limitation.  See this article for details on Items that a property has decided are 'Live' and which are set 'Not Live' to sell online.

However, where a developer would prefer to build Packages and Items 'on the fly', we recommend using MyGuest.  With this product, you can place as many 'Guest requests' as needed, and with whatever notes describing the Item(s) desired.  Because each MyGuest Request is saved with the Booking ID, these Requests are linked from the Booking, and in front of staff on the Front Desk, these 'Requests' make ideal places for getting creative with extended info about Item(s) placed onto a Folio.

If you look at the MyGuest Pubic API, it shows a Notes:  element that would be used.  Anything you place here is free form text, thus flexible and availale for staff for tracking and reporting purposes.  In addition, you can use the Request ID to 'consume via the API' tho constantly update the Request with additional details as the Item is sold, altered, deleted, and ultimately delivered to a Guest.  

{
  "hotel_id": 2,
  "room": "32",
  "booking_id": "1332025-4X",
  "guest": {
    "email": "joeb@banks.com",
    "name": "Joe Banks",
    "phone": "7075551414"
  },
  "guest_notify": false,
  "form_category": "Treatment",
  "form_name": "Spa Menu",
  "form_fields": {
    "Notes": "We'd like hot towels and a room to meditate in, which will need to be large as we bring our dogs and cats on meditation retreats with us. ",
    "swedish1": 2,
    "pregnancy2": 1
  }
}

1) Connect to the ‘PMS/CRS’ and retrieve hotel rates and availability, with specifics for finding which rates are Packages, what Items they include, and Quantity and Price.  To learn about rates and availabiity for an XML developer, we recommend reviewing the KnowledgeBase articles here.

OTA_ HotelAvailRQ/RS-

As summarized at: https://docs.bookingcenter.com/display/MYPMS/APIs+and+Web+Services+Available+From+BookingCenter this message provides an array with Type and Rate availability, and you could parse the array to get the ‘lowest’ available rate, or whatever hierarchy desired to offer a Guest. The credentials (User ID and password or API key) enable this API call to return what is needed when formatting this message for showing by date or Type.  

2) Save the Booking, what we call the NewBooking message

OTA_HotelRes

This is the message that sends a 'payload' of all data needed to save a booking.  As we explain at: https://support.bookingcenter.com/index.php?/Knowledgebase/Article/View/667 when querying and selling Packages, understanding the way your API calls for Inventory Items (which constitute the ‘parts’ of a package), and then saving them with a booking, is critical. 

If the BookingCenter customer is using a Payment Gateway, then you can request the server 'process' the deposit amount (payment) as part of saving the Booking.  The deposit policy for the specific Rate & Availability will be sent with the OTA_ HotelAvail so doesn't have to be cal;culated by teh developer.  If a deposit/payment is requested by the developer, if we get an authorization, then the server sends back the Booking ID (reference number) and you can be assured the 'payment' was saved with the Booking. The payment will be qued for the next merchnat account 'Batch' and assocaited to the booking.  See: Point of Sale/MyCard (credit cards, hardware, etc.) part of the XML KnowledgeBase to understand the settings for requesting a payment or saving an 'offline' payment a developer may make, and to understand errors with failed deposits/payments.

The WSDL allows one to use both Time and Dates to query for bookings that match common requests. Below helps identify what the results provide:

ResStatus="Reserved" = confirmed 
ResStatus="Requested" = unconfirmed 
ResStatus="Cancelled" = Cancelled 
ResStatus="Active" = checked in 
ResStatus="Complete" = Complete 

The date type has an option "All" and "Cancelled", as well.

Date Type "All" "LastUpdateDate" "MadeOnDate" "ArriveDate" "DepartDate" "CancelledDate" are self-explanatory.


The API endpoint has the message specifics, but if using our client area in the Test system, ws-client-test, use the 'Modify Booking' message to enter in the Booking ID and click the Modify button (Site ID: EXAMPLE Site ID; Booking: 150509).

This will take you to a new 'Modify booking' section/URL to view a client interface to the message.

At the bottom of the page, you will see the Inventory Items derived for the Site Details messages, where the web services delivers a list of Items that are set to sell 'online' and that are flagged as 'add on at checkin' and/or addon at checkout' to differentiate Items that are to be sold during the guest stay process.  

The developer should identify one or more of the appropriate Item(s) and specifiy a quantity (such as 1 Breakfast and 2 Fosters Bitter beers) and submitting the message, the quantity (at the price set for the Item) to be added to the primary Folio of the Booking.

If one were log into MyPMS and load the booking, they should see the item(s) post to the folio of the specific booking.