Bus Ticketing System

I have a propective client for a bus ticketing system. I'm having it difficult with having both an online and offline ticket purchase.

Offline you purchase from the bus terminal. So for a 18 seater bus been sold online and offline how streamline the sales such tickets sold at the terminal are not bookable online and vice-versa? A solution would be to have terminal attainder use the online system to book seats on behalf of customers.

But how about when there is internet down (especially when it rains as it is common across Africa) that customers can not book online by themselves, they would flood to the terminal and with the terminal attainder not able to use the online system, they would result to doing manual paper-based sales. How do would one reconcile that and mitigate having booking records missing on the online database or a seat being booked more than once for several customers for the same time schedule?

Also how feasible is it to have the terminal attainders use an offline version of the system to process ticket sales and have it uploaded to the online system at the close of the day?

Will appreciate voices laid to this.

You need two things. Online access checking, and centralized storage of ticket sales.

The website would need to regularly check for a connection to the centralized storage server. If there is no connection, the site should automatically be taken offline (a script to change the System Setting "site_status"). A "Sorry, we're offline, apologies for the inconvenience" message would be displayed. This could be done with a plugin on each page request. When the connection is restored, if the site was offline it would be put back online.

The ticket system would check the central storage database, both the physical and online systems, thus keeping the central storage always up-to-date for all access points. This database will not be associated with MODx, it will just be accessed by snippets for handling the online sales forms.

This could be complicated if more than one database server is required, but the databases all have methods of keeping track of each other and updating each other. The actual database design would depend on too many factors for me to be able to make any suggestions; a database developer would be needed to handle the actual database design.

If any "child" databases cannot connect to the central database to keep itself up-to-date and update the central database to its own activity, sales at the stations that uses that database should be stopped until the connection is restored and the "child" is updated to mirror the central database. Again, any good database developer or administrator should know how to manage that sort of duplication and mirroring.

Some great thought here. Thanks.

There will be three sales outlet: at the terminal, online and at partnering retail stands. I'm thinking we could designate tickets with classes that sold at terminal, online and at retail stands, with the online database being the master DB and the terminal and retail using an offline version of the online application. Daily sales are then reconciled at the close of the day or just before bus departure.

But would it be ideal to maintain and be able to mitigate sales malpractices? [ed. note: ojchris last edited this post 12 years, 8 months ago.]