Employee Expense and

Reimbursement System

Stuart Mackie
Computing 2004

The candidate confirms that the work submitted is their own and the appropriate credit has
been given where reference has been made to the work of others.

I understand that failure to attribute material which is obtained from another source may be
considered as plagiarism.

Stuart Mackie
Summary
Cooper Cameron (U.K.) Limited is located in Leeds and is a subsidiary of Cooper Cameron
Corporation, a U.S. Company. The Company utilises high technology business solutions including
SAP R/3 and a full range of Microsoft , manufacturing and engineering dedicated software.

The project addresses employee expense reports which are currently prepared and submitted for
processing on paper which is cumbersome and inefficient. The objective is to provide a web based
system to facilitate the submission of expense reports on a weekly basis which will form the basis of
making data available for departmental costs, financial related transactions and re-imbursement to
employees.

The system will be a satellite system to the existing SAP R/3 with bridging being executed by the
Company’s I.T. department.

This report documents the process encompassing the initial study, design, implementation and final
system evaluation.

-i-
Acknowledgements
I would like to give acknowledgement to the under noted for their time, advice and support given
throughout this project:

Leeds University – Computing Department

Stuart Roberts
Sarah Fores

Cooper Cameorn (U.K.) Limited

Jim McPhail (Director of Information Services)
Alex Woolley (Accounts Payable Manager)
I.T. Department Staff
H.R Department Staff
Accounts Payable Staff

- ii -
Contents
1. Introduction 1
1.1 The Company 1
1.2 The Project 1
1.3 Background Research 2
1.4 Project Schedule 2

2. Objectives 3
2.1 Main Objectives 3
2.2 Minimum Requirements 3
2.3 Additional Requirements 4

3. Analysis 5
3.1 Requirements Gathering 5
3.1.1 The Current System 5
3.1.2 Interviews 6
3.1.3 Existing Solutions 6
3.2 User Requirements 7
3.2.1 Essential User Requirements 7
3.2.2 Enhanced User Requirements 8
3.3 Chosen Methodology 8
3.4 Chosen Technology 8

4. Design 10
4.1 Database Design 10
4.1.1 Entity Relation Diagram 10
4.1.2 Database Entities and Attributes 12
4.1.3 Database Constraints 13
4.1.4 Database Normalisation 13
4.2 System User Types 15
4.3 User Interface Design 16
4.4 Coding Style 18
4.5 Existing System Integration 19

- iii -
 4.6 Security 20

5. Implementation
5.1 Database Implementation 23
5.2 Interface Implementation 24
5.3 Backup 31

6. Testing 32
6.1 Methods of Testing 32
6.2 System Testing 32

7. Evaluation
7.1 System Requirements 34
7.2 Methodology 34
7.3 Implementation and Testing 35

8. Conclusion 36
8.1 Future Enhancements 36
8.2 System Testing 36

Biography 37

Appendixes
Appendix A – Personal Reflection 38
Appendix B – Initial Project Schedule 39
Appendix C – Revised Project Schedule 40
Appendix D – Entity Relationship Diagram 41
Appendix E – Database Schema 42
Appendix F – ASP Code Extract 46
Appendix G – Sample Test Plan 47
Appendix H – Current Company Paper Expense Report 48

- iv -
1. Introduction
1.1 The Company
Cooper Cameron Corporation, a U.S.A. company is a leading international manufacturer of oil and
gas pressure control equipment, including valves, wellheads, controls, chokes, blowout preventers
and assembled systems for the oil and gas drilling, production and transmission used in onshore,
offshore and sub-sea applications. Cooper Cameron Corporation also provides aftermarket parts and
service to the energy industry worldwide.

Cooper Cameron (U.K.) Limited has a major manufacturing operation in Leeds and an aftermarket
facility in Aberdeen with the legal entity being a fully owned subsidiary of Cooper Cameron
Corporation. The U.K. subsidiary has over 1000 employees based in the U.K. and their operations
support Customer projects on a worldwide basis.

1.2 The Project

The aim of this project is to develop an Employee Expense and Reimbursement System for
Cooper Cameron (U.K.) Limited (Cameron.). The Company has in place a paper based system and
has conducted some basic research into new solutions. For a number of reasons they have not found
any satisfactory solutions and have been considering a custom solution at a later date that will
interface with the current SAP R/3 system they use.

The project will involve requirements analysis for, and development of an appropriate solution to
allow employees in the Company to submit expense reports electronically, instead of the current
process which is done on a paper template either through Excel or handwritten. The electronic
expense report system would take into account the procedures currently in operation by the Company
as well as produce a more modern technologically advanced system making the process more
efficient for all involved.

All employees of Cameron use the same paper system, and administrative employees are required at
various stages through the process to handle the paperwork and enter the data from the employee
expense report documents into an electronic format. Due to the nature and size of the Company, the
initial application for the system would encompass all locations under the U.K. Legal Entity. Future
rollout of the system may be used by the Company at all locations across the World who utilise the
SAP system.

-1-
1.3 Background Research
For this project to be successful and fulfil the system requirements, background research took place
for strategic areas of the project. After initial consideration of the project problem, it was apparent
that the following areas require research before being able to proceed :

• Data Protection
• Human Computer Interaction (HCI)
• Database Design
• Software Testing

These areas were researched before continuing with the project. References to these research
materials can be found on the Bibliography as well as referenced throughout the project. Rather than
devote a chapter explaining my findings, where a reference has been used I have explained the
information contained within the reference before considering how it affects the project.

1.4 Project Schedule

Due to the limited time available for this project, a schedule was produced early on in the
development. My original schedule as found on Appendix B was acceptable to work to until January
2004. Unfortunately due to additional pressures the schedule was not appropriate for work targeted
to be completed after January 2004 leading up to the submission date. Subsequently the Project
Schedule was re-structured to accommodate an appropriate time frame for this period. The updated
schedule can be found on Appendix C.

-2-
2. Objectives
2.1 Main Objectives
The main objectives of this project is produce an appropriate Expense, Reimbursement and Reporting
system for Cooper Cameron to replace their existing paper based system. The Company has
investigated a number of existing solutions and has found them to be inadequate for their needs.
They have since decided to have a custom solution produced which reduces the amount of time spent
by the employee and by the company processing expense reports. The new system should provide a
smooth and intuitive progression from the old paper system layout and process to the new electronic
version with the added advantage of automating the accounting transactions from the electronic data.
The current expense reports are manually transacted in SAP and the intention is to develop a system
that the Cameron I.T .Department can interface with and process into the standard SAP application.

The achievement of accurate expense report recording will automatically achieve significant
efficiencies in the reimbursement process

2.2 Minimum Requirements

For the system to fulfil the minimum expectations of users, the following minimum (‘must have’)
requirements must be achieved :

• Investigate appropriate methodology for use in the development of this project.

• Document user and system requirements through contact with the Company, and
examination and evaluation of their existing procedures.

• Investigate possible solutions and select the most appropriate.

• Implement full Back-End (databases) and initial Front-End (basic web interface) for
the appropriate solution.

• Carry out planned technical testing and resolve any issues.

-3-
2.3 Additional Requirements
If time permits, or for future system development, the following items have been considered:

