Annex2 DetailedRequirementsspreadsheet

RFP PS20161055 Provision of Weigh Scale Management and Point of Sale System - ANNEX 2 - Detailed Requirements Spreadsheet
INSTRUCTIONS
The evaluation of the Proponent’s solution functional capabilities shall be based on the requirements stated in this document.
Therefore, the Proponent should present detailed information regarding the proposed solution’s capabilities.
Proponents must include all specifications tables in their response.

Proponents should first respond directly to each specification entry by placing an “X” in the applicable column in each row. Proponent’s may mark “X” in more than one column for a particular specification; however, the Proponent
should provide an explanation of why more than one column was marked. Descriptions of each column heading are provided in the table below.
Each specification not answered will result in an assumption that the Proponent cannot accomplish the specification and/or deliverable. The City seeks solutions that meet all specifications with minimal configuration required.
Use the Comments column, where applicable, to provide explanations and examples to ensure City Evaluators have a clear understanding of how the Solution provides the functionality.
For all requirement type specifications, if there is an associated cost for custom development and costs for its on-going maintenance support such costs must be stated in Commercial Proposal Pricing Table(s) as applicable.
If the Proponent fails to itemize the pricing for custom development, then The City shall not be able to consider that this requested function/capability is able to be fulfilled.
The Proponent shall use the numbering format provided in this document for ease of identification of the requirements in this document and to add explanatory details as necessary. The following answer key should be used when
responding to the requirements reflected herein.
Response Explanation
Yes = This feature is currently provided, or the software can be configured to provide the required functionality for the Weigh Scale Solution.
No = This feature is not currently provided, nor can the software be configured to provide the required functionality for the Weigh Scale Solution.
Third Party = Third Party Software will be integrated into the Weigh Scale Solution to provide the required feature and functionality.
Customization will provide the required feature and functionality to the Weigh Scale Solution. Customization would require new source code. The City is interested in knowing the degree of or level of effort
Customized= needed to provide the customization (i.e., minor customization that can be provided to The City within a week’s time, or a high level of effort for the customization requiring more than 6 months to provide to The
City, etc).
Use this answer key code to provide The City Evaluation Team with a response/explanation to the respective requirement, as applicable.
Proponents must supply details for requirements displaying <Comment Required> in the Comments column.
Comment =
Proponents are encouraged to provide details, for any requirement, to assist evaluators in understanding the functionality of the proposed Solution.
- For responses requiring graphics or exceeding 2-3 sentences, provide a note in the Comments column "See Annex 2A - Response Addendum" and use the provided file, described below.
Response Addendum
Explanation
Per Section (worksheet), up to 5 pages of screen shots and explanatory text may be included in the file "Annex 2A - Response Addendum for Annex 2" to supplement the responses in this Annex. Reference the
ID
ID of the requirement at the start of the response.
Annex 2 - Instructions
RFP PS20161055 Provision of Weigh Scale Management and Point of Sale System - ANNEX 2
Minimum Criteria for Submission

NOTE: These requirements are the minimum specifications which a proponent must offer in order to be considered viable, the proponent is expected to provide a corresponding project/c
Please Provide a Reference where this

ID Minimum Specification
Yes
No
has been implemented
All data collected must be readily available for active use (searching, display, reporting) for at least 16 months
1.01
in a production system environment.
Response times:
- all data collection: instant
- all transaction alerts: instant
1.02
- events: 30 sec
- offence alerts: 3 minutes
- notifications: 3 minutes
1.03 The solution must be compliant with the Canada Weights and Measures Act.
1.04 System must be able to operate independently of the central server in the event of a network issue.
Support City load cells and load cell indicators. Support and communicate with a number of load cell and load
1.05
cell indicator types (ex. Western Scales, Richmond Scales, Mettler Toledo).
1.06 Create unique transaction record for each transaction.
Associate unique transaction records to individuals/accounts and VehicleID. For commercial vehicles with a
1.07
trailer, store the Trailer ID also.
1.08 CDN Units. Weight measured in Kilograms, $CDN, etc.
All vehicle weights must be entered automatically into the system from the load indicator - weighmasters will
1.09
not be able to override.
1.10 Support 3 or more separate weigh scale facilities.
4/1/2016 Annex 2 1.0 Min Criteria

stem - ANNEX 2 - Detailed Requirements Spreadsheet
mission
vide a corresponding project/customer reference where this specification is currently in place.
e
ty
abl Comment
Par
miz
No
rd
sto
Th i
Cu
4/1/2016 Annex 2 1.0 Min Criteria

RFP PS20161055 Provision of Weigh Scale Management and Point of Sale System - ANNEX 2
Capability - Business Functionality Matrix
NOTE: These capabilities are the business unit specifications for the Weigh Scale Solution, the proponent is expected to provide details regarding the proposed solution functio
Cap ID Category Capability
Enable transaction categorization data to be collected efficiently, using a simple

2.01 Transactions interface and pre-defined lists of values for each category variable e.g. Material,
Origin, Vehicle Type, Destination, Payment Types, etc.
Enable complex Fee calculations. Fees vary by facility, time of day, material
2.02 Transactions type, customer type, origin, quantity limits, quantity ranges and any combination
of transaction or load characteristics.
Payment Processing: must handle multi-mode Payments, partial Payments,
inbound Deposits, Refunds, NSF. Payment types accepted: Account, Cash,
2.03 Transactions
Credit and Debit cards (Moneris), Vouchers, Cheques. Account payments may
require a signature image capture.
Ideally, integrated payment processing is available; must meet current PCI
2.04 Transactions
compliance requirements.
Enable Weighmasters to change transaction details including license plate
2.05 Transactions
number and payment type, with appropriate audit logging
Tickets - for account customers paper tickets may be optional. Individual
2.06 Transactions
electronic tickets should be e-mailed to the account holder.
2.07 Transactions Tickets must be re-generated and re-printed as needed.
Allow Mobile devices to be used by Yard Attendants to view and update open
2.08 Transactions Transactions. They must be able to enter verification of load materials and
quantities, enter adjustments to load materials and surcharges.
For Account Customers, maintain billing information, contact details, e-mail
2.09 Customers addresses for alerts and e-tickets, billing method (e.g. direct or third-party),
authorized lane type (e.g. Attended, Unattended).
Associate Customers with Profiles that define active data fields, default value
2.10 Customers
logic for transactions.
11/01/2023 Annex 2 2.0 Capability Matrix

Maintain lists of customer VehicleIDs with Active/Inactive billing permission.

