Operation Guidelines for QuickBus© and vTrack Systems:

This is system. The button is available throughout the system for information about any particular item in context.

The system is a COMPLETE BUSINESS SYSTEM and can be used in many different business environments. It is operated from a browser on any device that supports a browser with HTML and CSS capability. The System is tested using Windows, Linux and Unix operating systems using Chrome, Opera, Safari, FireFox and Internet Explorer on DeskTop, Tablet and Smartphone. It is designed to be able to be run from a Smartphone and therefore provides a COMPLETELY MOBILE, PAPERLESS AND EFFICIENT OFFICE WITH EXCELLENT SECURITY AND BACKUP FACILITIES using sound business practices and CUSTOMER SERVICE ORIENTATION.

The System can be used by an AGENCY type business which relies on managing Bookings and/or JOBs on behalf of a CLIENT and for allocation to Sub-Contractors for execution.

The System has been built for the Transport Industry and has two versions available. The first is which caters for the operational management of buses for Tours, Charters and School or Urban Schedules and the second is which caters for the management of JOBs (by means of the Booking System) for collection and delivery of vehicles themselves or loads from PickUp to Destination and the location of vehicles and/or plant.

The OFFICE can be used as a simple tool to look after a small part of your daily business or full use can be made of all of the facilities available in the OFFICE . More detailed information can be found as follows:

How to manage your OFFICE by moving from one Section to another... GoTo The Menu Structure.
The System WorkFlow is controlled by three confirmation steps... GoTo Business Integrity.
Enter Customer Booking details to manage quotes and invoices... GoTo Organising a Booking.
Cater for all the requirements to run an effective and profitable business... GoTo Make use of all the Power.
-OR- perhaps you have a lot of friends who own their own buses for charter and/or tours and have a busy website which services other tourist or business needs. In this case you are in a very good position to create your own TOUR AGENCY... GoTo Create an Agency.

No action is taken on any form in QuickBus© until that form is -SAVED-. Any other action button on the screen can be actioned at any time.
The Demo System is a complete OFFICE with two limitations. Firstly any DELETE options are not shown and secondly the -Admin- Section cannot be used. This is done to protect the system data. It is done by making the DEMO system a security level 3 and is the same security level as that which is assigned to Staff which you can assign to your OFFICE as users of the system. This is done in an effort to preserve the demostration data which has been loaded to the system. It is our intention to develop a translation module for so that all customer related forms can be translated into any language which may be required. This will be made available when requested.

Because the system is complete the information loaded can be subject to unsavoury language. We apologise if there is any such data loaded. The full set of demo data is regularly reloaded and updated to ensure that you have as many examples as possible available for viewing and changing to test the results of changes. We have tried our best to make the OFFICE as friendly and error proof as possible. we hope that you enjoy your trip through THE OFFICE .


We would encourage you to REGISTER as an Owner of a fully operational system with the following advantages :

IS COMPLETELY FREE for operators with 5 or less buses

This offer is available until 1st Jan, 2023 to enable us to assist Smaller Bus Operators at this time.
Registration before 1/1/2023 will entitle you to FREE use of the system for as long as you wish.

For operators with more than 6 buses Registration is
-- COMPLETELY FREE FOR A PERIOD OF 60 DAYS. No credit card information requested
-- The System is created without any data other than a default User Parameter File and one entry in each of the system tables.
-- The NEW system starts in TUTORIAL mode and guides the user through the creation of ALL the data, required to run the system, one step at a time in the required sequence.
-- During the Trial Period you have full access to the support team at quickbus77@gmail.com and a telephone number which will be provided to you as soon as the database has been set up for your system.
-- When you are satisfied that meets (and hopefully exceeds) your requirements you GoTo the -Admin- Section and make your first payment using the PayPal button according to the PRICING SCHEDULE below.
-- There are NO CONTRACTs. We hope to be able to provide you with a system with ongoing development guided by your input to the support team AND meeting the needs of your organization which will expand using built for effective Customer Service.

Pricing Schedule:

Pricing schedule :
Buses/Vehicles on-file: 1 to 5 6 to 10 11 to 100 101 to 250 More than 250 vTrack System BOTH Systems
After the FREE 60day Trial.
All data entered is retained
Payment coverts Trial to LIVE
Payments via AdMin/PayPal.
Monthly in ARREARS: FREE A$250 A$500 A$1000 call call call
Tour Bookings (TBL): + A$50 -- ** ** ** **
Ticketing (TBT): + A$50 -- ** ** ** **
Business Links (BWL) + A$50 -- ** ** ** **
Passenger Duty-of-Care (PDC): + A$150 ** Student Checking On-board

** --- These optional facilities available for QuickBus require integration into YOUR specific business requirements and/or website capabilities so please eMail or call QuickBus OFFICE for further information. Thank You.

Discounts are available and will be applied as follows :
IF 3 months payments are submitted for payment NextPaymentDate will be set for 4 months ahead
IF 6 months payments are submitted for payment NextPaymentDate will be set for 9 months ahead
IF 12 months payments are submitted (1 year in advance) NextPaymentDate will be set for 18 months ahead ( 12 months in advance = 18 months service provided.)
If the number of buses on-file increases during the periods of advance payment the pricing increase will only be applied as from the NextPaymentDate.

Impala Distribution and Marketing have taken over the BusWise system and renamed it QuickBus Office (QBO) (www.quickbus.net). The intention is to have a PAPERLESS OFFICE which operates in CONVERSATIONAL MODE by providing one-click access to the USER REFERENCE MANUAL (The Library) and 24/7 SUPPORT.
Contact: quickbus77@gmail.com.
Teamviewer, phone and ZOOM support is available to Registered Users.

The most challenging part of getting any new system up and running is the capturing of existing business data. Even a single-bus operator or a single truck operator frequently has a lot of Customers on-file. Contact support for information about loading your data from any existing computer systems such as spreadsheets to your QuickBus OFFICE .

We would appreciate any recommendations so please tell your friends.
In fact by completing the Registration Form for another business there is a provision at the bottom of the Registration Form for you to add your QuickBus© OFFICE system name and your System ID number. This will flag you as their AGENT and you will then receive a percentage of their monthly payments for the rest of the time that they continue to use the system.
Any existing customer can therefore become a AGENT for QuickBus. Thank you.

Consider the savings provided by the System:
4. Customers can request BOOKINGS or JOBs from their own browsers. You do not need to have staff taking BOOKINGs.
5. Huge time savings as BOOKING, QUOTATION and ACCEPTANCE plus JOB creation, ITINERARIES, RUNSHEETS and JOB management are all done by eMail or ONLINE.


After REGISTERING the system you have FULL ACCESS for 60 days (2 months). When you have decided that the System does work as your complete OFFICE you make the first payment via PayPal with all the securities offered by PayPal (money back guarantees ) and continue to use the System. If you cease payments you will be contacted by Impala to ensure that your system is not closed down by computer for non-payment. On Registration you will receive a mobile telephone number which will be available 24/7 in case of emergencies. eMails will be handled ASAP (normally within 12-15 hours depending on time-zone differences).

Your data backups are controlled from the Admin Section in your system in addition to monthly securities taken automatically onsite AND on our own systems in case of any emergencies. The website used for the operation of has failsafe proceedures to ensure worldwide system security. The site backup is in a different country.
You can request backups of ALL your data on physical DVD at any time for a fee equivalent to 2 months payment of your monthly rental rate.

The payment system is intended to be as simple and as affordable as possible. A significant advantage of QuickBus© is that it automatically grows to accomodate an expanding business.

Address Table:

Address Section :

The ADDRESS table in is a very powerful business tool. The table is created for each user. It is your own local reference table to the Google Address system holding additional information about the addresses such as names (LOCAL Places of Interest Names, buildings, school sports fields ) PLUS notes. The OFFICE refers to the Google GPS locations which are used for calculating distances and trip times. These calculations are used by the ITINERARY Table associated with a Booking.

When Address task SELECT button is chosen the first option for selecting an address is the Address by Address Name list. The list presents the address references sorted by address name and provides the street name, street number, suburb, state, postcode followed by the address name (POI) if there is one and the the system ID number for that Address
The Address Table can be displayed for selection in any of three structures and sort-orders. These -SELECT- options can be changed for most of the -SELECT- tasks by setting the Options in -Admin-, -EDIT_PARM-, The sequence for ..... Should you find this option is not available for a apticulat -SELECT- Address in the system please email support and we will have the parameter setting option included.

NEW can be clicked without selecting a specific address to enable the loading of a NEW address to the Address table.
REPORTS can also be clicked without selecting a specific address because the the REPORTS cover all the addresses on-file.

The rest require an address to be selected THEN : VIEW displays all the details about an address as a form.
MAP displays a Google MAP for that address provided it is a valid Google Address.
EDIT displays the Address form with the ability to SAVE the changes.

The Address Records:

Addresses are loaded to the system clicking Address task then NEW .

Use the Google Auto Address finder:
Enter an address in the form that would be placed on the face of an envelope as StreetNumber followed by StreetName. As the entry is made the system will show a list of the addresses closest to the information entered so far. Skipping the suburb and adding the state will usually include suburbs in the list. When the correct address has been listed, click on that address in the list to SELECT it. The selected address will be loaded into the form. Google can become confused with Places, Point of Interest or building names so these can be added to the form as an address name. The UNIT NUMBERS are not catered for by GOOGLE (as at June 2019 anyway) and can be added to the form after selection from the list.

The address location ( as a longitude and latitude ) is added to the local address table by making use of the MAP. See __ Location Informtaion.

To explain the layout of the FORM we will use the following address :
Unit 3, 54 Short St, Slacks Creek 4127 Australia

Unit :
Alphanumeric (8 char) as 54.
Street No :
Alphanumeric (10 char) as 3.
**Street Name :
Alphanumeric (70 char) as Short St. Take care with St vs Street, vs Lane, vs Road. The tendency with GPS systems and Google is to use the long form.
**Suburb :
Alphanumeric (40 char) SPECIFIC Suburb is required rather than city, town or division name. This is where Google is particularly good because there is often confusion as to the official suburb name. Example: Slacks Creek rather than Brisbane.
**State :
Alphanumeric (4 char) as QLD, NSW (Australia) or NY, DC (USA) ..
P/Code :
Alphanumeric (6 char). Google does a good job of providing correct postal codes for addresses. Postal codes are not specifically used by the System.
Country :
Alphanumeric (32 char). The System will normally default the Country Code with that entered into the Registration Form.
Point_of_interest or AddressName:
Alphanumeric (40 char). See __ AddressName /Local Named Address POI: Be very specific when using the Address Name field because it is used as a sorting field when listing Addresses by Address NAME rather than by STREET NAME. NEVER put a customers name in this field. This is why Customers have Primary Address details. If there is ever a need to look up a Customers Address this should be done by using the Customer task. The Customers Primary Addresses ARE available in the ADDRESS by STREET NAME lists in case a Customer wishes to use their Primary Address as a PickUp address
Address Notes :
1024 characters of any information which may be relevant to this address. These notes will be shown on the DRIVER RUNSHEET. Example: Do NOT park vehicles in the front of this address. Heavy fines.

Validating Address Records:

Invalid addresses only affect the ability of the ITINERARY for a Booking to provide time and distance calculations. If the address is workable and can be used to find a location it is not necessary to validate the address (Use the MAP to SET the location).

If an ADDRESS is loaded to the system manually then it is possible that the address is not found by Google Maps. The only limitation of having an address on-file which cannot be recognised by Google is that the ITINERY Table will not be able to provide time and distance information.

There are three main reasons for keeping your own Address Table :
Enter common addresses ONCE only:
This is particularly significant when a customer makes use of your QUOTE/JOB REQUEST SYSTEM. The QRS provides the customer with a list of addresses for selection instead of having to retype the complete address into Google Auto Address. When a new address is added to the system a NAME can be associated with that address. Example: XYZ College Sports Fields. All NEW addresses should be saved for future use.
HUGE time saving in completing Forms (eg Booking Form):
All Forms in that need an address provide selection lists for ADDRESSES in both StreetName and AddressName sequence. This saves the re-entry of an address each time it is needed. The Table is a bit tedious to build BUT the benefits to you and the Customer are SIGNIFICANT. (Customer Service).
The ITINERARY Calculator and Valid Addresses:
When using the Google Auto Addresss the address that is selected from the list provided is stored in the address form. This address, because it is from the extremely co-ordinated and useful Google databases, is a VALID address for the system. This means that using Address (select an address) then MAP , is able to present a MAP for that Address. The system shows both the address from the local address table as well as the address from the Google Address System including the latitude and the longitude. This lat and lng information is what is needed by the ITINERARY to calculate distance and time from one address to the next. See __ Location Informtion.

AddressName /Local Named Address POI:

The address name is your most powerful asset in the System. This enables you to store all addresses that are important to you and provide the address with a name.

NOTE : You never need to provide a Customer (as a person) with the Customers name in the NAME / POI of the address record. Every Customer has a primary address attached to his Customer record and wherever this address is of significance the System will display the address with the Customers name. In addition this would be a breach of the Customers privacy.

This name is referred to as a POI (Point-of-Interst) when it is the name of a tourist attraction or a significant building or location. When we last tried to find the Sydney Opera House in the Auto Address search we had no success. So entering the address in full as a street name reference (understood by Google Maps ) and adding the Sydney Opera House as the NAME will make selection of this location very easy each time it is needed for Booking entries ....

Such addresses as XYZ College Sportsfield or Opera House Parking will prove very useful. This will be especially useful to Customers who use the Quote Request System available to YOUR SYSTEM. The Address Table only has to be entered ONCE.

Valid Google addresses (MAP)

Non-validated addresses only affect the ability of the ITINERARY for a Booking to provide time and distance calculations. If the address is workable and can be used to find a location and the ITINERARY calculations are not required, there is no reason to validate it. An address can be -SET- as validated when a meaningful MAP can be displayed after selecting the Address in the Address Section. Addressses that are marked with ** in the Address lists for selection are not validated addresses for the purpose of the Itinerary calculations and cannot be used by a driver as a navigation assistant. When a NEW address is -SAVEd- it should be validated using the -MAP- and confirmed as validated by selecting -SET- when the map is being displayed.
The SET_ALL_MAPS button ( not available for the DEMO System) will -RESET- all of the addresses in the file. This task is not completely consistent (We believe that this is a Google Code function but will continue to try and find a solution in our code. Sorry.) This may therefore -UNSET- some addresses so it should not be used indiscriminately. If these were valid before then use -MAP- on THAT address and -SET- the locations again.

If the address has ** in the Address task Select button then the address has not been -SET- yet and the ITINERARY cannot calculate costs for a Booking. These costs serve as a very useful guide for calculating QUOTES or as a cost-of-business guide to assess the difference between driver hours vs. cost-per-kilometer.

A message is shown in the information box when requesting a MAP or Google may display a weird MAP. This weird MAP can sometimes be -Out of the blue- or a MAP in the wrong country (often somewhere in the USA).
When this weird MAP is displayed that address should always be UNSET. If this address is likely to be selected for a Booking and the ITINERARY table is used for calculating costs then that address should be corrected.

When a valid MAP is displayed then that MAP should be SET for that address. The latitude and longitude (as displayed by the Google address at the bottom of the screen) will be loaded to the Address Table and when selected for the ITINERARY table in a Booking the System will be able to provide cost calculations for time and distance from one Address to the next. This will also ensure that the lists provided for selecting the addresses are no longer flagged with ** (two asterisks).