• Implement Final Front-End

• Deploy the system for use at Cooper Cameron (U.K) Facilities.

• Carry out User Testing and make any necessary adjustments.

• Produce Appropriate Documentation for using the system

• Roll-out the Expense System for World Wide use.

-4-
3. Analysis
3.1 Requirements Gathering
The basis of any project is a good understanding of what the end product is targeted to achieve. In
the case of this project three areas are available to help define these requirements, The Current
System, Staff Interviews and Existing Solutions. These three areas have been explained in more
detail below. The information gained from each of these areas will then be compiled in a listing of
User Requirements which the system will have to fulfil to be successful.

3.1.1 Current System

The current paper based system was closely examined, and notes were taken while watching staff
members using the system. Various stages exist in the current system which were also examined,
since they have a significant affect on the final version of an electronic replacement system.

The major data elements in the current paper Expense Report document are listed below. A full copy
of the current paper Expense Report can be found on Appendix H.

For Re-Imbursement to Employees

Employee Name, Number, Location and Cost Centre
Expense Report Period – Week Ending dd/mm/yyyy
Expense Report Submission Date
Company Vehicle Registration & Mileage
Employee Account No. (Vendor No.)
Expense – Type
Expense – Date Incurred
Expense – Amount (Gross)
VAT Amount : Finance to Complete
Expense – Net of VAT : Finance to Complete
Expense – Account Code : Finance to Complete

Company Paid Expenses – Not For Reimbursement (information only)

Air Travel
Rail Travel
Car Hire

-5-
Other Details
Cash Advance Details
Currency Conversion Rates
Date & Location and Business Purpose
Signatory Details / Management Approvals

Special Notes – Exceptional Expense/Circumstances

3.1.2 Interviews
Meetings with a number of main members of staff involved with the system have been carried out. A
number of areas were discussed ranging from the existing paper based system and its performance, to
any areas which they felt the current system failed to accommodate. Notes were taken during the
meetings which were then reviewed to produce a listing of requirements.

3.1.3 Existing Solutions

There are a number of existing solutions available from small scale companies to more sophisticated
companies such as SAP. Cameron as well as being heavily Microsoft orientated also has strong links
with SAP, and is currently running SAP R/3 (recently converted from SAP R/2) through the entire
company. When Cameron started investigating existing solutions they primarily started with SAP
R/3. After receiving the information from SAP the company ruled out this option due to it poor
interface and spiralling costs which were in excess of £300,000 per office/plant with additional
annual fees for maintenance support. Cameron currently do not utilise the SAP R/3 H.R. module
which is a prime requirement to implement the SAP Expense Report module. Effectively the current
decision was to utilise a non SAP application with bridging interface to SAP R/3.

The problem found with most other available systems is either additional features which interfere
with the main requirement features needed by Cameron, or the system is too basic and does not fulfil
the Company’s requirements.

Unfortunately due to the costs and implementations of the existing solutions available, I have been
unable to get any hands on testing with available software to be able to discuss the positive/negative
attributes of the applications. Cameron advised me that they should be able to make available for
review the system profile of the SAP Expense and Reporting package. However, this was not
achieved due to the Companies decision not to purchase this module.

-6-
3.2 User Requirements
After reviewing the above three areas, it has been possible to produce a listing of Requirements
which this project has to target. These requirements have been split into two sections, Essential and
Enhanced. The Essential Requirements are those which the system will have to fulfil to be
successful, otherwise the project will fall short of the User and Company expectations. The
Enhanced Requirements are those which may provide extended use for the User and the Company.
These Requirements are not mandatory and could be included in the system at a later date after the
completion of the Project, or built into the project during development if time permits.

3.2.1 Essential User Requirements

Taking into account the previous analysis data extract, the following essential requirements were
derived :
• A web interface should be designed to allow employees to have access to the system.
• The system should store expense report data for at least 14 months, before moving it to an
archive.
• Employees should be able to submit expenses to the system which will be compiled on a
weekly basis
• The system must handle foreign currencies.
• The system should complete all Tax, VAT and other mathematical calculations required for
the Company and the User.
• The system where possible should provide a list of selectable items to accommodate any
restrictions on Expense types (i.e. Disallowable expenses for un-receipted claims above
£5.00 per item, baby sitters, spouse travel unless approved in advance, inappropriate
Entertainment, travel upgrades unless approved in advance, expense paid on another
employees behalf and office equipment which should be purchased on approved company
Purchase Orders etc)
• Security should be accommodated to make sure the system applies with the Data Protection
Act (1998). Under the Data Protection Act the Company has an obligation to ensure
records are “company confidential”. Expense Reports may include legitimate approved
expenses that must not be divulged. Examples would include Medical, Education,
Qualifications and Personal Information
• Users should only be able to view their own expense reports
• Employees who will be administering the expense report system should have higher
privileges, and control over settings used by the system

-7-
3.2.2 Enhanced User Requirements
• Options to store user preferences should be provided. These options include
preferred currency, car registration, personalised Expense categories.
• Scanners should be integrated into the system to allow receipts to be electronically
stored.

3.3 Chosen Methodology

There are a number of main methodologies which could be considered for use with this project.
These include the Waterfall Model, Spiral Model (as used as part of the Structure Systems Analysis
and Design Methodology) and UML. Due to the restricted nature of this project, both in size and
time, I do not feel it appropriate to adhere to a strict pre-defined Methodology but hope to take on
board areas of some methodologies which are more appropriate to this type of project.
Since this is a customised project specific to Cameron in an area which the company has not
developed for a number of years, it is likely that alterations will be required at various stages
throughout the lifecycle to the design and implementation. The Waterfall Model does not
accommodate this, and modified versions of the Waterfall Model which do support changes to the
specifications during development are still very restrictive due to the nature of the ‘Waterfall
Design’.
To accommodate the requirements of this project, as well as the ability to make changes during the
development process I will be using an Iterative approach. Iteration is one of the main features of the
Spiral Model and I plan on following the principals of this Model during this project.
UML is another methodology which I hope to use, although not in its full context. For this Project,
certain parts of UML will be beneficial, in particular in diagrammatical context in which UML can
be used to demonstrate the development of the system to the client, as well as provide a structured
view for areas of development.

3.4 Chosen Technology

Cameron is a large International company which is heavily reliant on computer technology. They are
heavily dependent on Microsoft technologies and after speaking with their main support departments
this will have to be taken into account when choosing appropriate Technologies. This project will
primarily require a web server, appropriate server side language and a database server. The company
has informed me that their preference in these cases for all new software they use is Windows 2003
Server running Internet Information Services (IIS6.0) which will facilitate the use of Active Server
Pages (ASP) for the server side scripting language. They have a number of database servers which
again are running on Windows 2003 Server with SQL 2000.

-8-
Cameron is currently in the process of upgrading their systems World Wide. Subsequently the
specifications for the chosen technology and systems which this software will run on have taken this
into account. Although this project would run on Cameron’s current system base, planning for the
completion of their upgrades which should be complete shortly was deemed the best action.

-9-
4. Design
This section of the report aims to investigate the design criteria required for the software before
moving on to implementation. The section is broken down into a number of main areas – database
design, interface design, security and coding style

4.1 Database Design

