FUNCTIONAL SPECIFICATION - lga.sa.gov.au · FUNCTIONAL SPECIFICATION ... a group was formed...

LAND AND PROPERTY INFORMATION SYSTEM (LAPIS)

FUNCTIONAL SPECIFICATION

January 2001

Prepared by:

“Delivering Innovative Business Solutions to Government”

ADC RESULTS PTY LTD

Page 2 of 146 “Delivering Innovative Business Solutions to Government”

LAPIS Functional Specification December 2000

EXECUTIVE SUMMARY With the announcement by GEAC Computers Pty Ltd that support for TCS is being phased out within the next few years, a group was formed consisting of key stakeholders from a broad cross-section of South Australian councils. This Land and Property Information Systems (LAPIS) Group, in conjunction with the South Australian Local Government Association (SALGA) commissioned the land and property information system project in order to determine future requirements. ADC Results Pty Ltd was selected to collate and document the functional requirements for a new land and property system under Phase 1 of the project. The project involved a high level of participation, consultation and exploration of the issues, processes and systems surrounding the modules required for a local government land and property system. The six core modules of the land and property system were identified as: 1. Administration 2. Applications 3. Land management 4. Licensing 5. Property and rating 6. Regulatory Each of the core modules were split further into manageable subject groups. Successions of interviews were held with key council staff to extract systems requirements. The results of these interviews provided a base functional specification to use as a starting point at the workshops. Subsequent workshops were held to discuss and refine the initial findings, prioritise the requirements and achieve consensus amongst council representatives. This document is intended to be used as the basis for further phases of the land and property information system project, to assist councils in selecting an appropriate direction for the future with respect to a land and property system.



CONTENTS EXECUTIVE SUMMARY............................................................................................................2

INTRODUCTION ........................................................................................................................4 Background.................................................................................................................................4 Scope..........................................................................................................................................5 Document Structure....................................................................................................................6 Module Structure.........................................................................................................................7 Prioritising Requirements............................................................................................................8

ADMINISTRATION MODULE ...................................................................................................9 1. Name and Address Register ................................................................................................10 2. Electoral Roll ........................................................................................................................16 3. Section 7 Certificates ...........................................................................................................22 4. Freedom of Information Act Requests .................................................................................27 APPLICATIONS MODULE......................................................................................................31 5. Development Applications....................................................................................................32 6. Inspections ...........................................................................................................................43 7. Essential Safety Provisions ..................................................................................................50 LAND MANAGEMENT MODULE ...........................................................................................55 8. Heritage Land.......................................................................................................................58 9. Land Management Agreements...........................................................................................62 10. Community Land/Non-Community Land ............................................................................65 11. Road Reserves ..................................................................................................................68 LICENSING MODULE.............................................................................................................70 12. Licenses/Permits/Casual Hire ............................................................................................71 13. Environmental Health .........................................................................................................81 14. Waste Management...........................................................................................................87 RATES & PROPERTY MODULE............................................................................................92 15. Property..............................................................................................................................93 16. Rates..................................................................................................................................99 16.2 Data Collection ...............................................................................................................100 16.3 Rates Modelling and Generation....................................................................................104 16.4 Notice Generation ..........................................................................................................108 16.5 Payments/Receipting .....................................................................................................111 16.6 Fines/Interest .................................................................................................................115 16.7 Arrangements/Debt Collection .......................................................................................118 REGULATORY MODULE .....................................................................................................121 17. Infringements ...................................................................................................................122 18. Animal Control..................................................................................................................131 APPENDIX 1. - GENERAL AND TECHNICAL REQUIREMENTS........................................138 1.1 User Interface...................................................................................................................140 1.2 Workflow Capability..........................................................................................................140 1.3 Systems Administration....................................................................................................142 1.4 Audit Trail ........................................................................................................................144 1.5 Data Access/Reporting ...................................................................................................144 1.6 Interfacing/Integration .....................................................................................................144 1.7 Web Interface..................................................................................................................145 1.8 Upgrades.........................................................................................................................145 1.9 Data Migration.................................................................................................................145 1.10 Operating System Environment .....................................................................................145 1.11 Database Environment...................................................................................................145 1.12 Network Environment/System Architecture ...................................................................145



INTRODUCTION

PROJECT BACKGROUND

In the wake of the announcement by GEAC Computers Pty. Ltd. of their intention to withdraw support for significant aspects of TCS (Total Corporate System) software and the realisation amongst a number of councils that their IT systems require enhancement, a large number of councils around Australia have been faced with the need to source an alternative product suite. A group of metropolitan councils, the GEAC MIS special interest group and the Council purchasing co-operative assisted by the Local Government Association determined to make a coordinated approach to resolving the corporate computing issue. As a result of a presentation by a member of a NSW council syndicate some 14 South Australian councils agreed to pool resources. These steering and reference groups hope to achieve the best balanced view of what councils might need in the next 10 years and leverage from the buying power such a large syndicate provides. The overall objectives of the project aims to; • Produce requirements definition document, detailing all the functionality, interfaces and integration

required for Land and Property related information and services provision. • Examine options for partnerships between councils with regards to a new core Property Information

System to: • Purchase existing software • Undertake software development • Examine ownership models • Examine other relevant issues

• Ultimately implement a new property information system solution for the participants of the project. This project has been planned to be delivered in 4 phases of which funding has been approved for phase 1 only. The objectives of this phase being to develop a common set of business requirements, identify any unique requirements and determine the overall functionality specification for the land and property system applicable for use by all South Australian Local Government to assist in the determination of their system requirements. The 4 phases of the project are: Twelve councils are represented under Phase 1 of the project.

Phase 1 Phase 2 Phase 3 Phase 4

System requirements & functional specification document

Tender document preparation & evaluation methodology

Conduct tender & evaluation process

Optionally develop implementation and conversion plans



PROJECT BACKGROUND (CONT’)

The councils actively involved in the various forums to determine future requirements were: 1. Adelaide Hills Council 2. Burnside City Council 3. The Barossa Council 4. City of Campbelltown 5. City of Charles Sturt 6. City of Holdfast Bay 7. City of Norwood, Payneham & St Peters 8. City of Onkaparinga 9. City of Playford 10. City of Port Adelaide Enfield 11. City of Unley 12. Town of Walkerville This report documents the results of Phase 1 of the project.

PROJECT SCOPE The scope of this project was limited to identifying both unique and common business requirements and a functional specification for the major application modules of a land and property information system. This did not include re-engineering of existing business processes.



DOCUMENT STRUCTURE The attached document outlines the detailed functional requirements for a land and property information system as identified by the LAPIS Group of South Australian Councils under Phase 1 of the LAPIS project. The document is based on the following core modules: 1. Administration

• Name and Address Register • Electoral Roll • Section 7 Certificates • Freedom of Information Act Requests

2. Applications

• Development Applications • Inspections • Essential Safety Provisions

3. Land Management

• Heritage Land • Land Management Agreements • Community Land • Non-community Land

4. Licensing

• Licensing and Permits • Environmental Health • Waste Management

5. Property & Rating

• Property • Rates

6. Regulatory

• Infringements • Animal Control



MODULE STRUCTURE Each module follows a standard structure and is grouped under the following 7 headings; 1. Business Objectives

This section contains an outline of the business objectives for each module. These objectives were compiled at a specific business objectives workshop with Council senior management with the aim of providing more strategic direction and context to each of the functional modules. The business objectives have been grouped under three headings;

• Customer/Community Service Objectives • Legislative Requirements • Internal Council Management Objectives

2. Procedural Flows

This is a pictorial representation of the procedural flow of information through a specific module, highlighting interaction with other LAPIS modules, other corporate systems and external organisations.

3. Functional Requirements

This section provides the heart of the document and lists the detailed functional requirements of the individual modules of the land and property system. This section does not however address the requirements relating to data access and reporting, interfacing/integration issues or audit requirements which are included within the sections below.

4. Data Access/Reporting Requirements

This section provides a list of system requirements specifically related to data access and reporting.

5. Interface/Integration Requirements

This section provides a list of system requirements specifically related to interfacing and integration with other LAPIS modules, other corporate systems and external organisations.

6. Audit Requirements

This section provides a list of system requirements specifically related to system audit controls.

7. Data Content

Each module has a detailed list of data content required to be recorded, stored and accessed.



PRIORITISING REQUIREMENTS Each requirement has been prioritised and consensus achieved through workshops based on the following priority scale.

M Mandatory These are mission critical requirements. A system not meeting a mandatory requirement would be rejected on this basis.

HI High Importance These represent very important requirements. A system not meeting these requirements would cause significant difficulties for Councils and may be rejected on this basis.

I Important These represent moderately important requirements. A system not meeting these requirements would not be rejected on this basis but could cause some difficulties for Councils.

O Optional These are optional requirements which would not result in rejection of system nor cause problems.

GENERAL ADC Results recognises and would like to thank all the active participants in this process for their exceptional knowledge and commitment to the project and their quality of contribution to the final document.



LAND AND PROPERTY INFORMATION SYSTEM FUNCTIONAL REQUIREMENTS ADMINISTRATION MODULE The Administrative subject group contains the functional requirements for the following detailed areas/modules:

! Name and Address Register ! Electoral Roll ! Section 7 Certificates ! Freedom of Information Act Requests

1. Name and Address Register

2. Electoral Roll

3. Section 7 Certificates

4. Freedom of Information Act Requests



1. NAME AND ADDRESS REGISTER (NAR) 1.1 Name and Address Register - Business Purpose

Customer/Community Service • To provide a customer service front-end framework facilitating accessibility to all customer

business/interaction with Council i.e. Dogs, rates, library, development, infringements, suppliers, employees, voters etc.

• To provide a knowledge base for identifying stakeholders within the community for the

purpose of promotion, consultation etc.

Legislative Requirement

N/A Internal/Council Management

• To provide a single centralised repository for all names and addresses (NAR) of individuals and organisations interacting with Council.

• To provide a link with all other applications within the land and property information system

and to other corporate database systems. • To reduce the time and cost of researching, identifying and gathering information on the

individuals, organisations or groups within the community. • To maintain the integrity of name and address data held by Council • To ensure accuracy of all name and address data stored.

Alternative Delivery

N/A



1.2 Name and Address Register - Procedural Flow

Reporting Data Maintenance/Integrity

Property Infringe- ments

LicensesDevelopment ElectoralRoll

Industry NAR

Standard

Merge & Link

Duplicates

Births & Death Roll

Monthly automated clean up process

Audit Log

GIS

Animals

Development Specific

NAR

Compliance with Industry Standards

Notification of name/address change sent to all relevant modules for individual approval

NAR updated by individual Module

Warning Messages for Duplicate Names and Addresses

ExceptionReporting/Duplicates

Reporting flexible- on

all Field

Mailing Lists

InfringementSpecific

NAR

Land Titles Office

House of Assembly

Role

Data Checkfor possibleDuplicates

Random Name

Selection

NAR SystemAdministrator



1. Name and Address Register Ranking Comment 1.3 Functions 1.3.1 NAR field structure complies with industry standards M

1.3.2 Able to link each NAR record with a unique identifier (i.e. unique elector identifier, council unique identifier for interaction over the Internet)

M

1.3.3

Name & Address field structure is flexible, i.e. allowing configuration of: • User-defined fields (Eg. Separate field indicating

additional street data such as Left/Right, North/South),

• Variable field widths (Eg. So that fields will be wide enough to hold all required data, and field widths will be editable).

M

1.3.4

Name & Address field format is flexible, i.e. allowing configuration of: • Case conversion tables (Eg. To enforce

capitalisation standards – Mcpherson, etc.), • Handling of abbreviations, • Templates (Eg. Standards for data entry of phone

numbers, in the format (99) 9999 9999), • Handling of hyphenated names, • Handling of punctuation (Eg. Included or excluded

automatically), • Case sensitivity (Eg. Able to enforce capitalisation,

etc.), • Default values (Eg. Enable default area code for

phone numbers to be 08), • C/- lines.

M

1.3.5

Name & Address field rules are flexible, i.e. allowing configuration of: • Address types, including:

- Units/flats (Eg. 1A Smith Street), - Rural/’rapid number’ (Eg. no street numbers or

addresses bear no relation to conventional placement on street),

- Multiple addresses (Eg. 1-3 Smith St), - Addresses without identifiers (Eg. The

Esplanade, The Parade), - Corner addresses.

• Oriental names where the surname comes first.

M

1.3.6 Able to override default field formats and rules with appropriate security. HI

1.3.7

Able to ensure that any modification or addition complies with Name and Address Industry Standards such as Australia Post or Local Government Name and Addressing standards.

M

1.3.8 Provide a mechanism facilitating conversion of existing data so as to meet Name and Address Industry Standards.

HI

1.3.9

When adding a new name, able to quickly and accurately determine whether the person exists in the database, without the Name and Address record necessarily being identical (Eg. phonetic matching, checking for duplicates, and warning messages if like matches are found).

M



1. Name and Address Register Ranking Comment

1.3.10