2.11 Customers
Vehicles may be recognized by License Plate or RFID tag.
Commercial vehicles may have a stored tare for faster processing. Store the date
2.12 Customers the tare was measured, and provide method to periodically require the tare to be
updated.
(Desired) Web Portal integration for Account Customers to manage billing
2.13 Customers
permissions, and view transaction history.
2.14 Billing Enable large-volume commercial customers to charge fees to Accounts.
Allow Account customers to authorize hauler vehicles to cross-bill to their
2.15 Billing account, using Hauler VehicleID and defined time span. Include Origin and
Material Type in authorization.
Track available credit for Account customers; automatically set a Charge Lock
2.16 Billing
when credit is exhausted.
Alert Weighmasters to Accounts with Dump Locks or Charge Locks in effect
2.17 Billing
when an associated vehicle enters the facility.
2.18 Offences Associate Offence incidents with VehicleID and Owner/Billing account.
Enable details of specific types of Offences to be sent to an external system for
2.19 Offences advanced workflow. E.g. Safety or Regulatory Violations require immediate
notifications to Supervisors and follow up actions.
Enable Offence Status to be updated from external system, e.g. using API or
2.20 Offences
web service.
Alert Weighmaster to open Offences for an inbound Vehicle . Enable
2.21 Offences
Weighmasters to view Offence history for Vehicle/Account.
Enable Administrative Users to register approved Waste Assessments to
2.22 Waste Assessments Vehicle/Account. Record material type, date range, maximum quantity (total or
loads per day), and status.
Alert Weighmaster if an open Waste Assessment is registered for the
Vehicle/Account, display remaining allocation and allow the Weighmaster to
2.23 Waste Assessments
Confirm if it is applicable to the incoming load. Decrement allocations as
transactions occur.
At an unattended scale, automatically decrement allocations for matching
vehicle/account/material type loads.
Alert Weighmaster if Waste Assessment allocation is overdrawn. Site admission
will be at the Weighmaster's discretion.
Enable vehicles to be recognized by License Plate reader, or RFID tag on
2.26 Automation
windshield.

Unattended Scales - allow registered vehicles to enter facility via lane with
2.27 Automation unattended scale. Pre-set load description and billing information is to be
confirmed or corrected by the driver.
Photos of vehicle License Plates and Loads are to be saved with each
2.28 Automation
transaction. Weighmasters can preview images and re-take if necessary.
Weighmasters can monitor and intervene in a transaction on an unattended scale
2.29 Automation
from a remote workstation.
Weighmaster reconciliation tool for end of shift must report each payment type,
2.30 Reconciliation
including Deposits and Refunds.
Provide tool for Daily reconcilation for the facility which aggregates all
2.31 Reconciliation
Weighmaster records for the day.
2.32 Reporting and Analytics Weighmasters need to query the activity logs to resolve transaction errors.
Numerous reports on revenue, traffic and materials are required; a broad range
of canned reports with user-selected parameters for dates and categories must be
2.33 Reporting and Analytics
provided. Also ensure the system works with the City's reporting and BI
software for ad hoc reporting and dashboard integration.
For internal customers, validate Work Order number from City-provided daily
2.34 Integration
list.
2.35 Integration Export transaction data to billing systems daily after Reconciliation.
2.36 Integration Export material quantities to inventory systems daily after Reconciliation.
2.37 Integration Update Available Credit for Account Customers when a payment is received.
Enable different intake/payment processes based on lane type: attended scale,
2.38 Lane Management
unattended scale, bypass lane
Enable easy lane configuration changes in response to traffic volume. (Desired)
2.39 Lane Management
Use predefined processes to ensure consistent setups are used.
(Desired) Enable staff training on a cloned configuration of the production
2.40 Training
system, with simulated transactions.
Support and System Single point of contact for City relating to Weigh Scale Solution
2.41
Details issues/questions.
Support and System
2.42 Establish Service Level Agreement.
Details
Support and System Each facility must be able to operate independently, without access to the central
2.43
Details server in the event of a service disruption.
Support and System
2.44 System is expected to prevent data loss, and operate in High Availablility mode.
Details

Support and System Performance should be such that no response delays are evident to the
2.45
Details Weighmasters, Yard Attendants or Drivers using unattended scales.
Support and System Coordinate with City Support staff to resolve hardware, software and operating
2.46
Details issues quickly.

Management and Point of Sale System - ANNEX 2 - Detailed Requirements Spreadsheet
Capability - Business Functionality Matrix
, the proponent is expected to provide details regarding the proposed solution functionality which will enable the business unit to achieve the associated capability.
e
ty
abl
Comment
Par
miz
Associated Functionality within Proposed Solution
Yes
No
rd
sto
Th i
Cu

e
ty
abl
Comment
Par
miz
Yes
No
rd
sto
Th i
Cu

e
ty
abl
Comment
Par
miz
Yes
No
rd
sto
Th i
Cu

e
ty
abl
Comment
Par
miz
Yes
No
rd
sto
Th i
Cu
0 0 0 0

RFP PS20161055 Provision of Weigh Scale Management and Point of Sale System - ANNEX 2 - Detaile
Spreadsheet
Functional Requirements - Global
le
Mandatory /
rty
zab
Critical /
Pa
Req. ID. # Category Description
mi
No
Ye
Desirable /
ird
sto
Optional
Th
Cu
All data collected must be readily available for active use (searching, display,
3.0.01 Data Availability Mandatory
reporting) for at least 16 months in a production system environment.
Response times:
- all data collection: instant
Near Real Time
- all transaction alerts: instant
3.0.02 Alerts and Mandatory
- events: 30 sec
Notifications
- offence alerts: 3 minutes
- notifications: 3 minutes
Weights and
3.0.03 Measures Act
Compliance The solution must be compliant with the Canada Weights and Measures Act. Mandatory
All database edits, notifications and customer transmissions must be logged for
audit. Users must be able to query the logs for specific events or recent activities
3.0.04 Audit Trail Critical
and view filtered log reports, using a simple interface with fields for search and
sorting parameters.
3.0.05 Data Availability All data collected must be retained for at least 5 years in an archive format. Critical
The proposed solution should have the capability for the City to define data
Data Value
3.0.06 formats. Critical
Formatting
All weight data should be recorded natively in metric format.
All system functionality must be available to City users 24hrs per day 365 days per
System
3.0.07 year (with an exception to be made for scheduled updates and system maintenance - Critical
Availability
subject to agreement SLA).
Date formatting should be configurable e.g. YYYY-MM-DD or MM/DD/YYYY
3.0.08 Date / Time Critical
and Time formatting should follow 24hr clock (HH:MM:SS).
The date/time should be reported in local time and be capable of automatically
3.0.09 Date / Time Desirable
adjusting for daylight savings time.
Viewing and updating of active transactions should be possible using a handheld
3.0.10 Mobile devices Desirable
device or tablet.
11/01/2023 Annex 2 3.0 Global