Through my analysis of the problem it was apparent that there was going to be a large number of
database entries on a regular basis, and a significant amount of information has to be stored. The
database design has to be efficient and accurate for use in the system for the immediate future, but
also be as flexible as possible to allow future software development to be incorporated without
compromising the design.

4.1.1 Entity Relationship Diagram

The first phase of the database design was to identify the central entities and relationships involved
and represent them on an Entity Relationship Diagram (ERD). E-R Diagrams are beneficial because
they do not contain any technical information which means they can be shown to the Company. The
Company can then comment on its validity allowing for any areas which have been overlooked to be
revealed early in the process. In terms of implementation of the final solution, E-R Diagrams ensure
that all user requirements have been considered and included.
The diagram below is a high level abstraction of the entities in the problem, and does not contain any
attributes for these entities. Appendix D contains an E-R Diagram taken at a lower level which uses
the information shown in the diagram below, with the addition of the data in the next Section
(Database Entities and Attributes). With the addition of these two Sections, the lower level diagram
demonstrates the final database design required for use in this project.

- 10 -
 Entity Relationship Diagram

Function Group

1
m
Cost Centre 1 m User 1 1 System Group

m
Expense Item m 1 Expense Report

[Figure 4.1.1.1 – High Level E-R Diagram]

Figure 4.1.1.1 shows the relationship between the basic entities required for the database. The values
‘1’ and ‘m’ represent ‘one’ and ‘many’ respectively, for use in describing the relationship between
two specific entities. For example ‘one’ user may have ‘many’ Expense Reports, and ‘one’ Expense
Report may have ‘many’ Expense Items.
The diagram was done at a high level so that no detailed entities were drawn, and the diagram could
be used to demonstrate the relationship between the various entities. The use of this low detailed
diagram was particularly beneficial to use with non-technical members of the company to check that
on principal to main entities of their expense report system were included and nothing obvious was
missing.

- 11 -
4.1.2 Database Entities and Attributes
Using the information gathered during investigation of the user requirements and the Entity
Relationship Diagram produced in Section 4.1.1, it is possible to compile a list of Entities and their
attributes required by the system to store real world data :

Entity Attributes
Expense Report Report ID, Claimaint ID, Description, Cash
Advance, Cash Advance Currency, Cash
Advance Currency Rate, Submission Date,
Approval Date, Payment Date, Status
Expense Item Item ID, Expense Report ID, Description,
Expense Date, Amount, Currency, Exchange
Rate, Receipt, Receipt Type, VAT Rate
User Accounts User ID, Username, Password, Email Address,
System Group, Employee ID, Cost Centre
Cost Centre Cost Centre ID, Name, Manager
Function Group Function Group ID, Name, Parent

The above five entities will form the central core of the final Expense and Reporting System
database. A final database scheme can be found on Appendix E. The final database scheme will
take into account the following sections which include Database Constraints and Database
Normalisation. Subsequently the final database scheme may have a different structure to the Entity
and Attribute list above, as well as include additional entities and attributes which are specific to the
system. The reason for this is that the above listing only covers the real world entries and attributes,
whereas the database will also have to accommodate the system side equivalents. Similarly it is
likely that database design changes will take place during Normalisation.

- 12 -
4.1.3 Database Constraints
When storing data in a database it is important that the type of data entered/stored is of the expected
type. Database Constraints suggested by Elmasri & Navathe (1999) are documented below :

Key Constraints
Attributes can be used to identify a record uniquely. There are different types of Key Constraints
which can be used, but if an attribute is made a Primary Key it means that the value of that particular
attribute can only appear once. The one value then represents the whole record uniquely from all
records.

Domain Constraints
Each attribute in a database must be of a particular data type such as an Integer or a String. Domain
Constraints allow a data types to be set for attributes. Only data which matches this data type is then
allowed to be entered for a particular attribute.

Entity and Referential Integrity

Referential Integrity guarantees that a foreign key matches with a primary key from another relation.
Entity Integrity ensures that a primary key is not null.

Functional Dependencies:
A Functional Dependency is where an attribute in one database is dependent on an attribute in
another database. A real world example of a functional dependency would be the name of a person
and their National Security number. In this case the persons name is functionally dependent on their
National Security number.

4.1.4 Database Normalisation

Database Normalisation is a vital part of database design. Normalisation is the process of comparing
a database scheme based on its functional dependencies and primary keys against a set of conditions.
As described by Elmasri & Nevathe (2000) and Roberts (2002) the following advantages can be
gained if database normalisation is carried out :

• The process of normalisation connects tables together for referential integrity. Without
referential integrity, it is possible to have data in one table which should pair/match with data
in another table but doesn’t. An example of this would be a car dealership ordering a car. A

- 13 -
 customer should be paired with a car if they have ordered it, but if referential integrity is not
maintained it would be possible for the system to store a car order with no linking to the a
customer.

• In a database system, poor design can result in data redundancy. This is where data is stored
multiple times unnecessarily. Data redundancy can produce inconsistency and makes
maintaining a database very difficult. As part of Normalisation, data redundancy is removed,
and if done correctly causes any tables with redundancy to be removed. This is done through
the use of primary and foreign keys.

• Normalisation makes use of primary keys at its various levels. An advantage of using
primary keys is the indexing it then allows the DBMS to provide. Primary keys are attributes
which can only exist once in a table which makes each entry uniqie. Indexing can therefore
be done using these keys which results in greater performance for almost all database
activities such as updating or deleting entries.

Normal Form is a progressive set of conditions with First Normal Form (1NF) being the least strict
through to Fifth Normal Form (5NF) being the most strict. Fourth & Fifth Normal Form are rarely
used, and there is an additional Normal Form called Boycee-Codd Normal Form (BCNF) which is
the equivalent of 3NF with a minor change. Below are explanations of the criteria for each type of
Normal Form.

First Normal Form (1NF)

For a database to be in First Normal Form all values in a table must be atomic and there must be no
multi-valued attributes.

Second Normal Form (2NF)

For a database to be in Second Normal Form it must be in 1NF and all non-key attributes must fully
depend on the key. To resolve any attributes which are not full dependent on the key, these attributes
are normally split from the table and moved to another.

Third Normal Form (3NF)

For a database to be in Third Normal Form, it must be in 2NF, and mustn’t contact any transitive
dependencies. An attribute is transitively dependent if it depends on another attribute which is
dependent on a key.

- 14 -
Boyce-Codd Normal Form
Boyce-Codd Normal form is very similar but slightly stricter than 3NF. A database is in BCNF if
every determinant is a candidate key. A determinant is an attribute which has another attribute fully
dependent on it.

In general a well designed database should comply with 3NF or BCNF and most database designs
aim to comply with 3NF or BCNF. This produces the best all round solution which avoids some of
the major pitfalls such as data redundancy and missing referential integrity.

I have completed a number of modules covering database topics and have developed great personal
interest in the subject area. I have found the more databases I develop the more natural I find
designing these databases to comply with 3NF and BCNF. There have been certain rare
circumstances where the design is better if it doesn’t completely comply, but this is rare.

4.2 System User Types