Able to display and select like matches after typing only a portion of the required Name or Address text (Eg. automatic search after typing x characters or upon entry of wildcard indicator ‘*’ or ‘#’).

HI

1.3.11 To allow for multiple addresses to be added for each Name (Eg. to allow different contact details for different Council activities), including trustee and agent names.

M

1.3.12 Flexibility to reset multiple Names and/or Addresses to a single default. I

1.3.13 To allow for multiple name aliases (Eg. Joe and John for Giovanni). HI

1.3.14 Able to record interstate and international addresses. HI

1.3.15 Able to use flexible workflow procedures to manage a centralised Name and Address authorisation process. HI

1.3.16 Able to add, delete and change the order of workflow tasks depending on individual circumstances. HI

1.3.17 Able to suppress of Name and Address information where this is required to be confidential. M

1.3.18 Able to record and store records of deceased people. M 1.3.19 Able to identify government entities. M

1.3.20 Able to flag names active/inactive i.e. people that move in and out of the area. O

1.3.21

Able to complete bulk maintenance procedures for changes in street names/suburb names, etc. for multiple properties (Eg. Able to select multiple properties for address update).

HI

1.3.22

Able to provide an automated cleanup process (duplicate Name and/or Address identification, etc.) maintaining data integrity (using pre-defined validation steps), along with suitable exception reporting.

HI

1.3.23

Able to easily merge duplicated names, consolidate the information (Eg. married and maiden names) to create one record and preserve the most correct information, taking into account all data associated with that Name.

HI

1.3.24 Able to archive and purge data based on pre-defined criteria. I

1.3.25 Able to attach ‘analysis’ criteria for council marketing purposes, etc.(Eg. doctors, restaurants beyond land use codes).

O

1.4 Data Access/Reporting

1.4.1

Able to generate ad hoc queries on any combination of key data fields without the need for specific systems knowledge. (Eg. List all property owners living on the left hand side of Smith St) For elected member campaign purposes, extraction of names and addresses for specific mailing lists, generation of random name selections for surveys limited by type i.e. rate payers only.

M

1.4.2 Able to print the results of any ad hoc queries to screen or paper. M

1.4.3 Able to store and retrieve frequently used queries. I

1.4.4 A set of standard reports available for regular reporting use. (Eg. duplicate records report). M

1.4.5 Able to write new reports or modify existing reports without the need for specific systems knowledge. HI




1.4.6

Able to maintain reporting flexibility on historic data for comparison with current year, trend analysis, predictive modelling, etc. (Eg. trend on population age, sex, special needs etc.).

HI

1.4.7 Able to restrict access to NAR allowing module administrators to change data only in the modules where they are authorised to do so.

HI

1.5 Interfacing/Integration

1.5.1

Able to integrate with all other modules which use or access names and/or addresses for council related activities (Eg. ratepayers, dog owners, building applicants, licensees etc.).

M

1.5.2

Able to input alternate Names and/or Addresses for the system’s individual modules (Eg. for a given Name and Address, the ability to input different contact details for dog related information, building application information, etc.).

M

1.5.3

Ability to maintain Addresses by department. Where a name is linked only to one module, or third party database, able to complete maintenance via that module. Where a name is linked to other modules/applications able to record changes as pending to be confirmed via a central authorisation process. Once flagged as pending update able to restrict other modules from applying the update until such time as the proposed change has been ratified or rejected.

M

1.5.4

Where addresses have entered by departments able to provide electronic notification to a central authorisation point and/or other effected areas with the option of update without retyping.

M

1.5.5 Able to import files from external sources (Eg. Deaths list) with appropriate validation rules. HI

1.5.6 Able to link with the White Pages or similar to ensure standardisation of surnames, addresses, suburbs, etc. O

1.5.7

Able to import alternative Name and Address data into the various system modules without affecting the centralised NAR (Eg. Allowing flexibility for Council to exclude certain names from a centralised NAR ie people outside of Council district).

O

1.5.8 Able to easily extract accurate mailing lists (Eg. mail merge) from any Name and Address related data irrespective of where it is stored.

HI

1.5.9 Able to automatically generate letters (Eg. letter to new resident). HI

1.5.10 Able to incorporate barcode technology for rapid delivery of mail. M

1.6 Audit Requirements

1.6.1

Able to produce an audit trail of all additions, modifications and deletions to selected fields and system parameters, and track to a user/date/time/reason etc.

M

1.6.2 A set of standard exception reports available for regular use (Eg. warning flags have been overridden, records where specific fields have not been populated).

HI

1.6.3 Able to produce specific exception reports on adjustments to key data. M




1.6.4 Able to provide alerts triggered from particular audit trail events. HI

1.7 Data Content Including, but not limited to the following fields: Reference # (Unique Identifier) Unique elector identifier Salutation Person/Company Flag (P or C) First Name, Middle Name (S) Preferred name Surname/Company Name Company Trading Name Name qualifier (to identify as person, business, Govt Dept etc) Alternative Contact Name Alias (Multiple) Date of Birth Sex Home Phone Number Work Phone Number Work Extension Number Mobile Phone Number Fax Number Pager Numbers Website Address E-Mail Address (Multiple) Property Address Mailing Address Preferred Address Street name and type Street Number with Prefix and Suffix Lot Type and Number Suburb Post Code State/Province Country Alternative Addresses (Multiple) Geographic Info (Left or Right Hand Side Of Street) Special Needs (Interpreter Required, Hearing Disability, Cultural Register Etc.) Pensioner Number Pensioner Type Suppression (available on a number of fields enabled by a check box) Deceased (Y/N) Web Access Security ID Web Access Password Digital Signature



2. ELECTORAL ROLL 2.1 Electoral Roll - Business Purpose

Customer/Community Service

• To support the democratic process allowing all eligible people the opportunity to have a say in how they are governed.

• To support an equitable elector representation.


• To satisfy legislative requirements under the Local Government Elections Act and Regulations.

Internal/Council Management

• To provide an accurate register of all people entitled to vote under legislation, i.e. provide a complete list with no duplicates, avoiding or reducing the possibility of fraudulent practices.

• To support and manage the logistics of an election process.

• To link closely with the name and address register providing a tool for checking the accuracy

of the Electoral Roll and the NAR.


• Potential for future outsourcing of the electoral process to Electoral Commission.



Electoral Roll- Procedural Flow

Vote Allocation

File Filter

NAR File

Extract

File Edit

Reporting

Audit Log

House of Assembly

Roll File

Extract

Reporting

File Match

Process

Abbreviation Conversion

Table

Check all Combinations of Names & Addresses

Reporting

File Edit

Link to NAR alternative

name and address

NAR

Audit Log

Matched

CouncilOnly

Vote Allocated

Vote Entitlement

Criteria Check

Vote Allocated

Vote Denied

Reporting

Draft Voters

Roll

Reporting

File Edit

Audit Log

Legislation (Act &

Regulations)

Draft Council

Roll

File Edit

Electoral Commission

Final Council

Roll

Final Voters

Roll

GIS

Save Final File

Save Final File

Save Final File

File Merge

Save Final File

Save Final File

Alteration of Ward

Boundaries

Reporting errors to Electoral Commission

Council Extract

Electoral Commission Extract

Merging & Matching Process

Voters Roll

Property



2. Electoral Roll Ranking Comment 2.3 Functions

2.3.1 Able to select fields as required from the NAR and property modules, and extract a preliminary Council voters’ roll file.

M

2.3.2

Able to exclude: • Government entities, • Deceased voters, • Voters under legal age.

M

2.3.3 Able to merge the Council Roll with the Electoral Roll comma-delimited text file. M

2.3.4

When matching the Council Roll with the Electoral Roll, able to perform matches on unique elector identifier, able to perform ‘like’ matches (on a selectable range of characters) rather than requiring names and addresses in NAR and Electoral Roll to be identical. (Eg. include aliases, phonetic matches, similar names, matching on initials rather than full name, etc.).

M

2.3.5 When matching the Council Roll with the Electoral Roll, able to view duplicates, merge duplicates and multiple names, etc. and validate or edit unmatched data.

HI

2.3.6 Able to conform to appropriate legislation, and handle changes to legislation: (Eg. entitlement codes required by Electoral Commission).

M

2.3.7 Able to provide links to relevant legislative documents i.e Elections Act on-line for reference purposes. O

2.3.8

In addition to the central Name and Address, able to store an alternate Name and Address relating specifically to the Electoral Roll and able to update this from the Electoral Roll without re-typing.

HI

2.3.9

Matching to take into account: • A user-defined range of fields, • Alternate addresses, • Multiple address types (Eg. Rural, unit, multiple

street addresses i.e. 1-3 Smith St, etc.), • Multiple addresses (including residential address,

mailing list, preferred \address for specific council business such as dogs, rates, etc.),

• Suppressed names and addresses, • Wards.

M

2.3.10

Able to allocate votes in line with legislation and handle changes to legislation: • Sole resident votes, • Sole occupier votes (including tenancies), • Group votes, • Denied votes, • Alien votes.

M

2.3.11

Assign rules to vote allocation (Eg. system will check for business across wards for number of votes allocated), to be performed after all data has been verified i.e for duplicates, etc.

M

2.3.12 Distinguish between residents and occupiers. M

2.3.13 Able to allocate votes to voters having suppressed names – able to flag and then compare by address. M

2.3.14 For group voting, able to check whether individual members have been allocated votes. M



2. Electoral Roll Ranking Comment

2.3.15 Able to add group names and include alternate addresses for individual members. HI

2.3.16

For groups without names, able to automatically allocate a group name based on pre-defined criteria (Eg. group name = ‘SMITH’ because all individual members have surname = ‘SMITH’).

HI

2.3.17 For those ineligible to vote, able to flag reasons (Eg. if property inside or outside the area, married/maiden name etc.).

I

2.3.18 Able to maintain version control over Rolls (including ability to number Rolls and include descriptions). HI

2.3.19 Able to assign copies of Rolls to candidates electronically. O

2.3.20 Able to override a vote (but this to be tracked and reportable). M

2.3.21 Able to attach a comment and copy comments (using copy/cut/paste). O

2.3.22 Able to view percentage of completion when processing on all Voters’ Roll functions. I

2.3.23 Able to extract voters’ roll via a text file. M 2.3.24 Able to provide a data cleanup utility. I 2.3.25 Able to print voters’ roll on A4 paper. I

2.3.26 Able to reach a definitive point of closure for the Voters’ Roll. M


2.4.1

Able to generate ad hoc queries on any combination of key data fields without the need for specific systems knowledge. (Eg. extract information from the Electoral Commission (EC) data prior to merging with Council role, extract missing names, extract rural addresses etc.).

M



2.4.4

A set of standard reports available for regular reporting use, such as: • List of unmatched records from Council and EC

merge, • List of EC data discrepancies to be forwarded to

EC, • Vote allocation report, • Final Council role report.

M


2.4.6

Able to maintain reporting flexibility on historic data for comparison with current year, trend analysis, predictive modelling, etc. (Eg. comparison of voting percentages between elections).

HI


2.5.1 Able to link with the property module to extract property owner/occupier information for the Council voter roll. M

2.5.2 Able to link with the NAR module to extract name and address information for the Council voter roll. M

2.5.3 Able to extract House of Assembly Roll (from State Electoral Office) from email or floppy disk. M

2.5.4 Voting through the web is facilitated. O



2. Electoral Roll Ranking Comment

2.5.5 To interface/integrate with e-mail and electronic fax facility for communication with eligible voters, electoral commission etc.

M

2.5.6 Able to link documents stored in Document Management System to individual voters. M

2.5.7

Able to link with customer services to: • Record voter inquiries, • Record voter complaint details, • Record nature of complaint, • Resolution of compliant or inquiry.

HI

2.5.8 Able to link with word processing software to access document templates, automatic mail merges etc. M


2.6.1


M

2.6.2 A set of standard exception reports available for regular use e.g. Manually allocated votes, duplicate voter names.

HI





2.7 Data Content Including, but not limited to the following fields: Unique Elector Identifier Surname/Business Name First Name Middle Name (S) Group Name Group Contact Name Property Address Mailing Address House Number Rapid Number Lot Number Ward Source Code (State or Council) Voter Code (Resident, Owner, Group Owner Etc.) Granted Vote Code (None, Ward Only, Ward and Area) Postal Vote Status (Used in Electronic Voting or For Those Who Are Mad Enough to Enter Them Manually) ID Number For Electronic Voting



3. SECTION 7 CERTIFICATES 3.1 Section 7 Certificates - Business Purpose


• To ensure the highest quality customer service throughout the process of issuing Section 7 Certificates, i.e. delivering complete and accurate information on a timely basis, providing alternative access, tracking and delivering through the Internet.


• To fulfil legislative requirements under the Local Government Act 1999 and the Land Business (Sale and Conveyancing) Act 1994


• To provide links to, and extract all relevant Section 7 items across applications, ensuring completeness of information.

• To maintain accuracy of section 7 Certificate information, i.e. control over attaching/updating

new information, processes for removing information no longer relevant etc.

• To provide an efficient process for completing Section 7 Certificates, with a view to improving revenue generation and ultimately profit.


N/A





3.2 Section 7 Requests – Procedural Flow

Work Flow Tracking

Request in person to

CSU

Request Formmailed

Request made

electronicallyGIS

Property selected on-line

using GIS

Property Information checked to

Property Info

Receipted manually

Receipted through

Payment Gateway

Cash Receipting

Lodgement date recorded

CompleteRate

Search Property

See data content for details

Land TitlesOffice

Generate Section 7Search

Development

Infrastructure

Environmental Health

Check searchinfo against

CIT

MS Office

Automatic

Request Cert of Title

Certificateof Title

Attach file/image

GenerateSection 7

Cert

Send Report

to Customer E-mail/MailReporting

Sign off steps when complete

Unique lodgement #

assigned Reporting

Fee Calculation

Standard tasks

allocated to groups



3. Section 7 Certificates Ranking Comment 3.3 Functions

3.3.1 Able to automatically calculate fees, incorporating discounts, rebates and pensioner concessions. HI

3.3.2

Able to use flexible workflow procedures to manage the Section 7 process, i.e. able to configure standard search tasks i.e. define standard workflow steps, required for a Section 7 search.

HI

3.3.3 Able to add, delete or change the order of workflow tasks depending on individual circumstance. HI

3.3.4 Able to allocate standard tasks at a group or individual level. HI

3.3.5 To facilitate electronic routing between multiple groups or individuals for completion of assigned tasks. HI

3.3.6 To facilitate electronic signoff for all search tasks, including record of each user completing each task and the time of completion.

HI

3.3.7 Able to attach priorities to Section 7 searches (Eg. normal, urgent, etc.). I

3.3.8 Able to keep track of multiple Section 7 searches on a group or individual basis. HI

3.3.9 Able to keep track of time spent on each Section 7 search by task in real time linking to performance criteria and/or legislative requirements.

O

3.3.10 Able to remind groups and/or individuals when searches are left incomplete after a pre-defined timeframe. O

3.3.11 To allow an escalation path for incomplete searches within pre-defined timeframes. O

3.3.12 Able to record the number of searches undertaken per property. O

3.3.13 Able to fully automate the Section 7 request process (Eg. select and generate a Section 7 at the push of a button).

M


3.4.1

Able to generate ad hoc queries on any combination of key data fields without the need for specific systems knowledge. (Eg. number of Section 7 requests lodged per property, number of completed searches, average time per search, able to generate mailing lists etc.).

M



3.4.4 A set of standard reports available for regular reporting use. (Eg. Section 7 status report, monthly performance statistics, Section 7 certificate).

M


3.4.6

Able to maintain reporting flexibility on historic data for comparison with current year, trend analysis, predictive modelling, etc. (Eg. Comparison/trend of Section 7 performance statistics, numbers, turn around times etc.).

HI


3.5.1 Integration with all other modules (specific consideration to be given to linkages, ensuring all relevant Section 7 data is identified and captured).

M



3. Section 7 Certificates Ranking Comment

3.5.2 Able to import files and attach from external sources (Eg. Certificates of Title from Lands Titles Office, etc.) automatically on initiation of a search.

HI

3.5.3 Able to accept payment electronically and allow automatic receipting. HI

3.5.4 To interface/integrate with White Pages for inclusion of agents’ names, etc. O

3.5.5 Able to integrate with GIS throughout the process. HI

3.5.6 Able to accept requests electronically via the Internet and e-mail. HI

3.5.7 Able to track search progress via the Internet. HI

3.5.8 To interface/integrate with Document Management/Records Management System for tracking of correspondence, etc.

HI


3.6.1


M

3.6.2

A set of standard exception reports available for regular use e.g. where actual completion times exceed legislative requirements or performance standards are not meet.

HI





3.7 Data Content Including, but not limited to the following fields: Certificate number Lodgement date Condition Type Notifiable flag Receipt Number Search Start Date/Time Search Completion Date/Time Requestor Workflow process identifier Workflow task number Workflow status code



4. FREEDOM OF INFORMATION ACT REQUESTS 4.1 Freedom of Information Act Requests - Business Purpose


• To provide accountability and transparency of Council operations to the Community, helping to improve the image of Local Government.

• To ensure the highest quality customer service when processing FOI requests, i.e. delivering

complete and accurate information on a timely basis. Legislative Requirement

• To fulfil legislative requirements under the Freedom of Information Act relating to the provision of information to customers upon request.


• To promote the need for good systems and security to satisfy governance requirements • To maintain accuracy and integrity of information for FOI requests.


• FOI requests could be effectively managed outside of the land and property information system through a document/records management system.



4.2 Freedom of Information Act Requests - Procedural Flow

Work Flow Tracking

Request in person to

CSU

Request Formmailed

Request made

electronically

Receipted manually

Receipted through Payment Gateway

Cash Receipting

Lodgement

date recorded

Review requested information

Document management

system

Send letter to customer re. process

Word Std templates

Send Requeststo referral

organisations

External Organisations

ReferralLetters

Internalreview

process Reporting

Unique FOI #

assigned

Find relevantinformation

files

Customer Letter

Customer Word Std templates

Response received

Do we release

info?

Info sent tocustomer

Yes No

Customer Appeal information

released

Yes

No

Ombuds-man

review

Yes No

Customer

Customer

Customer

Customer

Reporting

Fee Calculation



4. Freedom of Information Requests Ranking Comment 4.3 Functions 4.3.1 Able to automatically calculate fees. HI

4.3.2

Able to use flexible workflow procedures to manage the Freedom of Information Act process, i.e. able to configure standard search tasks (Eg. Define standard workflow steps) required for a FOI search.

HI


4.3.4 Able to allocate standard tasks at a group or individual level. HI

4.3.5 Able to manage the standard appeals process (Eg. internal and external ombudsman review). HI

4.3.6 Able to facilitate electronic routing between multiple groups or individuals for completion of assigned tasks. HI

4.3.7 Able to facilitate electronic signoff for all tasks, including record of each user completing each task and the time of completion.

HI

4.3.8 Able to attach priorities to Freedom of Information requests (Eg. normal, urgent, etc.). I

4.3.9 Able to keep track of multiple Freedom of Information requests on a group or individual basis. HI

4.3.10 Able to keep track of time spent on each Freedom of Information search by task in real time linking to performance criteria and/or legislative requirements.

O

4.3.11 Able to remind groups and/or individuals when requests are left incomplete after a pre-defined timeframe. O

4.3.12 Able to allow an escalation path for incomplete requests within pre-defined timeframes. O

4.3.13 Able to record the number of requests undertaken. O

4.3.14 Able to fully automate the Freedom of Information request process (Eg. generate Freedom of Information results at the push of a button).

M


4.4.1

Able to generate ad hoc queries on any combination of key data fields without the need for specific systems knowledge. (Eg. Number of FOI requests lodged, number of completed searches, average time per search etc.).

M



4.4.4 A set of standard reports available for regular reporting use. (Eg. FOI search status report, monthly performance statistics, FOI document).

M


4.4.6

Able to maintain reporting flexibility on historic data for comparison with current year, trend analysis, predictive modelling, etc. (Eg. Comparison/trend of FOI performance statistics, numbers, turn around times etc.).

HI


4.5.1 Able to link with the property module to record property related FOI requests against individual properties. M



4. Freedom of Information Requests Ranking Comment

4.5.2 Able to import files from external sources. HI

4.5.3 Able to attach files from external sources. HI

4.5.4

To interface/integrate with e-mail (Eg. Microsoft Outlook) for: • Sending search completion advice, • Notifying users when work is required, • Sending completed freedom of information advice

to customers and agents.

HI

4.5.5 To interface/integrate with Microsoft Office software suite. HI

4.5.6 To produce Microsoft Word documents automatically via ‘mail merge’. HI

4.5.7 To interface/integrate with a GIS for property data, etc. HI

4.5.8 To interface/integrate with Document Management/Records Management System for tracking of correspondence, etc.

HI

4.5.9 To allow automatic receipting. HI

4.6 Audit Requirement

4.6.1


M

4.6.2

A set of standard exception reports available for regular use i.e. where actual completion times exceed legislative requirements or performance standards are not meet.

HI



4.7 Data Content Including, but not limited to the following fields: FOI Number Lodgement Date Receipt Number FOI Request Start Date/Time FOI Completion Date/Time Requestor Workflow process identifier Workflow task number Workflow status code



5. Development Applications

6. Inspections

7. Essential Safety Provisions

LAND AND PROPERTY INFORMATION SYSTEM FUNCTIONAL REQUIREMENTS APPLICATIONS MODULE The Applications subject group contains the functional requirements for the following detailed areas/modules:



5. DEVELOPMENT APPLICATIONS 5.1 Development Applications - Business Purpose


• To ensure the highest quality customer service when processing development applications, i.e. delivering complete and accurate information on a timely basis, providing alternative lodgement, tracking and delivering through the Internet.

• To enforce and monitor building standards with a focus on maintaining public safety.


• To fulfil relevant legislative requirements, including future requirements under the Local Government Act 1999 requiring the completion of a strategic management framework.


• To allow Councils to monitor and manage growth and assess the potential impact this will have on resource management.

• To assist with the development of a strategic management framework, allowing access to

information required for performance reporting, covering - quantity, quality, time and cost. • To provide an efficient process for tracking and completing development applications, with a

view to improving revenue generation and ultimately profit, and competing for development applications outside of a Council area.


• Potential for future outsourcing of building certifications



5.2 Procedural Flow – Development Applications

Application in person at

Council

Application posted to Council

Application received via

Internet

Application receipted to holding a/c Cash

Receipting

AutomaticAllocationto officer

Automatic allocation of

minimum tasks

Property

Cash receipted thru Payment

Gateway Payment gateway

Electronic Calender

Appln Lodged

Allocation of Fees General

Ledger Dev App number

assigned

Development Approval

Provisional DevelopmentPlan Consent (See Below)

Provisional Building Rules

Consent (See Below)

Yes

No

Calculationof Fees



5.2 Procedural Flow – Development Applications (Cont’)

Provisional Development Plan Consent

Task Database

Additional planning

tasks added to Workflow

Development Plan

Assessment Public

notificationState Agency

Referral

Responses received

Council/ Committee/ delegation

Provisional Development Plan Consent

State Agency

GIS Neighbours/News Paper

Internet

Conditionsconfirmed/attached

Property

No

Yes

ConditionsDatabase

Section 7

Further InformationRequested

Pending conditionsattached

ConditionsDatabase

Appeals Process

(see below)




Appeals Process Council/

Committee/ delegation

AppealsProcess

Approval

Notify All Parties

HearingConferencedecision

ConditionsAttached

Yes

Yes

No

No

Conference

Council/ Committee/ delegation

Section 7

Hearing decision

No

Yes

ApplicationDeclined




Provisional Building Rules Consent

Task Database

Additional Building

tasks added to Workflow Building rules Assessment Referrals

completed Surveyors assessment Internet/

E-mail

Conditionsattached

Property

Additional InformationRequested

Private Certification

Section 7

Provisional Building Rules

Consent

ConditionsDatabase



5. Development Applications Ranking Comment 5.3 Functionality

5.3.1 Able to input applicant name for Development Applications. Must have ability to change if entered incorrectly.

M

5.3.2 Able to add multiple applicants per Development Application. HI

5.3.3 Able to add standard descriptions for Applications (Eg. building a house, building a garage, etc.) without having to retype text.

HI

5.3.4 Able to lodge Development Applications as pending. HI

5.3.5 Able to enter description details of an application using a free-form text field. HI

5.3.6

Able to use flexible workflow procedures to manage the development process, i.e. able to support multiple types of Development Application (Eg. planning, building, complying, non-complying, minor), each having different workflow tasks.

HI

5.3.7 Workflow able to support multiple types of land division (i.e. Torrens title, Community Title, Strata title, etc.). M

5.3.8 Ability to automatically attach the minimum task list to each application type on lodgement. M


5.3.10 Ability to add a complete workflow process to an existing process, so that additional tasks slot in at the appropriate points in the sequence.

HI

5.3.11 Able to bypass workflow tasks if Council deems appropriate. HI

5.3.12

Able to attach flexible preconditions to workflow (Eg. in general Development Approval notices must not go out to applicants before fees are received, however there are exceptions; can’t issue approval without completing certain tasks, etc.).

HI

5.3.13 Able to automatically reflect amendments to workflow tasks in existing applications where the task has been started.

HI

5.3.14 Workflow able to allow completion of tasks within provisional building and planning consents concurrently. M

5.3.15 Able to have many responsible officers for each application – per task if necessary. M

5.3.16 Ability to change any data (name, address, development type, etc.) after lodgement. M

5.3.17 Able to add comments (notes) against each task in the workflow. HI

5.3.18 Able to facilitate electronic signoff of each task in the workflow (include user, date and time stamp automatically).

M

5.3.19 Able to attach predefined performance criteria (time) to each task. M

5.3.20 Ability to accept a timeframe of less than one day to individual tasks and be able to retain if necessary. M

5.3.21 Ability to measure task performance concurrently (Eg. Three individual tasks completed on the same day are measured as one day and not three days elapsed).

M



5. Development Applications Ranking Comment

5.3.22 Ability to have the overall completion time for a Development Application automatically attached at lodgement.

M

5.3.23

Ability to have performance targets for completion time updated automatically when certain tasks are added from the workflow list (Eg. State Government referral required – 2 weeks added to expected completion date).

M

5.3.24 Able to stop/start clock for recording time against each task, but with appropriate audit trail (Eg. for requesting additional information).

M

5.3.25 Able to differentiate between date and time for planning consent tasks and date and time for building consent tasks related to the same development.

M

5.3.26 Able to differentiate between task times for internal staff and external (Eg. agencies, etc.). M

5.3.27 Able to separate individual task timeframes and overall development application timeframes to ensure accurate recording of performance information.

M

5.3.28

Able to automatically allocate the application to an officer. Allocation based on: • Specific customer request, • Officer’s workload, • Officer’s skills/experience, • Officer’s availability. This functionality can be switched off.

HI

5.3.29 Able to easily reallocate tasks previously allocated to another officer even if these have been started. M

5.3.30

Ability to manage officer’s workloads by attaching indicative completion times to each task. Able to prioritise tasks for officers (Eg. Longest outstanding tasks, tasks closest to exceeding performance targets need to be completed first).

I

5.3.31

Able to automatically: • alert users when tasks are due, • escalate tasks when they are left incomplete, • send reminders where a performance criterion

has not been met.

M

5.3.32 Able to process staged development applications (using the same number but prefixed/suffixed with stage indicator 1,2).

M

5.3.33 Able to view the status of a development application and identify the officer responsible for completing the current step(s).

M

5.3.34 Able to calculate fees automatically based on pre-determined conditions and in real time. M

5.3.35

Able to vary/override calculated fees for individual applicants i.e. volume builders, Heritage land, etc. and this fee structure is automatically put in place when working with these applicants.

M

5.3.36 Dual fee fields are available showing calculated and adjusted fees (Eg. discount, etc.). M

5.3.37 Able to adjust fee after amounts receipted without having to reverse the original fee. I

5.3.38 Able to alter class details and have this automatically update fee info. (Providing a warning message). M




5.3.39 Able to instantly approve minor development by passing normal procedural flow (approval to be granted with receipt).

HI

5.3.40 Able to attach conditions to a Development Application, and able to set up a standard set of conditions (including soil type and wind speed data).

M

5.3.41 Able to attach multiple conditions. M 5.3.42 Able to link conditions with specific applications. HI

5.3.43 Able to flag conditions as inactive where conditions have been met. M

5.3.44 Able to attach standard conditions/notes to standard development types (Eg. verandahs, carports, etc.). HI

5.3.45 Able to classify conditions as pending prior to council approval. HI

5.3.46 Ability to flag/tick correspondence to be sent to several parties (owner, developer, etc.) with automatic link to e-mail/document generation.

M

5.3.47 Ability to hold information of all representations received from public notification. HI

5.3.48 Able to send responses automatically to parties who submitted to council (Eg. Notification of decision). HI

5.3.49

Able to automatically send an e-mail to lodge advertisements with newspapers when specific development applications are lodged (Eg. category 3 developments).

I

5.3.50 Able to record developer contributions and open space contributions and be able to track contributions per property and attach to applications where necessary.

HI

5.3.51 Able to facilitate post-approval Development Application tasks. M

5.3.52

Ability to differentiate between conditions that are notifiable and those that are not (Eg. Land management agreements would be notifiable, while contaminated land would not be).

M

5.3.53 Ability to designate mandatory input fields (Eg. Land use code is a mandatory input field). M

5.3.54 Ability to record one application over multiple properties without additional input. M

5.3.55

Application Expiry • Able to include automatic date calculation for

expiry date of approvals based on SA Legislation, • Able to automatically notify/alert applicant and

responsible officer when application is about to expire (ie month left) and when it has actually expired,

• Ability to automatically generate a letter informing the applicant.

HI

5.3.56

Able to complete auto-validation of application category against zoning, based on development plan Able to access zoning and land use information directly through a link from the development plan.

HI

5.3.57 Able to approve “alternative solutions” based on individual circumstance, land use, etc. I




5.3.58

Able to flag where an alternative solution has been granted on a property, and has an alert highlighting the situation in the event of any proposed development on the site.

I


5.4.1

Able to generate ad hoc queries on any combination of key data fields without the need for specific systems knowledge. (Eg. Approval times based on a specific classification of application - complying versus non-complying, applications by suburb, etc.).

M

5.4.2 Able to print the results of any ad hoc queries to screen or paper. Also able to export to MS-Excel or ASCII text for use in other products.

M

5.4.3 Able to store and retrieve frequently used queries with the ability to include an appropriate description of the query.

I

5.4.4

Sets of standard reports are available for regular use. i.e. Development application statistics for management reporting, Information required by the Australian Bureau of Statistics (ABS).

M


5.4.6

Able to maintain reporting flexibility on historic data for comparison with current year, trend analysis, predictive modelling, i.e. To track economic development indicators based on the number of approved applications by region.

HI

5.5 Interfacing/integration

5.5.1 Able to integrate with all property information. M

5.5.2 Able to access owner details from the property module and store as applicant where the applicant is the owner. M

5.5.3 Able to track Development Application history per property. M

5.5.4 Development Applications able to link to single or multiple properties. (Eg. during land division). M

5.5.5 Able to link all conditions and notices to section 7 requests. M

5.5.6

Able to integrate with the Inspections module, including the ability to schedule inspections automatically based on conditions attached to development applications and related legislative requirements; and able to flag where work has been conducted by private certifiers, inspectors, etc.

M

5.5.7 Able to integrate with cash receipting, receivables and general ledger for managing customer payments from various sources (Internet, B-pay, agencies, etc.).

M

5.5.8 Able to link directly to the development plan based on property address. HI

5.5.9 Able to import conditions to a building consent that has been privately certified. M

5.5.10 Link to Lands Titles Office for access to Certificates of Title at lodgement. O

5.5.11 Able to automatically link with Valuer General and/or private valuer at the completion of building advice for instant valuation updates.

O




5.5.12 Able to attach documents electronically (Eg. maps, correspondence, etc.). M

5.5.13 Able to add in ABS data. This should be structured so any authorised user can enter this data at any point. M

5.5.14 Able to link with transport, EPA, engineers, etc. for referrals, correspondence from owners, private inspection companies, etc.

M

5.5.15 Able to interface/integrate with White Pages for inclusion of agents’ names, etc. I

5.5.16

Able to link to the GIS throughout the process (including for display of the property/properties and associations, and identification of adjoining land owners for creating mailing lists, etc.).

M

5.5.17 Ability to receive/process Development Applications electronically via the Internet with fees able to be determined over the Internet also.

M

5.5.18 Ability for customers to inquire on progress of development application through the Internet. HI

5.5.19 Ability for customers to obtain map information from council electronically, document planned development and send this back to council to attach to an application.

HI

5.5.20 Able to link with electronic staff calendars for control over workflow (scheduling of tasks). M

5.5.21

Able to issue a Decision Notice to applicants electronically via mail merge or other (this would need to be stored historically with the Development Application record).

HI

5.5.22 Links with word processing software (MS Word, etc.) to access document templates, automatic mail merges, etc.

M

5.5.23

To interface/integrate with e-mail (Eg. to receive/process development applications and send Development Application completion advice; notify users when work is required, etc.).

M

5.5.24

Able to link to documents stored in a Document Management System associated with an individual Development Application, link to posted applications, etc.

M

5.5.25 Able to link development contributions to financial system general ledger (Under new Local Government Act requirement to track and report on financial matters).

M


5.6.1 Able to produce an audit trail of additions, modifications and deletions to selected fields and system parameters and track to a user/date/time.

M

5.6.2 A set of standard exception reports are available for regular use (Eg. calculated fees overridden and tasks completed outside of performance targets).

HI





5.7 Data content Development Application Number DAC Land Division Number Applicant Name Applicant Address Contact Person. Builders Name Builders Address Builders License Number Other Names (Architect, Private Certifier, Consultant, Engineer, Etc.) E-Mail Address For All Names. Name Of The Office Application Type (Plan Consent, Building Consent) Task Due Date Development Stage Initiation Date (Automatically Generated). Completion Date (Automatically Generated). Development Type (Verandah, Carport, Etc.) Calculated Fee Adjusted Fee. Certifier’s Name (Internal or External) Private Certification Company Name Building Rules Classification Development Floor Area ABS Code Heritage Listed (National, State, Local, Contributory – i.e 4 Classes) Land Management Agreements Land Use Conditions (including Applied Date, Condition Type, Notifiable Flag) Notices Essential Safety Provisions Alternative Solutions Certificate Of Occupancy Zoning Contaminated Land Soil Type Wind Speed Significant Trees Easements Water Courses Waste System CITB Levy Public Notification Category Certificate Of Title Construction Industry Training Levy Building Indemnity Insurance Development Cost Statements of Compliance Number Of New Allotments Site Area Date Building Constructed (Strata, Community Title, Torrens Title) New Identifiers Link To Original Property Land Division Type (I.E. Division, Lease Community or Strata Title) File Plan Result Flag



6. INSPECTIONS 6.1 Inspections - Business Purpose


• To facilitate high quality customer service when managing a compliant i.e. Acting on a timely basis, providing alternative complaint registration and tracking through the Internet.


• To fulfil all relevant legislative requirements Internal/Council Management

• To provide an efficient process for initiating, scheduling, tracking and reporting results of inspections.

• To allow for integration across all applications within the land and property information system

and other corporate systems i.e. dogs, building, food, linking to GIS, debtors etc.


• Potential for future outsourcing of inspection services



6.2 Procedural Flow –Inspections

Workflow

Licensing of SRF’s

Notification of food

premises

Inspection Required

Inspectiondetails

recorded in the field

Inspection passed

Calender

Yes

No

Property

Customerrelations

ComplaintReceived

Officer Availability

Check

InspectionScheduled

on line

Inspection schedule

printed/e-maileddaily

Laptop/ hand held/

paper

Reschedulefollow up

inspection

InspectionApproved

Property

Expiation generated

Customer

inspectionfrequency

determinedRisk score calculation

Automatic allocation of tasks

Add/removetasks Task

database

Inspectiontype

allocated

Complainttype

allocated

Inspectionhistory

included

Notice generated

Word Processing

Section 7

General ledger

New risk factors

determined

Inspection required

No inspection

Yes

No

CustomerRelations

Development Applications, Licensing and other

LAPIS modules

Development Conditions

Customer Relations



6. Inspections Ranking Comment 6.3 Functionality

6.3.1 Able to process multiple inspection types (Eg. building, health, Essential Safety Provisions, animal control, abandoned vehicles, etc.).

M

6.3.2

Able to set parameters for predefined inspection categories/types. • Selections available via drop down box, • Parameters flexible to manage future

requirements.

HI

6.3.3 Ability to associate multiple inspectors to one inspection. HI

6.3.4 Able to defer, cancel or reschedule inspections and add comments by overriding automatic scheduling. M

6.3.5 Able to automatically schedule inspections based on inspecting officer workload and specific skills. HI

6.3.6 Able to generate minimum inspection schedule from conditions or previous inspections. I

6.3.7

Ability to automatically schedule inspection events for establishments for both standard periods (Eg. 6 and 12 months) as well as the flexibility of arranging ad hoc inspection visits.

M

6.3.8 Automatic prompt to ensure inspection dates are scheduled at the time an inspection report is recorded. M

6.3.9 Able to set up multiple commencement and due dates for inspections. M

6.3.10 Warning facility indicating maximum period of time to elapse before the next inspection is to be undertaken. I

6.3.11 Ability to record reason for delay in investigation or inspection for standard inspections, follow up inspections and complaints.

M

6.3.12

Ability to allocate unique file and inspection reference for each inspection event. Facility to apply each unique reference number with a status of suspended, cancelled and active.

M

6.3.13 Ability to schedule inspections by activity type or area etc. to take advantage of efficiency opportunities. M

6.3.14 Ability to assign mandatory entry fields associated with each activity type to ensure complete record of inspection results.

M

6.3.15 Able to attach narrative giving additional useful information on the establishment and inspection document for reference.

M

6.3.16 Ability to enter and maintain inspection commencement and due dates linked to an automatic inspection scheduling facility.

M

6.3.17 Ability to record the start and end times of inspections against events or take an inspection duration option. M

6.3.18

Able to use flexible workflow procedures to manage the inspection process, i.e. unique workflow tasks and mandatory inspection fields associated with each inspection type, management of food safety plans, etc.

HI


6.3.20 Able to add comments (notes) against each task in the workflow. M



6. Inspections Ranking Comment

6.3.21

Ability to record inspection results and calculate risk score recording the following: • Date and time of inspection, • Inspector reference, • Demerit total, • Premises code, • Patron code, • Training code, • Free comments field, • Outstanding corrective remarks.

M

6.3.22

Ability to record the progress and results of samples taken on inspections. Workflow able to support: • Unique recording of each sample taken at

inspection, • Different workflow tasks associated with different

results of samples taken, • Further action due to results of test.

M

6.3.23 Ability to attach an area code to each establishment linked to an individual inspector to assign duties. HI

6.3.24 Ability to maintain default area codes linked to inspector reference. M

6.3.25

Ability to trigger warning facility against multiple owners of establishments/businesses. If there is an incident outstanding at one location the warning shows on other locations due for inspection – providing details of incident at other location.

HI


6.4.1

Able to generate ad hoc queries on any combination of key data fields without the need for specific systems knowledge. (Eg. number of inspection by an officer with a specific result, outstanding inspections sorted by due date, etc).

M


M


I




6.4.4

Sets of standard reports are available for regular use, such as: • Inspection schedules (Inspections to be completed

this day, week, month, by officer); • Inspection statistics for management reporting, • Response times, • Outcomes, • Report on complaints with the following:

- By date of complaint, - By establishment, - By business owner, - By complainant details, - By status.

• Common components, such as: - All locations with same business owner, - All locations with same property owner.

• Inspection history by establishment, inspector, owner, type, etc.

• Inspection status between specific dates, such as: - Number of inspections completed, - Number of inspections outstanding, - Number of complaints investigated, - Number of complaints outstanding, - Number of inspections overdue, - Number of re-inspections required.

• Work schedules by type/area reference/date range, etc.

• Work scheduling itinerary providing inspection and complaint history of establishment.

M


6.4.6 Able to maintain reporting flexibility on historic data for comparison with current year, trend analysis, predictive modelling, etc.

HI


6.5.1

Able to integrate with all property information (i.e. able to record all inspections/complaints against a property, Able to attach inspection schedules and inspection data to properties eligible for rebate, etc).

M

6.5.2 Able to link inspection history to single property or multiple properties (during sub division process). HI

6.5.3

Able to interface with Development Applications to; • Receive “condition” information and required follow

up periods, • Record application number, • Record classification, • Record task details, • Record contact details.

M

6.5.4

Inspections to be tracked independently of development applications, but able to be linked to applications and properties during planning approval, building approval and post approval.

HI

6.5.5 Able to attach documents electronically (Eg. detailed memos/notes, maps, correspondence, digital photos, etc).

M




6.5.6

Able to link to the GIS for data representation, bulk maintenance, creation of mailing lists, record of inspection history against such events as mobile vendors and streets serviced, locations of wasps and bees, etc).

