Skip to Content
  2. Mailing Lists
  3. Contributors
  4. Re: booking of resources

Archives

Contributors

Re: booking of resources

Re: booking of resources

hello,

thank you, pedro, olaf, and jairo, for your answers.

what we ended up doing is creating a module (resource_booking_auto_create) that adds a wizard that allows to select resources by category, and create resource combinations on the fly. it is available in oca/calendar#83. reviews welcome.

while this solution works, it feels to me like a big workaround. i realized too late into the development process (our budget on this was too limited) that a better solution would be to split the resource_booking module into multiple parts, because it handles too many independent things:

  • resource_booking would be the base module which defines the resource.booking model and allows to book resources directly (m2m relationship to resource.resource) and handle the availability of resources.
  • resource_booking_type would depend on resource_booking and define the resource.booking.type model.
  • resource_booking_combination would depend on resource_booking_type and define the resource.booking.combination model.

installing resource_booking_combination would result in the same behavior as is currently the case with resource_booking. in our case, we would depend only on resource_booking instead of creating useless combinations under the hood.

what do you think of this refactoring?

we also needed to be able to link a resource booking to a sale order. the sale_resource_booking module (which has not yet been migrated to 14.0) allows this but works in the opposite way of what we needed: it allows to schedule a booking from an existing sale order, while we wanted to create a sale order from a scheduled booking.

we ended up creating a new module resource_booking_sale that creates a sale order for each resource booking and displays (and allows to edit) the sale order lines directly on the resource booking form. it also allow to link a product to a resource booking type and to a resource and generates the sale order lines based on this. it is available here. what do you think? reviews welcome.

for the module containing the wizard, we had to define a resource.category model. we did it in another module (resource_category) (oca/calendar#83 adds several modules). it is a really simple addition (just a simple resource.category model with a name and m2m relationship between it and resource.resource), but i think that it should not belong in oca/calendar. i think that we are missing an oca/resource repository for modules handling resources.

what do you think?

cheers,

hugues
coop it easy

by hugues - 11:40 - 22 Feb 2023

Reference

  • booking of resources

    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

    by hugues - 08:55 - 17 Jan 2023

    4 replies 4 replies

    • Re: booking of resources

      hello,

      thank you, pedro, olaf, and jairo, for your answers.

      what we ended up doing is creating a module (resource_booking_auto_create) that adds a wizard that allows to select resources by category, and create resource combinations on the fly. it is available in oca/calendar#83. reviews welcome.

      while this solution works, it feels to me like a big workaround. i realized too late into the development process (our budget on this was too limited) that a better solution would be to split the resource_booking module into multiple parts, because it handles too many independent things:

      • resource_booking would be the base module which defines the resource.booking model and allows to book resources directly (m2m relationship to resource.resource) and handle the availability of resources.
      • resource_booking_type would depend on resource_booking and define the resource.booking.type model.
      • resource_booking_combination would depend on resource_booking_type and define the resource.booking.combination model.

      installing resource_booking_combination would result in the same behavior as is currently the case with resource_booking. in our case, we would depend only on resource_booking instead of creating useless combinations under the hood.

      what do you think of this refactoring?

      we also needed to be able to link a resource booking to a sale order. the sale_resource_booking module (which has not yet been migrated to 14.0) allows this but works in the opposite way of what we needed: it allows to schedule a booking from an existing sale order, while we wanted to create a sale order from a scheduled booking.

      we ended up creating a new module resource_booking_sale that creates a sale order for each resource booking and displays (and allows to edit) the sale order lines directly on the resource booking form. it also allow to link a product to a resource booking type and to a resource and generates the sale order lines based on this. it is available here. what do you think? reviews welcome.

      for the module containing the wizard, we had to define a resource.category model. we did it in another module (resource_category) (oca/calendar#83 adds several modules). it is a really simple addition (just a simple resource.category model with a name and m2m relationship between it and resource.resource), but i think that it should not belong in oca/calendar. i think that we are missing an oca/resource repository for modules handling resources.

      what do you think?

      cheers,

      hugues
      coop it easy

      by hugues - 11:40 - 22 Feb 2023
    • Re: booking of resources
      Hi Hughes!

      El mar, 17 de ene de 2023 a las 19:56:59 PM, hugues de keyzer <notifications@odoo-community.org> escribiĆ³:
      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

      Although you might feel like the combinations design is weird, the use case you're proposing here is actually a good reason why it exists.

      Are customers able to do a single booking of 2 projectors? That's unlikely. Or 1 projector and 2 rooms? Also very unlikely. 1 projector, 1 room and 2 waiters? That could be. 1 projector and no waiters or rooms? Depends on the case. Are all projectors available in all rooms? Or some rooms have a projector installed statically that can't be booked for another room? Are all rooms in the same building, or are they in different buildings? Are all buildings in the same country? Are there big rooms that cannot be handled by just 1 waiter?

      The amount of possible combinations (and more important: the impossible combinations) justifies the existence of resource.booking.combination.

      So IMHO the best approach would be to simplify the usage of resource.booking.combination, instead of replacing it. Some ideas:

      1. Add a button "Generate combinations". The button opens a wizard that will help you create combinations massively.
      2. When the user is selecting the combination, improve the UX making them available to pick resources individually. The engine would then select the appropriate combination under the hood.
      3. Add an option to the type: "Allow all possible combinations". Then, when customer selects the combination, resource by resource (idea 2), if it doesn't exist, it will be created on demand.
      Other than that, it seems to me like the use case you described fits perfectly in the resource_booking collection, so you'll probably be better improving them than reinventing them.
      by Jairo Llopis - 09:46 - 19 Jan 2023
    • Re: booking of resources

      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

      by Olaf Wagner - 09:51 - 18 Jan 2023
    • Re: booking of resources
      Hi, Hugues,

      You can expand current resource_booking for adding the concept of "quantity of a resource" for not having to declare each of them individually, and also add a resource type. Then, both can be added to the resource combination for not needing to declare such an amount of combinations. I think it's not so hard to plug both features into the current module and will prevent you from reinventing the wheel.

      Regards.
      by Pedro M. Baeza - 09:26 - 18 Jan 2023