1-CO-Town of Parker RFI Workbook-ERP.xlsx
XLSX spreadsheet 101 KB Posted
- Solicitation number
- 26-013
- Issued by
- Douglas County, Colorado
About this file
This is a Request for Information (RFI) workbook issued by the Town of Parker, Colorado, in partnership with BerryDunn, to evaluate enterprise resource planning (ERP) and community development software solutions. The workbook requests vendor responses regarding the availability of integrated modules and functional capabilities across finance, human resources, procurement, payroll, budgeting, and other core municipal operations. Vendors must indicate whether requested modules and functionalities are provided natively within their software, available through third-party integrations, or unavailable, with supporting narrative comments. The RFI document, dated May 7, 2026, includes detailed specifications across 49 functional requirement areas covering general ledger and financial reporting, budgeting, procurement, accounts payable, project and grants management, fixed assets and inventory, accounts receivable and cash receipts, stormwater utility billing, licensing and sales tax, human resources management, recruitment and applicant tracking, performance and learning, time and scheduling, and payroll. Each functional area contains multiple sub-requirements addressing system capabilities, workflow automation, reporting and analytics, security controls, compliance monitoring, and integration with existing municipal systems.
The workbook does not specify pricing, contract terms, award dates, or renewal options within the provided content. The document emphasizes the Town's need for integrated financial and operational systems that reduce duplicate data entry, support municipal accounting standards, enable role-based security and audit controls, and provide configurable workflows and comprehensive reporting. Key technical requirements include support for governmental fund accounting, multi-entity financial management, cloud or browser-based access, API integrations, document management, electronic signatures, and compliance with cybersecurity frameworks such as SOC 2 Type II, ISO 27001, and NIST. The RFI responses will inform the Town's business system strategy regarding modernization, optimization, or replacement of its existing technology environment.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 2-RFI 26-013 Enterprise Asset Management Technology.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 Town 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 | ||
| 3 | Procurement | ||
| 4 | Accounts Payable | ||
| 5 | Project and Grants | ||
| 6 | Fixed Assets and Inventory | ||
| 7 | Accounts Receivable and Cash Receipts | ||
| 8 | Stormwater Utility Billing | ||
| 9 | Licensing & Sales Tax | ||
| 10 | Human Resources Management | ||
| 11 | Recruitment and Applicant Tracking | ||
| 12 | Performance and Learning | ||
| 13 | Time and Scheduling | ||
| 14 | Payroll | ||
| 15 | Benefits Administration | ||
| 16 | Risk Management |
&"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"&14Town of Parker &"Arial,Regular"Request for Information (RFI) Workbook
&"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"&10May 7, 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 Town 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 | |||
| Technical Environment | |||
| GT.1 | The system shall have the ability to support a configurable, integrated application environment that allows changes made in one module to flow to related modules without duplicate data entry. | ||
| GT.2 | The system shall have the ability to support separate production, test, training, and development environments, including the ability to track configuration changes, software updates, and environment refreshes. | ||
| GT.3 | The system shall have the ability to support environment refreshes, including the ability to copy data and configuration from production to non-production environments using Town-defined timing and security controls. | ||
| GT.4 | The system shall have the ability to support browser-based access through current versions of major web browsers, including Microsoft Edge, Google Chrome, and Safari. | ||
| GT.5 | The system shall have the ability to support data retention, archive, purge, and retrieval rules based on Town-defined operational, legal, audit, and historical reporting requirements (e.g., capital project, asset lifecycle). | ||
| Data, Integration & Interoperability | |||
| GT.6 | The system shall have the ability to support data import and export using standard file formats, including CSV, XLSX, XML, PDF, DOCX, TXT, HTML, and other Town-defined formats. | ||
| GT.7 | The system shall have the ability to support APIs for third-party system integration, including data entry, data extraction, workflow initiation, status updates, and system-to-system communication. | ||
| GT.8 | The system shall have the ability to support secure scheduled data feeds, imports, exports, and automated file transfers with Town-defined third-party systems. | ||
| GT.9 | The system shall have the ability to support data export for public records, audit requests, analysis, reporting, and future system transitions without requiring vendor-developed custom extracts for standard data fields. | ||
| Security, Privacy & Audit | |||
| GT.10 | The system shall have the ability to support integration with the Town’s identity provider, including Entra ID/Azure. | ||
| GT.11 | The system shall have the ability to support multi-factor authentication for internal, external, mobile, and administrative users based on Town-defined security policies. | ||
| GT.12 | The system shall have the ability to support role-based security to restrict access to information and functions based on job role, department, user group, module, record type, data field, and other Town-defined criteria. | ||
| GT.13 | The system shall have the ability to support field-level security and data masking for sensitive information, including Social Security numbers, tax identification numbers, dates of birth, bank account information, health information, personal addresses, and other Town-defined confidential data. | ||
| GT.14 | The system shall have the ability to support multiple administrative roles, including technical administrators, functional administrators, department administrators, and read-only audit users. | ||
| GT.15 | The system shall encrypt data at rest and in transit using industry-standard encryption methods and secure key management practices. | ||
| GT.16 | The system shall capture audit log details including user ID, date, time, action performed, original value, updated value, affected record, and related module or process. | ||
| GT.17 | The system shall align with recognized cybersecurity and privacy frameworks applicable to the proposed solution, such as SOC 2 Type II, ISO 27001, NIST, CJIS, HIPAA, PCI, or other relevant standards, where applicable. | ||
| Document & Records Management | |||
| GT.18 | The system shall have the ability to support document management functionality that allows electronic files to be attached, linked, categorized, searched, viewed, retained, and retrieved from related system records. | ||
| GT.19 | The system shall have the ability to support drag-and-drop upload, scanned document capture, batch upload, and manual attachment of electronic files to transactions and records. | ||
| GT.20 | The system shall have the ability to support document version control, including the ability to retain prior versions, identify the current version, and view version history. | ||
| GT.21 | The system shall have the ability to support configurable allowable file types, file size limits, document categories, naming conventions, and required attachment rules. | ||
| GT.22 | The system shall have the ability to support electronic signatures, digital signatures, document stamping, approval signatures, and integration with third-party signature platforms where applicable. | ||
| GT.23 | The system shall have the ability to support document redaction, restricted document visibility, and confidential document handling based on Town-defined security rules. | ||
| GT.24 | The system shall have the ability to support document sharing through secure links, email, portal access, download, export, or integration with Town-defined document repositories. | ||
| GT.25 | The system shall have the ability to support records retention and litigation hold rules for electronic documents based on document type, module, record status, and Town-defined schedules. | ||
| GT.26 | The system shall have the ability to integrate with third-party document management systems (e.g., Laserfiche). | ||
| Workflow & Notifications | |||
| GT.27 | The system shall have the ability to support configurable workflows across proposed modules, including initiation, routing, approvals, task assignments, status tracking, escalations, notifications, and completion rules. | ||
| GT.28 | The system shall have the ability to support workflow routing based on user, role, department, division, record type, transaction type, amount threshold, location, or other Town-defined criteria. | ||
| GT.29 | The system shall allow authorized users to view where a record or transaction is in the workflow process, including current step, assigned user, pending action, due date, and workflow history. | ||
| GT.30 | The system shall have the ability to support workflow audit trails, including initiator, approver, reviewer, date and time, comments, decisions, status changes, and completed steps. | ||
| GT.31 | The system shall have the ability to support delegation, backup approvers, temporary user availability settings, and automated reassignment during absence, leave, vacancy, or non-response. | ||
| GT.32 | The system shall have the ability to support bulk review and approval of selected tasks or transactions where permitted by Town-defined business rules and security permissions. | ||
| GT.33 | The system shall have the ability to support event-driven notifications through email, in-system alerts, dashboards, mobile notifications, or other Town-defined communication methods. | ||
| GT.34 | The system shall allow authorized users to override, reroute, return, or advance a workflow step with required reason codes, audit trail, and security controls. | ||
| Reporting & Analytics | |||
| GT.35 | The system shall include a library of standard pre-built reports for operational, financial, administrative, compliance, audit, and management reporting needs. | ||
| GT.36 | The system shall have the ability to support an integrated, user-friendly report writer that allows authorized users to create and modify reports using available system data fields without advanced technical skills. | ||
| GT.37 | The system shall support ad hoc reporting capabilities, including the ability for users to select data fields, apply filters, define groupings and sorting, perform calculations, and configure parameters and output formats. The system shall also allow users to save, share, and designate ad hoc reports as favorites for future use. | ||
| GT.38 | The system shall have the ability to support configurable dashboards that display role-based metrics, trends, exceptions, workloads, due dates, alerts, and key performance indicators. | ||
| GT.39 | The system shall have the ability to support scheduled report generation and distribution by email, secure link, dashboard publication, or export to Town-defined repositories. | ||
| GT.40 | The system shall have the ability to support historical trend reporting and point-in-time reporting for operational, financial, service delivery, audit, compliance, and management analysis. | ||
| GT.41 | The system shall integrate with Microsoft Excel to enable live, refreshable reporting and analytics, allowing authorized users to securely retrieve, filter, and analyze ERP data in Excel with on-demand and scheduled refresh capabilities. | ||
| GT.42 | The system shall have the ability to support payroll compliance with applicable federal, state, and local laws, regulations, and Town-defined policies, including configurable payroll rules, validations, and controls for earnings, deductions, taxes, leave, and overtime, with audit trails and reporting to support compliance monitoring, audit requirements, and consistent payroll processing. | ||
| GT.43 | They system shall have the ability to configure and report against user-defined fields. | ||
| User Experience, Accessibility, & Mobile | |||
| GT.44 | The system shall provide a consistent and intuitive user interface across proposed modules to promote ease of use, reduce training needs, and simplify system administration. | ||
| GT.45 | The system shall have the ability to support partial, wildcard, and keyword search across key records, including names, IDs, addresses, parcels, assets, permits, vendors, employees, projects, and other Town-defined records. | ||
| GT.46 | The system shall have the ability to support pre-filled fields, dropdowns, lookup lists, field-level help, tooltips, and data validation to reduce duplicate entry and improve data quality. | ||
| GT.47 | The system shall comply with ADA accessibility expectations and WCAG 2.2 AA or current applicable accessibility standards for internal and public-facing functionality. | ||
| GT.49 | The system shall have the ability to support mobile access through browser-based responsive design, native mobile applications, or both, based on the proposed solution and user role. | ||
| Core GL and Fund Accounting | |||
| GL.1 | The system shall have the ability to provide an integrated general ledger and financial reporting environment that supports the Town’s core finance processes, reduces duplicate data entry, and reduces reliance on spreadsheets and supplemental tools for routine GL activity. | ||
| GL.2 | The system shall have the ability to support governmental fund accounting, including fund, division/department, object code, revenue/source, and other Town-defined financial structures needed to support municipal accounting, project accounting budgetary control, financial reporting, and audit requirements. | ||
| GL.3 | The system shall have the ability to support multi-entity financial management. | ||
| GL.4 | The system shall have the ability to support entity-specific and consolidated financial reporting, including reporting by entity, fund, department/division, revenue source, project, grant, activity code, and other Town-defined reporting structures without duplicate data entry or manual reconciliation. | ||
| GL.5 | The system shall have the ability to support a flexible chart of accounts and supplemental reporting dimensions that allow the Town to track funds, divisions/departments, object codes, revenue sources, grants, projects, programs, funding sources, and other Town-defined attributes without excessive account proliferation or inconsistent account numbering practices. | ||
| GL.6 | The system shall have the ability to support centralized COA maintenance, including the ability to update, validate, and publish account changes across related financial modules such as budgeting, procurement, projects, accounts payable, reporting, and integrations. | ||
| GL.7 | The system shall have the ability to support COA versioning, crosswalks, effective dating, account activation/deactivation, and change history to preserve historical reporting and support future COA redesign or cleanup efforts. | ||
| GL.8 | The system shall have the ability to support manual, recurring, interfund, allocation, budget, accrual, reversing, and system-generated journal entries, including templates and configurable posting rules. | ||
| GL.9 | The system shall have the ability to allow journal entries to include electronic backup documentation, notes, descriptions, supporting spreadsheets, approval history, and related transaction references, reducing or eliminating the need to print and physically store JE packets. | ||
| GL.10 | The system shall have the ability to support controlled import, validation, and export of journal entries and financial transactions from approved sources, including Excel, CSV, p-card files, POS systems, budget entries, payroll, accounts payable, and other Town-defined source systems. | ||
| GL.11 | The system shall have the ability to support recurring, allocation, and internal service journal entries, including allocation formulas, templates, reversals, supporting documentation, and review/approval workflows. | ||
| GL.12 | The system shall have the ability to support month-end and year-end close task management, including configurable close checklists, assignment of responsibilities, due dates, dependencies, completion tracking, reminders, and management visibility into close status. | ||
| GL.13 | The system shall have the ability to support soft close and period reopening processes with configurable permissions, posting restrictions, audit logging, and controls to preserve historical data integrity while allowing authorized adjustments. | ||
| GL.14 | The system shall have the ability to support configurable accounting periods, including standard monthly periods and one or more special periods for accruals, audit adjustments, and year-end closing entries, with the ability to define period access, posting permissions, reporting treatment, and audit controls by period type. Please describe any limitations on the number or use of special accounting periods. | ||
| GL.15 | The system shall have the ability to support automatic reversal of month-end and year-end accrual entries at the beginning of a future accounting period, with the flexibility to designate reversals based on user-defined criteria, transaction attributes, or entry type. | ||
| GL.16 | The system shall have the ability to support automated bank reconciliation for multiple Town bank accounts, including daily reconciliation of the general operating account, import of bank files, matching rules, exception handling, department cash reconciliation support, and integration with banking or treasury platforms. | ||
| GL.17 | The system shall have the ability to provide configurable financial statements and reports that can be filtered, grouped, formatted, saved, versioned, scheduled, exported, and reused by authorized end users without requiring back-end development or vendor support. | ||
| GL.18 | The system shall have the ability to support GL reporting by project, grant, activity code, funding source, department, fund, and other Town-defined attributes to support financial monitoring, reimbursement requests, SEFA support, audit schedules, and management reporting. | ||
| GL.19 | The system shall have the ability to support ACFR preparation by providing configurable financial statements, trial balances, journal detail, audit schedules, fund statements, statistical data exports, and other auditor-requested reports in formats that reduce manual compilation and spreadsheet rework. | ||
| GL.20 | The system shall have the ability to provide configurable role-based security for GL access, including inquiry, reporting, transaction detail, field visibility, output/export permissions, and posting authority by fund, department/division, account, entity, role, and security group. | ||
| GL.21 | The system shall have the ability to enforce posting controls for live and batch GL activity, allowing only authorized users to post to specified funds, departments/divisions, accounts, entities, periods, and transaction types. | ||
| GL.22 | The system shall have the ability to support document management integration for GL records, journal entries, approvals, reports, audit support, and related financial transactions, including secure storage, indexing, retrieval, and role-based access to supporting documentation. | ||
| Budgeting | |||
| BU.1 | The system shall have the ability to support an integrated budgeting environment for operating, capital, and personnel budgeting, including preparation, review, approval, amendment, monitoring, and reporting activities. | ||
| BU.2 | The system shall have the ability to support online budget entry for departments with role-based access, budget guidance, line-item detail, narrative fields, attachments, and status tracking. | ||
| BU.3 | The system shall have the ability to support automated notifications, reminders, escalations, and proxy or delegated approvals for budget entry, review, and approval activities based on Town-defined rules. | ||
| BU.4 | The system shall have the ability to restrict changes to submitted or approved budget requests unless authorized through Town-defined permissions, workflow reopening, or controlled revision processes. | ||
| BU.5 | The system shall have the ability to support audit trails for budget preparation, review, approval, amendment, and reporting activities, including user ID, date/time stamp, prior value, revised value, workflow status, and approval history. | ||
| BU.6 | The system shall have the ability to support electronic attachments and supporting documentation at the budget request, line-item, project, position, and amendment levels, including common file formats such as Word, Excel, PDF, and image files. | ||
| BU.7 | The system shall have the ability to support role-based budget security by department, division, fund, program, project, position, account, workflow role, and reporting access level. | ||
| BU.8 | The system shall have the ability to support multi-year budgeting and forecasting for operating, capital, and personnel budgets, including at least five-year and 10-year planning views where applicable. | ||
| BU.9 | The system shall have the ability to support development of annual operating budgets by fund, department/division, account/object, program, and other Town-defined dimensions, including baseline budgets, new requests, adjustments, and one-time items. | ||
| BU.10 | The system shall have the ability to support structured submission, review, prioritization, approval, denial, and tracking of supplemental budget requests, including requests for new initiatives, position changes, budget increases, technology needs, and capital needs. | ||
| BU.11 | The system shall have the ability to classify budget requests by Town-defined categories such as compensation and benefits, technology, contractual mandates, public safety, operating impact, strategic alignment, and one-time or recurring cost type. | ||
| BU.12 | The system shall support the ability to move approved budget requests and adopted budget amounts into the base budget while preserving request history, approval history, and the distinction between one-time and recurring amounts. | ||
| BU.13 | The system shall have the ability to support budget amendments, supplemental appropriations, transfers, carryover requests, and mid-year adjustments with workflow routing, supporting documentation, audit trails, and reporting by ordinance or approval action. | ||
| BU.14 | The system shall have the ability to support tracking of capital and operating carryforward requests, lapsed appropriations, restored spending authority, and related budget amendment actions in accordance with Town-defined fiscal policies. | ||
| BU.15 | The system shall have the ability to support capital budget planning for multi-year projects, including project ID, project name, phase, asset type, project type, responsible department, anticipated start and end dates, budget year, and life-to-date financial activity. | ||
| BU.16 | The system shall have the ability to support prioritization and scoring of capital requests using Town-defined criteria, including strategic alignment, board or commission direction, operating impact, funding availability, project readiness, and risk or service impact. | ||
| BU.17 | The system shall have the ability to support integration between capital planning, project accounting, grants, procurement, accounts payable, fixed assets, and the general ledger to provide visibility into adopted budget, amendments, encumbrances, expenditures, remaining budget, and life-to-date project activity. | ||
| BU.18 | The system shall have the ability to support position-based personnel budgeting integrated with HR and payroll data, including authorized positions, vacancies, salary projections, step or range changes, merit assumptions, benefits, taxes, and other employer costs. | ||
| BU.19 | The system shall have the ability to maintain position control records that link authorized positions, employees, funding sources, departments, job codes, pay plans, and adopted budget amounts to help prevent staffing levels from exceeding approved budget authority. | ||
| BU.20 | The system shall have the ability to support vacancy tracking and personnel scenario planning, including new positions, eliminated positions, reclassifications, promotions, seasonal staffing, part-time staffing, and effective-dated changes. | ||
| BU.21 | The system shall have the ability to support budget-to-actual monitoring throughout the fiscal year, including adopted budget, amended budget, actuals, encumbrances, commitments, available budget, and projected year-end amounts. | ||
| BU.22 | The system shall have the ability to support real-time dashboards and inquiry tools for departments, Finance, leadership, and other authorized users to monitor budget status, request status, budget-to-actual activity, and financial trends. | ||
| BU.23 | The system shall have the ability to support preparation of the Town's budget book by generating financial schedules, budget tables, charts, narratives, statistical information, and exports that reduce manual compilation in Excel and Word. | ||
| BU.24 | The system shall have the ability to support publication or export of budget and financial information for public transparency reporting, including integration or file outputs compatible with Town-defined transparency platforms. | ||
| BU.25 | The system shall support multi-scenario revenue forecasting (e.g., best case, worst case, and most likely). | ||
| BU.26 | The system shall have the ability to maintain historical budget information, including adopted and amended budgets, encumbrances, expenditures, remaining budget, projections, and life‑to‑date financial activity, to support budget‑to‑actual analysis, auditability, trend analysis, reporting, and public transparency. | ||
| BU.27 | The system shall have the ability to integrate with the Chart of Accounts (COA) to support adopted budgets, budget amendments, and budget adjustments, ensuring consistency in account structures, alignment with financial reporting, and accurate tracking of budgetary changes. | ||
| BU.28 | The system shall have the ability to support workflow-driven reporting and user notifications for account transfers, including submission, review, approval, and completion statuses, with visibility into transfer history, status tracking, and audit trails. | ||
| Procurement | |||
| PUR.1 | The system shall have the ability to support an integrated procurement lifecycle that connects requisitions, approvals, purchase orders, contracts, receiving, encumbrances, accounts payable, and financial reporting without duplicate data entry. | ||
| PUR.2 | The system shall have the ability to support Town-defined procurement rules and thresholds for open market purchases, informal quotes, formal solicitations, Town Manager approval, Town Council approval, IT approval, capital construction procurement, professional services procurement, and emergency purchases. | ||
| PUR.3 | The system shall have the ability to capture structured requisition and procurement request information, including requesting department, requester, vendor, purchase type, description, GL coding, funding source, project or grant, technology indicator, procurement method, required approvals, and internal notes. | ||
| PUR.4 | The system shall have the ability to support online requisition entry and inquiry for departments, with role-based access to submit, review, revise, approve, and monitor procurement requests and related budget availability. | ||
| PUR.5 | The system shall have the ability to support configurable procurement workflows with sequential and conditional routing based on Town-defined criteria such as dollar threshold, procurement type, department, fund, account, project, grant, IT involvement, contract requirement, and approval authority. | ||
| PUR.6 | The system shall have the ability to support automated notifications, reminders, escalations, approval status updates, rejection notices, and delegation or proxy approval rules for procurement workflows. | ||
| PUR.7 | The system shall have the ability to support electronic attachments and document management for procurement records, including quotes, scopes of work, contracts, insurance documents, approvals, correspondence, bid documents, award records, and other Town-defined supporting materials. | ||
| PUR.8 | The system shall have the ability to support a complete audit trail for procurement transactions, approvals, attachments, workflow actions, funding checks, user changes, PO modifications, change orders, and contract-related updates. | ||
| PUR.9 | The system shall have the ability to support real-time budget checking during requisition, PO, and modification processing at the line, fund, department, division, object, project, grant, funding source, and other Town-defined attribute levels. | ||
| PUR.10 | The system shall have the ability to support pre-encumbrance, encumbrance, liquidation, recalculation, release, carryforward, and closeout of procurement commitments, with real-time visibility into committed spending and available budget. | ||
| PUR.11 | The system shall have the ability to support converting approved requisitions to purchase orders, including system-generated PO numbering, electronic distribution, print or reprint options, and linkage back to the originating request and approvals. | ||
| PUR.12 | The system shall have the ability to support purchase order modifications, change orders, quantity or amount changes, account coding updates, and scope-related revisions without requiring the original PO to be voided, while preserving version history and reapproval rules. | ||
| PUR.13 | The system shall have the ability to support PO closeout processes, including partial close, final close, automatic or workflow-based release of remaining encumbrances, and year-end review of open POs and commitments. | ||
| PUR.14 | The system shall have the ability to support receiving and receipt tracking for goods and services, including partial receipts, receipt approvals, supporting documentation, exception handling, and integration with invoice matching and accounts payable. | ||
| PUR.15 | The system shall have the ability to support procurement document and transaction drill-down from requisition to PO, receiving, invoice, payment, contract, solicitation, approval history, and supporting documentation. | ||
| PUR.16 | The system shall have the ability to support solicitation planning and management activities, including procurement method selection, solicitation templates, scope development, evaluation criteria, scoring structures, procurement milestones, notices, addenda, and award recommendation tracking. | ||
| PUR.17 | The system shall have the ability to support tracking of informal quote processes, including required quote counts, vendor outreach, quote documentation, selected vendor, justification, and approval history. | ||
| PUR.18 | The system shall have the ability to support formal bid, RFP, and RFQ processes, including vendor questions, addenda, evaluation committee assignments, evaluator scoring, comments, recommendations, award decisions, protests, and related documentation. | ||
| PUR.19 | The system shall have the ability to support integration or structured coordination with external bid management platforms used by the Town, while maintaining internal procurement planning, tracking, reporting, and award documentation within the ERP where appropriate. | ||
| PUR.20 | The system shall have the ability to support contract tracking related to procurement actions, including contract requirement indicators, approval status, award date, Council action, execution status, renewal dates, expiration dates, amendments, and links to executed agreements stored in the Town's records repository. | ||
| PUR.21 | The system shall have the ability to support vendor and supplier information visibility during procurement, including vendor selection, remit or contact details, vendor status, vendor debarment status, procurement history, award history, and linkage to vendor records used by accounts payable. | ||
| PUR.22 | The system shall have the ability to support procurement compliance reporting and exception tracking, including purchases made below or above thresholds, emergency purchases, missing documentation, approvals obtained after the fact, open items, and policy exceptions. | ||
| PUR.23 | The system shall have the ability to support user-friendly, remote-access procurement review and approval capabilities where appropriate, including the ability for authorized users to review key request details, funding availability, supporting documents, and approval history before taking action. | ||
| PUR.24 | The system shall have the ability to support keyword-based search across contract records and scopes of work, including the ability for Town staff to locate existing contracts, scopes, and related procurement documents using configurable search criteria, indexed contract content, and searchable document metadata. | ||
| Accounts Payable | |||
| AP.1 | The system shall have the ability to support end-to-end accounts payable processing within an integrated financial environment, including vendor invoice intake, coding, approval, matching, payment processing, remittance, posting to the general ledger, reporting, and audit support. | ||
| AP.2 | The system shall have the ability to support configurable accounts payable workflows for routing, review, coding, approval, escalation, and exception handling based on invoice type, department, fund, account, project, grant, dollar threshold, vendor, payment type, or other Town-defined attributes. | ||
| AP.3 | The system shall have the ability to support role-based access controls for accounts payable users, approvers, auditors, and inquiry-only users, including security for invoice entry, vendor maintenance, payment processing, reporting, attachments, and override actions. | ||
| AP.4 | The system shall have the ability to support a complete audit trail for invoice processing, including invoice receipt, coding, edits, approvals, rejections, comments, attachments, matching exceptions, payment selection, payment approval, and posting activity. | ||
| AP.5 | The system shall have the ability to support electronic attachment and retention of AP supporting documentation, including invoices, approval records, receipts, contracts, purchase orders, receiving documentation, checks, ACH support, retainage documentation, and other Town-defined records. | ||
| AP.6 | The system shall have the ability to link AP transactions to related procurement, contract, purchase order, receiving, project, grant, fixed asset, and general ledger records, with drill-down access to related source transactions and supporting documentation. | ||
| AP.7 | The system shall have the ability to support invoice data capture for scanned or electronic invoices, including extraction of vendor, invoice number, invoice date, line item, amount, payment terms, tax, and remittance information, with user review and validation before posting. | ||
| AP.8 | The system shall have the ability to support bulk import of invoice and payment files using Excel, CSV, or other Town-defined formats, including header-level and line-level detail, validation reporting, error handling, and creation of draft invoices or vouchers. | ||
| AP.9 | The system shall have the ability to support invoice coding and allocation across funds, departments, accounts, projects, grants, capital projects, activity codes, and other Town-defined reporting dimensions. | ||
| AP.10 | The system shall have the ability to support recurring invoice processing and templates for repeat payments, including recurring vendor invoices, scheduled payments, standard distributions, and recurring approval routing. | ||
| AP.11 | The system shall have the ability to support allocation of invoice costs across multiple departments, accounts, projects, grants, funds, or other Town-defined dimensions based on user-defined rules, templates, percentages, or manual distribution. | ||
| AP.12 | The system shall have the ability to support two-way and three-way matching among purchase orders, receiving records, contract references, and vendor invoices, including configurable tolerances, exception routing, and security-controlled overrides. | ||
| AP.13 | The system shall have the ability to support AP processing when a purchase order is not referenced or not required, including controls to verify appropriate approval, account coding, budget availability, contract association, and supporting documentation. | ||
| AP.14 | The system shall have the ability to support construction payment processing, including pay applications, retainage tracking, prior payment history, contract balance visibility, supporting documentation, approval routing, and retainage release processing. | ||
| AP.15 | The system shall have the ability to support payment processing for check, ACH, wire, manual check, emergency check, and other Town-defined payment types, including configurable approval workflows, payment batch review, and separation of duties controls. | ||
| AP.16 | The system shall have the ability to support digital vendor remittance advice with itemized invoice details and delivery through email, vendor portal, or other Town-defined delivery method at the time of payment. | ||
| AP.17 | The system shall have the ability to support Positive Pay and Payee Positive Pay file creation and transmission for check payments, including manual checks, with check number, issue date, amount, payee name, account number, and other bank-required fields. | ||
| AP.18 | The system shall have the ability to support check reconciliation tools to track cleared, outstanding, voided, stopped, reissued, and stale-dated checks across multiple bank accounts, with audit trails and configurable user permissions. | ||
| AP.19 | The system shall have the ability to support importing bank files and comparing bank activity to AP payment records to identify exceptions, support reconciliation, and help resolve variances. | ||
| AP.20 | The system shall have the ability to support a centralized vendor master file shared across procurement, accounts payable, contracts, inventory, purchasing cards, and related financial modules, with role-based security for viewing and updating vendor information. | ||
| AP.21 | The system shall have the ability to support vendor onboarding using Town-defined forms, required documentation, W-9 collection, tax classification, payment method selection, remittance information, and approval workflow before vendor activation. | ||
| AP.22 | The system shall have the ability to support workflow approval and audit logging for vendor master changes, including changes to legal name, DBA, address, remittance information, ACH banking details, tax classification, 1099 status, commodity codes, and inactive or hold status. | ||
| AP.23 | The system shall have the ability to support 1099 processing, including vendor classification, transaction-level 1099 indicators, review and correction workflows, form generation, electronic consent tracking where applicable, status monitoring, and filing support. | ||
| AP.24 | The system shall have the ability to support electronic 1099 filing using IRS-supported file formats and validation rules, including the ability to export required filing data and retain filed form history for audit and vendor inquiry purposes. | ||
| AP.25 | The system shall have the ability to support purchasing card transaction import, reconciliation, receipt attachment, coding review, approval routing, GL import, and reporting, including controls for missing receipts, coding exceptions, and restricted users. | ||
| AP.26 | The system shall have the ability to support inquiry and reporting by vendor, department, fund, account, project, grant, payment type, invoice status, payment status, fiscal period, and other Town-defined attributes. | ||
| AP.27 | The system shall accommodate employee expense reimbursements (uniform allowance, mileage, tuition reimbursement, etc.) through either the accounts payable module or the payroll module as nontaxable events. | ||
| Projects and Grants | |||
| PG.1 | The system shall have the ability to support an integrated project accounting and grant management environment that reduces duplicate entry and spreadsheet reliance across general ledger, budgeting, purchasing, accounts payable, accounts receivable, payroll/timekeeping, capital assets, and reporting. | ||
| PG.2 | The system shall have the ability to support project records with Town-defined attributes, including project ID, name, type, status, department, project manager, funding source, project phase, start and end dates, and other reporting dimensions. | ||
| PG.3 | The system shall have the ability to support parent and child project structures, including the ability to track subprojects, phases, components, and related budgets and transactions within an overall capital or operating project. | ||
| PG.4 | The system shall have the ability to support multi-year project budgeting and life-to-date project tracking, including adopted budget, revised budget, appropriations, encumbrances, actual expenditures, remaining balances, and available budget by fiscal year and project life cycle. | ||
| PG.5 | The system shall have the ability to support project accounting across multiple funds, departments, divisions, object codes, grants, activities, and funding sources without requiring separate GL accounts for each project component unless defined by the Town. | ||
| PG.6 | The system shall have the ability to associate project transactions with purchase requisitions, purchase orders, contracts, invoices, payments, journal entries, budget entries, grants, and capital assets. | ||
| PG.7 | The system shall have the ability to support configurable project and grant workflows for approvals, routing, task management, notifications, escalations, and status tracking based on Town-defined rules and security roles. | ||
| PG.8 | The system shall have the ability to support role-based security for project and grant records, including the ability to control access by department, project, grant, funding source, transaction type, approval role, and reporting need. | ||
| PG.9 | The system shall have the ability to support electronic document management for project and grant records, including agreements, award documentation, invoices, reimbursement support, change orders, retainage documentation, time-and-effort certifications, correspondence, closeout documentation, and audit support. | ||
| PG.10 | The system shall have the ability to support retainage tracking for construction and capital project pay applications, including retained amounts, releases, aging, paid and outstanding balances, vendor/project reporting, and supporting documentation. | ||
| PG.11 | The system shall have the ability to support project cost allocation rules for direct costs, indirect costs, internal service charges, overhead, and other Town-defined allocation methods. | ||
| PG.12 | The system shall have the ability to support labor and personnel cost tracking for projects and grants using payroll, timekeeping, or imported labor data, including salaries, benefits, labor hours, activity codes, approval tracking, and user-defined allocation rules. | ||
| PG.13 | The system shall have the ability to support grant records with Town-defined attributes, including grant ID, name, type, status, sponsor/funding source, award number, CFDA/Assistance Listing number, FAIN, award amount, grant period, match requirements, reporting deadlines, and closeout status. | ||
| PG.14 | The system shall have the ability to support grant lifecycle management from award through budget setup, procurement, spending, reimbursement, compliance monitoring, reporting, and closeout. | ||
| PG.15 | The system shall have the ability to support tracking of multiple funding sources for a project or grant, including funding source budgets, expenditures charged to each source, match requirements, transfers, and remaining funding balances. | ||
| PG.16 | The system shall have the ability to support grant reimbursement request preparation and tracking, including linkage to eligible expenditures, backup documentation, request status, reimbursement amount, payment received, and related accounts receivable activity. | ||
| PG.17 | The system shall have the ability to support grant compliance reporting, including reporting deadlines, required submissions, expenditure categories, funding source restrictions, match requirements, and notifications for upcoming or overdue compliance activities. | ||
| PG.18 | The system shall have the ability to support SEFA reporting by identifying federal expenditures by grant, funding source, Assistance Listing/CFDA number, FAIN, award number, fiscal year, and other required audit attributes. | ||
| PG.19 | The system shall have the ability to support Capital Improvement Plan (CIP) planning, forecasting, and prioritization using Town-defined ranking criteria, funding sources, project phases, estimated costs, timing, and operating impacts. | ||
| PG.20 | The system shall have the ability to support reporting by project, grant, activity code, fund, department, funding source, vendor, contract, purchase order, invoice, payroll/labor cost, fiscal year, and life-to-date totals. | ||
| PG.21 | The system shall have the ability to export project and grant data, reports, and supporting detail to Excel, CSV, PDF, and other Town-defined formats for audit, reimbursement, management, and public reporting needs. | ||
| PG.22 | The system shall have the ability to rollover multiyear projects and grants for expenditure and revenue budgets. | ||
| Fixed Assets and Inventory | |||
| FA.1 | The system shall have the ability to support fixed asset and inventory management within an integrated financial environment, including connections to general ledger, purchasing, accounts payable, project accounting, budgeting, fleet, and other Town-defined systems. | ||
| FA.2 | The system shall have the ability to support role-based access, workflow routing, approval tracking, notifications, audit trails, and document attachments for fixed asset and inventory records and transactions. | ||
| FA.3 | The system shall have the ability to support capitalization rules and fixed asset identification based on Town-defined thresholds, useful life criteria, asset classes, object codes, funding sources, departments, and project associations. | ||
| FA.4 | The system shall have the ability to identify potential capital assets during purchasing, receiving, accounts payable, project accounting, or inventory activity and route those items for Finance review before asset creation. | ||
| FA.5 | The system shall have the ability to support fixed asset lifecycle management from acquisition through capitalization, depreciation, transfer, impairment, disposal, surplus, and final disposition. | ||
| FA.6 | The system shall have the ability to support fixed asset records with Town-defined fields, including asset ID, description, asset type, serial number, equipment number, VIN, location, department, project, funding source, acquisition date, acquisition cost, useful life, capitalization status, and supporting documentation. | ||
| FA.7 | The system shall have the ability to support configurable depreciation methods, useful lives, conventions, and depreciation posting, including straight-line depreciation and half-year convention calculations where applicable. | ||
| FA.8 | The system shall have the ability to support electronic fixed asset disposal workflows, including department initiation, Finance review, approvals, supporting documentation, disposal reason, proceeds, accounting treatment, and removal from active asset listings while retaining history. | ||
| FA.9 | The system shall have the ability to support inventory management for multiple Town-defined locations, warehouses, vehicles, shops, departments, or storage areas, with separate stock levels, transactions, item accountability, and reporting by location. | ||
| FA.10 | The system shall have the ability to support a centralized inventory catalog with item descriptions, units of measure, item categories, vendor information, stock-on-hand, reorder points, shelf life, warranty information, and Town-defined custom fields. | ||
| FA.11 | The system shall have the ability to support barcode, label, QR code, or mobile scanning capabilities for fixed asset and inventory tracking, including field or warehouse use where applicable. | ||
| FA.12 | The system shall have the ability to support inventory issues, transfers, reservations, and returns tied to work orders, projects, departments, vehicles, equipment, facilities, or other Town-defined activities. | ||
| FA.13 | The system shall have the ability to support physical inventory count workflows, including count sheets or mobile counts, count approvals, variance review, discrepancy resolution, and update of inventory balances. | ||
| FA.14 | The system shall have the ability to support inventory costing and valuation methods, including actual cost, average cost, FIFO, LIFO, replacement cost, or Town-defined methods, and shall describe any limitations by item type or module. | ||
| FA.15 | The system shall have the ability to support inventory usage, turnover, stockout, negative balance, reorder, variance, and aging reports by department, location, item, project, work order, or date range. | ||
| FA.16 | The system shall have the ability to support approved inventory adjustments and related general ledger postings for increases, decreases, write-offs, corrections, and transfers, with configurable accounting codes and approval workflows. | ||
| FA.17 | The system shall have the ability to support integration or data exchange with fleet management systems such as FASTER to support fleet asset records, parts inventory, maintenance history, lifecycle cost tracking, and capital replacement planning. | ||
| FA.18 | The system shall have the ability to support integration or data exchange with enterprise asset management, work order, GIS, or departmental asset systems such as Beehive, GIS, or other Town-defined tools to reduce duplicate entry and improve asset and inventory visibility. | ||
| FA.19 | The system shall have the ability to support inventory and asset transactions related to infrastructure, fleet, facilities, parks, recreation, traffic, stormwater, and other department-maintained assets where the Town chooses to manage those records in or through the ERP. | ||
| FA.20 | The system shall have the ability to support reporting for capital asset schedules, asset additions, disposals, transfers, depreciation, accumulated depreciation, net book value, asset class, department, fund, project, and audit support. | ||
| FA.21 | The system shall have the ability to support bulk import of asset information from third-party software, including configurable data mapping, validation of imported records, review and approval workflows, and controlled posting of approved assets to the appropriate asset records and general ledger. | ||
| Accounts Receivable and Cash Receipts |
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 .