The Expense and Reporting System will be used by a wide variety of employees at Cameron. The
majority of these employees will be using the system to create expense reports, but a number of
specialist users also have to be accommodated. These two initial additional user types are :

Functional Group Managers

Function Group managers will be the first level of Administration above a basic user. When a user
submits a completed expense report, it will first be queued for authorisation by their manager. If the
expense report is valid the manager can authorise it, which then queues it for final audit/processing
by the Accounts Department. Although a manager is required to Authorise a member of staff’s
expense report, they should not be allowed to make any changes. It is against Cameron’s Company
policy for a Manager to make any changes to an employees expense report. If there are anomalies,
the expense report will not be approved

Accounts Department Staff

Members of the Accounts Department staff carry out the final level of Authorisation of an expense
report before the employee is reimbursed for their expenses. The Accounts Department will work
through a similar process as a Manager in terms of authenticating the expense report, but with one
major difference. Members of Accounts Department are allowed to make changes to an employees
expense report should any simple errors be found. Serious errors/omissions will result in the expense

- 15 -
report being rejected. The employee on accessing the system will see that the expense report has not
been released for payment.

The requirement for User Types and subsequently different levels of user permissions has a
significant affect on the design and implementation of the system. The two main areas which will
have to accommodate this in their design will be Security which is covered in Section 4.6, and the
User Interface which is covered in Section 4.3.

4.3 User Interface Design

The user interface for the system is paramount for it to be successful. The design of a graphical user
interface (GUI) has to be considered carefully since there a number of very important areas to
consider to achieve an efficient and user friendly GUI. As explained by Ruddell(2002) the most
important areas to consider for a user interface are :
•The GUI should have a consistent layout to allow users to quickly and easily become fluent
with the system.
• Appropriate user of colours is vital. Colours should be chosen that highlight important
areas, while making sure main bodies of text are readable.
• The system should automate tasks and data entry as much as possible, but avoid completing
sections differently to the users needs creating additional work.
• Display appropriate and clear error messages to allow users to quickly understand and fix
any mistakes.
• Page layout should be consistent and flowing.

Taking these important issues into account, the Expense & Reporting System interface will
incorporate the following :

• The interface will have a consistent design throughout for all user types. The interface will
include a two level menu system at the top, with the main content area underneath, and a
shortcut menu bar at the bottom.

• The colour scheme for the system will be based around the colour scheme that the
Company utilises. Matching colours will be used throughout the site for header and other
important areas. The main body section will be a white background with black text which
is the most comfortable solution for a user’s vision. The surrounding areas of content will
be ‘soothing’ to provide the user with a ‘comfortable’ interface to use.

- 16 -
 • The menu system will look very similar for all user types, but additional menu items will be
visible for Administrative levels of staff compared to a basic user. The menu system will
be available on every page within the site and provide access to all parts of the system.

• The system will automate data entry such as expense items dates where possible.
Automated data entries will either be fixed or editable after they are inserted depending the
particular data variable.

• The Company has a very up to date computer system. Although this is the case, it is still
standard for web design to accommodate 800x600 resolution computers. Since many users
are using the next resolution up (1024x768), a design which fills the screen using 800x600
will have a small ~100 pixel border down both sides which will be incorporated into the
design.

• The system shall accommodate three main error notification types. On submitting data
into the system, any data entry errors will be displayed to the user via a popup error box.
Errors related to data entry where the system believes the user has made an error will
displayed as a Advisory error to the user, but shall not affect the progress of the user in the
system.

Any System errors shall be ‘caught’ and processed to allow for system maintenance and problem
resolving. The user will not see this message, but instead be provided with an appropriate message
indicating the position of the system. Fatal errors where the system is effectively offline should be
avoided at all costs, and where practical the system should still function at a lower capacity to avoid
user inconvenience.

- 17 -
4.4 Coding Style
As with any software, continued development and future expansion is always present. Since this
project is to produce software for use by a third party, it is likely that future development will
required by the writer, or possibly developed further internally by the company. To make it possible
for the software to be easily developed at a later date, the structure of the coding has to have
consistent formatting. This makes it possible for any experienced programmer to understand the
methods used, and be able to quickly understand the code to continue development. Although this
project uses the programming language ASP, coding conventions apply to any language. As such I
found the explanations of Wrox – PHP Programming (2003) below most helpful:

• Variable names will be comprised of an initial letter or word which describes their type e.g.
s for string, i for integer. The initial letter will then be followed by a word which describes
the relevance or originating source of the variable e.g. a web form variable may be
“sForm….”. Finally an appropriate term will be used to distinguish variables e.g. the login
web form may contain the variables “sFormUsername” and “sFormPassword”

• Function naming will use mixed case naming through out to provide a consistent format.
The names for functions will be such that they will be obvious to the reader their intention,
and the context they can be used in. For example a function for carrying out user
authentication may be “function getUserId {….}”

• Although consistent function naming should provide a significant amount of information to

a developer, it may not be obvious the nature in which the function can be used and the
information required to use it. Subsequently it is important that functions and important
areas of code are appropriately commented. A popular method of commenting function is
based on the ‘JavaDoc’ commenting format which will be used in this Project. The format
of this type of commenting is demonstrated below :

/**
* @param string – time to be set
* @ return boolean
* @access private
*/
function setLoginTime( dtSysTime ) {
return true;
}

- 18 -
4.5 Existing System Integration
Through my initial research and contact with Cameron there was a need to provide system
integration in two areas. The company is extensively reliant on Microsoft technologies for day to
day client and server usage. They are currently still running NT Servers in a Domain Environment
with Windows 2000 and XP Workstations. Their final testing period has just completed for a full
rollout of Windows 2003 Servers with full Domain integration and Windows XP workstations.
Subsequently to avoid creating a new login system with its own user database for the Expense &
Reporting system, it is much more efficient to integrate the new system with Microsoft Active
Directory.
The Company requested that they be able to complete the integration with their new network since
they would also be upgrading other custom software to achieve the same result. To achieve this
within the software I have produced login and authentication functions within the software which are
used as their names suggest. The Company can integrate the Expense & Reporting System with their
Active Directory rollout by modifying these functions to interact and question Active Directory.
Since the functions are well documented through the coding standards explained in 4.3, the Expense
and Reporting system will not be affected as long as the changes made to the function comply with
the documented design of the functions. In particular the system expects to pass the to function
certain pieces of data, and expects a particular reply.
The end result of this integration will be a better streamlined use of the software for the user.
Company employees will be able to access the system using their primary network logon credentials
removing the possibility of problems when users are required to use different credentials for each.

Although the company is reliant on Microsoft technology for the networking environment, they also
have a similar level of reliance on SAP R/3 for many of their central software systems. With
particular respect to the Expense & Reporting system, SAP R/3 is used for processing information
between bank accounts, company transactions and employee salaries. The previous paper system
required an administrative employee to transfer the Expense sheets into SAP R/3 manually. With the
Expense & Reporting System each employee will enter the data for their own expenses which will be
stored in a central SQL Server database. The Company again wants to be able to gain access to this
data to automate the payment process through SAP R/3. This particular need does not have a direct
impact on the Expense & Reporting software, but well designed and accurate databases are required
to support the payments as well. The Company has a number of SAP specialist staff who will write a
bridging script to retrieve the data they require from the Expense and Reporting system databases and
process accordingly into SAP R/3 for further use. This is slightly inefficient since there will be a
small quantity of data redundancy between SAP R/3 and the Expense and Reporting system, but SAP
R/3 only requires a small number of database values per expense report, compared to the vast amount

