Fwd: Re: Creating time scheduled products - bus tickets

[Atul Vani <at...@hotwaxmedia.com>]

Ah, Missed to do reply-all so forwarding.

------- Forwarded message -------
From: "Atul Vani" <at...@hotwaxmedia.com>
To: "Angel Gerdzhikov" <an...@gmail.com>
Cc:
Subject: Re: Creating time scheduled products - bus tickets
Date: Sun, 31 Mar 2013 01:14:31 +0530

Comments inline.

On Sat, 30 Mar 2013 16:36:34 +0530, Angel Gerdzhikov
<an...@gmail.com> wrote:

> Hi Atul,
>
> thank you for the quick response. I think more or less I would make the  
> stuff the same way, but I see some problems doing it this way.

Though the way product features are mentioned to be used is not right, but
what I had in mind was to minimize the custom implementation. If a bus
travels from station P to T via Q, R & S, and some customer wants a ticket
   from P to R, then you can sell him the PQ and QR features (think like
sizes for a t-shirt) of that seat.

>
> How about time tables. The use case is, that I have a lot of trips but  
> they are regular trips. A bus is traveling each business day from A to B  
> and I don't wont to define each "ticket" (an instance of a virtual  
> product) individually but much more to define some time expression like  
> a cron job on the virtual product level.

Tickets will need to be defined individually. People would want to book
the tickets in advance. And you would like to tell the customers which
tickets/seats are already booked. So, they need to exist in the system to
store these kinda information.

It's not like one can book a ticket for infinite time in advance. There
will be some kind of upper limit, say two weeks. Two weeks will be the
time that you can provide commitment for. So with the design provided, you
will need to have products created for all the trips in next two weeks, to
be able to sell those. You can surely use some scheduled jobs to create
tickets, or you can create them on the fly. For example, if someone tries
to buy a ticket for a trip on 40 days from now, then create that trip at
that moment. You will need to store plans for future trips in this case,
possibly using work efforts.

For the problem of creating so many tickets for so many trips of just a
single bus, ofcourse there will several buses, you can use template
products. There might be different size/design of buses with different
number of seats. With these different numbers, you might have different
number of reserved-for-women, reserved-for-seniors, reserved-for-handicaps
and VIP seats (another use of product features). So, you will need to
design the setup (product) in advance, and then just duplicate it along
with it's variants for each trip.

> So the user should be able to search about trips in the feature, and the  
> system administrator don't have to define these trips manually but he  
> still should have the possibility to cancel some trip in the feature  
> manually.

Custom implementation will be required for both of these, but it's going
to be a small one.

>
> An other question is I will to have some kind of management of the  
> busses. Each bus has a capacity e.g. 40 seats and some meta information  
> like type, name, year of construction and so on. The count of tickets  
> from A to B should be based on the count of seats in each bus. And in  
> accordance of this count I have to determine the available count of free  
> seats for a particular trip.

Buses are fixed assets for your business, but I do not have much knowledge
in that area. Someone else from the community might be able to help here.
Though you can also use product attributes for meta information, but I
would have explored the first option if I were you.

The count thing will be managed by the variants, along with lot of other
options like window-seat, the row of the seat etc. You will need to show
something like this for seat selection
http://a1hollowayrental.co.uk/images/17seater_top_view.jpg

>
> What are you meaning exactly with "Associate from and to geo with the  
> product feature" ?

As in the example above. P, Q, R, S and T are the stations/cities. Then
they will be managed using the Geo entity (table). Also there will be a
timing associated with them, people would want to know when the bus
reaches station Q and R and S.

>
> I can't see how can you manage this aspects in the way you've described,  
> but I'm really new in the stuff.... What of this things can I do with  
> functionalities from Ofbiz and what have I to build from scratch.

Well, some are outlined above, but for a full fledged ecommerce system you
will need a decent amount of development. The library supports it all, but
a customized interface to manage stuff will be required.

>
> Thanks and regards,
> Angel
>
>
>
> On 27.03.2013, at 06:46, Atul Vani wrote:
>
>> Hi Angel,
>>
>> Here is what I could quickly think:
>> * Create the trip between origin to destination as a virtual product.
>> * Create seats in the bus as variant products. You will be selling  
>> these.
>> * Create all the stations as product features. This will allow to sell  
>> a seat for a particular set of stations.
>> * Extend the product feature entity to include from and to timing.
>> * Associate from and to geo with the product feature.
>>
>> You will need to code some business logic yourself.
>>
>> --
>> Thanks & Regards
>> Atul Vani
>>
>> On Tue, 26 Mar 2013 04:38:16 +0530, Angel Gerdzhikov  
>> <an...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm pretty new in the Apache OfBiz and I'm looking for a solution to  
>>> build a online portal for selling bus tickets. So far as I saw the  
>>> Apache OfBiz offers almost everything to create such a solution. The  
>>> only thing, I'm not sure if it's possible, is how to create a product  
>>> representing a place in a bus at some time point from "A" to "B". Its  
>>> the standard use case for this scenario: I have some providers,  
>>> offering a journey from A to B: each monday at 12:15 a bus with 40  
>>> places is traveling from A to B via C and D. I'll offer my customers  
>>> to by tickets for the trip from A to B, but may be also from C to B   
>>> etc. Is a use case like this full ore partially covered by the Apache  
>>> OfBiz or I have to implement everything from scratch. I'll be very  
>>> happy if someone has an advice how to solve my problem
>>>
>>> Thanks a lot and kind regards,
>>> Angel
>>>
>> --
>> Using Opera's revolutionary email client: http://www.opera.com/mail/
>


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/