Request for Proposal for Cash Receipting System | Questions and Answers
Questions and Answers (Posted 12/13/22)
Question: The County is currently deeply embedded with Lexis Nexis for payment processing, but would the County at least entertain an alternative payment provider demo if it were competitive and integrated out of the box with an Enterprise Cashiering system? This approach would negate the need for integrating Lexis Nexis with multiple applications as they would be integrated with the Enterprise Cashiering system and a single point of payment (shopping cart) for all receivables from all County applications.
Answer: There is no requirement that the system take cash or credit card transactions. You may propose anything that you feel would make sense for Skagit County to consider as an optional feature.
Question: Can you tell me what is meant by "case notes"? We develop health care software and are very familiar with case notes in that context, but I don't know what it means for an accounting / transaction processing system. Does it mean just that each transaction has a description or notes field, or is there something else you're looking to track here?
Answer: We are dropping the “case” from the requirement. We are only looking to have a notes capability and that can be a description on a transaction or a field added to a form. Some method where information about a transaction or process can get documented.
We have changed requirement 6.4.2 to reflect this change.
Questions and Answers (Posted 12/23/22)
Requirement 6.3.3
The system shall be compliant with the Revised Code of Washington 42.56 Public Records Act
Question:
Please provide specific technical requirements which would comply with this item. Our system stores all data in a SQL Server owned, controlled by and fully accessible by County IT: if this setup meets the requirement, please advise. If evaluation is needed before confirming compliance with this law, we invite you to accept our proposal conditionally on your own review and verification that our features are legally compliant.
Answer:
The Public Disclosure Law essentially says that we have to be able to provide any data that we have in our possession to a requestor, unless that information is excempt by statute. Given that the County will “own” the SQL server data, we would have full access to the data and will be able to address any request for data. So, your solution is compliant with this requirement.
Requirement 6.4.2
Notes shall have an access control list of who can view, modify, create or delete notes
Question:
6.4.2: The RFP clarifies that notes include transaction description and transaction line descriptions. In our system, security is at the transaction level and depends on the type of transaction, the state of the transaction (posted or unposted, and/or in a locked period), and the security group the user belongs to (read-only, clerk, supervisor, or administrator: users not in one of these groups have no access at all). We can create custom security groups during system configuration (for example, if you want some users to have one level of access to receipts and another level to warrants) but as designed, users don't have a different level of access to one field of a transaction (for example, description) than the rest of the transaction. For modifications to posted transactions, we advocate using descriptive "adjusting entries" to provide an audit trail. Does this requirement require different behavior than this (such as column-based security, writability to some fields of a read-only transaction, etc.), or does our security model meet this requirement?
Answer:
If security of your system is at the transaction level, that will be adequate. For this security model, this makes sense.
Requirement 6.4.3
6.4.3 - The database shall allow authorized users to view, edit or clear fields based on security level authorized
6.4.3: See 6.4.2
Answer:
A transaction based security model makes sense and will meet our security needs.
Requirement 6.4.7
The system shall have the capability of creating custom screen fields.
Question:
6.4.7: What's meant by a custom screen field? If you need additional fields the system doesn't supply, we can create them (and whatever business rules attach to them) as part of a system update, fully supported and documented. If you're referring to data elements created and maintained by users, these would be outside the scope of our system. All data in our system is read-only accessible by ODBC to authorized users, so it's possible for users to extend it using separate SQL Server or Access databases and/or create their own user interfaces in Access or another product. Though we don't restrict users from creating them (and can even offer advice on a consulting basis) customizations like these aren't considered part of our system and aren't supported by our Tier One or documentation staff. Please clarify what you're looking for here and whether our model meets the requirement.
Answer:
Our preferred solution is for the system to allow for the creation of customer fields, however, we are also fine for this application with addressing the need through program enhancement in the future. We are going to move this requirement from a Minimum requirement to a Highly Desirable one. The Requirements document has been updated reflecting this change.
Requirement 6.4.8
The system shall have the capability to add or remove fields without affecting past data inputs
Question:
6.4.8: All modifications made by us as part of a system update are tested to ensure no impact to the reports, imports and exports in our system. By removing fields without affecting past data inputs, I assume you mean removing them from the user interface, not from the database itself? In the database, we would nearly always just stop using a field rather than removing it. In the very rare occasion of a breaking change, our update would include migration of any of our supported reports, exports, etc. Customers are responsible for any effect of breaking changes on their own customizations or integrations.
Answer:
We believe your response meets the requirement.
Requirement 6.4.9
The system shall provide a library of common field inputs, conditions, inspections, corrections in a drop down that can only be changed by an system administrator
Question:
6.4.9: We have system-level settings and lookup tables that can only be changed by an IT administrator (and are typically only modified during system updates); we also have a few types of user lookup data (such as the list of funds and revenue accounts and their display behavior, the list of bank accounts and their import configuration, etc) which can only be changed by a user in the "administrator" group. Are you asking for something else here, or are these the sort of controls this requirement is looking for?
Answer:
We believe your response meets the requirement.
Requirement 6.4.10
The system shall support employee dashboards that are customizable. Dashboards should show approval items, files and generate reports.
Question:
6.4.10: See 6.4.7. We provide a common user interface for all users (though depending on their security group membership, users may not have access to all features). It is possible for users to create their own interfaces for read-only information from our system using ODBC and tools like Access or SQL Server Reporting Services, though customizations like these are not considered part of our system and don't benefit from our documentation or support services. Please advise if this capability meets the needs of this requirement.
Answer:
After further review of this requirement, we are going to move it from a minimum requirement to Highly Desirable. The Requirements document has been updated to reflect this change.
Requirement 6.5 Alerts
Question:
6.5.1: We don't currently package any automated background processes with our system (though if needed, you could engage us to develop specific alerts as part of a system update). All data in our system is stored in a SQL Server owned, controlled and fully accessible by County IT, so it can also be queried through ODBC or tools like SQL Agent or Task Scheduler/Powershell to send your own email alerts, log data, drive custom dashboards or for used other alerting purposes. Does this give you the capability this requirement needs?
6.5.2: See 6.5.1
6.5.3: See 6.5.1
6.5.4: See 6.5.1
Answer:
After further review we are going to remove requirements 6.5.1 through 6.5.4. These were written for Software-As-A-Service applications, which is NOT a requirement in the proposal.
Requirement 6.7.1
The system shall be able to import data into the Cayenta Financial system General Ledger
Question:
6.7.1: Do you mean export data to, or import data from, Cayenta? We don't currently have an integration with Cayenta but if it's needed, this is something you could engage us to develop in a system update. In addition, we expose all our data through ODBC and/or direct SQL connection for any integrations you intend to develop internally. Would this meet the need of this requirement?
Answer:
Yes, we mean to export data from the Cash Receipting system to the Cayenta Financial System. To accomplish this, we would need to identify the format to use one of the Cayenta supplied interfaces or work with Cayenta and the selected Cash Receipting vendor on a joint development. It is not clear at this time what the design of the interface will be. We anticipate that it will likely be just a flat file interface.
Requirement 6.7.2
The system shall be able to import data into the Property Appraisal and Collection System to load property tax information.
Question:
6.7.2: See 6.7.1. We don't currently have an integration with PACS, though we have processes which allow for a single monthly property tax reconciliation transaction so you might not need real-time connection to the tax system. If an import needs to be part of the system, you can engage us to build it into a system update; in addition, we expose our data tables & views to you for any integration processes on your end. Does this give you the capability you need?
Answer:
The PACS solution only provides a flat file interface capability. We wrote this requirement so that we could move data from the Cash Receipting system to PACS once we clearly identify the business need and how the data will get into the PACS system. We are looking for the “capability” to move the data, not that it is currently available and operational.
Requirement 6.7.3
Question:
6.7.3: See 6.7.1. We don't currently have an integration with Sympro but we usually don't need detailed investment activity. We only need aggregate change in investment balance, and depending on how your fund investments work (some counties are "fully invested" so there's no need to distinguish fund balance, cash balance and investment balance separately) we may already be capturing the changes through general receipts and disbursements. Like with the other integrations, if something is needed here you can engage us to build it as a system update and/or give you data access for your own process. Would this meet your needs?
Answer:
This has the same answer as 6.7.2, we want to make sure that if we identify the need to import data to or received data from Sympro that the system we procure has the “Capability” to do so. An on premise SQL based system meets that functional need.
Requirement 6.8.1
The system shall have a User Accounts for each person that will access the application.
Question:
6.8.1: We use Windows-integrated security so we don't store user names or passwords (Windows does this more securely than we could hope to, also enforces your password and group policies). Would this meet the requirement?
Answer:
Yes, this meets the requirement
Requirement 6.8.2
Passwords to the system shall be encrypted
Question:
6.8.2: See 6.8.1
Answer:
Yes, this meets the requirement
Requirement 6.8.3
The application must permit users to change their passwords as required at predefined intervals, require specific character/numeric/punctuation use, and limit use of previous passwords.
Question:
6.8.3: See 6.8.1
Answer:
Yes, this meets the requirement
Requirement 6.9.1
The Vendor shall demonstrate that they have a disaster recovery plan for Skagit County data stored by vendor
Question:
6.9.1: We don't store any of your data ourselves: it's all on your SQL Server and County IT is responsible for backup, records retention, disaster recovery plan, etc. (We usually help set up the Database Maintenance Plan and review SQL recovery models with IT during installation). All documents are stored on County servers. Does this meet the criterion?
Answer:
Yes, this meets the requirement
Requirement 6.10.1
The system shall maintain records for a minimum of 7 years
Question:
6.10.1: See 6.9.1
Answer:
Yes, this meets the requirement
Requirement 6.10.2
The Vendor shall provide all data to Skagit County on termination of the contract
Question:
6.10.2: See 6.9.1. If you discontinue your subscription, we provide a denormalized data extract of all your data. You would then have to remove our application and SQL database from your servers and commit not to restore them from backup.
Answer:
Yes, this meets the requirement
Requirement 6.10.3
Vendor shall destroy all data on termination of agreement and after delivery to Skagit County
Question:
6.10.3: See 6.9.1
Answer:
Yes, this meets the requirement
Requirement 6.10.5
The Vendor shall be able to store file records of at least 10MBytes in size
Question:
6.10.5: See 6.9.1
Answer:
Yes, this meets the requirement
Requirement 6.11.1
Skagit County shall retain intellectual property rights to data created and/or derived by Skagit County Government
Question:
6.11.1: Yes, if referring only to data (the contents of records and report/export outputs). "Derivative works" of our system, our metadata, core data structures, code, stored procedures or other components of our system are generally things we retain rights to. We don't have additional fees for using these things but it can be an issue if you want to discontinue your subscription license with us while still using a feature, structure or code derived from our IP. If you intend to create extensions of our product and want these to survive the use and licensing of our system, the best practice is to discuss with us and have us provide you a denormalized export or view which is stipulated "no-IP". If you build something based only on no-IP views or exports (rather than using our core data structures, stored procedures, etc.) there will be no "derivative work" concern for that component. If you intend to do extensive integration or if it's important to create derivative works for use within your county, we can discuss a perpetual license buy-out option. This is probably over-explaining but I want to make sure to cover all the bases. Does the above meet the need from this requirement?
Answer:
We are not referring to anything that is your intellectual property, we only require that data created and maintained by Skagit County remains Skagit County’s intellectual property.
Requirement 6.13.1
The Data Conversion Process shall be able to transfer Documents that are linked with the Cashtax system if applicable
"Data Conversion" 6.13.1: Would you please explain this requirement? Our intention is to import your chart of accounts, all balances forward, and your outstanding warrants from Cashtax during the conversion process. Following this we don't intend to exchange data with Cashtax: ideal deployment has a month of parallel operation in which users are using both systems and checking their totals and outputs at the end of each day, but the systems don't talk directly to each other during this process. If this requirement refers to documents that are stored on the County filesystem we can leave them in the same location, we don't need to import them or transfer them anywhere. Does this meet the criteria for this requirement?
Answer:
After discussion with our internal staff, we have decided to remove this requirement,
Requirement 6.13.1
The system shall track and report on warrant processing as required by the Revised Code of Washington (RCW) 36.29.010.
Question:
"Warrant Processing" 6.13.1: We're not qualified to provide opinions about the law. Please provide specific technical requirements which would comply with this item (if not covered by the other itemized requirements in this section). If evaluation is needed before confirming compliance with this law, we invite you to accept our proposal conditionally on your own review and verification that our features are legally compliant.
Answer:
To meet the statutory requirement, the software shall be able to balance daily warrant transactions.
Requirement 6.13.3
The System shall have the ability to read and import each junior districts individual's text file from their software system.
Question:
"Warrant Processing" 6.13.3: It sounds like this requirement would require you to import files from many different systems and formats as dictated by the districts, a potentially expensive requirement. Our system supports a standard format for warrants which we would encourage you to stipulate as a required format to the districts. You can also engage us to develop specific custom import formats as part of a system update. Does this meet the requirement?
Answer:
Please provide your recommendation to meet the requirement as part of your proposal.
Requirement 6.13.5
Question:
"Warrant Processing" 6.13.5: Yes, though your bank may use a different format than the ones we support. Assuming they have an export we can use, we will create an importer during initial system customization. Does this meet the criteria?
Answer:
Yes, this meets our criteria.
Requirement 6.13.8
Convert daily warrant/ACH transactions into a receipt to upload into the financial system.
Question:
"Warrant Processing" 6.13.8: I'm not sure I understand this requirement. Could you please clarify? I believe that our users enter the total of warrants redeemed into the checkbook for reconciliation purposes, is this what you're referring to?
Answer:
Must record the daily warrant/ACH transactions on a receipt. Then upload those transactions into the appropriate fund and GL numbers in Cayenta through an automated process.
Requirement 6.13.10
The ability to import and extract individual county warrant data to reconcile to the financial system.
Question:
"Warrant Processing" 6.13.10: Does this requirement refer to importing individual warrants from districts and the county (such as payroll clearing / claims clearing from the Auditor's office), or something else? Like the district warrant imports, we can import County warrants in the standard format and/or create specific import formats as part of a system update. Does this meet the needs of the requirement?
Answer:
This question is referring to County data only, which are payroll and claims clearing warrants.
Requirement 6.13.11
The system shall be able to submit to each junior district a report of the state of finances on the first day of each month, which report shall be submitted not later than the 7th day of the month, which shall contain the balance on hand the first of the preceding month, the funds paid in, warrants paid with interest thereon, the number of warrants issued and not paid, and the balance on hand. The ability to create reports based off of the type of transaction ex: outstanding, issued, redeemed, voided and/or stop by date range.
Question:
"Warrant Processing" 6.13.11: We have a feature which allows users to set up distribution lists of districts and funds and customize which reports go to each recipient (by fund(s), report name and rollup level). This is a feature which users initiate:they enter the date range and a message, then select recipients and kick off the process. The 7th day requirement would be met by the user; the system doesn't automatically generate these reports without user intervention. Does this satisfy the requirement?
Answer:
This would meet the requirement
Requirement 6.13.12
The ability to create an ACH disbursement by fund to accommodate the electronic payments made by each district.
Question:
"Warrant Processing" 6.13.12: Users can enter disbursements (this a transaction type in our system, much like receipts and warrants are). Does that meet the criteria of this requirement, or are you asking for something else?
Answer:
This is the same answer as requirement 6.13.8
Requirements Document Issue
*** NOTE: there seem to be two sections numbered 6.13, using the labels below to clarify ***
Answer:
We have updated and corrected the Requirements document.
"Skagit County has budgeted $125,000 for implementation of the CRS solution. This cost includes third party software, professional services, license costs, subscription costs and/or hardware. This cost does not include ongoing support, which must be added to the cost sheet per section 12, Cost Proposal.
The budget includes ALL costs that would be invoiced prior to the date the County goes “live” on the system. Third party expenses, such as third party software would be part of this budgeted cost."
- Our system requires your county to have licenses for Microsoft Windows, Microsoft Office (including Access) and Microsoft SQL Server for all users. We don't sell these licenses. For the purposes of the budget can we assume that you already have (or outside of this scope, will procure) your Microsoft licensing?
Answer:
Skagit County will procure any needed Microsoft licenses.
Question:
- We have no special requirements for hardware other than your server and desktops meet the requirements to effectively run SQL Server, Microsoft Office, etc. Can we assume you already have (or outside of this scope, will procure) the necessary hardware?
Answer:
Skagit County will provide workstations, laptops, and printers. If there is speciality equipment such as a check scanner or point of sale system, those must be identified in the proposal.
Question:
- Our license is a subscription and we are willing to forego license fees for up to 90 days during data migration, customization, training and testing (or until "live" use, whatever comes first). Unless we have an unusually long implementation, little if any of our license fees would be invoiced "prior to the date the county goes live". If I understand you correctly, in our case, the $125k budget will cover all professional services (like project management, customization, training, etc.) and any license fees prior to "go live", but all ongoing fees after this (including licensing) are "ongoing support" and not included. Do I have this right?
Answer:
The budget of $125,000 is for project implementation. If license fees are separate from the subscription cost, then those would be included in the project implementation costs.
On-going support is being handled separately. A subscription would be considered on-going support. If licensing is managed within the subscription, then those fees would not be part of the implementation budget.
We require all costs for the next five years to be identified in the Cost Proposal. So the subscription fees will need to be entered on that sheet.
Question:
- Some of the materials call for a detailed project plan, Gantt charts, etc. at this stage of the process. With custom/niche software development it's very important not to make guesses or assumptions. Requirement gathering, project management, solution design and general consulting are billable services (and some of the most valuable things we do). These would be part of an engagement we will include in the Cost Projection. Until we've been through this process the project plans won't be worth much: in fact, all they can reflect at this stage is a "vanilla implementation" of our base system. We need to reserve the right to dive deep on customer requirements, discuss tradeoffs and make recommendations, or our solutions won't have much value: they will comply with the RFP but ultimately they won't have the outcomes we deliver to our other clients. I'm very hesitant to commit to anything we may need to change later. Would you rather for these sections that I recite "to be determined after project planning" or that I give you a simple plan with a disclaimer like "base plan with no customization: subject to change after project planning"?
Answer:
The proposal is for evaluation purposes. Once we select a vendor, then we will work on a contract where details are more defined, inclusive of project methodology, scope of work, project plans, training plans, etc… We ask that proposers provide the best data they have for their proposal submittal so that Skagit County has information to make an informed decision on which vendor we will move forward with.
|
