TravelTrack

The TravelTrack client/server application is designed to give business travelers a very simple advantage…more time. By reducing the time spent on many mundane but very necessary travel related activities, TravelTrack frees the business traveler’s mind and energy for more important tasks...like those related to the whole reason for being on the road to begin with.

= Description = Activities like booking travel, coordinating schedules & events, submitting receipts and finding acceptable restaurants while in the field are simpler with TravelTrack.

Overview
OK. Now that the sales pitch is over, here are some more tangible line items about TravelTrack:
 * Itinerary tracking
 * Nested events
 * Expense recording, tracking and submittal
 * Expense reporting
 * Document routing & approvals
 * Entry into many accounting systems
 * Peer reviews and notes for any facility (like restaurants or hotels)

Here are some architecture details:
 * Client/Server
 * Supports multiple users
 * Disconnected operation
 * Clients for popular handheld computers running either Linux or PalmOS
 * Synchronization between a handheld and a notebook (or other system) client or directly with a TravelTrack server
 * Single source runs on Linux, MacOS X, Microsoft Windows, Sun Solaris, HP-UX, IBM AIX and Linux based handhelds. This means that each release is immediately available on all supported platforms. (PalmOS version requires separate code tree, unfortunately)

Currently, the basic framework for both the notebook/desktop client and the server components is nearing completion. The database engineering is almost done. Once that is complete, the communications protocol API can be finalized. At that point the only thing remaining is to implement the server-side communications API pieces, the business logic behind the server-side and the client presentation & user interface elements. One other UI task will be to write a separate GUI for the handheld version, for efficient use of that form factor. At this time, the PalmOS client has not been started and may not be available at the time the rest of the application reaches it’s full Alpha test stage. the PalmOS client is a show-stopper item for the Beta release, however.

These features have been suggested and might be considered for future versions:
 * Plug-in clients for Kontact/KOrganizer, Novell Evolution and Mozilla Sunbird PIMs
 * Mapping support, possibly even including a complete GIS database on the TravelTrack server
 * Extending the TravelTrack server Itinerary functionality to become a full-blown calendaring server

Details
In the engineering documents, the full design and set of use cases can be found. These detailed descriptions of each planned function are intended to guide feature development.

Itinerary Tracking
An Itinerary is a compound set of events and data points. For example, when taking a business trip, you need to know several addresses (airport, hotel, customer sites, etc.) and for some of those there will be scheduled appointments or times when you need to be at certain locations.

Existing calendaring software can not link separate events together. An Itinerary in TravelTrack is composed of several events. For example, a flight item can be entered with both departing and returning sets of legs but still be wrapped around other events and appointments can be scheduled between the flights.

Expense Reporting
After entering "Transactions" (take the info from the receipts, of course), the "Pending Transactions" view will list those transactions that have not been assigned to an expense report. Date/time, payees & sub-payees (as in the address of the particular location for multi-site payees), amount, category and (perhaps) a memo can be entered.

When you are ready, check-box the Transactions and click the "Create Expense Report" button. If it looks good, commit it, print and let land on the right desk.

In a later version, committed expense reports will be routed by the system from one person to another gathering digital signatures as it progresses until it finally reaches the system ejection point; that will either print it, export it or push it (into an accounting system).

Facility Notes
Since we are already recording names and addresses of locations being visited, we only need 1 more table with 4 fields in the DB to be able to keep some notes (datetime, personID, text, payeeID). Simply pull up past notes when you are going on a trip and see what your peers think of the hotels, restaurants, attractions and other stores in the area.

= Development Roadmap = The first roadmap that I produced was in a text file (before founding OpenBrainstem). It has been reworked since I decided to change the way TravelTrack's features would be implemented.

We will build the desktop/notebook client to the point where it can operate stand-alone and cover some of the basics. This means that most GUI elements will be available but they may not have all of the business logic behind them yet. At that point, we will finalize the TravelTrack client/server communications API, finish building all the server code and then finish up the last couple of bits in the client.

= Engineering Documents = At OpenBrainstem, we always design first, document second and code third. All the design documents are found on the Engineering Docs page.