le
Mandatory /
rty
zab
Critical /
Pa
mi
No
Ye
Desirable /
ird
sto
Optional
Th
Cu
0 0 0 0
11/01/2023 Annex 2 3.0 Global

m - ANNEX 2 - Detailed Requirements
Comment
<Comment Required>
11/01/2023 Annex 2 3.0 Global

Comment
11/01/2023 Annex 2 3.0 Global

RFP PS20161055 Provision of Weigh Scale Management and Point of Sale System - ANNEX 2 - Detailed Requirements
Spreadsheet
Functional Requirements - Communications
le
Mandatory /
rty
zab
Critical / Comment
Pa
mi
No
Ye
Desirable /
ird
sto
Optional
Th
Cu
All system functions are available from administrative offices
3.1.01 Data Analysis Critical
throughout the City network.
Ensure the system communicates with site peripherals (example:
traffic gates, traffic control lights, traffic sensors, swipe card
readers, scale scoreboard, thermal printers, RFID transponders,
3.1.02 General Critical
image capture technology (license plate and load images), optical
codes (barcode or QR code), image interpretation technology
(license plate reader).
<Comment Required>
Allow for paperless transactions. Ability to send payment tickets
3.1.03 Billing Critical
electronically (i.e. email), in addition to or in lieu of paper tickets.
Communication with City Financial Systems (Tempest and SAP).

3.1.04 Billing Transaction details must download daily for transfer to the Critical
appropriate financial system, after an initial audit.
Correlate inbound/outbound transactions between locations. For
3.1.05 Data Analysis example, link an outbound transaction from one facility to an Critical
inbound transaction at another facility.
Handle data originating from different source locations (such as
3.1.06 Data Analysis Metro Vancouver’s scale system) in an open format (i.e. XML, Critical
CSV, txt file, MS Excel).
Able to use RFID (radio frequency technology). Allow for vehicles
3.1.07 General to be identified into the system based on radio frequency identifier Critical
mounted on vehicle.
<Comment Required>
Able to use image capture technology (license plate and vehicle
3.1.08 General load). Allow for all transactions to include an association to and Critical
data derived from a Vehicle License Plate and load photo.
<Comment Required>
Logic to trigger email notifications, e.g. for credit issues, specific
3.1.09 General Desirable
offences, expiry of Waste Assessments, outdated stored Tares.
Integration with City web portal for account clients - to manage

Vehicle list, and billing assignments.
Sum 0 0 0 0
11/01/2023 Annex 2 3.1 Communications

Spreadsheet
Functional Requirements - Configuration
le
Mandatory /
rty
zab
Critical / Comment
Pa
mi
No
Ye
Desirable /
ird
sto
Optional
Th
Cu
System must be able to operate independently of the central server in <Comment Required>
3.2.01 IT Mandatory
the event of a network issue.
Support City load cells and load cell indicators. Support and
3.2.02 Scales communicate with a number of load cell and load cell indicator types Mandatory
(ex. Western Scales, Richmond Scales, Mettler Toledo).
Local storage and backups (Disaster recovery and Independent
3.2.03 IT Operations). All data to be initially stored at local site, in a local Critical
server.
Ensure current data fields are collected. System data format must <Comment Required>
accept current data formats for Account #, account details, material
3.2.04 Data Critical
types, source location, license plate details - commercial account,
residential account.
Business rules within the solution should be configurable by
authorized users to allow for changes to the business rules without
3.2.05 Business Rules Critical
necessitating a full solution release (business rules should not be
hard-coded within the proposed solution).
Allow Administrative Users to specify fields to contain system <Comment Required>
3.2.06 Data default values within user entry forms and turn on/off default setting Critical
for specific customer profiles.
Allow Administrative Users to Add/Edit/Delete system default values
used within user entry forms.
System must store financial system association by transaction type
(e.g. credit card or City account). Administrative users can specify
which financial system is to receive daily transaction records, based
on transaction type.
Allow Administrative Users to specify time limitations (logic) for <Comment Required>
3.2.09 Business Rules certain transaction types. For example, Residential dump for material Critical
type: Asbestos - 1 transaction per 24hrs.
Allow Administrative Users to specify quantity limits (logic) for <Comment Required>
3.2.10 Business Rules certain transaction types. Example: size of residential load of Critical
asbestos.
Allow for previous transaction values to be used as defaults for
certain fields in user entry forms at the next visit.
Ability to add/edit/delete users, in particular for these roles: <Comment Required>
a) Weighmasters
b) Yard Attendants
c) Administrative Users
d) Support and System Administrators
e) Service Accounts for system integration
3.2.13 General Create audit log entries for all configuration changes. Critical
11/01/2023 Annex 2 3.2 Configuration

le
Mandatory /
rty
zab
Critical / Comment
Pa
mi
No
Ye
Desirable /
ird
sto
Optional
Th
Cu
Tickets to display (minimum) facility header, date and time in/out,
itemized list of materials, quantities and rates, surcharges, fines,
vouchers, transaction charges, total fee, Transaction ID, Vehicle ID,
payment type(s) and (opt) signatures.
Sum 0 0 0 0
11/01/2023 Annex 2 3.2 Configuration

Functional Requirements - Data Management and Integration
le
Mandatory /
rty
zab
Critical / Comment
Pa
mi
No
Ye
Desirable /
ird
sto
Optional
Th
Cu
3.3.01 Transaction Create unique transaction record for each transaction. Mandatory
Associate unique transaction records to individuals/accounts and
3.3.02 Transaction Mandatory
VehicleID.
Store Account information. For commercial accounts: the commercial
invoice information, cross-billing capability, and email addresses
3.3.03 Accounts Critical
(contact, billing authorization, e-tickets) should be stored in the system.
Store Hauler information. For commercial accounts using independent

3.3.04 Accounts haulers, the hauler information and email addresses (contact, e-tickets) Critical
should be stored in the system.
3.3.05 Accounts Accounts must be tagged with Customer Type Critical
Store cross billing information to a commerical account. For <Comment Required>
commercial accounts using a hauler from a different company, the
hauler's Vehicle ID and account must be noted as a Billing Assignment
3.3.06 Accounts Critical
under the commercial account with material type and schedule
limitations . Authorization activities must be logged and available for
reporting to the commercial account holder.
3.3.07 Accounts Store credit limits for commercial accounts with an alert threshold Critical
Automatically send alerts to commercial account contacts when credit
3.3.08 Accounts alert threshold or credit limit is reached. Set a Charge Lock on the Critical
account if credit limit is reached.
Material Types with descriptive labels; for each material type indicate
3.3.09 Code Definition Critical
if fees are calculated by weight, per unit or flat fee.
Minimum 5 transaction category fields each with a restricted list of <Comment Required>
values and descriptive labels. The list of values and labels can be
edited and updated by Administrative Users. Currently used for
Customer Type, Origin, Vehicle Type, Transaction Type.
Offence definitions. Indicate if immediate management notification is
required when an instance of the specific offence is recorded.
Definitions can be edited and updated by Administrative Users.
Offence Status labels must be defined and the initial value set per
offence. As an Offence is processed the Status label should be updated
by staff.
Driver Beat and/or Route Number. The format of the beat or route
3.3.12 Code Definition number can be specified by the Administrative User and the Critical
alphanumeric values can be edited and updated by the Users.
All transactions throughout the system (locations) should be uploaded <Comment Required>
to a central server (off site).
The proposed solution must be able to store historical data - which may
3.3.14 General be retrieved at any point, for a period of 5 years in a secure and Critical
accessible data structure.
11/01/2023 Annex 2 3.3 Data Management