Addresses can be corrected by using Address task / EDIT button until a valid MAP is displayed and then the Address MAP can be SET.

However this can be a somewhat tedious method and an more certain way of doing this is as follows :
(This technique should only be used by advanced computer users as it is pretty complex).

Most browsers allow you to open a duplicate screen. For Chrome as at Mar 2019 the following process works : right-click on the TAG at the very top of the browser screen. Usually this will request Confirm Form Resubmission. Right-click again and select Reload. This will open another copy of your system. THEN :
Click Address task then NEW button . In the Auto Address field start off by typing just the StreetName. This should produce an list including the correct suburb . Add your number in the front to check that it is acceptable. Google does not always have a street number recorded in its databases. Select from the list. and if it all gets loaded into the form brush (run the cursor over the address with left button pressed on the mouse ) and CNTRL and C to copy the address. Close this duplicate screen. Open Notepad or similar text editor and paste (CNTRL and V) the address in the note. Return to your original EDIT screen and copy and paste each part of the address into your form. THEN SAVE.

This process caters for correcting an address which is the Primary Address for a Customer because the ID number of the address MUST STAY linked to that Customer. If the address is deleted then the link to the Customer will be broken.

If the address is not a Primary Address for a Customer it may still be associated with a Booking and presents the same challenge.

Address Locations SET and UNSET.

When Address task then SELECT button is chosen one of the options is the MAP .
This will displays a MAP of that address provided that the address is valid.
Invalid addresses are unpredictable as this varies with updates made by Google ©
At the bottom of the map the Address as loaded to the QuickBus© Address Table is displayed in full and below that is the complete address as resolved by Google. The important part of the Google Address is the latitude and longitude provided.
If the MAP is meaningful and the address is complete then the Lat./lng should be loaded to the address table as a VALID address by clicking SET else click UNSET. When the address NOT SET it will NOT be used in the distance and cost calculations provided by the ITINERARY.

Occasionally an invalid MAP is displayed when the address IS VALID. Rerunning the MAP will frequenly resolve this problem.

Otherwise the Address should be -Edited- until such time as it is correct. The -EDIT- action provides the ability to enter the address into the Address finder until such time as a correct address is displayed.


BOOKING Section :

The objective of the OFFICE is to ensure that the best business practices are employed to ensure the accurate saving of essential business data and the best possible CUSTOMER SERVICE. To achieve this objective we need to treat the collection and handling of data to be the highest priority. the next priority is to ensure that information (data) is only entered once and then re-used for all the necessary purposes of running the OFFICE . AND to achieve these objectives in the most efficient way we also need to ensure that the actions to be taken by the user are as logical and sequential as possible.
With these design objectives in mind the OFFICE Main Menu, which is at the top of all the major tasks, has been sequenced from left to right with the most to least used sections. The user can bale out of ANY screen by just going to any SECTION on the Main Menu.
Each SECTION has its own Tasks that can be accomplished within that SECTION. These are on the Task Menu: at the top of that Task.

Every SECTION has the first Task as -SELECT- so that the user is always presented with a screen to enable the selection of data for that task presented in alphabetic sequence. If there are a large number of items available for selection press the appropriate alpha key on the keyboard and the list will select the first (or closest) item for that key in the list.
The most frequent use of the system will require the selection of a data item from the list followed by an action as chosen from the Task Menu: that needs to be carried out on the selected item. This BOOKING SECTION, being the heart of the OFFICE , has a large number of Tasks available:
After a Specific (Existing) Booking is SELECTED then that Booking can be:
Edited, changed and managed from the PlanSheet
All of the data management actions and Booking information is entered via the PLANNING SHEET. The PLANNING SHEET is the most signicificant form for managing the business. The Planning SHEET has Edit buttons available for every piece of information to contruct a comprehensive Booking Form so as to make it possible to ensure that all potential variations of a Booking are catered for. This includes the ITINERARY TABLE which has its own editing functions to build a fully detailed tour or school bus schedule or similar. The -RECALC- option for the ITINERARY TABLE will calculate the distance and time costs for that ITINERARY to facilitate the preparation of QUOTES.

The Booking is viewed in summary form using VIEW . The -VIEW- is a much simpler presentation of the BOOKING. The VIEW includes all the JOBs required for that Booking once the Booking has been completely planned, checked and -CONFIRMED-.
A -PlanSheet- and -VIEW- button has also been placed below the SELECTION List for ease of use.

-OR- you can GoTo:
Which provides the NEW BOOKING Form to create a new Booking. -OR-
Booking REPORTS :
Select from the range of REPORTS that are available for ALL the Bookings rather than documents or reports related to a selected Bookings.

Further Actions available for a SELECTED BOOKING:
Notes can be ADDED to the Booking with ADDNOTE

AFTER ALL information and processing details have been defined and checked the Booking can be CONFIRM ed. This will secure the Booking. No further changes can be made to the Booking except for the ITINERARY TABLE. JOBs will be created to ensure that the Booking is properly executed on the correct date and at the correct time by means of the Daily Diary which is part of DailyDiary SECTION. The accounting transactions will also be completed to the Ledgers and the Customer (or CLIENT) accounts.

The RECEIPT Task is used to issue a RECEIPT to a customer as related to the selected Booking. A receipt can also be issued to a customer from the PlanSheet. This would be used for payments made before the Booking is -CONFIRMed- such as intial payments or deposits.

Receipts could also be issued as negative credits by means of Journals but the JOURNAL Task is intended for DEBITS against selected Booking as charges to Customers (or CLIENTS) for charges that are made subsequent to a QUOTE such as damages to buses etc..

A number of business documents are available for display -OR- eMail these includes QUOTE , INVOICE or ITINERARY from a selected Booking. The eMail address for these documents defaults to the Customer or the CLIENT depending on the type of Booking.

-OR- if the Booking has been sub-contracted to a SUBBY then a QuoteRequest, WorkOrder ( = RUNSHEET for s Driver ) or PayMent could be required for a the SUBBY for any Booking assigned to the SUBBY.


The business process starts with the creation of a Booking and the COMPLETE BUSINESS PROCESS is defined by using all of the EDIT capabilities available on the PlanSheet. The PlanSheet identifies any combination of special conditions or options which can be applied to a Booking. Each option on the PlanSheet has a separate help button to explain the purpose of the option and an EDitxxx button to GoTo the edit/update screen for that particular option. The PlanSheet ensures that every aspect of a Booking is catered for and when - CONFIRMed - that Booking defines the JOBs for the DailyDiary (= WorkSheet) as well as the financial transactions necessary to control the CASHFLOW of the Business.
The -VIEW- displays a Booking in a more detailed but summary form. The -VIEW- does not cater for making any changes to a Booking the -EDIT- task must be used to do this.

Before selecting a Customer or an Address check the respective lists to ensure that the address is on-file and available for selection. If this is the first time for either then the new customer and/or address should be added to the files by using Add Customer or Add Address.
When a NEW CUSTOMER and/or NEW ADDRESS has been added return to Booking then NEW and select a CUSTOMER and a new PickUp Address from the address list and then the new Destination Address.

A Booking is controlled entirely by its ID number so that ANY of the information on the Booking can be changed (except the ID) on the PlanSheet until the Booking is -CONFIRMED-. After a BOOKING is -CONFIRMED- the PlanSheet cannot be edited. A BOOKING CAN, however, BE - DUPLICATED - AFTER IT HAS BEEN CONFIRMED.
Select Customer Name :
This is mandatory.
Select PICKUP Address :
This is mandatory.
Select Destination Address:
This is mandatory. In the case of multiple-stops being required for a Booking the multiple-stops will be entered into the ITINERARY. The ITINERARY is an optional route schedule which is a section of the PlanSheet. Select the furthest StopOver address as the destination.
Otherwise The DropOff or the FINAL DESTINATION should be selected at this time.

When all of the required details have been entered the NEXT button must be clicked. The selections will create a Provisional Booking with : Customer Name: as selected
PickUp and Destination addresses as selected
An ITINERARY will be created assuming a driver is collecting a bus from the DEPOT, going to PickUp to collect pax and then going to the Destination. From the Destination the route will return to the DEPOT via the PickUp address.
The times from DEPOT to PickUp and PickUp return to DEPOT will default to 15mins.
If no amount has been entered into the initial Quote Value then there will be no financial transactions prepared and the Booking will be zero value.

Once a Provisional Booking has been created the - PlanSheet - then becomes the document that sets up all aspects of the Booking for the business process.


The business process is explained in the System WorkFlow

THE PlanSheet:


The Booking Name is the NAME associated with any specific Booking. The OFFICE gives the Booking an ID when it is created. When the Booking Section is opened the first requirement is to SELECT the Booking that is going to be actioned / processed.
The list that is provided for SELECTing a Booking is an alphabetic list of ALL the Booking Names. The Booking Name is therefore the the method used to find a Booking. The NAME should be structured to make this task as easy as possible. This NAME can be set up when creating a Provisional Booking and should be structured starting with the customers name followed by a very brief description of the Booking details such as PickUp address to Destination address or Tour identification number if it is to be a Tour.

The Quote Request structures a Booking Name as
-- QRS then QRSID then for CustomerName CustomerIDnumber ---
so that it is recognizable as a Booking from a Quote when it is accepted as a Booking from the Quotes Section.
This should be tidied up when the PlanSheet is first run.

CUSTOMER Allocation:

The Customer Allocation is used in Bookings. The Allocation defines the way that the Booking handles Documents, eMails and Financial Transactions.
The Financial transactions require management of the Accounting details as associated with the Customer Allocation specified in the PlanSheet.
All Financial transactions are created when a Booking is -CONFIRMED- .
FOR ALL ALLOCATIONS OTHER THAN Type 0 (NORMAL) a Customer must be associated with the allocation selected.

(Type 0) NORMAL : All financial transactions are for the Customer account. Booking is managed IN-HOUSE via JOBs on DailyDiary. All Documents (Quotes, Invoices .) are directed to the Customer by default.

(Type 1) contact Person / Person of Interest : Is a Person/Customer who needs to be kept informed of any problems. Booking is still NORMAL. Only used for reference or if there are any problems. All Documents (Quotes, Invoices ) are directed to the Customer by default BUT copies can/should be sent to this person by redirecting the eMail. This is particularly relevant to ITINERARY.
All financial transactions are for the Customer account.

(Type 2) CLIENT --- The Person / Customer who is identified as a CLIENT :
Booking is being managed IN-HOUSE on behalf of this CLIENT for the Customer.
Any person on the Customer List can be a CLIENT.
All Documents (Quotes, Invoices .) are directed to the CLIENT by default.
All financial transactions are for the CLIENT account. ---
Copies of relevant documents can/should be sent to the Customer by redirecting the eMail.

(Type 3) The Booking is assigned to the selected SUBBY.

A Booking cannot be assigned to a SUBBY if it is being done on behalf of a CLIENT.

The Complete BOOKING is assigned to a SUB-CONTRACTOR.
Any Customer can be a SUBBY BUT must be identified as such in the Customer File.
No JOBs will be produced for the DAILY DIARY because the responsibility of managing the Booking belongs to the SUBBY. If the booking is being executed for a Customer on behalf of a CLIENT -OR- you wish to oversee the execution of the Booking ( the Customer may be a VIP ) then the Booking should NOT be assigned to a SUBBY. Flag the fact that the Booking will be managed by a SUBBY in the NOTES and then assign ALL the JOBs associated with this Booking to the SUBBY. This is done in DailyDiary (WorkSheet) on the day of the Booking.
All Documents (Quotes, Invoices .) are still directed to the Customer.
Additional financial transactions are for the SUBBY account. The SUBBY must be paid for his services. The amount to be paid to the SUBBY can entered into the SUBBY Allocation in Financial Details of a Booking and the System will automatically prepare accounting transactions for the SUBBY account. Otherwise these payments will need to be made by Journal Entries for the SUBBY ( via Cust / Journal ).

PickUp Address:

A BOOKING is not valid (able to be confirmed) until it has a PickUp Address.

The PickUp address is where the driver must take the vehicle to pick up the passengers -OR- where the driver the driver must PickUp a vehicle if there is not Collect-the-vehicle entry on the Itinerary. If there is No Itinerary prepared then the former applies.


A BOOKING is not valid (able to be confirmed) until it has a Destination Address.

The significance of the Booking is defined by the Type of Destination that has been selected. It may be appropriate to refer to the Library for Operations Section to understand the significance of the information that is prepared for Operations to ensure that the complete business can be run from the Operations and the JOBs structured for that time on that day. The JOBs are used to prepare RUNSHEETS, workOrders and drivers rosters. The System will always use the Destination Type and refer to the ITINERARY for the preparation of JOBs if an ITINERARY has been prepared.
The PLANNING SHEET describes ALL the JOBs that will be created from the use of the Booking Details: Start and End, date and time, the PickUp address,the Destination Type, the Destination and the ITINERARY. Test the effect that changes to these entries make by repeated -EDITS- on the PLANNING SHEET.

There are 4 different methods that QuickBus© can use Destination to create JOBs:
TripType__0 : NORMAL (default):
The default Destination type is NORMAL and the Provisional Booking is created with Type = 0.
All JOBs are created assuming that the Destination is where the group is going and the driver will either wait for the group at the Destination and return them to PickUp or return to the Destination later to pick up and return to the PickUp address or as may otherwise be defined in the NOTES for the Booking and/or notes that may be made for the JOB on the Operations ( which caters for last minute changes or problems ).
In the case of vTrack the destination is where the vehicle will end its trip so the vehicle location is moved from the PickUp address to the Destination address and plans must be made to return the driver to base if necessary..
TripType__1 : EXTENDED/TOUR:
This Destination type assumes that the Booking is for a TOUR. Remember that a Booking can be duplicated to ensure a very quick process for transferring ALL the information from one Booking to another particularly if the Booking is complex and/or similar. Example: School runs and Urban Routes.
The Destination is the FURTHEST stopping address / Drop-Off address for the Tour. This Type would benefit from the planning and information / calculations provided by the ITINERARY which would also faciltate the identification of the FINAL Destination.
The furthest Destination is recommended for all Customers in the Quote Request Form. When they have multiple stops or DroOff addresses it makes the Quote Request a lot easier to assess.
In this case the System uses the Itierary to contruct the JOBs especially if it is a MUlti-day JOB.
TripType__2 : TRANSFER:
This assumes that the Destination is where the Passengers will be delivered and the vehicle will return to the primary DEPOT address.
Information becomes significant when the System needs to create multiple JOBs for multiple days.
TripType__3 : SPLIT:
This could be a one-day JOB but has more significance for multi-day JOBs.
This Type specifies that the vehicle will be driven to the Destination where the passengers will be off-loaded. The vehicle will return to BASE (DEPOT). At some later time (and date if appropriate) the vehicle will return to the Destination to collect the group and return them to the PickUp address.

The ITINERARY (Normal = no calcs):

The ITINERARY is an optional facility and all Bookings/Jobs could be handled using the PickUp address, the Destination Address and the NOTES. without the ITINERARY
The Itinerary is intended to provide 1) A fully fledged Itinerary Table for customers who may require this for planning, passenger control or reference, 2) To provide Drivers with complex RUNSHEET information (eg Tours, School or urban Routes) AND 3) Cost calculations when required for Bookings. HOWEVER

The ITINERARY provides a very powerful business tool.

The Planning Sheet includes the ITINERARY with the cost calculator. The additional features and options are described below.

ITINERARY and Travel Information : with Booking ID