- 19 -
of data stored in the developed Expense Report system. Subsequently there is little concern over
doing this, and the SAP R/3 integration can be view as a higher level summary of the expense reports
stored within the new system.

4.6 Security
In the last few years Security in the Computing Industry has become a business in its own right. A
number of companies and software developers have overlooked this area subsequently leading to
spurious vulnerabilities. As discussed by Efford (2004), one of the main reasons for these security
problems in software was a view taken my many companies that the functionality of the software
being first priority with security being added/patched on afterwards if required. Effectively security
was a secondary consideration within software, and was seen as a ‘bolt-on’ which was added to the
software. Unfortunately with these development attitudes and practices, software does not provide
adequate levels of security and consistency required in today’s high technology world.
Taking this into account, the only way to provide a system that is secure is to take account of these
security problems during design rather than during implementation. The section of the report borders
Design and Implementation due to the nature of Security. As such many implementation decisions
will be made at the same time as designing security into the system since it is not suitable to have one
without the other.

Cameron is a large organisation with offices across the world. The Company takes security very
serious, and requires this system to include adequate protection. Due to the nature of this system
there are a number of areas which are susceptible without consideration for effective security
protection:

• On completion of the Company’s upgrade as discussed in section 4.4, the system integration
will vet the users when they logon with their credentials to the Expense System, since the
system queries an AD Domain Controller. If the credentials are correct the user is allowed
access to the system. The Company requires this and will take steps when completing the
integration by securing the data transmission between the client and server. Since the
programming language used for this project is a Microsoft Language, the language provides
appropriate integration with other Microsoft technologies such as AD.

- 20 -
• The system is highly dependent on Microsoft SQL Server to store the system date. If an error
incurs when using the database such as invalid parameter being passed as part of a query, the
system by default displays a detailed errors message. These error messages can disclosure a
large amount of information about the server, but more importantly it would give an attacker
information about specific databases and their tables which can then be abused in particular
attacks. To secure against this vulnerability the system will detect error messages and provide
a custom error message which will inform the user of a problem without disclosing any
underlying data. A system administrator can then be informed of the problem and appropriate
action can be taken.

• A number of different user types will have access to the system, ranging from basic users
who will be submitting their Expense Reports, to administrative members of the Finance
Department who will authorise employee Expense Reports. Each user of the system will have
a user level. When a user logs into the system, the system interface will be customised to
allow access to areas granted to that particular user level, and additional areas only accessible
to higher privileged users will be hidden.

• Although the interface displayed for a user is customised to their permission level, there is the
possibility of a malicious user attempting to gain access to areas they are not authorised to
access. The system will accommodate this by authenticating the users rights for each
webpage in the system. When a user requests any page, the system will compare the user’s
privileges with the required level for the page. If the user does not have the required privilege
level the system will deny access to that page and inform the user appropriately.

• Data entry into systems is another area which can be exploited by malicious users. A number
of vulnerabilities have been made public recently which allow a user to enter data into a web
form which when submitted cause the server to carryout an action written by the user. To
protect against this type of problem all user entered data will first be verified by the system as
a correct data type for that question, i.e. an error will be presented to the user if they enter
words in the form where numbers should have been used.
User data will also be examined for malicious code to make sure the system is protected
against any future software flaws made public which apply to the database server.

• The System from a basic point of view has the user entering data through a web page which is
then stored in a database. When the user enters their data into the web forms, the data has to

- 21 -
be transmitted across a network to the server to be processed. The standard way of
transmitting this data uses the Hypertext Transfer Protocol (HTTP) which sends this data in
plain text across the network. If no precautions were taken, the data could be monitored by a
third party allowing abuse through information disclosure or data modification. To protect
against this the web interface will use Secure Sockets Layer (SSL) with Secure Hypertext
Transfer Protocol (HTTPS). The process requires no alteration to the coding of the software
because the transmitted data is encrypted separately on the client before transmission, and
decrypted on the server when received.

- 22 -
5. Implementation
This section of the report show how the design decisions made in Section 4 were used in the final
implementations.

5.1 Database Implementation

In section 4.1 the design of the database was completed using the User Requirements and Entity-
Relationship Diagrams which was then processed using Database Normalisation. The database
design described was then built in SQL Server to store the data for the system. Once the design was
created in the SQL Server there was no other work required specific to the database implementation.

Once the database was complete, work was then required to produce appropriate SQL Queries to be
used by the interface. When a user views a page in the system, it is likely that the page will contain
dynamic content which will be retrieved from the database. To retrieve this data the website uses the
ASP scripting language which connects to the server, executes the query and returns a result or data.

An example query written for use in the system is a basic query which authenticates users when they
first login to the system :

SELECT u.screenname, u.pass, g.permission

FROM dbo.user_accounts u JOIN dbo.system_group g ON u. user_system_group=g.id
WHERE u.screenname= “[frmUsername]” AND u.pass= “[frmPassword]”

The above query will then return the result of the query which can be used by the system. Since the
each user’s username should be individual, if the user has entered a valid username, the query should
only return 1 result.

- 23 -
5.2 Interface Implementation
The interface for the Expense and Reporting System has been broken down into a number of areas to
allow more detailed examination of the chosen design.

Main Design

[Figure 5.2.1 – Main Interface Design]

The screenshot above shows a general view of all the areas which will be covered in later sections.
The design and colour scheme for the website is consistent throughout, and as seen on the screenshot
the design accommodates all the design criteria specified in Section 4.3.

- 24 -
Menu System

[Figure 5.2.2 – General User Menu System]

[Figure 5.2.2 – Managerial & Account User Menu System]

The General User Menu System (Figure 5.2.2) forms the basis for all user types that have access to
the system. The menu is straight forward and intuitive for the user to use. The user firsts selects the
topic area that they would like to access. A second menu is then displayed with selectable options
dependent on their initial main menu choice. The user can then select which particular task they
would like to carry out and is taken to the relevant area of the system.

The second menu screenshot (Figure 5.2.2) shows a very similar menu to that used by a General User
which is for use by Function Manager or Accounts Department staff. The difference between the
menu system is the additional options which allow these higher privilege staff to review general user
expense reports for authorisation.

The custom menu system which is specific to each user type is vital for two reasons. Firstly, for ease
of use it is important that users only have to choose from the menu options which they should have
access to. The visibility of options not available to that user would cause confusion and waste a users
time. Secondly from a security point of view, if users were shown a menu system with options not
applicable to their user type, some users may be tempted to try and gain access to these areas of the
system. Although security has been designed into the system which would block their access, there
is nothing to gain by encouraging this type of behaviour. The visibility of these additional menu
items would also disclose information about the system unnecessarily again creating security
implications.

- 25 -
Content Area (Including Use of Text Formatting)

[Figure 5.2.3 – Main Content Area & Text Formatting]