le
Mandatory /
rty
zab
Critical / Comment
Pa
mi
No
Ye
Desirable /
ird
sto
Optional
Th
Cu
Track Open/Closed transactions. Users must be able to view Open
transactions easily, and review the current day's Closed transactions.
Audit trails. All transactions must be able to be tracked through a paper

trail and an electronic audit trail.
<Comment Required>
Enable users to find specific records in the accounts, transactions and
approved Waste Assessments using search criteria on selected fields
All lanes in a facility should allow for input and output from any
workstation in the same facility.
Store weight to nearest 5kg in compliance with Weights and Measures
3.3.19 Transaction Critical
Act.
Per transaction: Track category variables, material types and quantities,

weights, time in, time out, license plate and load photos, status.
Pre-populate data fields with default values relevant to vehicle and <Comment Required>
account type. [Desired] Use method specified in Customer Type
Profile; e.g. for non-account customers information from the most
recent transaction associated with the Vehicle is displayed, for Account
customers display the authorized billing account name and material
type.
Track Work Order. For specific customer type profiles, collect the <Comment Required>
3.3.22 Transaction alphanumeric City Work Order number. Apply validation rule to Critical
ensure correct format.
Track Driver Beat and/or Route Number. For specific customer type <Comment Required>
3.3.23 Transaction profiles, allow for the input of a beat or route number that is associated Critical
with the transaction.
Track PaymentType(s). Payment may be split across multiple methods.