M

6.5.7 Links with word processing software (MS Word, etc.) to access document templates, automatic mail merges, issue a Decision Notice, etc.

M

6.5.8

To interface/integrate with e-mail (Eg. Microsoft Outlook) for: • Receiving inspection requests, • Reminders for inspections, • Notifying inspectors when work is required, • Inspection progress and results (especially for

complaint-driven inspections).

M

6.5.9 Able to link with staff calendars/work schedules for scheduling, overriding and rescheduling of inspection tasks based on workload.

M

6.5.10

Able to attach/link to associated documents electronically in a Document Management System (Eg maps, correspondence, etc) to individual establishment details, inspections, complaints, etc.

M

6.5.11 Able to link inspection arrangements to Financials to enable electronic receipting or acknowledgment of payment for inspection, expiations, etc.

M

6.5.12

Able to interface with Customer Services to: • Receive inspection requests, • Record customer contact details, • Record nature of complaints, • Communicate inspection results.

M

6.5.13 Able to link with handheld computers for recording of inspection details in the field, using wireless technology via the Internet or private data network.

HI



M

6.6.2

A set of standard exception reports are available for regular use (Eg. inspection schedule overridden, inspections not completed with performance limits, inspections undertaken outside of the maximum alert warning period, etc).

HI


6.6.4 Able to provide alerts triggered from particular audit trail events. (Eg. failed inspection, etc). HI



6.7 Data content House Number Street Name Suburb Lot (Including DP and Section Number) Development Application Number DAC Reference Number Private Certifier Reference Number Classification Inspection Category Task Details Contact Name (S), Including Occupant and Owner Contact Number Request Date Request Time Inspection Date Logging Officer Inspecting Officer Inspection Reference Number Inspection Status Inspection Commencement Date Inspection Due Date Inspection Start Time Inspection End Time Inspection Duration Inspector Reference Inspection Delay Comment Inspection Notes/Comments E-Mail Addresses Heritage – State/Local or Contributory, or Adjacent To Flood Zones/Watercourses Significant Trees Main Arterial Roads Easements Land Management Agreements Unique Information (Eg. Fill on Allotments, Soil Instability, Etc.) Enforcement Notices Zoning Result Flag



7. ESSENTIAL SAFETY PROVISIONS 7.1 Essential Safety Provisions - Business Purpose Legislative Requirement

• To fulfil relevant legislative and fire safety provision requirements



7.2 Procedural Flow – Essential Safety Provisions

Automatically prompted for

ESP considerations

Property

Building Applications

Proposed development

requires schedule of

ESPs

No further ESP

consideration

ESP Database

Prepare forms 1,2 and 3 Form 1- Schedule of ESPs Form 2- Cert of Compliance

With ESPs Form 3- Cert of Compliance

With maintenance procedures for ESPs

Schedule sent to

developer

Complianceform

ESP flag checked in Property

Automatic reminders

sent

Management of annual

returns throughlicensing Module

Licensing Form 3 - AnnualReturn

Developer

No

Yes

Linked to Certificate of occupancy

No form returned triggers

inspection

Inspections

Form 2 returned ?Yes

No

Log Book



7. Essential Safety Provisions Ranking Comment 7.3 Functionality

7.3.1 Able to identify/flag all properties that are subject to Essential Safety Provision (ESP) requirements (but allow manual override).

M

7.3.2 Able to automatically link an application to an existing property to assess whether ESP’s are required. M

7.3.3 Automatic alerts/notification where size/classification triggers ESP requirements. M

7.3.4

Able select individual requirements from a standard list of safety provisions, depending building requirements, and have these merged into standard forms (MS Word, etc.) to be sent to building owner.

M

7.3.5 Alerts/reminders sent automatically when ESP forms are not returned within specified time frames (to officer and owner)

M

7.3.6 Able to attach ESP returns to property records for viewing M


7.4.1 Able to generate ad hoc queries on any combination of key data fields without the need for specific systems knowledge.

M


M


I

7.4.4

Sets of standard reports are available for regular use, such as: • Properties requiring ESP’s, • Outstanding annual returns (form 3’s), • Requirements not met.

M



HI


7.5.1 Able to link ESP’s directly to property records. M

7.5.2

Ability to integrate Development Applications/ESP with Licensing module to automatically create a licensing record when development application requiring ESP is approved. Licensing module to manage the receipt of annual ESP returns.

M

7.5.3 Development Applications able to automatically identify developments that require ESP’s. M

7.5.4 Able to link ESP’s to Section 7 requests. M

7.5.5 Able to accept ESP returns electronically. M

7.5.6 Able to attach documents electronically (Eg. ESP forms, site plans, correspondence, etc.). M



7. Essential Safety Provisions Ranking Comment

7.5.7 Links with word processing software (MS Word, etc.) to access document templates, automatic mail merges, etc.

M

7.5.8

To interface/integrate with e-mail (Eg. Microsoft Outlook) for: • Receive/process ESP returns and sending ESP