Notes and comments as entered.
This is the reference number that is allocated to that row of the ITINERARY. When a -NEW- Booking is saved ( -NEXT- ) the system creates a comprehensive ITINERARY which assumes that a driver will collect his vehicle from the main DEPOT, travel to the PickUp to collect passengers, travel to the destination, wait at the destination until passengers are ready to return to the PIckUp and then return to the DEPOT.
This could be an overkill for most Bookings but the rows are very easy to delete.
The addresses are as selected from the Address Table for each row.
The Seq is the number of the rows as they are listed and would effectively be the stops that would be made for the trip in sequence.

ITINERARY with Calculator:

The ITINERARY is an optional facility and all Bookings/Jobs could be handled using the PickUp address, the Destination Address and the NOTES. without the ITINERARY

The ITINERARY provides a very powerful business tool.

Before a Booking has been -CONFIRMED- the Planning Sheet includes the ITINERARY with the cost calculator and the ability to change or rebuild the ITINERARY.

ITINERARY and Travel Information :
with Booking ID and Q: total of all allocations = quote total.

Notes and comments as entered when ITINERARY is edited.
This is the reference number that is allocated to that row of the ITINERARY. When a -NEW- Booking is saved ( -NEXT- ) the system creates a comprehensive ITINERARY which assumes :
a) driver will collect his vehicle from the main DEPOT (-Ref- 1)
b) travel to the PickUp to collect passengers (-Ref- 2)
c) travel to the destination (-Ref- 55 ) This caters for the easy insertion of up to 50 additional PickUp points before the driver heads off to the destination
d) wait at the destination until passengers are ready to return to the PIckUp unless special instructions are entered in the Comments.
e) return to the PickUp to DropOff the passengers (-Ref- 56) and
f) return to the DEPOT (Ref- 57).
This could be an overkill for most Bookings but the rows are very easy to delete if they are not required.
The addresses are as selected from the Address Table for each row. Addresses must be in the Address Table to be selected.
The Seq is the number of the rows as they are listed and would effectively be the stops that would be made for the trip in sequence.

Calculation Information:

These columns are included with the ITINERARY Table when the calculation can be used. If A Booking is -CONFIRMED- they will not be shown. They are also not shown when a -VIEW- is requested for a Booking.
hr:min @
This is the time in Hours and minutes that it would take to travel from the previous row to this one. The first row would be 0.00 and any invalid Address would also create a 0.00 time.
Value of Drivers Time from the previous -Ref- to this one.
Km @
This is the distance in Kilometers from the previous row to this one. The first row would be 0.00 and any invalid Address would also create a 0.00 distance.
Value of the distance calculation using value from User Parameter file.

Editing the ITINERARY:

ANY change to the ITINERARY requires a -Ref- number to be actioned unless the entire ITINERARY is to be deleted. Entering ALL as a -Ref- and then REMOVE will delete all rows from the ITINERARY. and the complete ITINERARY can be rebuilt row by row.
Enter the number of a row to process (from 1 to 900 ) and THEN
CHANGE Will replace the information for that row.

REMOVE (without the -Ref- = ALL ) will remove that row from the ITINERARY

_INSERT_ Will insert that -Ref- as a new row with that -Ref- number. If that -Ref- number already exists then that -Ref- number plus all -Ref- numbers after that number will be increased by 1 (existing -Ref- number plus 1 ).

RECALC RECALC cannot calculate the distance and time from one invalid address to another address. If the Address is maked with ** (double asterisk) then that address is invalid. An invalid address is an address not recognised by Google MAPs and thus does not have a latitude and longtitude SET into the Address. See : Validating Address Records for more information.
When -RECALC- is selected the system recalculates all the information in the last 5 colums of the ITINERARY Table.

When a -RECALC- is requested there is an additional facility which adds a number of minutes to each PickUp time on the Itinerary Table. GoTo : Additional PickUp Time Allowance for more information.

PlanSheet Reloads the PlanSheet for that Booking. SAVE_CHANGES


The GRADE is a sort key provided for the system owner to facilitate a match of BOOKINGs to Buses / Vehicles and Drivers. The value of this key is entirely up to the user. The 3 character key represents the VIP value in terms of Bookings, the quality value in terms of Buses/Vehicles and expertise or experience (or both) in terms of Drivers.
The system defaults to 555 or blank. The field is not evaluated for data entry purposes and alpha can also be used. The three caharcters could be used to identify specific attributes of the resource.
In general a value of 555 for a driver would be a driver who can drive any bus which is certified as 555 or less. He would be a general all rounder and would be able to be allocated to pretty well any job. If he had been with the company for 10 years and held the highest driver licence available in the country he could be rated as 777. If he was a relatively new driver, with 3 months experience and a limited drivers licence ( MR with auto only ) for example he may be rated as 333.
A bus that was only used in emergencies and had no seat belts or air would be rated as a 222. A school bus that was in good condition with belts and air but not ideal for charter groups would be rated 333. And a supermlong-distane coach would be rated 777.
A normal good customer that was a reasonable payer and used the service of the company quite regularly would be rated 555. But a lousy paying customer would be rated as 222. And a really fussy customer that required EXCELLENT service and the best busses could be rated as 666

This structure is entriely up to the user and would probably not be used by operators of smaller organisations.

Booking Details:

All of the BASIC requirements to manage a Booking are provided by completing all of the details for a -NEW- Booking. HOWEVER if more sophisticated business tolls are required then this section of the Planning Sheet should be completed:
Booking Name:
The Booking Name is very important for selecting Bookings from the List of Bookings to do additional processing or making changes. The list of names is presented to enable the SELECTION of a Booking.
Resources Required:
The number of passengers is very important for selecting a suitable BUS for the Booking. There are times when a Customer may require a number of buses because the trip is split into sections. If there are a large number of passengers then multiple-buses will be required. The number of buses is very important because when JOBs are created by the System for the Operations (DailyDiary) then it is necessary to have a JOB for each bus for each day so that buses and drivers can be allocated appropriately.

For the vTrack system passengers is replaced by tonnage. And there may be a convoy of many vehicles required for a transport company that specialises in ferrying vehicles.

The GRADE is explained just above this section.
Dates and times are very important for Bookings. The dates can be entered using the SmatDate which saves a lot of time or the calendars can be used. In the case of entries made using a SmatPhone the calendars are not very useful and the QuickDate should be used. Click on the help-button next to a date field for the explanation of the QuickDate.
DATE exclusions:
The ITINERARY table enables the preparation of complex route schedules which could be used for School or Urban bus routes. The START / END date for such a route could be over a period of a month or a quarter or even a Year. Such a route could be for weekdays only over that monthly period (or School term perhaps) and in this case Sun and Sat would be ticked as a exclusion. The JOBs for that route would then be prepared for Mon-Fri for each day of the period. If the route was a weekend route only the Mon thru Fri would all be excluded. This facilty used with the ability to DUPLICATE the Booking Form makes the preparation of multiple school schedules a very easy task especially as all the Timing-Points ( Stops ) for the route can all be loaded to the Address Table for selection and the ITINERARY can then give you a costing estimate for that route.
Destination Options/Types:
Complex trips with multiple stops and detours could be covered by the use of the Booking Notes and/or the notes which can be entered on the JOBs but this requires a great deal of attention to detail and the trust that the notes will be read and understood. These complex options have however been catered for by the the 4 types of destantion offered by the System. This means that the System is able to compile meaningful JOBs for display on the Operations and for the Driver's RUNSHEETs.

The Destination Options can be changed with the Destination details.
The options that are available are defined below.
Time Allowances:
When a NEW Booking is entered ( and -NEXT- is pressed ) the System creates a complex ITINERARY Table for the NEW Booking. This is an overkill in most cases but it is created with all the likely vehicle movements so that those that are not required can be deleted. The ITINERARY is therefore accurate for all the times and distances times.

These Time Allowances cater for the times that it will take from DEPOT to PickUp and final Destination to return to DEPOT for the drivers RUNSHEETS. These times need to ne separately loaded because the ITINERARY may not be used and these times are very important to ensure that a DRIVER can maintain accurate time schedules.
For a company that has one bus which does MOST of the work then this prealloaction can be loaded to the Users Parameter File so that all JOBs use the Bus. It is a very easy task to change the allocated buses/drivers for the JObs on the Operations .
This preallocation can be loaded her for a specific Booking because it saves time allocatng buses and drivers for the JOBs on the Operations .
It also saves later entries for Bookings that a fixed routes and have a specific bus and driver allocated to them most of the time. Particularly if the Booking is one that will be duplicated.


Destination Type :
These re-define how QuickBus uses the END Date/Time on the Booking:

-0- NORMAL :
Arrival at the Destination. For Multiple days each day is considered as a separate day. Suited to schedules for school runs or tours run on a regular basis. End of JOB will be Dest + Dest to Depot Time Allowance.
NOTE: The EXCLUDING/INCLUDING days of the week tables apply to NORMAL Multi-DAY Bookings.
Single day will be changed to -NORMAL- each time -EDIT- is run. Intended for multi-day trips where the resources (bus + driver) will be away overnight. Destination should be the furthest point on the schedule to be meaningful. End of TRIP will be as entered in END DATE/Time. Arrival/Departure at Dest and any intermediate stops should be entered and evaluated using the Itinerary. The Itinerary will provided time and distance between each stop if Addresses have been validated.
End Date/Time is End of TRIP. If vehicle is to return to the Depot (or some other Address) then the DropOff to Return time should be entered into the RUNSHEET Travel Time Provision for Destination to Depot. This time is in minutes. The max value is 9999 to cater for Multi-day trip returns.
-3- SPLIT :
The END Date/Time for a -SPLIT- Destination Type is the date and time that the vehicle is intended to COLLECT passengers for the RETURN TRIP to the PickUp address. This works fine for Multi-Day -SPLIT- runs. In this case the RUNSHEET Travel Time Provision for Destination to Depot should specify the time in minutes from the DESTINATION to the DEPOT (ie PickUp-to-Destination and Destination-to-PickUp time ) to ensure accuracy on the RUNSHEETS. NOTE: A -SPLIT- Run will always produce TWO JOBs to enable the use of different resources for the return trip if required. Any variation or special conditions should be entered in notes or built into an ITINERARY.


To ensure that RUNSHEETS can be accurately prepared for the DRIVERS it may be appropriate to provide the times in minutes from the DEPOT to the PIckUp Point and from the final Destination back to the DEPOT. These can be calculated using the ITINERARY and then added to the PLanning Sheet. The RUNSHEET does not have access to the ITINERARY Table directly. To incorporate this in the system would entail too many rules and conditions on the compilation of the ITINERARY.

Booking Notes:

Booking NOTES provides 1024 characters of any and all informtion which may ensure better customer service. A better experience for the Customer. Example: Remember to take the trailer on the bus. Take the barbecue. Pick up the beer form Jacks Bottle Store. Ensure Jenny Marlow-Jones is always present on the bus.
If a Booking is being taken in a hurry and you do not want to delay the customer any more that necessary then ensure that you have ALL the CORRECT details for the Customer, the PickUp Address and the Destination Address (furthest address for a tour), SELECT these three items of information the click on NEXT and go to ADDNOTE where you can write up ALL the information about the tour and sort it out into the Planning Sheet at a later time.


The Pre-allocation can be setup as a User Paramater in the Admin Section. This creates a default which will be loaded to each any every Booking. This is useful if you have one bus that does most of the work. It is very easy to change this on the JOB at a later date.
Each JOB will be allocated with Bus and Driver when the Booking is -CONFIRMed-.
The next level of Pre-Allocation is on the Planning Sheet. For multi-day Bookings the FIRST BUS and/or driver for each day will be Preallocated
The Pre allocation can be changed or removed here AND/OR on the JOBs from the Daily/Diary before the RUNSHEETS (or DailyDiarys for SUBBYs) are displayed, printed or emailed. Pre-allocation saves a lot of work with the JOBs and can be easily changed later
A RUNSHEET cannot be printed without both Driver and Bus/Vehicle being allocated.
This ensures business integrity and that the Business Log Books are complete.


When a NEW BOOKING is prepared there is a need for Quote information to be loaded so that a QUOTE can be sent to the Customer for acceptance and confirmation. This is called the INITIAL Quote Estimate (Main) and is a single value for the Booking.
If no further changes are made to this amount then the System will credit this amount to the Booking Ledger and debit it to the Customer ( or the CLIENT if the booking is being made on behalf of a CLIENT ) whether the accounting information is used later or not.
However when a more sophisticated accounting system is required then the FINANCIALS for the Booking can be modified via the EditFinancials button of the Planning Sheet.
The INITIAL Quote Estimate is placed in the Main field. The total Quote amount for a Booking is Main plus CLIENT plus DRIVER plus SUBBY.

The EXTRAS are always shown as a separate amount throughout the system and are intended to cater for additional costs that are not part of the initial quote. These EXTRAS cater for such items as tolls or any other expenses which are not subject to the GST which may apply to the Booking. Example: later charges to a Customer for damage caused to a bus. These are always reflected as an extra charge on the Booking for INVOICES or QUOTES and reports.
SUBBY has a special significance. If a ENTIRE Booking is going to be handed to a SUB-CONTACTOR then this amount is what will be paid to the SUBBY. This amount would need to be subtracted from the Main amount because remember that the TOTAL QUOTE = Main + SUBBY + DRIVER + CLIENT. When the Booking is -CONFIRMED- the TOTAL Quote amount will be credited to the Booking Ledger, and the TOTAL will be debited to the Customer or CLIENT account BUT in addition the SUBBY account will be credited with the SUBBY Amount and the General Leger will be debited with amount. As RECEIPTS are issed for hese various transactions the financials will all be balanced out.

At this time the DRIVER and CLIENT fields are intended to be used however you may desire to keep track of the drivers share of the booking or the commission you may wish to withhold from the client. Always bearing in mind TOTAL QUOTE = Main + SUBBY + DRIVER + CLIENT excluding Extras.

This form also caters for ISSUE RECEIPT for Cust BEFORE THE BOOKING IS CONFIRMED. These receipts are therefore more in terms of deposits and/or prepayments for the Booking. Enter the amount paid. The last receipt number and the last aount paid is shown for interest and control. The receipt number for this payment should be entered either as last receipt number + 1 or the receipt number from a recipt book which is used in your OFFICE for your banking purposed. an INVOICE should now be sent to the Customer because it will reflect the exact status of the account including this last receipt number and payment.

CHANGE Payment Terms shows the current terms that have been agreed with the Customer. If necessary these can be changed as required BUT the payment due date should always be corrected to reflect the latest status. This date has particular significance on the payment oustanding reports if they are used.


This feature is very useful for repeat bookings.
Example 1 : a customer who has a outing once a month and all that needs to be changed on the duplicate is the destination, dates and time.
Example 2 : A school route with a very comprehensive ITINERAY which includes the timetable for all the timing points. The Booking can be set up for a term (using the date exclusions) or a week and then duplicated as required so that only the dates need to be changed.
Example 3 : Urban runs with all the necessary timings entered in to ITINERARY

In all of these examples the DRIVERS/ BUSES can be allocated a few days in advance using the Operations for the appropriate day.

DELETE Booking:

A BOOKING which has been CONFIRMED is not deleted but archived.

Booking REPORTS:

These are the reports available. Please review what the reports contain by going to the demo system and having a look ate the set of reports that are available. These include :
REPORTs Booking:
TO_DO Bookings that have NOT yet been CONFIRMED.


ALL DATE All Bookings on-file (excluding ARCHIVE) in date order.