Figure 5.2.3 demonstrates the use of appropriate colours and space for the main content area. As per
the design specifications the main content area uses primarily black text on a white background but
this does not have to mean the site design has to be white all over. The design incorporates a blended
surround down either side of the content area and any other areas of the interface where the
background can be seen. The reason for choosing this type of design was to make the interface more
comfortable on the eyes for the user while still using the well tested black text with white background
for the main content which is known to be the best combination to make reading easier on the eyes.

Figure 5.2.3 also contains an example of each font style used within the site. The implementation of
the text within the site mainly uses the HTML commands <H1> through <H6> and <P> (normal
paragraphed text) which is a specific set of HTML components for text. The advantage of using
approach is two fold. It is very easy when adding new pages to the system to use appropriate heading
styles for areas of text if you know in advance what styles are available to you. Also, the use of these
HTML commands integrates well with ‘Accessibility Features’ provided in most Operating Systems

- 26 -
and Browsers. These Accessibility Features allow user to over-ride these settings to accommodate
particular disabilities. For example although appropriate sizes and colours have been chosen for the
text used on the interface, a disabled employee with an eye sight condition (e.g. colour blind) could
adjust their Operating System Accessibility Options to over-ride the <H1>-<H6>. This would then
allow the rendered interface to make use of the user defined settings to accommodate the user’s needs

User Summary Data

[Figure 5.2.5 – User Summary Screen]

It is likely that users will log in regularly after submitting an expense report to get an update on its
status. Since this is a task likely to be carried out often, an expense report summary was integrated
into the main entry page of the system. This means that every time a user logs into the system they
will have instant access to the status of their expenses.

- 27 -
Expense Report Creation

[Figure 5.2.6 – Expense Report Creation]

When a user creates an expense report they will use the interface as pictured in Figure 5.2.6. The
creation of an expense report requires the user to enter general information which is applicable to all
the expense items added to the report. Some sections of the report are automatically filled in for the
user which the system does not allow them to edit such as their Cost Centre number. There are a
number of different types of form entry boxes which the user is requested to complete. To reduce
user error and decrease the time to enter the data,, where possible the user is given a drop down list
which is populated in advance. Form features such as drop down lists also assist in restricting the
type of data the user enters.

Once they have completed the form, the user selects ‘Create’ at the bottom to create the report in the
system. Once the report is created in the system, the user is questioned whether they would like to
add expense items to the report. If they select yes they are taken to the Expense Item Creation
screen, otherwise they are taken to their expense report summary page which will now contain the
new empty expense report which can have expense items added later.
Additional control buttons are also given at the bottom of the report to allow the user to reset the
form if they want to start again, or cancel the form if they no longer want to enter a report into the
system.

- 28 -
Expense Item Creation

[Figure 5.2.7 – Expense Item Creation]

Expense item creation is very similar to expense report creation previously explained. The item
creation form again makes use of the different data entry types to restrict the user’s entries. The form
also where possible calculates appropriate data values such as the amount of VAT on an expense
item. When the user enters the Receipt Total and the VAT Rate, the system will automatically
calculate the amount of VAT. Since the system has calculated the VAT amount, there is no need for
the user to be able to manually alter this since it was based on their previous data entry, the system
does not allow the user to manually enter the figure.
Expense items can be categorised into a number of areas. The system makes available a pre-defined
list of Item Expense Types for the user to choose from for each expense incurred. One main
advantage of providing the list for the user is to avoid the different descriptions each user may give to
the same expense. It also allows the system to restrict what types of Expense the employee can claim
for, although the system does allow the user to over-ride the provided list because there are situations
where a claim is valid but doesn’t naturally fall into a pre-defined category.

- 29 -
Managerial & Account Staff Administration Pages

[Figure 5.2.8 – Administration Pages]

The Managerial and Accounts Staff system interface is very similar to that of the general user. The
main differences as seen on the Summary screenshot in Figure 5.2.8 is that the
Managerial/Accounting Users are able to see submitted expense reports made by general users. As
well as being able to see general user expense reports, the Managerial staff of a function centre have
additional options buttons visible in the expense report to allow them to ‘Authorise’ or ‘Reject’ the
expense report.
Accounts staff an identical set of additional options, but they also have the ability to modify the
expense reports if they find an error.

- 30 -
User Preference Page
The system supports an initial small number of user preferences which are used to improve the use of
the system for the user. As seen on Figure 5.2.9, the user can store their preferences such as Default
Expense Type. With company expenses, in a number of circumstances, many users submit expenses
for regularly occurring events. When an expense item is added to an expense report the user has to
select the ‘type’ of expense item which best describes it.

5.3 Backup
As with any system it is vital for appropriate backups to be taken. The Expense and Reporting
System will be hosted on a web server and database server within Cameron. Cameron already have
other systems which have similar requirements and as such have a documented and planned backup
policy. The data in the database is the most important part of the Expense and Reporting System in
terms of backup requirements since this is where all vital data is stored. The web interface which is
hosted on a web site is less important in terms of regular backup because it will rarely have any
changes made to it compared to the database which will have new data being added all the time.

- 31 -
6. Testing
Testing for any software is vital to its success, and it is no different for the Expense and Reporting
System.

6.1 Methods of Testing

There are a number of methods of testing which could be considered. From experience I have gained
from Jesty (2002) the three main methods I considering using were :

White Box Testing

This testing method carries out test at the code level for errors. White Box testing tests that functions
and pieces of code carry out their original design correctly. White box testing can be carried out
during the development.

Black Box Testing

This testing method carries out test which examine the input and outputs of the software. Black box
testing primary focuses on extreme and normal values of data entering and leaving the system. This
means that software normally has to be at an advanced stage before Black Box testing can be applied.

Acceptance Testing
Acceptance Testing is a form of Black Box testing which makes use of user interaction of the system
to find problems. Acceptance testing is normally carried out by the software writer giving a scenario
to a final user of the system and asking them to carry out the tasks just like they will do when the
software is complete. The user is then asked to make comments as they work through the scenario,
and point out any errors they come across. Is it normal practice for a system developer to monitor the
test because there may be errors found which the system user does not see or understand.

6.2 System Testing

At the start of this project I knew that detailed testing would be required to be sure that the software
had no bugs. Because of this, I chose to use a combination of black box and white box testing during
development and acceptance testing at strategic areas of development.

During the initial implementation phases of the project it was possible to carry out White Box testing
on the ASP functions and code to validate that the carried out their purpose correctly. This testing
was less formal than the other two methods used because each function required a different
combination of data, and execution of pieces of code resulted in multiple areas being affected.

- 32 -
Black Box testing took place when sections of interface, its ‘back-end’ code and validation code were
complete. This testing was more formal than the White Box testing and comprised of using extreme
and expected values for data inputs and outputs. It was then possible to examine the results and
comparing the actual result with what was expected to find any errors. An example test plan can be
found below, and a copy of an actual test plan found on Appendix G.

Test Section:
Form Field Test Data Expected Result Actual Result

[Figure 6.2.1 – Example Black Box Test Plan]

