Indigo Insurance have a requirement for an efficient
computer based file management system. The key goal is automation of file
movement within the company and for comprehensive tracking of files from
inception, to basement, to administration, and finally to archive.
Outline
Functional Specification
Request
process.
This function will allow users to request files from
the system. Verification of user name and identity will be required along with
validation of policy number. The status of the file is checked and if it is
already checked out to another user the requester is informed who the holder is
and the file status. If the file has been archived, security clearance is
checked to see that the user can request off-site/archived files.
If the file is missing or under investigation this
will be notified to the requester. If the policy is available this is confirmed
(date and time stamped). The status of the policy then changes to requested. If a request is urgent the user can request the assistance of a
supervisor whose authorisation level allows the request to skip the queue.
Return Process
This function is available to all users for
returning files which have been checked out. Effectively, it records the fact
that a policy has been returned to the collection tray. A user may enter the
policy number of the policy to be returned or may scan in the policy number.
The policy number is validated and verified. The return (if valid) is dated and
time stamped and the return is confirmed. Invalid returns (e.g. policy not
checked out, non-existent) are flagged to the user and the return is denied.
Transfer
Process
The Transfer function transfers policies from one user to another and access is
restricted to users with an appropriate level of authority (at least level 5).
If the user has authority, they are invited to enter a policy number. Existence
of the policy number is checked in the policy table, and a check is made that
the policy is actually with another user and that the transfer is not made to
the transferring user. A new request record is created for the new owner and
details of the old owner are update (to show that the file has been
transferred).
Review Process
The Review process is available to all users and
allows requests to be reviewed historically. On entry to the function, a policy
number is entered, validated and verified. A valid policy number will then have
its full movement history displayed sorted chronologically as well as details
of the policy.
Remove From
Collection Tray
This function allows an authorised user to remove
files with status collection tray
from the system. For a valid removal the transfer is confirmed (date and time
stamped) and a new request record is created for the new owner and the details
of the old owner are updated.
Transfer
Workload
Initial specification not yet defined.
Basement
Display Request
This function displays the current set of request
from all of the users.
Access is via username and password. Security level
undefined. Requests are displayed in priority/date/time order but can be
resorted by priority/date/time/username. A refresh facility will be available
to enable which will rescan the database for additional outstanding requests
and check-outs since function invocation.
To print a policy the user double clicks on the
policy on the screen which then be referenced in a print box from which entries
can be printed or removed. Printed entries each generate two labels with user
details an policy details: one label is used on the plastic sleeve of the file
while the other is attached to the file card marking the absent files position
in the filing bin.
Basement
Outgoing Files (Clock Out)
The clock-out function records all policies found
which have been requested and set sent for collection at the hatch. User
identification and password are requested and the user must have the correct
security level. A policy number is entered at the clock-out screen which is
validated and verified and whose status must be requested. A valid policy will be updated to out of stock and data and timestamped.
Basement
Returns (Clock In)
This function records a policy returned and filed in
the basement. To gain access to this process the user must have the correct
security authorisation. The encrypted number on the bin card is used to check
in the policy meaning that the file
must first be filed. The policy status is updated to in stock. The precondition is that the
file was in the collection tray.
Basement
Archiving
This allows users with appropriate permissions to archive
files off-site at another location. To gain access to this process a user must
present valid user identification and password and have appropriate security
authorisation. A policy number can be entered which is validated and verified,
and once there are no outstanding requests and the file is not checked out, the
file can be archived and status changed to archived. It may
be useful to have a three month or 90 day check on the file to see has
it been recently requested.
Audit Process
Enables a spot check or audit to be carried out on
any user who may have files allocated to them. Again the process is only
accessible to persons with appropriate security and authorisation clearance.
One days notification is provided to users. All located user files are scanned
by a trakker device. The auditor then uses this (audit) function, loading all
policy numbers stored in the trakker for the audited user, which are checked
against the users Request Table entries. An exception report is generated for
any discrepancies.
Download
Process
This process is concerned with the population of the
Policy Table with in stock file
entries and the generation of a bar code for each file. The process is batch oriented whereby policies created
on the mainframe each day will be downloaded after hours to the server and
automatically updated to the Policy Table with not in system yet status. The basement operator will generate
barricades for all new files and scan them into the system.
Mainframe policy defined by INDIGO INSURANCE to be through Tempus link from easytrieve
report on new policies. Program to update policy table then invoked.
Audit Screens
(i) Live and archived policy details downloaded from mainframe to
Policy Table.
(ii) Each Thursday, a report will
be printed listing all the policies due for audit for the coming weekend. Bar
code batch for these policies printed over night..
(iii) Update policy table screen.
If policy not found must change status to missing prior to audit.