ALL NAME All Bookings in Booking NAME order.

REPORTs Financial:
PAYMENT DUE Bookings which have not yet been paid for.

REVENUEs by BookingID:

REVENUEs by BookingDate

DROSTER Drivers 14 Roster of JOBs to be done.

SROSTER Subby 14 day Roster of JOBs to be done.

ARCHIVE REPORTS: These are still under test.

Booking, JOB and Quote Request CONFIRM:


Your Business Integrity is assured if these FOUR confirmation steps are used as designed.
1. Validate any Quote Requests that have come into the system by setting the OK flag.
Use the PlanSheet/WorkSheet to ensure that ALL information about the Booking is CORREDT including the recording of RECEIPTS paid in advance THEN 2. CONFIRM the Booking which will add all transactions to the Customer Account
and create all the JOBs necessary to ensure that the Booking is executed THEN
Allocate resources (driver and bus) to the JOB on the Daily Diary and THEN
3. Flag the JOB as Done when the Vehicle is enroute. All actions for the JOB
can be netered as NOTES on the Daily Diary while JOB is in progress. 4. Finally, by running the ARCHIVE Task, as a regular action, ALL your business data
is fully backed up, secure and available for statistical analysis.
1. Quotes OK:
The Quote Request System is a powerful validation tool. The Quote Request System can be entered from any friendly website including your own. This needs to be set up on that speciific website by the website administrator. Placing an action button, which is detailed at the top of the Admin Task, onto a website and marking the Button as Ask-for-FREE-Quote or similar the Quote Request Form is presented in that user's browser.
System security prevents access to anything other than the QRS system BUT the QRS editing has to be as non-restrictive as possible to encourage use by both NEW and existing customers or inhouse staff. Example: Staff at a school using to book class tours. It is therefore possible for errors or junk requests to be loaded to the QRS system.
The -Quote- Task in the Master Menu provides the ability to check ALL Quote Requests. The genuine requests are easily recognised and by clicking the -OK- action button the Request is loaded internally as a Prov. Booking. The others can be deleted when suitable or will be deleted automatically when a Monthly Archive Run is done from the Admin Tasks.
2. Booking CONFIRM :
Bookings come from the Quote Request System (above) or are entered into the System as NEW Bookings. Both of these Bookings will require action in the Planning Sheet (PlanSheet) which is the Booking EDITOR. A very basic Booking requires a minimum of :

Mandatory Entries:
a) Customer name
b) PickUp Address
c) Destination Address

Optional when entering a NEW Booking:
d) A Booking Name (so it can be found easily for processing changes etc)
e) START and END dates and times
f) Number of Passengers. (Essential for Tours system). Tonnage is requested for vTrack but that is optional.
g) An initial Quote estimate will enable the system to process Quotes and Invoices for a Customer.

Without the Mandatory entries the Booking is useless.
Without the rest the Booking has many limitations. With all of these details the System is able to create JOBs for the required dates and times. Drivers and buses MUST be allocated to the JOBs on DailyDiary (WorkSheet) for the JOB to be OKed as valid.

Once a Booking exists it is available for use in the Planning Sheet. The PlanSheet is where a Booking can be turned into a very powerful business tool. There are so many options avaiable on the PlanSheet that a help section has been created to explain each one of the options and services. The most powerful service provided by the PlanSheet is the ITINERARY SHEET. The ITINERARY is blank for Quote Requests but is very detailed when it is created for a NEW Booking because it is easier to delete than it is to enter details. The ITINERARY caters for building a complete TOUR and includes the ability to CALCULATE the costs for that TOUR.
The PlanSheet can be used as many times as is necessary to plan ALL the details for a Booking. The Financial Section of the PlanSheet defines the accounting requirements. If no Financial details are entered then there will not be any transactions created by the system for the Customer accounts.
When every detail of the Booking has been finalised the Booking MUST be -CONFIRMed-. Only the ITINERARY can be changed after a -CONFIRM-. The Booking is in fact a referenceable business data asset.
3. JOBs Done :
When the Booking is -CONFIRMED- a JOB is created for each bus for each day thus catering for School runs, Tours and multi-day multi-bus charters and contracts .
These JOBs are then managed in the Operations section / DailyDiary / WorkSheet
DailyDiary provides TOTAL information about each JOB so that the DailyDiary becomes the activity screen for the business for any DAY. The fact that this can be accessed from a SmartPhone means that the business can be managed from anywhere where there is internet coverage.
The JOBs need to be prepared before THE date by allocating drivers and buses. This enables complete control of your own fleet-buses as well as any buses which may be hired as non-fleet buses (or vehicles). From DailyDiary DRIVERs RUNSHEETS and ROSTERS can be displayed and/or eMailed to the Drivers. SUBBY WorkOrders can be produced. Notes be entered on DailyDiary regarding any activity that needs to be taken during that day. In the event of problems one click on the JOB will display the complete Booking that created the JOB, all the driver information including a guide as to his committments over 11 days around this day and all the bus details. The JOB also caters for the re-assigment of drivers and/or buses from AVAILABLE resources at the time.
As soon as a JOB is being executed (on-the-road) the JOB is flagged as Done BUT changes can still be made to resources. Any changes are automatically recorded in the notes. This provides a valuable business log which can be retained as long as required (10 years ??). JOBs which are not -Done- should be deleted because the ARCHIVE process will not be run until ALL JOBs for any DAY are done.

These processes ensure total Customer Service and secure Business Data. If the Financials are entered and maintained (overdue amounts collected or journalled accordingly) the system is able to provide detailed cash-flow, balance sheets and accounting reports.
On a regular basis, as defined by company policy which must be decided, run the ARCHIVE action from the Admin Tasks which will move all valid data to special tables built to hold the historical data for the business, discard data that is not required and make a number of backups of ALL your business data. These BackUps are retained in a cycle of 6 copies on three separate sites in three different countries!
In the event of Impala Distribution and Marketing going insolvent all the program code and access to the System is held by our accountants in escrow. This information is provided to you as soon as your first payment is made. Register now for the FREE TRIAL OFFICE SYSTEM which provides a fully operational system with no contractual committments. We believe that we can provide you with a system which can exceed your expectations and grow with your business.


Return Trip for a SPLIT Destination Type :

The OFFICE will AUTOMATICALLY prepare TWO JOBs for a SPLIT booking. If there are multiple buses then the JOBs prepared will cater for this as well.
The SPLIT Destination Type ( Type 3 ) caters for Trips that do not take more than one day each way. If the ou-bound trip, PickUp to Dest, is more than one day then separate BOOKINGS must be prepared to handle that situation. Prepare Booking for out-bound trip. Make sure it is correct then duplicate it and using the Planning Sheet reverse the PickUp and Destination plus correct dates and times. All the Financials can be on the first Booking or the costs can be split between the two. Take care not to duplicate the Financials.

When SPLIT Destination Type is selected ensure that the START date and time are for the out-bound trip and that the END date and time cater for the in-bound (RETURN) trip. The System will prepare the JOBs accordingly. Note that Date and TIME means the in-bound trip can be on the same or any other date.

DailyDiary Coloured Bar Details:

The Blue Buttons in the DailyDiary are, as usual throughout , action buttons. Please read Vehicle for Bus if you are using the QuickBus vTrack option.
DailyDiary provides the ability to allocate and or change Vehicle (Bus) and/or Driver as would be required during the normal process of a working day.
Next to the entries in certain of the columns on DailyDiary coloured bars will be diplayed whenever there is something that is informative, as a check, or where something needs attention action, usually an error. These are the columns that have coloured bars :

Done Column :

BlueButton = Job has been started. Vehicle is manned and on the road.
+ RedBar = This JOB is waiting on confirmation.
When the Job is on-the-road Click on the BlueButton and the JOB will be activated and this column will show as -Yes- which signifies that the JOB has been Started. Any furthe activity requiring comments should be added as -Notes-.
When the -Archive- task is run from the -Admin Task- on the MasterMenu ALL JOBs that END before the date that the -Archive- run is completed will be stored in the JobArchive database for later reference. If there are JOBs that are NOT flagged as DONE the Archive will abort (not be run) and an error message displayed. The eror message will list all jobs-not-done. If those JOBs were NOT done then they should be deleted. This can only be done by a user with security level above 3.
The purpose of this process is to ensure that the QuickBus Archives, which are all the tables created by the -ARCHIVE- job ( part of the ADMIN TASK ), make up an accurate (auditable) record which is a true reflection of the business activities.

Cust Column :

BlueButton = Display ALL Customer details. If JOB is being done for the Customer on behalf of a CLIENT then the CLIENT details will need to be displayed separately after getting the CLIENT details from the BOOKING display (next column).

Booking Column :

BlueButton = Display ALL Booking details.

Bus Column :

The BlueButton (Bb) will always be present in this column so Action can be taken:
Bb + RedBar = Click BlueButton to select a Bus for this JOB.
Bb + BusRefNumber = Click BlueButton for ALL information about this bus OR to take the action necessary to clear a coloured bar.
Bb + BusRefNumber + RedBar = Since this Bus has been allocated it has become unavailable. Requires urgent correction. Click BlueButton and than -Change- to replace allocation.

Bb + BusRefNumber + YellowBar + (nn) = This bus is a non-fleet (Customer owned bus) and the nn = the Customer ID number.
Further colourbars could be added as below.

+ YellowBar = This bus is allocated to more than one JOB for today. Take care when allocating to another JOB that times do not overlap.
+ DoubleRedBar = The start/end times for this JOB overlap for this bus. QuickBus will allow this situation because it is possible for a bus and driver to be requested to do THIS JOB during the wait time on JOB xx. This decision should be made with care and the travel time from dropoff time at JOB xx to PickUp time at THIS JOB must be taken into account. Plus dropoff time from THIS JOB back to JOB xx must aso be taken into account.

Driver Column :

The BlueButton (Bb) will always be present in this column so Action can be taken:
Bb + RedBar = Click BlueButton to select a Driver for this JOB.
Bb + BusRefNumber = Click BlueButton for ALL information about this Driver OR to take the action necessary to clear a coloured bar.

Bb + BusRefNumber + YellowBar + (nn) = This Driver is a non-staff (Sub-Contractor) and the nn = the Customer ID number for that Sub-Contractor.
Further colourbars could be added as below.

+ GreenBar = This Driver is allocated to more than one JOB for today. Take care when allocating to another JOB that times do not overlap.
+ DoubleRedBar = The start/end times for this JOB DO overlap for this Driver. QuickBus will allow this situation because it is possible for a bus and driver to be requested to do THIS JOB during the wait time on another JOB. This decision should be made with care and the travel time from dropoff time at JOB ?? to PickUp time at THIS JOB must be taken into account. Plus dropoff time from THIS JOB back to JOB ?? must also be taken into account.

Notes Column :

BlueButton: Notes can be added to JOB as any related incidents occur. These notes are as a Daily Logfile with the JOB which can be referred to any any time in the future as a reference or history document. Limited to 1000 characters = roughly half a screen.

Columns V, of, D, of and T :

The columns, V (Vehicle) of (Number of Vehicles requested for this JOB) and D (Day number) of (Number of Days that this JOB is Booked for) and T (TripType for this JOB as defined with the Destination), included on DailyDiary are there for information reference. They should always be taken into account. Example: Multi Day Bookings ( where -of- column is greater than 1) require bus to be allocated on Day 1 of that Booking and the system will allocate that Bus as -V- -of- for the rest of the days for that Booking. The Bus (or Driver) can be changed on later days if necessary (eg. broken down bus or sick driver etc)

Structure of DailyDiary/ WorkSheet :

Explains all DailyDiary Columns :

The DailyDiary / WorkSheet is a complete system in its own right and provides :
1 --- JOB identifies the JOB number. Each JOB in the system has a unique number
2 --- Done identifies whether the JOB is waiting on some action or is on-the-road
3 --- Start is the start time of the JOB. The drivers RUNSHEET caters for the time necessary to get to the PickUp for the JOB
4 --- End is the intended time for the JOB to be completed. Does NOT include the time required for the Vehicle/BUS to get from the final DropOff to DEPOT or next PickUp. ( the required Driver time can be viewed by checking the Driver's RUNSHEET.)
5 --- Cust is the ID number of the Customer. ALL information about the customer can be displayed by clicking on the blue action button.
6 --- BOOKING shows the ID number of the Booking and the first 14 characters of the Booking NAME. This first 14 chars of the Booking is known as the BookingTag as it is used in other parts of QuickBus ALL information about the Booking can be displayed. Click on the blue action button.
7 --- Bus (or Vehicle) has a red bar if a Bus has not yet been allocated to the JOB and the blue button will display a complete list of ALL buses/vehicles that are available for allocation including an 11 day schedule for that bus/vehicle. Clicking the blue button will allocate the selected bus/vehicle and return to DailyDiary after clicking the blue Continue button.
If there is not a red bar shown then the bus/vehicle reference number will be shown with a blue action button. Click on the blue action button will show ALL the details for THAT bus/vehicle PLUS blue action buttons to -CHANGE- or -REMOVE- the bus from that JOB.

8 --- Driver has a red bar if a Driver has not yet been allocated to the JOB and the blue button will display a complete list of ALL Drivers that are available for allocation including an 11 day schedule for that Driver to ensure that Work allowances are not exceeded. Clicking the blue button will allocate the selected Driver and return to DailyDiary after clicking the blue Continue button.
If there is not a red bar shown then the Driver reference number will be shown with a blue action button. Click on the blue action button will show ALL the details for THAT Driver PLUS blue action buttons to -CHANGE- or -REMOVE- the driver from that JOB PLUS -RUNSHEET- or -ROSTER-14- to display these documents which can be eMailed.

9 --- Notes is available for the recording of Notes FOR THE OPERATIONS STAFF or anything relating to the JOB for THAT day. These notes serve as a Log of any and all activities that need to take place or have taken place during the day. The system will add a note here for any changes made to buses/vehicles and/or drivers.

Please see the help reference for Legend: For an explanation of the coloured bars for more information about the columns.


Website Tour/Job/Trip Booking LINKs:

Using the first 12 characters of a BOOKING NAME the Bookings are linked to any website so that customers can book seats on tours or any other Booking website which has the link button associated with THAT Booking Link on that website.
These SPECIAL BOOKINGs are created in the Ticket Task of the Main Menu ............... to be continued zzzzzim

YOUR Valuable Data:

Benefits and Design Objective:

was conceived and developed with the following BUSINESS OBJECTIVES in mind:
-1- The value, integrity and security of your business information (which is called data in the computer world).
-2- The initial cost (which is $0.00) and ongoing running costs MUST BE MINIMAL to make the system affordable by a one-man, one-bus operation ( who is actually a person who most needs the MANAGEMENT structure provided). This means that the system relies on Open-Source programs which are available at no-cost to the user. We only charge for the cost of maintaining the system programs, running a suffiently powerful website and ensuring the ability to maintain GOOD CUSTOMER SERVICE.
-3- Avoid ALL the costs of running an OFFICE ( but suited to an multi-location office with many people running many terminals if necessary = scalable ) and avoid the use of PAPER entirely ( which used to be a theoretical possibility only ).
-4- You or your staff can be located anywhere in the world (or country) and can operate the system from a SmartPhone. ( Large volumes of data is however still easier to load to the system from a notebook or a laptop or a desktop - as always ).
-5- The system can be operated without training because of the conversation mode in which it operates and the User Manual available by clicking the icons located wherever the -What is ?- question might be asked. ( called online help )
-6- Staying INDEPENDENT. By using a browser to run the QuickBus OFFICE System any computing device which has a browser can be used access and run the System. We do not rely SOLELY on Chrome, Firefox, Edge, Safari, Opera, Chromium, Torch, Google, Internet Explorer, Micrsoft, Apple, IOS, Android, UNIX or Linux to be able to use the system. The System has also been tested using the Brave Browser which we feel is the only browser that really seems to be independent from the big5?? Brave Browser also OFFERS user involvement rewards for your surfing the web !!
We know that there is not a more powerful advertising media than WOM (wordhow-of-mouth)

Talking of which; You can become an QuickBus OFFICE supporter by:
a) Signing on for a Trail Version of QuickBus ( Register so that you can become familiar with how it works )
b) Assisting a friend when THEY REGISTER for their Trial copy and ensure that your AgentId = System Registration name is included on their Registration ( OR email that information to support so that we can add your ID to their Registration and
c) Receive a % of their monthly payment to your PayPal eMail account.
eMail support for more information