a) Residential: Allow users to select what type of payment to be used
(Cash, Credit, Voucher, etc)
3.3.24 Transaction b) Commercial: Allow users to select what type of payment to be used Critical
(Cash, Credit, account (i.e. future invoice))
c) Internal: Allow users to select what type of payment to be used
(Cash, Credit, account (i.e. future invoice), transfers or work orders)
Track available credit for commercial customers and display alert to <Comment Required>
Weighmaster when available credit drops below defined threshold
Stored Tare vehicle weights for commercial vehicles. The system must <Comment Required>
indicate a stored tare is present, flag if it requires update, and allow the
user to clear the tare. For vehicles with stored tare for a trailer, allow
the user to disable the trailer tare for the current day.
Signature image. Ability to store captured signature image with
transaction.
Update commercial vehicle tares based on rule (e.g. random, min #
3.3.28 Transaction trips, max # trips, annually). Alert Weighmaster/Driver on scale entry Critical
to update vehicle tare on exit.

le
Mandatory /
rty
zab
Critical / Comment
Pa
mi
No
Ye
Desirable /
ird
sto
Optional
Th
Cu
Store tare weights for commercial vehicles. Commercial vehicle should
3.3.29 Vehicles be associated with commercial or hauler accounts. Store the date the Critical
tare was updated.
Set a Dump Lock on vehicles with Offences that need attention. The
3.3.30 Vehicles Dump Lock must be communicated to the central server in near real- Critical
time (<3 minutes).
Accounts must be tagged with Status: Active, Inactive or Closed;a date
3.3.31 Accounts Desirable
should be stored for each change in status.
<Comment Required>
Customer Type Profile. Different data is collected for specific customer
types, with varying logic for retrieving defaults. The Weighmaster
3.3.32 Code Definition screens and reports should use the defined profiles to optimize the data Desirable
entry experience, control validation and assist in reporting. The
Customer Type is also used in Rate and Fee calculations.
Voucher Types. Voucher values, effective dates, Origin code and

3.3.33 Code Definition descriptions . Definitions can be edited and updated by Administrative Desirable
Users.
3.3.34 General Track users flow within sites and between sites (path codes). Desirable
Alert Administrative Users at the conclusion of the day if there remain
any Active transactions within the system.
Waste Assessments: Alert Weighmaster of active Waste Assessments
and remaining allocations, matching vehicle/account and material type.
3.3.36 Transaction Weighmaster to confirm if current transaction applies to Waste Desirable
Assessment and system to adjust available allocation on transaction
close.
Waste Assessments: For unattended processing, automatically apply

3.3.37 Transaction Desirable
loads to active Waste Assessments with matching vehicle/account.
GVW Check: Recall stored GVW for commercial vehicles and display
on Weighmaster's screen. If scale Gross Weight exceeds GVW by a
threshold value alert the Weighmaster. Provide option to automatically
generate an Offence.
Provide the ability to create transactions offline (not in "real time"). <Comment Required>
3.3.39 Transaction System is able to create transactions in past/future dates without Desirable
changing date setting on computer.
For specific lanes (bypass) define logic by customer type for <Comment Required>
processing inbound vehicles. E.g. recall most recent Outbound
transaction from a different facility to provide Inbound data (facility-
to-facility transfers)
<Comment Required>
Provide a method to treat loads containing multiple weighed material
types as a single transaction. After dumping each material type the
vehicle is re-weighed to gather the intermediate tare weights; the goal
is to collect a single payment at the final exit of the vehicle.

le
Mandatory /
rty
zab
Critical / Comment
Pa
mi
No
Ye
Desirable /
ird
sto
Optional
Th
Cu
<Comment Required>
Provide a method to handle roll-off bins placed at the facility to collect
recyclable materials. The bins may be delivered and picked up by
3.3.42 Transaction different trucks, requiring the bin tare to be stored independent of the Desirable
truck. On removal from the site the weight of the bin contents must be
determined and stored as the appropriate material type.
Associate RFID tag to license plate number; track status of RFID tag:
3.3.43 Vehicles Desirable
Active/Inactive/Closed
3.3.44 Vehicles Store GVW for commerical vehicles. Track the date of entry. Desirable
Retain Offences by Vehicle ID and Account. Once an offence has been
addressed by administration, the offence notification should be
3.3.45 Vehicles Desirable
disabled and its status adjusted, however the history of offences should
remain with the vehicle/account information.
Maintain a list of approved waste assessments, associated with either a

vehicle or account. Store the material type, range of dates, total
quantity or maximum loads per day allowed and a link to the approval
3.3.46 Waste Assessments document(s) and lab test results. Update status (Active, Max, Closed), Desirable
and current available quantity/loads as transactions occur.
Automatically update fields daily (status, daily allowances).
Administrative users can modify all fields.
Total 0 0 0 0

Functional Requirements - User Interface and Edits
le
Mandatory /
rty
zab
Critical / Comment
Pa
mi
No
Ye
Desirable /
ird
sto
Optional
Th
Cu
3.4.01 User Interface CDN Units. Weight measured in Kilograms, $CDN, etc. Mandatory
3.4.02 Edits Allow for manual Vehicle License Plate data entry into transaction. Critical
All transaction edits, which have been placed into a modification log, must be searchable <Comment Required>
3.4.03 Edits by selected field, ex. Edit type, Date, User, Transaction type, Material type, Payment Critical
type.
All edits of transactions to be entered into a modification log with transaction ID,
3.4.04 Edits Critical
username, date and time. Optionally workstation ID and mode: interactive or batch.
Store history of system data edits, example: fee calculation changes. All edits to code <Comment Required>
3.4.05 Edits definitions (e.g.: material type specifications, offence types, origin) should be retained Critical
but not displayed as options - keep for historical tracking purposes.
3.4.06 Edits All edits/updates provide a method to record the reason for the change. Critical
Allow users to modify Payment Type(s), with automatic logging of the edit, on the same <Comment Required>
3.4.07 Edits day of the transaction. E.g. customer states they will pay with Visa, then uses Critical
Mastercard instead.
Allow users to override automatic data entry fields with manually entered values
3.4.08 Edits Critical
(license plate reader, default values), except weighscale indicators.
Administrative Users may make adjustments to reconciled transactions. The adjusted <Comment Required>
3.4.09 Edits records must be identifiable in order to generate updates to the City financial and Critical
inventory systems.
3.4.10 Edits Transaction edits limited based on user group. Critical
Complete Online Help and User Documentation. Documentation for the system must
3.4.11 User Interface Critical
outline the functionality of each component of the system.
<Comment Required>
Comprehensive, user-understandable error messages. If an error were to be encountered
3.4.12 User Interface by a user, the message sent back to the user would outline the functionality in error and Critical
the likely cause of the error. Includes error messages that can be customized.
System must be able to search existing and historical data. Should contain standard <Comment Required>
3.4.13 User Interface query specifications as well as user defined queries available (For Example: By license Critical
Plate, By Material Type, By Commercial Account, By Date)
Allow Administrative Users the ability to add a standard message associated with all
3.4.14 User Interface Desirable
transactions, per facility.
CDN References. Addressing information must allow for provincial and postal code
references.
User friendly troubleshooting. If a component of the infrastructure associated with the <Comment Required>
3.4.16 User Interface system were missing/unresponsive - a notice would be logged/sent to the user as to the Desirable
issue and how to possibly resolve the issue.
Windows look and feel (usability - application functions). Allowing for common
3.4.17 User Interface windows defaults, "ctrl-C" copy; "ctrl-V" paste. Change mouse cursor to indicate Desirable
processing activity.
3.4.18 User Interface The Solution should allow users to display information in a multiscreen environment Desirable
Ability to easily accommodate ergonomic requirements (e.g. left-handed operator, high
contrast, magnified screens, text-to-speech)
11/01/2023 Annex 2 3.4 User Interface & Edits

le
Mandatory /
rty
zab
Critical / Comment
Pa
mi
No
Ye
Desirable /
ird
sto
Optional
Th
Cu
Ability to provide both menu and function access that is consistent throughout different
modules or user/administrator interfaces
Simplified, easy-to-read screen designs for data collection from drivers on unattended
lanes
Ability to enable/disable specific Transaction data fields based on customer type profile, <Comment Required>
and perform validation only on enabled fields.
Preview of time-stamped license plate and load photos; reject and retake photos if
necessary
Allow for variety of user input devices including keyboard, optical code scanner, mouse,
touch screen, tablet and mobile devices.
Provide method to update status on multiple Offence records, selected by user criteria.
3.4.25 Edits Desirable
E.g. change status to Closed on offences older than 3 years.
Multiple record edits. Administrative Users must have the ability to select and edit <Comment Required>
3.4.26 Edits multiple records within a single edit transaction. E.g. corrections to the billing account Desirable
for a group of hauler transactions.
11/01/2023 Annex 2 3.4 User Interface & Edits

Functional Requirements - Financial
le
Mandatory /
rty
zab
Critical / Comment
Pa
mi
No
Ye
Desirable /
ird
sto
Optional
Th
Cu
Allow Administrative Users to identify payment type associations with customer
3.5.01 Billing accounts. Administrative Users can associate vehicle information with customer Critical
accounts in order to access account details.
Billing Assignments. Allow Administrative Users to associate certain vehicles with <Comment Required>
3.5.02 Billing the ability to bill and cross bill accounts, and set limitations on dates and quantity Critical
to cross bill accounts.
Allow the system to lock accounts. For locked accounts (depending on the lock <Comment Required>
3.5.03 Billing type) invoicing/site access will not be allowed during the locked period, but the Critical
information is available from the system.
Allow Administrative Users to specify refunds on individual transactions.

3.5.04 Billing Administrative Users may specify refund amounts to commercial accounts, or Critical
credits to vehicle IDs for residential and commercial non-account transcations.
Fee Calculation. The system must automatically do complex fee calculations based <Comment Required>
on customer characteristics, time of day, material type, quantity thresholds,
surcharges, fines, vouchers, facility, etc. Keep historical fee calculation rules for
traceability.
Rounding. System will allow rounding of transaction values, such as fees for cash
payments only.
3.5.07 Business Rules Automatically calculate line item fees based on the appropriate rates. Critical
3.5.08 General Allow for mixed payment type (example: 1/2 cash, 1/2 credit). Critical
Allow for a variety of payment types. Payment types to include: Debit, Credit,
Deposit, Cheques, Cash, Account, NSF, Voucher, Work Order, Subsidy.
3.5.10 General Allow multi-material transactions for customers to occur on one ticket. Critical
<Comment Required>
3.5.11 Reconcilation Provide transaction totals by payment type for Weighmaster end-of-shift reports. Critical
Weighmaster end-of-shift reports must include Deposit funds collected and credited <Comment Required>
3.5.12 Reconcilation Critical
to allow balancing across the site lanes.
Weighmaster end-of-shift reports must include NSF totals to track non-payment of
3.5.13 Reconcilation Critical
fees for transactions.
Indicate weight entry type on transaction record in database (automatic, manual,
3.5.14 Scales Critical
administrative override).
<Comment Required>
Input the calculated total directly into the debit/credit machine from the system.
Once the rate has been calculated and the total indicated, depending on the payment
3.5.15 General option selected, the total is directly entered into the payment system. Return the Desirable
payment method actually used and automatically correct the transaction field if
necessary. The solution must be PCI compliant (see also Security requirements).
Sum 0 0 0 0
11/01/2023 Annex 2 3.5 Financial

Functional Requirements - Reporting and Analytics
le
Mandatory /
rty
zab
Critical / Comment
Pa
mi
No
Ye
Desirable /
ird
sto
Optional
Th
Cu
<Comment Required>
Provide examples of basic canned reports, with parameters for date ranges and
category variables. For example:
a) Offence
b) Commercial Accounts Summary
c) Transaction Edits
3.6.01 General d) Transaction Calculations Critical
e) Material Type from Source
f) Material Type from Source with Account
g) Material Balance between Sites
h) Vouchers
i) Consolidated Materials
Ability to re-generate ticket to match original ticket, for re-printing or electronic