Acceptance testing also contributed significantly to the full testing of the software. Acceptance
testing started at a later stage to the Black Box and White box testing because it was dependent on
user interaction with the system. Acceptance testing was particularly beneficial for testing data
related to the user interface, although there were a few issues raised by some of the staff regarding
missing data entries on certain forms.
Since Acceptance testing was carried out later in development, there was a risk that any significant
system design problems being raised by users at such a late stage in development would be
impossible to fix. To avoid this happening, new sections of the interface were made available to
users when they were completed to have the acceptance testing carried out just in case a major error
was found. The one restriction I found with acceptance testing was trying to get the company to
make time to carry it out. The Company and staff have their normal work to get done during the day
and the acceptance testing, although kept as short as was possible, still consumed some of their
valuable time. Taking this into account, the main testing was therefore definitely placed on Black
and White box testing.

The testing carried out was extremely important in the lifecycle of the project and helped root out a
number of faults which were then rectified.

- 33 -
7. Evaluation
7.1 System Requirements
At the start of this project there were five minimum requirements and five additional requirements as
documented in Section 2.2 & 2.3. On completion of the project the solution produced fulfilled all
five minimum requirements and three out of five of the additional requirements, these being the
following :

• Implement Final Front-End

• Carry out User Testing and make any necessary adjustments.

• Produce Appropriate Documentation for using the system

The two additional requirements which could not be accommodated were “Deploy the system for use
at Cooper Cameron (U.K) Facilities” and “Roll-out the Expense System for World Wide use.”
Unfortunately Cooper Cameron is in the process of a major World Wide network and systems
upgrade to rollout Windows 2003 Servers in a Domain Environment with Windows XP Professional
workstations. At the same time the SAP R/3 Human Resources module is also being rolled out.
Taking this all into account the company could not accommodate the addition of the software to their
schedule and will review the situation in the coming months.

7.2 Methodology
For this project is chose to take an Iterative Approach to the development rather than follow a pre-
planned Methodology. On looking back I am glad I decided to make this decision. During the
development of the software there have been a number of occasions where I have had to go back one
or two stages of the development process to make a change to the design because of information
provided late by the company, or by over-sight during those initial stages. If I had chosen a more
formal methodology, going back that far in the development process may not have been possible.

In saying this, during the project development modules taken at University I was made aware of this
type of situation occurring. To try and prepare in advance in case the need did arise, I specifically
tried to design the software in a module fashion which would allow the change to some modules
without having a major knock on effect. If the software had not been designed in this manner I
believe I may have had significant problems in meeting my scheduled dates because of delays.

- 34 -
The Iterative Methodology was subsequently a good approach to take with this project because it
allowed me to move back in the project development at any point, which is not possible for many
other methodologies.

7.3 Implementation and Testing

The implementation of the system was the most enjoyable part. I was glad to have spent as much
time concentrating on the design to reduce any problems incurred during implementation. During the
implementation one factor which was always in my mind (which was covered during my design
considerations) was to allow for system expansion, without affecting the already implemented
system. To achieve this I found that treating each entry point in the system as its own entity was the
best way to get this effect. The method allowed me to produce a modular type system so that
additional modules could be plugged in which would work straight away, without requiring a
significant amount of work to be done on the system already developed.

The testing of the software took longer than expected to complete. I tried where possible to carry out
testing during development once a function, or full sections of the system was completed. This was
beneficial because it allowed me to catch obvious coding errors early during implementation, rather
than produce large numbers of errors at the end. I suspect my chosen methods of testing may have
been too pedantic for the type of system I developed, and if I were to develop another project again, I
may spend additional time investigating other possible methods, or adjust the proportions of the
methods I used in this case.
In saying this, the tests did find areas of the system where data was not validated correctly, or the
automation of an entry field did not take place. Without carrying out this testing the system would
have been made available with a number of bugs which would not have been acceptable and as such
the testing which took place was a success.

- 35 -
8. Conclusion
The expense report project was a good choice and brought complexities in areas that go beyond the
technical attributes of the system. I had direct involvement in discussing the H.R. concern that the
processing of expenses is a key issues for employees in terms of their personal cash flow, but at the
same time conforming to Management demand of adherence to Company Policy on spending and the
need to limit spending to budgeted levels of cost. In addition financial Managements had to handle
the adherence to financial rules related to external parties, Banks, VAT Claims and reporting,
electronic payment systems (BACS) and approval in accordance with a defined structure of
hierarchy.

The data base and web development was extremely satisfying and the output results I feel meet the
demands of a quality company as Cooper Cameron is.

The current downside is the position where the Company has moved focus (temporarily) to review
the SAP H/R system. The intention is still not to utilise the SAP R/3 Expense Reporting module
since the H/R implementation will demand significant resource. At the appropriate point in time the
dedicated system as written will be reviewed and implemented in accordance with the requirement at
the time.

8.1 Future Enhancement

The developed system may be enhanced to support the following :

• Company Car mileage records and employee incurred vehicle costs.

• Reporting and analysis module to maximise the use of the database that could be extended to
record additional information such as Hotels utilised and analysis of cost on durations for
specific trips.
• An additional interface could be added to support mobile users with access to any mobile
enabled devices such as Smart Phones, Blackberry’s or Palms etc.
• Handling and communicating of expense receipts which proved to me a major issue due to
the external implication of VAT and internal checking/audit processes.
• Interface with Corporate Credit Cards to minimise cash advances and enable employees to
have minimum use of personal cash.

- 36 -
Bibliography

Baartse, Conway, David, Li, McFarlane Palmer, Stephens, Virdell, Williams, Wilton, Wooton, Yates
(2001), Professional Javascript 2nd Edition, Wrox

Dix A, Finlay J, Aboud G and Beale R (1998), Human Computer Interaction 2nd Edition, Prentice
Hall

Efford N. (2004), Secure Computing – SY32, University of Leeds

Elmasri & Navathe (2000), Fundamentals of Database Systems – 3rd Edition, Addison Wesley,
Chapter 14.3

Howard and LeBlanc (2003), Writing Secure Code 2nd Edition, Microsoft Press

Jesty. P (2002), SO22: Software Project Management, University of Leeds.

Lea, Buzzard, Cinis, Thomas (2002), PHP mySQL Website Programming, Wrox, Chapter 2.

Paul Wilton (2000), Beginning Javascript, Wrox

Roberts S. (2001), DB11: Introduction to Databases, University of Leeds.

Ruddell R, P Brna (2001), SI23 Introduction to Human Computer Interaction, University of

Leeds

Shneiderman, B (1998), Designing the User Interface, Addison Wesley

W3Schools (2004), ADO and ASP Reference Guide, URL:

www.w3schools.com

- 37 -
Appendix A: Personal Reflection

I found it constructive to take time and look back at the project and consider my experience.

The selection of the expense report system gave me an opportunity to evaluate what I already thought
was a fairly complex system, and at the same time recognising the importance and complexity in
developing the system within a company with major systems already in place.

In fact as I developed the design and system parameters I discovered that the requirement was even
broader than I initially thought, and this gave me the opportunity to develop my knowledge on
databases, web design and the discipline of project management.

I did incur some major drawbacks in the form of restrictions. The company decided not to pursue the
SAP R/3 Expense Reporting module since at the beginning they did not proceed with the H.R.
module which was linked to the expense report segment. This meant I did not get access to the SAP
R/3 expense report system. I also found that the expense receipts were problematical since they are
required to be reviewed by the company finance department (VAT Reporting etc). This required me
to “tag” the receipts by a unique number to link the receipts to the electronic expense report.