We also use a number of websites scattered throughout the world to serve as backup systems. ( Possible the ONLY online application to offer this level of Security/BackUp )

When the Registration Form is completed the system creates a set of tables to manage ALL your OFFICE information. Technically this is called a relational database so that any information entered into the system is ONLY ENTERED ONCE and all subsequent use of the data is cross-linked by the program. This provides QUICK reference to any of this data BUT only to persons with Authorised access.

Your critical and most valuable OFFICE Data is stored in FOUR TABLES :
1. Customer :
The CUSTOMER Table holds a single record for EACH CUSTOMER. This could be called a people table because each and any person which deals with your OFFICE is considered a CUSTOMER. When the Registration Form is completed the system creates a CUSTOMER record for YOU as the business owner so that JOBs can be allocated to yourself ( as the owner ) for execution.
Customers can be a NORMAL CUSTOMER (a person paying for a Tour or Charter or Contract), a CLIENT (someone who is contracting YOUR BUSINESS to do a JOB via a BOOKING) or a SUBBY (a SUB_CONTRACTOR who can be allocated either BOOKings or JOBs for execution).
Each Customer also has a Primary Address which is loaded to the Address Table as any normal Address but is also linked to this Customer.
Note: The customer name should never be entered into an Address Name for Privacy reasons.
2. Address :
The Google Automatic Address finder provides anyone with a very powerful tool. However for repetitive entry of an address this does become very tedious. In addition many addresses have particular significance to YOUR BUSINESS.
Example: You are a Charter Company and do work for XYZ College who frequently require buses to their Sports Complex at 27 Lower River Road. The ADDRESS is loaded the first time it is needed and is given a NAME ( also referred to as a Point-Of-Interest or POI ) as XYZ Sports Complex. Whenever an address needs to be selected, the ADDRESS SELECTION by NAME requires one click to select that address.
Note: The customer name should never be entered into an Address Name for Privacy reasons.
3. Bus / Vehicle :
has an alternate system called which can be selected when Registering. The Systems place emphasis on BUSES or VEHICLES respectively. BUSES are usually located at the BUS DEPOT. VEHICLES default to being at the DEPOT until they have been sent to a Destination.

Either vehicle is defined as being NON-FLEET (owned by one of the Customers) or FLEET (owned or under lease by YOUR COMPANY/ OFFICE ). The system manages these vehicles accordingly.
A DUMMY vehicle is loaded to the Bus / Vehicle Table when Registering to ensure structural integrity for your OFFICE . It can be deleted as long as it is not in use.
Driver :
DRIVER information is required when selecting a driver for the execution of a JOB. ALL the Driver Information is then readily available when managing JOBs from the DAILY DIARY which is the system display which facilitates the complete management of your business on a daily basis. It provides one click access to CUSTOMER, BOOKING, Bus/Vehicle and DRIVER and ties all of these resources together to provide a business LogBook / History for later statistical reports as may be required.

When the Registration Form is completed the system creates a DRIVER record for YOU as the business owner so that JOBs can be allocated to yourself ( as the owner ) for execution.
If a Customer is identified as a SUBBY then that CUSTOMER will be made available for allocation to a JOB as a DRIVER.

Protecting your Data :
After REGISTERING the system you have FULL ACCESS for 60 days (2 months) to test your data in the system. When you have decided that the System does work as your complete OFFICE the first payment can be made via the PayPal button located in the Admin Task of the OFFICE System. Their are many securities offered by PayPal such as money back guarantees in the event of lack of service. Your System is then -LIVE- and the opening screen will reflect when you next payment is due. If you cease payments you will be contacted by Impala to ensure that your system is not closed down BY COMPUTER for non-payment.
On Registration you will receive a mobile telephone number which will be available 24/7 in case of emergencies. eMails will be handled ASAP (normally within 12-15 hours depending on time-zone differences).

Your data backups are controlled from the Admin Section in your system in addition to monthly securities taken automatically onsite AND on our own systems in case of any emergencies. The website used for the operation of has failsafe proceedures to ensure worldwide system security. The site backup is located in a different country.
You can request backups of ALL your data on physical DVD at any time for a fee equivalent to 2 months payment of your monthly rental rate. The format of this output will need to be discussed with quickbus support hence the charge involved.

A Customer:

Customer Section :

The CUSTOMER Table is really a misnomer. It should in fact be called the PERSON table in keeping with Windows 10's weird change to PEOPLE as their eMail Address Book ??? There are a number of ways that the CUSTOMER Table is used in . In a BOOKING Customers can be allocated as:
-- Normal Customers as Joe Bloggs or Cypress Engineering ..
or AS CUSTOMERS they can ALSO be referred to as
-- CLIENTS who assign Bookings to your business to be expedited.
-- SUBBYs. Sub-Contractors who are specifically identified in the CUSTOMER Table
-OR- Persons-of-interest. A person to be contacted or kept advised about a Booking
In addition the Customer Table stores COMPANIES and Passengers for the Passenger module.

Additional Customers are loaded by using the Cust then NEW . A new, very basic and "provisional" customer can also be loaded to the System by means of a Quote Request System being submitted from your own or another website. This QRS (Quote Request System) is an external link into your System.

A list of the Customers are presented for selection (Pick a customer) for the creation of a NEW Provisional Booking and if the Booking Customer Type is either a CLIENT or a SUBBY or if a vehicle/Bus is Non-Fleet and therefore belongs to a person who is registered in the Customer Table.

NEW/EDIT Customer:

New CUSTOMERS are loaded to the system by Cust / NEW or when there are NO CUSTOMERS LOADED TO THE System Continue . The INPUT form is :
**Company or Last Name :
When entering a Company name the First name should not be used. For a person or a person trading as a company enter the Last name.
First :
Enter the first name ( or given name ) of the person. Not required for Companies / Organisations. These should include CONTACT person and an appropriate mobile number.
Category :
Category can be ignored initially and can be set up and used at a later date. The Customer Category has special significance in because it defines the sequence in the lists which are presented for selecting Customers ( by category) and also provides the mechanism for splitting financial reports. For Example : All Staff Members are loaded to the Customer Table (people file) with a Category of STF so that internal cost allocations can be reported separately. See Category for a suggested method of using this feature. This field is optional and should be left blank unless the CUSTOMER needs to be identified as belonging to a special category.
Grade :
Only applicable for sorting certain selection lists. There is a specific section for Grade in this help file. Until a Grading system has been defined for the organization use 555 ( General purpose grading ) or leave blank. The system defaults to 555 in many cases.
Contact Name :
For use with a Company Name. Can be left blank. This is a person whom you would normally speak to when calling this Company.
**Mobile :
This is the mobile number for the Customer and in the case of a Company would best be the Contact Persons Mobile number. This is a mandatory entry for a NEW Customer.
**Email :
This is mandatory entry for the system.
Telephone :
In the case of a Company this would be the Company Landline where the Mobile number would be for the contact person.
These notes are for reference puposes for staff only. They are NOT used in any other document produced by and can thus be regarded as private reference information.
The PIN is a FOUR DIGIT number 0000 through 9999 and can only be seen when selecting a Customer. (Last number between brackets.
It can be updated in the EDIT when the current PIN: is displayed. It should never be changed unless requested by the customer who should be able to tell you what the current PIN is. The number in brackets behind the PIN is a randomly calculated number which can be used if there is a need to update the PIN. Advise the Customer if his PIN is changed. A PIN: number is allocated for NEW Customers.

When using the QUOTE REQUEST System RETURNING CUSTOMERS need to know their PIN number. When a NEW Customer signs on via QRS he is allocated and advised about his NEW PIN.

The next two sections, -SUBBY- and -Primary Address- should also be read when capturing information for a -NEW CUSTOMER-.

IS Customer a SUBBY?:

A SUBBY is a Customer to whom Bookings and Jobs can be assigned for execution as a Sub-Contractor. SUBBYs are a special group of CUSTOMERS. Any Customer can be assigned as a SUBBY. Customers can be NORMAL Customers ( Joe Bloggs or Civic Constructors PTy Ltd ) or they can be Normal Customers AND either CLIENTs or SUBBYs.

A Customer becomes a SUBBY when a SUBBY REFERENCE NUMBER is assigned to the Customer. If this REFERENCE NUMBER is blank then the Customer is not a SUBBY. So to restore a Customer to being a normal Customer and NOT a SUBBY the SUBBY REFERENCE NUMBER in the Customer record should be cleared ( return to being a blank using the Customer EDIT ).

The purpose of making a Customer a SUBBY is to enable BOOKINGs and/or JOBs to be assigned to that customer as a SUBBY = Sub-Contractor.

The SUBBY REFERENCE NUMBER must be unique and should be structured in such a way as to be easily recognizable when selecting a SUBBY from a list. IT CANNOT BE LESS THAN THREE CHARACTERS LONG. An easily recognizable structure would be SUBnn or SUBCCC where nn = numeric 01 to 99 OR CCC = the three character initials used for that Customer as VC for Vernon Charles or VFC is his Middle Name was known to be Fred.

It is a good idea to enter the SUBBY Driver licence number, Passenger Authority (or similar) and Expiry Dates into the Notes section of a Customer who is a SUBBY.

The system has pre-loaded template to request a quotation from a SUBBY for a Booking or a JOB and caters for the allocation of a SUBBY COST component in the Booking as well as the ability to debit or credit the Customer Account for amounts due to that Customer as a SUBBY for work done.

There is a WorkOrder available as an email for SUBBYs in the same way as a RUNSHEET is available for DRIVERS.

Customer Primary Address:

A -NEW- Customer PRIMARY ADDRESS INFORMATION should always be entered as well. There is an optional QUICKSAVE provided. This should only be used when there is strong reservations about getting a complete address from a customer at that time and the customer details entered so far must be saved. The Primary Address can be added by using EDIT at a later time. It should be noted that an -EDIT- cannot be -SAVEd- without valid address information being entered.

Each Customer MUST have their own Primary Address to make effective use of the System. If one is not present then the System will comment accordingly.

For Companies this should be the Head OFFICE location and
For Schools the Admin OFFICE or regular Pick-Up point would probably be best
For Indivuals this should be the Residential address
with the understanding that these addresses are used as defaults when specific Pick-Up or Drop-Off addresses are not correctly advised or for some reason have been deleted from the system.

This address is NOT allocated as a PickUp address when a Customer is selected. PickUp and DropOff addresses are selected seperately.

Any other addresses can be added to the Address table and the Address NAME can be used to associate an address with a Customer. The selection of addresses by Name will then make the task of finding an address a one-click task.
Example : Customer = Number One School
Extra Address 1: No1 School - Gym Classes
Extra Address 2: No1 School - Boat Launch
Extra Address 3: XYZ Swimming Center

Customer DELETE:

Customers should never be deleted. Rather change name, add OLD and create a new Customer if required.
If they are deleted the system retains the Customer details to ensure that any expedited Bookings for that Customer still reflects all the then-current information.


DRIVER Section :

There are two types of DRIVERS in . The first is a driver who is ON-STAFF as either an employee or a contractor and the second type of Driver is the SUB_CONTRACTOR ( SUBBY ). Both types of driver are included in the list of Drivers that are presented for allocation in JOBs on the DAILY DIARY ( WorkSheet ).

The information available in becomes very significant when it comes to allocating Drivers on the Operations Daily Diary. The DailyDiary for the WorkSheet has the same power for JOBs as the PlanSheet has for Bookings. Before the Driver is allocated to a JOB on DailyDiary the Driver carries a RED BAR to indicate that alloccation is required. When the blue action button is clicked next to the Driver a Table of ALL available drivers is presented for selection. This Table includes Drivers who are STAFF (entered in the Drivers Table) AS WELL AS those CUSTOMERS that have been flagged as SUBBYs in the Customer Table.
The information includes an 11 day schedule of the days on which THAT driver has been allocated to JOBs

NEW / EDIT Driver:

Drivers are loaded to the system from the Driver Section by selecting NEW The input form is :

**STAFF REFERENCE (Mandatory 3-6):
This reference number is used throughout and should be meaningful. It will become the nickname for the Driver and be significant method for identifying a Driver and selecting the Driver for JOBs. The recommended structure for this ref. is abc4 where a, b and c are three INITIALS of the driver and 4 is a numeric digit in case there are a few drivers with the same initials. Examples: Fred Johanathan Bourke would be FJB, Ian Mitchell could be IMM (to keep the structure to THREE INITIALS.
Grid :
A code which is used by large companies with many resources to sort the resources in sequence of importance, ability or quality. The default is 555 which means the resource has all required skills or facilities for most JOBs.
First Name :
**Last Name :


Unit :
No :
**NAME :
SPECIFIC Suburb is required rather than division name or City or Area. Example: Slacks Creek rather than Brisbane.
**State :
QLD, NSW (Australia) or NY, DC (USA) . .
P/Code :
Google Automatic Address System, used elsewhere, does a good job of providing correct postal codes for an addresses. Postal codes are not specifically used by the System.
A MOBILE CONTACT number is essential for being able to contact a Driver. If the Driver does not haveone it is the interests of a Company to provide one.
Landline :
An eMail address functioning on a Smartphone enables best use to be made of the System. With a SmartPhone and an eMail address a Driver is able to get copies of his RUNSHEETS. The Driver can also LogIn to and see his RUNSHEETS online as well as viewing appropriate addresses for the RUNSHEETS online.
**DATE-of-Birth :
This normally be entered in full as dd-mm-yyyy because QuickDate is not very helpful when it comes to dates that are not in the current year.
**Drivers Licence Number :
**Drivers Licence Expiry Date :
Which is used to produce a REPORT in date sequence to check whether any Drivers have expired Licences.
Licence Type/s :

Drivers OFFDUTY:

There are two types of DRIVERS in . The first is a driver who is ON-STAFF as either an employee or a contractor and the second type of Driver is the SUB_CONTRACTOR ( SUBBY ). Both types of driver are included in the list of Drivers that are presented for allocation in JOBs on the WorkSheet ( DailyDiary ).


Only ON-STAFF Drivers can be placed OFFDUTY.
These offduty records are stored individually in a special Driver table. When a Driver is viewed the unused records are listed ( those for to-day and all future ). They can be used to book Drivers leave, off sick, temp not-available .. The number of records stored are pretty well limitless.
Vehicles / Buses have this same facility.

Link Requests:

Link Requests / Ticketing Reservations :

to be written up zzzzzim

Quote Requests:

Quote REQUEST Form (described in detail below):

The Customer Quote request links directly into YOUR QuickBus System (the OFFICE ) and is therefore open to malicious data entry. For this reason the checks on data input to the QRS are very strict however persistent hackers, jokers or persons not really interested in entering a valid request can submit QRS forms. The purpose of the QUOTE REQUEST Approval Table is to ensure that any inappropriate REQUESTS can be recognised and ignored or deleted.

Quote REQUEST Approval Table:

If the first column (OK) has a number with the action button then that QR has been approved and the number is the Provisional Booking that has been created. Clicking the blue action button will display the complete Booking record that has been created. That Booking will have - QRS ID:nn - as a prefix to the Booking Name.
If the first column (OK) has a red bar with the action button the QR has not yet been approved . Clicking the blue action button will ensure that the QRS is rebuilt as a provisional Booking and placed into the OFFICE so that it can be further processed before it is -CONFIRMED-.

The action buttons in the other columns (Request, PickUp and Destination) will display all the information available for those columns.

Quote Requests Form:

Quote REQUEST -- Customer entry form:

To understand the Form process below it would be best to go to the SignIn screen ( the Foyer) and GoTo the FREE Quote. This Free Quote button is exactly as it would appear on your own or any other friendly website to link into YOUR QuickBus System.
The QUOTE REQUEST SYSTEM is a sophisticated link system. To ensure the security of QuickBus© as a whole changes to the website security structure are required. For this reason a Trial OFFICE will not have the QRS System set up. It will only be installed after the first payment has been made. You can test the QRS System by clicking on the -FREE Quote- Task button on the Reception Screen where you Sign In. Please email quickbus77@gmail.com if you need the Quote System for evaluation!
QUOTE REQUESTS for the can be requested by placing an HTML action button on any friendly website who is prepared to create a FREE-TOUR-QUOTE or FREE-JOB-QUOTE or FREE-CHARTER-QUOTE button on their website. You should create such a button on your own website. The structure of the HTML action key is defined on the first page of the Admin Section for this site. The QuickBus© FOYER has a --FREE QUOTE -- button which goes to a QUOTE REQUEST page for the DEMO system.

NOTE: The right-hand side of the first QRS page has a panel which will be blank until the contents for this panel have been entered into the EDIT_PARMs. GoTo the Admin Task (Right hand side of the Main Menu) Then click on - EDIT-PARM - which is near the top of the Admin Task screen just above Data BackUp/Security so that you can Edit the User parameters. Use the PageDown key twice (or move down approximately two pages in a browser) until you see Quote Request Screen. There are 6 blocks (called fields) marked Line 1 through Line 6. Each one of these fields is intended to hold a maximum of 30 characters each and are displayed EXACTLY as they are entered. For system security reasons no special characters should be used. And if wide letters are used (eg. A W M etc..) then they will overflow the line. Here is an example of 6 lines (used in the - FREE Quote - link.) :
Line 1: This is QuickBus.
The system will insert a blank line in the panel at this position. Line 2: The Quote Request
Line 3: will be sent to
Line 4: sales@buswise.mail
Line 5: --------------------
( 20 hyphens/minus signs) Line 6: Thank you.
The lines will be placed centrally.

The form consists of two pages. Page 1 of 2 has :
Request for how the Customer would like to receive the quotation. Either by eMail or by SMS.
If Booking is being entered by a regular Customer you would have advised the Customer of their Customer ID number. By inserting this ID here no further Customer information needs to be entered
The PickUp address can then be selected from the Local Address Book that has been loaded for YOUR OFFICE in street name sequence. If the address is available on the list then the Customer can select that address and GoTo --NEXT--
If the Customer is not an existing Customer with his ID available then Company or Last Name, First Name, Mobile Number and eMail address is requested.
If an address was not available on the list then the PickUp address information is requested. A Google Auto Address option is provided or the Address can be manually entered including any notes which may apply to this particular address.
If the Quote request is being entered by a Customer who is a CLIENT on behalf of another Customer then the CLIENT will have a Customer ID and that can be entered before --NEXT-- is selcted to GoTo Page 2 of 2.

The --NEXT-- selection will display the errors in the Page 1 or else display the details that have been entered so far and the --NEXT_-- button can be selected for Page 2 of 2.
Page 2 of 2 has :
Information about the Booking being: Number of Passengers, Booking DATES (Start and End with a Calendar displayed when clicking of DATES or date can be entered in dd-mm-yyyy form ), TIMES as selected from the lists and any notes or comments.
The Destination Address is then requested in the same form is the PickUp address on Page 1.

The --SUBMIT-- button will submit all the information for further checking and validity and if all details are OK.

Any errors which occur on Page 2 will be listed but the request will be processes anyway based on the information on Page 1 so that the Customer (or CLIENT) can be called to get further information.
If possible all information will be displayed with a confirmation eMail to the CLIENT/Customer and an email will be sent to the OFFICE advising that the Quote Request has been submitted.
The Quotes Section will reflect the Quote Request and if it is valid (enough information is available) the Quote Request can be OKed. This will transfer all the information to the Booking Section where it can be EDITed via the Planning Sheet, a QUOTE can be eMailed (or SMS to the Customer) and the Customer can be phoned to discuss the Request. When all the details have been clarified and the Customer accepts the QUOTE and makes his payment or deposit the Customer Receipt can be entered on the Planning Sheet, the receipt can be eMailed to the customer in the form of an INVOICE and the Booking can be -CONFIRMED- which will create JOBs to be followed up on the approriate DATE at the appropriate Time. Drivers and Buses can be assigned to the JOBs in a timely manner.


Vehicle / Bus Section :

NEW BUSes/VEHICLEs are added to by clicking Bus OR Vehicle task then NEW .

Cost Allocation and Receipts:

Initial Quote Estimate :

Cost Allocation and Estimates for Quotaions and Account Transactions. Entry for a NEW BOOKING will treat this as a single entry. Any further costing splits will need to be done using the Booking -EDIT- ( PlanSheet). Financial details can be left as ZERO VALUE BUT this will mean that Booking will have NO FINANCIAL significance and no transactions will be created.

Allocation Options :

DRIVER : Has no significance at this time ( 06vNN ) other than as a note. Future possible use may be for Driver bonuses.
CLIENT : Not Used yet. Future use. Probably credit CLIENT Account as a due for payment item as happens with the -SUBBY-
SUB : Must be entered when a BOOKING is assigned to a SUBBY by using the Customer TYPE (as Customer Type 3 ).
When Booking is -CONFIRMED- this amount will be CREDITED to the SUBBYs account.
When Payments are made to the SUBBY a Customer Journal must be completed.
Main : This is the main entry for a Booking.
If no other Allocations are used then this Allocation will reflect the TOTAL amount of the Booking.
Extras : This Allocation shows any charges that will be charged to the Customer (or CLIENT) that are excluded from the Quote Amount of a Booking. This caters for charges such as Toll, Parking .. to be charged to the Booking but are NOT subject to GST.
They are charges that are normally outside the control of the business.
When -JOURNALs- are entered for this Booking they are reflected as Extra Charges. -JOURNALs- would be entered for such charges as damage to the bus ...

TOTAL QUOTATION AMOUNT: for a Booking is the total of ALL Allocations.
So if an amount is entered for SUB, DRIVER or CLIENT that amount must NOT be included in Main.
On all documents related to Booking amounts the Extras are always shown as a separate amount not subject to GST.
GST : When Registering with QuickBus© the form has an option for GST. The default is GST Type 1
Type 1: GST is included in all Booking Costs (excluding Extras).
Type 2: GST is added to all Booking Costs for Customer invoices as an additional charge
Type 3: GST does not apply to the business. No provision is made for GST.
If the Type needs to be changed for your business please email support.
Applicable GST is reflected as a separate amount in all QuickBus© reports but no separate General Ledger Account is maintained for GST. Receipts can be entered HERE while Booking can be -EDITed- (ie. before -CONFIRM-)
After -CONFIRM- RECEIPTs can be applied to THIS BOOKING by using -BKG_RECEIPT- or -JOURNAL-

1) Enter an Amount AND change Receipt Number. ( Example : R/$actid/nn where nn is established from LAST RECEIPT )
2) Receipts for BOOKINGS, either from EditFinancials -OR- from BKG_RECEIPT, are applied to both CUSTOMER and BOOKING when -SAVEed-