3.6.02 Billing distribution. All transaction records should be able to be re-generated at any time by Critical
system users.
Generate flat-file reports of new billing and billing adjustments for transfer to the City <Comment Required>
billing system
Generate flat-file reports of material types and quantities by Work Order for transfer
to the City Engineering systems
Output scale usage reports. For example, summary of scale usage during a specified
time period (Typical values: time in use, number of customers).
Allow for user specified and ad hoc report generation, in addition to canned reports <Comment Required>
available from the system. Allow sorting and filtering.
Extract reports from logs for configuration changes or transactions, with parameters <Comment Required>
for date ranges and activity type.
All reports, canned or configured, must have the capability to define the user access <Comment Required>
group which has permissions to run & retrieve the data.
Generate summary page of detailed reports. Condense the various detailed columns to
an "executive summary" page - to be user defined.
3.6.10 General Interface with SQL Server Reporting Services 2008 or later version. Desirable
Screen display of report previews. A complete preview (similar to Adobe) of all
reports and queries before printing.
3.6.12 General Reports can be saved as PDF, Excel or CSV formats Desirable
Report printing. System must allow users to limit the amount of report material to be
printed (single page, range of pages, entire report).
Provide functions to group data based on business rules set by Administrative Users; <Comment Required>
ensuring easy re-use and consistent reporting.
Waste Generate report of Expected Quantities of approved Waste Assessment materials, by
3.6.15 Desirable
Assessments day, by week with list of haulers and vehicle IDs
Total 0 0 0 0
11/01/2023 Annex 2 3.6 Reporting

Functional Requirements - Weights and Measures
le
Mandatory /
rty
zab
Critical / Comment
Pa
mi
No
Ye
Desirable /
ird
sto
Optional
Th
Cu
All vehicle weights must be entered automatically into the system from the load
3.7.01 General Mandatory
indicator - weighmasters will not be able to override
Store weight to 5kg precision; small loads require this precision, large loads require
10kg precision. Federal inspectors in BC have been requiring the 5kg precision.
In locations with multiple scale decks, the individual axle weights and total weight
must be indicated within the transaction and on the resulting transaction ticket
Sum 0 0 0 0
11/01/2023 Annex 2 3.7 Weights and Measures

Spreadsheet
Technical Requirements - Extensibility, Performance and Scalability
le
Mandatory /
rty
zab
Critical / Comment
Pa
mi
No
Ye
Desirable /
ird
sto
Optional
Th
Cu
Support 3 or more separate weigh scale facilities. Describe incorporation of <Comment Required>
3.8.01 Extensibility additional facilities and maximum number of facilities the system can Mandatory
manage.
The City must have database access to create/maintain custom interfaces to <Comment Required>
3.8.02 Extensibility other systems. The preferred method would be via web service or API to Critical
ensure database integrity is preserved.
<Comment Required>
Flexibility to incorporate changes in the number of scales and lanes within a
3.8.03 Extensibility Critical
weigh scale facility. Indicate the maximum number of lanes supported.
Transaction volume and throughput - System must support minimum: <Comment Required>
Performance & - 600 open transactions at a site
3.8.04 Critical
Scalability - 200 transactions per hour per site
- 700000 transactions per year in central server
Performance & System must support minimum 3 sites with multiple lanes communicating to
3.8.05 Critical
Scalability central server
System must have 0% data loss for transactions within and between City <Comment Required>
Performance &
3.8.06 sites. In the event of errors or failures, it must have methods to retry and/or Critical
Scalability
identify a data transmission error.
Performance & System must be architected to operate through a full day without scheduled
3.8.07 Critical
Scalability system reboots
System Performance of 24 hours per day, 7 days per week, 365 days per
Performance &
3.8.08 year; System must provide 99.99% uptime outside of scheduled monthly Critical
Scalability
maintenance outages
Performance & <Comment Required>
3.8.09 System must be able to failover to standby system Critical
Scalability
API for custom application development; should allow full SCRUD <Comment Required>
3.8.10 Extensibility Desirable
functionality. Include documentation and examples.
Web Service endpoint, preferably REST, providing basic SCRUD <Comment Required>
functionality. Include documentation and examples.
Mobile device access for transaction data collection and updates to open <Comment Required>
transactions, with example source code
Total 0 0 0 0
11/01/2023 Annex 2 3.8 Extensibility & Performance

Spreadsheet
Nonfunctional Requirements - IT Standards and Security
Preface: City Standards and preferred tools are listed below.
Indicate if the Proponent's Solution is compatible
le
Mandatory /
rty
zab
Critical / Comment
Pa
mi
No
Ye
Desirable /
ird
sto
Optional
Th
Cu
System must store data in Microsoft SQL Server 2008 R2 or more recent
4.1.01 IT Standards Critical
version; or Oracle 11g or more recent versions
Server Operating System: Windows Server 2012 or Windows Server 2016, in a
virtual server environment.
4.1.03 IT Standards Active Directory domain authentication. Critical
4.1.04 IT Standards Database Corruption Recovery. Nightly backups of data to an off-site location. Critical
System must be compatible with City Standard Backup System (NetApp
SnapMirror 8.3x).
The end-user solution shall be certified to run in Microsoft Windows 7 64-bit
and later operating solutions on ‘locked down’ workstations (workstations with
no administrative privileges). Windows 8.1 may be used on touch-screen
devices.
The workstations must be able to be accessed from users within the City's
internal network or from off-site by Support staff
The solution should allow for 3rd party reporting tools to pull data from the <Comment Required>
solution to satisfy unanticipated reporting requirements
4.1.09 IT Standards Microsoft SQL Server Reporting Services 2008 Critical
Where applicable, the end-user solution shall support either Google Chrome or
Internet Explorer 11+ for the browser-based components of their solution.
11/01/2023 Annex 2 4.0 IT Standards & Security