forms, • Notifying customers when ESP is due.

M

7.5.9 Able to link to documents stored in a Document Management System associated with an individual ESP property return.

M



M

7.6.2 Sets of standard exception reports are available for regular use. HI





7.7 Data content Development Application Number Address of Building Reference Number Owners Name Floor Area Standard List of Essential Safety Provisions Certificate of Occupancy Building Classification Assessment Type



8. Heritage Land

9. Land Management Agreements

10. Community Land / Non Community Land (Operational, Road Reserves)

11. Road Reserves

LAND AND PROPERTY INFORMATION SYSTEM FUNCTIONAL REQUIREMENTS LAND MANAGEMENT MODULE The Land Management subject group contains the functional requirements for the following detailed areas/modules:



8. LAND MANAGEMENT 8.1 Business Purpose


• To maximise the community benefits from Council owned/controlled land and facilities • To allow efficient community access to Council owned/controlled land and facilities i.e.

through on line booking and payment systems for hall hire, tennis courts, etc.

• To maintain and protect historic sites within the community for future generations to enjoy. Legislative Requirement

• To fulfil relevant legislative requirements under the Local Government Act 1999. Internal/Council Management

• To maintain accurate details of all land/property owned/controlled by Council. • To assist with the management of environmental issues by linking a diversity of environmental

factors to achieve best practice environmental management. • To assist with recording and measuring performance targets for Council owned/controlled

land and facilities (financial and non financial).

• To maintain accurate details of Heritage listed properties

• To provide a integrated link between Council land management and natural resource management i.e. Water Catchment Boards, Soil Boards, Pest Control Boards

Alternative Delivery N/A

Functionality for Land Management is divided into the following topics

• Heritage Land

• Land Management Agreements

• Community Land

• Non Community Land

• Road Reserves



Procedural Flow – Land Management

Council Owned/Controlled Property

Heritage Property

Heritage Agreements

Internet

Contributory heritage

Flag & details

Customer

Property

Local heritage

flag & details

State heritage

flag & details

Internet

State Dept

Records Mnmt

AssetMnmt

Rates Accounting

Develop applications

CouncilDevelop

plan

Applicationfor heritage

status

CustomerMnmt

GIS

CouncilDevelop

plan

Land Mnmt

Agreements

Section 7’s

Community land flag & details

Operationalland flag & details

Road reserveflag & details

Communityland reg

General Ledger

Lease/ contract mnmt

CommunityMnmt Plans

GIS



8. Heritage Land Ranking Comment 8.1 Functionality

8.1.1 Able to flag land as Heritage listed, and either national, state, local or contributory. M

8.1.2

Able to categorise the nature of Heritage items with major and minor categories, with a free-form data field available for comment. Including major categories such as: • Trees/native vegetation, • Architectural merit, • Cultural (Aboriginal, European, Natural), • Dam, • Mine, • Significant trees, • Etc.

M

8.1.3 Able to identify what is Heritage listed, (Eg. building versus wall, etc.) and identify its location. M

8.1.4

Able to flag entries on the interim Heritage list and able to distinguish between Local and State Heritage items as:

• Interim State, • Permanent State, • Interim Local, • Permanent Local.

HI

8.1.5 Able to show a ‘from’ date for when properties are added to the interim or permanent Heritage list. M

8.1.6 Able to flag against adjoining land that a Heritage item exists locally (this affects how property can be dealt with under the Development Act).

M

8.1.7 Able to access the history of restrictions imposed on Heritage listed property. HI

8.1.8 Able to provide a warning when the Heritage status is under appeal, and maintain a history of appeal decisions.

HI

8.1.9 Able to readily identify any grants or funding invested in a Heritage item or property. I

8.1.10 Able to add workflow tasks (Eg. for consulting with community). M

8.1.11 Ability to revoke Heritage status (controlled access), with a comment as to reason for removal in a free text field (for reference).

M


8.2.1

Able to generate ad hoc queries on any combination of key data fields without the need for specific systems knowledge. (Eg. List of properties with revoked Heritage status).

M


M


I



8. Heritage Land Ranking Comment

8.2.4

Sets of standard reports are available for regular use, such as: • Heritage listing by state, local or contributory, • Listing by interim, permanent, etc. • Comparison of current and prior year data, • Heritage listed properties in the current year, • Heritage listed properties in previous years, • Applications and requests currently under

investigation.

M



HI

8.3 Interfacing/Integration 8.3.1 Able to link to property data. M

8.3.2 When subdivisions occur for a Heritage listed property, able to copy Heritage status across to the correct portion of the division to which the Heritage listing applies.

M

8.3.3 Able to perform bulk updates for Heritage listed properties (Eg. if an entire suburb is Heritage listed, properties do not have to be updated individually).

M

8.3.4 Able to integrate with the rates accounting module to flag a Heritage listed property as non-rateable, issue a rates notice and rebate information.

M

8.3.5 Able to integrate with development applications module, for highlighting Heritage properties and possibly limiting access to development.

M

8.3.6 Able to prevent progress of a development application before the appropriate consultative steps have been completed with the Heritage bodies.

M

8.3.7 Able to import data from external bodies (Eg. State Departments, Heritage agreements, etc.). HI

8.3.8 Able to link with Planning SA for access to Development Plans. M

8.3.9 Able to link with the State Heritage list. M

8.3.10 Able to link to any Heritage Agreements and/or Land Management Agreements. M

8.3.11 Able to attach digital photos. I

8.3.12 Able to links with a GIS for access to Heritage information (through the property module). M

8.3.13 Able to link to Records Management System if records (Eg. Land Management Agreement, etc.) exist for a property.

M

8.3.14

Able to link with the Internet so that customers can access Heritage information (Eg. development opportunities, Plan Amendment Reports, Heritage surveys, etc.).

HI

8.3.15 Able to link to an Asset Management System. M 8.3.5 Able to hyperlink to appropriate legislation for reference. I

8.3.16

Able to link with a customer service system so that action resulting from customer request, applications for Heritage status, etc. may be tracked and communicated through to resolution.

HI




8. Heritage Land Ranking Comment


M






8.5 Data content Heritage Type Heritage Category (Including Major and Minor Categories) Comment Location Field Identifier Field Date Active Date Added Hill Data Date Of Revocation Revocation Free Data Field Grants/Funding Received Grant/Funding Source Grant/Funding Amount Rates Issues Date of Review Appeal Data Conditions Workflow Status/Date Development Issues Consultation Status (Including Affected Property, Date Sent, Closing Date, Description, Number Of Returns, How Many Responsible, Decision, Review Date, Etc.).



9. Land Management Agreements Ranking Comment 9.1 Functionality

9.1.1

Able to maintain a variety of major and minor warning indicator categories attached to each agreement, with a free-form data field available for comment. Including major categories, such as: • Floodland, • Watercourse, • Easement, • Significant vegetation, • Remedied contamination, • Contaminated, • Encumbrance, • Etc.

M

9.1.2 Able to attach a start and end time period for the agreement or date overturned. M

9.1.3 Able to indicate whether an agreement is active or has lapsed. M

9.1.4 Ability to retain history of lapsed agreements. M

9.1.5 Ability to readily identify any grants or funding invested in an item or property. HI

9.1.6 Maintains history of owner names and properties attached to Land Management Agreements (mainly for when properties are transferred between owners).

M

9.1.7 Maintains history of changes to a Land Management Agreements. M

9.1.8 Ability to identify if an owner has applied for, the progress of and any change to an agreement and retain history of such applications.

M

9.1.9 Able to add workflow tasks to manage the Land Management Agreement process. M

9.1.10 Able to identify easily with automatic warning indicators whether the agreement is notifiable or not. M

9.1.11 Able to trigger automatic notifications and escalation if not completed within a predetermined timeframe. M

9.1.12 Upon sale/transfer of a property, able to produce automatic warning if a Land Management Agreement exists.

M


9.2.1

Able to generate ad hoc queries on any combination of key data fields without the need for specific systems knowledge. (Eg. Query on properties having Land Management Agreements and search by unique reference number as well as property and location).

M


M


I

9.2.4 Sets of standard reports are available for regular use. (Eg. reporting on numbers of agreements by category and active period).

M




9. Land Management Agreements Ranking Comment


HI


9.3.1

Able to flag against a single or multiple properties that a Land Management Agreement exists. Able to perform bulk updates to properties for Land Management Agreements (Eg. if an entire suburb has a Land Management Agreement attached, properties do not have to be updated individually).

M

9.3.2 Able to integrate with the Development Application module highlighting LMA’s, conditions, restrictions, etc. M

9.3.3 Able to link with Section 7’s highlighting LMA over the property M

9.3.4 Able to link to the GIS for spatial data representation. M

9.3.5

Able to link to Records Management System (Eg. able to attach further information for clarification to warning indicators where formal documentation is not available to be attached).

M

9.3.6 Able to hyperlink to appropriate legislation for reference. I 9.3.7 Able to link to an Asset Management System M 9.4 Audit Requirements


M






9.5 Data content Land Management Agreement Reference Number Owner Name Property Id Status Flag (Registered, In Progress) Unique Agreement Document Reference Agreement Category (Including Major And Minor Categories) Start Date End Date Date Overturned Free Data Field Against Categories Active/Lapsed Indicator Grant/Funding Details Grant/Funding Source Grant/Funding Amount Notifiable Indicators Event (to enable tracking of Agreement progress) Change request date Description of request Requestor



10. Community Land/Non-Community Land Ranking Comment 10.1 Functionality

10.1.1