To be entered:

QuickBus© Payment System:

To be entered:

Journal Entry:

The purpose of a Journal Entry is provide for the application of Credits or Debits to a Customer Account. All accounting entries have DOUBLE ENTRIES in keeping with good bookkeeping practice. For this reason has a number of Ledgers to enable this DOUBLE-ENTRY system. Journal entries for Customers apply the transaction to both the Customer account and the General Ledger Account.

All tranactions relating to Bookings are done automatically so that; When a Booking is -CONFIRMED- the Customer/CLIENT is Debited with the total amount for the Booking. While a Booking is in the PLANNING stage receipts can be issued to the Customer/CLIENT using the RECEIPT section of the PlanSheet. Corresponding DOUBLE-ENTRY transactions are entered into the Booking Ledger.

Transaction Description :
This identifies the reason for the Journal Entry in the General Ledger. This description is displayed for General Ledger REPORTS.
Document Number :
Whenever an accounting entry is made there is a reference to a document number. Receipt Books have numbers for each receipt. Invoices have numbers. For this system the Invoice number is the Booking ID. Number. For Journal Entries we need to provide a number to enable the DOUBLE-ENTRY cross reference. If you have a DEBIT NOTE BOOK or similar then the ref. number from this book is the number that should be entered here.
The number displayed in The Form is the last reference number that was used for this customer if the customer ref. number field has been used before. The most informative structure for this ref. is T/cccc/00 WHERE T = indicates a transaction / = used to keep the ref. meaningful cccc = customer ID (which is shown at the top of the form) AND 00 = this transaction number.
Credits for a Customer Journal Entry refer to money that we have received from a Customer or money which we need to pay to the customer. Such as a refund for some overpayment or money that needs to be paid for a service. Money that is due to be paid to a SUBBY for a JOB done on our behalf would be a CREDIT.
A DEBIT Journal would be required for the reverse of a CREDIT. Money that must be charged to a customer for a service or penalty (damage caused to a bus by the customer on a tour). Or money due to us from a SUBBY for overpayment or services which we have done for a customer/SUBBY. Invoices that can be eMailed (or printed from the screen and posted) to Customers/CLIENTS are automatically processed by the System. All transactions are processed automatically when a Booking is -CONFIRMED-.
Account Details :
The current status of a Customers Account is displayed at the bottom of the Journal Entry Form.

No action is taken on any form in until that form is -SAVED-. Any other action button on the screen can be actioned at any time.

QuickBus© Status Simulator:

Status :

When all the facilities of are used then the System has the ability to create a simulation of the status of all resources and accounts. This is effectively A SUMMARY OF ALL ASPECTS OF THE BUSINESS AS AT THIS TIME.
The full System requires that all Financials are entered for all Bookings, Bookings are CONFIRMED, all JOBs are ACTIVATED, all Receipts are entered and all other financials are completed. If any of these features are not used then that section of the simulation will not be displayed.

The simulation displays the following as selected from the menu:
1. All Bookings that are currently being executed. Buses/Drivers on-the-road.
2. A summary of all future Bookings.
3. All the JOBs being excuted for today as for the Operations but in expanded form
4. A summary of all JOBs for the next 14 or 28 days.
5. The location of all buses/vehicles on-file at this time.
6. The location of all drivers on-file at this time including SUBBYs. If not on duty the home address will be assumed.
7. A chart reflecting the committments for all resources for the next 14 or 28 days.
8. A list of all Customers that have payments due.
9. A summary of all Customer Accounts for the current year.
10. A Cash Flow report for all entries made to the Payments System.

These reports are in addition to the information available with each of the major Sections; Booking, Operations, Customer, Address, Bus/Vehicle, Driver, Status and Admin.

Buses / Vehicles:

There are Buses and Vehicles:

There are two versions of the System. The first is vTrack which is oriented to VEHICLES (or plant) such as trucks, utes, 4x4s, cars, limosines, bulldozers and the second is ToursBW which has the emphasis on BUSES. The reason for this differentiation is to ensure that the PLANNING SHEET ( Booking -EDIT- / -PLAN- form ) is able to collect the appropriate information that is required to set up JOBs for the DAILY DIARY. When we are dealing with Vehicles the tonnage can be important (although it is an optional entry for VEHICLES and PLANT).

In the case of BUSes the SEATs are essential to ensure that BUSes can be allocated to JOBs for the correct NUMBER OF PASSENGERS.

Another difference is that BUSes are normally allocated a FLEET number or name for quick reference purposes. This is catered for by the REFERENCE (name) when adding Buses to the System. There is provision to add the Registration number for Buses as well.

With the vTrack system the vehicle Registration Number is required and is stored in both Registration Number and the REFERENCE number. This is to ensure that the unit is loaded into the System in a meaningful way. In the case of plant or other equipment a unit identification can be entered as the Registration Number.

Entering a NEW BUS :


facilitates the management of Buses / Vehicles depending on the System Type that is chosen at the time of Registration. The two System types are TourBW and vTrack. QuickBus© manages Buses and vTrack manages Vehicles. The main difference between the two is that Buses require management by means of their seating capacity and are usually located in one specific yard and Vehicles (and PLANT) require management by tonnage and location. The BUS table is required for the allocation of Buses to JOBs in the WorkSheet (DailyDiary). The Buses are then micro-managed through the WorkSheet / DailyDiary.

Buses are loaded to the system from the Bus Section. Select NEW . A double asterisk (**) indicates mandatory entries. If these entries are not completed on the form they will be highlighted as errors in the information box of the browser page and the entry will not be processed. When adding a NEW Bus / Vehicle the complete form will have to be re-entered.

The form is as follows:
**Bus NAME :
Allocate a name by which the bus is commonly known. (30 char) Examples: Red Dog, The Mecedes, Hino 6432, TransLink No4. <
Licence registration number.(12 char).
This should normally be a Fleet Number. (8 char). Examples: XYZ001, QRF217, Route231.
This is very important when allocating buses to JOBs.
SeatBelts :
Y or N entry. In many situations this is a legal requirement.
AirCon :
Y or N entry. Few buses these days do not have a/c.
Special Equipment :
Important notes in an abbreviated form. ( 30 char ). Examples : 4x4, 2 ton Trailer .. A further 1024 characters of information can be entered into the NOTES for a BUS.
Date Registration Due:
This provides information for a REPORT in Registration Required sequence.
Licence Type Reqd :
Example for QLD, Australia: HR, MR, MC This is significant when allocating DRIVERS to BUSES.
1024 characters of information which may be required when BUS information is printed on documentation.

BUS NOT Available / Out-of-Service :
This entry enables the System to keep track of any times that this vehicle is not available for allocation to JOBs. During these dates the BUS will not be listed as available for allocation. If it has already been allocated previously and then made NOT AVAILABLE the BUS will be marked with a red-bar on the DAILY DIARY. Red-bars ALWAYS show that something is either not allocated or that there is a new problem associated with that resource.
Both Start and END dates MUST be entered when required else there will be an ERROR and the -SAVE- will not be executed and record will not be added or updated in the table.
Bus OWNERSHIP status :
This enables the System to identify NON-FLEET buses when presenting the list of BUSES for allocation. The BUS REFERENCE NUMBER will be flagged with a yellow-bar if it is NON-FLEET which means that the bus is sub-contracted from a Customer who may also be a SUBBY. So when a Bus is flagged as NON-FLEET the person to whom it belongs must be identified. This is done by selecting the owner from the Customer list.