le
Mandatory /
rty
zab
Critical / Comment
Pa
mi
No
Ye
Desirable /
ird
sto
Optional
Th
Cu
The COV supports the following standards:
- Java Message Service (JMS) API v1.0.2
- JavaScript Object Notation (JSON)
(also - GeoJSON)
- Extensible Markup Language (XML) v1.0 and related specifications (e.g.,
XML Namespaces, XML Signature, XML Encryption)
- Representational State Transfer with a XML MIME (Multipurpose Internet
Mail Extensions) type
- Simple Object Access Protocol (SOAP) v1.1 and v1.2
4.1.11 IT Standards Desirable
- Web Services Description Language (WSDL) v1.1 and v2.0
- Web Services Security (WS-Security or WSS) – Username Token Profile
v1.0 and X.509 Token Profile v1.0
- Hypertext Transfer Protocol (HTTP) v1.0 (IETF RFC 1945) and v1.1 (IETF
RFC 2616)
- Hypertext Transfer Protocol Secure (HTTPS), also known as HTTP over TLS
(Transport Layer Security) (IETF RFC 2818)
The Proponent's solution must integrate with COV applications using these
standards.
Web-based interfaces should incorporate Responsive Web Design

4.1.12 IT Standards Desirable
fundamentals
<Comment Required>
All information will be encrypted to acceptable security standards, both "at
rest" and "in transit". The data includes personal information (such as license
4.2.01 Security Critical
plate/license information), and potentially, financial information (if using
integrated payment processing for credit/debit card info, PCI standards apply).
The solution must monitor and log all security events. <Comment Required>
The solution must alert administrators of suspected security violations.
4.2.03 Security Allow Administrative Users to add/edit/delete RFID account information. Critical
Username/Password Management. Conforms to City security standards,
preference for City AD domain authentication for internal accounts.
If not using City domain authentication:
a) Enforce periodic password changes (the City standard is every 60 days);
b) Enforce a minimum password length (the City standard is 7 characters);
c) Enforce requirement that passwords contain alpha and numeric characters
and symbols; and
d) Prevent assigning of a previously used password.
The application must be able to pass annual vulnerability testing of account
management and security protocols, as conducted by the City.
Limit the system functionality available to the user based on their <Comment Required>
username/group association.
4.2.07 Security Limit certain transaction edits to specific user roles. Critical

le
Mandatory /
rty
zab
Critical / Comment
Pa
mi
No
Ye
Desirable /
ird
sto
Optional
Th
Cu
The Proponent shall ensure that all security updates to the solution, including, <Comment Required>
4.2.08 Security but not limited to, the application, operating solution, and databases are Critical
incorporated within 30 days of their release.
Time-stamped photos of License Plates and Loads will be used to provide
proof of entry.
4.2.10 Security Automated scales - restrict access to authorized account customers Critical
<Comment Required>
All web services associated with the solution must incorporate security
protocols, such as those listed below or their successors:
- Web Services Security (WS-Security or WSS) – Username Token Profile
v1.0 and X.509 Token Profile v1.0
- Hypertext Transfer Protocol Secure (HTTPS), also known as HTTP over TLS
(Transport Layer Security) (IETF RFC 2818)
<Comment Required>
Integrated payment processing. Describe the application's capabilities for
working with PCI-compliant payment channels that deal with in-person
transactions. An overview of the proven security architecture would be useful
4.2.12 Security Desirable
in assessing if the proposed system would meet the City's strict PCI
compliance requirements. The Proponent shall indicate if a Letter of
Attestation can be provided upon the City's request.
<Comment Required>
The Proponent has a security program and conducts testing activities to

identify and address any software and/or hardware vulnerabilities.
Sum 0 0 0 0

RFP PS20161055 Provision of Weigh Scale Management and Point of Sale System - ANNEX 2 - Detailed R
Spreadsheet
Nonfunctional Requirements - Training, Support and Documentation
le
Mandatory /
rty
zab
Req. ID. Critical /
Pa
Category Description
mi
No
Ye
# Desirable /
ird
sto
Optional
Th
Cu
All training aids and manuals shall be provided in electronic format. Training
5.1.01 Training Critical
may be provided as video recordings.
Application training for general Users (Weighmasters),and additional training for
5.1.02 Training Administrative Users. Provide one chapter of the training materials as an Critical
example.
5.1.03 Training System training for City System Administration and Application Support staff. Critical
Maintenance and troubleshooting training for City Application Support staff, for
5.1.04 Training Critical
hardware interfaces and software.
Enable the City to configure a Training environment emulating the City's
5.1.05 Training Desirable
production configuration, with simulated transactions.
On-site or online training as requested for functional topics, Refresher sessions,
5.1.06 Training Desirable
Updates and New Functions
General application support to be available by online communication or
5.2.01 Support Critical
telephone, during business hours of Weigh Scale Facilities.
Verify all hardware interfaces operate correctly with Weigh Scale Solution
software.
Updates to the application, manuals and help system must be supplied as they are
released.
5.2.04 Support Updates must not break existing custom functionality. Critical
Consult on configuration to set up data fields, default rules, logging and reporting
per City specifications
High availability configuration with redundant servers to be commissioned and
tested.
Coordinate with City's Support technician to document hardware setup, and
provide advice on parts and spares inventory.
Coordinate with City's Support technician for hardware maintenance and
troubleshooting.
11/01/2023 Annex 2 5.0 Training Support Doc

le
Mandatory /
rty
zab
Req. ID. Critical /
Pa
mi
No
Ye
# Desirable /
ird
sto
Optional
Th
Cu
Enable tests to be run with simulated transactions from a stored script in the
Testing configuration.
Proponent must report regression testing results for fixes and new features. In
particular, document issues with customizations.
5.2.11 Support Enable system monitoring and event logging for troubleshooting problems. Desirable
All product cut sheets, brochures and operating manuals for hardware
components, and cables shall be provided and include information on
5.3.01 Documentation temperature/environment, voltage, inputs/outputs, connectors, memory quantity, Critical
and types, etc.
All product cut sheets, brochures and operating manuals for software components
5.3.02 Documentation Critical
must be provided.
All documents should be provided in electronic format, and hard copy format
where available
The Proponent shall provide all documents relating to project deliverables:

- Project Implementation Plan and Schedule (PIPS)
- Solution Design Document (SDD)
- Solution Testing Plan (STP)
- Solution Acceptance Criteria
5.3.04 Documentation - Solution Administration Guide Critical
- Integration and API Procedures
- User Training Documents
- Solution Issues and Defect Report
- Solution Test Results Report
- Delivery Confirmation

