1. Mailing Lists
  2. Contributors
  3. Re: booking of resources

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: booking of resources

Re: booking of resources

Avatar

Re: booking of resources

by
elego Software Solutions GmbH, Olaf Wagner
- 18/01/2023 09:47:17

On 17 Jan 2023, at 20:56, hugues de keyzer wrote:

hello, dear contributors!

one of our clients needs a solution for managing bookings of rooms in a building (for events like conferences, parties, etc.). they have several rooms that can be booked, and each booking can have options involving objects or people, like a video projector, waiters, tables, chairs, plates and cutlery,…

some objects are identified individually (like video projectors), while others can be considered as always available in infinite quantity (like tables, chairs, plates and cutlery) and only the amount matters.

bookings would be created manually (on the back-end side) by our client after communicating with their customers (by e-mail, telephone,…). for each booking, a sale order should be made, and the price should depend on the room, the duration and the chosen options. the bookings (and thus availability) of each room, person, and individually identified object (like a video projector) should be visible in a calendar, and booking conflicts must be avoided.

do you have any advice on how to implement this without reinventing the wheel?

we looked into the resource_booking module, which seems mostly great overall, but quickly faced a constraint: a resource.booking can only book one resource.booking.combination. a combination is a fixed list of resources, and combinations must be created manually. i’m not sure how it’s supposed to be used.

if only one resource.booking is created for a customer booking, this means that the booking and all its options must be represented by one combination. for example, if there are 4 rooms, 3 video projectors and 5 people that can be combined freely, 96 combinations (including the “no video projector” and “no waiter” choice) must be created (and each of them must be added to at least one resource.booking.type to be selectable). moreover, the client would need to search through all of these to find the desired one. and what if there could be multiple waiters? this feels awkward. also, availability is only visible per combination, not per resource, so it is not very useful. however, it seems that availability conflicts are checked per resource, but in case of conflict, no information is given about which resource is not available.

another option is to create one combination per resource, and create multiple resource.bookings (with the same date and the same partner) for one customer booking. this is more flexible, but there are no direct links between all of these bookings. what if the customer wants to change the date or cancel the booking?

for billing, sale_resource_booking allows to link a product to a resource.booking.combination, so one product is needed for each combination. it also allows to generate a sale order from a resource booking type (so combination and dates must be selected afterwards), but i didn’t find a way to do it from a booking, which would be more useful.

i understand why using combinations can be useful (as a compound for common use cases), and this is maybe a good technical decision (because it can avoid duplication), but i think that as they are, it seems that, in many cases, they get in the way instead of helping. am i maybe missing something obvious?

here are some possibilities i’m currently considering:

  1. use one resource.booking per booking, but hide the combinations from the user (using a wizard, for example). the user would select all desired resources, and a matching combination would be used if one exists, or one would be created on the fly.
  2. use multiple resource.bookings per booking (one for each resource), create one combination per resource, and find a way to link resource.bookings together.
  3. extend resource.booking by allowing multiple combinations to be booked per booking (instead of only one), and create one combination per resource.
  4. extend resource.booking by allowing multiple resources to be booked directly per booking (instead of a combination), and don’t use combinations.

for objects considered as always available, use a product, and extend resource.booking by allowing multiple products (with a quantity) to be linked to a booking, or simply add them directly to the generated sale order.

i’m pretty sure that this resource booking use case is quite common, and having a generic solution that works for most cases would be useful. do you have any ideas about all this?

cheers,

hugues de keyzer
coop it easy

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

Another option besides resource.booking would be to just use the rental modules
and add all rooms and individual objects as products in Odoo.
You can then use products packs and product sets to create combinations or
standard offers of the base products.

Olaf
--
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com
Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194

Reference