The URL can be used to link to this page

Home My WebLink AboutExhibit 9CLARK COUNTY REQUEST FOR PROPOSALS couNrr. eal # 365 Point of Sale Receipting System ISSUING AGENCY: Clark County Office of Purchasing ISSUED ON BEHALF OF: Clark County Treasurer's Office RELEASED: February 17.2004 CLOSES: March 19. 2004 PROPOSALS MUST BE SUBMITTED NO LATER THAN 4:30 P.M. TO: Clark County Office of Purchasing P.O. Box 5000 1300 Franklin Street, 6th Floor, Suite 650 Vancouver, Washington 98660 (360) 397-2323 x Request for Proposals Table of Contents 1.0 Introduction, Background, and General Information 1.1 Purpose 1.2 Program Description and Objectives 1.3 Authorized receipt of RFP 1.4 Funds Available and Source of Funding 1.5 Proposal Calendar 1.6 Bidder's Conference 1.7 Duration of Contract 1.8 Type of Contract 2.0 General Requirements 2.1 Independent Price Determination 2.2 Authorship 2.3 Price Warrant 2.4 Conflict of Interest 2.5 Subcontracting 2.6 Consortium of Agencies 2.7 Equal Opportunity 2.8 Award of Contract 2.9 Debarment and Suspension 2.10 Limitation 2.11 Cancellation of Award 2.12 Interlocal Agreements 3.0 Administrative Requirements 3.1 Single Audit Requirements 3.2 Other Audit/Monitoring Requirements 3.3 Insurance 4.0 Proposal Development 4.1 Proposal Format 4.2 Proposal Content 5.0 Proposal Submission 5.1 Schedule 5.2 Late Proposals 5.3 Verbal Proposals 5.4 Oral Presentations 5.5 Rejection of Proposals 2 6.0 Proposal Evaluation and Selection 6.1 Evaluation and Selection Process 6.2 Evaluation and Selection Criteria 6.3 Disputes Attachment A: Directions for Developing a Proposal Part I: Part II: Part III: Part IV: Part V: Part VI: Part VII: Part Vlli: Part IX: Proposal Summary Vendor Qualifications Customer References Functional Features Technical Features Interface & Integration Features Support & Training Features Credit Cards Features investment Summary Appendix A: Table of Statistical Information for Transaction & Workstation Counts Appendix B: Flow Charts ➢ Appendix B1: Proposed Point of Sales Overview. D. Appendix B2: CATS Receipting with Initiate a Refund. > Appendix B3: Oracle Receipting. > Appendix B4: Remittance Processor. > Appendix B5: Mortgage/Loan Servicing. > Appendix B6: CRIS+ Plus receipting. ➢ Appendix B7: Proposed web site process. > Appendix B8: Cashier Balancing, Depositing, and Oracle Cash Management. > Appendix 89: Excise tax process. > Appendix B10: Community Development (Tidemark) Permitting (4). Planning Permit, Building Permit, Fire Permit, Building Permit Payment options. All flowcharts are the current processes unless noted. 3 Request for Proposal # 365 Point of Sale Receiptina System 1.0 Introduction, Background, and General Information Clark County is a general-purpose government located in southwest Washington, adjacent to Portland, Oregon. The county's residential population is approximately 364,000. The County employs over 1,600 full and part-time employees. Clark County's annual revenue exceeds $220 million. In January 2003, the County opened its new Public Service Center with a joint lobby co -locating customer service delivery for the Assessor, Auditor and the Treasurer Offices. This is the first time in Washington State that this configuration of service delivery has occurred. The intent of this combination is to serve customers of these three offices by having one customer service specialist accommodate their county business associated with these three offices in a more effective and efficient manner. Today, a customer may be required to wait in different lines and have different cashiers service them because the transactions occur in separate applications. It is our desire to utilize a Point of Sale receipting application which allows a fully trained cashier, with one cash drawer, to service the customer's business needs regardless of the 'host' application. This will include updating the host application and the County's General Ledger. CURRENT SYSTEMS ENVIRONMENT THE JOINT LOBBY: The Joint Lobby is located on the second floor of the Public Service Center. Currently, cashiers located on this floor must use three (3) of the four (4) following applications to conduct county business effectively. 1) Oracle's Financial Management System 111 (FMS) on an Oracle database (version 8.1.7.3) running on a UNIX platform. The type of receipts processed include: Mapping fees, 911 Excise tax (telephone charges for emergency service delivery), NSF Fees, Foreclosure costs, deposits from our Junior Taxing Districts (such as Library, School, Fire Districts, Port, etc.), and miscellaneous receivables and receipts. The County has been processing transactions on this system since November 1, 2002. The following public sector modules are currently utilized: Accounts Receivable (AIR), Accounts Payable (AIP), Cash Management, Project & Grants, Purchasing, and General Ledger. HRIPayroll and Public Sector Budgeting will soon be implemented. The receipt count for 2003 is trending toward 47,000+ where approximately 33% are processed over-the-counter. These transactions are entered from various points: the 'front counter', the remittance processor (lockbox), and Bank Import files. During our morning bank file import routine, a receipt is automatically created for each of the deposits from our junior taxing districts and other county departments that deposit directly to a bank. Currently, there are approximately 20 individuals with Oracle 4 receipting capabilities, County -wide, but our current focus for this implementation is in the Joint Lobby, where 15 workstations are used for receipting. 2) A legacy Hewlett Packard (HP) MPE platform known as the County Assessor Treasurer System (CATS ) that has been in existence since 1986. This system also hosts the Local Improvement District (LID) assessment application. These 2 separate applications share the same name and address database. Payment transactions involving taxes and assessments are receipted into the CATS receipting module. These activities consist of Real and Personal Property taxes, Advanced Taxes, Clean Water fees, Lighting Assessments, Excise taxes and fees on real property and mobile homes, Land use, minor Water utilities, and County Road Improvement Districts (CRID's). An image database is utilized in this system. A mix of COBAL, QUIZ and Speedware programming languages are used to develop and maintain these applications. In the year 2002, the CATS system had 361,000 receipted transactions. Approximately 50,000 transactions were receipted over-the-counter. In addition to over-the-counter receipts, other data entry points are electronic files from the mortgage companies (115,000) and from the remittance processor (lockbox) for mailed -in payments (196,000). Hewlett-Packard (HP) has announced End -of -Life (EOL) support for this platform effective December 31, 2006. To accommodate this announcement, the County has begun a planned approach to replace this system (both hardware & software) and its associated applications. The County prefers to identify and purchase application solutions that are open - system in nature. Our expectation is that the new Point of Sale application will meet that objective. Additional information on the two applications listed above - Oracle Financials (FMS) and HP MPE (CATS): We currently have 9 cashiering stations in the joint lobby and another group of 15 workstations through out the County running both Oracle FMS & CATS. These cashiering workstations are all running Windows XP Professional operating system, while many workstations throughout the office are operating on Windows NT4. In order to accept receipts, our Cashiers must have both applications (CATS and Oracle) open to process transactions into the appropriate host application. For all mailed -in payments the County receives, the remittance processor readies a deposit to our banks, and also creates a file of the Oracle and CATS payments respective, which is then loaded into the appropriate system. These transactions are extracted and posted by batch to the specific tax/assessment parcel (account in CATS/LID) and distributed to the General Ledger (multiple records per receipt). The remittance system is an Image workflow system with a NCR Transport and programming and hardware support provided by Wausau Financial Systems. 3) Eagle Computer System software called 'Cris+Plus': The recording of documents, receipting of recording fees and issuing of marriage licenses, are transacted through Cris+Plus. 5 This application is a document image recording application that processes the recording of real estate transactions and issuing of marriage licenses for the Auditor's Recording department. In the year 2002, there were approximately 172,000 transactions processed by this application. There are 5 cashiering stations running Cris+Plus, with 15 stations connected to the Cris+Plus application for non-receipting activity. The Joint Lobby's public self-service area allows customers to utilize this application to inquire into ownership and real estate recording transactions themselves. These workstations run on Winows NT4 version 6.0 and Windows XP operating systems and some have touch screen technology. The data resides in an Oracle database. A database index is available on the County's Internet site that allows the public to determine if the appropriate documents are available on the system. Other Applications which will have interfaces to the Point of Sale include: Community Development Department: Collects permit fees and miscellaneous fees. 4) Accela's Tidemark Advantage software (formally known as Tidemark Solutions, Inc.) application is located in the Community Development offices performing the County's permitting process. The receipting activity into this application occurs on the first floor of the Public Service Center, where 7 cashiering stations record approximately 12,000 transactions annually. There are up to 150 PC's (County staff as well as outside agencies) that have access to Tidemark for inquiry purposes. The cashiering module accepts payments for items in Tidemark (permits) as well as miscellaneous items (such as maps and bus passes). In 2003, Animal Control began to utilize the cashiering application to record their deposits, but the detail activity continues to be in Animal Control's licensing application. Tidemark Advantage Cashier is interfaced to the County's General Ledger using summarized entries via a semi -automated process. The database for the Tidemark Advantage application is Oracle. Other Information: Please see Appendix A for future transaction activity and associated workstation needs to accommodate such growth. The County's network protocol is TCP/IP. Currently, the County's workstations (PC's) are Windows NT4 SP6 or Windows XP Professional. The current standards for new PC's are 1.7 Ghz with 512mb memory running Windows XP Professional and Microsoft Office XP, Existing PC's, which are 550Mhz or greater with 256mb of memory are being migrated to the County standard as well as moving to Windows XP. 1.1 Purpose Clark County's primary objective is to acquire a front-end, point of sale receipting application. This purchase will include assistance with installation & interfaces, associated training, and on -going software maintenance. This application will integrate with the various county department databases noted above. This will replace 6 the existing methods of receipting into multiple host applications by providing a single application with functionality which exceeds our current applications. 1.2 Program Description and Objectives Clark County is searching for a cashiering application that integrates with our current business applications. This new solution will not only replace our current receipting applications' unique transactional abilities, but must exceed such application's multi - transactional capabilities and enable a one -stop interaction with the customer by a single cashier. This new application must be scaleable so that in the future, it may be implemented throughout other Clark County offices where payment collection activities are being performed. One of Clark County's goals is to add web capability as a new transaction source. Current technology utilization would suggest there is a growing demand to provide for financial transactions to be processed using the web on a 24/7 basis for our citizens and business partners. Our customers are requesting the ability to complete transactions and make their payments over the Internet. These transactions must be processed through the awarded Point of Sale application. Clark County's objectives are: • To provide Clark County customers one -stop payment service. • To simplify and increase the speed of processing manual transactions by enhancing account balance inquiry capabilities and automating payment data input where possible. • To standardize the record keeping for payment collection activities from all sources including over-the-counter, IVRS, mailed payments, Internet -based collections, and other electronic sources. • To maintain appropriate control and accountability for all transactions through comprehensive audit trails and transaction research capabilities. • To automate preparation of bank deposits. • To simplify and speed up the Cashier's balancing process. • To create the ability to simultaneously inquire customer account balances across multiple host applications. • To provide miscellaneous AIR summary accounting transactions to Oracle AIR. • To provide clear & accurate reports to eliminate or aid daily reconciliation's. • To provide a simplistic process to handle electronic payments. • To implement 55 cashiering stations where stations may include, for example, the following peripheral equipment; scanner, receipt printer, OCR reader, electronic cash drawer and credit/debit card reader at each station, with the application capable of supporting an unlimited number of concurrent cashiering workstations simultaneously. • To create an application which provides for Internet transactional capability and using credit/debit card and/or electronic check payment tendering ability, while creating an integrated receipting and accounting process. This shall preclude having to perform multiple reconciliation's as to when the payment occurred versus when the cash was received, as well as posting to the appropriate account in the appropriate application on a credit or debit basis. 1.3 Authorized receipt of RFP All Proposers shall be listed on the Plan Holders List to be considered responsive. To be listed, you may contact Clark County Purchasing via e-mail: linnea.larocque a(�.clark.wa.gov, or call (360) 397-2323. 1.4 Funds Available and Source of Funding Clark County has planned for acquisition of hardware, software, and integration of such to the applications noted above. 1.5 Proposal Calendar February 17th, 2004 Purchasing Department will distribute the Request for Proposal February 18th Questions from vendors will be accepted up to the day of the bidders conference. All potential vendors will receive Clark County's response. After the conference, no further questions will be taken. Please address questions to: Iinnea.Iarocque5clark.wa.aov. March 3`d Bidders Conference (in person or conference call) March 10th Responses to Bidders Conference March 19th Proposals Due 1.6 Bidder's Conference A Proposer's Conference will be held at 10:00 am on March 3, 2004, to provide clarification of our expectations. Any clarifying responses will be made available in writing to all respondents. Attendance is encouraged, but not required. Vendors will participate either in person or by phone. For planning purposes, all participating vendors need to contact Steve Dahlberg at (360) 397-2252 x 4462 no later than 4:30 p.m. Pacific Time, Tuesday, March 2, to advise how they will be participating. Vendors electing to participate by phone will dial into the automated -system and be transferred into the conference call. Please follow these instructions: 1) Dial 360-397-2252 (Clark County Treasurer's office) 2) At the prompt "If you know the four -digit extension number of the person you would like to speak to"... then Press 5230. 3) The system will ask you to wait while your call is being transferred. 4) You will hear one or two rings and then silence while others are joining into the conference call. Incase of difficulty with these instructions, please contact Kathleen Smithline at: (360) 397- 2255 for directory - then press 4 e Vendors electing to participate in person will meet at the Clark County Public Service Center located at 1300 Franklin Street Vancouver, Washington on the sixth floor conference room # 678. Driving Instructions: http:llwww.clark.wa.gov/finditlgovmap.pdf 1.7 Duration of Contract A contract will be awarded to the successful respondent to this RFP for the necessary timeframe to perform the required components of this request. All Proposers shall include a timeframe for installation and integration of the system requirements. Contract duration will be negotiated with the successful Proposer. 1.8 Type of Contract A fixed price contract. 2.0 General Requirements Clark County is requiring that the Vendor and Application must be able to meet the following requirements. For each item below, please describe how the Vendor and Application supports the following mandatory items. Please utilize the blank space immediately following the question for your answer. If reference is made to another document, please clearly reference that source. All items must pass in order to proceed with the RFP. If the Vendor or Application fails, their RFP will not be considered any further. Item MANDATORY FEATURE PASS FAIL 2.0.1 The Application must run on Windows NT and XP workstations. 2.0.2 The Application must communicate over a network via TCP/IP protocol. 2.0.3 The Application must be able to utilize an Oracle Database version 8i or greater or MS SQL database version 7 or above. 2.0.4 The Application must be able to inquire multiple host systems at the same time. 2.1 Independent Price Determination The prospective contractor guarantees that, in connection with this proposal, the prices and/or cost data have been arrived at independently, without consultation, communication, or agreement for the purpose of restricting competition. This does not preclude or impede the formation of a consortium of companies and/or agencies for purposes of engaging in jointly sponsored proposals. 2.2 Authorship 9 Applicants must identify any assistance provided by agencies or individuals outside the Proposers own organization in preparing the proposal. No contingent fees for such assistance will be allowed to be paid under any contract resulting from this RFP. Ali proposals submitted become the property of Clark County. It is understood and agreed that the prospective contractor claims no proprietary rights to the ideas and written materials contained in or attached to the proposal submitted. 2.3 Price Warrant The proposal shall warrant that the costs quoted for services in response to the RFP are not in excess of those which would be charged any other individual or entity for the same services performed by the prospective contractor. 2.4 Conflict of Interest All proposals submitted must contain a statement disclosing or denying any interest, financial or otherwise, that any employee or official of Clark County or the appropriate Advisory Board may have in the proposing agency or proposed project. 2.5 Subcontracting No activities or services included as a part of this proposal may be subcontracted to another organization, firm, or individual without the approval of Clark County. Such intent to subcontract shall be clearly identified in the proposal. It is understood that the contractor is held responsible for the satisfactory accomplishment of the service or activities included in a subcontract. 2.6 Consortium of Agencies Any consortium of companies or agencies submitting a proposal must certify that each company or agency of the consortium can meet the requirements set forth in the RFP. 2.7 Equal Opportunity It is the policy of Clark County to require equal opportunity in employment and services subject to eligibility standards that may be required for a specific program. No person shall, on the grounds of race, color, religion, sex, handicap, national origin, age, citizenship, marital status, political affiliation or belief, be denied employment or benefits, or be discriminated against as a consumer, administrator or staff person under any program or activity receiving funds under this RFP. In compliance with Department of Labor Regulations implementing Section 504 of the Rehabilitation Act of 1973, as amended, no qualified handicapped individual shall be discriminated against in admission or access to any program or activity. The prospective contractor must agree to provide equal opportunity in the administration of the contract, and its subcontracts, or other agreements. 2.8 Award of Contract 10 The contract award will not be final until Clark County and the prospective contractor have executed a contractual agreement. The contractual agreement consists of the following parts: (a) the basic provisions and general terms and conditions, (b) the special terms and conditions, (c) the project description and goals (Statement of Work), and (d) the budget and payment terms. Clark County is not responsible for any costs incurred prior to the effective date of the contract. Clark County reserves the right to make an award without further negotiation of the proposal submitted. Therefore, the proposal should be submitted in final form from a budgetary, technical, and programmatic standpoint. 2.9 Debarment and Suspension The contractor must certify that they are not debarred or suspended or otherwise excluded from or are ineligible for participation in Federal Assistance programs under Executive Order 12549, "Debarment and Suspension". The contractor must also certify that it will not contract with a subcontractor that is debarred or suspended. 2.10 Limitation This RFP does not commit Clark County to award a contract, to pay any costs incurred in the preparation of a response to this RFP, or to procure or contract for services or supplies. Clark County reserves the right to accept or reject any or all proposals received as a result of this RFP, to negotiate with all qualified sources, to waive formalities, to postpone award, or to cancel in part or in its entirety this RFP, if it is in the best interest of Clark County to do so. 2.11 Cancellation of Award Clark County reserves the right to immediately cancel an award if the contractual agreement has not been entered into by both parties, or if new state regulations or policy make it necessary to change the program purpose or content, discontinue such programs, or impose funding reductions. In those cases where negotiation of contract activities are necessary, Clark County reserves the right to limit the period of negotiation to sixty (60) days, after which time funds may be unencumbered. 2.12 Interlocal Agreements Clark County has made this RFP subject to Washington State statute RCW 39.34. Therefore the bidder may, at the bidders option, extend identical prices and services to other public agencies wishing to participate in this RFP. Each public agency wishing to utilize this RFP will issue a purchase order (or contract) binding only their agency. Each contract is between the proposer and the individual agency with no liability to Clark County. 3.0 Administrative Requirements Contractors shall comply with all management and administrative requirements established by Washington Administrative Code (WAC), the Revised Code of the State of Washington (RCW), and any subsequent amendments or modifications, as applicable to providers licensed in the State of Washington. 3.1 Audit Requirements 11 Any contract awarded as a result of this RFP includes an agreement by the successful Proposer to have performed an annual audit of its financial statements, which have been compiled in compliance with United States Generally Accepted Accounting Principles, and performed in accordance with Generally Accepted Auditing Standards. Such audit shall be remitted to the County on an annual basis for the year of the engagement, and two successive years after completion of this engagement. 3.2 Other Audit/Monitoring Requirements In addition, for this project, auditing or monitoring for the following purposes will be conducted at the discretion of Clark County. a. Contract compliance; and b. Program performance. 3.3 Insurance • General Liability The Contractor shall provide to Clark County a copy of commercial general liability insurance to protect against legal liability arising out of Contract activity. Such insurance shall provide a minimum of $1,000,000 per occurrence and $2,000,000 annual aggregate limit, with a maximum deductible of $5,000. • Auto Insurance If the Contractor or its employees use motor vehicles in conducting activities under this Contract, liability insurance covering bodily injury and property damage shall be provided by the Contractor through a commercial automobile insurance policy. The policy shall cover all owned and non -owned vehicles. Such insurance shall have minimum limits of $500,000 per occurrence, combined single limit for bodily injury liability and property damage liability with a $1,000,000 annual aggregate limit. If the Contractor does not use motor vehicles in conducting activities under this Contract, then written confirmation to that effect on Contractor letterhead shall be submitted by the Contractor. 4.0 Proposal Development 4.1 Proposal Format Directions for developing a proposal are included in Attachment A. Acceptance of proposals is based, among other criteria, on detailed adherence to the directions outlined in Attachment A. Clark County reserves the right to reject proposals not in compliance with this requirement. 4.2 Proposal Content At the time of submission, the proposal must provide a full description of all services following the outline presented in Attachment A. The proposal must enable readers to understand how the Proposer intends to use these public funds, and what measurable outcomes are expected. (See instructions in Attachment A for more information.) Proposers are reminded that proposals will be considered exactly as submitted. Points of clarification will be solicited from Proposers at the discretion of Clark County. Those proposals determined to not be in compliance with provisions of this RFP and the applicable law and/or regulations will not be processed. 12 The information and proposed budget for the agency selected for contract award will form the basis for negotiation of a contract. Clark County reserves the right to issue a contract without further negotiation using the data contained in the RFP. Failure of a prospective contractor to accept this method of contract development will result in cancellation of the award. 5.0 Proposal Submission 5.1 Schedule The original proposal package (with the appropriate number of copies) must be delivered to the following location no later than 4:30 p.m. on March 19th. 2004: Clark County Purchasing Department 1300 Franklin Street — 6th floor, Suite 650 Vancouver, Washington 98660 Original documents and appropriate copies must be delivered to the Clark County Purchasing Department in sealed package (s). Include RFP# and Name/Organization visibly located on outside of package. Proposals received with insufficient copies cannot be properly disseminated to the Review Committee and other reviewers for necessary action and therefore may not be processed. COPIES REQUIRED: One (1) Original and Thirteen (13) Copies Include One (1) electronic version of your proposal on a CD-ROM 5.2 Late Proposals A proposal received after the date and time indicated above will not be accepted. No exceptions will be made. 5.3 Verbal Proposals Verbal proposals will not be considered in making the award of any contract as a result of this RFP. 5.4 Oral Presentations Prospective contractors may be informed that an oral presentation is desired and will be notified of the date, time and location the oral presentation is to be conducted. 5.5 Rejection of Proposals Clark County reserves the right to reject any or all proposals received and to negotiate with any or all prospective contractors on modifications to proposals. 6.0 Proposal Evaluation and Selection 13 6.1 Evaluation and Selection Process Proposals received in response to this RFP will be evaluated by a Review Committee. The Committee will review the results and recommendations which may be presented to an appropriate advisory board prior to the consent process with the Clark County Board of Commissioners. 6.2 Evaluation and Selection Criteria Clark County will have an evaluation team consisting of appropriate managers, employees, and Information Services staff to review the proposals. Each proposal received will be objectively evaluated and rated according to a specific point system. A) The first phase of the evaluation is based upon the successful passing of the questions in 2.0 General requirements by the Proposer(s). 14 B) The second phase is based upon the representative scores each Proposer receives under the following sections. For each section, the maximum number of points possible is depicted below. Each evaluator will assess vendor responses and assign points, which may be full points, partial points or no points. The scores of the evaluators will be compiled and ranked. The top vendors will be requested to conduct an on -site demonstration and technical discussion of the application they are proposing. Attachment A Attachment A Attachment A Attachment A Attachment A Attachment A Attachment A Attachment A Attachment A Part I - Proposal Summary Part II - Vendor Qualifications Part III - Customer References Part IV - Functional Features Part V - Technical Features Part VI - Interface & Integration Features Part VII - Support & Training Part VIII - Credit Card / E-Check Part IX - Investment Summary Cover Page Available points 10 Available points 5 Available points 40 Available points 25 Available points 25 Available points 15 Available points 10 Available points 20 Total points 150 C) The final phase of the selection process will be the Demonstration. This will consist of a functional demonstration of the systemic process proposed, a technical discussion of how the application will look, and what steps and processes will be performed to successfully integrate the point of sale to each application identified herein, and a review of the cost proposal. For the functional demonstration, a listing of items and technical questions to be demonstrated will be provided. The top scoring vendor will be selected. A functional demonstration of the Application A Technical Discussion Review of Cost Proposal (5 year summary) 6.3 Disputes Available points 50 Available points 20 Available points 30 Total Points 100 Clark County encourages the use of informal resolution to address complaints or disputes arising over any actions in implementing the provisions of this RFP. Written complaints should be addressed to Clark County - General Services, P.O. Box 5000, Vancouver, Washington 98666-5000. 15 Attachment A Directions for Developing a Proposal These instructions were developed to aid in proposal development. They also provide for a structured format so reviewers can systematically evaluate several proposals. These directions apply to all proposals submitted. An original and each copy of the proposal package must include all of the sections in the order indicated; attachments should be clearly referenced and identified to facilitate the review process. Part I: The "Proposal Summary" form is designed to serve as the cover sheet. Do not attach cover letters, title pages, or blank sheets ahead of this form, nor substitute letterhead paper for it. If additional space is needed, plain paper may be attached behind this form. Special bindings are not required for submittal of your proposal. This form must be signed by a person authorized to make proposals and enter into contract negotiations on behalf of your Agency. Part II: The "Vendor Qualifications" must reflect the Proposer's ability to perform the specific criteria and appropriately respond to the questions listed. Part III: The "Customer References" needs to be a list of references that most closely match Clark County, Washington in size, scope, and host applications. Clark County will conduct phone interviews with these references. Part IV: The "Functional Features" must demonstrate the Proposer's ability to perform the specific criteria and how the questions listed will be functionally performed by the application. Part V: The "Technical Features" must demonstrate the proposer's ability to process the specific criteria and demonstrate through the questions listed how the application will be properly integrated to the various applications and databases. Part VI: The "Interface & Integration" must demonstrate how the specific criteria will be performed and the questions listed must demonstrate a complete understanding of the scope of the project. Part VII: The "Support & Training" must clearly demonstrate how the specific criteria will be performed and questions listed should provide a clear understanding of the commitment required of the Proposer and the County to effectively have the application understood by the County's employees. Part VIII: The "Credit Card Features" must demonstrate functional use of each of the specific criteria and questions listed are to provide a clear understanding by the County as to how the tender type will be transacted under the proposal. Part IX: The "Investment Schedule" section has a defined schedule in order to standardize the format of the vendor proposal responses and must be completed as presented. If additional information is required to complete the Investment Schedule, please clearly indicate and reference the additional documentation. 16 Request for Proposal # 365 Point of Sale Recelptinq System Part I PROPOSAL SUMMARY General Information: Legal Name of Applicant Street Address City State Zip Contact Person Title Phone Fax Program Location (if different than above) e-mail address Tax Identification Number Total Funds Requested Under this Proposal $ Did outside individuals or agencies assist with preparation of this proposal? Yes No If yes, describe. The following items are to be returned in response to the Point of Sale proposal. Part I — Proposal Summary Part II — Vendor Qualifications Part III -Customer References Part IV — Functional Features Part V — Technical Features _Part VI — Interface & Integration Features Part VII — Support & Training Part VIII — Credit Card / E-Check Part IX —Investment Summary Electronic copy (1) on CD-ROM I certify, that to the best of my knowledge the information contained in this proposal is accurate and complete, and that I have the legal authority to commit this agency to a contractual agreement. I realize the final funding for any service is based upon funding levels, and the approval of the Clark County Board of Commissioners. Signature, Administrator of Applicant Agency Date 17 Request for Proposal # 365 Point of Sale Receiptina System Part II VENDOR QUALIFICATIONS 10 Points Possible To provide an understanding of the Vendor qualifications to successfully implement this system, the following questions must be responded to by each Proposer. Please provide your response in the space provided immediately following the question, reference documents or other supporting information, should be attached immediately after this section. This section has 10 points possible for inclusion in the Summary of Points. Item # Vendor Overview II.1 Please provide audited financial statements for the last three years. I1.2 Please provide a corporate profile, including number of employees, types of jobs such employees perform, number of employee in each type of functional expertise, and site locations and number of employees at such sites. Type should include categories like: Admin, Sales, Training, Implementation, Operations, Software, Helpdesk, Others, etc. II.3 Are you a subsidiary of a parent entity? If so, please provide a corporate overview of the parent and your relationship to it. I1.4 How long have you been in the cash collection "Point of Sale" business? How long has the current version been released? 1I.5 Please provide a strategic overview for the future enhancements, specifically in regards to electronic commerce. 1I.6 Listyour strategic partners, if any, and the role they play in the implementation. 11.7 Describe the roles which Clark County and yourself will perform during system planning, data conversion, implementation, and start-up. II.8 Describe your approach to post -implementation support. I1.9 Describe how you manage application "bug" corrections (fixes). II.10 Describe project escalation based upon the seriousness of a bug or problem. II.11 Describe the typical response time for a successful resolution to a bug or problem. I1.12 Describe your preferred approach to system customization. I1.13 Describe an overview of your typical application upgrade / enhancement strategy. 18 Request for Proposal # 365 Point of Sale Receiptinq System Part III CUSTOMER REFERENCES 5 Points Possible Please provide a list of references that most closely matches CIark County, Washington in size, scope, and host applications. Clark County will conduct a phone interview with those references. Customer: City & State: Contact Person: Title/Position: Phone: E-Mail: Customer: City & State: Contact Person: Title/Position: Phone: E-Mail: Customer: City & State: Contact Person: Title/Position: Phone: E-Mail: Customer: City & State: Contact Person: Title/Position: Phone: E-Mail: 19 Request for Proposal # 365 Point of Sale Receiptinq System Part IV FUNCTIONAL FEATURES 40 Points Possible Please provide a narrative response to each feature in the expandable line following each item. If references are made to external documents or examples, please provide a clear reference to that source. This section is to determine how each proposed Point of Sale application is able to support the following features. ITEM# REQUIREMENT OPERATOR (CASHIER) INTERFACE IV.1 The Application should be easy to navigate and guides the Cashier through the transaction. IV.2 The Application shall have a Windows look & feel. IV.3 The Cashier may select a deposit date that is in the future. The Application must be able to exclude holidays, weekends, and County defined holidays. The date needs to be flexible in that we may future date to accommodate Bank activity, and we may date for today in relation to a special deposit. IV.4 Describe the Application's ability for a Cashier to begin a transaction, "save" the incomplete transaction, then later have the ability to recall the specific transaction and complete it. This recalling of a transaction may occur on another receipting day. If needed, can it be retrieved by another cashier? What security features does the Application have to track such an activity on a transaction. IV.5 Describe the Application's ability for a Cashier to complete a receipt and later have that receipt reversed or voided. Describe system controls over this type of activity. IV.6 The Application shall provide for and assign unique cashier numbers and consecutive receipt numbers unique to that cashier. Unique receipt numbers may be passed to or pulled from a host system. The receipt number may contain both alpha and numeric characters. IV.7 The opening of the cash drawer should be controlled by the computer, and will automatically open at the proper time. Is the closing of the cash drawer noted? IV.8 Describe the Application's ability for a Cashier to flow through a receipting routine where transaction attributes will be validated and, if error conditions are detected, a pop- up help will guide the cashier for re -input of correct values. IV.9 The Application shall allow a Cashier to begin a cycle of multiple items with a single or multiple -payment type and completing that cycle with one receipt. 20 ITEM# REQUIREMENT IV.10 Describe the Application's ability to process remittances for items that are both host - system driven as well as miscellaneous items. Example: a customer needs to pay for a Permit (host system) as well as a photocopy charge (misc. item) using a single payment, with both items recorded on the same receipt. IV.11 The Application's ability to display meaningful error and warning messages based upon predefined transaction detail and attribute processing rules. IV.12 The Application's ability for the cashier to use transaction detail context sensitive help during a receipt routine. IV.13 The Application's ability to use predefined special key operations to facilitate the flow and operation of a receipt routine (such as function keys) to invoke a specific action. IV.14 The Application's ability to invoke special operations when the existence of predefined transaction detail attributes is detected. IV.15 The ability of operators to view external applications during any receipting routine. Example: toggling to a different system or application to look -up additional information or use the workstation as a 'normal' PC. IV.16 The ability to copy/paste data from an external Application to an on -screen field and vice versa. IV.17 The ability to cash warrants and report the appropriate tendering activity. IV.18 The ability to open the cash drawer, make change for a customer without recording a transaction, but maintain a record of the event. IV.19 Describe the Application's ability to limit available activities (menu items) based upon department or individual or transaction type. Example: 1) Joint Lobby cashier can receipt all activities, except for permits. 2) Deptl shall only receipt Deptl's transactions. IV.20 Describe the Application's ability to initiate a "cashier refund" IE: to initiate the refunding process when accepting an overpayment. This would be to create a file formatted as an Oracle Invoice, and sent to Oracle AP, and a supporting report to be printed. IV.21 The Application shall also provide an inquiry only mode. IV.22 Describe the Application's ability to link to an imaging system. IV.23 Describe the Application's ability to inquire on a name or account # (or some other field such as address, etc.), and bring on -screen any balances or activity from the various host systems. Will it also be able to retrieve transactions? 21 ITEM# REQUIREMENT RECEIPTS - FOR THE CUSTOMER IV.24 Describe the ability of the Application to allow Clark County to design unique receipts for each department or category of transactions. IV.25 Describe the type(s) of receipts that are produced for the Customer IV.26 Describe the ability for Clark County to have additional data elements on the receipt. How many data elements are available? This would be different data elements based upon transaction activity. Examples of some (but not all) unique data elements: For Property tax: -Property #, Receipt #, Tax Year. For Recording activity: -Receipt #, Transaction #, Document #, # of pages. For Oracle activity: -Receipt #, Document #, Activity Code, Invoice # IV.27 Describe the Application's ability for different departments having unique endorsements for checks. IV.28 Describe Application's ability to interface with various external Applications, such that balances can be updated and/or returned for on -screen viewing, as well as be included in a receipt. IV.29 The Cashier shall be able to reprint a receipt at any time. Are reprinted receipts any different than the original receipt? TENDERING IV.30 Describe the Application's ability to record a check number during the tendering process. IV.31 The Application should be able to capture an image of the check, and create an electronic file of data and images, which is transferred to the remittance network. IV.32 Describe the Application's ability to limit payment methods for selected Activities. In other words - not all payment types are valid for all activities. Example: Property taxes will accept Cash, Check, E-Check, and Debit card, but will not accept Credit cards. Another example is that the web will only accept Credit/Debit cards and E-Checks. 1V.33 The Application shall not have any limits as to the quantity of remittances accepted. Example: Title companies often send in a batch of items (20) to be recorded, along with one or more checks for each item. IV.34 Describe the Application's ability to endorse checks. This may include different departments with their own endorsement. IV.35 Describe the ability to utilize check verification services. What data is captured from the verification process? 22 ITEM# REQUIREMENT IV.36 Describe the Application's ability to perform check conversion to ACH-(transfer electronic file to remittance processor for ACH conversion). IV.37 The Application shall have the ability to accept multiple payment types for a single transaction. This may be like, but not limited to: cash, check, money order, and a credit card for a single transaction. IV.38 The Application shall be capable of accepting a single payment where there are multiple transactions. Are there special issues if the activities are from multiple host applications? IV.39 Describe the Application's ability to process a warrant. This payment type does not go to the bank if presented over the counter. IV.40 Describe the Application's ability to track a'Credit' for a customer that may not be in the current Oracle Accounts Receivable. Currently, we have a couple of instances where this applies: 1) A Customer prepays an amount, then later uses this credit as a payment option. 2) A department applies a credit to a special customer # where the customer provides a service on behalf of the County, then uses this credit as a payment option. IV.41 Describe the Application's ability to have a 'No Charge' payment type for internal customers where this method satisfies the host systems 'paid' status (to complete the process), yet the payment is processed as a Fund Transfer by the accounting department. IV.42 Describe the Application's ability to track a' Prepaid' card, if the County should decide to offer that option in the future. IV.43 Describe if the Application will support check truncation (check 21) in the future? IV.44 Describe how a "Correction" would be handled for each given transaction. Examples: 1) An incorrect account charged for a miscellaneous receipt. 2) A payment type of cash was selected, but the payment was actually a check. 3) Wrong Account number as entered. Fully describe internal controls associated with this activity. IV.45 Describe if there is the ability to have a returned check file that flags the Cashier to this condition and doesn't allow the acceptance of this check without an authorized manager override. IV.46 Describe the ability to create and handle a derog file. A derog file is created each evening, capturing all the items that are pending payment or have been paid. The file is used by the CATS receipting application and the remittance system to help prevent receipting a duplicate payment. IV.47 The Application should automatically calculate and display change due when appropriate, show the change amount and who received the money on the receipt. If the County desires to record who receives any cash back, will the Application have this feature? Example: when a 'company runner' receives cash back for a permit paid by a company check. 23 ITEM# REQUIREMENT ADMINISTRATION OF MENUS, CATEGORIES, AND OTHER ATTRIBUTES IV.48 Describe the ability or process for an authorized person(s) to create, modify and delete the design and behavior of a receipt routine using a graphical user interface. IV.49 Describe an administrator's ability to build a new menu, menu items and related features for a new department or activity. Can this be implemented in real time? Can this be scheduled for a future effective time? IV.50 Describe an administrator's ability to modify existing menu configurations and features. Can this be implemented in real time? Can this be scheduled for a future effective time? IV.51 Describe any remote administration capabilities. IV.52 Describe the Application's capacity to have additional tables that contain user defined products, costs, accounting codes, etc., that departments may select to provide (sell) that are not in a 'Host' system. Example: a department may also sell bus passes, maps, photocopy charges and other misc. items in addition to their regular product/service. Each of these items would have appropriate amounts and accounting codes associated with it when sold. IV.53 Describe the Application's capacity to provide and walk the cashier through a customized process that requires a series of steps. This example relates to processing real estate excise. Begin by entering a property # which retrieves information from CATS, computes the Excise amount, assigns an excise number, saves all this information, then either 'check out' or continues to record the document(s) in the Recording Application, then 'checking out'. How can the data saved be exported to allow for analysis and distribution at a later time? IV.54 The Application set up should be as much table driven as possible, allowing Clark County to define, maintain, and control the maintenance of such data. IV.55 The Application shall have unlimited payment types that are user defined and maintained. This would include items such as Cash, Check, Warrant, Money Order, Credit/Debit Card, e-Check, etc. BALANCING AND CLOSING IV.56 Describe how a special deposit is handled. A special deposit typically occurs when a cashier receives a large amount of monies (cash and checks) and Clark County wants the monies to be deposited that day. IV.57 Describe the daily balancing and closing procedure the cashiers are to perform. IV.58 Describe the counting of the cashier's till. IV.59 Does the cashier have an option to count the contents or the value of contents? For example, 12 quarters in the till - 12 quarters and the application computes the value or the cashier enters the value of $3.00. 24 ITEM# REQUIREMENT IV.60 Are rolled vs. loose coins counted separately? IV.61 Describe the Application's ability to handle cashing a warrant. IV.62 The Cashiers shall be able to view reports on -screen and as printed reports. IV.63 Describe the cashier transaction journal where the transaction details are listed in date/time order and may be viewed as either electronic or a printed listing. Will the application allow for other sort -orders? IV.64 For the following: Any of these reports may need to include various additional sorting. IV.65 Describe the ability to summarize transaction detail at the close of business by menu and menu category. IV.66 Describe the ability to summarize transaction detail at the close of business by Host system. IV.67 Describe the ability to summarize transaction detail at the close of business by Cashier. IV.68 Describe the ability to summarize transaction detail at the close of business by Cashier and Payment type. IV.69 Describe the ability to summarize transaction detail at the close of business by workstation. IV.70 Describe the ability to summarize and transfer automatically the activities of a cashier, when balanced, to either Oracle A/R or Oracle General Ledger as required by the business rules for that activity or function. IV.71 Will the Application allow reprinting of any balancing reports to be run at any time? Is any special authority required? IV.72 Describe the method(s) that are utilized to balance Application -wide activity for a given day. IV.73 Describe recommended credit card and other electronic payment settlement capabilities and procedures. TRANSACTION DETAIL ACCESS AND REPORTING IV.74 Describe the ability to provide immediate access to transaction detail activity for problem solving and audit trail purposes. IV.75 Describe the ability to access data based upon any transaction detail attribute (operator, menu, date/time ranges, payment type, receipt #, etc.). Is there the ability to drill down from the report to the source documents? 25 ITEM# REQUIREMENT IV.76 Describe the ability to allow access to the data from query tools not included in the application software. Please give a few examples of such query tools. IV.77 Describe the ability to export data on a scheduled basis to external databases for historical analysis (data warehouse). IV.78 Describe the ability to provide reporting in various formats: paper, on -screen, export, or electronic. IV.79 Describe the report writer(s) that is (are) available so that Clark County may run ad hoc reports if necessary. Does it (Do they) come with the purchase or added -on separately? IV.80 Describe the ability to have reports run automatically per a defined schedule. IV.81 Describe the Application's range of comprehensive management reports. This should include reports providing daily, weekly, monthly, and/or yearly reporting of various business activities based upon a period selection by the user of the report. The Application should also include detailed and summarized transaction reports by revenue codes, departments, menu categories, etc. IV.82 Describe if the Application can generate a report of a customer's activities over a period of time selected by the operator to reflect a historical presentation. How about a payment history where the customer is not an A/R account? AUDITING FEATURES IV.83 Describe the application's auditing features built into the program. IV.84 Describe how and in what ways the Application will aid the cashier in finding 'problems' when balancing? What kind of a "Help" on-line document is available? IV.85 Describe the process used if an Auditor wanted to review the activities for a cashier for a specific period of time. IV.86 Are all changes tracked for auditing purposes including date, time and user? IV.87 Describe the Application's ability to track credit card activity attributed to activity to any given bank, by any given cashier, on any given day. IV.88 Are transactions ever deleted from the system? If so, what kind of an audit trail is created for historical and management records? IV.89 Describe how administrators or management can access tender type activity to include dollar amounts for a workstation and or specific cashier. IV.90 Describe the auditing process to review a cashier's work for a given period of time. 26 ITEM# REQUIREMENT TOTAL POINTS POSSIBLE - 40 27 Request for Proposal # 365 Point of Sale Receiptinq Svstem Part V TECHNICAL FEATURES 25 Points Possible Please provide a narrative response to each feature in the expandable line following each item. If references are made to external documents or examples, please provide a clear reference to that source. This section is to determine how each proposed Point of Sale application is able to support the following features. ITEM# RE UIREMENT NETWORK PERFORMANCE & PROTOCOL V.1 Describe optimum andlor required 10Base-T network connection speeds for the Point of Sale application server communications. (10Base-T, 100 Megabit, Gigabit, etc). V.2 Describe optimum andlor required network connection speeds for a Point of Sale application workstation communications. (10Base-T, 100 Megabit, Gigabit, etc). V.3 Describe any benchmarks that you use to assess performance for the proposed Application. APPLICATION AND DATABASE SERVER COMPONENTS V.4 Clark County has a mix of business applications running a mix of Oracle and Microsoft products. Our Server environment is a mixture of HP-UX and Microsoft server products. Please describe how your Application fits within this environment. V.5 Identify the recommended application server and database server architecture for the proposed Application. V.6 Identify all supported server operating systems certified to run the proposed product. Identify the recommended platform. Identify all versions supported. Provide historical and projected version update turnaround schedules. V.7 Identify the recommended specifications for server configurations required to operate the proposed application server software and database management system. Include: Processor configuration, memory requirements, data storage requirements, and other physical components that are pertinent to your configuration. V.8 Describe the application administrator user interfaces. Please provide what items are accessed to assist in maintaining and monitoring the Application, such as connections, performance, etc. V.9 Describe application -specific fault tolerance strategy and ability. Include descriptions of management functions for error detection and alerts. 28 ITEM# REQUIREMENT V.10 The Application shall be able to automatically notify a system administrator where there is a problem or issue with the Application or database. V.11 Describe database backup strategy and ability. Include description concerning ability to perform hot'backups without disabling the application. V.12 Describe the Application's ability to 're -connect' to a host system if it should go down unexpectedly or isn't available during normal business hours. V.13 Describe the recovery techniques used by the database server. In particular, explain how all the completed and committed transactions (but not posted to the host system) can be retrieved in the event of a hard disk failure in the server or in a client. CLIENT SERVICES (OPERATOR WORKSTATIONS) V.14 Describe client system hardware specifications. V.15 Describe the Application's abilities to support different workstation configurations: A) workstations with a full complement of peripheral devices such as receipt printers, card readers, optical readers, etc; B) workstations with no peripheral devices used only for back room operations. V.16 Describe client workstation touch screen capabilities. WEB FEATURES V.17 Where web -based user operations are applicable, identify preferred web server platform. V.18 Where web -user interfaces are applicable, cite browsers and versions supported. V.19 Where web -user interfaces are applicable, cite browsers and versions supported. APPLICATION / DATABASE SERVER / CLIENT INTERACTIONS V.20 In a client/server configuration, discuss how upgrades to the software resident on the client and/or the server are managed? How are integration issues associated with upgrades handled, including addressing "patches" to prior application versions? V.21 Describe how data validations may occur when a client is operating in an offline mode. Situations may occur where a Host system is not currently online or disconnected to the POS Application. V.22 Describe how the proposed product synchronizes data between a client workstation and the application database when offline operations are necessary due to a host or network outage. 29 ITEM# REQUIREMENT V.23 If a workstation has not been used for quite some time, describe how it would be brought 'Current' so that it could easily go back into production as needed. DATABASE, CODE, AND MANAGEMENT SYSTEM V.24 Describe the method of distributing and installing modifications to the proposed software that are developed and recommended by the Vendor. Please outline the responsibilities of the Vendor and Clark County in the installation and acceptance of such modifications. V.25 Does the application ship with a detailed data dictionary and data model definition in textual and/or graphical format? Is all applicable documentation included? V.26 Describe whether or not application -specific administrative functions interact with the database management system. Specifically, if an application administrator has the ability to define new transaction data attributes for use in a new menu, may the new data be defined within an application function, and the data definition then propagate to dynamically build the new database table or fields? Or, is there dependency on first modifying the database by a DBA? V.27 Describe ODBC compliancy. Provide a list of supported versions. V.28 Identify the application programming language and other tools used to build and maintain the Application. Identify all versions. V.29 Describe the use, or lack thereof, of "user exits" strategically located in code that enable local programmers, for example, to make data or process calls to or from external resources. For example, this methodology may be used to read external data files for data validation. Include the programming language that the "user exits" may be written in and how they are compiled. V.30 Does application licensing allow source code to be made available to Clark County? Clark County will require that the source code, if not made available, be placed in an "Escrow Account" and contractually the County shall have access thereto should the Vendor become bankrupt, cease to exist for any reason, and/or be purchased by or merged with another vendor. V.31 Does the application and database management system environment allow external applications to either read or write to the database? Please describe capabilities and limitations. SECURITY - APPLICATION & DATABASE V.32 Describe how security is administered -- for the Application, for the database. V.33 Describe how the application security is managed. Include a description to the level of detail that's available: for example by location, workgroup, department, person, or menu level. 30 ITEM# REQUIREMENT V.34 Describe the layers or groupings of security levels. Clark County currently maintains four levels in one of our host systems. V.35 Describe how many levels of security are available in the application? The database? V.36 Describe how authorized person(s) would create, modify, and delete permission for individual persons to use the Application. V.37 Is the security between the application and the database administered independently? Concern: Within the application, an individual is assigned different responsibilities (securities). Will the database administrator be required to also update the securities to match those responsibilities? V.38 Fully describe the Application's password security management. V.39 Does the Application automatically log -out a cashier if a period of inactivity occurs? If yes, is there a set up feature that allows Clark County to control the length of inactivity or an automatic log -out time? V.40 Does the Application's security limit the Cashier to only "see" their own activities? V.41 Describe whether or not any of the data may be stored encrypted? Can the Administrator define specific fields to be encrypted? If yes, please provide documentation as to how this is performed? V.42 If Clark County desires, describe the ability, or lack of, to enable the Application to use the Clark County network login as the application login. BAR CODING, OCR, AND WIRELESS CAPABILITIES V.43 Describe the application's support for reading and processing bar codes on a statement or payment stub. V.44 Describe the application's support for reading and processing OCR scan lines on a statement or payment stub. V.45 Describe supported hardware for barcode and OCR equipment. V.46 Describe the Application's current abilities and any future expansion plans for wireless support. V.47 Describe the Application's ability to read MICR lines on checks for verification purposes. 31 ITEM# REQUIREMENT PERIPHERAL DEVICES V.48 List and identify technical specifications for all supported cash drawers. V.49 Describe the Application's ability to utilize touch screen monitors. V.50 Describe the Application's support for card -reading devices. V.51 List and identify all supported printing devices. Identify recommended printers. Identify printing devices capable of integrating receipt and charge slip. V.52 Describe hardware requirements for all card swiping such as for credit cards, debit cards, and debit cards with PIN number. DOCUMENTATION V.53 Provide an electronic version of user and technical documentation for the proposed application. If an electronic version is not possible, provide a paper -based version. Documentation types include but are not limited to: technical system documentation for program flow and data design, installation planning, technical software specifications, and end -user material such as training materials and user manuals, including documentation of on-line help materials. V.54 Will Clark County be allowed unlimited reproduction of all documentation for internal distribution only? If not, then what documentation will be allowed? DATA RETENTION V.55 Describe Application's ability to define data purge processing according to Clark County record retention requirements of six years [Disposition authority numbers GS50-03A-07 and GS50-03A-211. V.56 Describe your Application's typical data retention and archival process that you commonly recommend. V.57 Describe forms of media the application archival function is designed to use. What are the preferred forms based upon your experience? TOTAL POINTS POSSIBLE — 25 32 Request for Proposal # 365 Point of Sale Receiptinq System Part VI INTERFACES & INTEGRATION FEATURES 25 Points Possible Please provide a narrative response to each feature in the expandable line following each item. If references are made to external documents or examples, please provide a clear reference to that source. This section is to determine how each proposed Point of Sale application is able to support the following features. ITEM# REQUIREMENT INTERFACES AND INTEGRATION VI.1 Describe how you would interface to the Oracle Accounts Receivable API (Oracle 11 i or greater). VI.2 Describe how you would interface with the Tidemark Advantage Permit plan system? We are currently running version 2.61 and will be moving to 3.3. VI.3 Have you interfaced with a Cris+Plus (by Eagle Computer Systems) before? Please describe if you have had any links to products from Eagle Computer Systems. VI.4 Describe how you would interface to an in-house system. Have you interfaced with an Image (HP MPE) database before? VI.5 Describe how the Application will create an EIP (Exception Item Process) file from transactions collected at the front counter. This file will integrate with remittance system for encoding and endorsing of checks and also to prevent the duplication of transactions receipted (via two different payment methods). VI.6 Describe how the Application shall be able to inquire to multiple -host systems from a single inquiry? Our current applications do not have a single constant unique identifier. VI.7 Describe data export/import function capabilities and how they are invoked. Cite specific methods supported by the application, such as FTP, specific API's, and supported formats like ASCII, fixed length, CSV, etc. VI.8 Please discuss whether or not the proposed product ships with API's that will allow the product to directly update other databases as a result of receipt transactions. VI.9 Describe the Application's ability to receive transaction detail from other Applications. This may be, for example, from a web site or an interactive voice response system. VI.10 Currently, we have two (2) different IVRS applications which we want to integrate with electronic payment capabilities. Please describe the architecture needed to communicate from IVR to the POS. Concerns are with delays between the source system updates and POS queries source system. 33 ITEM# RE U4 IREMENT VI.11 Describe the Application's ability to receive transaction detail from other Applications in a batch mode, i.e. FTP, spreadsheet, word document, etc. VI.12 Include a scope -of -work in the proposal defining all installation responsibilities and the parties responsible for each task. VI.13 Include a comprehensive project timeline that depicts all major milestones and a detailed schedule of tasks to be completed and by whom. VI.14 Describe the Application's ability to have calculations shown on -screen utilizing data from the host application and the business rules for that application. This shall include the ability to change the date for the calculation. VI.15 Describe the Application's ability to automatically create groups of transaction detail according to an external Application specification. This may include sending a detail file and a summary file for the same group/type of activity to different locations/systems in a specified format. VI.16 Describe the Application's ability to transmit groups of transaction detail to predefined locations across the County where the locations may be folders on a remote server, an FTP site, or to a database supporting an external application. VI.17 Describe the Application's ability to transmit groups of transactions according to a schedule. The schedule will vary according to external Application requirements. VI.18 Describe the Application's ability to pass data to a host system OR to pass data to the host AND the accounting activity to the General Ledger, given that the General Ledger is not the host system. VI.19 Describe automated scheduling services in the context of executing jobs to export and transfer data to another destination, in the context of executing jobs to retrieve and import data to the proposed application database from another location. Also describe the error -checking and correction capabilities. VL20 Describe if the Application can 'reload' previously loaded data to the Host system. This would be in case of a hardware failure and the 'backup' was unsuccessful, resulting in the reloading of original data. VI.2 1 Describe how you would interface to Oracle Accounts Payable API for refund ability. TOTAL POINTS POSSIBLE — 25 34 Request for Proposal # 365 Point of Sale Receiptinq System Part VII SUPPORT & TRAINING FEATURES 15 Points Possible Please provide a narrative response to each feature in the expandable line following each item. If references are made to external documents or examples, please provide a clear reference to that source. ITEM# REQUIREMENT SUPPORT & TRAINING VIL 1 Describe the support for all software and peripheral equipment proposed under this RFP. VIL2 Describe the options and pricing for maintenance and support after the initial warranty/support period. VIL3 If there is a support hot-line available to Clark County, please explain the procedures for providing additional assistance if a software failure is not resolved in a timely manner. VIL4 Describe if there are any User Groups available, on the web, conferences, or other means dedicated for your product? If so, how can Clark County become involved? VII.5 Describe the training users and administrators receive that is provided as part of the `package' purchased. What materials are typically provided? Will this be held at a Clark County location? If not, how are travel, hotel/motel accommodations, etc., handled? VII.6 Describe your approach to on -going training. If Clark County desires to have on -site training, how would that be accomplished? VII.7 Clark County desires that a vendor representative be present for a period of time immediately after implementation to help solve any issues (technical and/or process) when going live. Explain how this is handled. VIL8 Describe reports generated by vendor which define support issues for each month and that will include open -ticket items with dates, time -of -call, and resolution. VII.9 Describe the training that is provided for the system/application administrators for hardware set-up, installation, application maintenance, database maintenance, etc. VII.10 Describe your Help Desk support and hours of operations. TOTAL POINTS POSSIBLE —15 35 Request for Proposal # 365 Point of Sale ReceiptinQ System Part VIII CREDIT CARD FEATURES 10 Points Possible Please provide a narrative response to each feature in the expandable line following each item. If references are made to external documents or examples, please provide a clear reference to that source. This section is to determine how each proposed Point of Sale application is able to support the following features. ITEM# CREDIT REQUIREMENT CARDS VIII.1 List who you have partnered with (if any) to provide the client with Credit/Debit and E- Check capabilities. VIII.2 Who are you certified with for processing transactions? VIIL3 Describe the Application's process for communicating to a third party provider for credit card authorization. VIII.4 Describe the authorizing service for a credit card vs. a debit card vs. electronic check. VIII.5 Describe the way/method the credit card numbers are processed. Describe the security that is applied to ensure the safety of the transactions. Are the numbers stored? Clark County does not want the liability of storing credit card numbers or the bank account/routing and transit numbers for any electronic payment items. VIII.6 Describe how the proposed product will interface with those services for credit card and electronic check processing. Specifically, describe how the proposed product may receive credit card and/or e-check transactions directly from the institutional service provider. Is there a report to verify and match the transactions sent to be paid vs. the transactions that are actually paid? VIII.7 Describe the product's mechanism to accumulate credit card activity by merchant location and provide information to facilitate the distribution of discounts associated with credit card utilization. VIII.8 In the event of a dispute over authorization for payment, what is the process for resolving the dispute? VIII.9 Describe Debit card processing with PIN authentication. VIII.10 Does the Application have the ability to restrict cash back on a debit transaction? VIII.11 Describe the Application's ability to integrate customer signature line into the receipt printing process? 36 ITEM# REQUIREMENT VIIL 12 Describe credit card reader capabilities and if they are an integrated device or an external one. VIII.13 Is your Application capable of providing reconciliation reports between the data (batches) sent to the credit/debit card processor(s), including e-check routing and transit data, and the monies received by our bank for those batches? If Yes, please describe. If No, how could your application be utilized to provide this reconciliation? If neither, how is this accommodated? VIIL 14 Describe how your system would behave or respond if the credit/debitle-check verification is down or if the communication to it is lost. VIIL 15 Describe the process when a credit card payment is reversed. How will the host applications be updated? How is this matched to the original payment? IE: If a product was purchased (a map) and subsequently returned. VIIl.16 Describe the process if the owner of the credit card calls their bank to cancel the payment. IE: Unauthorized card usage reported by card holder. VIII.17 Is it possible to have a transaction processed, yet an authorization was not obtained. If yes, what is the process to correct this error? TOTAL POINTS POSSIBLE —10 37 Request for Proposal # 365 Point of Sale Recelptinq System Part IX INVESTMENT SCHEDULE Costs should be based upon a minimum user base of 55 workstations. Vendor licensing provisions should be identified to demonstrate how pricing will be determined as the user base and/or the transaction volume is increased. Some items like travel are understood to be an estimate at the time of this proposal, and will be charged at actual costs when incurred. All vendors shall complete the following table to form a complete and accurate investment basis. The first table covers the costs in the first year, while the second table covers the recurring costs. Please list which items you expect Clark County to provide. Alternative structures are acceptable and will be considered provided they are deemed reasonable and doable. Each structure is to be priced separately. Cost Category Clark County Provide Purchase Price (Each) Qty Extended Cost Annual Maintenance (If any) Application software/license Specialized Peripherals: (Priced as each) Receipt Printer Keyboard Card Reader Electronic Cash Drawer Touch Screen Monitor _ Check Reader ❑ Check Imager/Micr Reader Barcode Scanner E OCR Reader ❑ Credit Card Hardware ❑ Additional Hardware: If required, please specify ❑ Training: List any optional packages ❑ Implementation/Installation: ■ Conversion Support: ❑ Interfaces: ORACLE A/R ❑ CATS CRIS + 38 TIDEMARK 2 Maintenance & Support: -See below for yearly summary -List available plans Travel & Accommodations: Documentation: Shipping Tax (Washington 7.7%) Total Investment First Year SOFTWARE MAINTENANCE AND OTHER RECURRING COSTS Year 1 Year 2 Year 3 Year 4 Year 5 Total Software Annual Maintenance Costs List And Describe Any Other Recurring Cost Below Total of All Recurring Costs Year 1 Year 2 Year 3 Year 4 Year 5 Total TOTAL OF ALL COSTS 39 Request for Proposal # 365 Point of Sale Receiptinq System APPENDIX A: Statistical information for sizing our application. The table below contains statistical information that should be useful in responding to the RFP. Anticipated Transaction Count for the Future Source Annual Receipt Count Remittance Processor* 250,000 CATS (over-the-counter) 50,000 AVRS (Automated Voice Recognition System) 0 Web** 10,000 Mortgage Company Files 120,000 Oracle (over-the-counter) 15,000 Cris+Plus (over-the-counter) 175,000 Tidemark (over-the-counter) 12,000 Total Anticipated Count 632,000 * This includes both CATS & Oracle transactions ** Currently we do not have transactions processed via the web, This is an ESTIMATE. Cashiers (Joint Lobby, GIS, Tidemark) 31 Workstations: Currently - 55 Front Counter 18 Back room receipting stations 12 Inquiry stations 25 Workstations: Potential Growth - 75 (including current) as other departments may be added, Front Counter 30 Back room receipting stations 15 Inquiry stations 30 Expected time to complete a single simple transaction from start to finish (operation time) <30 seconds Expected data inquiry from host applications (single host inquiry) 1 second (normal) 2 seconds (under load) Printing a receipt (from the time the button is clicked) <10 seconds 40 Request for Proposal # 365 Point of Sale Receiptinq System APPENDIX B1: Proposed Point of Sale Overview. Electronic Authorize Process Payment Types Accepted: Cash, Check, Warrant, Money Order, Credit / Debit cards, E-Check (ACH Debit), Electronic Payment reconciliation Web, IVR Electronic Payments 'Transaction Data back to the POS Cashier 1 Receipting Cashier 2 Receipting Point of Sale Cashier 3 Receipting Tidemark Cashier deposits HOST Systems 1 Cashier 1 Deposit ----I Dollars *3� Balancing Reports by Cashier Cashier 2 Deposit Cashier 3 Deposit CRIS+ Tidemark Cashier tImported ;Bank File i Other Postings ORACLE AR t J TIDEMARK After Cashiers are Balanced I Then, POS creates a receipt for all NON -Oracle systems — by cashier Oracle Cash Mgmt Bank Statement Each deposit is auto -reconciled to the receipt created by the POS for each cashier. 4 Oracle AR Request for Proposal # 365 Point of Sale Recelptlna System APPENDIX BI: Current Process of CATS Receipting with Proposed Initiate a Refund. YE Return by mail customer 1. •" Tax Types 'blank' = Personal 11 = Real 33 = 55 = Drainage 66 = Drainage 77 = County Road 66 = Fire 99 = Clean Water Program (CWP) YE YE Tax/Assessment Screen Key Items: Account Tax Type**, and Interest Ente Pending FIa87 NO Select item(s) for Enter payment Payment Type, and Paid Ente More accounts to Print (which aseIQne the Receipt tf) Note: Different receipt We are assigned, by cashier end by type of Item recelpted. Customer * Payment Types Cash = Checks ='nothing' Warrant = W ***Within CATS, there are multiple daRTiSedalabase contains Real and Personal tax LID database contains tax types for 33, 55, 66, 77, Se Excis Process 4— YE TR Receipt Key Payment Amount, Type*, and Ente Print (which aaaigna the TR #) 1 P 000- t* nab ,i pl* New Window: Initiate Refund (amount carried Key Fields: (user entered) Account#, Loan #, Mailing Address, System Creates file at end of File Is Imported into Cashier Print cover Send to Finance creates refund batch, import to Oracle, checks Return Checks to Tex Office Create mail merge Mails letter & 42 Request for Proposal # 365 Point of Sale Rece ptinq System APPENDIX B2: Current process of Oracle Receipting. INVOICE: Key fields: Receipt Type + "Cash" Receipt #, Amount, Payment Method, and Trans Number or Customer Number or Customer Name. Note: Receipt # begins with the cashier number if It is a cash payment, or X" & check number if it is a check or warrant. Then Applications Button: - to select which Invoice to pay or place "On Account". MISC: Key fields: Receipt Type v "Mac" Receipt #, Amount, Payment Method, and Activity Note: Receipt # begins with the cashier number if It is a cash payment or X" & check number if It is a check or warrant. • After selecting the Activity code, click the "Distributions" button and verify/modify the account number(s) and amount for each. Receipt is printed out 43 Request for Proposal # 365 Point of Sale Receipting System APPENDIX B3: Current process of CRIS+ Plus receipting. There are various steps Involved in Crls+, like Scanning Documents, Indexing, Verlfing, Workflow, and various reports. Basic difference between batch & Individual la the # of documents & # of checks. IE: Batch: a title company with 20 documents & 20 checks which Is scanned later In the Back -Office'. Individual: with 1 document, 1 check and is scanned white they wait. Receipt Fees: Step 1 Enter the Doc Type to begin: IE: DT -- brings up a listing of Items that belong with this document type. — Option for: # of Documents IE: 6 documents of same type & page count. — a temporary receipt number is assigned Step 2 Step 3 t Calculate Fees: Enter the Unite {typically Pages/Titles, etc} -- this will be used to compute the fee. — optional over -ride fields may be available IE: 'Emergency-NonStandard' "' Proceed "' (back to 1st screen) Notes: Difference between buttons 'Print' & 'Insert 1) "Prinr" • Receipt #, Document #ts), Endorsing, end Labels. 2) "Insert" • Receipt #, Document rile) Labels contain: the Bar -Code, Record #, Page x of xx, Date, Time, Recorded by xxxxxxxxxx, Type Code, Amount, Clark County, WA YES NO Proceeed to 'Paid by' RECEIPT FEE NOTES: When MULTI is selected: new screen pope up for cashier to select all the documents to be recorded. Enter each Doc code. "' Proceed •" continues to the Calculate Fees screen In step 2 Select Payment Type (Check, Caeh, On Account, or No Fee Code), Payment Amount, Check Number/Remarks, Pail by Multiple checks? Yes - Next Payment �o Click on 'Proceed' (back to Receipt Fees Screen) NO 'Finish by clicking 'Print' I 1 Payment Notes: 1) do thle for as many payment (checks • default) as necessary until the total paid equals the total due. 2) There ere selected customers where they have an "account" for billing purposes Instead of paying at the time of recording. YES —► System assigns a Receipt Number & Document #'s, the system prompts for "Endorsing" the Check, than prints the receipt, then begins printing labels. Organize paperwork for "backroom` labeling and scanning System is ready for another transaction. Enter the Refund Code and the amount of the refund (overpayment) Organize paperwork for Refund approval process. use Quicken to write refund check. 44 Request for Proposal # 365 Point of Sale Recelpting System APPENDIX B5: Current Process of the Remittance Processor. Mailed -In payments E-mall to Finance: batches processed for the day. Cashier's Checks for encode & endorse only. Remittance 4_ Processor TR Created to 8758 for CATS$ (creates offset to CATS entry) File for CATS File for Oracle 1 Checks go to the banks In CATS: (menu button) Loan Tape Entry Update (prompt to add Interest date.) View batches: 0001 = RP batches * Select yesterday batch date (status = opened) ' Proof • Select the batch, fix errors. 4 Off -Line (Print proof batch) YES NO Select batch (status = Proofed} Extract: (RCL batch to RC) Select date to extract and select batch i Verify Status of batch i End of Day: Finance prints the final Journal. Journal Is filed, finish writing up TR with receipt # from final Journal. Data Management: Verification of TR Banks Accounting Is notified (via E-mail with an Excel attachment) that a file is ready. 4 In Oracle, do transfer (Interface, Lockbox) • Open the receipt batch for the newly created receipts from the remittance processor. YES NO in receipt batch(s), Post Quick Cash i Oracle report: Post Quick Cash Execution report. Convert to text file. Archive the text file. Notify users (6) vla E-mail that the RP batch has been posted. Attach the Text file. Review any Unapplied/On Account Items from this receipt batch. Forward to AR Manager to apply to accounts properly. Review reJected Items: In Oracle: Lockbox, Maintain data L Typlcial problem: 1 payment form many Items. Must manually create unique recelpts for each item to be applied to. Run Oracle Process: Transfer & Submit validation for the original batch, BUT only for rejected Items. New receipt batch is created. Definitions: CATS = County Assessor Treasurer System, RC = Receipt Control (a table in CATS), RCL = Receipt Control Loader (a table in CATS), RP = Remittance Processor, TR = Treasurer Receipt 45 Request for Proposal # 365 Point of Sale Receiptingl System APPENDIX B6: Current Process for Mortgage/Loan Servicing. Mortgage and/or Loan Compan Mail Check(s) documentation parcels being Photocopy the Check(s) documentation Is Receipt check (via into Suspense 4, Check(s) deposited the Enter Loan data into Loan Detabas • Print TR or Original Check File ) •..... tot ...s. t Enter details IfYU/fl/hd Is it 4totka t4 itll lfcatc, c mcctt,an Print Refund TR send to Finance enters TR Into CATS. Next Day - Distribution run and revenues posted to the Create Oracle Batch & print Review & Errors In Sends file to Countys'FTP • CATS process Is run to "Import" these • Unposted batch created in Loan ir Specialist the ,YE Return checks to Processing Specialist Create mall merge letter for Balance Suspense i Malt check & NO 1 Post (CATS) Extract Process to post to Accounts (parcels) distribute revenue to General Ledger (GL). • Excel File is for archive and record of transaction 46 RFP# RFP TITLE: POINT OF SALE RECEIPTING SYSTEM APPENDIX B7: Proposed Web site process. Web Clark County Web Property tax Firewal Make Payment (checkout) ** Next Web page with data to carry 1) Property 2) Totals available to pay (by User selects year(s) to ** Next Web Inquiry & payment complete web page for Point Of Inquire & return follow the rules for Host Electronic proces Transactions follow Mist rules for posting GL Host CATS, Tidemark, Verlflcatlo Proses Host CATS, ► Tidemark, *** Daily Balancing The web is treated like a Fiscal cashier for balancing. should be like the remittance To be determined * Will POS make Mac A1R entr es for the web batch that be deposited, by merchant #, to our bank? To be cleared Oracle Cash * Will Oracle Cash Management create entries to record deposit, by merchant #, at the bank? Oracle Cash Management will clear the transaction. 47 Request for Proposal # 365 Point of Sale Receiptinq System APPENDIX B8: Cashier Balancing, Depositing, and Oracle Cash Management. Current Process Print CATS Journal & balance across the bottom of the report. Open an Oracle batch (new or existing). For each tender type summarized (rash, checks, warrants), enter a receipt into Oracle. (See Additional Effort Oracle receipts, all cashiers folder, as a text tie_ Open Access database for Cashier balancing. Inhport Enter Check Amount Count the coins Count the currency search & for With the POS: Begin the balancing process Count the Cash Drawer using tools provided WHEN BALANCED Pr)D DSE"fi Additional Requhematas for the PDS regarding balancing: POS makes Oracle AIR receipt for the bank deposit day: by Cashier, by Tender Type for the various applications CATS Requirements: Create additional receipts into Oracle Alfa, in the cashier's batch. into'6900'. CRIS+ Requirements: Create additional lrxeiptt into Oracle A/R, in the cashiers batch, for the summarized accounting activity for the deposit date. Tidemark Requirements: Create a receipt into Oracle for the summarised accounting activity for the deposit date. Cash is prepared for Anmred Pick-up for the Bank deposit (with deposit sip) _olChecks Prepared for the remittance Processor (with deposit slip) _Warrants go to the vault Print Journals Journal to Finance $ Cash Drawer back into the Annoyed Journals & Documentation is tied_ Banks The next s Morning bank download for each bark the bank details are by: 'Cash by cashier and `Checks by RP (on us and all others) Oracle Cash Matching / Clearing process of receipts in Oracle. Includes both the auto -match & manual matching. Oracle well automatically create receipts of selected (predetermined) deposits. Oracle will auto -reconcile the bank statement for all items that match. Accountant will manually recorhde cash 'i transactions, by cashier. Accountant will manually reconcile all Check - transactions. The total checks should match the check total for all cashiers Accountant will manually clear ehdemal items. 48 Request for Proposal # 365 Point of Sale Receiptinq System APPENDIX B9: Current & Proposed Excise Tax Process. Current: Excise 1 Recording Today, this is two (2) distinct Cashier carefully reviews document for NO NO NO Assessor verifies. OK or FMS Invoice Pay anent Taxes, ownership & $2 Treasteees Receipt CATS : the on-line Enter the Pmpery Account #, Sale Amount Sales .... m Enter the amount **Compute** Off -dine - Stamp the Document and write on bottom document - Date. Cashier Initials. Amount, Who (On -Line) Enter the Excise A from L, Receipt Excise Money or 42 for exempt properly (create Copy of affidavit to: Treasurer. Assessor. and Dept Of Send customer bade in fine by Id ofe, icy the customer # to a 1 Follow the prooeduae for reconfirm a Receipting: 1) Doc to Add, 2) # of 'Proceed' 'Paid by screen - Payment Type. Amount. Check #, Paid 'Proceed^ Print receipt Endorse Check, Prim Allis Labets to document, Scan Documents, Verify count of Pages Return documents to Done with Later In the Back Office' - Index & P►oposed Igecording Cashier carefully reviews the document for NEW Seled the Excise From the on -fine Enter the Property Account #, Sale Amount. Sales (system should verify land use, mobile Excise # is Write dawn the E>:the #, Date, Cashier Initials, Amount. Who the bottom of the SAVE ;Mang with other dada elements relating to the property to aid in dStrihdtm process Would they rice to record the Document YES Follow the procedure for recording a Receipting: Doc to Add and # of 'Proceed' 'Paid by screen - Payment Type. Amount Check #, Paid 'Proceed' Print receipt, Endorse — Somehow - The Skis+ system must 'know' that the payment been made Print Affix labels to document, Scan Documents, Verify count scanned Rerun documents to (Later in the Banc Office' - Index & Proceed to the payment process in the Proceed 14 Payment in the Follow the ► ProCesS in the of Request for Proposal # 365 Point of Sale Receiptina System APPENDIX B10: Current processes for Community Development (Tidemark) Planning Permit Application (3), Building Permit Application (3), Fire Permits (4), and Building Permit Payment Options (5). Planning Permit Application Applicant/CD Specialist Paperwork Paperwork Planning Permit Application (Payments) - CASH CPayment Screen Select "Method" Cashier Less Than Amount Due rester Than Amount Due Cashier Case Number List of Changes Payment Screen To CD Specialist Planning Receipts Folder Applicant To Administration Cashier End-of- ShtJi PRO - 50