le
Mandatory /
rty
zab
Req. ID. Critical /
Pa
mi
No
Ye
# Desirable /
ird
sto
Optional
Th
Cu
The Proponent shall include all documentation for their proposed solution
including:
a. End-user manual
b. Installation of solution on servers and clients
c. Trouble-shooting common hardware problems
d. Administrative Guide: Installation, operation and maintenance of server
solution including database
e. Configuration of the Solution
f. Integration methods - e.g. API, web services
g. High Availability configuration and operation; failover tests
h. Disaster Recovery Procedures
i. Data flow diagrams with security and encryption descriptions
Total 0 0 0 0

EX 2 - Detailed Requirements
tation
Comment
<Comment Required>
<Comment Required>
<Comment Required>

Comment
<Comment Required>

Comment

RFP PS20161055 Provision of Weigh Scale Management and Point of Sale System - ANNEX
2 - Detailed Requirements Spreadsheet
Nonfunctional Requirements - Components
Preface: The City is undertaking major construction projects at the Weigh Scale sites in 2016-2017. During construction new
cabling and peripherals will be installed.
The City seeks input from the Proponent for the selection, installation and configuration of hardware and software components
supporting the Solution.
Specifications and estimated costs must be submitted in advance of construction.
Installation of specific components may be delegated to the General Contractor.
Existing components at City sites are to be assessed prior to installation of the Proponent's Solution. Consistent with Vancouver's
Greenest City initiative, the existing components are to be re-used if they meet requirements and have at least 3 years before end-of-
life is reached.
Assume the City will provide database servers, network switches, workstation PCs, Moneris payment machines and peripheral
connection stubs with communication and power wiring. Indicate which components the Proponent requires for the Solution, and
in the Commercial Proposal provide costs for components the Proponent will supply.
Provide the responses to this list of Components requirements in the document "Annex 2A - Response
Addendum to Annex 2".
Mandatory /
Critical /
Desirable /
Optional
6.0.01 General Specify Server requirements: processor type, speed, memory, storage, NICs Critical
11/01/2023 Annex 2 6.0 Components

Mandatory /
Critical /
Desirable /
Optional
Specify workstation computer requirements: processor type, speed, memory, storage, NICs, serial
6.0.02 General connections. Designate which requirements are applicable to the various stations: Weighmaster, Critical
remote lane, reconciliation and Administrative User.
6.0.03 General Specify traffic management components and interface units; i.e. loops, photo eyes, gates, signal lights Critical
6.0.04 General Specify camera components for automated License Plate recognition, with associated software Critical
6.0.05 General Specify camera components for automated load photos and inspection, with associated software Critical
6.0.06 General Specify RFID antenna and tag system for automated vehicle recognition Critical
6.0.07 General Specify ticket printers for use in scale house Critical
6.0.08 General Specify signature pads for use in scale house Critical
6.0.09 General Specify compatible mobile devices Critical
6.0.10 General Specify peripheral interface units Critical
6.0.11 General Provide any special network requirements : routers, switches, shielding, speed and latency ranges Critical
6.0.12 General Provide web server requirements if applicable (web portal) Critical
6.0.13 General Specify inbound and outbound Driver Terminals for unattended scales Critical
6.0.14 General Provide specifications for any custom Solution devices or configurations. Critical
Sum
11/01/2023 Annex 2 6.0 Components

Annex2 DetailedRequirementsspreadsheet

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Annex2 DetailedRequirementsspreadsheet

Uploaded by

Copyright:

Available Formats

RFP PS20161055 Provision of Weigh Scale Management and Point of Sale System - ANNEX 2 - Detailed Requirements Spreadsheet

Proponents must include all specifications tables in their response.

Minimum Criteria for Submission

Please Provide a Reference where this

4/1/2016 Annex 2 1.0 Min Criteria

4/1/2016 Annex 2 1.0 Min Criteria

Capability - Business Functionality Matrix

Cap ID Category Capability

Enable transaction categorization data to be collected efficiently, using a simple

11/01/2023 Annex 2 2.0 Capability Matrix

Maintain lists of customer VehicleIDs with Active/Inactive billing permission.

11/01/2023 Annex 2 2.0 Capability Matrix

11/01/2023 Annex 2 2.0 Capability Matrix

11/01/2023 Annex 2 2.0 Capability Matrix

Capability - Business Functionality Matrix

11/01/2023 Annex 2 2.0 Capability Matrix

11/01/2023 Annex 2 2.0 Capability Matrix

11/01/2023 Annex 2 2.0 Capability Matrix

11/01/2023 Annex 2 2.0 Capability Matrix

11/01/2023 Annex 2 3.0 Global

11/01/2023 Annex 2 3.0 Global

11/01/2023 Annex 2 3.0 Global

11/01/2023 Annex 2 3.0 Global

Communication with City Financial Systems (Tempest and SAP).

Integration with City web portal for account clients - to manage

11/01/2023 Annex 2 3.1 Communications

11/01/2023 Annex 2 3.2 Configuration

11/01/2023 Annex 2 3.2 Configuration

Functional Requirements - Data Management and Integration

Store Hauler information. For commercial accounts using independent

11/01/2023 Annex 2 3.3 Data Management

Audit trails. All transactions must be able to be tracked through a paper

Per transaction: Track category variables, material types and quantities,

Track PaymentType(s). Payment may be split across multiple methods.

11/01/2023 Annex 2 3.3 Data Management

Voucher Types. Voucher values, effective dates, Origin code and

Waste Assessments: For unattended processing, automatically apply

11/01/2023 Annex 2 3.3 Data Management

Maintain a list of approved waste assessments, associated with either a

11/01/2023 Annex 2 3.3 Data Management

Functional Requirements - User Interface and Edits

11/01/2023 Annex 2 3.4 User Interface & Edits

11/01/2023 Annex 2 3.4 User Interface & Edits

Functional Requirements - Financial

Allow Administrative Users to specify refunds on individual transactions.

11/01/2023 Annex 2 3.5 Financial

Functional Requirements - Reporting and Analytics

Ability to re-generate ticket to match original ticket, for re-printing or electronic

11/01/2023 Annex 2 3.6 Reporting

Functional Requirements - Weights and Measures

11/01/2023 Annex 2 3.7 Weights and Measures

11/01/2023 Annex 2 3.8 Extensibility & Performance

11/01/2023 Annex 2 4.0 IT Standards & Security

Web-based interfaces should incorporate Responsive Web Design

11/01/2023 Annex 2 4.0 IT Standards & Security

The Proponent has a security program and conducts testing activities to

11/01/2023 Annex 2 4.0 IT Standards & Security

11/01/2023 Annex 2 5.0 Training Support Doc

The Proponent shall provide all documents relating to project deliverables:

11/01/2023 Annex 2 5.0 Training Support Doc

11/01/2023 Annex 2 5.0 Training Support Doc

11/01/2023 Annex 2 5.0 Training Support Doc

11/01/2023 Annex 2 5.0 Training Support Doc