OTHER Vehicle Details: (Optional. Not required by Bookings but used for REPORTS

Grid :
A code which is used by large companies with many resources to sort the resources in sequence of importance, ability or quality. The default is 555 which means that the resource has all required skills or facilities for the JOB.
Manufacturer :
Model :
Odometer NOW :
Odometer Reading Date :
Next Service Due Date:
There is a REPORT in Service Due Date order to enable the identification of Buses that are due for servicing. This field is maintained by -EDITing- the BUS record.

If the Bus is under Contract relevant details of the Contract can be entered here for reference.
START date :
Odometer Reading at Start :
Contract END date :

Entering a NEW Vehicle:


facilitates the management of Buses / Vehicles depending on the System Type that is chosen at the time of Registration. The two System types are TourBW and vTrack. QuickBus© manages Buses and vTrack manages Vehicles. The main difference between the two is that Buses require management by means of their seating capacity and are usually located in one specific yard and Vehicles (and PLANT) require management by tonnage and location. The BUS/Vehicle table is required for the allocation of Buses/Vehicles to JOBs in the DAILY DIARY (WorkSheet). The Buses / Vehicles are then micro-managed through the DAILY DIARY / WorkSheet.

Vehicles are loaded to the system from the Vehicle Section. Select NEW . A double asterisk (**) indicates mandatory entries. If these entries are not completed on the form they will be highlighted as errors in the information section of the browser page and the entry will not be processed. When adding a NEW Vehicle the complete form will have to be re-entered.

The form is as follows:
**Vehicle NAME :
This would mostly be a duplication of the Manufacturer information. It should be a name which is meaningful for identifying the Vehicle. Examples: ISUZU 24t Warter Truck, Cat. 7654L Front Loader, Prado Mine SetUp, Special Armoured Mercedes XLX46.
Licence registration number.(12 char). In the case of PLANT this could be a Stock Number.
Special Equipment :
Important notes in an abbreviated form. ( 30 char ). Examples : 4x4, 2 ton Trailer .. A further 1024 characters of information can be entered into the NOTES for a BUS.
Date Registration Due:
This provides information for a REPORT in Registration Required sequence.
Licence Type Reqd :
Example for QLD, Australia: HR, MR, MC This is significant when allocating DRIVERS to BUSES.
1024 characters of information which may be required when BUS information is printed on documentation.

Vehicle NOT Available / Out-of-Service :
This entry enables the System to keep track of any times that this vehicle is not available for allocation to JOBs. During these dates the Vehicle will not be listed as available for allocation. If it has already been allocated previously and then made NOT AVAILABLE the Vehicle will be marked with a red-bar on the DAILY DIARY. Red-bars ALWAYS show that something is either not allocated or that there is a new problem associated with that resource.
Both Start and END dates MUST be entered when required else there will be an ERROR and the -SAVE- will not be executed. The record will not be added to the table.
Vehicle OWNERSHIP status :
This enables the System to identify NON-FLEET Vehicle when presenting the list of Vehicle for allocation. The Vehicle Registration NUMBER will be flagged with a yellow-bar if it is NON-FLEET which means that the Vehicle is sub-contracted from (or owned by) a Customer who may also be a SUBBY. When a Vehicle is flagged as NON-FLEET the person to whom it belongs must be identified. This is done by selecting the owner from the Customer list that is presented.

OTHER Vehicle Details: (Optional. Not required by Bookings but used for REPORTS)

Grid :
A code which is used by large companies with many resources to sort the resources in sequence of importance, ability or quality. The default is 555 which means the resource has all required skills or facilities for most JOBs.
Manufacturer :
Model :
Odometer NOW :
Odometer Reading Date :
Next Service Due Date:
There is a REPORT in Service Due Date order to enable the identification of Buses that are due for servicing. This field is maintained by -EDITing- the BUS record.

If the Bus is under Contract relevant details of the Contract can be entered here for reference.
START date :
Odometer Reading at Start :
Contract END date :

Quote Request System :

Quote Section :

The QUOTE Section can be contacted from any website. An activation HTML button needs to be placed on the website inviting FREE-QUOTE or similar. The structure for this button is found at the top of the ADmin Section. It is located under the heading of :
YOUR website Link (URL) to this System is:

This link will open a browser page which is operating on your QuickBus© System and provides 2 forms for any Customer to complete. The pages are as self explanatory as they can be made. The link can look like FREE Quote
and should be inserted on any suitable index page.

Page 1 of 2 has action buttons top and bottom of the screen for -NEXT- -EXIT- and -RETURN-. The -RETURN- button is structured to return to the calling website (Your website). The -EXIT- button opens a new browser page with the equivalent of the the -RETURN-
The details requested on Page 1 are :
--- a) Which contact point should we use to call the CUSTOMER to discuss the QUOTE. The System very specifically requires direct contact with the CUSTOMER based on good CUSTOMER SERVICE practices. There is no automatic Quote calculation and email reply.
--- b) Is the CUSTOMER an existing CUSTOMER with an allocated ID. If so fill in the ID number. For regular CUSTOMERS this makes a Quote Request a very quick process.
--- c) Select the PickUp address deom the list provided. If this is a regular Customer then all his PickUp addresses will already be loaded and one click from the list completes Page 1 of 2 and -NEXT- goes to Page 2.
--- d) If not an existing Customer the details entered will be checked for logic and special characters and a NEW CUSTOMER will be registered in the QuickBus© System.
--- e) If the PickUp Address is not availale from the list and no selection is made then the PickUp address can be entered. Typing the address in the form described in the Google Automatic Address finder will list addresses as soon as Google can find any similar address getting more accurate as the address is entered. When the correct adddres appears in the list then it should be selected. This will load all the details into the address form below. If the address is a known Point-of-Interest (regularly visited building or location) then the Address NAME should be included plus any notes that may be appropriate.
--- f) If the Quote Request is being completed by a CUSTOMER who is a CLIENT ( one who passes Bookings across to your company for your execution ) then the CLIENT will have a CUSTOMER NUMBER which should be entered here. This would indicate that the CLIENT will be paying for the Booking on behalf of the CUSTOMER for whom the Booking is being entered. The CUSTOMER details MUST also be entered for a CLIENT Booking.
--- g) When all entries have been completed click on -NEXT- and the details as entered so far will be displayed for checking with -NEXT_- or -RESTART- buttons displayed. --- h) If there are errors then Page 1 will be displayed and a description of any/all errors will be diplayed. Try entering -NEXT- with no entries in the form to see a list of all of the possible errors.
--- i) -NEXT_- will store the information so far as a Provisional Quote Request and GoTo Page 2 of 2.

The details requested on Page 2 are :
--- a) Enter number of Passengers. This is used to select an appropriate BUS. For vTrack systems an optional vehicle tonnage is requested.
--- b) Clicking on the START date field (or using the TAB key after entering the number of passengers ) will bring up a Calendar for the current month. Later months can be displayed by clicking the arrow TOP right of the calander. Select the required START date or enter the date in the form dd-mm-yyyy in full.
--- c) The END Date is the same process.
--- d) Select a START TIME
--- e) and then select an END TIME
--- f) Enter any notes or comments or special requests or enter all the details for a particularly complex request. (1024 characters max).
--- g) Select a DESTINATION address which is provided in POI order or if the address is not availabel on the list
--- h) Enter the address in the same way as the PickUp address was entered.
Check all the details entered and selected and then GoTo -SUBMIT-

If you wish to bale out at any stage click -EXIT- or -RETURN-

The -SUBMIT- button will add these to the Provisional Request completed after Page 1 and display a summary of all the information that is in the newly created Quote Request. The System will also send an email to the owner of the Website advisng that a Quote Request has been entered
The owner of the website will be presented with a message to say that there is a Quote Request awaiting acceptance and processing. This is accompliahed by going to the Quote Section of the OFFICE .
The Quote Request is then accepted and will appear as a Provisional Booking. It can be selected and placed in the Planning Sheet for editing. The Booking then be checked and edited with particular attention being paid to the ITINERARY SHEET. When the ITINERARY SHEET is complete and all the addresses on the sheet are valid the the Quote Request can be costed and the QUOTE emailed or phoned to the CUSTOMER depanding on the contact method selected in the Quote Request.

System Special Tasks :


This process is only available for Security Level 5 (ie. owners as for Admin Section).
The process is intended to load latitude (lat) and longitude (lng) into the Local Address Table to facilitate the cost calculations that are provided using the ITINERARY Table. If these cost calculations and the MAP display is not used then the validity of addresses is not important. Invalid addresses do NOT have lat. and lng. loaded and have ** appended to the address in lists used for SELECTION. Invalid addresses may not display the MAP when so requested.

If an Address is SELECTED and THEN SET_ALL_MAPS that single address will have lat. and lng. updated if the address is valid (a MAP can be found in Google Map Display). In the same way that an address can be SET whenever a valid MAP is displayed.

ALL addresses should only be used if the majority of the address-on-file are invalid ( flagged with ** when listed ). If an ADDRESS is NOT selected then this task will reload ALL Addresses and could take some considerable time ( up to minutes with slow internet connection for the browser). There will be certain addresses which will be loaded with zero lat. and lng. when ALL are processed. This is a peculiarity with Google which we are attempting to resolve at this time (May 18). And this means that if ALL are processed (A single Address was not selected ) there WILL be a number of addresses which will be flagged as invalid when they are in fact valid.
These addresses can then be be SELECTED singly and MAP tried again. If a valid MAP is displayed then that address should be SET or else the address should be UNSET and the address should be corrected and re-evaluated with MAP

Admin Section :

PayPal Connection :

We have been using PayPal for over 10 years now and have found their services to be very trustworthy and appropriate to our needs. In fact we only make internet purchases from websites that use PayPal. If they do not have PayPal we source our requirements from someone else or do not make that purchase. They are very CUSTOMER ORIENTED and look after the interests of the purchaser in an excellent manner.

User Parameters :

1. -- Calculate the Values for MINS and KMS in the ITINERARY Table :
Bus and Coach magazines maintain figures for the cost of running buses. These numbers are loaded here as defaults. You are wecome to change them to suit your own requirements. The addresses listed in the Itinerary Table are maintained in the sequence specified and Google MAPs are used to calculate the distance and the time to travel from one address to the next provided both addresses are valid. These distance and time figures are multiplied by the costs entered here to provide the distance and time costs on the ITINERARY Table. The ITINERARY Table shows these two entries at the top of the respective columns.

2. -- The INFORMATION box on all QuickBus© screens :
The system sends ALL user messages to this box on the QuickBus© Section screens. There are two types of information. The first is informative MESSAGES about what actions will or have been taken when action buttons are clicked. The second are ERROR MESSAGES. The options that are available are verbose or non-verbose information. VERBOSE means that ALL information generated by the OFFICE is displayed in the INFORMATION box. NON-VERBOSE means that only ERROR messages will be shown.

3. -- hMail : Do not copy documents to OFFICE eMail :
Any OFFICE requires records to be kept for all documents sent to Customers. The PAPERLESS OFFICE achieves this objective by sending a CC of all emails sent from QuickBus© to the secondary eMail address provided when systems are REGISTERED. This CC of the eMails can be suppressed with this option. All eMails sent by QuickBus© are referred to as hMail because the eMails all make use of the HTML structure to ensure that the documents sent are well structured and easy to read and print if required.
These eMails are structured to include your company logo provided to QuickBus©. If a logo was not supplied then the QuickBus© Impala logo will be used.
The right-hand block of any email will contain information which is entered into the Document Address lines defined below.

4. -- Document Address lines :
QuickBus© constructs a set of lines from the REGISTRATION FORM and enters them here. This option allows you to restructure these lines however you may wish. These are 6 lines available in the right-hand box of a documents. They can have 40 characters each. 5. -- Quote Request Screen.
As above but used specifically on the Quote Request Form as displayed on any website that will be able to LogIn to your QuickBus© System.

6. -- One line Footer. Last line on a Drivers RUNSHEET.
These two entries form one line at the bottom of the Drivers RUNSHEET as printed from the JOB on DailyDiary (Operations ). The blue action button in the Drivers Column will display the RUNSHEET for eMail provided that a Driver has been allocated to the JOB on the DailyDiary. This single line, comprised of a left hand 40 character set and the right hand 40 character set, is added to the bottome line all RUNSHEETS. the default that is loaded to the system reads -Please complete this Checklist as per Company policy-.

7. -- Email address to be used as THE OFFICE email: 100 characters:
Option 3 above specifies whether all documents should be CCed to the OFFICE eMail for record purposes. This email address is the eMail address used for the CC. It should be added whether use is being made of the CC process or not as it may be used in other functions (like error messages) in the system.

8. -- The PAYKEY in BOOKINGs :
When FINANCIALS are entered into any Booking (from the Planning Sheet) these 6 options are presented as a list for selection as to the method of Payment for the Booking. The default loaded initially is 14 days for all the PayKey Types. These can be changed to suit your company requirements. Example : Contract may be used for contracted government departments and this may need to be changed to 90 days.
These days-for-settlement are added to the Booking Date and stored as the due-date for the Booking in reports and the Booking Status information.
OnPickUp has particular significance in that this PayKey is passed to DailyDiary so that any JOB for that Booking will include a note to the DRIVER on the RUNSHEET to remind the driver to collect the amount outstanding at the time that the RUNSHEET is displayed.

9. -- Default vehicle and Driver :
For smaller organisations which have few buses and few drivers the situation is normally that one particulat driver and one particular bus are the most frequently used resources for JOBs. JObs are where buses and drivers are matched. If values are placed here as the default bus/driver combination then the fist bus for each JOB for each day will be allocated this bus/driver combination.
They are very easy to change on DailyDiary if this is necessary and a change is easier to make than an initial allocation.
The REFERENCE NUMBERs are the specific STAFF REFERENCE and REFERENCE numbers allocated to Drivers and Buses respectively at the time of loading them to QuickBus©. There must be at least one of each loaded to the System before the System will function.
If the bus or driver is not available for that day (out-of-servce) then the OB will be marked accordingly on DailyDiary (WorkSheet.

Archive, BackUp and Restore :

The SECOND LEVEL of BackUps for each User/Owner database is the ARCHIVE which should be run each month on a date decided by your organisation.
The ARCHIVE BackUp is what is termed a Periodic BackUp because the System does a number of tidy-up tasks at this time. These are (as at 23/7/2019) :
1. -- Makes the ARCHIVE BACKUP of the COMPLETE database.

2. -- Delete all Quote Request System records where end date is more than 1 week old.

3. -- Transfer all completed and activated JOBs from the Daily Diary to the JOB ARCHIVE.

4. -- Transfer all BOOKINGs to the BOOKING ARCHIVE provided that
a) The END DATE of the Booking is less than to-days date AND
b) Any outstanding balance (amount due) has been PAID. AND
c) That the booking has been confirmed. UNCONFIRMED bookings must be manually deleted if they are not required.

5. -- Clear down all of the driver and vehicle (BUS) out-of-operation reservation dates that are out of date (BEFORE TODAYs DATE).
The FIRST LEVEL of BackUps is the BackUp Process which should be run whenever you are about to make any SIGNIFICANT changes to your data. For example you decide to delete all addresses for XYZ. Run this BackUp before the major change so that you have an easy method of re-instating the deletion if it does not achieve what was expected.
The Admin Section provides a list of all available backups for the RESTORE. Normally the latest BackUp is the one that will be restored but there is a cycle of BackUps that are retained in case of disasters of one sort or another. PLEASE BE AWARE THAT A RESTORE WILL RE-CREATE ALL THE DATABASE INFORMATION AS IT WAS AT THE DATE OF THE BackUp AND THAT ANY AND ALL TRANSACTIONS, ENTRIES AND/OR CHANGES MADE TO THE SYSTEM SINCE THE DATE OF THAT BackUp WILL BE LOST.