Able to determine whether a property is on: • Crown land not under Council control, • Crown land under Council control (Community land), • Council owned land (majority will be community land

but some will be council owned, for Operational purposes (Eg. Council buildings, etc.),

• Other land under Council control.

M

10.1.2 Able to flag separately Community land, Operational land and Non-community land. M

10.1.3 Ability to flag whether a management plan has been adopted, when performance plans are due, review date, etc. (and able to override this facility).

M

10.1.4 Able to add workflow tasks (Eg. based on category of property; for management plans, etc.). M

10.1.5 Able to change land classification given the appropriate approval process as prerequisite. M

10.1.6 Able to maintain history of all status changes with date. M

10.1.7

Able to attach prerequisites before certain actions may be performed in line with legislative requirements (Eg. can’t flag Community land as Operational unless a resolution has been agreed to).

M

10.1.8

Able to access details of resolutions, such as: • Date, • Reason, • Item number in Council agenda, • Etc.

M

10.1.9 Able to divide community and non-community land into subsets. M

10.1.10 Able to identify who manages the community/non-community land. M

10.1.11 Able to identify the Council position responsible for the community/non-community land by position. M

10.1.12

Able to identify if the property is hired including details, such as: • What part of the property, • Who holds the hiring agreement, • Period of hire agreement including start and end

dates, • Etc.

M

10.1.13 Able to identify any interested parties or associations etc. with regard to the property. M


10.2.1

Able to generate ad hoc queries on any combination of key data fields without the need for specific systems knowledge. (Eg. Track and report on land history, query properties on Community Land, council owned property, etc.).

M


M


I



10. Community Land/Non-Community Land Ranking Comment

10.2.4

Sets of standard reports are available for regular use. Such as: • Workflow progress against performance targets, • All work in progress and their stages, • Which responsible officers overseeing the

changes.

M



HI

10.2.7

Able to access the management plan related to the land, item or property and link single plan to multiple properties. For each management plan, able to show dates; review dates; when due, etc.

M

10.3 Interfacing/Integration 10.3.1 Links with Licensing, permits and occasional hire. M

10.3.2 Links with the Lands Titles Office to determine whether there are any trusts, dedications, etc. attached to the land and access documentation.

M

10.3.3 Links with a Records Management System (Eg. for linking to resolutions, management plans, trusts, dedications, etc.).

M

10.3.4 Able to hyperlink to appropriate legislation for reference. I 10.3.5 Links with an Asset Management System. M 10.4 Audit Requirements


M






10.5 Data content Land Classification Indicator (S) Community/Operational Land Indicator (S)- (Including Major and Minor Categories) Resolution Details Land Manager Identifier Responsible Employee (S) (Position (S)) Interested Parties Identifier Management Plan Review Date Management Plan Adoption Status Management Plan Hirer details Date for Status Changes



11. Road Reserves Ranking Comment 11.1 Functionality

11.1.1 Able to record streets/roads as properties with a unique Street/Road identifier. M

11.1.2 Able to uniquely identify sections of streets/roads within the property system (Eg. rapid numbers). M

11.1.3 Able to record the owner/maintainer of the street/road (Eg. Council, Transport SA, an individual, rented, etc.). M

11.1.4 Able to register location of significant trees and buildings on streets/roads. M

11.1.5 Able to maintain history of street/road name changes or by aliases, local knowledge, etc. HI


11.2.1

Able to generate ad hoc queries on any combination of key data fields without the need for specific systems knowledge. (Eg. access details of applications currently approved or in the approval process and able to search by street/road, etc.)

M


M


I

11.2.4 Sets of standard reports are available for regular use. M



HI

11.3 Interfacing/Integration 11.3.1 Able to link to property data. M

11.3.2 Able to attach Development Applications to a street/road (based on street/road name). M

11.3.3 Able to link to street register for each street/road. M

11.3.4 Able to link to GIS (to show streets/roads subject to flooding, easements, etc.). M

11.3.5 Able to hyperlink to appropriate legislation for reference. O

11.3.6 Able link to Asset Management System/Pavement Management System for street/road classifications, widths, record of stormwater/drainage systems, etc.

M



M






11.5 Data Content Street/Road Identifier Road Name Road Section Number Previous Road Name Alternate Road Name Rapid Number Road Owner Location Register From To Suburb Name Lot Number Plan Number



12. Licenses/Permits/Casual hires

13. Environmental Health

14. Waste Management

LAND AND PROPERTY INFORMATION SYSTEM FUNCTIONAL REQUIREMENTS LICENSING MODULE The Licensing subject group contains the functional requirements for the following detailed areas/modules:



12. LICENSES & PERMITS/CASUAL HIRES 12.1 Licenses & Permits- Business Purpose


• To authorise and coordinate the use of public spaces and Council owned facilities appropriately so as to provide protection to the community.


• To fulfil relevant legislative requirements under the Local Government Act 1999. Internal/Council Management

• To regulate and control the activities of businesses and individuals within the Community.

• To allow Council to protect it’s liability exposure in the event of damage.

• To provide accurate information on licence and permit holders eg responsible person, property, to assist Council with the regular renewal process.

• To identify and raise revenue to offset the costs to Council.




12.2 Procedural Flow – New Applications Prior Year Roll Over

Workflow

Application received at

Council

Application received via

Internet

Cash Receipting

Automatic allocation of

minimum tasks

Property

Paymentgateway

Calculation of Fees

General Ledger

License/ permit # assigned

GIS

Allocation of Fees

Key details

Allocation ofrestrictions

Automatic Roll-over

of Licenses

Issue Keys

Word processor

Reservation/ permit #

automatically assigned

License

Agreement/Permit

GIS

Property

Renewal

letters

Preliminary

Booking

Customer

Confirmation

received

Venue

booking/

Check

availability

License/permit lodged

Available? Alternatesolution?

Classification

allocated

Fee Types

Terms & Conditions

Terms andConditionsAttached

Add/remove

tasks

Cash

Received

Customer

Task database

License/permit issued

Asset Maintenance

Inspections

No

Yes

Yes No

Application

Denied



12. Licensing and Permits Ranking Comment 12.3 Functionality

12.3.1 Able to issue Licences/Permits against a property or if necessary independent of a property. M

12.3.2 Able to issue multiple Licenses/Permits against a single property, or a single license to multiple properties. M

12.3.3 Able to record Licensee/Permit holders details as an organisation or individual, and able to differentiate the two.

M

12.3.4 Able to link Licensee/Permit holder to multiple License/Permit classifications, activities, venues and time periods.

M

12.3.5

Able to maintain multiple License/Permit classifications to which different optional workflow processes may be assigned, each with a unique number sequence. License/Permit classifications include: • Community Development, • Private Function, • Environmental Health, • Sporting Club Hire, • Etc.

M

12.3.6 Able to over-write or append additional notation to the narrative provided by the default classification type. HI

12.3.7

Able to enter and maintain default list of activities for assignment to each Licensee/Permit holder containing a short narrative to appear on the document negating the need to retype, such as: • Over Sixties Club, • Street Entertainer, • Swimming Pool, • Aerobics Class, • Mobile Food Vendor, • Charity Collection.

M

12.3.8 Able to over-write or append additional notation to the narrative provided by the default activity type. HI

12.3.9 Ability to maintain condition levels for automatic warning indicators with facility to switch on and off. I

12.3.10 Able to produce automatic warnings/notification ensuring Public Risk Insurance details are received and recorded before License/Permit is issued.

M

12.3.11 Ability to issue a License/Permit by using a standard base template, with the ability to add/delete specific provisions/conditions/restrictions.

M

12.3.12

Able to enter seasonal, annual and ad hoc start and end periods, allowing automatic generation of fees based on License/Permit type issued and the period to which it relates.

HI

12.3.13

Flexibility to maintain a variable fees based chart with the method of fee calculation being determined by the License/Permit classification and activity chosen. Calculation methods being: • Floor space, • Number of units, • Etc.

M

12.3.14 Ability to amend default fees and add additional ad hoc fees during issue. HI



12. Licensing and Permits Ranking Comment

12.3.15 Automatic warning facility ensuring fees are received before keys are released. M

12.3.16 Ability to switch fee calculation facilities on and off, or able to set fee amount to zero. M

12.3.17 Facility to record details of keys and link to specific venue/location and record use. HI

12.3.18 Maintain registration of issue/receipt of keys including details of individuals responsible for them and issuing officer.

M

12.3.19

Ability to issue and record restrictions to an existing License or Permit whilst active (Eg. Water quality restriction), recording: • Individuals notified, • Start and end period of restriction, • Reason for restriction, • Contact details for further information.

M

12.3.20 Ability to change or add new contact details to Licensee/Permit holder details whilst processing application.

M

12.3.21

Workflow able to support multiple License/Permit classifications having unique workflow tasks associated with each classification (Eg. Public entertainers, Sporting club meetings) and multiple contacts.

M

12.3.22 Able to easily add, delete or amend assigned workflow tasks. M

12.3.23

Ability to maintain a variety of standard communication documents issued depending upon License/Permit classification and activity (Includes ability to mail merge from the GIS/property information a standard information notice stating the nature of the event and date of event).

M

12.3.24

Ability to create a standard set of License and Permit conditions and associated documents (linked to word processing package) with ability to attach specific conditions and restrictions when issuing License/Permit.

M

12.3.25

Able to have automatic prompts recommending the use Council resources based on the type of licence/permit requested (Eg. for corporate conference: data projector, white boards, microphones, etc.)

12.3.26 Ability to issue work requests to relevant contacts at the venue for specific requests (Eg. cutting grass, line painting, seating arrangements, etc.).

HI

12.3.27

Ability to view status of License/Permits with a standard set of decision or status codes: • Applied, • Approved, • Refused, • Withdrawn, • Awaiting Payment, • Cancelled, • Etc.

M

12.3.28 Automatic warning indicator attached to application if extends beyond a certain period before receipt is made. M




12.3.29

Flexible search facility to enable search and inquiry made by: • License number, • Specific address, • Venue, • Date range, • Owner/Licensee, • Manager, • License type, • License classification, • Etc.

M

12.3.30

Ability to maintain central record of venue usage to prevent duplicate bookings and facilitate inquiry. Whilst application is processed a temporary reservation is made upon the venue during processing to avoid duplication.

M

12.3.31 Ability to view photographs of venue, print maps and inquire upon and choose suggested floor layouts. I

12.3.32 Automatic invoicing upon request for License/Permit. Issue of License/Permit to be made only when receipt (monetary, grant or other) has been registered.

HI

12.3.33 Electronic record of acceptance of terms and conditions when applying over the Internet. M

12.3.34 Maintain record of both deposit and noise bonds for each License/Permit. Ability to prevent refunds or only allow partial refund if infringements are made.

M

12.3.35 Ability to attach reports or documents to Licenses/Permits and/or Licensees/Permit holders of reported damage/infringements or breakages.

HI

12.3.36 Ability to terminate and/or revoke License/Permit with default reason/categories. M

12.3.37 Ability to flag warning against Licensee’s with a history of damage, breach of conditions or unpaid fees. M

12.3.38 Able to process automatic rollover of seasonal and annual Licenses/Permits leaving them in a suspended status awaiting approval for renewal.

M

12.3.39 Automatic Annual License/Permit renewal scheduling facility, prompting action before license expires showing previous License details and fees paid.

HI

12.3.40

Use check-box facility for recurring items to attach standard workflow tasks to support annual/seasonal rollover process based on License/Permit classification/activity.

M

12.3.41 Ability to transfer Licenses between properties. M

12.3.42

Ability to renew a License/Permit with the same narrative as a previous License/Permit without re-keying details, but ability to amend License period, venue and times, etc.

M

12.3.43 Have the facility to reschedule applications to times and venues ensuring optimal usage before applications are approved.

M

12.3.44 Ability to amend/extend or expand Licenses and Permits due to error or venue change, etc. and transfer fee payment history.

M

12.3.45 Ability to issue credits or refunds against Licenses /Permits/casual hires. M




12.3.46

Ability to waive fees for a variety of default reasons such as: • A grant payment to licensee, • Special dispensation, • Etc.

M


12.4.1 Able to generate ad hoc queries on any combination of key data fields without the need for specific systems knowledge. (Eg. Available venues on a specified date).

M


M


I

12.4.4

Sets of standard reports are available for regular use. Eg. • Report on statistics such as Usage, Seasonal

variations, Fees received etc for management reporting,

• License/Permit history per licensee and report on venue used and fees paid,

• License/Permit inspections due and scheduled within time parameters,

• Report on workflow progress listing all License/Permit applications in progress, the relevant stages of progress and responsible officers overseeing the application,

• Reports of forthcoming activities, • Changes in season, • Etc.

M


12.4.6

Able to maintain reporting flexibility on historic data for comparison with current year, trend analysis, predictive modelling (Eg. report on licensing/permit history by license classification or activity).

HI


12.5.1

Licenses/Permits able to integrate with property information, such as: • Owner name, • Address, • Etc.

M

12.5.2 Able to link License to single or multiple properties (during sub division process). I

12.5.3 Licenses/Permits able to integrate with Inspections module to schedule, conduct and document inspections based on licensing conditions, damages, etc.

M

12.5.4

Automatic inspection schedule for the responsible officer created through link with License/Permit classification and established through the workflow requiring inspection protocol to be set through the issuing of the License procedure.

HI

12.5.5 Able to integrate with the cash receipting module for receipting of customer payments from various sources i.e. Internet, B-Pay, agencies, etc.

M



12. Licensing and Permits Ranking Comment 12.5.6 Able to link to external system for key registry. HI

12.5.7 Able to attach documents electronically (Eg maps, pricing structure, correspondence, etc.) to venue details. HI

12.5.8

Able to link to the GIS for display of the venue to enable clarification of specific structural queries and essential details, such as: • Drainage, • Sprinkler systems, • Etc.

HI

12.5.9

Able to integrate with GIS information to enable mail merge facility to notify of any possible disruption in the immediate area, due to: • Street carnivals, • Road closure, • Etc.

I

12.5.10 Able to accept License/Permit applications and renewals electronically via the Internet with fees able to be determined at time of application.

M

12.5.11 Able to issue Licenses, Permits and renewal notices electronically via the Internet. M

12.5.12 Ability for customers to inquire on availability of venue and appropriate fees through the Internet. HI

12.5.13

To interface/integrate with e-mail and electronic fax facility for: • Notification of when work is required, • Notification of restrictive notices to licensees, • Notification to venue of specific requirements or

queries, • Etc.

M

12.5.14

Ability for customers to obtain map of location of venue from council electronically, showing facilities available including: • Parking, • Toilets, • Fire exits, • Catering facilities, • Etc.

HI

12.5.15 Ability for customers instruction for a particular format for a venue to be issued electronically to responsible officer of venue.

HI

12.5.16 Able to link documents stored in Document Management System to individual Licenses/Permits issued.

M

12.5.17

Able to integrate with asset maintenance division allowing the ability to electronically send detailed reports of forthcoming activities, changes in season, customer requests, etc.

HI

12.5.18

Able to link with customer services to: • Record application details, • Record complaint details, • Record nature of complaint.

HI

12.5.19 Able to link with Staff Calendars for control over workflow (Eg. Scheduling of tasks). HI

12.5.20 Links with word processing software to access document templates, automatic mail merges, etc. M




12.5.21

Able to integrate with finance system, receivables and general ledger for managing customer payments allowing acknowledgment of payment arrangements before release of keys is authorised.

M



M






12.7 Data content Adjustments to Fees Application Date Calculated Fee Caretakers Address Caretakers Name Caretakers Telephone Number Contact Name Contact Number E-Mail Address Emergency Contact Name(s) Emergency Contact Number(s) Free Data Field Infringements Key Reference Last Date Amended Warning Indicator Classification License/Permit End Date License/Permit Start Date License/Permit Status Activity Activity Type Narration Bond Type License/Permit Unique Number Licensee/Permit Holder Name or Title Public Risk Insurance Reference Mailing Address Notes Presidents Name Renewal Date Reservation Number Responsible Officer Restrictions of Venue Usage Secretary Name Street Names Treasurers Name Vehicle Registration Venue Location Venue Title Venue Type



13. ENVIRONMENTAL HEALTH 13.1 Environmental Health - Business Purpose


• To help protect and sustain the current environment for communities to enjoy now and into the future.

• To protect the health of the community from disease and pollution, through monitoring of

food premises, septic tanks, providing immunisations etc.

• To regulate and manage the natural resources within the community Legislative Requirement


• To efficiently monitor the various environmental health functions/services provided within Council, i.e. septic tanks, immunisations, air conditioning, Food Act etc.

• To provide a system capable of monitoring the environment


• Potential for future outsourcing of environmental health services, however, Council would still provide a strong monitoring role.



13. Environmental Health Ranking Comment 13.3 Functionality

13.3.1

Ability to enter and maintain default activity, such as: • Food, • Pool, • SRF, • Boarding House, • Cooling Tower, • Septic Tank, • Hairdresser/Beauty Salon, • Etc.

M

13.3.2

Ability to enter and maintain default category types attached to activity type, such as: • Hotel, • Deli, • Pub, • Swimming Pool, • Tattooist, • Ice Cream Vendor, • Etc.

M

13.3.3

Ability to assign certain fields as requiring mandatory input, such as: • Area code, • Property owners details, • Activity type, • Business owners details, • Etc.

M

13.3.4 Ability to flag either the property or business owners details as the postal address. M

13.3.5 Ability to view summary data and/or customise screen with a free choice of fields to display. M

13.3.6

Ability to display and inquire upon inspection status, such as: • Pending, • Scheduled, • Overdue, • Etc.

M

13.3.7 Ability to enter and maintain flexible default Food Safety Plans audit submission periods against establishment types. Able to easily add/remove tasks.

M

13.3.8 Maintain schedule of events for Food Safety Plan submission and audit. Ability to track audit report result and issue approval/failure notice.

M

13.3.9 Maintain central reference of auditors of Food Safety Plans linked to each report audited. M


13.3.11

Ability to search by and lodge complaints against either or multiples of: • Property owner, • Premises, • Mobile vendor, • Etc.

M



13. Environmental Health Ranking Comment

13.3.12 Ability to enter and maintain default complaint types containing a short description of type of complaint and indication of complaint severity.

M

13.3.13

Ability to display status of complaint, such as: • Referred to officer – under review, • Noted – no action required, • Under investigation, • Pending, • Further action required, • Resolved.

M

13.3.14 Ability to set the number of years of history to be maintained. M

13.3.15 Automatic alarm for imminent and overdue events. M

13.3.16 Ability for complainants to request follow-up and correspondence sent electronically or manually explaining action taken and result.

M

13.3.17 Ability to create and maintain a library of standard letters and notices to be used in mail merge facility for all documents and notices.

M

13.3.18 Ability to maintain, record and report unique data related to activities. M

13.3.19 Warning indicator for outstanding sample results requiring follow-up. O

13.3.20

Option of recording sample details, such as: • Date sample made, • Time of sample, • Measure of sample, • Results of sample, • Deviation, • Comments, • Name of company undertaking analysis, • Officer responsible for sample, • Etc.

M

13.3.21 Ability to maintain a standard default fee matrix linked to specific events automatically triggering an invoice charging the payee a fixed fee.

M

13.3.22 Ability to waive fees by choice of a variety of default reasons. M

13.3.23 Ability to check status of account for each establishment and inquire upon unpaid fees. M

13.3.24 Ability to record levels of training of staff at establishment. O

13.3.25 Facility to issue, track and maintain records of the value of and reasons for the issue of expiations. M

13.3.26 Ability to flag transactions for archiving at point of change of use. M


13.4.1 Able to generate ad hoc queries on any combination of key data fields without the need for specific systems knowledge.

M


M


I




13.4.4

Sets of standard reports are available for regular use. Such as: • Report on a common component, such as:

- All locations with same business owner, - All locations with same property owner.

• Report on sampling history by establishment, inspector, owner, type, etc.

• Report on status of samples between specific dates, such as:

- Number of samples taken, - Results of samples taken.

• Report on food safety plans by establishment, inspector, auditor, type, etc.

• Report on status of food safety plans between specific dates.

• Report of audit statistics such as number made, results of audits, outstanding audits, etc.

• Outstanding notification of results of audits. • Report on reasons for waived fees. • Report on expiations issued by establishment,

inspector, auditor, type, etc. • Report on payment of expiation, reason and

between specific dates, such as: - Number of expiations issued, - Reasons for issue, - Details of outstanding payments.

M



HI

13.5 Interfacing/Integration 13.5.1 Ability to link to property module. M

13.5.2

Able to search property module for location and have relevant fields automatically filled with data, such as: • Property owners name, • Property owners contact details, • Etc.

M

13.5.3 Able to link to the Inspections module, including the ability to maintain and track inspection history against properties.

HI

13.5.4 Ability to lodge complaints electronically over the Internet. M

13.5.5 Ability to attach reports or documents to establishments linked to the property module. M

13.5.6 Ability to enter new registration as an application over the Internet. M

13.5.7

To interface/integrate with e-mail and electronic fax facility for: • Notification of complaints, • Response to complaints, • Work flow requests, • Follow up requests, • Requests for further information, • Etc.

M




13.5.8 Able to issue decisions electronically via mail merge or other facility. M

13.5.9 Links with word processing software to access document templates, automatic mail merges, etc. M

13.5.10

Able to link with customer services to lodge complaints via property module or GIS reference for: • Record complaint details, • Record complainant contact details, • Follow up request, • Etc.

M



M


13.6.3 Able to produce specific exception reports on adjustments to key data.

M

13.6.4 Able to provide alerts triggered from particular audit trail events. (Eg. receipt of complaint, etc).

HI



13.7 Data content Location Address Property Owners Name Property Owners Address Telephone Number Fax Number Mobile Number E-Mail Address Business Owners Name Business Owners Address Postal Address Reference Activity Reference Category Reference Status Field Location Reference Demerit Total Premises Code Patron Code Training Code Outstanding Corrective Remarks Area Code Comments Boxes Complaint Type Complainant Name Complainant Contact Address Complaint Status Complaint Date Complaint Details Complaint Unique Reference Auditor Name Auditor Contact Address Auditor Contact Number ANZFA Risk Classification Food Safety Plan Report Date FSP Audit Due Date Application Unique Reference Expiation Unique Reference Expiation Date Unique Sample Reference Sample Date Sample Time Sample Measure Sample Results Sample Deviation Sample Company Name Sample Company Contact Details Officer Responsible for Sample Fee



14. WASTE MANAGEMENT 14.1 WASTE MANAGEMENT - Business Purpose


• To manage and control the disposal of waste for residents and businesses within the community

• To ensure a high quality customer focused waste management service is provided to the

community, i.e. consistent timely pickups, cost effective, timely response to customer requests etc.

• To protect the environment through reductions in non-recyclable waste, assisting the community to achieve State Government’s vision of zero non-recyclable waste by 2020.

Legislative Requirement N/A Internal/Council Management

• To provide complete, accurate and efficient waste management information, allowing Council to either, provide a high quality waste management service, or to manage an external provider of this service, i.e. service levels, cost, environmental issues etc.

• To assist Council with the control of waste within the community


• Potential for complete outsourcing of waste management services.



14. Waste Management Ranking Comment 14.2 Functionality

14.2.1 Able to maintain a register of all waste bins in the Council area, either linked to individual properties or held in stock awaiting allocation to customers.

M

14.2.2 Ability to link multiple bins and multiple bin types to a property via electronic recording facility such as bar coding.

M

14.2.3 Able to allocate bins to a property from inventory, automatically producing a delivery work order and fee. M

14.2.4

Able to record the amount (volume/weight) of refuse collected and differentiate by type, such as: • Domestic, • Green, • Hard, • Recyclable, • Etc. For each individual customer, for each collection.

M

14.2.5 Able to differentiate between the collection of domestic waste and industrial waste. M

14.2.6

Able to maintain property waste collection history i.e. volume of waste per type, seasonal impacts, etc. to be used for predictive/trend analysis to support decision-makers.

HI

14.2.7 Able to split/differentiate Council areas for purposes of waste collection (not necessarily by ward) and flag these areas for reporting purposes.

M

14.2.8 Able to flag the waste collection pick-up day(s) for each area and link this to the property. M

14.2.9 Able to maintain multiple bin rental/purchasing fee types (Eg. based on bin size, usage, type of waste, concessions, etc).

M

14.2.10 Able to automatically calculate bin rental/purchase fee based on fee type and monthly/weekly volume. HI

14.2.11 Able to override automatic fee calculation (Eg. Waste collection fee) with reason codes/free form text explanation attached (audit report to collate).

HI

14.2.12

Able to maintain multiple waste collection fee types based on: • Volume, • Type of waste, • Fixed charges, • Tiered rates, • Able to set maximums/minimums, • Concessions, • Etc.

M

14.2.13 Able to allocate customers a no fee flag to by pass fee calculation i.e. Council’s internal waste etc. and record reasons for adjustment.

M

14.2.14 Able to record customer/property complaint history, i.e. number of replacement bins, damaged bins, complaints, etc.

M

14.2.15 Able to record waste destination data, i.e. where the waste was dumped, volume of waste dumped, type of waste dumped, etc.

M



14. Waste Management Ranking Comment

14.2.16 Ability to record other relevant information relating to properties/areas i.e. accessibility of streets, width and special truck requirements.

HI

14.2.17 Able to maintain details on service levels and types of services based on property/occupancy type i.e. domestic, industrial, etc.

HI

14.2.18 Provide warning flags/notification, where actual service levels fall below agreed limits or key performance indicators.

HI

14.2.19 Able to inquire and search data across all fields, including key word and wild card searches. HI


14.3.1

Able to generate ad hoc queries on any combination of key data fields without the need for specific systems knowledge. (Eg. total waste dumped at site B, total recycled waste at site D, etc).

M


M


I

14.3.4

Sets of standard reports are available for regular use, such as: • Meet all legislative reporting requirements set by

the EPA, State Govt, etc. • Customer query/call statistics, • Volume of refuse by type, • Volume of refuse by area, • Number of collections by day/week/month, • Domestic versus Commercial, • Trend/seasonal volume analysis, • Report on performance statistics combining both

internal and external sources of data.

M



HI


14.4.1 Able to integrate directly with property system to attach bins/services to properties, owners and occupiers. M

14.4.2 Able to integrate with the rates module for charging of bin rental/purchases and waste collection services. M

14.4.3 Able to integrate with central NAR. M

14.4.4 Able to integrate with cash receipting for customer receipts for waste collection and bin rent/purchasing. M

14.4.5 Ability to load and maintain statistical information from third party contractors and link collection levels to properties, refuse type and dates collected.

M

14.4.6 Able to receive/attach information electronically from external sources i.e. land fill, weight bridges, EPA etc. M

14.4.7 Able to link data reporting and recording with GIS, for bulk maintenance updates, customer inquiry, trend analysis, area mail merge functional, etc.

M



14. Waste Management Ranking Comment

14.4.8 Able to link with the Internet allowing the ability to request additional refuse services, replacement bins lodge complaints and pay invoices.

M

14.4.9

Ability to integrate/interface with e-mail and electronic fax facility for; • Additional work requests, • Replacement bins, • Etc.

M

14.4.10

Able to link directly with a word processing software to maintain and access a variety of standard letters for issue (includes ability to mail merge GIS /property information a standard information notice stating the nature of event and date).

M

14.4.11 Able to link with documents stored in Document Management System. M

14.4.12

Able to link with customer management system to: • Record complaints, requests and inquiries, such as

replacement bins, etc. • Issue work requests to relevant contacts attached

to a location or specific service.

M

14.4.13 Able to link to general ledger for recording and management of financial transactions, debt collection, etc.

M

14.4.14 Able to link with the Contract management application for management of contract performance against agreed service levels.

M



M






14.6 Data content Property Owner/Occupier Property Address Details (Location/Postal/Details) Unique Identifier (Internet Log In) Pin/Password (Internet Log In) Bin Number(S) Bin Type/Size Collection Area Waste Type Waste Volume/Weight Collection Day(S) Dumping Location Bin Rental/Purchase Fee Type Waste Collection Fee Type Zero Fee Calculation Flag Service Level Criteria Key Performance Indicators Dates Weights/Tonnage Contractor Name Contractor Contact Numbers Service Contract Unique Reference Recycling Cost Breakdown



15. PROPERTY

16. RATES

LAND AND PROPERTY INFORMATION SYSTEM FUNCTIONAL REQUIREMENTS RATES & PROPERTY MODULE The Rates & Property subject group contains the functional requirements for the following detailed areas/modules:



15. PROPERTY 15.1 PROPERTY - Business Purpose


• To assist Council with property related customer enquiries, allowing easy navigation from a property record to any related modules.



• To accurately identify individual parcels of land for which Local Government conducts business eg rates, development applications, dog registration etc.

• To form the base for the collection and management of all property related information from

which all other modules will draw on. Alternative Delivery N/A



15.2 Procedural Flow – Property

Property

Proposed Property(s)

Current Property

Historic Property

- Property Location - Area - Zone - Land Use - Titles - Parcels - Plans

Electoral Roll

Infringements

Inspections

NAR

Dogs

Development Applications

Rates Section

7

ESP’s Licensing

GIS

GIS

Rates

PlanningSA

Valuer General

LTO

Land Agent

Dev Apps

Dev Plan

NAR

RecordMnmt

Community

Plans

Asset Mnmt



15. Property Ranking Comment 15.3 Functionality

15.3.1 Able to flag a property status as proposed, current or historic. M

15.3.2 Able to easily change a property status between proposed, current and historic (with audit trail). M

15.3.3 Able to create proposed properties i.e. based on land division information from Development module. M

15.3.4 Able to create proposed property layers with alerts and workflows to ensure proper order of processing. M

15.3.5 Confirmation of proposed properties triggers current property to be historic. M

15.3.6 Able to attach an effective date when a proposed property will become current, and the current will become historic.

M

15.3.7 Able to make a proposed property current in advance of confirmation from Valuer General. M

15.3.8 Able to add/delete/modify property address data on an individual basis (Eg. streets, suburbs, house/unit numbers, prefixes, etc.), including bulk maintenance.

M

15.3.9 Able to add/delete/modify all parcel details (including plans and plan types, parcel and types, titles and types, GIS References (and to generate).

M

15.3.10 Able to modify data on properties regardless of status. M 15.3.11 Able to record/modify services against properties. M

15.3.12 Able to reverse a change in property status i.e. proposed property made current in error. M

15.3.13 Able to provide notification to staff of properties about to expire requiring action (could also be done through the Applications module).

O

15.3.14 Able to merge multiple existing properties into one property. M

15.3.15

Able to easily select current property information i.e existing owners and billing information for copying over to a proposed property. Flexible, allowing a choice of selectable data.

HI

15.3.16 Able to create a new property, not necessarily from a land division; or delete a property, not necessarily as the result of a land division (with an audit trail).

M

15.3.17 Able to attach multiple names and types to properties i.e. owner, occupier, ratepayer, etc. M

15.3.18 Able to record owner(s)/occupier(s) against the property, and/or the title(s) and/or the parcel(s) M

15.3.19

Able to configure a multi-tiered hierarchy of property data (parent properties, child properties, sub-child properties, etc.). Able to associate tenancies with a property.

O

15.3.20

Able to copy property information between properties (including child properties) without re-keying i.e. ownership, services, land use, applications, conditions, etc., with the ability to select data elements.

O

15.3.21 Able to handle multiple land use codes per property. HI

15.3.22 Able to identify adjoining/contiguous properties and include Single Farm Enterprise identification. O

15.3.23 Able to identify predominant use of a property (Eg. a house/deli, where predominant use is residential.). O



15. Property Ranking Comment

15.3.24

Able to record multiple valuations per property and the source of valuations: • VG Site Value, • Capital Value, • Notional Value, • Private Certifier Value, • Proposed values, • Historical Values, • Etc.

HI

15.3.25 Able to flag Council/Crown owned land for exclusion from Rating and Electoral Role extracts. M

15.3.26 Able to attach owners to a property before or after a Certificate of Title has been issued. O

15.3.27 Able to create or delete a Certificate of Title relating to a property within the Property module. M

15.3.28 Able to attach a name to a property i.e. Masonic Lodge and a type (Eg. normal, reserve, retirement village, etc.).

I

15.3.29 Able to add/attach/delete conditions or notices to a property. M

15.3.30 Able to add/attach/delete bulk conditions or notices to properties based on individual fields. M

15.3.31

Able to set up flexible preconditions which either restricts or triggers future events (Eg. Entry of data into a field may be dependent upon data being entered in another field(s) first).

HI

15.3.32

Able to maintain and view all historical property data linked to current property/properties (Eg. Changes in title, land use history, previous owners, purchase and sale history, etc.).

M

15.3.33

Able to group properties by common elements i.e. address, ward, zone, land use to facilitate bulk maintenance rather than having to edit properties individually (Eg. Ward boundary changes, shopping centre tenancy changes, etc.).

M


15.4.1 Able to generate ad hoc queries on any combination of key data fields without the need for specific systems knowledge, i.e. customised property queries.

M


M


I

15.4.4 Sets of standard reports are available for regular use. e.g. New properties report M



HI

15.4.7

Able to perform searches from the GIS to the Textural System (such as bulk updating of zones) and searches performed from the Textual System to be displayed on the GIS.

HI



15. Property Ranking Comment 15.5 Interfacing/Integration

15.5.1 Able to seamlessly integrate with all other land and property modules (Eg. Rates, Animal Control, Development, Section 7’s, etc.).

M

15.5.2 Able to highlight all links with other modules when a property is deleted (with audit trail) and/or made historic. Able to provide warnings for unremoved links.

I

15.5.3 Able to link development applications directly to a current property, or a proposed property when land divisions are approved.

M

15.5.4 Able to link to electronic image of plans (Eg. Deposited Plans, etc.). O

15.5.5 Able to select/restrict individual fields from the imported data files when updating Council information. M

15.5.6 Able to import data files from external sources i.e. Land Titles Office, Valuer General, Planning SA, Land Agents.

M

15.5.7 Able to reverse imported data files prior to reaching a point of electronic signoff for finalisation. M

15.5.8 Able to link to the GIS throughout the process (Eg. For bulk maintenance, selection of properties for mail outs, etc.).

HI

15.5.9 Able to give account customers access to property information via the Internet (i.e. assessment book information, etc.).

O

15.5.10 Able to create mailing lists via mail merge and/or query. (Able to generate standard letters from property data).

M

15.5.11 Able to link with records/document management system. HI

15.5.12 Able to link to asset system. I 15.6 Audit Requirements


M






15.7 Data content Name(S) – Owner/Occupier, Etc. Address(Es) – Property/Mailing/Preferred/Alternate – See Name and Address Register. Property Name Shop Number Rapid Number (For Rural Properties) Certificate of Title – Prefix/Volume/Folio/Status/Date Parcel – Section/Plan/Level Plan Type – Deposited Plan/Community Plan, Etc. Valuer General Number Adjoining Properties Property Area Frontage GIS Reference Hundred Reference Service Numbers Conditions (Include Heritage Status) Notices Easements Certificates Catchment Area Flood Rating Unsuitable Building Land Environmental Significance Significant Trees Fire Zone Soil Type Sale Date Sale Value Transfer Date Land Use Code – (Approved, Actual, Historical) Local Government Land Use Code Land Description Zone Allotment (Section and Lot Number) Ward (Ability to Record Against Streets or Properties or Both) Property Status (Current, Proposed) Current Valuation Proposed Valuation (All Types as Provided by Valuer-General, Eg. CIV, SV, NV) Government Entity Flag Assessment Book Reference Other References



16.2 Data Collection 16.3 Rates Modelling and Generation 16.4 Notice Generation 16.5 Payments/Receipting 16.6 Fines/Interest 16.7 Arrangements/Debt Collection

16. RATES 16.1 Rates - Business Purpose


• To facilitate high quality customer service when handling customer enquiries i.e. timely processing of valuation objections, concessions and other enquiries, and providing alternative enquiry methods through the Internet.


• To fulfil all relevant legislative requirements • To complete other statutory functions i.e. Section 187 certificates.


• To provide the primary source of revenue for Council to implement strategies and deliver services to the community.

• To provide a rates debtors system, allowing Council to manage outstanding debts from rate

payers

• To assist a Council in determining and calculating the annual rate, through the use of rates modelling, assessment of rebates and levies and the actual calculation and generation of rate amounts.


The rates module has been divided into the following detailed sections:



16.2 Rates - Data Collection 16.2.1 Procedural Flow

Valuer General

Property

Customer

Private Valuer

Information

Property

Full valuation list received

Receive Updates/

Objections

SA Water

Match info based on VG #

Exception Reporting

Update Rate

Records

Other external

Input

Catchment Boards,

STEDS , etc.

Council rebates

recorded &flagged

Council rebates

database

Validate information

Full Pensioner concession list received

Match info based on VG #

NAR

Property Rate Data

Valuer General

SA Water



16.2 Data Collection Ranking Comment 16.2.2 Functionality

16.2.2.1

Able to process rates and property data separately to ensure both modules maintain the most current relevant data (Eg. Property system and rating system data may not always match due to time lags between development and Valuer-General information, and ownership information).

M

16.2.2.2

Able to electronically match data from external sources i.e. SA Water and Valuer-General, with Council property and rating databases based on a common identifier, i.e. VG Number. Able to exclude data flexibly from the matching process.

M

16.2.2.3

Able to select individual fields from the external files and electronically update Council records based on information matching but subject to validation (Eg. if vacant land, no pensioner concessions to be applied).

M

16.2.2.4 Able to identify the date when concession data was updated from external sources (and include a comment, such as Week 1, Week 2, etc.).

HI

16.2.2.5

Able to create tenancies for individual assessments. Able to attach a sequence number to the Valuer General number where there are multiple tenancies on one assessment (each sequence relating to one particular occupancy of that group).

M

16.2.2.6

Able to store multiple valuation methods (together with source) per assessment, including private and Government valuations, and include historical data. Including: • Site value, • Capital value, • Annual value, • Notional value, • Capital improved.

HI

16.2.2.7 Able to attach proposed values to an assessment with a future commencement date when value becomes active. M

16.2.2.8 Able to flag assessments as ‘non-rateable’, attach an expiry date, and include a reason code/comment. M

16.2.2.9 Able to attach a variety of Council rebates to assessments i.e. for churches, schools, etc., attach an expiry date, and include a reason code/comment.

M

16.2.2.10

Able to attach an expiry date to a Council rebate and include a comment, i.e. New business is given a rate holiday for 3 years, concession expires automatically at the end of the period.

I

16.2.2.11 Able to identify the nature of each rebate/concession update, i.e addition, amendment, etc. O

16.2.2.12

Able to update valuation amounts, Local Government Codes, concessions, etc. based on customer objections, with automatic flow through for recalculation of rates, etc.

M

16.2.2.13 Able to manually flag and record details of an objection relating to valuations, Local Government Codes, concessions, etc.

O

16.2.2.14 Able to have multiple objections per year for each ratepayer. M



16.2 Data Collection Ranking Comment

16.2.2.15 Able to spread the financial impact of any financial adjustments over any combination of instalment periods. M

16.2.2.16 Able to differentiate between objections and general rating changes (journals) and include comment fields. HI

16.2.2.17 Able to add or delete ratepayers without going through a change of ownership process. M

16.2.2.18 Able to record beneficiaries for rebates and concessions. M

16.2.2.19 Able to accept multiple rebate groups and assign a rebate type to each group. I

16.2.2.20 Able to assign rebate limits as a percentile or dollar amount. M

16.2.2.21 Able to assign variable rebate percentages over time (Eg. 50% for first year, 40% for second year, 30% for third year, etc.).

M

16.2.2.22 Able to reverse financial transactions without having to reverse rebate transactions. I

16.2.2.23 Able to suspend rate types using expiry dates. I

16.2.2.24 Able to record a tracking codes (activity) against assessments (Eg. debt collection phase, etc.). HI

16.2.2.25

Able to perform bulk maintenance: • Update rebates, • Rate types, • Local Government Codes, • Tracking codes, • Etc.

HI

16.2.2.26 Able to copy current rating information onto proposed assessments. HI

16.2.2.27 Able to copy property owners as ratepayers. HI 16.2.3 Data Access/Reporting

16.2.3.1

Able to generate ad hoc queries on any combination of key data fields without the need for specific systems knowledge (Eg. Report on/extract individuals who receive pensioner, council or rebates/concessions at all levels by group or type, etc.).

M

16.2.3.2 Able to print the results of any ad hoc queries to screen or paper. Also able to export to MS-Excel or ASCII text for use in other products.

M

16.2.3.3 Able to store and retrieve frequently used queries with the ability to include an appropriate description of the query.

I

16.2.3.4

Sets of standard reports are available for regular use. (Eg. Summary reports verifying successful import of data from external sources such as SA water and Valuer General), reports detailing all unmatched records, report on duplicate concessions, i.e. Pensioner and fays, objections report - nature of objections, etc.).

M

16.2.3.5 Able to write new reports or modify existing reports without the need for specific systems knowledge. HI

16.2.3.6 Able to maintain reporting flexibility on historic data for comparison with current year, trend analysis, predictive modelling.

HI

16.2.4 Interfacing/Integration 16.2.4.1 Able to interface Property information. M 16.2.4.2 Able to interface Name and Address Register M



16.2 Data Collection Ranking Comment

16.2.4.3

Able to import data files from external sources i.e. SA Water and Valuer-General, private valuer, in real-time, without significantly impacting performance or locking records.

M

16.2.4.4 Able to reverse import file data prior to reaching a point of electronic signoff for finalisation. M

16.2.4.5 Able to link with GIS. HI

16.2.4.6 Able to link to the Internet for provision of rating information, transaction processing, online rating generation/reversals for objections, etc.

O

16.2.5 Audit Requirements

16.2.5.1 Able to produce an audit trail of additions, modifications and deletions to selected fields and system parameters and track to a user/date/time.

M

16.2.5.2 Sets of standard exception reports are available for regular use. HI

16.2.5.3 Able to produce specific exception reports on adjustments to key data. M

16.2.5.4 Able to provide alerts triggered from particular audit trail events. HI

16.2.6 Data content Billing Reference Number VG Number Pensioner Flag Rebate Flag Rebate % Rebate Type Beneficiary/Beneficiaries for Rebates Non-Rateable Flag FAYS Benefit Flag (Updated via Receipting) Assessment Number Concession/Rebate Amount Concession/Rebate % Objectioner (Person Making an Objection) Objection Flag and identifier (i.e. objection lodged and Rate Type Local Government Code Billing Status Valuation Rates Paid % Or $ Increase Over Last Year History Changes In Rebate Instalment Date Number Of Instalments Instalment Due Date Discount (%) Rate Type Date



16.3 Rates Modelling and Generation 16.3.1 Procedural Flow

Complete Property

Rate Data

Summary (short-cut) Rate Data

Goal seek/ legislative

requirements

Balance valuation

totals with VGData

Prior Years Data

Rate calculation

Adjust key rating

variables

Final Rate amounts agreed

Property Rate Data

Valuer General Report

Desired rate resultachieved

?

No

Yes

Rate calculation/Generation

Data Testing/Validation

Exception Reporting

Update live rate

data

Agree to rate modelling

total

Prior YearRate

Arrears

See Notice Generation

Rate categories

& types

Rebates & remission



16.3 Rates Modelling and Generation Ranking Comment 16.3.2 Functionality

16.3.2.1

Able to model on full database or a selection of records/query result. (Able to handle full year generation and individual billing generation as requested). M

16.3.2.2 Able to determine which assessments do not have specific rate types. M

16.3.2.3 Able to store rate model reports electronically so can compare figures year to year. O

16.3.2.4 Able to represent rebates as a percentage of rate amount. I

16.3.2.5 Able to display rates due for a given day, i.e. able to key in a date. I

16.3.2.6 Able to display arrears by year (Eg. 2000 arrears include 1997,98 and 1999 arrears). M

16.3.2.7 Able to link/compare model data with the related final rates generation data (in summary and detail). HI

16.3.2.8 Able to run a “quick test” model on summarised information providing an accurate result (within reason). M

16.3.2.9

Able to model rates for all combinations of rate types, i.e. general rates, fixed rates, separate rates, etc. Provides summary information on various rating components.

M

16.3.2.10 Able to model rates by setting a range for each rate type variable, i.e maximum increase from prior year. HI

16.3.2.11 Able to model rates by setting total rate target and using goal seek functionality. Target is reached through manipulation of variables within predetermined ranges.

HI

16.3.2.12 Able to run multiple rates models simultaneously. M 16.3.2.13 Able to add rounding during modelling and generation. M

16.3.2.14 Able to calculate Council rebates based on legislated percentage rules and STEDS provisions, with provisions for a fixed rebate amount, and include a comment.

M

16.3.2.15 Able to calculate the impact of rebates and rate concessions by type. M

16.3.2.16 Able to handle unlimited number of instalments in rates generation. I

16.3.2.17 Able to attach multiple ratepayers to assessments. M 16.3.2.18 Able to accept multiple rate types (per assessment). M

16.3.2.19 Able to have proposed assessments, operational from date of activation. HI

16.3.2.20 Able to accept ex gratia and postponed rates. M

16.3.2.21 Able to calculate rates using a variety of methods, i.e rate in the dollar, per unit, fixed rate, tiered rate, etc. M

16.3.2.22 Able to calculate and process rate discounts. M

16.3.2.23 Able to apply SA Water remission provisions to Council STEDS charges in rebates. M

16.3.2.24 Rebate provisions need to recognise Local Government Code. M

16.3.2.25 Able to set minimum (and maximum) rates by rate type. M

16.3.2.26 Able to apply maximums and minimums to adjoining/contiguous properties in line with legislation. M



16.3 Rates Modelling and Generation Ranking Comment

16.3.2.27

Able to provide an analysis of ratepayers affected by tiered rating and ensure compliance with legislative requirements (Eg. 65% of rates must be calculated using Rates in the Dollar method).

I

16.3.2.28 Able to undo rates calculations before electronically signing them off as final. M

16.3.2.29 Able to maintain history of rating data for a discretionary number of years. M

16.3.2.30 Instalments, amounts and dates should be maintainable per assessment. HI

16.3.2.31 Able to regenerate rate amounts for individuals for changes in valuation details resulting from objections. M

16.3.2.32 Able to specify due date(s) for payment(s). M

16.3.2.33 Able to link all outstanding balances to a parent assessment, i.e. for reporting on Section 187 Certificates.

HI

16.3.3 Data Access/Reporting

16.3.3.1 Able to generate ad hoc queries on any combination of key data fields without the need for specific systems knowledge.

M


M


I

16.3.3.4

Sets of standard reports are available for regular use. Reporting based on data groups: • Ward, • Local Government code, • Charge type, • Street name, • Etc. • Report on revenue lost - including rates foregone

as a result of non-rateable properties and rebates, • Report on rebates, rebate types and concessions.

M


16.3.3.6 Able to maintain reporting flexibility on historic data for comparison with current year, trend analysis, predictive modelling, etc.

HI

16.3.4 Interfacing/Integration

16.3.4.1 Able to link with all other land and property based modules (NAR, property, applications, etc.). M

16.3.4.2 Able to automatically update valuation amounts and rates from electronic objections. M

16.3.4.3 Able to calculate rate concessions for pensioners based on percentage in SA Water file. M

16.3.4.4 Able to link with GIS for spatial data representation, bulk maintenance updates, etc. M

16.3.4.5 Link to Document Management System for tracking of ratepayer related correspondence. M

16.3.4.6 Customers able to access specific rating related data via the Internet i.e. valuation information, rebate information, etc.

HI

16.3.4.7 Able to link with e-mail for rates related correspondence. M



16.3 Rates Modelling and Generation Ranking Comment

16.3.4.8 Able to link with a customer service system so that action resulting from customer complaints, etc. may be tracked and communicated through to resolution.

M

16.3.4.9 Able to link to Word (mail merge) for generation of rate payer related correspondence. M

16.3.4.10 Able to integrate with cash receipting, receivables and general ledger for managing customer payments. M

16.3.4.11 Able to hyperlink to appropriate legislation for reference. I 16.3.5 Audit Requirements


M




16.3.6 Data content Model Date Model Version Current Rate Value Objection Flag Rateable Flag Rate Amount Rebate % Rebate Amount



16.4 Notice Generation 16.4.1 Procedural Flow

Current YearRate

Generation

See Fines & Interest Charges

Has notice generation

been overridden?

Is amount less than minimum

notice amount?

Generate notice file

Prepare notice

template

Generateelectronic

notice

Internet Request reprint/

Statement

Rate Payer

Report onand Edit Printer

Rate Payer

No notice generated

Exception Report/ reasons

Exception Report/ reasons Yes

No

Yes

No

ReminderNotice

Warning

Instalment Notice

Fine/interestNotice

See Debt Collection



16.4 Notice Generation Ranking Comment 16.4.2 Functionality 16.4.2.1 Able to generate a rate notice for each assessment. M

16.4.2.2 Able to consolidate notices for properties under common ownership or management (Eg. Brock Partners, Housing Trust) and for contiguous/adjoining properties.

M

16.4.2.3 Able to generate rates notice by notice group (owner, principal ratepayer, agent, etc.). M

16.4.2.4 Able to nominate whether the generated notice is consolidated or detailed. M

16.4.2.5 Able to override notice generation for individual properties and for property groups. M

16.4.2.6 Able to set a notice generation minimum for both rates and fines, i.e. Do not want to generate a charge if less than $x; do not generate a notice if less than $x, etc.

M

16.4.2.7 Able to reprint a rates invoice on request (form and content identical to original notice) while users are still on the system.

M

16.4.2.8

Able to generate and print rate payer statements on request showing transaction details: Original rate amount, Rebates, Adjustments, Charges, Payments received, Current outstanding balance, Etc.

M

16.4.2.9 Able to automatically generate reminder notices based on elapsed time i.e. reminder notice after 28 days, final notice after 38 days.

M

16.4.2.10 Able to handle an unlimited number of instalments. M 16.4.2.11 Able to produce bulk notices/schedule/files. M 16.4.3 Data Access/Reporting


M


M


I

16.4.3.4

Sets of standard reports are available for regular use, such as: • Print statements of amounts owing, • Send out fines notices when payments under

arrangements are due, • Etc.

M



HI

16.4.3.7 Able to inquire and report on the extract file sent to printers and bulk owners. HI




16.4 Notice Generation Ranking Comment

16.4.4.1 Able to link with all other Land and Property system modules. M

16.4.4.2 Able to export selected notice information to a file for sending to a printing company or bulk owners i.e. Housing Trust, etc.

M



16.4.4.5 Customers able to access specific rating related data via the Internet i.e. ability for account customers to request, view and print rate notices via the Internet.

HI

16.4.4.6 Able to link with e-mail for rates related correspondence i.e able to send rate notices and reminders via e-mail. M


M





M




2.4.6 Data content Notice Number Minimum Amount Notice Generation Date Reminder Date Notice Group



16.5 Payments and Receipting 16.5.1 Procedural Flow

Internet Agencies CouncilReceipt

Match file

to Council

Exception

Report

General Ledger

Update

customerbalance

Validate

Information

Receipting

file

Edit data

Allocation rules

General Ledger

Extract

over paid

accounts

Discount Calculated

FAYS/ Housin

g Trust

Customertransactio

n detail &

System warning

messages

Transfer to

other modules

Balance prepaid

Refund

due Other

Module

Unmatched

item to holding a/c

CouncilBulk

Receipt

Rate agent

file

Allocate

Payments

Edit data



16.5 Payments/Receipting Ranking Comment 16.5.2 Functionality

16.5.2.1 Able to accept a flexible payment allocation sequence (Eg. payment to be taken in order of: legal fees, interest, fines, and rates in the order they fell due).

M

16.5.2.2

Able to process bulk receipts (Eg. agents, Housing Trust, etc.) – able to generate, validate, edit, balance, transfer, and reject in bulk and able to generate a summary receipt (with optional display instead of print).

M

16.5.2.3 Able to display/print outstanding balances per assessment. O

16.5.2.4 Able to reprint receipts on demand. HI

16.5.2.5 Able to accept payment in full and instalments i.e. quarterly. Able to specify full or instalment payment as receipt default and override if necessary.

M

16.5.2.6

Able to accept prepayments (prepayment flag is available to clear/reset once a payment has been apportioned to debits – avoids processing a refund cheque in error) and overpayments.

O

16.5.2.7

Able to provide cashier warning codes/alerts/blocks (Eg. able to block cashiers from receipting payments to an historic property, warnings for over and under payment, etc.) and ability to override alerts.

M

16.5.2.8 Able to determine the source of payments (Eg. counter, online, B-Pay, Commonwealth Bank, Australia Post, etc.).

M

16.5.2.9 Able to suspend receipts. HI

16.5.2.10 Able to transfer money between accounts for different modules (Eg. transfer overpayment in rates to pay dog registration).

M

16.5.2.11 Able to reverse receipts (current and previous periods). M

16.5.2.12 Able to transfer receipts between current and previous periods. I

16.5.2.13 Able to link bank BSB Numbers with bank names/branch to save time when entering cheque details.

I

16.5.2.14 Able to print drawer’s name on receipts and ability to override. O

16.5.2.15 Able to default ratepayer’s name as drawer of the cheque and override if necessary. M

16.5.2.16 Able to track transactions by Cashier Drawer Number. HI

16.5.2.17 Able to include discounts and apportion receipts at any time. M

16.5.2.18 Able to receipt multiple occurrences of any type of payment on one receipt. M

16.5.2.19 Able to accept payment for one receipt by multiple types (Eg. part cash, part cheque). HI

16.5.2.20 Able to automatically write off a balance under a predefined threshold. HI

16.5.2.21 Able to process barcodes/MICR/OCR. HI

16.5.2.22 Able to restrict the maximum refund to equal the total cash received. HI

16.5.2.23 Able to distinguish between receipts generated from any payment method (Eg. cash, cheque, EFTPOS, bank, etc.).

M



16.5 Payments/Receipting Ranking Comment

16.5.2.24 Able to handle offline payments, so that if the system is down, a transaction may still be entered. M


16.5.3.1 Able to generate ad hoc queries on any combination of key data fields without the need for specific systems knowledge i.e. On drawer of cheques, etc.

M


M


I

16.5.3.4

Sets of standard reports are available for regular use, such as: • Report on cashier drawer balances, • Collating all drawer balances into a single report, • Report on credit balances, • Etc.

M



HI



16.5.4.2 Able to transfer all or part of receipts between any module (especially a current receipt that has been brought forward for the current year).

M

16.5.4.3 Able to link to rate enquiry during receipt processing. M


16.5.4.5 Flexibility to handle transactions generated from any payment method (Eg. cash, cheque, EFTPOS, internet payment, bank, etc.).

M



16.5.4.8 Customers able to access specific rating related data via the Internet i.e. ability for account customers to pay rates via the Internet.

HI

16.5.4.9 Able to link with e-mail for rates related correspondence i.e documentation regarding payment terms and payment arrangements.

M


M




M



16.5 Payments/Receipting Ranking Comment




16.5.6 Data content Ex Gratia Payment Flag Receipt Number Drawer ABN BSB/Account Number Bank Payment Type (Cheque/Money Order/Credit Card, Etc.) Credit Card Details Amount (For Each Payment Type/Occurrence) GST Incl/Excl Total of Receipt



16.6 Fines/Interest 16.6.1 Procedural Flow

Prior Year Rate

Arrears

Current Year over dues

Balance overdue

Overdue Rates

Interest

OtherIs amount less than minimum

fine?

Is amount less than minimum interest?

No fine

generated

Fine

Generated

Balance

1 month + overdue

Current Year

Interest Generated

No interest generated

Update Rates

Balance

Update Rates

Balance

Fine

Calculation

Interest

Calculation

Manual

fine override

Manual interest override

Exception

Report

Exception

Report

Year end roll over

Yes

Yes

No

No

See Notice Generation

See Debt Collection



16.6 Fines/Interest Ranking Comment 16.6.2 Functionality 16.6.2.1 Able to generate fines and interest on overdue balances. M

16.6.2.2 Able to set preconditions for fine and interest generation (Eg. payment not received by due date). M

16.6.2.3 Able to calculate fines using predefined rules (Eg. based on fixed amount, percentage, minimum/maximum parameters, etc.).

M

16.6.2.4

Able to calculate interest using predefined rules (Eg. percentage, simple or compound interest, balance types, ensuring fines and legal fees, etc. do not attract interest, etc.).

M

16.6.2.5 Able to generate a fine notice for overdue payments on demand. M

16.6.2.6 Able to reverse fines/interest. M 16.6.2.7 Able to ascertain amounts outstanding in real time. M 16.6.2.8 Able to display fines, interest and legal fees separately. M

16.6.2.9 Allows override of fine/interest or both with reasoning and date/time stamp. M

16.6.2.10 Able to select a specific rate type for the fine (Eg. general rate, fixed rate, separate rate, etc.) M

16.6.2.11 Able to set a minimum amount at fine notice generation i.e. Do not want to generate a charge if less than $x; do not generate a notice if less than $x, etc.

HI

16.6.2.12 Able to fine and raise interest on payment arrangements outside quarterly instalments. O

16.6.2.13 Able to rollover rates, fines and interest separately into the next year. M

16.6.2.14 Able to display accurate historical transactions for outstanding balances. Need ability to access debt history over many years with a cumulative total.

M



M


M


I

16.6.3.4 Sets of standard reports are available for regular use. (Eg. fines and interest report, arrears report, etc.). M



HI



16.6.4.2 Able to display apportionment of payments (Eg. current instalment, previous arrears, last month’s arrears, etc.). M




16.6 Fines/Interest Ranking Comment


16.6.4.5 Link to Document Management System for tracking of rate payer/fines related correspondence. M

16.6.4.6 Customers able to access specific rating related data via the Internet i.e. ability assess total amount payable, including fines and interest for any point in time.

HI

16.6.4.7 Able to link with e-mail for rates related correspondence i.e documentation regarding payment terms and payment arrangements.

M


M




M




16.6.6 Data content Fine Date Interest Date Fine Amount Interest Amount Total Fine Amount Payment Due Date Comment (Eg. Reasons For Payment Grace Period, Etc.) Payment Source Minimum Amount



16.7 Arrangements and Debt Collection 16.7.1 Procedural Flow

WorkflowDebt Collector

See Fines & Interest Charges

Current overdueBalance

referred to debt collector

Customer

data

Intentionletter

sent to customer

Payment

arrangement

Debt collectionflag checked on rate payer

Memo

attached to file

Receipting suspended Chp 10 only

Section 7

Courts

Court costs

attached

Payment via debt collectoror direct by Ratepayer

Rate balanceupdated

Allocation

rules

Extract of new overdue assessments

without payment arrangements

Arrange -ment

Defaulted

Rate Payer

Rate Payer

Yes

No



16.7 Arrangements and Debt Collection Ranking Comment 16.7.2 Functionality

16.7.2.1 Able to establish payment arrangements – alternative arrangements to instalments. M

16.7.2.2 Able to set up a schedule of when payments are due and the amount of each scheduled payment for an arrangement.

HI

16.7.2.3

Able to use flexible workflow procedures to manage the debt collection processes (Eg. Able to alert when payments under arrangements are due, generate reminder notices, etc.).

HI

16.7.2.4 Able to block payments to properties under Chapter 10 proceedings (with override facility). M

16.7.2.5 Able to specify an appropriate action to be taken if payment is not made by a specified date (Eg. initiate debt collection process, sale of property process, etc.).

O



M


M


I

16.7.3.4 Sets of standard reports are available for regular use. (Eg.Debt collection and payment arrangement history via activity).

M



HI





16.7.4.4 Able to link to Document Management System for tracking of rate payer/fines/debt collection correspondence.

M

16.7.4.5 Customers able to access specific rating related data via the Internet i.e. able to make payments over the Internet.

HI

16.7.4.6 Able to link with e-mail for rates related correspondence i.e customer reminders for payment, correspondence with debt collector and court.

M


M


16.7.4.9 Able to hyperlink to appropriate legislation for reference. I



16.7 Arrangements and Debt Collection Ranking Comment 16.7.5 Audit Requirements


M




16.7.6 Data content Minimum Amount



17. Infringements

18. Animal Control

LAND AND PROPERTY INFORMATION SYSTEM FUNCTIONAL REQUIREMENTS REGULATORY MODULE The Regulatory subject group contains the functional requirements for the following detailed areas/modules:



17. INFRINGEMENTS 17.1 INFRINGEMENTS - Business Purpose


• To enforce compliance with Councils regulatory requirements, formulated to protect community residents and the environment.



• To provide efficient administration for enforcing Councils regulatory requirements i.e. ticket issuing at point of presence, electronic payments, on-line tracking etc.

• To provide a means of revenue generation for Council


• Potential for outsourcing of infringement services. Council information requirements would need to be meet in order to effectively manage the contract performance.



17.2 Procedural Flow – Infringements

Reminder notice

generated

Offender exempt?

Yes

No

Ticket issued

Ticket book allocated

Hand held unit

Property

Data input/ down loaded

Offence Type

Registration number

Locations

No ticket processed

Extract file tickets O/S > 28 Days

Motor vehicle fine?

Dept of MV’s

Cash receipting

Customer payment Fine paid

in 28 days?

Yes

No

Yes

No

Property

Name &

Address File

Fine calculated

Reminder notice fee

added

Fine paid in x days?

No

Cash receipting

Customer payment

Yes

Cert of Enforcement

Issued Court

Debt written off

Cash received

Court Write off

Court reinstates

fine

Update Council data

Customer

Customer

Auto email

MV search fee added

Final notice

generated

Final notice fee

added

First time thru process?

No

Yes

Fine paid in x days?

No

Cash receipting

Customer payment

Yes

New workflow process attached



17.2.1 Procedural Flow – Infringement Appeal

Waivefine?

Yes

No

Telephone Council MailInternet

Require objection in

writing

Objectionletter

received

Customer Relations

Records Mnmt

Customer

Review bySenior

Inspector

Fine written off

Customer

Letter to customer

Customer Relations

Letter to customer

Customer

Customer Relations

Responsein < xdays

Yes

No Cert of enforcement

issued

See Infringements

Customerletter

Records Mnmt

Customer Relations

Customer

Elect to prosecute

Yes

No Fine payment/ Cert of

enforcement

Customer

Court Proceedings Customer

Relations

Statutory Declaration Infringe-

ments

Infringe- ments

Infringe- ments



17.2.2 Procedural Flow – Abandoned Vehicles

Is car stolen?

Yes

No

AttachNotice

Police

Customer request

Customer

Sited byCouncil

Inspector Scheduled

Customer relations

Confirm abandoned (chalk tires)

Police notify owner

Customer relations

Car Towed

Car moved/claimed

Yes

No

No furtheraction

Dept of MV’s

Name &Address

File

Reg plateson car?

Yes

Letter sent toowner

+ve Owner response

No

No

Fee calculated

Yes

Fee Paid &

car collectedCash

Receipting

Car Advertised

Car sold/ disposed of

Customer relations

Photo taken & attached to record

Record created

& status

attached

Infringe- ments



17. Infringements Ranking Comment 17.3 Functionality

17.3.1

Able to select, configure and process a variety of infringements types: • Parking, • Animals (Eg. dogs), • Health, • Environment Protection Authority (EPA), • Council By-Laws, • Etc.

M

17.3.2

Able to allocate manual ticket books to officers without first needing to flag them as ‘received’, and able to prevent tickets from unallocated books from being processed.

O

17.3.3 Able to automatically allocate ticket numbers to officers based on book allocation. O

17.3.4 Able to accept prepayment prior to an infringement being entered. M

17.3.5 Able to accept use of manual tickets or electronic tickets (Eg. Via Autocite terminals). M

17.3.6

Able to select offence type via a configurable drop-down list: • Unregistered animals, • Animal wandering at large, • Animal in school premises, • Animal attack, • Etc.

M

17.3.7

Able to use flexible workflow procedures to manage the infringement process, i.e. able to attach standard workflow tasks based on infringement type, management of the appeals process, impounding of vehicles, etc.

HI


17.3.9 Able to track infringement status (Eg. from ticket issued through to payment/Certificate of Enforcement issued). M

17.3.10 Able to link infringements to a vehicle/animal registration/property/owner and record history of infringements and resolutions.

M

17.3.11

Able to attach a ‘next action date’ to each step in the infringement/payment process (with ability to override this), triggering an action at each step (Eg. generate a reminder notice on 31/12/2000).

M

17.3.12 Able to override ‘next action’/due dates. M

17.3.13

Able to assign different fees to an infringement depending upon the nature of the offence and pre-determined criteria (Eg. animal attack: $200 versus unregistered animal: $75).

M

17.3.14 Able to waive infringements/fees at any time after an infringement has been generated, with comment. M

17.3.15 Able to defer payment with comment. M

17.3.16 Able to attach multiple payment due dates, each triggering specific actions (Eg. if payment not received by due date, automatically add late fee of $x).

O



17. Infringements Ranking Comment

17.3.17 Able to specify payment due date as a number of days, and able to automatically calculate payment expiry date based on number of days entered.

M

17.3.18 Able to generate an infringement notice. M

17.3.19 Able to reinstate infringements after they have been written off. M

17.3.20 Able to flag infringements that has previously been reinstated through the Court process and assigns different workflows accordingly.

HI

17.3.21

For parking infringements, able to specify a parking zone ‘type’ such as: • Residential, • Temporary, • No Standing, • 15 minute, 30 minute, 45 minute, • 1 hour, 2 hours, 3 hours, etc.

M

17.3.22 For parking infringements, able to assign an area.

17.3.23 For parking infringements, able to name the driver of the vehicle (as well as owner of the vehicle). M

17.3.24 For parking infringements, able to add comments about the owner/driver (Eg. dangerous). O

17.3.25

For parking infringements, able to identify exemptions based on: • Location of vehicle (parking zone) and vehicle

owner, based on property data (Eg. For permit parking, such as residential parking, or permits allowing the vehicle owner to overstay parking zone time limit, etc); and

• Vehicle (Eg. council cars, emergency vehicles, etc).

I

17.3.26 Able to accept a flexible fee structure for residential parking permits and exemptions. I

17.3.27

For parking infringements, able to enter Sign Numbers optionally. All relevant details attached to the parking zone can be automatically populated upon entering a Sign Number.

I

17.3.28

For temporary parking zones, able to enter specific Registration Numbers for exemption (Eg. for vehicles that were in the street when the temporary zone was erected).

O

17.3.29 For temporary parking zones, able to attach traffic impact statements and authority. I

17.3.30 Able to track tasks associated with removal of an abandoned vehicle. HI

17.3.31

Able to record the status of abandoned vehicles as: • Impounded, • Returned to owner, • Lost, • Sold, • Destroyed, • Etc.

HI

17.3.32 Able to automatically generate and send a letter to the owner after an abandoned vehicle has been impounded.

HI

17.3.33 Able to generate infringements for abandoned vehicles. I 17.3.34 Able to record orders against animal type and detail. HI




17.3.35 Able to exempt animals from animal related infringements. (Eg. Guide dogs, working dogs, etc). M


17.4.1

Able to generate ad hoc queries on any combination of key data fields without the need for specific systems knowledge (Eg. query total dog related infringements within a particular area, total infringements issued for a particular property, etc).

M


M


I

17.4.4

A set of standard reports are available for regular use, Eg: • Infringement statistics for management reporting, • Infringement write off reports, • Total infringement notices issued by officer.

M


17.4.6

Able to maintain reporting flexibility on historic data for comparison with current year, trend analysis, predictive modelling (Eg. identification of infringement hot spots, growth/decline by type and area, etc).

HI


17.5.1 Able to integrate with Property module to attach infringements to property owners/occupier. M

17.5.2 Able to integrate with NAR module to access infringement related name and address information. M

17.5.3 Able to integrate with Inspections module to schedule inspections based on customer queries. HI

17.5.4 Able to provide an indication/hyperlink when another module is affected, or a task in another module is required.

HI

17.5.5 Able to import data from external bodies (Eg. Department of Motor Vehicles and Courts Administration Authority).

M

17.5.6 Able to export data to external bodies (Eg. export list of Registration Numbers for infringements where payment is overdue).

M

17.5.7

Able to link with Department of Motor Vehicles extract file to import names and addresses attached to Registration Numbers to identify infringements where payment is outstanding.

M

17.5.8 Able to limit repetitive Department of Motor Vehicles searches. O

17.5.9

Able to accept payment via a variety of methods: • Cash, • Credit card, • Money order, • B-Pay, • Post Office, • Internet, • Etc.

M





17.5.11 Able to link with a GIS for spatial representation of parking zones, etc. HI

17.5.12

Customers able to access specific infringement related data via the Internet i.e. Fine details, Amounts, Due dates, Arrears, Parking permit applications, Payment of parking infringements, Etc.

HI

17.5.13 Able to link with e-mail for infringement related correspondence. M

17.5.14

Able to link with Asset Management/Work Order Management system and generate work requests for specific tasks (Eg. erection of a temporary parking zone automatically generates a work request for the depot).

I

17.5.15 Able to link with a customer service system so that action resulting from customer complaints, etc. may be tracked and communicated through to resolution.

M

17.5.16

Link to Word (mail merge) for generation of infringement related correspondence (Eg. reminder notices for payment of parking infringements, renewal of parking permits, etc).

M

17.5.17 Link to Document Management System for tracking of infringement related correspondence. M

17.5.18 Able to integrate with cash receipting, receivables and general ledger for managing customer payments. M

17.5.19 Able to hyperlink to appropriate legislation for reference. I

17.5.20 Able to interface with handheld ticketing systems (Eg. Autocite) using wireless technology over the Internet or private data network.

M



M

17.6.2 A set of standard exception reports are available for regular use (Eg. fine write-off/override, adjustments to standard fines, extension of payment terms, etc).

HI





17.7 Data content Infringement # Infringement Type Issuing Officer Date of Offence Time of Offence Zone Area ID Area Name Ticket on Vehicle Flag (Y/N) Registration Number Plate Type License Number Registration Label Number Registration Expiry Date Registration State (I.E. SA, Vic, NSW, Etc). VIN Number Vehicle Make Vehicle Type Vehicle Colour Distinguishing Features Engine Number Exempt Details/Flag Infringement Status

(Eg. AL = Allocated (Ticket Allocated to Inspector) IS = Ticket Issued - 28 Days to Pay. FE = DMV Search Completed. FF = First and Final Notice (Issued After 14 Days) LE = Legal Extract (Remains for 1 Day – Then Writes all Tickets Off After 1 Day and Moves Monies Into Legal Account) CO = Completed AP = Appeal, Etc).

Ticket Issue Date Temporary Parking Control Number Street (Where Infringement Issued) Suburb (Where Infringement Issued) Cross Street (Nearest Point to Parking Control, Infringement Issued) Near (Information on A Nearby Landmark) Timeframe in Force (Temporary Parking Control) Abandoned Vehicle Flag Comments Fine Amount Sign/Metre Number Owner/Offender Name Driver Name Next Action Date Court Hearing Date Summons Raised Date Comment (Eg. Warning For Dangerous Driver).



18. ANIMAL CONTROL 18.1 ANIMAL CONTROL - Business Purpose


• To ensure a high quality customer focused service is provided to the community, i.e. acting on a timely basis, providing alternative complaint registration and tracking through the Internet.

• To control the animal population within Council i.e. enforcement of maximum animals per

property.

• To promote animal welfare within the community

• To protect residents against animal attacks and disturbances Legislative Requirement

• To fulfil all relevant legislative requirements under the Dog and Cat Management Act Internal/Council Management

• To maintain accurate information on animals registered within the Council area, allowing easy access to location, breed, sex, history etc.

• To provide a management and administration with a tool for decision making related to animal

policy. • To promote compatibility between animal owners and non animal owners

• To assist with the management of risk related to animal attacks


• Potential for outsourcing of animal control services. Council information requirements would need to be meet in order to effectively manage the contract performance.



18.2 Procedural Flow – Animal Control

Exceeds max # of animals

Yes

No

Applicationform for

new animal

Internet

Enter applicantdetails

Customer

Property

Warning - Permit

required

Fee calculated Fee type/

class

Licensing

PaymentreceivedCash

Receipting

Disk/chipnumber

allocated

Unregistered animal report

Inspectors

Reminder notice

sent for nextyears fee

Update/

changedetails

Internet

Impounding

NAR



18.2.1 Procedural Flow – Animal Control - Impounding

Animal Registered

Yes No

Contact owner

Animal Control

Animal impoundedby Council

Customer

Customer

Input animal details

Calculate impounding

fee

Animal collected

Yes

No

Impounding fee paid Cash

receipting

Animal released

See Infringements

Disposalof animal

Input animal description &pound details

Photographanimal

Animal claimed

Yes No

See AnimalControl

Fine for noregistration

Animal to be registered

Disposal of animal

after 3 days

Customerreports animal

Customer relations

Council sighting



18. Animal Control Ranking Comment 18.3 Functionality 18.3.1 Able to enter animal types (Eg. dog, cat, horse, etc). M

18.3.2

Able to enter animal details, including: • Breed (including cross breeds and breed codes), • Colour, • Sex, • Etc.

M

18.3.3 Able to enter animal ‘tattoo’ (electronic identification) number, which can automatically enter animal details if available.

HI

18.3.4 Able to use flexible workflow procedures to manage the animal control process, i.e. animal registration and impounding.

HI

18.3.5 Able to add, delete or change the order of workflow tasks depending on individual circumstance. M

18.3.6 Able to adopt a different fee structure based on animal ‘class’. (Eg. desexed, normal, under 3 months old, etc). M

18.3.7 Able to pro rata or allocate fee where registration period is less than 12 months. (Eg. new dog registered in January, fee is 50% of annual amount)

M

18.3.8

At the time of animal registration, system able to optionally check that the property owner is not exceeding the number of permitted animals, (Eg. no more than two dogs on a property).

HI

18.3.9

Able to maintain historical animal registration details against owners and properties (Eg. so animals registered in the previous year but not in the current year can be identified, etc).

M

18.3.10 Able to maintain a history of animal ownership by owner/property and therefore be able to link an animal to any previous owners/properties.

M

18.3.11 Able to track history of animal related matters (Eg. history of animal attacks, wandering at large, etc). M

18.3.12 Able to calculate refunds upon entering an animal death date. I

18.3.13 Able to automatically generate animal registration renewal forms when required and address to animal owners.

M

18.3.14 Able to link impounding of animals to individual animal registrations and record history of impounding (including specific pound) against individual animals.

M

18.3.15 Able to link animals too specific pounds and kennels. I 18.3.16 Able to calculate an impounding fees. M

18.3.17 Able to process animal releases (Eg. if animal ownership being surrendered to the Council). I

18.3.18 Able to accept registrations having zero fee (Eg. Guide dogs). M

18.3.19 Able to rollover animal details from one year to the next without the need for re-entering. M

18.3.20 Able to identify guard dogs, their location, and ‘from’ and ‘to’ dates at each location. O

18.3.21 Able to record and access additional information for an animal (Eg. special medication, allergies, etc). O

18.3.22 Able to add comments about the animal (Eg. dangerous dog, etc). O



18. Animal Control Ranking Comment 18.4 Data Access/Reporting

18.4.1

Able to generate ad hoc queries on any combination of key data fields without the need for specific systems knowledge such as: • Total number of registered dogs by area, • Complaints by type and area, • Total dogs currently in the pound, • Etc.

M


M


I

18.4.4

Sets of standard reports are available for regular use. Eg: • Registration statistics for management reporting, • Unregistered dog listing, • Animal complaints report.

M


18.4.6 Able to maintain reporting flexibility on historic data for comparison with current year, trend analysis, predictive modelling (Eg. growth in animal registration by area).

HI


18.5.1

Links with Property module to attach animal related information to a property, including current and historical data. Able to maintain flexibility when linking animals to a property i.e. link multiple animals to a single property, one animal to multiple properties, etc.

M

18.5.2 Links with Licensing module (Eg. to generate annual kennel license renewals, permits for extra dogs, etc). M

18.5.3 Links with Inspections module for follow up of customer requests and identification of likely unregistered animals, flagging for new inspections, etc.

M

18.5.4 Able to provide an indication/hyperlink when another module holds relevant information or a task in another module is required.

M

18.5.5 Able to link with electronic animal identification system (Eg. using animal ‘tattoos’ to uniquely identify the animal).

HI

18.5.6 Able to link directly to legislative database (Eg. S11 for barking animals – can advise people of their rights with respect to barking animals).

I

18.5.7 Able to link details of impounded animals with animal pounds and sanctuaries. I


18.5.9 Customers able to access specific animal related data via the Internet i.e. animal details, fines, arrears etc. I

18.5.10 Customers able to re-register animals via the Internet. HI

18.5.11 Able to link with e-mail for animal related correspondence. M



18. Animal Control Ranking Comment

18.5.12

Link to Word (mail merge) for generation of animal related correspondence, such as: • Animal registration/ renewal notices, • Impounding notification letters to animal owners, • Reminder notices for animal registration

renewals, • Etc.

M

18.5.13 Able to link with a Document Management System for generation of animal related correspondence. M

18.5.14 Able to link with a customer service system so that action resulting from customer complaints, etc may be tracked and communicated through to resolution.

M

18.5.15 Links with cash receipting and general ledger for payment of registration, fines, fees, etc. M

18.5.16 Able to generate animal tags. O

18.5.17 Able to hyperlink to appropriate legislation for reference.

I



M

18.6.2 A set of standard exception reports are available for regular use (Eg. more than 2 dogs per property without a permit).

HI





18.7 Data content Animal Reference Number Animal Disc Number Animal Disc Year/Colour Receipt Number Animal Tattoo Number Registration Start Date Registration Expiry Date Animal Name Breed (Including Cross Breeds) Sex Class (Eg. Normal, Desexed, Etc) Coat (Eg. Short, Etc) Collar Ears Tail Colour Markings Dob Age Location Area Id Area Name Date Of Last Site Visit Animal Status Flag: N=Normal, O=Out Of Area Exempt Flag Deceased Flag Date Of Death Flags For Whether:

• Animal Attack • Unregistered Animal • Complaint – E.G. Noisy Animal, Etc. • Field Observation

Impounded Flag Impounding Officer Reason For Impounding Pound Id/Name Pound Location Kennel Id/Name Kennel Location Impounding Date Disposal Method Release Flag Registration Amount Transaction Type (Eg. New Dog Registration, Registration Renewal, Etc) Animal Owner Name Owner Location Additional Information (Medication, Allergies, Etc) Comment (Eg. Warning For Dangerous Animal). Guard Dog Flag From Date/Time (Guard Dog Begins At Location) To Date/Time (Guard Dog Finishes At Location)



LAND AND PROPERTY INFORMATION SYSTEM FUNCTIONAL REQUIREMENTS APPENDIX 1. GENERAL AND TECHNICAL REQUIREMENTS A list of general and technical requirements for the Land and Property Information System has been included below. These requirements will be generic across all subject groups and modules:

1.1 User Interface

1.2 Workflow Capability

1.3 Systems Administration

1.4 Audit Trail



1.7 Web Interface

1.8 Upgrades

1.9 Data Migration

1.10 Operating System Environment

1.11 Database Environment

1.12 Network Environment/System Architecture



REQUIREMENTS DEFINITION DOCUMENT Ranking Comment




Functionality – General and Technical

1.1 User interface

1.1.1 Mouse-driven, Windows-style icon driven point and click environment, consistent with Windows Manager style guide.

M

1.1.2 Mouse capability and keyboard support (able to use function keys, shortcuts, macro capability, etc).

M

1.1.3 Print capability for all screens. HI

1.1.4 Options for touch screen capability. O

1.1.5 Options for voice activation. O

1.1.6 Screen sequence or 'thread' is not easily lost by a user. HI

1.1.7 ‘Right-click’ (mouse) features available and configurable. HI

1.1.8 On-line Help

1.1.9 An on-line tutorial is available, together with documentation on paper. HI

1.1.10 On-line documentation complements the paper-based documentation. M

1.1.11 On-line help is customisable by site or even by user/department/section. I

1.1.12 'Balloon' help is available to explain functions when hovering the mouse over icons/menus/etc.

M

1.1.13 Context-sensitive help is available, attached to screen or system function. M

1.1.14 Keyword searching is available.

M

1.1.15 Help is configurable (eg. to match workflow).

I

1.1.16 Wizards to aid general use of the system or specific tasks. I

1.2 Workflow capability

1.2.1 Able to turn workflow functionality on/off. HI

1.2.2 Workflow needs to be flexible. Able to easily add/remove tasks. M




1.2.3 Able to change the order of workflow tasks. M

1.2.4 Able to bypass workflow tasks if Council deems appropriate. M

1.2.5 Able to attach flexible preconditions to workflow. M

1.2.6 Able to add comments (notes) against each task in the workflow. M

1.2.7 Able to facilitate electronic signoff of each task in the workflow (include user, date and time stamp automatically).

M

1.2.8 Able to attach predefined performance criteria (time or output) to each task. HI

1.2.9 Able to stop/start clock for recording time against each task, but with appropriate audit trail (eg for requesting additional information).

HI

1.2.10 Able to differentiate between task times for internal staff and external. M

1.2.11 Able to attach a timeframe to the overall completion of all tasks in the workflow process.

M

1.2.12 Multiple severity levels are definable.

M

1.2.13 Severity levels are configurable (eg both in number of levels and name of each level).

M

1.2.14 Able to automatically increase urgency over time.

HI

1.2.15 Able to manually override severity levels given the appropriate privileges.

HI

1.2.16 Able to output performance related data for use in a resource planning capacity, etc. (eg interface/integration with HR system).

HI

1.2.17 Able to alert users on receipt of pre-determined events. M

1.2.18 Alerts superior to approaching/passed deadlines or when a certain action has not occurred.

M

1.2.19 Able to send alerts by e-mail or notify users irrespective of whether they are using the application at the time.

M

1.2.20 Able to notify personnel by pager, SMS message, etc. I

1.2.21 Records user skills and knowledge (technical skills, languages and so on). O

1.2.22 Maintains a calendar of user availability, or is able to link to third party electronic calendar. HI

1.2.23 Supports automatic request assignment based on user skills, knowledge, availability, etc. O




1.2.24 Dispatches requests and tasks to groups.

HI

1.2.25 Assigns requests to multiple users concurrently. HI

1.2.26 Multiple escalation levels are available and these are configurable. HI

1.2.27 Automatic routing of event/task to other user or groups of users is possible on escalation. HI

1.2.28 Escalated calls are highlighted (for example, using colour, flashing, sound, etc). HI

1.3 System Administration

1.3.1 User interface customisation

1.3.1.1 Changes to the user interface can be made via a point-and-click/drag-and-drop style interface.

M

1.3.1.2 Screen layout can be changed freely, including placement of icons and fields. M

1.3.1.3 colours and fonts can be changed. I 1.3.1.4 Names of field labels can be changed. HI 1.3.1.5 Basic user interface changes listed can be

made by individual users (eg colours, fonts, tab order, etc).

I

1.3.1.6 ‘Flex fields’ are available in all tables for adding new fields to the database, with the option ability to define the type of data, mask input and have a reason or descriptor for the input.

HI

1.3.1.7 Free-form text (memo) fields can be added as necessary, with the capability of inserting jpg’s, sounds, etc.

HI

1.3.1.8 Default field values can be selected. I 1.3.1.9 Fields can be hidden. M 1.3.1.10 Screens can be added from scratch. O 1.3.1.11 Screens can be removed. O 1.3.1.12 Shortcut key assignments can be configured. HI 1.3.1.13 Function key assignments can be configured. HI 1.3.1.14 Tab order can be configured. HI

1.3.2 Management of customisation

1.3.2.1 All methods of customisation (not performed by the vendor) can be performed without having to be reapplied during an upgrade.

M

1.3.2.2 access to the customisation function is restricted. M

1.3.3 Business Process/Workflow customisation

1.3.3.1 changing existing events and tasks. M



REQUIREMENTS DEFINITION DOCUMENT Ranking Comment 1.3.3.2 new events and tasks can be defined. M 1.3.3.3 business processes can be altered to include

new steps; or steps can be removed. M

1.3.3.4 Processes may be assigned to individuals or groups. M

1.3.3.5 tasks can be defined independently so they can be used by more than one process. M

1.3.4 Security

1.3.4.1 Users are able to change their own passwords.

M

1.3.4.2 User passwords are integrated with the Operating System.

M

1.3.4.3 User groups can be created.

M

1.3.4.4 User privileges can be attached to user profiles.

M

1.3.4.5 Custom user profiles can be created.

M

1.3.4.6 Access can be restricted to subsets of data.

HI

1.3.4.7 User access can be restricted down to field level.

HI

1.3.5 Error Messages

1.3.5.1 Error messages may be easily interpreted and are English based (not wholly code based). HI

1.3.5.2 From the error messages, the System Administrator can distinguish between errors which are application related or database related.

HI

1.3.6 Application Programming Interface (API)

1.3.6.1 A scripting environment is provided.

HI

1.3.6.2 An API is provided through which custom code components can be used.

HI




1.4 Audit Trail

1.4.1 An audit trail can be kept of every nominated event on the system. Specific details may be audited/unaudited.

M

1.4.2 Is secured.

M

1.4.3 Alerts can be triggered from particular audit trail events occurring.

HI

1.5 Data access/Reporting

1.5.1 Query capability is flexible so that any data fields may be included.

HI

1.5.2 Flexible query methods (eg. usage of wildcards, keywords, etc).

HI

1.5.3 Query type reporting is available.

M

1.5.4 Reporting is flexible so that any data fields from any module may be included.

M

1.5.5 Ability for multiple/itemised totals.

M

1.5.6 Able to export reports, with a range of file formats.

M

1.5.7 A highly normalised ‘business view’ of the database is available for query (i.e. containing only the fields relevant for business so that new reports can be written by non-technical users). Has capability to link with an Executive Information System.

HI

1.5.8 Able to use a third party report writer for reporting. M

1.5.9 An Entity Relationship Diagram is available, showing all tables and table relationships. HI

1.5.10 Purge/archive option for historical data. M


1.6.1 Able to enter and process credit card payments. M

1.6.2 Able to link with major corporate systems (using technologies such as XML, etc). M

1.6.3 Able to interface files with the ability to customise data gathering and/or transaction processing applications/applets.

I

1.6.4 Dynamic interfacing/integration with Office Automation products(eg Microsoft Office). M




1.6.5 Able to integrate with electronic staff calendars. I

1.6.6 Able to integrate with electronic staff task lists. O

1.7 Web interface

1.7.1 A web version is available as a distributed end-user application. HI

1.7.2 The web version is indistinguishable from the standard application. O

1.7.3 A web version is available which provides access to all software features via a web browser (including support for both Microsoft Internet Explorer and Netscape).

HI

1.7.4 The system facilitates e-commerce, providing mechanisms for secure payment (eg for payment of parking fines, dog registrations, etc).

M

1.8 Upgrades

1.8.1 All upgrades can be performed via execution of a purpose-built software routine, even if significant database changes are required. That is, manual changes do not have to be made to the database structure, constraints, etc when performing an upgrade.

HI

1.9 Data Migration

1.9.1 A software utility is available to assist with data migration from legacy system(s) so that manual routines do not have to be written for input of data into the new system.

HI

1.9.2 A software utility is available to assist with data migration if this is required (eg for a major system upgrade) so that manual routines do not have to be written.

M

1.10 Operating System environment

1.10.1 The system is compatible with current industry standard database platforms/operating systems.

M

1.11 Database Environment

1.11.1 Throughput specifications are available for number of transactions by module.

HI

1.12 Network environment / System Architecture




1.12.1 Supports distributed processing/replication (eg. 2-tier or 3-tier system architecture). Eg able to handle offline payments, so that if the system is down, a transaction may still be entered using the client, with processing being completed when the backend becomes operational again.

HI

1.12.2 Different environments may be run on any one client simultaneously (eg Production, Test, Development).

M

1.12.3 Software utilities are available to configure the client PC to run the application. M

Date post:	20-Aug-2018
Category:	Documents
Upload:	duongdan
View:	239 times
Download:	0 times

FUNCTIONAL SPECIFICATION - lga.sa.gov.au · FUNCTIONAL SPECIFICATION ... a group was formed...

Documents