Get documents about "Must Clone Certificate
W
Description
Must Clone Certificate document sample
Document Sample
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
General Requirements Bid Ref: 4.1.0
The proposed system when implemented must provide This functional capability is to be provided to the system Admin.
tools for the user (designated user - System admin ) to These tools allow for the City of Fontana (COF) to build its own
1.1.1 3.1.3 configure forms/screens. forms/screens and alter those provided. This will be in order to 3
provide a best fit for business practices within the COF.
•The proposed system when implemented must provide We expect this capability to be provided to the defined system
tools for user configurable tables, allowing super users admin person (s). This feature is provided in order for the
1.1.2 3.1.3 to add /update tables, fields and respective properties. customer (COF) to be able to have a flexible development 3
environment which provides alternatives to static or out of the box
approaches.
The proposed system when implemented must We expect this capability to be provided to the defined System
provided tools for user (System admin group) admin group for system purposes as well as reporting purposes.
configurable tasks using SQL scripts. This includes but
1.1.3 1.2.12 is not limited to SQL triggers, SQL views, SQL functions 2
and SQL stored procedures.
The proposed system when implemented must work We expect the system to work within the confines as prescribed
within the confines as prescribed and defined for and defined Microsoft SQL Server 2005 use and support.
1.1.4 Microsoft SQL Server 2005 usage and support (This is 3
a minimum requirement).
The proposed system when implemented must We expect the system to allow e-mails to be sent for prescribed
integrate e-mail calls with MS Outlook (2003 & 2007) tasks/activities and events in the work-flow.
1.1.5 3.1.13 9.1.2b Inboxes, Tasks, Scheduler and Contacts. The calls can 2
be made from tasks, condition alerts and calendar
events.
The proposed system when implemented must be able We expect the proposed system to have a seamless connection
to connect with the City of Fontana‟s existing intranet across the City of Fontana's intranet.
and internet capabilities and use it for WEB
functionality. This would require thin client (web enabled
capabilities) to have 100% functionality within Fontana‟s
1.1.6 existing intranet and internet. Modules or aspects of 3
the system requiring remote connectivity will need to
consider additional requirements and specifications
listed for the "field application" requirements.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 1 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system must work in a VMware Must work with the most current environment
environment and an application server environment,
1.1.7 with servers that are running Windows 2003 Server and 3
Windows 2005/2008 Server.
The proposed system when implemented must follow We expect Adherence to MS .NET version 2.0 standards.
current MS .NET version 2.0 standards. Adherence to features or best practices provided with .NET 3.0 &
1.1.8 .Net 3.5 are allowed but must be meticulously documented in the 2
code, in system documentation and system analysis documents.
The proposed system when implemented must provide This is a needed audit trail. The System admin along with
meta-data for when a record was added or updated developers can define which fields are most important for
(Date and show who did it). Changes to the listed fields tracking. This may be deployed as a "Client form Maintenance
(Date and who did it along with previous value and Meta data sub set.
1.1.9 set). 3
The proposed system when implemented must provide We expect to be provided with the documentation for all API
1.1.10 a published API object model, Web services and object object modules, Web services and object libraries.. 3
libraries.
The proposed system when implemented must be able We expect to be able to use the following .NET languages. C#,
to be extended using any MS .NET language (with MS Visual basic, ASP, AJAX along with associated CSS1, CSS2,
1.1.11 .NET 3.5 as the minimum standard) or Web Services XML and XHTML calls. 2
model.
1.1.12. The proposed system when implemented must We expect the system to contain spell check reference
provide a spell checker and provide a dictionary. The capabilities.
Dictionary must be configurable. Different dictionaries
1.1.12 1.1.13 must be able to be referenced for individual (unique) 2
forms and/or designated fields within any given form.
1.1.13. The proposed system when implemented must We expect the system to contain spell check reference
allow at the end user level for the end user to select a capabilities for special terms or common nomenclature.
1.1.13 1.1.12 pre-existing dictionary (from MS Word for example.) 2
(Remote clients such as non COF employees need not
have this capability.)
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 2 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must allow Currently this is internal within the existing system. The desire is
the user to attach files to cases, applications, permits, to have this function interface with the citywide Lasefiche system
activities, conditions, parcel records, and notes. The
1.1.14 3.1.19, 11.1.9 attachments would include but are not limited to PDF 3
files, JPEG files, MS Word Files, MS Excel files, MPEG
files, TIFF files and GIF files.
The proposed system when implemented when We expect a limited version of prescribed forms which will allow
providing areas for display (screen/forms) of public forum clients to use the system in order to obtain
information to be viewed by the public sector, should be information and submit information as part of requests.
distinguishable (separate and ascertainable) from other
confidential information (screens/forms). This is done
1.1.15 all section 15 so non-public users (city employees - generally 3
speaking) of the system can easily see what
information is about and discern what may or may not
be exposed to the public via the web or on other
reports.
The proposed system when implemented must provide We expect to be provided with the documentation for all DLL
a DLL object / class libraries along with documentation object / class libraries.
1.1.16 1.1.10 to the City of Fontana's (COF) IT system and 2
application staff. .
An agreed to training methodology must be a This is to be incorporated as part of the project. Process must
conspicuous component throughout the regard stipulations in the integration, communication and
implementation. This should include: Training scheduling plans. New information is to be placed into the
1.1.17 1.1.21 schedules, approach methodologies, individual training scheduling and communication plans. 3
product deliverables, iterative needs training and
consideration for product deliverables to specific
audiences.
The entire intended and designed implementation The same tools for modifying ancillary items must be used
solution must allow the LAMPS Land Management through out and be relevant to LAMPS LMS and CEGIS portions
1.1.18 System LMS to be thoroughly integrated with the of the project. 2
LAMPS CEGIS system (Code Enforcement - Weed
Abatement).
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 3 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system which is suggested for The ability for the user or designated users to find out the
implementation must provide with the forms/screen database field name and table which is being display. This can be
creation tool set the following capability for form/screen something like a right click or a momentary hover over the field
fields. When fields are inserted into the finished which displays the info.
1.1.19 form/screen the users or designated users should be 3
able to easily determine the name and source of the
field being used.
The proposed system which is suggested for This can be something like a right click or a momentary hover
implementation must provide with the forms/screen over the field which displays the info. About the fields use.
creation tool set the following capability for form/screen
1.1.20 fields. Provide the user with the meaning , use or 2
purpose for the field being used.
The agreed to training methodology must follow the Training will be given when it can be most effective and efficient.
project needs schedule. This will be governed by the Not to far before or after an effective increment is released.
overall schedule in the project plan which will support
an Agile process for deployment of incremental work
1.1.21 1.1.17, 11.1.12 and modules. The approach methodologies used will 3
focus on system training user usage training, and
business and workflow training. All this is to be done at
prescribed intervals governed by the project plan.
General Requirements - Reporting Requirements
The proposed system when implemented must allow for We use SQL Reporting Services (SRS) and expect the application
1.2.1 calls to a SQL Reporting Services (SRS) from within the to make calls to SRS for reporting purposes. 3
application.
The proposed system when implemented must allow for This would allow a case number to be passed to a particular
calls to a SQL Reporting Services (SRS) by allowing report such as a permit , invoice, activity sheet or fee report. This
1.2.2 the application to pass a parameter or series of specification would also include other information used by the 3
parameters in order to produce the report. system to be passed as a parameter.
The proposed system when implemented must provide This is a basic report writer function which users can depend o to
1.2.3 a basic report writing engine other than SRS. do quick and dirty reporting if needed. 2
The proposed system when implemented must allow This can be a search list or special query tool which allows the
1.2.4 users to create flat export lists through a data query. user to export the listed information for use in another format such 3
as MS excel
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 4 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must allow This is an AD-hoc reporting requirement and should come from
users to export data from a data query list and allow for search lists.
1.2.5 parsing. Parsing must allow export to insert at least a 3
tab, comma or space as a delimiter.
The proposed system when implemented must allow for This is an AD-hoc reporting requirement and should come from
external lists to be created for mail merge with MS search lists.
1.2.6 Word. 3
The proposed system when implemented must allow Specially designed reports can be directed to a specific printer
the report written in SRS (or external report writer) to
1.2.7 direct where the designated output printer is and NOT 3
automatically use the system default.
The proposed system when implemented must provide Outgoing documents must be able to be attached/associated at
a way for a CAP to be able to track correspondence the level needed .
1.2.8 1.2.9 1.1.14 (letters, invoices, statements, permits) going out. 3
The proposed system when implemented must be able Incoming information can be scanned into a document
1.2.9 1.2.8 to track correspondence (letters, invoices, statements, management system and placed either at the UID level, Parcel 3
permits) coming in. level, situs level, CAP level or activity level
• The proposed system and solution implementation The defined report list will need to have it's business requirement
must include the conversion of all designated Crystal analyzed and prioritized. Each report must be converted to the
reports used in the city's Tidemark/Advantage system. agreed report engine and work within the same workflow for each
1.2.10 10.1.6 This would also include the batch and system Utilities. (CAP) type or their related activities. 3
(see appendix for attached spread sheet)
The proposed system when implemented must allow for This is an AD-hoc reporting requirement and should come from
1.2.11 external lists to be created then mail merged with MS search lists or special list functions. 3
Excel
The proposed system when implemented must allow for Must allow for creation of views and functions to be used by
1.2.12 1.1.3 creation of views and functions to be used by reports. reports. 2
General Requirements - Sys Admin CAP Tools
The proposed system when implemented must allow for The System admin designates and controls CAP types.
the system administrator to designate CAP types (PMT,
1.3.1 1.3.2 ENG ASP etc.) 3
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 5 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must allow for The System admin designates and controls CAP nomenclatures.
the system administrator to control CAP nomenclature
1.3.2 1.3.1 parameters such as the use of the current calendar 3
year within the nomenclature and seasonal indicators.
The proposed system when implemented must allow for The System admin designates and controls drop down list (value
The system administrator to setup drop down list (value and descriptions) for form fields within the CAP forms.
1.3.3 and descriptions) for form fields for CAP forms. 2
The proposed system when implemented must allow for The System admin programs how one field in a form reacts to the
1.3.4 the system administrator to setup front end editing value of another field in the form. 2
between fields for all CAP forms.
The proposed system when implemented must allow for The System admin define valuation for any particular CAP form.
the system administrator to setup valuation for all CAP This may be done by a super user as well within the department
1.3.5 forms. the CAP form is defined for use. 3
The proposed system when implemented must allow for The System admin define which user and /or groups may view,
the system administrator to define field access rights read or write to a field.
1.3.6 and privileges. 3
The proposed system when implemented must allow for The System admin may define how a field is used and which
1.3.6 the system administrator to define how certain fields fields are used as part of the fee logic and calculation. 3
may be used for fees..
The proposed system when implemented must allow for The System admin or a super user needs to be able to setup
the system administrator or a super user setup activities/tasks/events for any particular CAP.
1.3.7 1.3.13 activities/tasks/events for any particular CAP. 3
The proposed system when implemented must allow for The System admin or a super user needs to be able to define
1.3.8 the system administrator to define what types of tags what types of tags may be used on any Particular CAP. 2
may be used on any Particular CAP.
The proposed system when implemented must allow for The System admin or a super user needs to be able to define
the system administrator to define what types of what types of conditions may be used on any Particular CAP.
1.3.9 conditions may be used on any Particular CAP. 3
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 6 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must allow for The System admin or a super user needs to be able to define
the system administrator to define what types of what types of conditions may be used on any
1.3.10 conditions may be used on any activities/tasks/events activities/tasks/events for any particular CAP. 3
for any particular CAP.
The proposed system when implemented must allow for Designated users need to be able to define projects which can
designated users to define projects which can have any have any particular CAP associated with it. This must include a
1.3.11 number of any particular CAP associated with it. project name, Project owner (sponsor), people associated with the 3
project, a project number (nomenclature), description and date
fields.
The proposed system when implemented must allow for Designated users need to be able to define programs which can
designated users to define "programs" which can have have multiple projects associated with it. This must include a
1.3.12 multiple projects associated with it. program name, program owner (sponsor), people associated with 2
the program , a program number (nomenclature), description and
date fields.
The proposed system when implemented must allow for The System admin or a super user needs to be able to setup
the system administrator or a super user setup date scheduled dates for activities/tasks/events on any particular CAP.
1.3.13 1.3.7 intervals used for tracking duration and scheduled work 3
for activities/tasks/events for any particular CAP.
Processing Data Screen and Forms Criteria
The proposed system when implemented must provide The system itself needs to provide the overarching designation of
3.1.1 Windows network authentication with Group Member privileges and restrictions.
security assignments.
Besides SQL data access levels, the permitting system Restrict/allow access CAP forms and fields for users and
must provide additional access levels, and restrictions departments.
3.1.2 within the software based on AD Group membership. 3
The proposed system when implemented must provide Allow user group leads (designated super users ) as well as the
access levels (User/group security rights & privileges) System Admin to be able to update these fields.
for viewing/update of various information. The following
considerations must be applied:
▪ Form/Screen: (Permit type)
▪ Functions within a Form/Screen: (Permit type)
▪ Field level restrictions within a form: (view & update)
▪ Activity/tasks/events Adds
▪ Activity/tasks/events signoff security
3.1.3 1.1.5 9.1.2b 3
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 7 of 104
Allow user group leads (designated super users ) as well as the
System Admin to be able to update these fields.
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
3.1.3 Reference
1.1.5 9.1.2b 3 Cost
▪ Attached Document: (view & update)
▪ Parcel/Situs address activity: (view & update)
▪ Parcel/Situs address Business Attribute: (view &
update)
▪ Fees (view & update)
▪ Tags, Conditions, holds
▪ People Information (view & update)
▪ Group membership (departmental level)
▪ Group membership ( special cadres)
▪ A user can belong to more than one group.
The proposed system when implemented must provide Tab down sequentially on a form/screen
tab order navigation along with functional drop down
3.1.4 menus that can be reordered and or changed by the 2
system admin user. Along with this, the system should
allow for unique hot keys.
The proposed system when implemented must allow for The user needs to be able to tab through the form in order to
tab order entry within a form. Along with this there is the expedite entry. The super user/system admin will have the ability
3.1.5 requirement for the super user/system admin to have to change the tab order if necessary. 2
the ability to change the tab order if necessary.
New releases/versions (upgrades) of the software We do not want a solution that proposes large scale alterations
proposed for use as part of the implemented solution for every minor version change.
must allow for existing forms/screens (already being
3.1.6 used in a production environment) to function without 3
requiring the forms/screens, field algorithms, table links
or views to be altered.
The system‟s screen forms must allow the user to The forms and typical displays need to use as much screen real-
utilize the full screen height and width of their monitor estate as possible.
3.1.7 (typical size shall be defined as a 17 inch diagonal 2
screen @ 1280 x 760 pixels).
The proposed system when implemented must provide The “system admin / super user” needs to be able setup the
the ability to setup an alert condition that are defined for appropriate alert messages in the system.
3.1.8 use on a particular form/screen and must be obvious. 2
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 8 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must allow for This is online help for the form as well as the fields within the form
specified fields or areas used in a forms/screen to be
3.1.9 3.1.10 linked to a help screen that is definable and 2
customizable by the system admin user.
The proposed system when implemented must allow At strategic points of forms/screens, a help screen can be
the embedding access to standard business operating generated for the user.
3.1.10 3.1.9 procedures including help and workflow documentation 2
from within all forms/screens.
Within the system the form design must allow the It is expected that certain forms/screens will need to have scripted
“system admin / super user” to design a scripted areas in order for the user to follow a "fool-proof" type work flow.
3.1.11 form/screen based on workflow (Standard operating 2
procedures to match best business practice).
The proposed system when implemented must allow
3.1.12 logical interconnection between related forms/screens. 3
(jumping between forms)
The proposed system when implemented must provide
3.1.13 1.1.5 built in e-mail capabilities. Along with this formatting 3
and sending a fax.
The proposed system when implemented must feature
“event-oriented” activation capability; i.e. “when a given
event occurs during a given process, then do this new
3.1.14 process.” OR “When the following fields contain these 3
arguments then set a flag field or multiple flag fields for
conditions.”
The proposed system when implemented must provide
tools for editing of existing system forms/screens,
including but not limited to some of the following:
(Note: this is expected to be a Client System admin
user capability)
The ability to add new fields
The ability to create scripted arguments for front end
input editing (business logic)
The ability to format the placement of fields
including; position, size, font, fore/background color
3.1.15 and frame. 3
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 9 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
3.1.15 Reference 3 Cost
The ability to add static graphic files as part of the
form (ex.. logos)
The ability to place functioning buttons, radials and
check boxes.
The ability to change existing field display names.
The ability to add an activity script to a field as
needed.
The ability to add a stored procedure (SPROC) to a
field for adds and updates.
The Systems forms/screen edit functions (tools) must
3.1.16 allow the system admin user to add graphic files for 2
logos, backgrounds and title bars.
The proposed system when implemented must allow The application needs to use as much screen real-estate that is
the forms must be able to do calculations. Fields which available.
3.1.17 act upon each other when filled out will calculate 3
The proposed system when implemented must allow
3.1.18 drop down lists for fields to be sorted if desired or 2
searched (especial for longer lists)
The proposed system when implemented must allow A proposed solution is expected for attaching documents (pictures
forms/screens which have been designed as the part of included) onto a CAP using an existing archival or documents
the initial implemented solution (or at the a later time management system as the storage application.
1.1.14, 11.1.9, should enhancement be needed) to provide for the
3.1.19
3.1.20
3
attachment of multiple documents are connected to an
external archiving and/or document management
system
The proposed system when implemented must allow The users expect to be able to see documents attached to CAPs
forms/screens as the part of the initial implemented generated on the legacy system, (perhaps not in the same way as
solution which have fields or subforms which will the overall proposed solution for attaching documents)
1.1.14, 11.1.9, contain attached documents coming from the legacy
3.1.20
3.1.19 system. This may be provided as an alternate means to 2
handle document attachments coming from the legacy
system
Implementation: Reporting requirements
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 10 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The data schema implementation of the proposed
system/ solution must allow both Crystal Reports™
10.1.1 and/or Microsoft SQL Reporter to be used for major 2
system report generation.
The data schema implementation of the proposed
system/ solution must allow reports created using
Crystal Reports™ and/or Microsoft SQL Reporter to
10.1.2 be launched from within the application form (at least 3
the thick Client not so much from the Web pages)
Implementation of the proposed system/solution must
include Invoices can be configured to print on a
10.1.3 specified (default) printer or select from a network list. 3
Implementation of the proposed system/solution must
include paper forms (letters invoices, estimates,
10.1.4 applications, reports) to be printed to a designated 2
default printer, not necessarily the user‟s (PC System)
default printer.
Implementation of the proposed system/solution must We expect Building and Safety permits to print using an impact
print the Building and Safety approved permit on a type printer on a prescribed NCR form currently being used by
preprinted 8 x 14 NCR form on a specified default COF the Building and Safety Department
10.1.5 printer. The form has a 40# card stock backing which is 2
pre-printed and used as the inspection card posted at
the site.
See referenced detail for list of reports currently
10.1.6 1.2.10, 10.1.7 produced in Tidemark and Used by the City of Fontana. 2
Implementation of the proposed system/solution must
10.1.7 10.1.6, 10.1.8 include the conversion of all reports from the Tidemark 3
System for use with the new system.
Implementation of the proposed system/solution must
include must consider during the conversion of all
10.1.8 10.1.7 reports from the Tidemark System, where the report is 2
originating from (what processes is spawning the
report).
Implementation of the proposed system/solution must
10.1.9 include the ability to design flat reports for the end users 3
to extract data for special analysis
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 11 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
Implementation of the proposed system/solution must
allow the end users to enter controls and selection
10.1.10 (dates, date ranges, permit types, field value types etc.) 3
as part of the reporting criteria prior to report
generation.
Implementation of the proposed system/solution must
provide report generation from CAPs to auto-populate
defined fields and auto-run with out user intervention. IN
10.1.11 other words from a click of a button an invoice can be
printed (reprinted) or a permit/applications can be
printed (reprinted) without the user having to "fill in in
information"
Implementation: General
Implementation of the proposed system/ solution must Migration strategy must be designed and tested several times
include converting all existing data from the City of
11.1.1 Fontana‟s – Accela Advantage/Tidemark system and 3
upload the data over to the new system.
The initial idea for implementation is a „phase-in‟
approach, the implementation of the proposed system/
solution must include subsequent selective conversions
11.1.2 of existing data from the City of Fontana‟s – Accela 3
Advantage/Tidemark system and County Parcel data
which will need to be uploaded to the new system.
Implementation of the solution must include a business
11.1.3 all of 12.1 area analysis prior to system builds, form builds, 3
schema builds and report builds.
Implementation must schedule regular training at
11.1.4 11.1.5 appropriate intervals that are cohesive with module 3
testing availability and go-live availability.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 12 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
Implementation of the solution must include multiple Prior to Go-live a large number of users ( which would be
load tests with users prior to go-live. The considered normal use of the system for a given day) will all login
implementation process for all interface parts of a and begin using the test system.
module or negotiated integral steps (this included but is
11.1.5 11.1.4 not limited to forms /screens, web pages, reports, 2
import process, export process, lists and extracts) must
allow for user 'buy-in' and approval signoff. These
integral steps must match negotiated implementation
decision points.
Implementation is envisioned as beginning with all land
based data schemas being defined and tested. This
would be the core starting point. Included but not
limited to schemas following business rules for Unique
11.1.6 parcel identifier table (s), Parcel asset) tables, Address 2
table (s), owner table (s), contactor table (s) all
validation and maintenance tables, security schemas,
and initial forms to handle land management areas.
Once testing and documentation is completed for
11.1.6 then the CEGIS portion (entire) Code
11.1.6, all of Enforcement implementation would begin. 11.1.6 11.1.7
11.1.7
section 20
1
are the first highlights of the beginning process or
phased in approach.
Assist the City in implementing Weed Abatement
11.1.7, all of
11.1.8 workflow and integrating it with the overall system. 2
section 20
The Implementation process for the proposed solution
when providing for the moving of data from the old
system onto the new, must include all link references to
attached documents. Along with the references there
11.1.9 1.1.14 must be the physical location for the files along with the 3
ability from within the function of the cases, applications
or permits for the attached documents to accessed
(opened for view, change, add).
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 13 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The Implementation process for the proposed solution We want the IVR process to work the same as the existing
must provide a tested integration with the existing IVR system using the same inspection numbers and the same
6.4.19, 6.4.6, system or provide a pre-approved IVR solution. The pre- protocol.
11.1.10
6.4.7 approved process must include testing, specification 3
listing and specification verification).
The Implementation process for the proposed solution COF will be using PMI project management methods and
and overall approach must consider PMI project techniques to govern the project.
11.1.11 11.1.12 management methods and techniques which will be 2
used by the City of Fontana (COF)
The Implementation process for the proposed solution COF will be using PMI project management methods and
and overall approach to design, testing and migration techniques to govern the project along with an AGILE approach to
11.1.12 11.1.11, 1.1.21 will incorporate an AGILE process for many of the many of the design iterations. 2
design iterations, reports and end-user deliverables
(including training).
Implementation Business Area & System Analysis
The Implementation process for the proposed solution Take the existing Business Area and System Analysis and use
must include a preview of the existing Business Area & this for a source baseline to define additional needs and
System Analysis. This is to be done for all project constraints.
defined product development modules, forms or build
12.1.1 12.1.2, 12.1.3 cycles along with their associated project tasks. The 3
outcome will be an updated Business Area and system
analysis that can be used and referred to during project
initiation.
The implementation process for the proposed solution
must review all defined implementation requirements,
(module builds, form builds, data schema builds etc.)
12.1.2 12.1.2, 12.1.3 specifications, business analysis, and project and 3
product scope documents.
The implementation process for the proposed solution
must follow a formal Project Quality Management
process. This requires adhering to the specifications,
12.1.3 12.1.2, 12.1.4 Quality Check lists, metrics and agreed to processes 2
which augment the metrics and quality checklists.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 14 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The implementation process for the proposed solution
must follow a formal Project Scope Management. This
requires adhering to the specifications, Quality Check
12.1.4 12.1.3 lists, metrics and agreed to processes which augment 2
the metrics and quality checklists. This also includes
the product scope.
The implementation process for the proposed solution
must provide documentation which augments the
12.1.5 11.1.12 provided BAA and BSA for use with the project in 2
developing the scoped product.
The implementation process for the proposed solution
must provide the data mapping from the old system
data structure to the New System data structure.
Therefore all proposed posed and actuated schemas
12.1.6 for the new system will need to be documented. The 3
documentation will need to include what table and field
from the old (Tidemark System) data scheme will be
used to populate this data at conversion time.
The project activation process requires designated
project [parties to create a living "Active" Business Area
12.1.7 11.1.12 Analysis and Business system analysis (referred to as 2
the "Active BAS or Active BSAA") .
CAP Management of People Information
Implementation of the proposed system/solution must This is to understand the City of Fontana's workflow in this area.
consider how current People information is utilized for
the existing system. This involves documenting its use
13.1.1 All of 12.1 and considering a similar structure for defining how 3
people information populates a CAP, the parcel
information and Situs Address information.
The proposed system when implemented will provide The current system allows this and is appreciated and used by the
the capability to define more than one people record to users.
13.1.2 a CAP, Parcel or Situs Address record. 3
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 15 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must provide The current system allows this and is appreciated and used by the
the capability to attach the same people record more users.
13.1.3 than once to any CAP, Parcel or Situs Address. The 3
difference on the attached record will be field definitions
such as role type.
The proposed system when implemented must provide The current system allows this and is appreciated and used by the
the capability to attach more than one contact users.
information record to the people record instance. This
13.1.4 for Phone1, Phone2, Cell Phone, FAX, Email, Business 3
address, Mailing Address etc..
The proposed system when implemented must provide
the capability to take an existing people record attached
to CAP, Parcel or Situs Address record and clone it
along with its attached contact information and license
information. Then allow the user to change the role
type. This facilitates the need when various roll types
for the same persons "people record" needs to be
13.1.5 3
populated within a particular CAP. In the workflow
instance where it is the same person fulfilling two
different role types the use can simply clone/copy the
record and change the needed fields. This is to save
time when redundant information is needed.
The proposed system when implemented must provide Attach Business, regulation and contractor license information
the capability to attach contractor license records. This only as required.
13.1.6 13.1.7 includes date driven parameters which allow the user 3
and the system to note when a contract expires.
The proposed system when implemented must provide Attach Business, regulation and contractor license information
the capability to attach (add, update and delete) license only as required.
13.1.7 13.1.6 (Business, Contractor) and certificate information. 3
The proposed system when implemented must provide be able to search people and CAPs based on License information
the capability to search people records and case including license type
13.1.8 records (CAPs) based on license (Business, 3
Contractor) and certificate information.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 16 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
Be able to clone people information applied to an Allow a directory to be built that can be drawn from a stream-lining
individual CAP and provide it in a "people" directory for input process.
13.1.9 future use by subsequent CAPs and for reporting. 3
The proposed system when implemented must provide The Community access user may add or update their own contact
13.1.10 15.1.7 the capability community access users to update their information. 2
own CAP people information
The proposed system when implemented must provide Add or update contact information in the field.
13.1.11 6.5.14 the capability for field inspector's to add additional or 3
update contact information.
General Requirements Score: - $ -
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 17 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
PARCEL GEO DATABASE Bid Ref: 4.1.1
PARCEL GEO DATABASE
The proposed system when implemented must have a We expect this group of tables to be updated from the GIS SDE
2.1.1 Parcel table (asset table) in the database along with information database which contains the UID. 3
attached tables.
In the proposed system when implemented the We expect all references for cases to be associated by the UID.
system‟s parcel (asset) table must contain an assessor The Parcel number (APN) becomes a secondary attribute field.
parcel number (APN) file which is separate from a
2.1.2 parcel record asset number field( key). The separate 3
asst number can be considered the universal ID (UID)
described in requirement 2.1.3.
In the proposed system implementation, the system‟s We expect all references for cases to be associated by the UID.
parcel (asset) table must contain a Universal Parcel The Parcel number (APN) becomes a secondary attribute field.
Identifier number (UID) field allowing a link to a table
2.1.3 located on an external database. The field in this table 3
must be able to be indexed, queried and sorted.
The system‟s parcel (asset) table must allow Universal We expect the use of drop down lists to during parcel
parcel number identifier (UID) to be used to retrieve maintenance to populate the fields for the corresponding types of
utilities district information located in the Permitting utilities. During CAP add or updates this information ca be made
2.1.4 System. Utility district types would be defined as Fire, available from the parcel table series on request. 3
Refuse/Trash, Water, Electrical, Lighting, Gas , Sewer,
Code Enforcement etc..
The system‟s parcel GEO database must provide an We are not sure of all the ways the data can come to this system,
occupancy information table to be linked to the but we are sure we need this table.
Assessor Parcel table. Include fields such as
2.1.5 2.1.7 person/business name, date of occupancy, note field, 3
reason field linked to table. This would be used for
indicating why this information is being tracked.
The proposed system when implemented must provide We expect the system's associated parcel tables to contain a
2.1.6 land use attributes for the parcel record. table which contains this information. 3
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 18 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The system‟s parcel GEO database must provide an We expect the use of drop down lists to during parcel
agency use flag and key field to be linked within the maintenance to populate the fields for the specific agency. During
same database. Identifies agency use (City, County, CAP add or updates this information ca be made available from
2.1.7 2.1.5 County-Fire, County Emergency, Federal, Utilities, the parcel table series on request. 3
School District, Historical Site and special)
The system‟s parcel GEO database must provide meta- We expect to be able to see and act upon this information (report,
data for when the record was added (Date and show update).
who did it), changes to the listed fields (Date and who
did it along with previous value and meta set):
▪ Parcel number entry/change
▪ Unique universal identifier
2.1.8 2.1.4, 2.1.7 3
▪ Parcel Address
▪ Tract/lot
▪ Land use attributes
▪ Addresses
▪ Owner information
▪ Details mentioned in sections (2.1.7, 2.1.4)
The proposed system‟s parcel GEO database when This information can serve as contact information for permits. It
implemented must include Information such as (Legal may also serve as applicant information as well.
2.1.9 name, Mailing address, Phone number 1, Cell Phone 2
number, fax Number, date assigned as owner, previous
owner details )
The proposed system‟s parcel GEO database when Need to be able to see all pertaining owner information
implemented must include parcel owner records that
include previous owner indicator, co-owner information
2.1.10 (Legal name, Mailing address, Phone number 1, cell 3
phone number, fax number, date assigned as owner )
The proposed system‟s parcel GEO database when Need to be able to see all pertaining owner information
implemented must keep a history of owners or pick up
2.1.11 owner history from ancillary system/database. 3
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 19 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must have Parcel attributes, conditions and history must be able to be
the system‟s parcel GEO database‟s parcel data given viewed and maintained. Maintenance will consist of needed
allowable access through maintenance form/screen. updates and or corrections
2.1.12 Access to this form must be able to be set for privileged 3
users, Admin User and/or user defined group.
Applications, functions and features utilizing the GEO This allows users to designate a search by setting up filters to
Parcel data must allow the user to be able to narrow their search criteria.
browse/filter parcel data by: parcel no., specific plan,
assessor No., Universal ID (UID), situs address, zoning,
2.1.13 * See Below districts, owner, permit no., code enforcement case, 3
residential type, commercial type, planning applications,
project, „In city‟ * flag codes, parcel status and tract/lot.
Case/Permit/Application process for add or update Need for Cap adds or updates; the user must be able search in
utilizing the system‟s parcel GEO database must GIS using prescribed or multiple entities.
provide the capability for the user to browse by: parcel
2.1.14 no., assessor no., universal ID., Owner, Zone, Specific 3
plan, situs address, zoning, districts and tract/lot.
Parcel records must be tied to a situs record. Parcel link Multiple addresses associated with one parcel as necessary.
2.1.15 must allow multiple situs addresses. This links to the
address point.
(See section on Situs Address for additional
2.1.15a
considerations)
The proposed system when implemented must provide Provide the following information.
the following fields for Parcel Data:
Parcel number The County Assessor's APN
Unique universal identifier UID
Parcel status Flag (Active, Retired) Parcel status Flag (Active, Retired)
Parcel Status reason – comment field (current, Parcel Status reason – comment field (current, number
number change, genealogy etc) change, genealogy etc)
Tract Tract Map Number
Lot Lot within the Tract
Last updated by Meta data
Date last updated Meta data
Notes field (memo field for notes)
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 20 of 104
2.1.16 3
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
Processing flag field ( Hold or No-Hold) due to Process flag
violations
Subdivision Subdivision
Zoning Designation Zoning code
School district Inter or Intra city School District
2.1.16 Flood zone Flood Zone 3
Census fields Census fields
Size various fields : (width, depth, sq. footage, Size various fields : (width, depth, sq. footage, acreage)
acreage)
Parcel Map id Parcel Map id
Specific/general plan Specific/general plan
“IN CITY” Code flag * “IN CITY” Code flag *
Utility district fields (Water, Electric, Gas, Phone, Utility district fields (Water, Electric, Gas, Phone, Fiber,
Fiber, Sewer) Sewer)
Last sale price This information is optional and comes from the assessor when
we can get it.
When last sold (date field) This information is optional and comes from the assessor when
we can get it.
Previous Owner id link to owner table Links to owner information
Owner id link to owner table Links to owner information
Land use attributes Multiple fields as required
Special District Used to assign special district (Historical)
Managed by City Managed by City
The proposed system when implemented must allow It is important within the internal process to only allow those who
the forms handling the above data (section 2.1.15) to be are required, make the changes. Therefore we expect the
restricted so that only specific (privileged) users can do implemented system to allow changes to the parcel and attribute
2.1.17 any updates. Other users may view specific field, but tables to be made by privileged end users and system admin 3
only defined uses can update. users.
The proposed system when implemented must provide This is to insure the City of Fontana has the ability to do any
automatic link fields from the parcel table to the owner, additional changes and development to the system as a whole.
permit, application, case, inspections and situs address
tables. Users should not be able to typically update or
2.1.18 view these links. Only COF system admin users may 2
be allowed to maintain these fields and their links as
required.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 21 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must allow A specified user or use group along with the system admin may
parcel renumbering to occur for the purpose of Parcel renumber parcels as needed.
2.1.19 number corrections, “PSEUDO” parcel number 3
assignments, Parcel grouping, Parcel splits and
Assessor map book changes.
The proposed system when implemented must allow A specified user or use group along with the system admin may
parcel renumbering to consider one of two business renumber parcels as needed.
flows to be selected. The business flow considerations
are as follows:
1.) When a parcel is given a new number, a new
parcel record is created, a genealogy record is
created, all attached tables create a new record and
the attached information is copied to the new record.
(attached information would include attribute data,
2.1.20 people data (owners), situs address and pending 3
Case/Applications/Permits (CAPs). AND optionally
historical cases
2.) Same as Number one except all historical CAPs
(closed CAPs) remain attached to the original parcel
and are linked to the new parcel through the
genealogy table for lookup purposes.
The proposed system when implemented must create a A specified user or use group along with the system admin may
new parcel record when renumbering occurs and copy renumber parcels as needed.
2.1.21 2.1.20#1 all attached data to the new parcel record. 3
The proposed system when implemented must create a A specified user or use group along with the system admin may
new genealogy record when parcel renumbering occurs. renumber parcels as needed.
2.1.22 2.1.20 Only as required by the business workflow. 2
The proposed system when implemented must be able This is another consideration for tracking parcel genealogy.
to perform the grouping of parcels and splitting of
2.1.23 2.1.20, 2.1.22 parcels, following the same considerations as parcel 3
renumbering.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 22 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must be able This is another considerations for tracking parcel changes.
to perform the splitting of parcels: selecting a larger
2.1.20, 2.1.22, parcel to create a group of parcels, following the same
2.1.24
2.1.23 considerations as parcel renumbering. Also allow for 3
comments and reason code.
The proposed system when implemented must be able This is another considerations for tracking parcel changes.
to perform the grouping of parcels: select a group of
2.1.20, 2.1.22, parcels to create a larger parcel, following the same
2.1.25
2.1.24 considerations as parcel renumbering. Also allow for 3
comments and reason code.
The proposed system when implemented must be able When a user is in the CAP they should be able to trace if a the
to perform a genealogy search at the parcel forms level, originating parcel changed.
2.1.26 case/application/permitting level and the GIS level. 2
The system in all situations of renumbering parcels, Meta data for tracking changes is expected.
splitting parcels and grouping parcels, must be able to
record meta data; including but not limited to: creation
2.1.27 date, created by, change date, changed by and include 3
reason codes, comments and descriptions.
IN CITY" codes are used by the City of Fontana to
determine if a property/parcel is in the City portion of
*
Fontana, the County portion of Fontana or in an
adjacent jurisdiction.
Parcel Data & Functionality Criteria
The system‟s Parcel link must allow multiple situs Many address to one parcel
2.2.1 addresses. Primary address flag may be set when there 3
are multiple situs addresses.
Situs Address may be allowed to encompass more than Many Parcels to one address
2.2.2 one Parcel. But records must flag or indicate that it 3
covers multiple parcels.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 23 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must track Be able to pull the data from the UID for reporting purposes.
address History and include fields for: Who created the
address, when was the address record created, active
2.2.3 address flag, outdated address flag, date of changes. 2
Meta data as to when and who changed along with
previous value.
The proposed system when implemented must provide Be able to incorporate the use of ESRI SDE.
2.2.4 a parcel genealogy table to allow for versioning process 3
with ESRI SDE.
The system, must allow for reporting of parcel parent's)
2.2.5
and child history “Parcel Genealogy.” 2
The proposed system when implemented must provide
2.2.6
the following fields for the situs Address:
House Number field
House number fraction field
Street name prefix field
Street name direction field
Street name field
Suite field
City (Defaults to Fontana)
County ( Defaults to San Bernardino)
Zip code ( nnnnn-nnnn) 3
“In City” Code (Whether or not in the City proper or
adjacent county area.)
Comment field
Active/Inactive flag for the address
Address Operand (SFD, MFD, APT etc)
DAB Usage – If business then Business type is
entered.
Bldg. Name/Use
General Notes Field
Inspector’s Map note field
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 24 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system, must allow parcels or parcel The system needs to post when this was updated, by what or
characteristics (in a table) to be flagged or coded to whom and why (i.e., the event that caused the update)
indicate a certain type of build out occurred. For
2.2.7 6.1.38 [1] example: The business work flow suggests when a 2
new structure is completed, the parcel characteristic is
flagged indicating sewer is available for billing and EDU
calculations.
EDU = Equivalent Dwelling Unit used for treatment
[1] calculations.
Parcel / Situs Activity/Event & Attributes:
all of 2, 30.1.2, The proposed system when implemented must have A tool which works with the defined system overall and allows
all of 30.2 the ability to generate activities or event and directly prescribed users to add, modify or delete parcel/situs address
31.1.1 associate them with a parcel and/or situs (UID) . activities. 3
all of 2, 30.1.2, The proposed system when implemented must have A form or format within the parcel/situs address tool and
all of 30.2 the ability to provide the users with a way to act upon parcel/situs address activity tool which allows users to add,
31.1.2 and or review the activities. change or delete activities. 3
all of 2, 30.1.2, The proposed system when implemented must have Only designated users may alter Parcel information and attributes.
all of 30.2 the ability to provide secure access for read, modify or
31.1.3 deletion of parcel or Situs activities. 3
all of 2, 30.1.2, The proposed system when implemented must have Only designated users may alter Parcel address information.
all of 30.2 and the ability to provide designated users with a way to
31.1.4 31.2 add, update or delete related address information to the
3
parcel
all of 2 The proposed system when implemented must allow for Required users have the ability to add necessary business
31.2.1 users to add necessary business attributes to a parcel attributes to a parcel and/or situs record based on a prescribed 3
or situs record. business workflow.
31.1.4 The proposed system when implemented must have A tool is needed when accessing parcels, but a form within a CAP
31.2.2 the ability to provide the users a way to act upon and or form should be accessible to the user. 2
review the attributes.
31.1.4 The proposed system when implemented must have
31.2.3 the ability to invoke secure access for read, modify or 3
deletion of parcel or Situs attributes.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 25 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
Total PARCEL GEO DATABASE Score: - $ -
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 26 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
Permitting: BUILDING & SAFETY PERMITS Bid Ref: 4.1.2
Permitting: BUILDING & SAFETY PERMITS
The proposed system when implemented must This allows users within a building permit to jump to another CAP
integrate planning, fire, permitting, code enforcement to review its particulars. The user needs to be able to open
4.2.2, 5.1.22, and case management capabilities (across all CAP another CAP without having to go to a separate
6.1.1 6.1.2, 7.1.2, types). This allows users within a building permit to program/application. In other words The users do not want to 3
9.1.2, 6.1.42 jump to another application or permit to review its restart another copy of the program or go to a completely different
particulars (details and related ancillary items). program in order to simultaneously open another CAP. (See
6.1.42 for additional specifications)
The proposed system when implemented must have This allows users within a building permit to jump to another CAP
4.2.2, 5.1.22, “out-of-the-box” cross functional processes between to review its particulars. The user needs to be able to open
6.1.2 6.1.1, 7.1.2, planning, permitting, business licensing, trade licensing, another CAP without having to go to a separate 3
9.1.2, 6.1.42 cashiering , application parcel management, fire and program/application. (See 6.1.42 for additional specifications)
code enforcement.
The proposed system when implemented must provide This allows users once they have doe a lookup to be able to jump
parcel lookup based on actual parcel number, address to another CAP to review its particulars. The user needs to be
6.1.3 6.1.4 and/or owner in order to spawn the permit application able to open another CAP without having to go to a separate 3
workflow. This would be a tested based look up vs. a program/application. This would be a text based look up vs. a GIS
GIS lookup. lookup.
The proposed system when implemented must be able This allows users once doing the lookup to be able to jump to
to use GIS for parcel lookup based on actual parcel another CAP to review its particulars. The user needs to be able
number, address and/or owner in order to spawn the to open another CAP without having to go to a separate
6.1.4 6.1.3 permit application workflow. This would be a GIS GUI program/application. This would be a GIS GUI lookup vs. a text 3
lookup vs. a text based lookup. based lookup. (See 8.1.15 for additional comment for GIS
specifications)
The proposed system when implemented must provide A field within a CAP Form may dictate what is allowed in a
conditions (such as based on an expiration date) for subsequent field. Also a CAP form must be able to let the user
processing the CAP based on the permit type. This can know which fields are required before processing can continue.
be considered "enforced field validation" and/or front Required fields are essential for processing and reporting.
end editing. Conditions can include but are not limited
to:
6.1.5 6.1.9
Required date parameters (Rcvd, Final Exp, Any date on the permit defined as required
3
issued, target etc.)
Required fields
A series of tasks/ activities that are tracked as part
of a work flow (E.g.. Do not Close a permit until the 899
have been completed.)
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 27 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must allow A template (CAP) can be created by a designated user and
typical (case, application or permit) templates to be recalled for use in a new CAP. The user may label this template
created and defaults defined by the user. (Example: themselves. The template is to be used as part of a defined
6.1.6 Fence, Block wall, Swimming pool, water heater) business process within the department workflow for generating a 2
new (CAP).
The creation of typical defaults should be allowed
based on security/privileges.
The proposed system when implemented must allow As templates are used to spawn a new permit the user must
the typical template defaults to populate fields when a always have the option of verifying and if need be changing per-
new permit type is created. The fields must be able to populated fields.
6.1.7 6.1.8 be verified by the user at the time the template is used 2
to create or spawn the new permit.
The proposed system when implemented must allow When templates are created for use certain fees can be added
6.1.8 6.1.7 typical templates to include the population of fee types. which will show up on the new permit created from the template. 2
The proposed system when implemented must allow The system would considered any blank "required" field as a
6.1.9 6.1.5 defined fields within various forms to alert the user of constraint and pause continued processing until the fields have 3
“required fields” before proceeding. been provided with correct or meaningful information.
The proposed system when implemented must capture This is information is meaningful to the Building department for
information, which will include, but not limited to the assembling certain types of building permits. The various fields or
following : types of fields apply to certain permits and may not apply to all
permits.
Applicant Name & Address
Project Name and Address and Cross Streets
Type of Application (new building, alteration, etc.)
Type of Use (residential, commercial, etc.)
Type of Permit
Date Submitted
Target Date & Ready Date
Date picked up
Valuation
Contractor ID
Final Inspection Date
Temporary Certification/Certification Date
Parcel Number
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 28 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
Tract & Lot numbers
Owner Information (name, address, phone)
Contact Person (name, address, phone, fax)
Building Construction Type
Floor Areas
6.1.10 3
Building Height
Setbacks
Sensitive areas
Status of Permit
Specific Plan
Code Year
Valuation
Set ID
# of Units
# of Buildings
Bin Number
Stock Plan #
Documents submitted
Number of Stories
Occupancy Class
Census Codes
Number of lots
Grading Area
Paving Area
Bldg Take off info : Plumbing fixtures, HVAC, These are extended lists which are used for information and fee
Electrical fixtures calculations
Bldg Take off info : Swimming Pools These are extended lists which are used for information and fee
calculations
Assigned Bldg Inspector
The proposed system when implemented must allow Based on prescribed business rules, certain fees need to be
fees with corresponding calculations and schedules to applied automatically.
6.1.11 6.1.44 be triggered based on values inserted in the fields of a 3
case/application/permit.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 29 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must provide The users expect to be able to creates an estimate using a
the ability to submit and save fee estimates. defined CAP, they should be able to save the CAP with the fees
applied without the system requiring the fees to be paid or aged.
See all of Estimates may be printed and provided to the customer as an
6.1.12
section 6.3
3
estimate. Estimates may be recalled and a permit generated from
them. (see 6.1.13). See also section 6.3
The proposed system when implemented must provide This essentially is the same as creating a permit with all of the
the ability to create a new permit based on a saved same details but it is identified as an estimate. The details would
6.1.13 estimate. include all of the same details as a real permit along with fees and 3
some activities. This estimate must then be able to be converted
to a building permit.
The proposed system when implemented must allow for The user group or designated users within the group needs
certain users to define permit types in order to creating access to a user CAP maintenance tool in order to edit and add
6.1.14 6.1.16 permits other than those listed below in section 6.1.16. values to this drop down list and other designated item value for 2
This is to allow the user group to control the drop down drop down lists.
value selection.
The proposed system when implemented must This is to be done by an action items list (activity list, to-do list)
automatically notify a designated list of users that the more so than bombardments of e-mails.
6.1.15 6.1.18 case/application /permit is ready for corrections, ready 3
to be issued or additional defined activities (Other
actions required).
The proposed system when implemented must provide The users expect to be able to manage this list within a CAP type.
users with the ability to create various permits. Codes, "No limits on the types that may be defined."
as well as full descriptions, shall be available for the
permit types that include, but are not necessarily limited
to, the following:
Additions / Alterations
Building Permit (general use)
Business License
Commercial Addition
Commercial Building - NEW
Combination Permit
Complaint -- B&S
Commercial Tenant Improvement
Demolition
Electrical Permit
Foundation Only Permit
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 30 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
Fences and Walls
Grading Permit
Industrial Addition
Industrial Building - NEW
Industrial Tenant Improvement
Multi-Family Addition
Mechanical Permit
Multi-Family Building -- NEW
6.1.16 2
Mobile Home Permit
Meter Set/Reset PLUMBING
Patio Cover Permit
Paving Permit
Plan Check Application
Plumbing Permit
PreAlteration
Bldg/Job Card Replacement
Roofing-Re-Roof
Residential Room Addition
Seepage Pit/Field - New or Replacement
Septic Tank/ Seepage Pit System
Sewer Connect to City (County Property)
Converted from Sierra
Sign
Single Family Dwelling - NEW
Swimming Pool/SPA Permit
Title 24 Permit
Temporary Occupancy Permit
Temporary Power Pole/SubPole
Single Family Dwelling - Stock Model
Meter Set/Reset ELECTRICAL
Fee Collection Only
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 31 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must allow The nomenclature for CAP numbering must be such that it is easy
the Land Management system to be flexible in the to determine the type of CAP and the (Calendar) year it was
methods of numbering permits that are supported created. The year of creation has been a long standing
system wide and whether the numbering methods can requirement which was included I all previous systems. The CAP
6.1.17 vary by type of permit. (This would be based on user determination has proved exceedingly beneficial as provided by 3
security allowing specific users within a CAP type the current system. For example, the current system creates a
department to be able to override the default numbering building permit for the year 2009 and the nomenclature for the
sequence) permit begins with "PMT09."
Based on the type of permit, the system should route See notes for this on item 6.1.15). This is an action item list
the permit to the required departments, which need to which contains activities for those departments (or actions for
review the permit (as defined by the user). This routing required departments) which may be accessed for documenting
6.1.18 6.1.15 is really an action item from an activity list that gets the action done and/or needed. There should be a typical 3
populated from an added process or procedures, and is (default) list associated with the types of permits. However, the
correlated to the permit. user must have the ability to add or subtract fro the list.
In the proposed system when implemented the user This process or solution and how it is considered in the proposed
must have the ability to “re-route” plans to appropriate system will need to be explained before acceptance.
6.1.19 departments so that revisions created by one 3
department are sure to be reviewed by other
departments.
For permits that require review by multiple departments, For the most part he users have to be able to see each others
the proposed system must have “routing” features that sign-offs (status along with person date and time)
6.1.20 allow users to determine review status of permit by 3
multiple reviewers.
The proposed system when implemented must allow Special activities added will only be added automatically if the
users to establish default Plan Review Activities, based User group which "Owns" the CAP designates this.
6.1.21 on permit types that are automatically added when a 3
permit is created.
The proposed system when implemented must allow
users to establish default (typical) Inspection Activities,
6.1.22 based on permit types that are automatically added 3
when a permit is created.
In the proposed system, when implemented the user Besides following an established workflow, the user has the ability
must be able to add to the approval/routing list if to add additional like type activities and schedule like type events
6.1.23 additional approvals are necessary. for additional like type work which may be required. An example of 3
this would be subsequent or repeated plan reviews.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 32 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must have This follows a workflow processing scheme where certain
the ability to add users to the routing processes based conditions can be set as to whether or not additional activities
6.1.10, 6.1.14, on information on the permit (e.g., “Route all (whether or not they are approvals) are required.
6.1.24
6.1.31 commercial tenant improvement permits with a 3
valuation over $20,000 to the Traffic division of
Engineering”).
The proposed system when implemented must have The user with the necessary privileges can open the CAP and
the ability to track review activities/tasks and comments review activities associated with the CAP.
made by in-house staff, including the complete text of
letters sent to applicants attached to the permit.
6.1.25 3
The proposed system when implemented must allow The holds can be anywhere from ordinance situations, Fees dues
the users able to place “holds” or post “notices” or or other conditions.
otherwise stop a permit from being issued until the
applicant complies with specific condition (s).
6.1.26
The proposed system when implemented must allow The users needs to see an indicator on the parcel as it is queried
3
for a substantially visible flag on various forms for for use to start a new permit showing them there is a hold or other
permits. defined condition.
Red, Green, Yellow, flag or stop light on the permit There needs to be an indicator on the permit
form and important fields.
Within the proposed solution and system The Form (the user window or screen) can only be changed by
implementation the permit form (or better stated CAP the system administrator. Some field drop down lists may be
form) may allow changes by designated in-house changed by a designated user within a department group.
6.1.27 users (agency employees). However forms, fields and 2
permit types should only be added/changed based on
the users security.
The proposed system when implemented must have The integration level can occur by various types of association
integrated planning, development, permitting, and case such as UID, Parcel, Address, Project name/number etc.
management capabilities within a single application
6.1.28 (application is defined as a software solution or it's sub- 3
module designed for the particular function) .
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 33 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must allow When the user attaches an external file it is essential to the
external documents to be attached/associated with the business processing of the CAP. Once attached other users
permit. This includes but is not limited to, Laserfiche should be able to see the attached list and when necessary open
6.1.29 6.1.29a documents, MS Word Files, MS Excel Files, Adobe for view and or update (provided they have the correct privileges) 3
Acrobat (.PDF) files, JPEG files, GIF files, TIFF files, the attached documents.
MPEG files, MOV Files and AVI files.
The proposed system when implemented must allow When the user attaches an external file it is essential to the
the users to use template documents in the format business processing of the CAP. Once attached other users
listed in 6.1.29 and create external documents to be should be able to see the attached list and when necessary open
6.1.29a 6.1.29 attached/associated with the permit. for view and or update (provided they have the correct privileges) 2
the attached documents.
The proposed system when implemented must have A designated user can set the conditions for a CAP type.
6.1.30 the capability to build and maintain a user-defined 2
condition library.
The proposed system when implemented must include Be able to list and/or report all activities related to a project. Other
a complete project history including reviews, historical information may be required such as where the permits
6.1.31 inspections, conditions, and fees. were generated from (see 6.1.43) 3
The proposed system when implemented must allow " .. But not limited to!"
users to easily lookup the contact information for a
project or planning/case. Contact information must
include but not limited to the following fields:
Company Name
Role (Contractor, Architect, Emergency Contact
etc.)
Type of Business
Link to business license screen
Contact person (s) full name fields
6.1.32 Primary contact indicator (along with secondary) 3
Company address
Contact Phone 1 (Designate Land line or
Cell/mobile)
Contact Phone 2 (Designate Land line or
Cell/mobile)
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 34 of 104
City of Fontana
6.1.32
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) 3
Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
Contact Phone 3 (Designate Land line or
Cell/mobile)
Contact‟s FAX Number
E-mail 1
E-mail 2
The proposed system when implemented must be able Designate a person associated with a case as having multiple
to assign multiple roles to a person/people attached to roles.
6.1.33 a case/application /permit without having to re-enter the 2
same information for each role type.
The proposed system when implemented must When a parcel is renumbered all attached items most follow the
automatically, change all of the existing parcel link new number
6.1.34 information (Parcel table, site address, table attached 3
case table, owner table etc.) to support the new parcel
information.
The proposed system when implemented must allow Valuations must be able to be set up by the users. Valuation rates
the valuation calculator to build the valuations based along with multipliers and field lookups must be included valuation
upon multiple construction types, occupancies, floor calculations.
6.1.35 9.1.21 areas etc. 3
The proposed system when implemented must Certain users with an acceptable privilege for specific CAP types
6.1.36 optionally allow the user to number the permit instead of may override the auto numbering of a CAP. 2
using auto-numbering.
The proposed system when implemented must be able The uses can create a to-do list which acts as a superficial
to provide a „To-Do-List‟. The conditions and checklist more so than a controlling list.
6.1.37 parameters should be set conditions for users to 2
configure what goes in to the list.
The proposed system, must allow parcels or parcel An indicator of some type perhaps a flag in a related parcel table
characteristics (in a table) to be flagged or coded to needs to be set so there is an indication that subsequent work
indicate a certain type of build out occurred. For may occur.
example: The business work flow suggests when a
new structure is completed, the parcel characteristic is
6.1.38 2.2.7 flagged indicating sewer is available for billing and EDU 2
calculations. This should occur when a specific type of
building permit is finalized. EDU = Equivalent Dwelling
Unit used for treatment calculations.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 35 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must provide The users expect to be able to have a search function which
the users the ability to search (Active Filter list) for a allows them to search for specific type of Cap based on the fields
single or group of CAPs based on field values (Partial used with that CAP type.
6.1.39 6.1.40 field values). In other words be able create a search list 2
based on matching the criteria from values of field
within the various CAP forms.
The proposed system when implemented must provide For the various search functions the user must be able to take the
search or filter lists which may be extracted for external produced list and extract it if needed.
reporting. This will include searches by any case (CAP),
Specific CAP Field values for particular CAPs, parcel,
6.1.40 6.1.39 Address, people or role types, activities, conditions, 2
valuations, mechanical items or fees (applied, due
and/or paid).
The proposed system when implemented must provide The Date fields include: Received date, Issued Date, Expiration
search or filter lists which may be extrapolated when Date, Completion/Closed date. Creation Date and Updated date.
selecting as filter criteria the main date fields within the
6.1.41 6.1.40, 6.1.39 permit. The date fields may be searched by a specific 2
date or a date range.
6.1.40, 6.1.39, The proposed system when implemented must allow The Date fields include: Received date, Issued Date, Expiration
6.1.42 6.1.1, 6.1.2 user the ability to view all CAPs (with their related Date, Completion/Closed date. Creation Date and Updated date. 3
information) for any specified parcel.
6.1.31 The proposed system when implemented must allow The Date fields include: Received date, Issued Date, Expiration
6.1.43 user the ability to view all CAPs (with their related Date, Completion/Closed date. Creation Date and Updated date. 3
information) for any specified parcel.
The proposed solution and system must allow a way for A way to see a logical flow of how this fee works.
the "system admin" and "super-user" to document the
6.1.44 6.1.11 business workflow of some of the more complex fee 3
business logic and fee schedules.
The proposed system when implemented must provide Provide a search list of cases based on given case applied fee
the users with the ability to search (Active Filter list) for records and paid fee records search criteria.
6.1.45 a particular or group of Engineering CAPs based on 2
applied fees and paid fees.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 36 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must provide Provide a search list of cases based on given case activity/task
the users with the ability to search (Active Filter list) for search criteria.
6.1.46 a particular or group of Engineering CAPs based on 2
activities/tasks.
PERMITS & LICENSES / BUILDING & SAFETY CLONING
The proposed system when implemented must be able Take a host permit and duplicate the information unto a new
to clone a case/application/permit. permit with a new number.
6.2.1 3
When cloning a case/ application /permit the proposed Usually cloning can occur when more than one permit is being
system when implemented must ask the user how created from a "Parent." The cloning operation should ask the
many copies to make. user "How many permits are required?"
6.2.2 3
The proposed system when implemented must ask the During the cloning process we would like the system to pause and
operator/user if they want each copy to use the same allow the user to enter the unique parcel data required.
6.2.3 parcel information as the source case/application/permit 3
and allow for an itemized parcel number change if
otherwise.
The proposed system when implemented must move all
the essential fields from the source
6.2.4 case/application/permit to the newly cloned 3
case/application/permit. (See sections 6.1.10, 6.1.14,
6.1.31)
The proposed system when implemented must move all Calculated fees must clone. Payments should never clone.
the essential case fees and case fee details. This
6.2.5 includes the amount due information. This excludes 3
any payment records.
The proposed system when implemented for the The default receive date will be the date of he cloning. However
cloning process will use a permit status default of the process should allow the user to override this date.
"Received." The received date field will be the current
6.2.6 date but may allow the user to alter the date. The meta 3
data for the creation date will be the current date.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 37 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented for the The "Received by" will use the username /initials of the person
cloning process will use the current username (person doing the cloning. The meta data will use the current date and the
6.2.7 doing the cloning) for the "Received by" field and meta username/initials of the person doing the cloning. 3
data field for "Created By" and "Updated By"
The proposed system when implemented for the prescribed activities and to do lists should be able to be cloned.
6.2.8 cloning process will allow prescribed activities to be 3
moved as well but show them as unresolved.
The proposed system when implemented for the A cloned permit must indicate the parent permit which was used
cloning process will populate the field (Parent Permit) for its creation.
6.2.9 within the permit which indicates what permit the newly 3
created permit was cloned from.
The proposed system when implemented for the The user creates a parcel list (UID list). From which a subsequent
cloning will provide a setup utility which maybe used by cloning run is generated. Besides providing auto numbering the
the user to setup a run for their cloning process. This cloning mechanism will read the parcel (UID) list and use this
6.2.10 would allow the user to enter a list of parcels (UID) that information for the parcel (UID) instead of the one from the cloned 2
the cloning processor would use to pre-populate the parent.
permits as it proceeds.
Permitting: Plan Check (Formerly BUILDING & SAFETY Estimates & Review)
The proposed system when implemented must be
flexible in the methods of numbering permits and
6.3.1 whether the numbering methods can vary by type of 3
permit.
Based on the type of permit, the system should route
the permit to the required departments, which need to
6.3.2 review the permit (as defined by the user). Please 3
describe if necessary.
The proposed system when implemented must allow When the permit is a Plan Review/Check, once added the
users to establish default Plan Review Activities, based activities list has inserted automatically those additional plan
6.3.3 on permit types that are automatically added when a review or approval activities. 3
permit is created.
The proposed system when implemented must allow This may be a To-Do list and inserted as a list and/or
users to establish default (typical) Inspection Activities, unscheduled activities. This allows the user to report to the
6.3.4 6.4.2 based on permit types that are automatically added customer what typical inspections are going to be required. 2
when a permit is created.
The proposed system when implemented must allow for Approvals are seen as activities added to the CAP (Permit). The
6.3.5 the user to add to the approval/routing list if additional activities are selected activities provided to the user in order for 3
approvals are necessary. them to choose necessary approval items.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 38 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must allow
6.3.6 estimates to pull from the full fee schedule. 3
The proposed system when implemented must allow
6.3.7 estimates to be printed in an expedient fashion at the 3
front counter.
The proposed system when implemented must allow
estimates to be retained if the user desires. This will be
6.3.8 in order for the user to re-call the estimate and generate 3
a new permit from the estimate.
The proposed system when implemented must provide
6.3.9 the same fee structures as the building permits. 3
The following section 6.4.0 pertains to all aspects of the
proposed system which would need to schedule
6.4.0 inspection activities for all groups including but not PERMITS & LICENSES / BUILDING & SAFETY INSPECTION SCHEDULING
limited to : Building and safety, Planning, Engineering,
Code Enforcement and Fire.
The proposed system when implemented must allow
inspection requests for Building and Safety Permits to
be entered using the following:
Front Counter client interface
WEB interface for remote/field inspection
applications
WEB interface for client/customer inspection
6.4.1 adds and inquiries 3
IVR (Integrated Voice Response) system.
Activity driven process
Event driven process
During CAP Generation
During CAP Updates
During CAP Activity Scheduling
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 39 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must allow for When so desired by the user, arguments (field values) within the
typical inspections to be listed (but not scheduled) on a building permit when taken as a whole, may be used as a way to
permit which is based on the permit type. determine what types of building inspections could be needed.
The user may then insert these without scheduling them or a need
to schedule them (almost as a to-do list). The inspections are
not inserted so much for scheduled tasks/activities as they are
6.4.2 6.4.5, 6.3.4 3
there as a way for the initiating user to inform the customer what
typical type of inspections may occur. Then later the "To-do"
inspection activities may selected and then placed for scheduling.
The proposed system when implemented must provide This requirement/specification must work both in the office and
users utilizing any particular CAP inspection activity the out in the field.
ability to allow inspections to be checked for:
Previous inspections (has this inspection been list inspections related to the CAP
done before)
Conditions on previous inspections (did a
pervious related inspection pass/fail)
Permit holds( are there general permit holds or
previous inspection holds)
6.4.3 3
Hierarchical inspections ( inspection needs
completion before another is scheduled)
Enter a series of related inspections.
Did a previous inspection spawn the new allow re-inspection and rescheduling
inspection as a re-inspection or rescheduled inspection.
See notes added to inspection activities See notes applied to the inspection activity by any user
Fees Owed (due) note any fees due
Code Enforcement holds on the parcel check for parcel holds
The proposed system when implemented must allow (designated) users should be able to override conditions or
privileged (designated) users the ability for them to hierarchical constraints. This is per CAP.
6.4.4 override conditions or hierarchical constraints 3
The proposed system when implemented must allow This allows for the reduction of morning scheduling. This would be
inspectors to be automatically assigned in at least one a daily step done first before manual scheduling is done.
of the following ways.
By Tract/lot number
* 3 = Included in delivered system
2 = Program modification (at cost)
6.4.5 6.4.2, 6.5.12 1 = Workaround 3
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 40 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST of morning scheduling. This would be
This allows for the reduction
a daily step done first before manual scheduling is done.
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
By address
By permit number
By Project Number
6.4.5 6.4.2, 6.5.12 By a unique Inspection zone 3
Parcel contains the inspectors ID Code
A field in the permit contains the inspectors ID
Code
If the above two are blank then the system
checks to see who the last inspector was
If all of the above are blank then it is assumed
the inspector is manually scheduled
The proposed system when implemented must allow for A prescribed user and/or user group should be allowed to do this.
non-working days to be entered as part of a calendar This should not necessarily be a system admin function. IVR will
check feature. This would tend to be a global setting. use this too!
6.4.6 6.4.7, 6.4.15 This calendar feature would not allow the system set 3
the schedule dates for activities on a non working days.
The proposed system when implemented must allow Any activity entered on any calendar day will (by default)
inspection tasks/activities to be scheduled automatically automatically use the next working day as the scheduled date.
on the next working day unless otherwise designated by The exception is when the activity/task has a "schedule" lead time
6.4.7 6.4.6, 6.4.15 the user. Thus scheduling around „Non working days‟ as (just like the current system). 2
mentioned in section 6.4.6.
The proposed system when implemented must allow
6.4.8 inspection tasks/activities to be entered using a thick 3
and thin client (Web) interface.
The proposed system when implemented must allow
inspection tasks/activities to be assigned to an
6.4.9 inspector using a thick and thin client (Web) interface. 3
The proposed system when implemented must allow
6.4.10 6.4.16, 6.4.19 inspection tasks/activities to be scheduled using a thick 3
and thin client (Web) interface.
The proposed system when implemented must allow
the user to list inspections for a specific date containing
the following and allowed sorting (ascending/
descending) by the following as well:
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 41 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
Inspector ID (Code and/or name) with description
Permit Number
Parcel ID
Address
Tract & Lot
6.4.11
Inspection Type 3
Any existing status codes including blank and
null values
Listed contacts
Owner or Contractor
Inspector
Inspection Area
Permit Type
Date (date entered, date scheduled and status date)
The proposed system when implemented must allow for Stated fields must be available for system, business and audit
all fields associated with an inspection to be reported on reporting specifications stated in the "reporting" specifications.
6.4.12 for the following: tasks list, trend analysis, inspection 2
status and workload analysis (with time parameters and
inspector parameters).
The proposed system when implemented must be able Insert status and validation arguments along with dates into fields
6.4.13 to automatically change a status based on the results of within the actual CAP. 3
specified inspections.
The proposed system when implemented must allow for Allow users to insert activities/tasks/events as this is more the
manual assignments of an inspection besides expected norm than to have them automatically entered.
6.4.14 6.4.5 automatic assignments as listed in section 6.4.5. 3
The proposed system when implemented must be able We will be sticking with Selectron's IVR system
6.4.19, 6.4.6,
6.4.15 to work with the City's existing Selectron IVR system. 3
6.4.7
The system‟s GIS solution should allow for the plotting Show visually on GIS inspections.
6.4.16 of inspections that are assigned to an inspector or field 3
crew.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 42 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must provide The To-do list can be typical but allows users to add, change or
a „To-Do-List‟. The „To-Do-List‟ would be a list of items delete items. These in turn reference activities/tasks/events and
that would need to be completed for the specific type of their status.
building permit. The list is really a high-light. The list
should be able to be populated based on conditions
6.4.17 (parameters) which or items include in the permit 2
including the permit type itself. The conditions and
parameters should be set conditions for users to
configure what goes in to the list.
The proposed system when implemented must allow for The users (designated user or user group) should be allowed to
preset correction /result codes for reviews and maintain this along with the system admin.
6.4.18 inspections. This must reference a validation table (s). 3
This must be configurable by a „super-user.‟
• The proposed system when implemented must allow We will be sticking with Selectron's IVR system
6.4.19 6.4.15 Inspection tasks/activities to be scheduled using the 3
City's existing Selectron IVR system.
The proposed system when implemented must allow As a group the inspectors would be able to schedule their groups
each inspection group to be able to schedule their inspection activities amongst each other for any given day.
6.4.20 6.4.5 groups inspection activities amongst each other for any 3
given day.
The following section 6.5.0 pertains to all aspects of the
proposed system which would need to provide field
6.5.0 inspection activities for all groups including but not Permitting: BUILDING & SAFETY FIELD INSPECTIONS
limited to : Building and safety, Planning, Engineering,
Code Enforcement and Fire.
The proposed system when implemented must allow
inspection requests for Building and Safety Permits to
be entered using the following:
6.5.1 WEB interface for remote/field applications by an 3
inspector (user)
VPN client through remote server with
application support for inspectors (users)
The proposed system when implemented must allow for
typical inspections to be listed (but not scheduled) on a
6.5.2 permit which is based on the permit type. 3
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 43 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must allow for
inspections to be checked for:
Previous inspections (has this inspection been
done before)
Conditions on previous inspections (did a
previous related inspection pass/fail)
Permit holds( are the general permit holds or
6.5.3 previous inspection holds) 3
Hierarchical inspections ( another inspection
needs completion before another can be scheduled)
Enter a series of related inspections.
Fees Owed (due)
Code Enforcement holds on the parcel
The system will allow privileged users to override
6.5.4 conditions or hierarchical constraints using a Web 3
interface.
The proposed system when implemented must allow
the inspector (user) to list inspections for a specific date
containing the following and allowed sorting (ascending/
descending) by the following as well:
Inspection ID (Code and/or name) with description
Permit Number
Parcel ID
6.5.5 Address 3
Tract & Lot
Inspection Type
Any existing status codes including blank and
null values
Listed contacts
Owner or Contractor
Assigned Inspector
Inspection Area (Zone)
The proposed system when implemented must provide
6.5.6 a thin client – web browser based interface which may 3
be used in the field.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 44 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The web browser based format must be able to be used
6.5.7 6.5.8 on a Tablet PC and or Panasonic power book. 3
With the Web based interface on a Tablet PC and/or be able to see case information, related details and
Panasonic power book, the proposed system when activities/tasks/events.
implemented must allow the inspector (Any inspector
using activities from implemented CAPs which are
designated for field use ) the capability to look up
6.5.8 6.5.7 building permit details, application details, case details, 3
people information (contacts), review parcel data text,
other activities/tasks/events and check inspection
history.
The proposed system when implemented must allow
the building inspector while out in the field to open a
permit and view all aspects of any permit.
6.5.9 3
The proposed system when implemented must allow for This would be a Pin member and password secure site which
the creation of and maintenance of an inspection Web allows the city client customer to login and schedule a needed
page for the citizen and outside developer/contractor inspection.
users. Access to this Web page must be able to:
Provide secure and limited access for this function
only!!!!!
Allow access to inspection information only.
Allow outside user to schedule an inspection
Allow outside user to view inspection schedule
6.5.10 6.4.6, 15.1.4 2
(select and add)
Allow outside user to change dates of a future
inspections ( avoiding non-working days)
Allow the outside user to post a note onto the
inspection.
Allow the outside user to re-schedule existing
inspection needed. (simply click on he failed inspection
and the system reschedules it).
Security must provide a pin number access (this
would be from the people or customer table).
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 45 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must allow for This is a designated list for each inspection for each
6.5.11 preset correction /result codes for reviews and corresponding CAP. 3
inspections.
The proposed system when implemented must take the Permits based on prescribed criteria can be "assigned" to an
first assigned inspector of an inspection and add the inspector.
inspector code (i.e.. initials) information to the permit
(as the assigned inspector). This will be for lookup
purposes in order to identify the permit with the
inspector. The system also needs to utilize this same
6.5.12 6.4.2, 6.4.5 3
information and apply it to subsequent incoming
inspections. This will reduce the time spent reassigning
inspectors to inspection loads (which presently occurs
on a daily basis.
The proposed system when implemented must provide The building inspector supervisor needs to be able to view any
a tool which allows for inspection supervisors to view inspections that may have been missed.
6.5.13 any latent or missed inspections. 3
The proposed system when implemented must provide
the capability for field inspector's to add additional or
6.5.14 6.5.9, 13.1.11 update contact information. This generally names, 3
emails and telephone numbers.
Total Permitting: BUILDING & SAFETY PERMITS Score - $ -
Planning Applications Bid Ref: 4.1.3
All business rules and specifications defined for
Building & Safety permits apply to Planning CAPs Planning Applications
as well.
The proposed system when implemented should have We expect the planning users to be able to open any planning
the ability to track a series of dates and findings so that application for view or update. Read only users/subscribers may
the proper or designated users can access these open an application for conditional read of information regarding
5.1.1 records in order to schedule tasks/activities and check the specific application. (conditional read: read only required 3
the status of pre-development tasks/activities. information and exclude exempt information).
The system should capture the following items of We expect the fields listed in 5.1.2 to be included in the form (s).
information related to pre-development: The use of these fields for purposes of fee processing and
reporting will need to be discussed and planned during design
time.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 46 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST in 5.1.2 to be included in the form (s).
We expect the fields listed
The use of these fields for purposes of fee processing and
Compl.
REF # Cross Feature Description
reporting will need to be discussed and planned during design Rating
time. Code*
Reference Cost
Project Description
Application Date
Application Type
Notice of Completion Date
Notice of Application Date
Bond tracking
Dates of Public Comment period, Public Hearing
Date, Time, Place, and Type
Date of threshold determination
Dates of appeal period
Date of Notice of Decision
5.1.2 Expiration Dates 3
Applicant Name and Address
Project Name and Address
Parcel Number, File Number
Zoning Designation/General Plan Designation
Parties of Record (Owner, Developer, Engineer,
etc.)
Project Manager
Owner name and Address Contact People
Plan Status (Active, Inactive, Void, etc.)
Acreage, Lots, Units, Density
Approvals/withdrawals/denials
Flood Zone
School Districts
Plan Check reiterations, versions and resubmittals
The proposed system when implemented must be able
to provide fields for timeline information in order to
create timelines, print reports, send electronic mail
5.1.3 messages or otherwise notify users when deadlines are 2
approaching and indicating that their feedback on a
proposed project has not been entered into the system.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 47 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
Based on the application type, the system should have
the ability to record the department, user or supervisor
5.1.4 whose approvals are required before the application 3
can be finalized.
The proposed system when implemented must have
the ability to electronically “route” the application
information to users whose input (usually provided in
5.1.5 5.1.36 the form of conditions) is required. The routing must be 3
an E-Mail notification along with a task assignment list
entry in the system.
The proposed system when implemented must provide
5.1.6 a memo field of text space for the user to describe each 3
condition.
The proposed system when implemented must provide
a list of “generic” conditions that may be selected from
5.1.7 a pick-list or drop-down box to ease data entry when 3
standard conditions are used.
The proposed system when implemented must allow
each condition associated with the department and/or
5.1.8 user that issued to have a status or condition flag set by 3
the user.
The proposed system when implemented must provide
search capabilities using ad hoc lookups either through
a user configurable browser functions, filter capability
and/or direct field wildcarding. Planning applications
and proposals should provide searching capabilities on,
but not limited to the following items:
Parcel ID Number
Universal ID number
Address
Project name/number
5.1.9 5.1.37, 5.1.38 3
Permit number
Permit type
Applicant/Contract/Owner Name
Application Date
Issue Date
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 48 of 104
City of Fontana
Release Date: 5.1.37, 5.1.38
5.1.9
12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
3
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
Decision Date
Time line to task date
Address (by field Number, Street name, City)
Case/application/permit status
Assigned Planner
In the proposed system implementation users must be By project or by special grouping the user should be able to see
5.1.10 able to query a CAP and list related CAPs that are related CAPs which across multiple disciplines. 3
associated with the same project.
In the proposed system implementation and solution all Holds should be able to be set by parcel, UID, project or CAP
5.1.11 holds to a project should affect related permits based using severity codes. Overrides can be done by specific user, 3
on a scaled severity code. group or needed action.
In the proposed system implementation and solution,
override capability for tasks and permit should be
5.1.12 configurable based on type of permit, type of tasks 3
(process/activity), user and user group.
In the proposed system implementation and solution, Designated users can create new projects. These projects would
projects should be allowed to be changed by users. be a way to group various CAPs and allow users to reference the
5.1.13 However forms, fields and permit types should only be attached CAPs by project number. 3
added/changed based on the users security.
The proposed system when implemented must allow If the user group opts to define a typical CAP as a template, the
typical templates to be created and defaults defined by system should allow this. The template can then be used to
5.1.14 the user. spawn (clone) a particular CAP. 2
The creation of typical defaults should be allowed
based on security/privileges.
The proposed system when implemented must allow
5.1.15 the typical template defaults to populate fields when a 3
new permit type is created.
The proposed system when implemented must provide
5.1.16 dropdown/pop-up windows listing valid values or 3
choices for specific fields.
The proposed system when implemented must allow
5.1.17 typical templates to include the population of fee types. 3
The system should allow projects to be created that are
5.1.18
not associated with a specific parcel 3
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 49 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must provide
a Projects Look-Up window for all fields on the Projects
5.1.19 window that are linked to a corresponding maintenance 2
table.
The proposed system when implemented must allow
users to have the capability to add, update and delete
5.1.20 Project information without exiting the main projects 2
window.
The proposed system when implemented must allow
users the capability to scan through previous and
5.1.21 subsequent projects without leaving the projects 2
window.
The proposed system when implemented must have
integrated planning, development, permitting, and case
5.1.22 management capabilities within a single application. 3
The proposed system when implemented must have
“out-of-the-box” cross functional processes between
4.2.2, 5.1.22, planning, permitting, business licensing, trade licensing,
5.1.23 6.1.2, 7.1.2, cashiering , engineering permits, application parcel 3
9.1.2 management and code enforcement.
The proposed system when implemented must allow
users to easily lookup the contact information for a
project or planning/case. Contact information should
include the following fields:
Company Name
Role (Contractor, Architect, Emergency Contact
etc.)
Type of Business
Link to business license screen
Contact person (s) full name fields
Primary contact indicator (along with secondary)
5.1.24 3
Company address
Contact Phone 1 (Designate Land line or
Cell/mobile)
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 50 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
5.1.24 FEATURE/FUNCTION CHECKLIST 3
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
Contact Phone 2 (Designate Land line or
Cell/mobile)
Contact Phone 3 (Designate Land line or
Cell/mobile)
Contact‟s FAX Number
E-mail 1
E-mail 2
The proposed system when implemented must have This is along the lines of a designated workflow or checklist
the capability to build and maintain a user-defined process. The user may select and control what needs to happen
5.1.25 5.1.26 condition library. next in the workflow sequence and or set up a needed workflow 3
sequence. This in turn must be able to spawn needed activities.
The proposed system when implemented must include The user needs be able to select from predefined status and
5.1.26 5.1.25 the ability for the user to define planning condition declare what is expected or acceptable for approval. 3
statuses.
The proposed system when implemented must include
the ability for the user to decide whether specific
5.1.27 planning conditions can be „inherited‟ by other 3
processes.
The proposed system when implemented must allow
5.1.28
planning conditions to have effective dates. 3
The proposed system when implemented must include
5.1.29 a complete project history including reviews, 2
inspections, conditions, and fees.
The proposed system when implemented must allow
fees with corresponding calculations and schedules to
5.1.30 be triggered based on values inserted in the fields. 3
The proposed system when implemented must have
the ability to void a case/ application/ permit. The
5.1.31 posted case/ application / permit would remain in the 3
system with a void status.
The proposed system when implemented must allow
the user (with appropriate security) to number the
permit instead of using auto-numbering. This would be
5.1.32 an over ride. Typically the default would be to allow the 3
system to automatically number the permit.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 51 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must allow
5.1.33 the user to view/open more than one application at any 3
one time.
The conditions and parameters should be set conditions
5.1.34 for users to configure what goes in to the list. 2
The proposed system when implemented must allow for
5.1.35 preset correction /result codes for reviews and 3
inspections.
The proposed system when implemented must allow for
automatic approval. Routing must be an E-Mail
5.1.36 5.1.5
notification along with a task assignment list entry in the
3
system and based on AD Group policies.
The proposed system when implemented must provide
the users the ability to search (Active Filter list) for a
single or group of CAPs based on field values (Partial
5.1.37 5.1.9, 5.1.38 field values). In other words be able create a search list 3
based on search matching search criteria based on
values on the various CAP forms.
The proposed system when implemented must provide
search or filter lists which may be extracted for external
reporting. This will include searches by any case (CAP),
Specific CAP Field values for particular CAPs, parcel,
5.1.38 5.1.9, 5.1.37 Address, people or role types, activities, conditions, 3
valuations, mechanical items or fees applied, due
and/or paid).
The proposed system when implemented should have
the ability to track activity and lookup application
5.1.39 assignments based on assigned tasks and assigned 3
planner.
The proposed system when implemented must provide Provide a search list of cases based on given case applied fee
the users with the ability to search (Active Filter list) for records and paid fee records search criteria.
5.1.40 a particular or group of Engineering CAPs based on 3
applied fees and paid fees.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 52 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must provide Provide a search list of cases based on given case activity/task
the users with the ability to search (Active Filter list) for search criteria.
5.1.41 a particular or group of Engineering CAPs based on 3
activities/tasks.
Facilitates accurate accounting of past and present
plan review workload thereby enabling an effective
4710
projection of workload in order to project plan review
3
appointments with applicants.
Capable of assisting plan review staff in the
preparation and organization of plan review lists,
4720
providing general code review guidelines upon
2
completion of basic input on any given project.
Calculates plan review fees for each stage of the review
4702
process based on rules defined for each type of plan.
3
Capable of combining multiple building/projects on one
4705 plan review application although permits will be issued 3
independently.
As part of the application routing/approval process,
19587 committee reviews and comments can be recorded as 3
part of the application history.
Facilitates efficient data entry process for projects
containing multiple structures with slightly different
4706
characteristics, i.e. building plan, address, etc.
3
WITHOUT reentering common data.
Facilitates an efficient plan review submittal process for
all types of applications, i.e. building, plumbing,
4715
electrical, mechanical, grading and fire sprinkler
3
submittals.
Interacts with Planning, Engineering, Building & Safety,
Code Enforcement, Fire District plan review tracking
4709
modules in order to establish accurate status of any
3
given project.
Establishes bonding, easement, legal document, etc.
4713 needs and tracks such through the plan review, 2
construction and archival.
Generates fees estimates for plan check, permit and
4701
related development fees.
3
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 53 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
Can generate plan identification labels (multiple copies)
4704 so they can be affixed to multiple documents and 2
folders.
Facilitates the generation of all applicable notices and
4717 mailing labels/envelopes, i.e. expiration or status, of 3
plan check activity.
Generates reporting of plan check activity, i.e. daily,
4718
weekly, monthly, quarterly, semiannually and annually.
3
Interact with development review system and parcel
4698 information system in order to extract pertinent data 2
regarding projects submitted for plan review.
Interacts with City's Finance system, in real time, in
order to eliminate redundancy in reporting. Also must
4700 facilitate an electronic accounting of application prior 2
to, and during, the actual submittal process. Generates
plan review receipt only upon payment of fees.
In order to reduce workload redundancy on the
4719
preparation of plan check correction lists.
2
Interacts with and provides the basis for the permit
4714
issuance process.
3
Initiate plan routing process to all affected City
4708 departments, divisions, consultants and outside 3
agencies.
Facilitates quick retrieval of permits, plans and retained
documents based upon location, type, inspector, plan
4801
checker, owner, architect, contractor, subject, key
3
word/phrase, etc.
Capable of retaining plan submittal information without
fee payment or generation of receipt until such time as
4707 the applicant can return with payment. Able to generate 2
a 'transaction' record without actual plan check number
assignment.
Capable of producing a recommended schedule of
4711
plan review meetings with applicants.
1
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 54 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
Facilitates standard plan review submittal info process
which notifies applicants of deficiencies at the earliest
4712
possible step. Produces notices of additional needs
3
and requirements on plan check receipt.
Facilitates supplemental plan review activities and ties
4716 all subsequent work back to the original application 3
and/or land parcel.
Ability to track developer-constructed public works
improvements from Plan Check through construction &
4682 inspection to acceptance by the City. Improvements 3
include streets, storm drains, curb, gutter, sidewalks,
landscaped areas, and parks.
Report showing all active projects and a brief summary
19594
of their current status in the review/approval process.
2
List Planning Projects for any street range
19591 (alphabetically), separate page for each new alpha 2
letter.
Report showing pending projects and what state they
19593
are in awaiting review.
2
Ability to print a schedule of all past, present, and future
19592 (if available) Planning Commission hearings for each 2
application/project.
Total Planning Applications Score - $ -
GIS: Bid Ref: 4.1.4
GIS:
The City of Fontana is an ESRI Product environment The users and in-house development group expect the new
using Arc SDE/ArcServer Advance 9.3 and Mobile GIS system to work cohesively, seamlessly and easily with the In-
as the enterprise database residing in Microsoft SQL house Arc SDE/Arc Server environment.
8.1.1 Server. The proposed system when implemented must 3
support a two-way interface with this environment.
The proposed system when implemented must use Arc The users and in-house development group expect the new
8.1.2 SDE as the Enterprise database version 9.3 ( or latest system to work cohesively, seamlessly and easily with the In- 3
version ) house Arc SDE database environment.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 55 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must not
require modification of the base GIS layer for records.
8.1.3 Whenever location oriented records are added to the 3
database, they must be automatically associated with
the base map.
In the proposed system when implemented, current
permit information must always be up to date and
8.1.4 accessible through the GIS component without the 3
need to go to the GIS department for digitizing.
In the proposed system when implemented, the
system's GIS functionality must allow the user to work
8.1.5 with (from) multiple maps. The user must be able to see 3
multiple layers.
The proposed system‟s GIS functionality must allow the
user to create a list of related parcel data (including
8.1.6 owner information, address information and permit 3
information).
The proposed system when implemented must allow
the user to do this using any part of the address as
8.1.7 2.2.5 defined by the Situs address (section 2.2.5) 3
The proposed system when implemented must allow
8.1.8 the user to query Parcel(s) using the GIS system 3
component.
The proposed system when implemented must allow
the user to query Parcel(s) based on specified fields of
the parcel table (example: zoning, utility districts, Land
8.1.9 2.1.15 use Attributes) using the GIS system provided GIS 3
component. (see section 2.1.15)
The proposed system when implemented must be
allowed to be used as the database container for a third
8.1.10 party interface for the City's Weed Abatement System 2
(CEGIS/WAMS) using Microsoft Dynamics CRM 4.0.
The proposed system when implemented must allow a
8.1.11 user to open an existing case/application/permit from 3
the GIS interface.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 56 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must allow a
user to open a form to create (start) a new
8.1.12 case/application/permit from a GIS interface search and 3
parcel select.
The proposed system when implemented must allow a
8.1.13 user display case/applications/permits on a GIS map 3
based on query criteria.
The proposed system when implemented must allow
map location of permit(s) based on address encoding,
8.1.14 or by matching parcel, parcel info., building info, or 3
Owner.
The proposed system when implemented must The system and provided GIS context need to remain in sync.
8.1.15 synchronize properties between the maps and the 3
forms/data screens for each CAP.
The proposed system when implemented must allow
8.1.16 aerial photography to be seen as a layer on the maps. 3
Total GIS: Score - $ -
Fees Maintenance and Fee Processing Criteria Bid Ref: 4.1.5
Fees Maintenance and Fee Processing Criteria
Within the proposed system , Fee records must be able
to be defined on how the fee is used:
4.1.1 This is defined by the permit type, parameters within the 3
permit and stand alone fees for miscellaneous cashier
transactions.
Within the proposed system, Fees must include
effective dates.
The effective dates must be able to check the specified Calculation records should be able to be entered using current
date on the permit as the parameter: (Example: a and future dates for changes of fee amounts and/or fee
Receive date, an Issue Date, a plan check date). arguments.
Fees should check a fee calendar table for
4.1.2
effective value
3
(Example: the new fee value after this date is $x.00 or
after a target calendar date increase the base fee by 2
%.)
Add a retro reference to older fees based on a
development agreement and the development
agreement date.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 57 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
Within the proposed system, the fee tables when Fees need to be calculated based on scale (schedule) which uses
applying fees must include a sliding schedule for fee an amount for a determining operand.
application to a permit:
Example: (Sq feet <= 2,000 charge $.25/sq foot, Sq
4.1.3
feet > 2,000 but <= 3,000 charge $.225/sq foot etc). 3
Sliding fee table should include minimum and maximum
parameters for fee application
Fee schedule should also include a base fee.
Within the proposed system , working along with a fee discounts must work with existing calculations and use a verbose
schedule there should be a discount table that can be argument to determine whether discount is needed.
checked
4.1.4
Discounts can be based on specified quantity for a
3
field within the permit, zone, area, land use or
Developer agreements.
Within the proposed system there must be the ability for Run a batch which adds specific fees to and arrangement (group
batch fee processing: of) CAPs (of the same type) by adding the fee and adding an
activity to t each affected CAPs activity list.
Batch add fees to a group of permits based on a
set-id
4.1.5 Batch change fees to a group of permits based on 3
a set-id
Batch delete fees to a group of permits based on a
set-id
Batch delete fees to a group of permits based on a
set-id
Within the proposed system, fee data records need to Besides the fields listed in the requirements the fees must also
include descriptions, title of the fee, applied permit type, include, receipt number field for the cashiering system, audit
applied template permit type, department use code, control number, reason code (for audit control payments, credits
4.1.6 amount of the fee, amount paid against the fee, credits or refund), transaction code, fee group code, update date, 3
(marked as credits), refunds (marked as refunds) and updated by.
General ledger revenue accounting code.
Within the proposed system, as fees are paid via a The user and/or system admin should be able to trace an
cashiering module, a transaction record must be itemized transaction back to the receipt, back to the CAP fee
created which shall be used for a creation of a receipt. records and back to the CAP.
4.1.7 Paid fees must be indicated in the case, application or 3
permit. History of paid transactions must be searchable.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 58 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
Within the proposed system, paid fees must be able to When a user is in the CAP they should be able to determine what
be seen from within the permit. This would be to allow has been paid (an how much) and what is owed (and how much).
4.1.8 the user to determine if appropriately applied fees are 3
paid if required for any next steps in processing.
Within the proposed system paid fees should post to a As items are paid this will show on an internal G/L. The G/L is
G/L which would comprise of an internal set of tables. also referenced for "Trust or On Account" conditions.
This group of tables would be part of the newly acquired
4.1.9 permitting system and would be included in the 2
installation of this same system This would be used
primarily for reporting, secondary audit and payment
transaction history.
Within the proposed system fees (whether line item or Clone the fees but not the payments.
formulated) applied to a case/application/permit must
4.1.10 be able to be cloned after being applied to a master 3
permit or template permit.
Within the proposed system, fee maintenance (fee cost Certain fees such as flat fees and valuation items should allow for
schedules, lookup field values, price indexes) should be controlled access for updates by a specified user from the
restricted to system users and defined super-users. general user community or from a control group.
Meta records would be required for user changes of
4.1.11 certain fields. 3
The proposed system when implemented must provide See notes on 4.1.6 - 4.1.10
a paid fees table to record payments against Cases,
Applications, permits and objects (Objects would
include names from a peoples directory within the
4.1.12 system, payable objects not associated with a 3
case/application/permit such as a passport fee, dog
license fee, parking fee, parking ticket or a general
ledger).
The proposed system when implemented must allow The fee transactions (possibly showing on a receipt can easily be
the paid fee record to include all fields listed in the traced to the permit and fee line items.
4.1.13 4.2.28 transaction table. (the transaction table would be the 3
table (s) recording payment and credits) (See item
4.2.28)
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 59 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must be able If a permit is paid and ready for invoicing the a zero balance due
to automatically change a status of a may (but not allows) be allowed to spawn a permit (CAP) print
4.1.14 case/application/permit based on payment of fees activity and change of status. 3
and/or zero balance due.
The proposed system when implemented must provide Paid fees should not be allowed to be arbitrarily changed.
security and business flow checks to avoid transactions
4.1.15 from resetting paid fees to unpaid. 3
Cashiering module needs to allow the user to enter a
transaction date (manually applied date by the user) for
the drawer. Dates records must include the transaction
date set by the user and the actual date from the
4.1.16 4.2.11, 4.2.12 system. Both dates, the manually applied date by the 3
user and the system date must be recorded in both the
paid fees table for the permit and the transaction table.
The cashiering module must allow for adjustments to
4.1.17 refunds and payments made to a specific GL account. 3
The proposed system when implemented must allow
4.1.18 the fee definitions to contain „terms‟ (30 day, 90 day, 3
180 day etc.)
The proposed system when implemented must be able
to process and print statements/mailers for fees
4.1.19 4.1.18, 4.1.20 due/owed and age them based on terms (see section 3
4.1.18)
The proposed system when implemented must be able
4.1.20 4.1.18 to age fees based on terms and add penalties if 3
required.
This is a defined series of tables developed and design based on
The proposed system when implemented must provide total specifications provided for the project.
an independent series of tables within the database
4.1.21 which are used for defining the fees for systemic 3
purposes. These are not to be confused with the actual
fee tables which would be used for processing fees.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 60 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must with the Fee Definition is done through a System Admin tool. During fee
provided definition tables, include a table which is used definition and subsequent maintenance of the fee, The Start and
4.1.22 for general definition of a fee. This table must contain End dates must be clear fields which can be modified as needed. 3
Start and Ending dates as a control parameter. These fields control the use of the fee.
4.1.21
The proposed system when implemented must with the Maintain a revenue account field
provided general definition table contain a field for
4.1.23 inserting a revenue account number which matches a 3
current revenue account number on an existing
4.1.21, 4.1.22 Financial system.
The proposed system when implemented must with the Updated by: date and person, Creation date *(When added to
provided general definition table contain fields for the system)
4.1.24 simple meta-data: This would include creation date, 2
last update date and updated by whom.
4.1.21, 4.1.22
The proposed system when implemented must with the Default Amount field
provided general definition table contain a field which
4.1.25 would contain a default amount for purposes of a flat 3
4.1.21, 4.1.22 fee.
The proposed system when implemented must with the Minimum and Maximum amount fields
provided general definition table contain " minimum and
4.1.26 maximum amount" fields which would be used to 2
control user input for manual fees and manual
4.1.21, 4.1.22 overrides.
Total Fees Maintenance and Fee Processing Criteria Score - $ -
Cashiering and Fee G/L Bid Ref: 4.1.6
Cashiering and Fee G/L
The proposed system when implemented must have The cashiering and GL functions is meant to be used for all
integrated planning, development, permitting, code implemented and developed CAPs.
4.2.1 enforcement, utility billing, Miscellaneous A/R and case 2
management capabilities.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 61 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must have
“out-of-the-box” cross functional processes between
4.2.2, 5.1.22, planning, permitting, business licensing, trade licensing,
4.2.2 6.1.2, 7.1.2, cashiering , application parcel management, utility 2
9.1.2 billing, Miscellaneous A/R and code enforcement.
The proposed system when implemented must allow
fees for all cases/applications/permits (CAP) , utility
4.2.3 billing, Miscellaneous A/R to be paid via the cashiering 3
module.
The proposed system when implemented must provide
security levels so that only defined users are allowed
4.2.4 access to the cashiering module. Read access can also 3
be given to other users for the purpose of reviewing
transactions to a CAP.
Security levels within any cashiering module must
4.2.5 include login access, credit allowance privileges, refund 3
privileges and bond payment issuance.
Cashiering functions must mark correctly paid fees
4.2.6
within each case/application/permit. 3
The Cashiering module must allow the user to enter the
case/application/permit number and automatically have
4.2.7 all the corresponding line items appear. 3
The Cashiering module must allow the user to filter line
4.2.8 items based on fee type and/or fee name. There must 3
be a sort capability as well.
The Cashiering module must allow the user to batch
4.2.9 enter a series of cases, applications or permits and 3
view only the subtotals if so desired.
• The Cashiering module must provide basic
information about the case, application or permit in
order for the cashier to verify payment. This information
would include who the applicant is, related contractor/
4.2.10 company information, case/application/permit type, 2
definition, parcel and address. The proposed system
when implemented must allow the user to create a
query list.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 62 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The Cashiering module must provide a
percentage/portion (partial payment) of payment based
4.2.11 on line items and in the case where there is a list of 3
cases, applications or permits being paid at one time.
• The Cashiering module must allow for refunds and
correctly show the credits on the case, application or
permit as well as the general ledger tables. The refund
4.2.12 4.1.16 records must be seen in the paid items tables, 3
transaction table and GL tables as a single line entry
marked as a credit but also flagged as a refund.
The Cashiering module must allow comments for
refunds. Comments must carry to the paid item tables
4.2.13 for the permit/case, GL tables and transaction tables. 2
The Cashiering module must print receipts and allow for
4.2.14
miscellaneous receipts. 3
The Cashiering module must provide hourly, daily,
4.2.15 weekly, monthly cash drawer batch reports and 2
maintain balance history.
The Cashiering module must record the user
identification login. The user identification login must
4.2.16 show in the transaction and be included in paid items 3
tables, transaction table and GL tables.
The Cashiering module must allow the user to view
payment (transaction) history on a
4.2.17 4.2.26 case/application/permit. The user must be allowed to 3
search based on items listed in section 4.2.26.
The proposed system when implemented must issue a
4.2.18
voucher for all refunds. 3
The system‟s cashiering module must allow for cash
drawer numbering /identification. This must appear on
4.2.19 all transactions, be included in paid items tables, 3
transaction table and GL tables.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 63 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The Cashiering module for the proposed system when
implemented must allow the cashier user to open a
transaction day for a given date. This date must post
4.2.20 onto the transaction records. This functionality must 3
require security/permission levels for specified users.
The Cashiering module for the proposed system when
implemented must allow the cashier user to go into a
particular transaction day and back out a payment. The
4.2.21 proposed system when implemented must track this 2
and allow for comments and to relate if it is a correction,
refund or credit.
The proposed system when implemented must be able
to function with the City's APG brand electronic cash
4.2.22 drawer attached to the cashier's desk top PC. 3
The Cashiering module for the proposed system when
implemented must function with a receipt slip printer
4.2.23 and allow for receipts to be printed on printers utilizing 3
NCR/mailer paper forms.
The proposed system when implemented must allow for
4.2.24
cashier to setup payment schedules. 3
The Cashiering module must allow for web
4.2.25 authorization ( example : Verisign, Web Authorize, etc.) 2
Line items on the cashier system should be able to be
4.2.26
grouped by G/L codes. 3
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 64 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
• The Cashiering System must allow for entry of single
or small multiple line items without reference to a permit
or paid fees set of tables (Ad-hoc cashiering items).
This would be for minor items coming into the
cashiering system that may not be accounted for. To
avoid abuse of this feature there should be a drop down
reference for the user to pick from. Also the list should
contain the applied G/L account number. All applied
transactions would record to the G/L the same as
4.2.27
permits. All transactions will record in the transaction 3
tables. All transactions will record in the paid fees
tables. The cashiering system will generate and apply a
unique key that would take the place of a permit
number. For continuity all Ad-hoc cashiering items may
reference a special (pseudo parcel ID).
The Cashiering module must record the following for
each transaction in the paid item tables for the
permit/case, GL tables and transaction tables:
Unique cashier record ID (transaction ID)
Date of the cashiering transaction (transaction
date entered by user – see 4.2.18 )
System date (actual date entered)
The fee ID
The fee description (description from attached
system)
Type of payment (Cash, check, ATM, Credit
card, escrow, project account)
Related case, application, permit number or
misc A/R
Amount of the original fee that was owed.
Date fee was owed
Amount paid
Balance due
Cashier User Login ID
Cash Drawer Number or ID
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls
4.2.28 4.2.18 0 = Not available 3 Page 65 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
Revenue account number associated with the
fee
Marked as a credit or debit
Refund flag
4.2.28 4.2.18 Refund comment field 3
Return payment flag (if payment paid in error and
needs to be backed out)
Return comment field
Credit comment field
Trust/project account Number ( if fee is to
debit against a trust account (bond))
Receipt number ( using a unique number )
Check number
Bank number
Name of Payer
Phone Number of Payer
Name on the check if different from the Payer.
Phone Number for person listed on a check
Business License Number
Contractor License Number
Identifying information field
Customer id field
Type of transaction (utility bill, passport, dog
license, yard sale permit etc.)
Type of Ad-hoc Cashiering transaction
Memo field
Thick client for the proposed Cashiering system and
implementation module must be able to open a cash
4.2.29 4.3.8, 4.3.9 drawer. The brand used by the City is APG. 3
The proposed Cashiering system and implementation
shall allow the user to select a destination printer to be
4.2.30 used as the receipt printer. 3
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 66 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed Cashiering system and implementation
4.2.31 shall produce receipts on a receipt printer or full page 3
laser/ink jet/NCR printer.
The proposed Cashiering system and implementation
shall allow the cashier to print special forms for specific
types of front counter documents (excluding permits
discussed in previous sections. This includes but is not
4.2.32 limited to; dog license, parking permits, billing 2
statements and special code enforcement receipt
documents/warrants.
The proposed Cashiering system and implementation
4.2.33 must allow for a drop down table and look-up for 2
specific „NAICS” business types.
The proposed Cashiering system and implementation
4.2.34 must allow for a drop down table and look-up for 2
specific „SIC” business types.
The proposed Cashiering system and implementation
must contain a separate memo and a separate screen
4.2.35 for deposits and to interface with the deposit account 2
subsidiary ledger in the general ledger.
Cashiering & Finance
Transactions would be posted either on-line or via batch A proposed solution should be submitted
process. Please submit an addendum and include all
4.3.1 implementation costs as separate line items. 2
The proposed Cashiering system when implemented
must allow extract files to be created for any of the
fields listed in 4.2.26 as exports in files in dbf format,
4.3.2 .TXT Format, MS Access Format, MS Excel format and 3
import format for MS Word.
The proposed Cashiering system when implemented
must allow the user to setup "Export" batch streams for
4.3.3 cashiering transaction record details, by account 3
subtotals, daily subtotals and by transaction type
subtotals.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 67 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed Cashiering system when implemented
must show the amount paid and the G/L distribution,
4.3.4 and A/C description in chronological sequence by 3
transaction.
The proposed Cashiering system when implemented
must allow cash registers and cash receiving to be
4.3.5 done anywhere in the City network and consolidated 3
against a central database.
The proposed Cashiering system when implemented
must allow all transactions to be recorded in a system‟s
core database cashiering tables, and then can be
processed at the end of the day along with detail and
4.3.6 summary reports. Daily/summary transaction reports 2
are not required to be printed from any Web cashiering
lookup.
The proposed Cashiering system when implemented
must allow Microsoft SQL Server Reporting Services or
4.3.7 Crystal Reports™ to be used as the prime reporting 3
tool. Reports generated must be able to print from the
form.
The proposed Cashiering system when implemented
must be compatible with the City's APG brand
4.3.8 4.2.29 electronic cash drawer controlled through the receipt 3
printer.
The proposed Cashiering system when implemented
4.3.9 4.2.29 must have the ability to interface with a POS 2
terminal/cash register.
The proposed Cashiering system when implemented
4.3.10 must have the ability to batch similar types of payments 3
to enter at once.
The proposed Cashiering system when implemented
must support the ability for a person to pay multiple city-
generated invoices/bills at any of a multiple site cash
4.3.11 register environment. Debts can be shown, itemized, at 2
the cash register screen and payments posted back to
the host system.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 68 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed Cashiering system when implemented
must automatically records summary level statistics for
4.3.12 daily, weekly, monthly, quarterly and YTD periods. 3
The proposed Cashiering system when implemented
must have the ability to query and display cash-receipts
4.3.13 by date, account number, amount, who paid, and/or 3
receipt number.
The proposed Cashiering system when implemented
must have the ability to generate the following reports:
exception, daily, monthly, and YTD cash receipt
journals, monthly revenue reports, and charts of
4.3.14 10.1.6 accounts for all revenue accounts. These are expected 2
to be Microsoft SSRS and are not included in any lists
of reports from Tidemark.
The proposed Cashiering system when implemented
must supports bar code scanning to identify codes from
4.3.15 printed invoices, cases, applications and permits. 2
The proposed Cashiering system when implemented
must have ability for Cashiering module to have at least
20 different selectable screens (different fields, field
4.3.16 placement, etc) for different types of cash receipts, i.e.. 2
Property tax, business license, utility bills, planning
charges, etc.
The proposed Cashiering system when implemented
must be able to produce an audit trail whether paid by
mail or walk-in, the check number, bill number, date
4.3.17 presented, date of check, name and bank number, 3
amount (and distributed amounts) are recorded and
accessible from each module.
The proposed Cashiering system when implemented
must be able to support refundable deposits, an
4.3.18 optional menu of deposit types, the enter name, date, 3
and amount. It then interfaces this and the deposit
subsidiary ledger in the G/L.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 69 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed Cashiering system when implemented
must be able to track receipt activity. Track and report
4.3.19 receipt activity by the date range, payee, type code and 3
amount
Total Cashiering and Fee G/L Score - $ -
COF Citizen Access Bid Ref: 4.1.7
All business rules and specifications defined for
this area apply to all Cases, Applications and
15.1.0
Permits (CAPs) along with ancillary information and COF Citizen Access
data needs.
The proposed system when implemented will provide a Allow outside users limited access to designated areas of
way for external users (Citizens, developers, information. This would be a web page access.
15.1.1 contractors) to access basic information from the 3
system through the City's website, hosted by CivicPlus.
The proposed system when implemented will provide A designated admin can assign access to outside users.
external users with a way to access special information
15.1.2 using a PIN number register to the user. 3
The proposed system when implemented will provide The designated city users will have the ability to maintain their
a way for the System administrator and/or designated own web pages.
15.1.4 6.5.10, 6.4.6 super user group to maintain various pages, field views, 3
field use and access level and update the CivicPlus
CMS.
The proposed system when implemented will provide a Designated sensitive areas shall not be viewed by the public.
way for secure data, rights and privileges as business
15.15 rules to be enforced also on the web pages designated 3
for community access.
The proposed system when implemented will allow
15.1.6 registered external users to check their own signoff 3
activities.
The proposed system when implemented will allow
registered external users to modify their own project
15.1.7 13.1.10 (CAP) information for purposes of updating phone 3
numbers and adding contacts.
Total COF Citizen Access Score - $ -
Engineering CAP Bid Ref: 4.1.8
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 70 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
All business rules and specifications defined for
9.1.0 Building & Safety permits apply to Engineering Engineering CAP
cases as well.
The proposed system when implemented must be
flexible (controlled by security designation) in the
9.1.1 methods of numbering permits that are supported in the 3
system and whether the numbering methods can vary
by type of permit.
The proposed system when implemented must have
4.2.2, 5.1.22, “out-of-the-box” cross functional processes between
9.1.2a 6.1.2, 7.1.2, planning, permitting, business licensing, trade licensing, 3
9.1.2b cashiering , application parcel management and code
enforcement.
Based on the type of permit, the system should route
the permit to the required departments, which need to
9.1.2b 3.1.13 1.1.15 review the permit (as defined by the user). Please 3
describe if necessary. This includes e-mail notification.
The user should have the ability to “re-route” plans to
appropriate departments so that revisions created by
9.1.3 one department are sure to be reviewed by other 3
departments.
For permits that require review by multiple departments,
the software should have “routing” features that allow
9.1.4 users to determine review status of permit by multiple 3
reviewers.
The proposed system when implemented must allow
users to establish default Plan Review Activities, based
on permit types that are automatically added when a
9.1.5 permit is created. The Activities (tasks) must 3
automatically be added when the specific type of permit
is created.
The proposed system when implemented must allow
users to establish default (typical) Inspection Activities
9.1.6 (tasks), based on permit types that are automatically 3
added when a permit is created.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 71 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
In the proposed system when implemented, the user
9.1.7 should be able to add to the approval/routing list if 3
additional approvals are necessary.
The proposed system when implemented must have
the ability to add users to the routing processes based
on information on the permit (e.g., “Route all
9.1.8 commercial tenant improvement permits with a 3
valuation over $10,000 to the Traffic division of
Engineering. Anything less does not have to be
routed”).
The proposed system when implemented must have
the ability to track the review activity and comments
9.1.9 made by employees, including the complete text of 3
letters sent to applicants.
The proposed system when implemented must allow
the users the ability to place “holds” or post “notices” or
9.1.10a otherwise stop a permit from being issued until the 3
applicant complies with specific condition(s).
The proposed system when implemented must allow for
a substantially visible flag on various forms for permits:
9.1.10b 3
Red, Green, Yellow, flag or stop light on the
permit form and important fields.
The proposed system when implemented must contain
the function where by which, permit details should be
able to be changed by users. However forms, fields and
9.1.11 permit types should only be added/changed based on 2
the users security.
The proposed system when implemented must have
integrated planning, development, permitting, and case
9.1.12 management capabilities within a single application. 3
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 72 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must
automatically notify a designated list of users that the
case/application /permit is ready for corrections or to be
9.1.13 issued. This should be done as all divisions and 3
departments complete their review of a case/
application /permit for approvals and/or corrections.
The proposed system when implemented should allow Not all CAP's necessarily need to be associated with a Parcel (or
permits (CAPs) to be created and not be required to be UID).
associated with a Parcel. Permit can be directed to link
9.1.14 to a pseudo parcel table that has a text definition field 2
rather than typical fields associated with the parcel
table.
The proposed system when implemented must allow Provide contact (people related to the CAP) lookup capability.
users to easily lookup the contact information for a
project or planning/case. Contact information should
include the following fields:
Company Name
Role (Contractor, Architect, Emergency Contact
etc.)
Type of Business
Link to business license screen
Contact person (s) full name fields
Primary contact indicator (along with secondary)
9.1.15 3
Company address
Contact Phone 1 (Designate Land line or
Cell/mobile)
Contact Phone 2 (Designate Land line or
Cell/mobile)
Contact Phone 3 (Designate Land line or
Cell/mobile)
Contact‟s FAX Number
E-mail 1
E-mail 2
The proposed system when implemented must allow Designated users may be allowed to do this.
9.1.16 the user to number the permit instead of using auto- 3
numbering if so desired.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 73 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must allow This is considered a normal business flow for all CAPs. See the
fees with corresponding calculations and schedules to fees requirements section for more details.
9.1.17 be triggered based on values inserted in drop down lists 3
or form fields.
The proposed system when implemented must allow
9.1.18 9.1.19 users and/or user groups to be assigned for signoffs, 2
tasks and activities.
The proposed system when implemented must provide A "To-do list" is needed and can function the same way as
a "To-Do-List'. The conditions and parameters should defined in similar requirements.
9.1.19 9.1.18 be set conditions for users to configure what goes in to 2
the list.
The proposed system when implemented must allow for This can function the same way as defined in similar requirements
9.1.20 preset correction /result codes for reviews activities and for the other CAPs. 2
inspections activities.
The proposed system when implemented must allow for Valuation items must be allowed a separate maintenance module.
project valuation items along with corresponding fee Maintenance should be audited. Maintenance of the valuation
9.1.21 6.1.35, 9.1.22 calculations. items should be controlled using user restrictions But provide a 3
System Admin override. (see also 6.1.35)
The proposed system when implemented must allow for Designated users or user group along with the system admin
project valuation item maintenance by a designated should be allowed maintenance capabilities to perform this
users (Using privilege requirements). Maintenance must function.
9.1.22 6.1.35, 9.1.21 include changes to singular valuation items and there 2
use within a fee calculations
The proposed system when implemented must provide We expect the system to allow wild card search.
the users with the ability to search (Active Filter list) for
a particular or group of Engineering CAPs based on
9.1.23 field values (Partial field values). In other words be able 3
create a search list based on search matching search
criteria based on values on the Engineering CAP form.
The proposed system when implemented must provide
search or filter lists which may be extracted for external
reporting. This will include searches by any case (CAP),
Specific CAP Field values for particular CAPs, parcel,
9.1.24 Address, people or role types, activities, conditions, 3
valuations, mechanical items or fees (applied, due
and/or paid).
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 74 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must have The user while being in a Code enforcement Case can see any
integrated planning, development, permitting, code relevant CAPS of any other type. This begins with a list then with
enforcement and case management capabilities. the user having the ability to jump to the particular CAP to view
9.1.25 additional details such main CAP information, activities, fees, 2
people information and attached documents.
The proposed system when implemented must provide Provide a search list of cases based on given case applied fee
the users with the ability to search (Active Filter list) for records and paid fee records search criteria.
9.1.26 a particular or group of Engineering CAPs based on 3
applied fees and paid fees.
The proposed system when implemented must provide Provide a search list of cases based on given case activity/task
the users with the ability to search (Active Filter list) for search criteria.
9.1.27 a particular or group of Engineering CAPs based on 3
activities/tasks.
Total Engineering CAP Score - $ -
Code Enforcement Case Bid Ref: 4.2
Code Enforcement Case
The proposed system when implemented must have The user while being in a Code enforcement Case can see any
integrated planning, development, permitting, code relevant CAPS of any other type. This begins with a list then with
enforcement and case management capabilities. the user having the ability to jump to the particular CAP to view
7.1.1 additional details such main CAP information, activities, fees, 3
people information and attached documents.
The proposed system when implemented must have
4.2.2, 5.1.22, “out-of-the-box” cross functional processes between
7.1.2 6.1.2, 7.1.2, planning, permitting, business licensing, trade licensing, 3
9.1.2 cashiering , application parcel management and code
enforcement.
The proposed system when implemented must allow
7.1.3 the creation of a case where the violation may not be 3
initially related to a specific parcel.
The system should allow permits to be created and not
be required to be associated with a Parcel. Permit can
7.1.4 be directed to link to a pseudo parcel table that has a 3
text definition field rather than typical fields associated
with the parcel table.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 75 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
In the case where a specific parcel is not used to
7.1.5 generate the case, a location field should be provided 3
and a nearest cross street field.
In the case where a specific parcel is not used to
7.1.6 generate the case, the system should allow for the 3
recording of GPS points and GIS points.
The proposed system when implemented must allow a
workflow process to be set by the user in order to match
7.1.7 course of action or “next steps” based on the type of 3
violation.
The proposed system when implemented must be able
to have Code violations that are parcel related, attached
7.1.8 to the parcel in order for other permitting/application 3
processes to view. This is especially true for hard holds
placed on parcels
The proposed system when implemented must allow a
code enforcement case, when delinquent, a “STOP”
condition must be able to be set on the parcel so that
7.1.9 no other permit/applications can be issued until the 3
code enforcement violation is cleared.
The proposed system when implemented must allow an
7.1.10 e-mail notice to be sent to Building and safety officials 3
when a Stop Condition occurs.
The Code Enforcement module must allow for a
warning flags that subsequent cases or inquiries allow
7.1.11 the user to see a potentially danger to an Enforcement 3
Officer. (i.e. Big Dog or violent Home Owner call for
backup)
The proposed system when implemented must allow
7.1.12 the user to number the permit instead of using auto- 3
numbering.
The proposed system when implemented must allow
7.1.13 inspection tasks/activities to be entered using a thick 3
and thin client (Web) interface.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 76 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must allow
inspection tasks/activities to be assigned to an
7.1.14 inspector using a thick and thin client (Web) interface. 3
Also there assignments must be done to an inspection
area operated by the inspector.
The proposed system when implemented must allow
7.1.15 inspection tasks/activities to be scheduled using a thick 3
and thin client (Web) interface.
The proposed system when implemented must allow
users to easily lookup the contact information for case.
Contact information should include the following fields:
Type of Business (if related to a business)
Link to business license screen
Contact person (s) full name fields
Primary contact indicator (along with secondary)
7.1.17 Company address 3
Contact Phone 1 (Designate Land line or
Cell/mobile)
Contact Phone 2 (Designate Land line or
Cell/mobile)
Contact Phone 3 (Designate Land line or
Cell/mobile)
Contact‟s FAX Number
E-mail 1
E-mail 2
The proposed system when implemented must allow
the user to list workload visitations/ inspections for a
specific date containing the following and allowed
sorting (ascending/ descending) by the following as
well:
Code Enforcement Officer ID (Code and/or name)
7.1.18 Case Number 3
Parcel ID (if applicable)
Address or street name lookup
Delinquency criteria
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 77 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
7.1.18 3 <VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
Type of violation
Any existing status codes including blank and null
values
The proposed system when implemented must allow
Code Enforcement Officer to be assigned in at least
one of the following ways.
Parcel / APN
By address
By permit number
7.1.19 3
By Project Number
A field in the case contains the inspectors ID Code
If the above two are blank then the system checks
to see who the last Code Enforcement Officer was.
The proposed system when implemented must allow
7.1.20 the users to create new case types for newly specified 3
codes or abatement needs.
The proposed system when implemented must allow
external documents to be attached/associated with the
permit. This includes but is not limited to, Laserfiche,
7.1.21 MS Word Files, MS Excel Files, Adobe Acrobat (.PDF) 3
files, JPEG files, GIF files, TIFF files, MPEG files, MOV
Files and AVI files.
The proposed system when implemented must have
7.1.22 the capability to build and maintain a user-defined 2
condition library.
The proposed system when implemented must include
7.1.23 complete case history including reviews, inspections, 3
conditions, and fees.
The proposed system when implemented must allow
fees with corresponding calculations and schedules to
7.1.24 be triggered based on values inserted in the fields. 3
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 78 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must allow
fields to be marked as „sensitive‟ so that they cannot be
7.1.25 viewed by non-essential personnel. 2
The proposed system when implemented must provide
a 'To-Do-List'. The conditions and parameters of the
7.1.26 activities/tasks on the list should be set conditions for 2
users to configure.
The proposed system when implemented must allow for
7.1.27 preset correction /result codes for reviews and 3
inspections.
The proposed system when implemented must provide
the users with the ability to search (Active Filter list) for
a single or group of Code Enforcement cases based on
field values (Partial field values). In other words be able
7.1.28 create a search list based on search matching search 3
criteria based on values on the Code Enforcement case
form.
The proposed system when implemented must provide
search or filter lists which may be extracted for external
reporting. This will include searches by any case (CAP),
Specific CAP Field values for particular CAPs, parcel,
7.1.29 Address, people or role types, activities, conditions, 3
valuations, mechanical items or fees (applied, due
and/or paid).
CEGIS Applications GIS: Functions
The proposed system and implementation of the GIS
functions on the field and desktop application must
20.1.1 allow the user the ability to Pan/Zoom: 3
a. Zoom in/out Full View & Pan
b. Percentage of Zoom
The proposed system and implementation of GIS
functions on the field and desktop application must
20.1.2 provide a mouse over function in order to display the 3
house/street address, APN, and/or owner.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 79 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system and implementation of the GIS
20.1.3 field/desktop application must provide function keys ( 3
Short Cuts or Hot keys).
• The proposed system and implementation of GIS
functions on the field/desktop application must allow the
user the ability to define Polygon Zooms. Based upon
20.1.4 case type and zone, “Management will define various 2
zones for the Inspectors or officers.”
The proposed system and implementation of the GIS
field/desktop application must allow the user the ability
search.
a. Search By:
i. APN
ii. Address
Intersection
iv. Particular Activity or type of activity.
20.1.5
v. fees
3
vi. owner
b. Result codes – violations
c. User Defined search (attribute search)
d. Spatial Search – from a Selection, Polygon or a
e. radius Search
f. Spatial Attribute Search
Identify: The GIS function on the field/desktop
application must have the ability to select the parcel
20.1.6 and view the parcel information 3
a. Generic: APN Owner etc.
b. Cases/ Events related to the selected parcel.
The proposed system and implementation of the GIS
functions on the field/desktop application must have the
20.1.7 20.1.10 ability to Edit / create a case for the identified parcel. 3
Considering the parcel is actually linked to a universal
identifier for the Parcel.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 80 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system and implementation of GIS
field/desktop applications must allow the user the ability
20.1.8 to delete: 3
a. Violation Polygon
b. Vehicle Point if no case is attached
The proposed system and implementation of GIS
functions on the field/desktop application must allow the
Violation Polygons:
20.1.9
a. Visualization for parcel cases
3
b. Associated case (including building and
planning permits )
The proposed system and implementation must allow
case / permits and applications to be written against a
20.1.10 Universal Parcel Identifier. This in turn would link to the 3
actual parcel tables and asset tables (including
address(s) and owner(s).
CEGIS Application GIS: Functions (Seasonal/Abatement)
The GIS Function on the field application and desktop
must allow the ability to open a new abatement case
20.2.1 with the preset default case type insert into the case. 3
The GIS Function on the field application and desktop
must provide the user with a visual that displays the
status of cases and allows for the viewing of cases
20.2.2 submitted (along with their status) for a particular 3
abatement season. (in this case it would be for the bi-
annual weed abatement season.
• The GIS Function on the field application and desktop
must allow the ability for the user to select a group of
contiguous parcels and issue a “Pass” status for the
particular abatement season. A colored layer would
20.2.3 appear to connote that the parcel had already been 3
inspected and passed for the season abatement. In this
instance no case needs to be generated.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 81 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The GIS Function on the field application and desktop
20.2.4 must allow the user the ability to define Zooms. “Zoom 2
to selected inspection area.”
The GIS Function on the field application and desktop
must provide Visualization.
20.2.5
Weed – Tickler 3
Visual reminder of Case status
The GIS Function on the field application and desktop
must auto-generate (create) an abatement case in the
20.2.6 city‟s permitting system Code Enforcement module 3
upon Failing an inspection by a Code Enforcement
user.
The GIS Function on the field application and desktop
must have all auto generated cases reference a rules
20.2.6b table to generate the next steps (events/activity). 2
The GIS Function on the field application and desktop
20.2.7 must allow the user to select a parcel to display a case, 3
abatement case or case history.
The GIS Function on the field application and desktop
must allow the user to:
20.2.8 a. Edit cases and related events/activities and 3
fees due.
b. Create new cases or events/activities.
The GIS Function on the field application and desktop
must allow the user to toggle between interfaces:
20.2.9 2
a. Only seasonal cases appear
b. And the seasonal case form.
CEGIS Application GIS: Interfaces
The GIS Function on the field application and desktop
must allow the ability to select a default case type that
may be opened for a new abatement case. Examples
20.3.1 include but are not limited to; weeds, animals, 3
abandoned vehicle, nuisances, structure, patio,
additions, roof and fences.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 82 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The GIS Function on the field application and desktop
must provide form (s) (lists) to display codes
20.3.2 enforcement case and view the case information. 3
The GIS Function on the field application and desktop
20.3.3 must visualization of violation status, violation numbers 3
and problems.
The GIS Function on the field application and desktop
must be able to record trouble information as well as
show alert icons/layers. This would be to indicate
20.3.4 events that are over due or need attention, problems 3
with (biting dogs), problem with residents (biting
resident) dangerous chemicals etc.
The GIS Function on the field application and desktop
must provide points on a GIS map for abandoned
vehicles, transient vendors. From these also link to any
20.3.5 cases created and the ability to open for view/edit from 3
the point on the map. These points can be attached to a
parcel if parcel related or (X, Y) coordinate if not parcel
related.
The GIS Function on the field application and desktop
must show layer for cases that are Vehicle parking
20.3.6 permits. The permits will be related to parcel. 2
The GIS Function on the field application and desktop
20.3.7 must allow the user to select a parcel to display a case, 3
abatement case or case history.
The GIS Function on the field application and desktop
20.3.8 must be able to open all related types of cases for Code 3
Enforcement and permitting.
The GIS Function on the field application and desktop
must be able to create any related types of cases for
20.3.9 Code Enforcement and permitting from GIS. 3
The GIS Function on the field application and desktop
must allow the user to toggle between interfaces:
20.3.10 3
a. Only seasonal cases appear
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 83 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF #
20.3.10 Cross Feature Description Rating
3 Code*
Reference Cost
b. And the seasonal case form.
CEGIS Application GIS: Views
• Users need to have predefined views and interfaces
that they may switch between or cycle through as they
wish. This will effect what the user can see on the map
as well as the case (permit) / event (activity) type that
will be available to the user. For all views the user
20.4.1 needs: 2
1. All cases to appear
2. Default to Code Enforcement zones
3. Default shading for specific code enforcement
needs (views)
• Users need to have predefined views and interfaces
that they may switch between or cycle through as they
wish. This will effect what the user can see on the map
as well as the case (permit) / event (activity) type that
will be available to the user. For seasonal views the
user needs:
20.4.2 2
1. Abatement season cases
2. Abatement season zones
3. Shading based on abatement season events
(activities)
• Users need to have predefined views and interfaces
that they may switch between or cycle through as they
wish. This will effect what the user can see on the map
as well as the case (permit) / event (activity) type that
will be available to the user. For Code Enforcement
specific cases:
20.4.3 2
1. Code Enforcement Cases
2. Code Enforcement zones
3. Shading based on code view
For all Views the user needs:
For all views and for case type views the user needs:
1. Garage
* 3 = Included in delivered system
20.4.4 2 = Program modification (at cost) 3
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 84 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
2. Recreational Vehicle permits
3. Seasonal History
20.4.4
4. (Paid) 3
5. Financial View
6. Issued warrants
7. Issued work orders
8. Scheduled dates of work orders
Users need to have predefined views and interfaces
that they may switch between or cycle through as they
wish. This will effect what the user can see on the map
20.4.5 20.4.4, 20.4.3 as well as the case (permit) / event (activity/task) type 3
that will be available to the user.
CEGIS Application GIS: Business Rules
The proposed system when implemented must be able
to process case events (activities/tasks) as a date
20.5.1 driven process and event driven process in order to 3
follow business rules.
• The proposed system when implemented must be
able to process through current/active Code
Enforcement cases and generate the next event
(activity/task) step or sequence. The next step or
sequence would based on field values and/or defined
business rules (flow/logic). The defined business rules
20.5.2 (flow/logic) can be a combination of time, date or 3
field/table result values. In other words The proposed
system when implemented must be able to spawn (into
the cases ) the next event (activity/task) step or
sequence automatically.
• Once the business rules have been processed the
proposed system when implemented must be able to :
1. Update field/table values
2. Corresponding GIS visualization
3. Generate corresponding events
20.5.3 3
(activities/tasks) on the case
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 85 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
20.5.3 3 Code*
Reference Cost
4. Create and display appropriate output on
forms and pages.
This needs to occur independent of user invention
(i.e. Opening the case and selecting manual update
sequences.)
For visualization the proposed system when
implemented must be provide a Table/Process that
20.5.4 allows GIS to display case disposition. (i.e. Owner 3
information, case status, number of cases)
The base client for the field application must be able to
provide a store and forward capability in order to
20.5.5 resynchronize the data in the event of a wireless 3
disconnect with the field unit.
The proposed system when implemented must provide
20.5.6 logs of spawned events (activities/tasks) and any 3
transactions that have occurred.
The proposed system when implemented must link to
20.5.7 the entire permitting system process and database 3
schema.
Any functional process developed for all mentioned
business logic sequences to occur automatically, must
be documented and defined for the City of Fontana.
This includes database management procedures,
20.5.8 house cleaning procedures, control file (if any) definition 3
(and their usage), any data mapping schemes, event
(activity/task) definition and system documentation.
The Vendor must provide the documentation of all case
20.5.9 types created for use by the City of Fontana for CEGIS 3
portion of the project.
The proposed system when implemented must be able
to handle batch processing for the user billing &
20.5.10 warrants also the season Start and updated Geo 3
Database.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 86 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The system is required to issue “RV” parking permits.
The proposed system when implemented must be able
to issue permits for RV parking. The RV permits are
given to citizen and correspond to a GIS point on a
map. Okay needs to be given the designated ordinance
manager in order for the citizen to park the RV either on
the street or on their property. This has to do with
intersection corners and viewing clearance.
1. The permit needs to be routed for approval and
checking.
20.5.11 2. The permit is date stamped for expiration from the 2
final approval.
3. Fees are collected.
The nearest property shows on a GIS view for
approved RV parking permits in the city.
5. Make model, license and VIN are stored for
view by Code Enforcement
6. Registered vehicle owner information is kept.
7. If related the property information is also kept
8. A multi-part permit is printed.
The system is required to issue “garage Sale” permits.
The proposed system when implemented must be able
to issue permits for “garage sale” parking
1. Two Garage sale permits are allowed per
year.
2. They must be at least 6 months apart.
3. Participant‟s address
20.5.12 4. Participants legal name and phone 2
The dates the permit is good for
6. Fees are collected.
7. Approvals are routed.
8. A permit is printed for the requestor.
9. GIS points are plotted for approved issued
permits
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 87 of 104
20.5.12
City of Fontana 2
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
10. Plotted points must be current issued permits.
The proposed system when implemented must allow
super users either in Community Development or Code
20.5.13 Enforcement to flag or note a parcel as being owned by 3
the City of Fontana.
The proposed system when implemented must track
notices ( Letter of notification and/or case notices) sent
20.5.14 to other agencies (i.e.. Rail Road or Utility Company). 3
The Current system numbers the Abatement cases as
follows.:
· “WA yy s xxxx ii nnnnnn”
· Where WA = Weed Abatement
· yy – last two digits of the year
20.5.15 · s = Abatement season „A‟ or „B‟ 3
· xxxx = Area
· ii = initials of inspector
· nnnnnn = Unique Case number
The proposed system when implemented must provide
a unique case identifier.
The proposed system when implemented must be able
20.5.16 to print out notices that will be posted and/or mailed to 3
owners.
The proposed system when implemented must be able
to print mailing labels. The labels would be based on
20.5.17 calendar driven events as required. The labels can also 3
print based on search criteria set by the user.
The proposed system when implemented must allow
calendar events to post next re-inspection. This must be
20.5.18 automatic. Re-inspection should be able to be queried 3
by the user to look at re-inspection load by date and by
inspector.
The proposed system when implemented must be able
20.5.19 to produce a daily re-inspection report. This should be a 3
spawned report.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 88 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented show re-
inspections also on a GIS layer as a designated color
shading. The inspector should be able to view their GIS
20.5.20 20.5.19 area and be able to see Re-inspections needed as a 3
color change (layer).
The user‟s GIS area map should match a daily report
detail of re-inspections.
The proposed system when implemented must be able
to schedule calendar driven events to post a work order
as required for the abatement case. The system must
print a work order to a prescribed abatement contractor.
20.5.21 Work order detail includes but is not limited to; Case 3
number, property address, inspector information (name
and phone), owner name, and detail of work to be done.
The proposed system when implemented must allow for
the maintenance of a validation list containing
Abatement contractors. This list should link to Business
20.5.22 license table of contractors doing business within the 2
city limits. There should also be an approval rating and
the approved inspection area they handle.
• The proposed system when implemented must
provide a list of (court) warrants as a weekly report. The
report format can vary depending on regional court
(judge) changes. Sometimes the report requirements
20.5.23 will change and the report format will have to be 3
changed within a weeks notice. This has occurred from
season to season but is usually one change within the
season.
The proposed system when implemented must allow
the warrant list to be printed for court as required based
on parameters entered by the inspector on to the case.
20.5.24 This would require certain fields in the case to 3
determine privacy access. If the fields are flagged or
contain the correct code or value than a warrant is
printed.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 89 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
CEGIS Field Application
The proposed system and implementation must provide
20.6.1 20.1-20.5,20.7 the field application all function listed in section 20.1, 3
20.2, 20.3 20.4, 20.5 and 20.7.
In order to provide coverage in the field the proposed
system and implemented field application must be able
to have a store and forward capability. Also work with a
field Web enabled application pointing to domain server
20.6.2 20.1.3, 20.1.4 in the City to access case information parcel 3
information , owner information ass well as create / edit
cases in the field.
The proposed system and implemented field application
with store and forward capability spoken of in section
20.1.2 needs to work both ways. Along with the GIS
Functionality the laptop must be able to be uploaded
20.6.3 20.1.2, 20.1.4 with current information in order to display the 3
house/street address, case history, create / edit cases,
Warrant history, fee history, APN information, and/or
owner.
The proposed system and implemented field application
with store and forward capability spoken of in section
20.1.2 needs to work both ways. Along with the GIS
Functionality the laptop must be able to resynchronize
with the main database any updated information
especially notes pertaining to house/street address,
20.6.4 20.1.2, 20.1.3 3
updated case history, newly created / edit cases,
warrant updates, new events/tasks, notes pertaining to
APN information, APN holds and notes pertaining to
owner.
CEGIS Application GIS: Case Tools
The proposed system when implemented must allow
20.7.1 the user to easily switch between interfaces. 3
The proposed system when implemented must provide
Selection/Identify Tools
* 3 = Included in delivered system
20.7.2
2 = Program modification (at cost)
3
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 90 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
Cases new or existing are accessed via GIS
20.7.2
Option to create a new case 3
List all open and/or Closed cases on the parcel
(Identify Tool as in WAMS)
The proposed system when implemented must be able
to create events for continued actions or deliberate new
cases i.e. COD( standard code enforcement cases) or
20.7.3 WEED (abatement cases) along with ( Permitting 3
system Fees & activities) on that are associated with
the defined case.
The proposed system when implemented must allow
20.7.4 attach documents or files to an existing Case. 3
The proposed system when implemented must provide
20.7.5 Ad-hoc reporting from, screen shot reporting and 3
reporting using MS SSRS.
The proposed system when implemented must provide
a form for the type of case that is being
20.7.6 opened/created. The case should decide upon the form 3
that comes up.
The proposed system and implementation must provide
CEGIS portion (module) to interface directly with the
permitting system. All Code enforcement cases created
20.7.7a through CEGIS should be able to be viewed from other 3
forms within the Code enforcement module.
The proposed system and implementation must provide
all developed forms both thick client and web based for
20.7.7b use with CEGIS and Code Enforcement. These forms 3
must portray a cohesive work flow
The proposed system when implemented must be able
to allow the permitting system portion to provide and
store parcel attributes used with Code Enforcement
and CEGIS. This includes but is not limited to:
20.7.8 1. Owner detail 3
2. Address
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 91 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF #
20.7.8 Cross Feature Description Rating
3 Code*
Reference Cost
3. APN
4. In City / Out of City codes
5. Tags or hold records for placing a hold on a
parcel.
The proposed system when implemented must allow
ownership of parcel and case to managed through
20.7.9 appropriate forms. (Perhaps located in other modules. 3
All keeping in mind security and rights to update.
The proposed system when implemented must contain
a table to track (public) hearings. The „Hearings‟ table
would need to keep track of the following:
***Hearing date
***Title of the Hearing
***Session
***Location
20.7.10 3
***Conducted by (full name)
***Attending Code officer(s).
***Abatement season
The table should link to and attendance table that
shows record of attendance. This would contain full
name of owners, their comments and link to he parcel
they own. This would be for case history lookup.
The proposed system when implemented must have
20.7.11 the Ability to assign each Inspector a geographic Area 3
The proposed system when implemented must allow
the Code Enforcement officer to switch between
20.7.12 inspection geographic areas in the event they are 3
covering for case loads for another inspector.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 92 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
• The proposed system when implemented must allow
for maintenance of defined inspection areas. The
inspection areas besides having an area identifier
20.7.13 should also have area definitions, layer information,
APN Map Book and who the typically assigned
inspector is.
CEGIS Implementation:
The proposed system and implementation of the
solution must include converting all existing data from
21.1.1 the City of Fontana‟s – WAMS (Weed Abatement 2
Management System) system and upload the data over
to the new system.
Since the initial idea for implementation is a „phase-in‟
approach, proposed system and the implementation of
the solution must include subsequent selective
conversions of existing data from the City of Fontana‟s
21.1.2 – WAMS (Weed Abatement Management System) 2
system. The subsequent uploads would be for testing of
the application prior to go live for this particular
module/application.
The proposed system and implementation of the
21.1.3 solution must include a business area analysis prior to 3
system builds.
The proposed system and implementation must
21.1.4 schedule regular training at appropriate intervals that 3
are cohesive with module availability.
The proposed system and implementation of the
solution must include multiple load tests with users and
21.1.5 multiple test „Go-Lives” prior to a scheduled go-live 3
date.
The proposed system and implementation of the
solution must include prior to go-live User sign-off for
application process acceptance at each application
21.1.6 layer and application process acceptance must be 3
complete. All acceptance testing agreed to must be
complete. . All acceptance testing must be
documented.
Total Code Enforcement Case Score - $ -
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 93 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
Business License Application : Bid Ref: 4.3
Business License Application :
The proposed system when implemented must be able
to contain and maintain a table for "Business Name"
information. The following fields are contained in this
table and maintained with links to the Business
owner(s), ownership type, business type, business
license number, home based business and GIS layer
for business types.
1. Business Name
2. Business Address (Address fields are
30.1.2, 30.1.3, Number, direction, street name, suite)
30.1.1
30.1.4, 30.1.5 3. Business City, State & Zip (City of Fontana is 3
set as a default as well as CA for state)
4. Mailing address (Address fields are Number,
direction, street name, suite)
5. Mailing City, State & Zip (defaults for city and
state can be configured by user if desired)
6. Local business Phone
7. Local Business Fax
8. Email address/website
The proposed system when implemented must be able
to contain and maintain a table for "Business Owner(s)"
information. The following fields are contained in this
table and maintained with links to the Business name,
business type, ownership type, business license
number, home based business and GIS layer for
business types.
1. Provide information for multiple owners.
30.1.1, 30.1.3, 2. Owner name
30.1.2
30.1.4, 30.1.5 3. Owner Title 3
4. Owner phone Number
5. Owner Address (Address fields are Number,
direction, street name, suite)
6. Owner City State and Zip
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 94 of 104
City of Fontana
Release Date: 12/18/2009
30.1.1, 30.1.3,
Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
30.1.2
Due Date: 2/16/2010
30.1.4, 30.1.5 RFP Response Form 3
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
7. Owner Social Security Number ( This field
needs to be blanked out on viewing forms except for
privileged users)
8. Driver‟s License No.
The proposed system when implemented must be able
to contain and maintain a table for "Ownership Type"
information. The following fields are contained in this
table and maintained with links to the Business name,
business type, Business owner(s), business license
number, home based business and GIS layer for
business types.
1. Ownership Type
Corporation
30.1.1, 30.1.2,
30.1.3
30.1.4, 30.1.5
Corp-Ltd Liability 3
Sole Proprietor
Partnership
Trust
2. Resale/Sellers No.
3. Federal I.D. No. & State I.D. No.
4. Email contact information.
5. Contractor State License No.
6. License Type
7. Expiration date
The proposed system when implemented must be able
to contain and maintain a table for "Home Based
Business" information. The following fields are
contained in this table and maintained with links to the
Business name, business type, ownership type,
business license number, home based business and
GIS layer for business types. The system contain a flag
or field within existing tables to connote this business as
a home business.
1. Business Name
30.1.1, 30.1.2, 2. Business Address (Address fields are
30.1.4
30.1.3, 30.1.5
3
Number, direction, street name, suite)
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 95 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF #
30.1.4
30.1.1,
Cross 30.1.2, Feature Description Rating
3
30.1.3, 30.1.5 Code*
Reference Cost
3. Business City, State & Zip (City of Fontana is
set as a default as well as CA for state)
4. Mailing address (Address fields are Number,
direction, street name, suite)
5. Mailing City, State & Zip (defaults for city and
state can be configured by user if desired)
6. Local business Phone
7. Local Business Fax
8. Email address/website
The proposed system when implemented must be able
to contain and maintain a table for "Business License"
information. With this as an associated table the
system must keep a history of reapplications.
1. Business Certificate number (Business
License Number)
2. Expiration Date
30.1.1, 30.1.2, 3. Renewal date
30.1.5
30.1.3, 30.1.4 4. Grace date (30 days after renewal. 3
5. Amount paid. And how paid (cash or check w/
check no.)
6. Amount owed.
7. Amount credited.
8. City Code
9. SIC /NAIC Code (must have a validation table
)
10. Issuing Clerk
The proposed system when implemented must allow
30.1.6 30.1 the user to do a sort and search based on all of fields 3
mentioned in feature section 30.1.
The proposed system when implemented must be able
30.1.7a to calculate fees which are based on fee schedules. 3
The fee schedules are based on business type and a
30.1.7b scale of business (estimated) gross receipts submitted 3
by the applicant.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 96 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The fee schedules are based on business type and a
30.1.7c scale of number of square feet submitted by the 3
applicant.
The proposed system when implemented must be able
30.1.8
apply to applications flat fees as well. 3
The proposed system when implemented must be able
30.1.9 to produce a letter as a mailer for an amount that is 3
due.
The proposed system when implemented must be able
30.1.10 note all over payments and apply them as credits for 3
the following years submittal.
The proposed system when implemented must have
the fee tables linked to the system wide general ledger
30.1.11 in order to contain revenue accounts with the fees. 2
The system needs to provide the user with a daily
30.1.12a receipts report for all newly submitted (entered) 3
applications.
The proposed system when implemented must allow
30.1.12b the user to search and sort based on fee fields. 3
The proposed system when implemented must provide
for business flow that looks for upcoming license
renewals and sets up a batch to produce mailers.
1. The mailers are produced with 30 days prior to the
expiration date of the business certificate.
30.1.13 2. There is also a 30 day grace period. 3
3. All new application s and renewals are given
an expiration date that is the last day of the previous
month (i.e. application submitted in December then
the expiration date is given as the last day of
November the following year.)
4. Late fees are 20% added for each late month
up to 100%
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 97 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
For hospitals and convalescent homes, the proposed
system when implemented must include fields for the
30.1.14 number of beds and be able to calculate fees from this. 3
For requested carnival events, there must be a field for
30.1.15 the number of days as well as fields for the dates of the 3
event and location.
The proposed system when implemented must allow for
fields used by vehicle related business (i.e. Taxi,
delivery services etc.) Fields must include but are not
30.1.16 limited to number of vehicles, license, vehicle 3
registration number, make and model. Fess need to
calculate based on the number of vehicles.
The proposed system when implemented must contain
30.1.17 fields for contractor class description, full name, full 3
address and contractor license info.
The proposed system when implemented must contain
a field to indicate whether a business license requires
the approval of another department, and whether or not
30.1.18 that approval has been received. 3
· Task or event lists may be used to provide for this.
The proposed system when implemented must have
30.2.1 the ability to interface with Tabular GEO-BASE and 3
graphic mapping system .
The proposed system when implemented must provide
Geo mapping so that the user is able to see business
located in the city based on particulars. Some examples
are:
1. Renewals
30.2.2 2. Dormant Business (lapsed License renewal) 3
3. Types of Business (i.e. Liquor stores)
4. Hazardous Materials
5. City Limits (proper) (Fontana City vs. Fontana
County)
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 98 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must have
the Ability to have fields to capture information for
30.2.3 companies who deal with hazardous waste. 3
The proposed system when implemented must have
the ability to validate input against user-defined tables
30.2.4 such as SIC codes, NAIC codes, etc. 3
The proposed system when implemented must have
the ability to provide analysis of business by: street
30.2.5 address, user specified section of city and SIC codes. 3
The proposed system when implemented must have
30.2.6 the ability to validate input against system wide city 3
address table.
The proposed system when implemented must have
the ability to for Citizen/Customer/Applicant to use a
30.2.7 web page for inquiry using specific fields to search on. 2
(Initially owner name(s), business name, business
address and license number.)
The proposed system when implemented must have
the ability convert data elements from files received
from County office. Files include: Land Parcel, Zoning,
30.2.8 and Assessment File. File information is used for 2
Redevelopment, Labeling, Property info, Planning,
Business License, Tax and owner information.
The products would be web based notifications when
30.2.9 someone does an enquire via the Web (optionally 2
emails ), letters and mailing labels.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 99 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented will provide
interactive query and display capabilities for business
license information. This will include forms for the thick
client and prescribed web page forms for public (citizen)
access. Selection criteria shall include owner, business
30.2.10 name, and address. Security will be applied to each 3
field as to whether or not it can be viewed by the user.
(i.e. security would be applied to super user for viewing
of social security numbers )
The proposed system when implemented must have
the ability to lookup records using wildcards, i.e. Not
having to type the entire name in. Just type a few
letters and the rest of the name appears, or an
30.2.11 alphabetical listing of names appear to choose from. 3
Or put wildcards and search for last part of name.
Wildcard lookups should include business names and
address street part.
The proposed system when implemented must have
30.2.12 the ability maintain multiple owner information. 3
The proposed system when implemented must have
30.2.13 the ability maintain multiple business location 3
information.
There needs to be also note codes, or a list of
commonly used notes which can automatically be
30.2.14 inserted into the note field without having to type the 3
entire note in.
The proposed system when implemented must have
30.3.1 the ability to calculate penalties on Late payments and 3
track payments.
The proposed system when implemented must have
30.3.2 the ability to calculate tax amount using flat rate table. 3
The proposed system when implemented must have
the ability to tie Gross Sales Results to Franchise Tax
30.3.3 Board information to verify accuracy of Gross Sales. 2
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 100 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must have
the ability to track and report on items in a
comprehensive data element list that provides
30.3.4 information about the Business License subsystem(s). 3
Updated fields (meta data) showing who and when.
The proposed system when implemented must have
30.3.5
the ability to track account payment history 3
The proposed system when implemented must have
the ability to automatically update accounts receivable,
30.3.6 cash receipts accounts and general ledger subsystem 2
in one transaction.
The system shall allow for partial payment of business
30.3.7
license fees 3
The proposed system when implemented must have
the ability to charge business in Business Improvement
30.3.8 District an additional fee using a rate table based on 3
gross receipts.
The proposed system when implemented must have
the ability to calculate and bill the business license for:
30.3.9 flexible billing cycles, flat rate, gross revenue, rate table, 3
penalty and interest, and user defined criteria.
The proposed system when implemented must have
the ability to electively choose how partial payments will
30.3.10 be applied, either automatically by a fee code or 3
manually.
The proposed system when implemented must provide
30.3.11 for the entry of cash receipts for business license fees. 2
The proposed system when implemented must have
the ability to enter payment data such as check
number, amount, date, reference number, receipt
30.3.12 number, and batch number. Can be dynamically linked 3
to City's cash receipts subsystem.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 101 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must have
the ability to distribute fees to different G/L revenue
30.3.13 accounts based on the fee code or type of business 3
license.
The proposed system when implemented must provide
interactive business information maintenance including
30.3.14 the ability to add, change, and delete businesses. 3
The proposed system when implemented must for
30.3.15 business license must provide a web portal for the 3
public.
The proposed system when implemented must have
the ability to interface with A/P system to issue credit
30.3.16 payments for business workflow needs dealing with 3
over payments.
The proposed system when implemented must have
the ability to sequentially generate Business License
30.3.17 Tax Receipts account numbers automatically and 3
assign for new business.
The proposed system when implemented must have
30.3.18 the ability to handle special fees such as arcades, 3
special events, and street vendors.
The proposed system when implemented must have
30.3.19 the ability to meet State of California reporting 3
requirements under AB 3230.
The proposed system when implemented must have
30.3.20 the ability to handle volumes currently at any # of accts 3
on the master file.
The proposed system when implemented must allow
the user (or perhaps the super user) the ability to set
parameters required as a compliance part of the initial
billing. This would be seen as part of a work flow
30.3.21 30.3.22 process that would need to be completed prior to and/or 3
after payment. An example would be inspections and/or
code enforcement compliance.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 102 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must allow
the user using the business license module to review
30.3.22 30.3.21 compliance tasks for activity detail. Especially for 3
completion flags, dates, notes and signoff.
The proposed system when implemented must
provided a report of delinquent business license fees
30.4.1 which is aged by date due. This should be a SSRS 3
report
The proposed system when implemented must have
the ability to generate audit reports for all entry to serve
30.4.2 as audit trail for additions, deletions and changes. 3
The proposed system when implemented must provide
a report which lists all relevant information regarding
business operating in the municipality. This report shall
30.4.3 be available in long and short versions. This should be 3
a SSRS Report Items on the report would include
business name, type, address and license status.
The proposed system when implemented must provide
a flexible selection and sort criteria for the printing of
30.4.4 reports. These criteria shall include business type, 3
license and forms type (e.g. notices. licenses, etc.),
location, and due date.
The proposed system when implemented must provide
a monthly report showing new businesses by type with
30.4.5 fees. This should be using MS SQL Reporting 3
The proposed system when implemented must have
the ability to generate ad-hoc reports and catalog
30.4.6 command stream for future use. Must also have the 3
capability to create a list based on search and sort
criteria for export to Excel.
The proposed system when implemented must provide
30.4.7 the capability to print business licenses on official 3
forms.
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 103 of 104
City of Fontana
Release Date: 12/18/2009 Comprehensive Land Management System RFP (#SP-20-IT-10) Vendor:
Due Date: 2/16/2010 RFP Response Form
<VENDOR NAME>
FEATURE/FUNCTION CHECKLIST
Compl.
REF # Cross Feature Description Rating
Code*
Reference Cost
The proposed system when implemented must provide
the capability to use a laser printer to print the business
30.4.8 licenses form with a graphic of the city logo. The form 3
will need to print on a blank laser-perforated 8y x 11
sheet (normal weight.)
The proposed system when implemented must have
30.4.9 the ability to print reminder notices for delinquent 3
business license fees.
The proposed system when implemented must have
the ability to generate year end report that meets or
30.4.10 exceeds the CA Franchise Tax Board Regulations, 3
Section 19286.8.
The proposed system when implemented must have
the ability to launch reports created using MS SQL
Server Reporting Services from a menu and from the
30.4.11 screen/forms directly as required by the business flow. 3
The system must allow users to created sorted menus
for reporting and add new ones as necessary to the
menus.
Total Business License Application : Score - $ -
COF Fire Case (FPP) Bid Ref: 4.4
All business rules and specifications defined for
Building & Safety permits apply to Fire prevention COF Fire Case (FPP)
(FPP) cases as well.
The proposed system when implemented must provide
14.1.1 the capabilities to serve the business needs of the 3
City's "Fire" case (Fire CAP).
The proposed system when implemented for use with
the "Fire" CAP must provide the same functional
14.1.2 considerations as those defined for the Building and 3
Safety Permit as well as Building and Safety
Inspections.
The proposed system when implemented must provide
the same type of field application functionality and
14.1.3 considerations as the Building & Safety building 3
inspectors.
Total COF Fire Case (FPP) Score - $ -
* 3 = Included in delivered system
2 = Program modification (at cost)
1 = Workaround
55878c6f-fa1f-4235-86ea-495686edaff5.xls 0 = Not available Page 104 of 104
Related docs
Other docs by jzp18763
IDoc Types Messages of Release 4 5 IDoc Type Predecessor Message Type Message text German Message text E
Views: 967 | Downloads: 0
