How must the e-Commerce module be enhanced to be suited as a booking system?

Hi all,

I think the e-Commerce module is a good basis for a booking system. I would suggest, that we discuss how the e-Commerce module could be enhanced so that it can be used as a booking system.

For the use cases I can think of, a booking system consists of two parts:

1. Data modelling and presentation (themeing) of the object/service/thing that can be booked. This can be done with CCK.
2. Support of the booking workflow (booking, invoicing, get in contact with customers). Would be good if this was supported by e-Commerce.

Here I would like to discuss only the second part, the workflow of booking and invoicing using the e-Commerce module.

• In the e-Commerce module the generic term for everything is 'Product'. This term should be made configurable. In a booking system, you would like to call this 'Objects' or 'Offers' or 'Services' or whatever.
• The same may apply for the term 'Store'. You may want to call it 'Catalogue' or 'Portfolio' or ... So this term should be configurable, too.
• Assuming that the items which can be booked are nodes that were designed with CCK, we just need an e-Commerce submodule, which allows any node type to be configured as 'bookable'.
• For 'bookable' nodes, you probably don't want a 'add to cart' link on the node page, but you want a 'book this object/service/whaterver' link.
• A booking is a more complex process than just adding a product into a shopping cart, by just selecting (size, color, quantity, ...)
• Currently the e-Commerce module allows users to put products into a shopping cart and then to checkout. During checkout, billing and shipping information is collected from the user and an invoice is automatically created. For the booking workflow this is quite different, invoices can only be created semi-automatic after the shop owner has approved the booking:
  • A customer clicks on a 'book this object' link and get's redirected to a booking form to create a booking. I would like to suggest, that a booking is just an other drupal node type, which can be designed by the shop owner/administrator with CCK. The only constraint is, that a 'booking' node must reference a 'bookable' node.
  • Using CCK a shop owner can define what data a customer must supply for a booking (e.g. arrival date, departure date, number of persons, age, checkbox for smoking/non-smoking, ...). So a customer filling out the booking form is actually creating a new 'booking' node, where the booking form is actually the create node form generated by CCK. The booking form may vary from content type to content type. Say you have a 'holiday apartment' content type which is flagged as 'bookable' and a 'hotel room' content type which is flagged as bookable. The booking form may differ for those two content types. So the shop owner must be able to assign the booking type for each bookable content type. In the example, we may have 4 content types in the end: apartment, hotel-room, booking-apartment and booking-hotel-room, where booking-apartment-booking is assigned to apartment and hotel-room-booking is assigned to hotel-room.
  • After creation of a booking, the referenced bookable node is flagged as 'booked up' (or even set to unpublished) or the available quantity is reduced. Their should be various 'bookable' implementations available (probably as own submodules). I can think of 4 variations right now: 1. The referenced node is marked as booked up. 2. The booking type allows to specify a quantity (e.g. maximum occupancy) and can reference a field of the booking type (e.g. persons). After a customer has filled out the booking form, the available occupancy value is reduced by the amount of persons specified in the booking form. While available occupancy > 0, the bookable node is not marked as 'booked up'. 3. A node cannot be booked up and is always infinitely available. 4. The bookable node is backed by a schedule and the node can't be booked for that date any longer.
  • The shop owner gets notified of new bookings and is able to list them (show me all bookings), view them and accept or decline them, which results in an appropriate booking confirmation message being sent to the customer.
  • The shop owner can create an invoice for a booking. I think for invoices, the existing e-Commerce invoice submodule can be used as it is, without much changes. An invoice just references a booking node. Creating an invoice should be semi-automatic, there must be form fields for the various data of an invoice, but they are pre-filled with data from the referenced booking (and it's referenced bookable node).
  • Simple Example for creating an invoice-tpye for holiday apartments: The shop owner configures a new invoice type invoice-apartments for the booking type booking-apartments. He declares, that the invoice-apartment has 4 positions. Every invoice position has a quantity, short description, unit price. For each position (row) and column (quantity, description, unit price), the shop owner can setup rules (using tokens of the token module) which declare, how the fields of the invoice creation form should be pre-filled with data, when a new invoice is created for an existing booking. The data types of those columns are fixed for all invoices (quantity -> int, description -> text, unit price -> decimal. Each position (row) as an auto calculated 4th column 'total' or 'sum' which is calculated (quantity * unit price) after the user submitted the invoice creation form.
    1. The shop owner declares, that the quantity of position 1 is the difference in days (departure date - arrival date) defined in the booking node. The description of position 1 is an catalog ID taken from the node referenced by the booking node, the title of that node and the arrival + departure date specified in the booking node. The unit price should be taken from the field 'price per day' specified in the node referenced by the booking node.
    2. Position 2 of the invoice should always have a fixed quantity of 1. The description should be named 'Deposit' and the unit price should be taken from the field 'deposit' of the node referenced by the booking node.
    3. Position 3 of the invoice should have the fixed description 'Visitors Tax', the quantity should be the product of the number of persons specified in the booking node multiplied with the difference in days of departure date - arrival date. The unit price should be taken from the field visitor_tax of the city node, which is referenced by the apartment node, which is referenced by the booking node the invoice should be created for.
    4. Position 4 of the invoice should have a fixed quantity of one (1). The description should be the fixed text 'Early Bird Discount'. The unit price should be the total price of position 1 multiplied with -0.10.
  • After the shop owner has setup an invoice type for a booking node type, it's possible to create invoices for exiting bookings. The invoice creation form is pre-filled using the rules defined for that invoice type (how many positions, quantity/description/unit price of each position). The owner can accept the pre-filled values or make changes to them (e.g. he had an email conversation with the customer and knows, that two of the 7 persons specified in the booking are children which don't have to pay the visitors tax, so he changes the quantity of position 3 from 49 (7 persons * 7 days) to 35 (5 persons * 7 days). The owner has the chance to modify all values during the invoice creation if he wants to.
  • After the invoice has been created, an email is sent to the customer. The invoice can be paid using the available e-Commerce payment modules.
  • Currently Drupal users can view their "order history" on their "My Account" page. This section should be enhanced so that it can be named "booking history", where customers can review their bookings and invoices.
• The e-Commerce module already implements transactions and their workflow states. What's missing is a transaction history. A way to review the complete history of a single booking. (When was is created, when was it accepted by whom, when was the invoice created by whom, when was the payment status changed to 'payment received' by whom, ...)

This list should not be considered as complete. I just want to start the discussion, if the existing e-Commerce module could be enhanced with a set of patches and submodules to be suitable for a booking system!? I think this approach might be easier than the implementation of a separate booking engine/system!? Please post you comments and ideas.