Discussions

Hypothetical Strategies for Travel Registration System

I have a project, in its early stages, and part of it, conceptually, is thwarting my brain.
I'm making a travel/tourism site.
Customers can make registrations for tours, that happen at specific times.
So far, no thwarts, but wait, it gets better ...
Let's say that a customer wants to sign up her/him-self up for a mountain biking adventure tour ...
also her/his significant other ...
ok ... quantity of product=2 ...
Customer has his/her own bike to take on tour, but significant other requires a (an add-on/product attribute) bike rental, that increases the cost of his/her registration by a set amount for that particular trip. So no ... the two products are not identical anymore ... product quantity !== 2 ... it's two different products of the same sort that need to have attributes configured separately ...

Also, lets say that we need to capture additional registration details for each persons trip-registration-product, ie, a mandatory webform of sorts, that captures, name, age, birthday, any relevant medical conditions, t-shirt size (they get a complimentary t-shirt with trip) etc.

How do we do it? I'm not looking for specific details/ or instructions here ... more like general pointers, some kindness from the D7Commerce clue fairies.
I've attempted to tackle this with d6/ubercart in a few different ways, and haven't received much joy for my troubles yet.

le_petit_basil
Posted: Mar 17, 2011

Comments

Ryan Ryan Szrama on March 19, 2011

This is still in the experimental realm for Commerce, as we need to decide how much should be done via line item fields and where we should integrate with other modules. I tend to side with creating unique products for any variable options that affect the price point of a sale, but for other related data I might want to see how we could associate line items with other form data... perhaps using "registration" nodes or Webform.

travel19 on August 17, 2011

It is very innovative idea and experimental thing which is very complected to implement all the factors which require to book a particular tour. And I agree with Ryan that we need to decide how much should be done and where we should integrate with other modules. But after a successful implementation system will be very useful to sign up a tour. Hope this will be top Travel & Tourism site for tour booking and information. Recently when we went on Gwalior India tour we were looking on internet to book a tour but whatever resources we found, we were not satisfied on those tour booking site. All the best..!

tahiticlic on August 22, 2011

We've just developed such a travel site : lot of work to face lot of problems but the result is quite good (at least it respects the brief), the major problem was to deal with time dependant prices (I've opened a post here, no answer, see http://drupal.org/node/1081826 for a more specific discussion) for what create variations of a single product was not possible (for a single product, that would have lead to thousands products). The solution was to define a complex "price" field and a module to manage prices on the add to cart operation.
Moreover, there was a lot of work to do to automatically add some products during checkout, because these products were dependant of the cart content and the number of traveler...
Payment module was easy to develop.
We also have developed a Commerce product auto creation on display product creation (the client only creates nodes, never Commerce product).

The site is on internal testing step at the client, and shall be opend soon to the public for the eCommerce part (already opened for the catalog part). I'll give the link as soon as it will be online.

Today, I'm glad to have chosen Commerce for this project, even if there was a big (and underevaluated) effort on bugs correction or early stage non stability of APIs.
Still, for less complexes project, or more "dynamic" project in structure (with a lot of catalog categories, and a lot of modifications in these categories), I'm less confident in Commerce to be the solution because it's too developer-oriented and not at all user friendly : this restricts use of Commerce to companies that can afford a Drupal webmaster.