Seat reservations for (recurring) events on given days

Question

I would like to let my users reserve seats (or a whole table) for events, and pay for the reservation via PayPal.

Different performances/shows would be advertised, users could choose which tables or seats they would like to reserve. A theater OR bar, restaurant, etc. would have "fix" seats and tables, so they would not change (or just rarely); events can be repetitive/recurring (e.g. concerts) - in some cases, locations can remain the same too, so only the date changes (e.g. a concert played in Example Bar 3 times a month); but one event can be played in other locations too.

I tried on Drupal.org first, but I got no answer; any help would be appreciated.

If there's no way to "bind" it to Ubercart, I'd solve it in another way (PayPal IPN), but I have to do it ASAP.

P.S.: I've already tried MERCI, Simple Reservation, Hotel Booking System for Ubercart and Reservation modules (the latter seemed OK from the picture), but unfortunately I couldn't figure out how to do something similar to what I need - BUT THIS MEANS NOTHING, maybe I just overlooked some opportunities!!!

If you say I can solve it with one of these modules, please help! Even if you have a totally different suggestion! Thanks!

---

UPDATE:

In the meantime I found this very interesting article: Ubercart Event Registration
Let me quote from it:

at the moment, the de facto Ubercart method for doing online event registration is with a module called UC Node Checkout. It's perfect for a one-and-done event registration site, but for a site that is hosting several events simultaneously and on an ongoing basis, it's awkward. This is due to the fact that it maps a content type to a product SKU - so for each event you'd need to create a new content type. Not really very good long-term, particularly when the site administrator is not overly familiar with Drupal or Ubercart.

So, an alternative solution was devised using the Webforms module. The webform stores the registrant's organization's information - and also asks the registrant how many tickets to the event they want, which is the use case the client specified. The webform, after processing the form, adds the event 'tickets' to the cart. This is done with the 'Webform advanced settings' field in the webform configuration, under 'Additional Processing'.

Good to know. This means the article I found earlier doesn't describe what I need.

Another quote from uc_event_registration's readme:

UC Node Checkout

This is the approach that has been used alot for Drupal conferences and demo'd at drupalcons. The huge problem here is twofold: First, registrations are nodes. That means we have to build views to create registration lists and that seems like unnecessary overhead when Webform is so much lighter weight. Second, and most importantly, you need a new content type for EVERY event. No thanks. On sites that are doing dozens of events per year, this would mean, eventually, a huge amount of content types. That's bad.

Here's another one related to Webforms: Drupal Webforms With Dynamic Select Boxes Tutorial This seems very promising, maybe this could be the way one could solve what Andy suggested.
I'm still interested in suggestions for practical solutions - maybe this way!

Answer 1

I don't think you are going to find a solution that does 100% of what you need, I expect there will need to be custom development here.

Sounds like a custom content type (CCK) + ubercart + paypal (with ubercart) will be the most flexible solution. Perhaps read through the reservation module to see how it limits the available supply of tickets (i.e. sold out).

I would also suggest to remove the graphical part of the event registation, as this looks like it could be tricky, and instead focus on the core functionality of the app, i.e. the registration and payment workflow.

Every problem can be solved in drupal, but some of them are unique, and have their own solution.

If you need this solved ASAP, looks like you may need contractors, or some late nights ;) If you want to attract more quality answers, consider placing a bounty on this

Answer 2

I agree with other answers in that you wouldn't get 100% of the way there without some custom development.

My first thought on solving this is don't worry too much about the interface, just get the data entities right. I think your products really only need two new fields at its most basic (venue, which could be a node reference and date (or another node reference to an event content type and reuse events)). Use stock to be the number of tickets available at a venue for an event and product kit could be a table which is just made up of the individual seats and would therefore manage stock and could also have discounts associated with it.

As far as interface goes you could create a calendar view of "seats" and "tables" (tables are just product kit).

EDIT: To distill the gist of the comment thread on this I'm going to summarise here.

What we seem to have got to is the following:

• A particular event at a particular venue is a product class/content type. These content types all have one CCK field, the event date.
• When you create a new instance of this product class you specify the date and add ONE attribute to it, that is the table number. The values of this attribute correspond to the number of tables to the event.

The workflow this describes is that a customer chooses to add an event to the cart, and as part of this process they have to choose a seat number and a number of seats that they want.

This allows a couple of things:

• You can actually price tables differently,
• You can manage stock at a per table level.

This is because an attribute, straight out of the box, has its own SKU and therefore its own stock levels and own pricing. If you think of what attributes are for this makes sense. If you have red and blue shirts you need to know how much of each you have, i.e. stock levels. If large shirts cost more than small shirts then you have to know how to price them.