QuickBus© BackUps :
The THIRD LEVEL of BackUp is a complete backup of QuickBus© which is taken by the support staff at least once per month. This BackUp file is called sysbummm where mmm is the month DURING which it was taken. It is taken whenever system maintenance of any sort is carried out. This BackUp is also copied to both the QB BACKUP WEBSITE as well as to our local inhouse servers. Contact support at quickbus77@gmail.com if you should ever need to restore any BackUp other than the many backups available to you with - RESTORE -. BackUps ARE NOT IN second-by-second SYNC WITH YOUR BUSINESS AND SOME DATA MAY BE LOST.

Master PassWord and Staff Logins :

The Master Password :
Is the Password which was entered into the Registration Application as your required password and can be changed here. Do so with great care. For security reasons you will have to contact QBO support to issue a replacement if you forget your password.

This is a complete OFFICE and provides for the registration of STAFF to use YOUR QuickBus Office (QBO) (QBO) System. The STAFF are able to LogIn to your QBO from anywhere on the planet using any device which has browser capability. This includes DeskTops, NotePads, Tablets and SmartPhones. The STAFF LogIn names and passwords are controlled from this Admin Task.

DRIVER : Security Level 2 :
When a new DRIVER is added to the DRIVER table QBO adds this driver to the STAFF list with a security level of 2. This enables the DRIVER to LogIn to QBO to VIEW his RUNSHEETS or 14-DAY ROSTERS and/or eMail these to his personal eMail address that is entered into the DRIVER record. He is also able to check the ADDRESS Table for details about an address or view a MAP for that address.
The Driver Staff Login name is the DRIVER REFERENCE and a password is eMailed to the DRIVER as confirmation when he is added to QBO. DRIVERs can be eMailed a new password from the Driver Task.

STAFF : Seecurity Level 3 or 4 : This Task in the Admin section allows a) a change to the STAFF password or b) the registration of a new Staff member with security level 3 or 4. Level 3 provides the same level of access as any user who uses the DEMO system which means that deletions and access to the Admin Task are NOT allowed. Level allows the STAFF to delete records but NOT access to the Admin Task.

The Admin Task is only available to the owner of the QBO System because the functions in the Admin Task change functionality of the QBO system and can destroy some of the System Data.


Use with great care. Do ARCHIVE RUN before using these tasks.

The ARCHIVE run will store all COMPLETED Bookings and associated Jobs and accounting transactions so that historical business information remains intact.
These tasks require Security Level 5 access to be run = System Administrator.
If there is any uncertainlty about these tasks PLEASE call QuickBus support.

Clear ALL Operational Data #R1:

This Option #R1 will clear ALL information related to :
Customer Accounts, the General Ledger, ALL JOBs from ALL DailyDiaries, and ALL Quote Requests.
It will NOT clear any business data. Busines data is held in the following Tables : Customer, Address, Bus/Vehicle Table, Bookings, Itinerary Table and Driver.

Re-Initialize complete System: #R2:

This option will destroy ALL system data. Customer information, Address information, Bus information and Driver information will all have to be re-entered from scratch. There will be No Bookings, Jobs, Customer Transactions or Itinerary Tables. The only file that will remain will be the User Parameter File.

For further Options re. ACCOUNTING FILES see #R3 and #R4 below.

Payment System #R3 :

If no attention has been paid to using the FINANCIALS then the information which the System has accumulated to date needs to be re-structured so that the FINANCIAL and accounting records can be used and reported on from this time on.
ALL The Customer Accounts will be reduced to zero balance whether paid or unpaid.
ALL the entries (transactions) made to the General Ledger will be cleared to zero.
THEN all OUTSTANDING Payment details from the CONFIRMED Bookings will be reloaded to the appropriate Customer Accounts ie. Customers, CLIENTs and SUBBYs.

Clear Bookings, JOBs and Accounts #R4:

This task will CLEAR ALL THE DATA contained in Customer Accounts and the General Ledger PLUS CLEAR ALL JOBs (there will be no information available for DailyDiary (Operations ) PLUS ALL Bookings will be set as not yet edited and not yet confirmed PLUS any amounts paid against ALL bookings will be reduced to zero.

Child Protection Card Processing:

QuickBus Office (QBO) caters for the control of a Child Protection Card to be held by Drivers.
This card is known by various names throughout the world. In Queensland, Australia the card is known as a BlueCard. This is the CARDNAME that is loaded into QuickBus Office (QBO) as the default when each system is created.
The CARDNAME can be changed and the process can be switched ON or switched OFF in the Admin Task/User Parameters.
If BlueCard is switched ON then the CARD NUMBER and the CARD EXPIRY DATE will be requested for all DRIVERS and for all SUBBYs. SUBBYs are created/loaded/identified as part of the CUSTOMER database. If A SUBBY REFERENCE NAME ( 6 characters ) is loaded into a CUSTOMER record then that CUSTOMER becomes available as a SUBBY.
If BlueCard is switched ON then each and every time a DRIVER or a SUBBY is referred to and the BlurCard EXPIRY DATE has passed then QickBusOffice will issue a warning message. This is only a warning message in case the action that is being carried out does not require the BlueCard to be up-to-date or that it is known that the BlueCard is actually valid and the date has not yet been corrected on the Driver's or SUBBIE's record.

DailyDiary: Overview

DailyDiary / WorkSheet / Operations Section

There is a DailyDiary for every DAY that there are JOBs :
The design objective for is to create a COMPREHENSIVE OFFICE in a remote and SECURE location which:
a) -- makes the task of capturing ALL your business data as simple as possible.
b) -- enables any person to sign into your system as a new Customer to obtain a FREE QUOTE for a Tour, Charter or JOB which becomes a provisional BOOKING.
c) -- provides a PLANNING SHEET so that ALL aspects of a BOOKING can be adjusted (edited) to ensure that ALL the information is available with one click on a COMPREHENSIVE Daily Diary including an ITINERARY TABLE which serves as a trip COST CALCULATOR.
d) -- the Daily Diary empowers the day-to-day management of all the JOBs required for that day to ensure CUSTOMER SATISFACTION and the management of any unforseen emergencies in the most cost-effective and timely mannner possible.
AND e) -- automatically create accounting transactions for these jobs while providing the facility for the creation of customer transactions for any financial activities outside the management of the Bookings
AND f) -- providing compreghensive reports and statistics relating to all your business resources including the provision of any customised reports which can be requested by system owners
AT a cost which is a small fraction of the savings which are a result of NOT HAVING THE NEED FOR ANY OFFICE COSTS WHATSOEVER.

JOBs are created when a BOOKING is -CONFIRMED- .
A BOOKING must only be -CONFIRMED- when the PlanSheet is completely checked and correct with ALL required/available information. The JOBs are created with the dates and times and number of buses/vehicles required as input to the DAILY DIARY. The DAILY DIARY is there to ENSURE that all the requirements for a Booking will be in place at the correct date and time. The JOBs on the DAILY DIARY provide the mechanism to allocate DRIVERS and BUSES to each of the JOBs. The DAILY DIARY also provides for the CHANGING of DRIVERS and/or BUSES in a competely controlled process in the event of any challenges such a sick driver or broken down buses .... Managing all of these issues on the DIALY DIARY also ensures that ALL information regarding the execution of a Booking is done in one place so that it will provide a Business Log record of business activities for reference or statistical information at any later time.
Buses/Vehicles are allocated to JOBs on DailyDiary:
Drivers are allocated to JOBs on DailyDiary:
Notes made on DailyDiary create a Business Log:

DailyDiary : Processing

Because of the huge amount of data available on DailyDiary it is beneficial to widen the browser screen to use DailyDiary. Reading DailyDiary on a SmartPhone is still viable.
The Booking Form creates JOBs for each day and for each bus so that the business has a Daily Diary for the execution of the Booking at the correct time and on the correct days.
Example 1: A simple Booking would be a charter for 1 bus on one day with a PickUp and a Destination with the passengers returned to the PickUp. This would require one bus on one day so there would be one JOB created to handle that Booking on the appropriate day.
Example 2: A contracted school run for the period of 12 weeks ( one term ) requiring two buses for week-days only with 16 stops for morning and afternoon runs would require two Bookings (one for mornings to the school and one for afternoons) with very detailed Itinerary Sheets (to provide the Driver RUNSHEETS). This would require 2 JOBs (one for each Bus + Driver) for each of 5 days ( Mon to Fri ) for each week being 120 JOBs per Booking = 240 JOBs in Total. By completing PlanSheets for each of these two Bookings all 240 JOBs would be created for the correct time on the correct days when the Booking is -CONFIRMED- (locked in). From the resulting DailyDiarys (one for each day) the driver 14day ROSTERS can be emailed to the drivers or read by the drivers by LogIn to the system from their smartphones.
The Operations Section (staff or person) is now able to use these DailyDiarys to plan each day as far in advance as is convenient.
Page 1: Selecting a DailyDiary :
GoTo DailyDiary The default requirement for DailyDiary is for to-day and -GoTo DailyDiary- already has the QuickDate entered for to-day in dd format. If the day that you wish to use is one or two days previous or after to-days date it is best to click -GoTo DailyDiary- and then use the PrevDay -OR- NextDay to move to the required DailyDiary date.
Any DATE which exists on the report for -ALL- can be entered here to show all the JOBs for that Day. ddmm QuickDate format makes this entry very easy for THIS YEAR.

-OR- Days-with-JOBS A checklist of ALL the future JOBs DATES. One item per DAY. The list is in date order with an blue action button next to each date. Click the button and the DailyDiary for that day will be activated. There is only one entry per DAY and the list shows the weekday for that date plus how many jobs there are for that day.

-OR- SELECT_JOB Enter a JOB ID number (if it is known) and DailyDiary for that DAY will be displayed. All other JOBs for that DAY will also be displayed so that this action will provide information about all the other JOBs that were run on the same day as that JOB.

THE REPORTS : for the JOBs list all JOBs on-file for the next -WEEK- or -MONTH- -OR- all -FUTURE- JOBs (after todays date that have not yet been done -OR- -ALL- JOBs that are available on-file respectively. JOBs which have been archived will not be listed.

14_DAY_ROSTER produces a roster for the next 14 days worth of JOBs that are scheduled for EACH Driver on-file including SUBBYs. Remember that any screen can be printed and mailed by snail mail or displayed on Notice Boards although this is against the major design objective of the PAPERLESS OFFICE !! This roster can be displayed by clicking a few buttons at any time.
Page 2: DailyDiary :
Every red bar on DailyDiary indicates action that is required.
DailyDiary displays ALL the JOBs that require attention on this DAY. Muti-day JOBs are listed on EACH DAY that they are active. And one JOB is listed for each BUS/Vehicle that has been specified (on the PlanSheet) for that DAY. This is the reason for the 5 columns on the right-hand side of this panel. It is also important to refer to these columns when assigning or RE-ASSIGNING buses or drivers on a particular day due to crises situations (which is one of the major reasons for using QuickBus OFFICE.
JOB : This is the identifier number for this specific JOB. This ID would be used when -SELECT JOB- is used on Page 1.

Done : When the JOB is on-the-road (ie not waiting to be checked out or for the driver to arrive) the action button next to -Done- should be clicked. This cannot be done if either a driver or a bus has not been allocated.

Start : The START TIME for the JOB. The start time that on the Drivers RUNSHEET includes the time allowance entered into the PlanSheet in case time needs to be allowed for preparation or fueling etc..

End : END TIME for the JOB as per the Booking. Time allowance can be catered for.

Cust : This is the Customer ID number. Click on the blue action button (the AB) and the full Customer record will be displayed. -NEXT- can then be clicked to return to DailyDiary.

BOOKING : The NAME allocated to that booking will be listed. Click the AB and a complete VIEW of the BOOKING that created that JOB will be displayed. Once -CONFIRMED- only the ITINERARY Table can be changed. Receipts for that Booking can be made by going to the Booking and choosing -RECEIPT- or -JOURNAL- will ensure that the transactions entered will reflect on both the Booking Ledger and the Customer account.

Vehicle : If a vehicle / Bus has not yet been allocated to the JOB there will be a red bar present. Click the AB and a comprehensive ACTION LIST of all Vehicles/Buses, both Fleet (owned) and non-Fleet (belonging to a CUSTOMER and available for charter) will be listed. Red Bar indicates that the bus is NOT AVAILABLE. Could be flagged as bus-out-of-service or out on another JOB (multi-day bookings included) . Yellow-bar indicates that the bus belongs to someone else and it may be necessary to call that customer before allocating the bus to that JOB for that Day. The SUBBY mobile number will be shown in the NextServ column of the listing. All relevant information to make a choice is listed including JOB information, such as the number of Passengers required, is shown at the top of the panel. When a bus has been chosen Click the AB for that bus, the system will confirm that the allocation has been made and -NEXT- back to DailyDiary and that bus reference number will now appear allocated to the JOB.

If a BUS is already assigned (the reference number is shown) Click on AB to show the complete information record for that BUS. From there -NEXT will return to the DailyDiary -OR- -CHANGE- will offer the complete Bus listing to enable the selection of another bus. The bus that was allocated on DailyDiary before carries a red bar as a reminder. Now when -NEXT- is selected (twice) the JOB will have the new allocation and a note will be placed in the NOTES column with something like |V- VehicleRefNo on date was replaced.

Driver : The Driver follows the same pattern as the BUS allocation as above.
PLUS1 on the right hand side of the driver listing panel is a column called Schedule in the form of ~~~~~~~|~~~ . This histgraph shows the upright bar ( | ) for today with 7 tilde ( ~ ) to the left and 3 to the right. The ~ will be replaced by an x ( = driver already allocated to a JOB) or s ( = driver is on-leave, sick or not available ) for any of those 10 days. This is to ensure that drivers are allocated to JOBs in accordance with the Driver Fatigue guidelines.
PLUS 2 when the driver is already allocated to the JOB the AB displays the full drivers record but with additional blue action buttons for:
-NEXT- = Return to DailyDiary
-D_CHANGE- = Show driver listing to allocate another driver to the JOB
-D_REMOVE- = remove the driver from the runsheet so that I can do some checking before re-allocation at a later time
-ROSTER-14- = show a 14-day roster for this driver only
-RUNSHEET- = Driver runsheet with ALL the information necessary to do the JOB including the ITINERARY which would provide a driver with the details of a School Run or TOUR etc.

Notes : The NOTES on DailyDiary are intended to provide for ANY action which may be required for a JOB or for the OFFICE generally or just as a reminder or defining actions that have been taken after problems, accidents or any other issue. Click on the AB to ADD TO DailyDiary. Notes cannot be removed from DailyDiary. Counter Notes must be inserted if necessary.
These notes provide you with a business Log sheet which can be kept for referece as long as may be required. All subject to the cyscle of BackUps for the System which are stored on three different sites around the world.

V of D of T : The five columns read as follows: The sequence number of the Vehicle/Bus for this day for the number of units required for the Booking AND The Day number of the number of DAYS that the Booking covers AND the Destination Type where N = Normal E = Extended (Multi-day tours) T = One Way Transfers S = Split where V returns to depot after drop-off and goes back to Destination to return Pax. to PickUp point at some later time.

Impala Distribution and Marketing (2001)