# Pre-book **Summary and examples** The Pre-Book transaction is used by partners to recheck the price and availability for a stay prior to making a booking. \ The Pre-book transaction will: 1. Check the requested room/rate plan is available and return a status indicator. 2. Check whether the price has changed and return a PriceChangeIndicator (i.e. no change, increased, decreased), together with a warning if it has changed. 3. If the Room is no longer available, then an error is returned. 4. Convert between Rate plan and Room Type codes used by UltraDirect and native CRS codes that are often used in Push ARI (for those chains that support this) 5. Convert between demand partner's property code and UltraDirect property code (for demand partners that use this fucntioanlity) The request should contain: • The same parameters contained in the availability request (Single Property Availability or Enhanced Shopping) and RateRules request such as arrival/departure dates, number of guests, number of rooms etc. • The specific Rate Plan code and Room Type code for the desired rate returned in the availability response. Note that the rate plan code in the availability response may be different from the one if the request (if sent), and so it is the code in the availability response that must be used in the rate rules request message • Public rates will be returned if no RateSearch element data is included in the request. • Any rate qualifiers returned in the availability response for the desired rate, such as a corporate ID, should also be included. Mandatory values in the Pre-Book Request – \ • Source/SGA • AgentInfo • Property Code + Context (new) • RatePlanCode • RoomTypeCode • GuestCount: Adult/Child/Age • NumberOfRooms • DateRange Page 91 of 127 • RateSearch: RatePlanCode & RatePlanType (Conditional, depending on whether the SGA is configured for new neg rate process or not). We will restrict this to one RateSearch element. Optional • RoomCodeContext (new) – values TBD • RateCodeContext (new) – values TBD • CorpInfo Code • TotalRate • TotalRateInclusive \ Some partners have a limitation of not knowing the Total Rate and Total Rate Inclusive during the Pre-book transaction, so the above-mentioned attributes are marked option and Pre-Book response will behave in the following way – • Total Rate and Total Rate Inclusive is passed in the Request – System will validate the Availability and the price returned from the CRS and will return PriceChangeIndicator in the response. • Total Rate and Total Rate Inclusive is not passed in the Request – System will validate the Availability but will skip the validation of Price returned from the CRS and will not return PriceChangeIndicator in the Response. **Request example:** ``` ``` Depending on if The Response will include – PriceChangeIndicator in the RoomType element with the following Valid values – \ o no change \ o increased \ o decreased \ Warning message if the rate has changed. Response example: ``` ``` Request Examples – 1. SGA/Chain uses new neg rate process so no need to send neg rates: Request ``` < ``` 2. Normal scenario included negotiated rates: ``` ``` 3. P2P or S2P client example, using native CRS codes for rate plan, room type and PID: ``` Page 95 of 127 ``` Request Examples – 1. No availability: ``` ``` 2. Price Change: ``` Page 96 of 127 ``` 3. Normal (available and no price change): ``` ```