Feature request : recurring booking

[samuelsov]

Is there any plan on having recurring booking ?
For example, book a resource every monday from 9h to 11h for next 10 weeks ?

In my case, there is no payment so it's a quite simple use case but i guess for paying booking, it could be more complex (keep it simple with a one time payment for now ?)

[guanhuan]

Hi @samuelsov ,

Thanks for posting this.

Will this be something that are you interested in contributing code to or financing? If it is latter, we will get one of our developers to take a look at what is feasible and provide some estimations.

[samuelsov]

Hi @guanhuan,

I don't think i have enough budget to finance it right now unfortunately.
If you have already put some thought on this, it could be a good idea to share so i could try contribute something. Otherwise, it seems like too much work for my specific project and i might end up with some other way to emulate recurring (using recurring activity).

[knockiiing]

Hi Guanhuan, Jamie, can you give me the cost factor regarding recurring and implementation timeframe? I will discuss this with my organization. Many thanks in advance.

[jmcheung]

hi @guanhuan @jamienovick

I just had a meeting with a customer interested in CiviBooking. One of their requirements is recurring bookings.

Did you have a cost for this development please?

thanks,
Jon-man

[jmcheung]

hi @guanhuan @jamienovick

I really want to help make this happen. I know there are questions to be answered about precise functionaltiy, but perhaps if we can agree something with @samuelsov and @knockiiing I know GMCVO will be able to contribute to costs of the project.

As mentioned, I would like to see CiviBooking developed in the same way as activities.

As a starting point, at the very least, the recurrences should create bookings - with the same contact, with the same limited resources (from step 1) on the re-occurring dates. The contribution records (payment) should also be created if there are costs involved. One further feature, would be a tick box to create one contribution record for all the bookings but I don't know how much work is involved there. This is to satisfy the scenario when you take a block booking. e.g. a school hall for a term, made in one payment.

This post https://civicrm.org/blog/deepaksrivastava/core-recursion-the-recurring-events-engine suggests Veda did some work on a Recursion Engine for CiviEvent. Can the same be done for CiviBooking?

thanks,
Jon-man

[samuelsov]

Quick thoughs :

• table civicrm_recurring_entity is generic so i don't think this require any change in the database.
• recurring api is made to duplicate entities based on any repetition parameters - in our case, we don't want to duplicate a booking but we want to duplicate the slots i believe. I don't think it will be too complex. It will effectively create new entries in the slot tables which CiviBooking will handle like any other slot but we need to ensure that each slot don't overlap with another slot (error message if it's the case).
• we need to change the UI for editing a slot to add the repeat slot UI that use the same layout as the one used in Repeat Activity
• by default, without modification, CiviBooking will give one contribution for everything and i suggest we keep it that way for the first version (otherwise, we might need to create recurring booking instead of recurring slots ?)
• I don't have enough knowledge on how CiviBooking is dealing with existing booking editing (price changes, locking of past slots ?), but we might encounter extra difficulties with recurring slots ?

[jamienovick]

Hi all,

Thanks for this. Sounds really exciting. Can I ask those who are interested to email me direct and we will see if we can get a call in to get this kicked off? [email protected]

I have to say that I think this is likely to be more complex then it at first appears. CiviBooking doesn't have full accounting integration with CiviCRM and some development is possibly needed there.

Also we need to differentiate between having multiple instances of a booking and a booking that has multiple "repeating" slots. Currently there is nothing to stop you doing each of these manually; so we need to really understand the use case to pick the correct option which is to make entering in this data easier in the system.

Best

Jamie

[jmcheung]

To be honest, accounting isn't really a priority for me. Is it something we can cover in future releases? I do agree with @samuelsov. One contribution for all recurrences is also ok for us.

I'm very happy to take part in a call. Who else wants to join us?

[jmcheung]

Hi Jamie, How do you think we can progress this please? Best regards, Jon-man Cheung Databases Manager (GMCVO Databases) T: 0161 277 1020 W: www.gmcvodatabases.org.uk<http://www.gmcvodatabases.org.uk/> From: Jamie Novick [mailto:[email protected]] Sent: 20 November 2017 16:26 To: compucorp/civibooking <[email protected]> Cc: Jon-man Cheung <[email protected]>; Comment <[email protected]> Subject: Re: [compucorp/civibooking] Feature request : recurring booking (#124) Hi all, Thanks for this. Sounds really exciting. Can I ask those who are interested to email me direct and we will see if we can get a call in to get this kicked off? I have to say that I think this is likely to be more complex then it at first appears. CiviBooking doesn't have full accounting integration with CiviCRM and some development is possibly needed there. Also we need to differentiate between having multiple instances of a booking and a booking that has multiple "repeating" slots. Currently there is nothing to stop you doing each of these manually; so we need to really understand the use case to pick the correct option which is to make entering in this data easier in the system. Best Jamie — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#124 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AIGZwortIi8vrpikyGvf18MTRxIARg1oks5s4af5gaJpZM4I2tE8>.