Involvement in the project encouraged me to focus on the following :

• Experience in discussing the project with management and selective employees of the
Company.
• Broader understanding of the day to day issues that impact a project of this complexity and
solutions found by discussion with involved parties.
• Benefit of exchanging ideas in both design and system concept taking into account the
technical attributes of the various systems I intended to use.
• Evaluation of business related attributes of expense reports from an Accounting, Management
and employees standpoint.
• The need to be prepared to change direction in system development to take into account
obstacles and problems encountered in the system development process.
• Adjust timetables to make up for lost time due to various development changes in design,
misunderstanding on key issues by either the Company or myself.
•Security attributes were high on my list and this was clearly a major item for a large company.

- 38 -
Appendix B: Initial Project Schedule

- 39 -
Appendix C: Revised Project Schedule

- 40 -
Appendix D: Entity Relationship Diagram

system_group user_accounts cost_centre

PK id PK,FK3 user_id PK id

display_name user_screenname display_name

permission user_pass FK1 function_group _id
user_email
user_remind
FK1 user_system_group
employee _id function_group
FK2 cost_centre_id PK id
last_login_ip
last_login_host display_name
expense _report _authorisation last_login_date parent _group _id
status
PK id deleted
created _date
FK1 expense_report _id modified _date function_group _manager
user_id deleted _date
date PK,FK1 id

function_group _id
manager _id
expense_report _auditing

PK id expense_report

FK1 expense _report _id PK id

user_id
date FK 1 user_id
expense_status_log
description
cash_advance PK id
FK 2 cash_advance _currency_id
cash_advance _currency_rate FK1 expense _report _id
date_submission approver _id
date_approved notes
expense _item date_audited
FK 3 status_id
PK id

FK1 expense_report _id expense _status_type

description
date PK id
currencies
amount
currency _id PK id description
exchange_rate
receipt description
vat_receipt symbol
vat_rate

- 41 -
Appendix E: Database Schema

A red attribute indicates a Primary Key.

• user_accounts
Columns Data Type Allow NULLS Default Value Other
user_id int(4) No Auto Increment
user_screename varchar(100) No
user_pass varchar(40) No
user_email varchar(150) No
user_remind varchar(100) No
user_system_group int(2) No
employee_id int(10) No
cost_centre_id int(4) No
last_login_ip varchar(15) No 0
last_login_host varchar(100) No
last_login_date timestamp No
status binary(1) No 1
deleted binary(1) No 0
created_date timestamp No
modified_date timestamp Yes
deleted_date timestamp Yes

• system_group
Columns Data Type Allow NULLS Default Value Other
id smallint(2) No Auto Increment
display_name varchar(100) No
permission varchar(20) No

• cost_centre
Columns Data Type Allow NULLS Default Value Other
id int(4) No Auto Increment
display_name varchar(100) No
function_group_id smallint(2) No

- 42 -
• function_group
Columns Data Type Allow NULLS Default Value Other
id int(4) No Auto Increment
display_name varchar(100) No
parent_group_id int(4) No

• function_group_manager
Columns Data Type Allow NULLS Default Value Other
id int(4) No Auto Increment
function_group_id int(4) No
manager_id int(4) No

• expense_report

Columns Data Type Allow NULLS Default Value Other

id int(4) No Auto Increment
user_id int(4) No
description varchar(500) No
cash_advance binary No
cash_advance_currency_id smallint(2) No
cash_advance_currency_rate double No
date_submission timestamp No
date_approved timestamp No
status_id int(2) No

- 43 -
• expense_item

Columns Data Type Allow NULLS Default Value Other

id int(4) No Auto Increment
expense_report_id int(4) No
description varchar(500) No
date timestamp No
amount double No
currency_id int(3) No
exchange_rate float No
receipt int(1) No
vat_receipt int(1) No
vat_rate double No

• expense_status_type
Columns Data Type Allow NULLS Default Value Other
id int(2) No Auto Increment
description varchar(100) No

• expense_status_log
Columns Data Type Allow NULLS Default Value Other
id int(4) No Auto Increment
expense_report_id int(4) No
approver_id int(4) No
notes blob No

• expense_report_authorisation
Columns Data Type Allow NULLS Default Value Other
id int(2) No Auto Increment
expense_report_id int(4) No
user_id int(4) No
notes blob No

- 44 -
• expense_report_auditing
Columns Data Type Allow NULLS Default Value Other
id int(2) No Auto Increment
expense_report_id int(4) No
user_id int(4) No
notes blob No

• currencies
Columns Data Type Allow NULLS Default Value Other
id int(2) No Auto Increment
description varchar(100) No
symbol varchar(20) No

- 45 -
Appendix F: ASP Code Extract – System Logon
<%
if (Request.Form("act") == "auth") {
%>
<!--#include virtual="/projectConnections/database.asp" -->
<!--#include virtual="/projectIncludes/objConn.asp" -->
<%
var objConn = Server.CreateObject("ADODB.Connection");
objConn.Open(database_conn_string);

var txtUsername=Request.Form("frmUsername");
var txtPassword=Request.Form("frmPassword");

//Compare to the User Database

var query_Auth = Server.CreateObject("ADODB.Recordset");
query_Auth.ActiveConnection = objConn;

query_Auth.Source = "SELECT SELECT u.screenname, u.pass, g.permission";

query_Auth.Source+= " FROM dbo.user_accounts u JOIN dbo.system_group g ON u.user_system_group=g.id";
query_Auth.Source+= " WHERE u.screenname= "‘+frmUsername+’ "AND u.pass= " ‘+frmPassword+”' AND
u.status = 1";
query_Auth.Open();

// User Authenticated
if (!query_Auth.EOF) {
Session("username")=authenticate.Fields.Item("screename").Value;
Session("userPermission")=authenticate.Fields.Item("permission").Value;
Session("userID")=authenticate.Fields.Item("user_id").Value;
}

// Authentication Failed
else {
var error = "authentication";
}
// Close Database Connection
authenticate.Close();
objConn.Close();
}
%>

- 46 -
Appendix G: Sample Test Plan

Test Section: Create Expense Report Screen

Form Field Test Data Expected Result Actual Result
Item Amount -0.01 Error Message Error Message
Item Amount 99999.99 Accepted Accepted
Exchange Rate -.0.01 Error Message Accepted
Exchange Rate 99999.99 Accepted Accepted
VAT Amount -.0.01 Error Message Error Message
VAT Amount 99999.99 Accepted Accepted
Description Not Filled Error Message Error Message
Date of Expense Not Filled Error Message Error Message
Item Amount Not Filled Error Message Error Message
Item Category Not Filled Error Message Error Message
Exchange Rate Not Filled Error Message Error Message
Currency Not Filled Error Message Error Message
Receipt Not Filled Error Message Error Message
VAT Receipt Not Filled Error Message Accepted

Add Item Button Click Proceed Proceed

Reset Form Button Click Reset Form Reset Form
Cancel Form Button Click Return to Expense Return to Expense
Report Report

- 47 -
Appendix H: Current Company Paper Expense Report

- 48 -