Keep in mind this only describes the workflow and the backend. Webforms as described in other answers can still be used to control the interface, as could a custom built form. This is just to manage the data entities. You still have to create events manually but I think in this case the small number of content types is a good thing, and a process could be put together pretty quickly to automate some of this (look at Node Import for this, it can with some other contrib modules handle attributes as well if you wanted to customise the values)

Some notes:

An interface that works in this instance is a simple view of your new content types (split them by venue if you want as each content type is venue specific) with a link to the actual product. Then you can select a date and a number of tables. If you want to book seats at different tables then you will need to add another product to the cart.

The module UC Attribute Stock isn't really relevant here I think. As far as I can tell it just combines multiple attributes into one selection. That is given the example above of red and blue colours and small and large sizing, rather than have two dropdowns that the customer has to select from you have one drop down with four selections.

The webform solutions are not precluded from anything above. They are providing the interface, and may make sense if there is other, NON PRODUCT, data that you want to collect from your registration. Keep in mind though that you may be able to collect this from the checkout pane a bit more easily and in line with current shopping workfow. I think writing a form though, especially if you want it to have some smarter widgets on the front of it will be easier and lighter in the long run than shoe horning webform into what you want to do. For the basic workflow I don't think you even need it.

Answer 3

A slightly different approach to the others. You could use Ubercart Event Registration for the individual registration forms, and the custom coding could just be a custom webform widget (see webform_hooks.php and the files in the components directory for more details). This would be responsible for showing only available places, and reserving the selected place on submission. If you saw a reason, you could integrate the component with one of the reservation modules you mention above. I don't think this is much less work than the alternatives, but it's a slightly different model in that it uses webform. (And I agree entirely with Malks that you want to first decide about how it's going to be handled internally.)

More details: I think there's a number of ways you can do it, depending on for example whether you want to integrate with an existing module, whether you want to use nodes (can be great for quickly making reports with Views), etc. Here's a very brief description of how you might do it with an entirely bespoke implementation.

Assumptions: a single reservation consists of a date, and any positive number of seat IDs.

1. Create a module that provides a webform component for the reservation.
2. The module should also create a DB table for storing reservation details.
3. To begin with forget about a fancy widget, just make it simple (eg. have a textfield for the date, and another for the seat IDs - they can be entered as a comma separated list at first).
4. On validation, the webform component checks with the DB table that the values are valid (ie not already reserved).
5. On submission, the webform component again checks if the reservation is available, and if so makes the reservation. You want to be careful here that two users submitting a request at the same time can't make the same reservation (eg. use a lock in your submit handler).
6. Go back to your widget and make it fancy, eg. have a nice JS date picker that only shows dates with remaining reservations, maybe with some semi-graphical tables that show available seats and let you select them neatly. But underneath it's all basically doing the same thing.

I've not tried something quite like this, so just an idea!

This is still a very simple system, and as it stands it's not very easy to get the data out. You might want to make some bespoke admin screens or you could views enable your db table.

You don't want to use this approach unless you want the idea of one node per form, with submissions being stored in the webform submitted data table. You really want to be sure that this fits your needs before taking this path imho.

Answer 4

I think you should make table as a product.

We've this relationship: event1 -> date1 -> city1 -> restraunt1 -> table1

So 1 refers to 1-many relationship.

Have Venue table with information about each venue and tables and other attributes

Have City table with city + venue details

Have OrderBooking table with this: event1,date1,city1,venu-id,product-id

Customer will browse from event to restraunt and will see available seats(products). Write a module to display the (availability) details along with links to create a product. As soon as one clicks a link in the venue, arrange for a pop up which will ask for table specific details and direct to product form and auto populate the product with those details in a custom cck field. Now when tries to buy the product then you should write a module to check availability and after payment have this product related to the OrderBooking table.

You'll need to use UC Node Checkout module as described here for collecting registration data.

I've taken a simplistic view.

Answer 5

I did something similar for a tour agency. I used the Hotel Booking module for Ubercart, each event is a "room" which you can set a limit for occupancy and charge differently depending on the day. On the admin side, you have calendars you can select what days are available on a recurring basis. I believe you can have different kinds of [events] as well.

The only issue was it was new in Drupal 7 and had a few bugs, but it may have improved by now.

Answer 6

You can check the following module: Booking Time Slots.

As the name says, it provides Time Slots Booking functionality. It integrates with Views and Calendar.

Check the sample screenshot in Drupal 7.x:

For more, check Comparison of Booking System modules.