.. meta:: :description: Wired API, handling rooms :keywords: Wired, xml, api, channel manager, booking engine, rooms, room Handling Rooms ************** Introduction ------------- This chapter is the right piece of documentation if you want to add, modify and remove rooms. There are two kind of rooms: * Standard room * Virtual rooms Virtual rooms are always associated to a Standard Room and inherit its availability. At the same time, they have indipendent restrictions and prices, occupancies and meal options (boards settings). Each room has a set of default values, which are globally applied (applied for each day of each year) until you override them depending on the dates. Rooms can be **WooDoo Only**: when a room is WooDoo Only, this room is not sold on the WooDoo Online Reception (booking engine). Finally, WuBook supports the **Anchorage** feature: the prices of one room can be inherited by another room and altered by a static or percentage variation. Fetching existing rooms ----------------------- To retrieve the rooms of one property, you can use one of the following functions: .. function:: fetch_rooms(token, lcode, ancillary= 0) **fetch_rooms** returns a list of rooms .. function:: fetch_single_room(token, lcode, rid, ancillary= 0) **fetch_single_room** returns just the requested room. Rooms returned by these functions are represented by a Key->Value structure. Each structure having the following keys: * **id**: the id of the room (what else?) * **name**: the main name of the room. * **shortname**: the room shortname: unique (per property) * **occupancy**: the room occupancy * **men**: adults (note: adults + children = occupancy) * **children**: children (note: adults + children = occupancy) * **subroom**: if the room is virtual, this field is the id of the Parent Room (0 otherwise) * **anchorate**: price anchorage. The field contains the Parent Room (0 otherwise) * **price**: the default price for this room * **availability**: the default availability * **board**: the default board (WooDoo Online Reception only) * **boards**: other optional boards (WooDoo Online Reception only) * **woodoo**: is that room woodoo only? (not sellable on the booking engine and Fount (TripAdvisor, Trivago and so on)) * **dec_avail**: availability to be decreased in Parent Room * **min_price**: the minimun price for this room (If passed, must be greater to or equal to 5. Otherwise defalt values is 0) * **max_price**: the maximun price for this room (If passed, must be greater to or equal to 5. Otherwise defalt values is 0) * **rtype**: rtype ID (room, apartment and so on) * **rtype_name**: rtype name (rtype human description) .. warning:: if a room is virtual, sending availability is useless. The availability is inherited from its Parent Room .. warning:: if a room has a price anchorage, updating prices is useless. Prices are inherited from its Parent Room .. note:: a room can at the same time be virtual and having a price anchorage. The Parent Room for its availability can be different from the Parent Room of its price. .. note:: with ancillary = 1 will be returned also description and name of the room for each language (just if previously set) Here is an example of a fetch rooms request followed by the answer. .. hidden-code-block:: xml :starthidden: True fetch_rooms 1238200946.2025 1213394817 <---------------response---------------> 0 name Romeo men 2 subroom 0 occupancy 2 id 1 shortname Rom children 0 name Romeo single usage men 2 subroom 1 occupancy 1 id 2 shortname rom1 children 0 Adding a new room ----------------- To add a room, you have two functions (depending on the nature of the room, standard or virtual): .. function:: new_room(token, lcode, woodoo, name, beds, defprice, avail, shortname, defboard [, names, descriptions, boards, rtype, min_price, max_price]) .. function:: new_virtual_room(token, lcode, rid, woodoo, name, beds, children, defprice, shortname, defboard[, names, descriptions, boards, dec_avail, min_price, max_price]) Both return the assigned ID of the new room. Let's discuss the not trivial parameters: * **woodoo:** if 1, this room will be WooDoo only * **shortame:** maximum 4 chars. For the same property, use different shortnames for different rooms * **defboard:** it can be *bb* (breakfast), *fb* (full board), *hb* (half board), *nb* (no board) and *ai* (all inclusive) * **names:** used to provide a name of the room for each language (booking engine). KV struct, like: {'en': 'Double', 'it': 'Doppia'} * **descriptions**: as *names* * **rtype:** type of the product (1: Room; 2: Apartment; 3: Bed; 4: Unit; 5: Bungalow; 6: Tent; 7: Villa; 8: Chalet; 9: RV park) * **boards:** optional and only useful for the Online Reception (booking engine). Details follow. * **beds:** the occupancy of the rooms (children included) * **children:** the number of allowed children (if 1 and beds= 2, the occupancy is 1 Adult + 1 Child) * **dec_avail**: availability to be decreased in Parent Room * **min_price**: the minimun price for this room (If passed, must be greater to or equal to 5. Otherwise defalt values is 0) * **max_price**: the maximun price for this room (If passed, must be greater to or equal to 5. Otherwise defalt values is 0) Notice that in order to add a virtual room the **rid** argument is necessary: this is the identifier of the Parent Room. Before understanding the **boards** parameter as Data Type, let's see how it works. First of all, this information is only used on the Booking engine. So, for example, if the room is *WooDoo Only*, this information is completely useless. The WooDoo Online Reception (booking engine) can propose different prices for the same room depending on the selected meal option (if multiple options are provided, otherwise, it's always sold with the standard board). Providing multiple meal options is possible and can be done by defining a price variation. For example, a double, sold with a breakfast option by default, can be sold with an increase of 10 EUR when the Half Board option is selected. So, a meal option is a variation of the room price. And the variation can be static (+/- N EUR) or defined in percentage (+/- N%). The parameter defining the variation is called **dtype** and can assume the following values: ===== =================== Value Meaning ===== =================== 2 Static increase 1 Percentage increase -1 Percentage decrease -2 Static decrease ===== =================== This being said, let's analyze the **boards** parameter. It is a complex KV struct, representing this logic. Let's check an example:: boards= {'hb': {'dtype': 1, 'value': 10}, 'fb': {'dtype': 2, 'value': 20}} Suppose that, for the day X, the room price (related to the default meal option) is 100. With the previous example, the room sold with an Half Board option would cost 110 (percentage variation, *hb*). The same room, sold in Full Board option would cost instead 120 (static increase for *fb*). Let's also report an xml representation of the previous KV struct:: hb dtype 1 value 10 fb dtype 2 value 20 Finally, let's check a full **new_room()** example: click on the following link to review it! .. hidden-code-block:: xml :starthidden: True new_room 9516736649.5172 1213394817 1 NewRoom 10 1000 1000 NeC nb ru russian name ru russian description bb dtype 1 value 10 3 0 120 And here is an example of the answer. .. hidden-code-block:: xml :starthidden: True 0 1000 Modifying a room ---------------- As for adding new rooms, we have two available procedures to modify existing rooms: .. function:: mod_room(token, lcode, rid, name, beds, defprice, avail, shortname, defboard[, names, descriptions, boards, min_price, max_price, rtype, woodoo_only]) Below you'll find an example of a request and a response. .. hidden-code-block:: xml :starthidden: True mod_room 9990289972.1552 1213394817 24438 Double room 2 42.0 5 DB nb it Camera doppia en Description of the room hb dtype 1 value 10 fb dtype 2 value 20 10.0 1000.0 1 0 0 24438 .. function:: mod_virtual_room(token, lcode, rid, name, beds, children, defprice, short, defboard[, names, descriptions, boards, dec_avail, min_price, max_price, woodoo_only]) To understand the meaning of the arguments, check the following example of a call followed by a response. .. hidden-code-block:: xml :starthidden: True mod_virtual_room 1374667085.8467 1213394817 34668 Family 3 1 80 MTRD hb 0 0 120 <-----------------answer-----------> 0 34668 Removing a room --------------- Deleting a room is very easy: .. function:: del_room(token, lcode, rid) Here is an example of del_room() call followed by its answer. .. hidden-code-block:: xml :starthidden: True del_room 9940098773.3035 1213394817 99318 <-----------------response---------> 0 0 Other functions --------------- The following functions can be useful: .. function:: room_images(token. lcode, rid) **room_images()** returns a list of images for the room identified by *rid*. Each image is a struct containing an url (*image_link*) and a flag *main_image* (1 or 0). When *main_image* is 1, that's the default image of the room (and other images should be considered additional). The following is an example of the room_images() call followed by the response. .. hidden-code-block:: xml :starthidden: True room_images 1322234714.0089 1213394817 3069 <-----------------------response-------------> 0 id_room 1 image_link https://wubook.net/wbk/imgs/room/3609.png main_image 0 Update Functions ---------------- .. function:: push_update_activation(token, lcode, url) Wired can send a notification if rooms values are changed, for instance when a user updates the availability of his rooms on WooDoo Extranet. The **push_update_activation()** method is used to setup an URL to which the notifications will be sent. A notification is very simple, it's just a POST with three parameters: lcode, dfrom, dto. By default, the URL configured for Update Notifications is empty and it means that no notification will be sent. By setting up a right URL, notifications **will** be sent. To **disable** the Update Notification System, just use url= "" (empty string). This function is very important if you use Wired to develop your own Booking Engine. It allows to set a reliable cache system on your side. The logic behind it is: you periodically **download** rooms values by using Wired functions (like fetch_rooms_values() and plans functions) and then, when you receive a PushUpdate notification, you know that your data must be refreshed for a specified range of dates. Here is an example of a request and an answer: .. hidden-code-block:: xml :starthidden: True push_update_activation 9222557560.2196 1213394817 http://wikipedia.com 0 Ok .. function:: push_update_url(token, lcode) While the previous function allows to set the url, this one simply **returns the url** used of that lcode. Here is an example of a request and an answer: .. hidden-code-block:: xml :starthidden: True push_update_url 9222557560.2196 1213394817 0 http://wikipedia.com