2-City of Cincinnati RFI Workbook v.02 040226.xlsx
XLSX spreadsheet 91 KB Posted
- Solicitation number
- 265X901166
- Issued by
- Hamilton County, Ohio
About this file
This is a Request for Information (RFI) Workbook issued by the City of Cincinnati, Ohio, seeking detailed information from software vendors regarding enterprise resource planning (ERP) and human capital management (HCM) system solutions. The RFI encompasses comprehensive functional requirements across financial management, procurement, human resources, payroll, time and attendance, budgeting, accounts payable and receivable, fixed assets, and advanced scheduling modules. Vendors are required to respond to four primary worksheets: availability of modules, availability of functionality with response indicators (Fit, Roadmap, Gap, Partial, or Third-Party), implementation approach with task ownership divided between vendor and City roles, and detailed cost estimates for one-time and recurring expenses. The RFI document includes 12 functional areas with over 400 specific requirements, implementation phase planning, anticipated project duration estimates, and informational questions regarding vendor experience, marketplace presence, data migration strategy, software licensing models, and regulatory compliance approaches. No specific response date, due date, or site visit information is provided within this workbook document.
The cost worksheet requests both low and high estimates for one-time implementation costs including software licensing, professional services, analysis, configuration, customization, training, data conversion, hardware, and travel expenses, as well as recurring annual costs for SaaS subscription fees, maintenance and support, hosting, and professional services. The City seeks to understand typical implementation timelines, resource requirements, and staffing models for comparable public sector clients. Vendors are instructed that cost estimates are for planning purposes only and non-binding, and that estimates should encompass all systems, platforms, licensing, and features necessary for a fully functional solution. The RFI also identifies seven potential information exchanges with existing systems including CGI Advantage Financial, AssetWorks Fleet maintenance software, Bonfire procurement software, Kronos time and attendance, OnBase document management, PatternStream budget book creation, and Telestaff advanced scheduling software. The document was last updated March 4, 2026, and is identified as RFI 265X901166 coordinated with BerryDunn consulting.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 1-RFI 265X901166.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
1. Availability of Modules
| Availability of Modules | |||
| Instructions for completing this worksheet: Please provide your responses to the tables below, including supporting narrative comments where applicable to help the City better understand the responses given. | |||
| Response Indicators: | |||
| 1: The module is part of the integrated software package we provide. | |||
| 2: The module is not part of the software we provide; however, we regularly integrate with a third-party software product to provide this functionality. Identify this product in the comments. | |||
| 3: We do not provide this module. | |||
| No | Module | Vendor Response | |
| (1, 2, or 3) | Comments | ||
| 1 | General Ledger and Financial Reporting | ||
| 2 | Budgeting: Operating, Personnel, and Capital | ||
| 3 | Accounts Payable | ||
| 4 | Accounts Receivable, Cash Receipts, and Miscellaneous Billing | ||
| 5 | Procurement | ||
| 6 | Fixed Assets | ||
| 7 | Human Resources and Personnel Management | ||
| 8 | Payroll | ||
| 9 | Time and Attendance – General Government | ||
| 10 | Time and Attendance – Advanced Scheduling |
&"Arial,Bold"&12Request for Information:&"Arial,Regular" ERP and Community Development Software
&"Arial,Bold"&12Request for Information:&"Arial,Regular" ERP and Community Development Software
&"Arial,Bold"&12Request for Information:&"Arial,Regular" ERP and Community Development Software
&"Arial,Bold"&14City of Cincinnati, Ohio &"Arial,Regular"Request for Information (RFI) Workbook - 265X901166
&"Arial,Regular"&10BerryDunn &"Arial,Regular"&10April XX, 2013
&"Arial,Regular"&10BerryDunn &"Arial,Regular"&10April XX, 2013
&"Arial,Regular"&10BerryDunn &"Arial,Regular"&10April XX, 2013
&"Arial,Regular"&10BerryDunn &"Arial,Regular"&10March 4, 2026
2. Avail. of Functionality
| Availability of Functionality | |||
| Instructions for completing this worksheet: Please provide your responses to the tables below, including supporting narrative comments where applicable to help the City better understand the responses given. | |||
| Response Indicators: | |||
| F: "Fit" indicates the product or a feature meets the need of the requirement. | R: "Roadmap" indicates the capability is on the system's roadmap. Please describe the planned functionality and associated timeline for release in the Comments column. | ||
| G: "Gap" indicates the system cannot satisfy the requirement. | |||
| P: "Partial" indicates the system can meet some of the requirement but not all. Please describe limitations in the Comments column. | T: "Third-Party" indicates the system cannot satisfy the requirement. However, this feature could be provided with integration with a third-party system. This system should be specified in the Comments column. | ||
| No | Functionality | Vendor Response (F,G,P,R,T) | Comments |
| General and Technical | |||
| 1.01 | The system shall flow all changes made in the system throughout all proposed system modules without the need for duplicate data entry. | ||
| 1.02 | The system shall import and export data from (or to) standard file formats including but not limited to .html, PDF, .txt, csv, .xlsx, .docx, .xml | ||
| 1.03 | The system shall support APIs (Application Programming Interfaces) and EDI (Electronic Data Interchange) standards for third-party system integrations and data exchange. | ||
| 1.04 | The system shall support scheduled data feeds for exchanging file import/exports with third-party systems. | ||
| 1.05 | The system shall store and apply digital copies of signatures to documents (e.g., checks, notification letters) with appropriate security permissions. | ||
| 1.06 | The system shall limit which signatures to be applied to documents based on whether the individual is an authorized signor for a given department. | ||
| 1.07 | The system shall operate on mobile devices (e.g., tablets, smart phones) and size-render appropriately. | ||
| 1.08 | The system shall support separate production, test, and development environments with the ability to track software changes, configurations, and updates applied to each environment. The system shall support the promotion of changes through a controlled deployment process with appropriate approvals and audit logs, and provide the ability to roll back or restore prior configurations or releases as necessary. | ||
| 1.09 | The system shall provide “Document Management System” functionality to track and manage electronic files associated with specific system records, including the ability to integrate with HR and payroll functions to automatically pull relevant employee data and link corresponding documents (e.g., benefit enrollment forms, personnel action forms, performance evaluations). | ||
| 1.10 | The system shall support the purging of linked electronic files, according to City defined schedules, allowing for differing schedules based on the document, module, and/or litigation hold. | ||
| 1.11 | The system shall support Single Sign-On (SSO). | ||
| 1.12 | The system shall inherit groups from Active Directory for application authentication. | ||
| 1.13 | The system shall allow for multi-factor authentication. | ||
| 1.14 | The system shall provide role-based security. | ||
| 1.15 | The system shall allow the City system administrator to add and change permissions for system access. | ||
| 1.16 | The system shall mask or allow select information defined by the City as confidential (e.g., SSN). | ||
| 1.17 | The system has OCR capabilities with sensitive data detection to identify and mask sensitive information. (e.g. SSN). | ||
| 1.18 | The system shall apply the same security permissions to system queries and reports as it does to data fields/elements, based on user/role (e.g., data fields masked on a record or transaction are similarly masked on reports run by the user). | ||
| 1.19 | The system shall provide the user with integrated application modules that offer a consistent user interface to minimize user training and administration of the system. | ||
| 1.20 | The system shall provide contextual help, such as field-level descriptions or tooltips, that display dynamically based on cursor location or user interaction to assist with data entry and navigation. | ||
| 1.21 | The system shall provide an administrative messaging system (e.g., a message to alert users of system maintenance activity). | ||
| 1.22 | The system shall support partial or wildcard searches, allowing users to locate records using a fragment or portion of a word, phrase, or number. | ||
| 1.23 | The system shall support multiple windows open at the same time and for multiple users to input and manipulate data concurrently. | ||
| 1.24 | The system shall allow application windows, including text and field dimensions, to be maximized to fit allotted screen size (i.e., increase window size to increase amount of data displayed instead of simply zooming in on data). | ||
| 1.25 | The system shall provide workflow functionality in all proposed system modules including initiating and tracking workflow and approval processes. Any modules or processes that do not support workflow functionality shall be clearly identified in the comments. | ||
| 1.26 | The system shall allow systems administrators to configure the system to maintain separation of duties related to workflow approval processes. | ||
| 1.27 | The system shall restrict a workflow user from being the same entry/creator and approver of a transaction. | ||
| 1.28 | The system shall provide a library of standard reports (i.e., "canned" reports) that can be accessed in real-time. | ||
| 1.29 | The system shall provide an integrated report writer that allows the creation of reports comprised of any discrete data field throughout the system with proper security permissions. | ||
| 1.30 | The system shall encrypt all data at rest using industry-standard encryption algorithms. | ||
| 1.31 | The system shall comply with the Americans with Disabilities Act (ADA) and meet accessibility standards such as WCAG 2.1 Level AA, ensuring full functionality for users with disabilities, including compatibility with screen readers, keyboard navigation, and alternative text for images. | ||
| 1.32 | The system shall log all access and administrative actions—including login attempts, changes to user roles, and access to sensitive data—with time-stamps. All audit and activity logs shall be retained for a minimum of 90 days, with the ability for the City to configure longer retention periods based on policy or regulatory requirements. Logs shall be accessible to authorized users for review. | ||
| 1.33 | The system shall generate export files (e.g., csv, xlsx, pdf, txt) for the purpose of uploading data to third-party applications. | ||
| General Ledger and Financial Reporting | |||
| 2.01 | The system shall support maintaining a flexible, multi-segment chart of accounts structure that allows the agency to define, add, modify, and reorganize segments (e.g., fund, department/budget center, project, account, and user-defined fields) without vendor or technical intervention. | ||
| 2.02 | The system shall support applying effective dating to chart of accounts and organizational changes while preserving historical balances and prior period reporting accuracy. | ||
| 2.03 | The system shall support configurable workflows, approvals, and audit trails for chart of accounts additions, updates, and inactivation to help ensure appropriate review and internal controls. | ||
| 2.04 | The system shall support activating, inactivating, or restricting accounts from posting without deletion while retaining complete historical transactions. | ||
| 2.05 | The system shall support real-time transaction posting and immediate visibility into current balances and budget impacts. | ||
| 2.06 | The system shall support the ability for users to create and process manual, template-based, and bulk-upload journal entries with attachments, validations, and configurable review and approval workflows. | ||
| 2.07 | The system shall support generating recurring, allocation-based, and system-generated journal entries to reduce manual effort and improve consistency. | ||
| 2.08 | The system shall support configurable budget checks and provide warnings or hard stops during transaction entry and journal posting. | ||
| 2.09 | The system shall support the ability for users to associate documentation and attachments directly with journals and transactions to support audit and review processes. | ||
| 2.10 | The system shall support configurable fiscal calendars, accounting periods, and controlled open and close processes, including hard closes and role-based access. | ||
| 2.11 | The system shall provide notifications and dashboards identifying outstanding or unposted journal entries, reconciliations, or exceptions prior to period close. | ||
| 2.12 | The system shall support configurable reconciliation and variance analysis tools that allow users to research balances and prepare for audits without reliance on external spreadsheets. | ||
| 2.13 | The system shall maintain comprehensive audit logs that capture who created, modified, approved, or posted transactions and configuration changes. | ||
| 2.14 | The system shall support multiple books or accounting bases (e.g., budgetary and GAAP) concurrently within the general ledger, allowing transactions to be recorded once and automatically reflected in each applicable book through configurable or rule-based postings, and support independent reporting, reconciliation, and period management for each book without requiring duplicate entry, manual adjustments, or external spreadsheets. | ||
| 2.15 | The system shall have the ability for users to report and reconcile across accounting bases without manual adjustments or offline spreadsheets. | ||
| 2.16 | The system shall support the ability to produce financial statements and schedules required for regulatory and management reporting directly from the system. This could include a separate option for basis of accounting (e.g. Cash or accrual) | ||
| 2.17 | The system shall provide configurable, system-generated financial statements (e.g., trial balance, balance sheet, income statement, budget-to-actual, and management reports) without requiring external manipulation. | ||
| 2.18 | The system shall provide configurable month-end and year-end close task lists, assignments, and status tracking to help ensure timely and coordinated completion of close activities. | ||
| 2.19 | The system shall support the ability for users to drill down from summarized balances and financial statements to underlying journal entries, transaction details, and supporting documentation to help ensure transparency, auditability, and efficient research of financial activity. | ||
| Budgeting (Operating, Personnel, and Capital) | |||
| 3.01 | The system shall support both annual and biennial budget processes, including development, management, adoption, and reporting of separate fiscal year budgets within a single budget cycle. | ||
| 3.02 | The system shall support concurrent development of operating and capital budgets while maintaining separate controls, reporting, and approvals. | ||
| 3.03 | The system shall support rolling forward prior fiscal year actuals as the base budget. | ||
| 3.04 | The system shall provide configurable budget templates that pre-populate historical data, default assumptions, and formulas while restricting editing based on user permissions. | ||
| 3.05 | The system shall provide secure, web-based budget entry for departments with role-based permissions controlling access by fund, department, or account. | ||
| 3.06 | The system shall allow departments to enter narrative justifications, attachments, and supporting documentation for each budget request. | ||
| 3.07 | The system shall allow users to enter detailed line-item budgets that automatically roll up to account, agency, department, fund, service area, and enterprise totals. | ||
| 3.08 | The system shall support budget querying at any level of detail (e.g., line item, account, fund, etc.). | ||
| 3.09 | The system shall automatically consolidate departmental budget submissions into a unified operating, capital, and revenue budget without requiring manual spreadsheets or offline compilation. | ||
| 3.10 | The system shall provide configurable electronic workflows for budget entry, review, revision, approval, transfer, and amendment processes, including notifications, reminders, and audit trails. | ||
| 3.11 | The system shall maintain multiple budget versions and scenarios (e.g., base, department request, executive recommendation, adopted) and allow comparison and reporting of variances between versions. | ||
| 3.12 | The system shall support defined budget process stages (e.g., department entry, staff review, executive review, board adoption) and restrict editing based on the current stage. | ||
| 3.13 | The system shall support native budget book creation with configurable formatting and the ability to attach external content (e.g., charts, tables, pages of PDF documents, etc.). | ||
| 3.14 | The system shall import and export budget data using standard file formats (e.g., Excel, CSV) and support automated integration with the general ledger and other financial modules. | ||
| 3.15 | The system shall load adopted and amended budgets directly to the general ledger without requiring manual journal uploads. | ||
| 3.16 | The system shall calculate budget deficit based off approved expenses and projected revenue. | ||
| 3.17 | The system shall allow authorized users to amend budgets during the fiscal year and maintain a complete audit trail of all amendments, including user, date, and approval history. | ||
| 3.18 | The system shall support real-time budget-to-actual reporting. | ||
| 3.19 | The system shall support multi-year budgeting for capital projects and grants, including life-to-date appropriations, current year budgets, and future year projections. | ||
| 3.20 | The system shall support configurable, publicly facing forms hosted natively within the system to collect community input and applications for funding, without requiring third‑party form tools. | ||
| 3.21 | The system shall prepare and track budgets by project, grant, or funding source, with reporting of life-to-date, year-to-date, and remaining balances. | ||
| 3.22 | The system shall support development and reporting of consolidated Capital Improvement Plans (CIP), including new and continuing projects, funding sources, and forecasted expenditures. | ||
| 3.23 | The system shall provide project request review capabilities with the ability to score, revise, and allocate funding to projects within the system. | ||
| 3.24 | The system shall provide configurable forecasting and modeling tools that support scenario analysis using historical actuals, assumptions, and user-defined drivers. | ||
| 3.25 | The system shall provide project request review capabilities, including the ability to score, revise, and allocate funding to projects within the system. | ||
| 3.26 | The system shall integrate with payroll and human resources modules to incorporate position, salary, and benefit data directly into the budgeting process. | ||
| 3.27 | The system shall support budgeting by employee or position control number, including salaries, benefits, taxes, and other compensation components. | ||
| 3.28 | The system shall assign multiple funding sources (e.g., operating funds, projects, grants) to each employee or position for cost allocation and reporting. | ||
| 3.29 | The system shall automatically apply future-dated compensation changes (e.g., step increases, contract provisions, COLAs, benefit rate changes) to budget projections. | ||
| 3.30 | The system shall budget premium and variable pay types, including overtime, shift differential, longevity, and other supplemental earnings. | ||
| Procurement | |||
| 4.01 | The system shall provide a Purchasing module that is integrated with all other proposed system modules including (but not limited to) general ledger, capital assets, contracts, budgeting, accounts payable, and grants. | ||
| 4.02 | The system shall support maintaining a single, centralized vendor master that serves as the authoritative source of supplier information across procurement and accounts payable. | ||
| 4.03 | The system shall support electronic vendor onboarding and self-service maintenance of vendor information and required documentation to reduce manual data entry and staff intervention. | ||
| 4.04 | The system shall allow vendors to initiate modifications to their vendor file information and shall notify Procurement of pending requests. | ||
| 4.05 | The system shall support automated validation and duplicate detection to help ensure vendor data accuracy and prevent duplicate records or payments. | ||
| 4.06 | The system shall support capturing, maintaining, and reporting vendor attributes and certifications (e.g., DBE, MBE, compliance classifications). | ||
| 4.07 | The system shall support secure collection and maintenance of vendor banking and payment preference information with appropriate role-based access and audit tracking. | ||
| 4.08 | The system shall support a decentralized electronic requisition process with configurable workflows, approval routing, and delegation to replace manual or external approval methods. | ||
| 4.09 | The system shall flag (or hard-stop) requisition entries without necessary documentation attached. | ||
| 4.10 | The system shall support real-time visibility into requisition and purchase order status, approvals, and exceptions. | ||
| 4.11 | The system shall support automated creation and management of purchase orders from approved requisitions within an integrated workflow, including automatically modifying a draft purchase order when a requisition is updated. | ||
| 4.12 | The system shall support real-time budget and encumbrance controls during requisition and purchase order processing to help ensure funds availability before commitments are made. | ||
| 4.13 | The system shall support automated matching of purchase orders, receipts or service confirmations, and invoices to reduce manual review and exceptions. | ||
| 4.14 | The system shall support tracking of purchase order balances, partial payments, retainage, and remaining commitments. | ||
| 4.15 | The system shall support the integration of contracts, purchase orders, and related documentation to provide visibility into obligations and expenditures. | ||
| 4.16 | The system shall support electronic receipt or confirmation of goods and services to help enable accurate matching and payment authorization. | ||
| 4.17 | The system shall support integrated purchasing workflows and approvals within the system and maintain an audit trail of changes made throughout the workflow process. | ||
| 4.18 | The system shall upload transaction detail from bank's P-Card applications with detail applied to the general ledger appropriately. | ||
| 4.19 | The system shall support user-initiated P-Card reconciliation with approval workflow. | ||
| 4.20 | The system shall support contract enforcement and pricing compliance during requisition and purchase order creation by applying City-defined contract terms, pricing, and approved vendor selections to help ensure purchases align with established agreements. | ||
| 4.21 | The system shall support real-time reporting and dashboards that provide Procurement and management with visibility into vendor activity, commitments, and purchasing performance. | ||
| 4.22 | The system shall support integration and synchronization of vendor and purchasing data with other enterprise systems to help ensure information is maintained once and shared consistently across applications. | ||
| 4.23 | The system shall support self-service reporting and inquiry capabilities that allow authorized users to analyze vendor and purchasing activity without reliance on technical staff or external tools. | ||
| 4.24 | The system shall support visibility into vendor spend, open commitments, and purchasing activity across departments to assist management with oversight and strategic decision-making. | ||
| 4.25 | The system provides native functionality to support formal public procurement processes (e.g., ITB, RFP, RFQ, RFI), including vendor registration, solicitation management, sealed submissions, evaluation, and award documentation. | ||
| 4.26 | The system shall support converting approved requisitions into formal bid or solicitation events. | ||
| 4.27 | The system shall support multiple solicitation types (e.g., RFP, RFQ, RFI, Quote, Invitation to Bid) with Agency-defined templates, criteria, and due dates. | ||
| 4.28 | The system shall support sealed electronic bid or proposal submissions that remain confidential and inaccessible until the established closing date and time. | ||
| 4.29 | The system shall support defining bid schedules, due dates, milestones, and maintaining a centralized bid calendar. | ||
| 4.30 | The system shall support electronic vendor registration and communication, including automated notifications of opportunities, addenda, and awards based on vendor profile or commodity classifications. | ||
| 4.31 | The system shall support secure vendor submission of bids, forms, pricing, and supporting documentation electronically, including the ability to save drafts and revise submissions prior to closing. | ||
| 4.32 | The system shall support automated bid tabulation and comparison of pricing, alternates, and Agency-defined evaluation criteria. | ||
| 4.33 | The system shall support collaborative bid evaluation, including assignment of evaluation teams, scoring, comments, and recommendation tracking. | ||
| 4.34 | The system shall support maintaining complete bid documentation and history, including addenda, correspondence, questions and answers, submissions, tabulations, and awards for audit and public records purposes. | ||
| 4.35 | The system shall support maintaining a centralized contract repository that stores contract details, vendors, values, terms, dates, and associated documents. | ||
| 4.36 | The system shall support linking contracts to related procurement and financial records, including requisitions, bids, purchase orders, projects, and grants. | ||
| 4.37 | The system shall support flexible contract structures, including multiple vendors per contract, multiple contracts per vendor, and various agreement types (e.g., service, construction, requirements, lease, revenue). | ||
| 4.38 | The system shall support tracking contract values, encumbrances, expenditures, and remaining balances throughout the contract lifecycle. | ||
| 4.39 | The system shall support multi-year contracts and the ability to manage contract funding, carryforward, and partial encumbrances by fiscal period. | ||
| 4.40 | The system shall support configurable alerts and notifications for key contract events and thresholds, including expirations, renewals, spending limits, insurance or compliance requirements, and milestone dates. | ||
| 4.41 | The system shall support change order and amendment processing, including tracking of revisions, approvals, and adjustments to contract scope, schedule, and value. | ||
| 4.42 | The system shall support tracking contract deliverables, performance measures, and associated payments or invoices. | ||
| 4.43 | The system shall support communication with vendors from within the system with the ability to save email templates for rejections or cancelled bids. | ||
| 4.44 | The system shall support monitoring and reporting of vendor performance and maintaining historical contract cost and performance information for future procurement analysis. | ||
| 4.45 | The system shall support comprehensive reporting and inquiry capabilities that provide visibility into bid activity, contract status, expenditures, and historical outcomes to assist management oversight and planning. | ||
| Accounts Payable | |||
| 5.01 | The system shall support electronic invoice intake through multiple channels (e.g., vendor portal, email, and bulk upload) to reduce reliance on paper and manual handling. | ||
| 5.02 | The system shall support automated invoice data capture (e.g., OCR or intelligent recognition) to minimize manual key entry and improve processing speed. | ||
| 5.03 | The system shall support vendor self-service submission of invoices and supporting documentation directly into the system. | ||
| 5.04 | The system shall support decentralized invoice entry and centralized visibility across departments. | ||
| 5.05 | The system shall support automated matching of invoices to purchase orders and receipts or service confirmations with configurable matching rules and exception handling. | ||
| 5.06 | The system shall support real-time budget or encumbrance validation during invoice entry and voucher creation with configurable warnings or hard stops. | ||
| 5.07 | The system shall support recurring, template-based, and bulk invoice entry to reduce manual effort for repeat or high-volume transactions. | ||
| 5.08 | The system shall support automated detection of duplicate invoices and validation of common data entry errors. | ||
| 5.09 | The system shall support associating invoices with contracts, projects, grants, and funding sources for tracking and reporting. | ||
| 5.10 | The system shall allow attachment and retention of supporting documentation directly with vouchers to support auditability. | ||
| 5.11 | The system shall support automated payment processing through ACH, wire, and check methods with secure transmission to banking institutions. | ||
| 5.12 | The system shall support electronic remittance advice delivery to vendors and payment inquiry within the system. | ||
| 5.13 | The system shall support batch or mass payment processing and multiple payment runs per day. | ||
| 5.14 | The system shall support management of voids, reissues, manual payments, stale-dated checks, and unclaimed property in compliance with City policy. | ||
| 5.15 | The system shall utilize a centralized vendor master shared with purchasing and contracts to eliminate duplicate vendor maintenance and improve data consistency. | ||
| 5.16 | The system shall support secure vendor self-service capabilities for maintaining contact, tax, and banking information with audit tracking of changes. | ||
| 5.17 | The system shall support automated 1099 tracking, reporting, and electronic filing directly from vendor and payment data. | ||
| 5.18 | The system shall automatically generate general ledger and sub-ledger journal entries for all AP transactions with drill-down capability to source documents. | ||
| 5.19 | The system shall support automated bank and payment reconciliation through electronic bank file imports and exception reporting. | ||
| 5.20 | The system shall support real-time inquiry, dashboards, and reporting that provide visibility into invoice status, liabilities, payment activity, and vendor history without reliance on external spreadsheets or tools. | ||
| Fixed Assets | |||
| 6.01 | The system shall support configurable capitalization thresholds and policies by asset category, including infrastructure, intangible assets, and construction‑in‑progress, in accordance with City policy and GASB guidance. | ||
| 6.02 | The system shall support standardized asset classifications (e.g., land, buildings, land improvements, infrastructure, machinery and equipment, leased assets, and construction‑in‑progress) with configurable sub‑types and attributes. | ||
| 6.03 | The system shall provide a native, department‑facing asset acquisition form to submit asset additions and supporting documentation directly within the system. | ||
| 6.04 | The system shall support configurable workflows for asset creation, modification, transfer, and disposal, including routing, approvals, status tracking, and audit history. | ||
| 6.05 | The system shall allow assets to be identified and flagged during requisitioning or encumbrance to support automated downstream asset creation and reporting. | ||
| 6.06 | The system shall automatically generate and assign asset numbers using configurable numbering logic that supports City‑defined formats and conventions, including distinct handling for fleet and non‑fleet assets. | ||
| 6.07 | The system shall maintain complete asset master records, including asset description, fund, department, acquisition method and date, cost, vendor, location, asset type, and other required City‑defined attributes. | ||
| 6.08 | The system shall calculate and track depreciation natively using configurable methods and useful lives, and support depreciation processing as part of month‑end and year‑end close activities. | ||
| 6.09 | The system shall support asset transfers between departments or organizational units with appropriate workflow approvals and automatic updating of ownership and responsibility. | ||
| 6.10 | The system shall support disposal and retirement workflows that automatically update asset status and disposal details. | ||
| 6.11 | The system shall support tracking of leased assets, including lease indicators, key lease attributes, and attachment of lease documentation to the asset record. | ||
| 6.12 | The system shall support bulk uploads and updates of asset data using structured templates to streamline initial data entry, corrections, and ongoing maintenance. | ||
| 6.13 | The system shall support asset reconciliation and provide configurable reports to support quarterly and annual asset reviews, audits, and financial reporting. | ||
| 6.14 | The system shall maintain a complete audit trail of all asset‑related transactions and changes, including user actions, dates, approvals, and prior values. | ||
| Accounts Receivable, Cash Receipts, and Miscellaneous Billing | |||
| 7.01 | The system shall maintain a centralized customer master that serves as the single source of truth for customer and receivable information across all departments, including individual riders, groups, employers, or interagency partners (e.g., vanpool groups or employer-sponsored participants). | ||
| 7.02 | The system shall configure customer types, categories, and attributes to accommodate interagency, contractual, program-based, subscription-based, and miscellaneous bill relationships (e.g., vanpool programs, transit partners, or employer-subsidized services). | ||
| 7.03 | The system shall maintain customer-specific billing terms, contacts, purchase order references, and third-party sponsor relationships to align with contractual, intergovernmental, or employer-sponsored requirements. | ||
| 7.04 | The system shall maintain a complete audit trail and historical record of all customer, billing, and receivable activity, including inactive or reactivated customers. | ||
| 7.05 | The system shall support direct creation of invoices, adjustments, credits, and cancellations by authorized users. | ||
| 7.06 | The system shall support automated and recurring invoice generation based on Agency-defined schedules, contracts, or usage-based variables (e.g., miles, service days, riders, gallons, subsidies, fees, or other calculated metrics). | ||
| 7.07 | The system shall support batch or mass billing to multiple customers within a single process to reduce manual entry. | ||
| 7.08 | The system shall import billing transactions from external systems or spreadsheets (e.g., operational or settlement systems) with validation, error handling, and audit tracking. | ||
| 7.09 | The system shall support configurable invoice formats and electronic delivery options, including digital distribution to customer contacts. | ||
| 7.10 | The system shall automatically generate unique, sequential reference numbers for invoices and related transactions to support traceability and audit requirements. | ||
| 7.11 | The system shall support processing and recording multiple payment methods, including cash, check, ACH, and electronic payments. | ||
| 7.12 | The system shall apply payments in mass or batch to multiple invoices or accounts, including automated application based on Agency-defined rules. | ||
| 7.13 | The system shall hold, apply, or refund customer credits and overpayments without requiring manual workarounds. | ||
| 7.14 | The system shall automatically apply incoming electronic or online payments to customer accounts and associated invoices where sufficient remittance data is available. | ||
| 7.15 | The system shall support simplified payment worksheets or tools that enable efficient reconciliation and cash application by staff. | ||
| 7.16 | The system shall support secure integration with banking institutions and third-party settlement providers for electronic payment processing and file exchange. | ||
| 7.17 | The system shall support daily or periodic reconciliation of imported settlement or revenue files to corresponding bank deposits and receivable balances. | ||
| 7.18 | The system shall support automated preparation of general ledger and sub-ledger journal entries for all billing, receivable, and cash receipt transactions with drill-down capability. | ||
| 7.19 | The system shall support identification and reporting of discrepancies between expected revenue, recorded receivables, and deposited funds. | ||
| 7.20 | The system shall support payment plan tracking and allow authorized users to modify invoice due dates in accordance with policy. | ||
| 7.21 | The system shall support real-time inquiry, dashboards, and reporting that provide visibility into balances, aging, billing activity, settlements, and revenue trends by customer, program, service type, or department. | ||
| 7.22 | The system shall support identification, referral, tracking, and reporting of invoices eligible for collection, write‑off, or legal action based on configurable thresholds. | ||
| 7.23 | The system shall support ad hoc reporting and data export capabilities that allow authorized users to analyze receivable and cash receipt information without reliance on external tools. | ||
| Human Resources and Personnel Management | |||
| 8.01 | The system shall provide an employee central/master file that is the single source of employee records in which all other proposed system modules interact with. | ||
| 8.02 | The system supports full integration of all modules included, allowing for flow of data from one module (e.g. benefits) to other modules (e.g. payroll and ESS) with appropriate transaction records and permissions. | ||
| 8.03 | The system shall support position management independent of employees, including creation, funding, classification, and active/inactive status. | ||
| 8.04 | The system shall maintain a unique employee number for each person regardless of their employment status within the system (i.e., termination, reinstatement, retirement). | ||
| 8.05 | The system shall set-up and establish rules, workflows, and track changes for multiple types of Personnel Actions. | ||
| 8.06 | The system shall track multiple types of service dates. | ||
| 8.07 | The system shall maintain an audit log of all personnel-related transactions and activity. | ||
| 8.08 | The system shall transfer an employee to a different department/division or payroll group without re-entering the entire employee file. | ||
| 8.09 | The system shall track reasonable accommodations provided under the ADA. | ||
| 8.10 | The system shall classify and filter correspondence Activity Log entries by type of activity (as defined by user, e.g., PA, grievance, discipline,. etc.). | ||
| 8.11 | The system shall maintain all employee file change history (including pay, position, status, etc.). | ||
| 8.12 | The system shall preclude employees from user defined actions/processes based on employee status (e.g., employee on FMLA will not accrue leave, an employee with an expired CDL license would not receive supplemental pay etc.). | ||
| 8.13 | The system shall support organizational hierarchy management, including departments, divisions, reporting relationships, and supervisory assignments. | ||
| 8.14 | The system shall assign role-based security to a position, supervisor, or individual user to control what employee information is accessible with limiting view and/or edit access including limiting a supervisor to their direct reports. | ||
| 8.15 | The system shall flag certain employees personnel files as confidential or exempt from Freedom of Information Act based upon unit/division/department (e.g., undercover employees in law enforcement, or relatives of law enforcement officers). | ||
| 8.16 | The system shall archive and easily retrieve on-line employee records based on City retention requirements after retirement/termination, with various time periods based upon the records (e.g., audit records, payroll records, etc.). | ||
| 8.17 | The system shall provide automated record retention and purge functionality based on City-defined criteria and policies, including the ability to retain and archive employee-related records (e.g., case management records, benefit enrollments, personnel actions) in accordance with applicable retention requirements. | ||
| 8.18 | The system shall support decentralized Personnel Actions (P.A.s), whereby end-users initiate P.A.s within the system (including at the department level and from within HR). | ||
| 8.19 | The system shall provide a date-based personnel system that allows "personnel/employee actions" to be automatically triggered based upon effective dates. | ||
| 8.20 | The system shall support dynamic form help, including form assistance that guides the user through required fields and screens (e.g., the type of PA selected determines the information user must provide on the form) | ||
| 8.21 | The system shall process personnel actions effective in the middle of a pay period (per user defined business rules). | ||
| 8.22 | The system shall support the entry and processing of multiple personnel actions for an employee concurrently, ensuring accurate tracking and seamless workflow integration. | ||
| 8.23 | The system shall default specified Job Code data (e.g., pay grade, schedule, probation period, leave types, pay types, civil service classification) to new position and employee record, with ability for default values to be overridden by the user (with appropriate security). | ||
| 8.24 | The system shall automate personnel record, compensation, and benefits information updates to be automatically applied within the appropriate file records based on successful completion an approval of related workflow processes. | ||
| 8.25 | The system shall support electronic acknowledgments and signatures for personnel actions and required HR documents. | ||
| 8.26 | The system shall provide checklists for employee hire and termination process to ensure all steps are completed (checklist should include policy and agreement documents). | ||
| 8.27 | The system shall automatically initiate onboarding notifications and/or workflow processes for new hires (e.g. City system access, physical access, uniform, tools). | ||
| 8.28 | The system shall automatically initiate termination notifications and/or workflow processes for separated employees (i.e. City system access, physical access, equipment collection, final paycheck). | ||
| 8.29 | The system shall request and accept electronic credit and background checks from outside agencies. | ||
| 8.30 | The system shall scan, link or upload and categorize/classify different types of documents and associate them with an employee. | ||
| 8.31 | The system shall allow for the entry and maintenance of employee performance reviews (orientation period and on-going) utilizing multiple schedules. | ||
| 8.32 | The system shall track employee performance reviews based on both duration of employment and duration in position or job classification. The system shall use this information to support pay progression, performance evaluation cycles, and eligibility for step, merit, or longevity increases. | ||
| 8.33 | The system shall integrate employee performance review documentation with employee development information (including employees' Individual Development Plan, or IDP). | ||
| 8.34 | The system shall attach documents to the performance review. | ||
| 8.35 | The system shall provide multi-step workflow for review and approval of performance evaluations, with the ability to restart the workflow if changes are necessary. | ||
| 8.36 | The system shall provide self-, peer- or “360" evaluation functionality. | ||
| 8.37 | The system shall record a variety of performance ratings (e.g., alpha and numeric scales). | ||
| 8.38 | The system shall allow the City to limit user visibility of performance ratings, based on user permissions and effective date. | ||
| 8.39 | The system shall accommodate multiple milestone dates in a performance review and development plan schedules (e.g., planning, quarterly, midterm, end-of-term). | ||
| 8.40 | The system shall provide for more than one supervisor to complete evaluation for same time period when employee changed positions during that time period. | ||
| 8.41 | The system shall allow employees to document their responses to performance reviews. | ||
| 8.42 | The system shall allow employees to set and track goals for performance reviews. | ||
| 8.43 | The system shall support a performance review template that pre-populates employee goals and essential job functions based on job type and other user-defined criteria (per user security). | ||
| 8.44 | The system shall generate a printable copy of employee performance reviews that is accessible to the employee. | ||
| 8.45 | The system shall maintain history of all performance evaluations for active and inactive employees according to City-defined employee file retention rules or other City-defined periods that may be shorter. | ||
| 8.46 | The system shall integrate performance reviews with employee development plans, including Individual Development Plans (IDPs). | ||
| 8.47 | The system shall record and track various employee-related issues (e.g., disciplinary actions, counseling, grievances) in an Activity Log that is maintained by the HR department. | ||
| 8.48 | The system shall support a decentralized employee relations, grievance, and discipline process in which HR staff serve in an advisory or oversight role, while the initiation, management, and resolution of cases are performed at the department level. | ||
| 8.49 | The system shall record and track disciplinary actions (and maintain history) including information on incidents causing the action, steps taken in resolution, and the personnel involved (captured by employee), with appropriate security. | ||
| 8.50 | The system shall capture user-entered narrative for each step of the disciplinary process with appropriate security permissions. | ||
| 8.51 | The system shall tie employee relations cases to the employee master file. | ||
| 8.52 | The system shall permit City staff to assign various levels of access for a supervisor to view current/prior discipline action/status, with appropriate security (e.g., see some but not all discipline steps/actions, or only certain types). | ||
| 8.53 | The system shall restrict the ability for a former/previous supervisor to view employee discipline action, upon transfer/other move to a new supervisor. | ||
| 8.54 | The system shall purge files of disciplinary actions after a user-defined period based on system security. | ||
| 8.55 | The system shall classify disciplinary records as formal and informal, with the ability to report on only one of these types. | ||
| 8.56 | The system shall allow employees to complete online entry of a grievance, with the ability to select the personnel policy being grieved from a list. | ||
| 8.57 | The system shall track all activities associated with the management of the grievance. | ||
| 8.58 | The system shall purge files of grievances after a user-defined period based on system security. | ||
| 8.59 | The system shall provide a centralized system for tracking and administering risk management. | ||
| 8.60 | The system shall generate all Human Resources and Risk Management reporting required to meet external mandates (including City Local, State, Federal). These should include the generation of all reports and forms that comply with EEOC, OSHA, Department of Labor, Military Status, and FLSA standards and regulations. | ||
| 8.61 | The system shall generate all benefits reporting required to meet external mandates (including City Local, State, Federal). These should include the generation of all reports and forms that comply with FMLA, IRS, and ACA standards and regulations. | ||
| 8.62 | The system shall provide an employee self service that provides employee access to update personal information, beneficiaries, tax withholding, direct deposit, and includes ability to post communication to a landing page. | ||
| 8.63 | The system shall indicate expiration dates of an employee's licenses or certifications. | ||
| 8.64 | The system shall link required certifications and licensures to job classification or position. | ||
| 8.65 | The system shall track and assign various schedule types on the employee's master file record. | ||
| Payroll | |||
| 9.01 | The system shall provide a Payroll module that is integrated with all other proposed system modules such as Time Entry, Benefits, and Human Resources. | ||
| 9.02 | The system shall integrate payroll with position tracking. | ||
| 9.03 | The system shall maintain unlimited prior year payment and deduction related details and totals. | ||
| 9.04 | The system has ability to track and report employees associated with any pay or deduction code. | ||
| 9.05 | The system shall allow continuous updating of employee personnel and job records in such a manner as not to interfere with payroll processing (i.e. no lock-out of users from system while payroll is being processed). | ||
| 9.06 | The system shall maintain payroll history, including earnings, deductions, taxes and other related supporting information for an unlimited number of years. | ||
| 9.07 | The system shall limit users access to view or make changes to employees' information based on security permissions (e.g., taxes, general deductions, retirement, garnishments). | ||
| 9.08 | The system shall allow individual employees to view full paystub and W-2 history through an employee self-service portal. | ||
| 9.09 | The system shall support the ability pre-note personnel bank accounts to avoid unnecessary delays in payroll processing and returned checks | ||
| 9.10 | The system shall support configurable payroll approval workflows prior to check/direct deposit release. | ||
| 9.11 | The system shall allow users with appropriate security permissions to perform mass changes to paycheck detail lines during payroll processing, including positive and negative values, earnings, deductions, and taxes. | ||
| 9.12 | The system shall establish base payrolls and process time record data for exception pay employees on a weekly, bi-weekly, or monthly basis or any user-defined combination thereof. | ||
| 9.13 | The system shall import timecard data from external systems. | ||
| 9.14 | The system shall allow for an extra withholding tax deduction in any amount at the option of the employee for a specified period of time. | ||
| 9.15 | The system shall allow the option to manually adjust taxable earnings for W-2 processing based on system permissions, with the ability to provide a full audit trail. | ||
| 9.16 | The system shall support paying current or in arrears. | ||
| 9.17 | The system shall track and withhold multiple wage attachments (garnishments, tax levies, child support orders, etc.) | ||
| 9.18 | The system shall accommodate multiple payroll schedules. | ||
| 9.19 | The system shall support retro pay and deduction adjustments. | ||
| 9.20 | The system shall support multiple positions for individual employees. | ||
| 9.21 | The vendor will ensure software is always updated to be compliant with all Federal and State taxing requirements. | ||
| 9.22 | The system shall define special taxation rules by earnings code (e.g., supplemental tax rates, cumulative, annualized, etc.). | ||
| 9.23 | The system shall edit and verify the labor distribution prior to the actual payroll check production with appropriate authorization. | ||
| 9.24 | The system shall establish base payrolls and process time record data for exception pay employees on a weekly, bi-weekly, semi-monthly, or monthly basis or any user-defined combination thereof. | ||
| 9.25 | The system shall create checks which are not regular payroll but which will be added to the regular payroll run (e.g., longevity, retro, off-cycle). | ||
| 9.26 | The system shall process fiscal year end when the date falls mid payroll period, with accrual posting to the appropriate fiscal year (prior year/new year). | ||
| 9.27 | The system shall produce a warning/error report of employees with no benefit deductions due to low or no paycheck prior to running payroll (insufficient net pay). | ||
| 9.28 | The system shall process zero net checks for adjustment checks or where all pay was used for deductions, with the ability to print paycheck stubs for employee. | ||
| 9.29 | The system shall calculate salary employee effective date step increases, as a result of actions changes (e.g., promotions, demotions, acting appointments, and other actions). | ||
| 9.30 | The system shall automatically adjust calculations for mid-pay period salary and employment actions. | ||
| 9.31 | The system shall calculate pay for multiple positions for one employee that transfers during a pay period. | ||
| 9.32 | The system shall calculate leave accruals for employees in more than one position, as a result of a transfer during a pay period. | ||
| 9.33 | The system shall automatically calculate gross pay from multiple user defined components such as base pay, longevity, educational incentive pay, shift differential, etc. | ||
| 9.34 | The system shall provide multiple formulas for complex earning and deduction codes (e.g., overtime weighted average, premium overtime calculations based on standby pay). | ||
| 9.35 | The system shall calculate/verify overtime and shift differential consistent with FLSA rules |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .