UNEMPLOYMENT INSURANCE PROJECT SYSTEM …



Table of Contents TOC \o "1-3" \h \z \u 1.UNEMPLOYMENT INSURANCE PROJECT SYSTEM REQUIREMENTS PAGEREF _Toc505343961 \h 4System Project Management Requirements (Table A) PAGEREF _Toc505343962 \h 4Unemployment Tax Business Requirements (Table B) PAGEREF _Toc505343963 \h 4Unemployment Benefit Business Requirements (Table C) PAGEREF _Toc505343964 \h 4Common Functional Requirements (Table D) PAGEREF _Toc505343965 \h 4Trade Case Management Functional Requirements – Optional (Table E) PAGEREF _Toc505343966 \h 4Work Opportunity Tax Credit (WOTC) Requirements – Optional (Table F) PAGEREF _Toc505343967 \h 42.Hardware and Software PAGEREF _Toc505343968 \h 53. Site Transition PAGEREF _Toc505343969 \h 53.1 State-Owned Data PAGEREF _Toc505343970 \h 53.2 State Owned Capabilities PAGEREF _Toc505343971 \h 53.4 Constraints PAGEREF _Toc505343972 \h 63.5 Automated Conversion Methods: PAGEREF _Toc505343973 \h 63.6 Manual Conversion Methods: PAGEREF _Toc505343974 \h 73.7 Conversion Prerequisites: PAGEREF _Toc505343975 \h 73.8 Conversion Procedures: PAGEREF _Toc505343976 \h 73.9 Resource Requirements: PAGEREF _Toc505343977 \h 83.9.1 Conversion Responsibilities: PAGEREF _Toc505343978 \h 83.9.2 State Conversion Responsibilities: PAGEREF _Toc505343979 \h 84Exit Strategy PAGEREF _Toc505343980 \h 85Future Enhancements PAGEREF _Toc505343981 \h 96Cost Proposal PAGEREF _Toc505343982 \h 9General Provisions PAGEREF _Toc505343983 \h 9Cost Proposal Requirements PAGEREF _Toc505343984 \h 9Subscription Pricing PAGEREF _Toc505343985 \h 9Software and Hardware Costs PAGEREF _Toc505343986 \h 9ODJFS Project Operational and Administration Support PAGEREF _Toc505343987 \h 10Total Cost of Project PAGEREF _Toc505343988 \h 107. Table A: System Project Management Requirements PAGEREF _Toc505343989 \h 118. Table B: Unemployment Tax Business Requirements PAGEREF _Toc505343990 \h 18B.1 Employer Registration PAGEREF _Toc505343991 \h 18B.2 Rate Determination PAGEREF _Toc505343992 \h 22B.3 Quarterly Reporting PAGEREF _Toc505343993 \h 26B.4 Employer Maintenance - Staff Options PAGEREF _Toc505343994 \h 32B.5 Employer Maintenance - Reimbursing PAGEREF _Toc505343995 \h 39B.6 Employer Self-Service PAGEREF _Toc505343996 \h 42B.7 Fiscal Management PAGEREF _Toc505343997 \h 45B.8 Proof of Claim - Bankruptcy PAGEREF _Toc505343998 \h 46B.9 Employer Compliance - Field Audit PAGEREF _Toc505343999 \h 48B.10Tax Appeals PAGEREF _Toc505344000 \h 519. Table C: Unemployment Benefit Business Requirements PAGEREF _Toc505344001 \h 54C.1 Initial Claims PAGEREF _Toc505344002 \h 54C.2 Monetary PAGEREF _Toc505344003 \h 59C.3 Employer Charging PAGEREF _Toc505344004 \h 62C.4 Benefits Processing PAGEREF _Toc505344005 \h 66C.5 Non-Monetary Appeals PAGEREF _Toc505344006 \h 70C.6 Overpayment/Repayment PAGEREF _Toc505344007 \h 74C.7 Miscellaneous PAGEREF _Toc505344008 \h 76C.8 Accounting PAGEREF _Toc505344009 \h 80C.9 Self Service PAGEREF _Toc505344010 \h 82C.10Quality Assurance PAGEREF _Toc505344011 \h 86C.11 Interface Interoperability PAGEREF _Toc505344012 \h 87C.12Federal Reports PAGEREF _Toc505344013 \h 90C.13Special Program PAGEREF _Toc505344014 \h 9110.Table D: Common Functional Requirements PAGEREF _Toc505344022 \h 95D.1 Labor Market Information Support PAGEREF _Toc505344023 \h 95D.2 Data Validation Support PAGEREF _Toc505344024 \h 95D.3 Review Commission Appeals PAGEREF _Toc505344025 \h 96D.3.1 Lower Authority Appeals PAGEREF _Toc505344026 \h 96D.3.2 Higher Authority Appeals PAGEREF _Toc505344027 \h 101D.3.3 Multi Claimant Appeals PAGEREF _Toc505344028 \h 101D.3.4 Tax Appeals PAGEREF _Toc505344029 \h 102D.3.5 Hearing Officer Calendar PAGEREF _Toc505344030 \h 102D.4 Client / Workstation PAGEREF _Toc505344031 \h 103D.5 Documentation and Standards PAGEREF _Toc505344032 \h 103D.6 Conversion PAGEREF _Toc505344033 \h 104D.7 Security and Recovery PAGEREF _Toc505344034 \h 104D.8 Identity Management PAGEREF _Toc505344035 \h 107D.9 System Performance and Capacity PAGEREF _Toc505344036 \h 107D.10Hosting PAGEREF _Toc505344037 \h 109D.11Single Sign-on PAGEREF _Toc505344038 \h 109D.12Correspondence PAGEREF _Toc505344039 \h 110D.13Work Flow PAGEREF _Toc505344040 \h 112D.14Internal Reports PAGEREF _Toc505344041 \h 113D.15Help Search PAGEREF _Toc505344042 \h 115D.16Security User Interface PAGEREF _Toc505344043 \h 116D.17General PAGEREF _Toc505344044 \h 11711. Table E: Trade Case Management Functional Requirements - Optional PAGEREF _Toc505344045 \h 119E.1 Trade Case Management PAGEREF _Toc505344046 \h 11912. Table F: Work Opportunity Tax Credit (WOTC) Requirements - Optional PAGEREF _Toc505344047 \h 121F.1 Work Opportunity Tax Credit (WOTC) PAGEREF _Toc505344048 \h 12113. Service Level Agreements - Operations PAGEREF _Toc505344049 \h 12313.1 Parties and Timeline PAGEREF _Toc505344050 \h 12313.2 Service Catalogue PAGEREF _Toc505344051 \h 12313.3 Deductions PAGEREF _Toc505344052 \h 12313.4 Reporting PAGEREF _Toc505344053 \h 12313.4.1 Weekly Status Report PAGEREF _Toc505344054 \h 12313.4.2 Monthly Review Meeting PAGEREF _Toc505344055 \h 12413.4.3 Quarterly Review Meeting PAGEREF _Toc505344056 \h 12413.4.4 Reporting Service Levels PAGEREF _Toc505344057 \h 12413.5 User Support and Problem Correction PAGEREF _Toc505344058 \h 12413.5.1 Prioritization Approach PAGEREF _Toc505344059 \h 12513.5.2 Application Function Type PAGEREF _Toc505344060 \h 12513.5.3 Response and Resolution Times PAGEREF _Toc505344061 \h 12613.5.4 Response and Resolution Service Levels PAGEREF _Toc505344062 \h 12613.5.5 Application Availability PAGEREF _Toc505344063 \h 12613.5.6 Application Availability Service Levels PAGEREF _Toc505344064 \h 12713.5.7 Application Responsiveness Service Levels PAGEREF _Toc505344065 \h 127Supplement One – Unemployment Insurance System Transformation (UIST) system requirements UNEMPLOYMENT INSURANCE PROJECT SYSTEM REQUIREMENTSThe requirements for the Ohio UI Benefits and Tax System are found in the attached tables. The State has worked to keep the requirements at as high a level as possible to take full advantage of an existing operational core system. Each requirements table has sections that consist of critical and desirable requirements. All requirements will be evaluated and rolled up into the score given for the particular section of the requirements table. Confirmation of availability of the desirable requirements will also be factored into the score for the section. Tables E and F contain requirements for optional modules. ODJFS has provided entries on the cost proposal form for separate cost quotes for these modules.System Project Management Requirements (Table A)Offerors must describe how they will implement A UIST Project solution in response to the Project Management Requirements. These requirements are found in Table A: System Project Management Requirements to this RFP. Offerors must respond to all requirements.Unemployment Tax Business Requirements (Table B)The Business Requirements describe the operation of the UI Tax program from a business perspective. These requirements are found in Table B: Unemployment Tax Business Requirements to this RFP. ORC is defined as the Ohio Revised Code Chapter 4141 Unemployment Compensation and OAC is defined as the Ohio Administrative Code 4141 Department of Job and Family Services. Offerors must respond to all requirements.Unemployment Benefit Business Requirements (Table C)The Business Requirements describe the operation of the UI Benefits program from a business perspective. These requirements are found in Table C: Unemployment Benefit Business Requirements to this RFP. Offerors must respond to all mon Functional Requirements (Table D)The Common Requirements describe the capacity, performance, security, interfaces and processes of the UI Benefit/Tax Project. These requirements are found in Table D: Common Functional Requirements to this RFP. Offerors must respond to all requirements.Trade Case Management Functional Requirements – Optional (Table E)The Trade Case Management Requirements describe the automation that we hope to apply in administering this program. These requirements are found in Table E: Trade Case Management Requirements to this RFP. If functionality is offered, offerors must respond to all requirements. This is not critical functionality, ODJFS will review proposals to decide whether to move from our current implementation to the proposed solution.Work Opportunity Tax Credit (WOTC) Requirements – Optional (Table F)The WOTC Functional Requirements describe the automation that we hope to apply in administering this program. These requirements are found in Table F: WOTC Functional Requirements to this RFP. If functionality is offered, offerors must respond to all requirements. This is not critical, ODJFS will review proposals to decide whether to move from our current implementation to the proposed solution.Hardware and SoftwareOfferors will identify any hardware and software that ODJFS will need to procure to use and support the system. Offerors must identify hardware and software components that are included as part of the RFP and those that must be purchased separately in order to fulfill ODJFS roles on the system. Include specifications for the hardware and software (models, versions, releases, etc.). ODJFS may, in its sole discretion, choose to purchase the equipment from the Contractor or from another State contract. Note: Pricing for hardware and software are to be included in the Cost Proposal (which includes the Cost Table and Components tabs).3. Site Transition As the new system promotes online, we will need data and capability conversion support in transitioning the existing Ohio data and capabilities to the new solution provider. Prior to the conclusion of the Contract, the Contractor agrees to:3.1 State-Owned DataThe Contractor must identify and document to the State all State-owned data in the system inclusive of volumes, record layouts, database objects and historical record counts. The Contractor must work with the State, and the aforementioned State-owned data, to establish a data handoff procedure inclusive of all State identified data that the State requires prior to the conclusion of the Contract. As part of this handoff procedure, the Contractor must work with the State to establish data conversion and formatting standards (e.g., file formats, record layouts or XML based structured files) as well as data extraction/conversion control reporting to ensure that all State data is extracted and provided as per the State’s requirements. The Contractor must execute required data conversions or extractions including, but not limited to all State data and ancillary supporting data as required by the system to be readable by the State and serve as the basis for State onward use of the data. This will be executed once with a subset of the data to test and confirm the process and then again quarterly to get latest data delivered to support the transition.The State of Ohio data must be removed from all Contractor systems (and their subcontracted systems) and repositories once the site transition has been successful, unless the State of Ohio has granted explicit permission for the Contractor to retain specific data.The Contractor must:Convert electronic data into a format, approved by the State, to be used by the State using a data conversion program;Perform required data matching activities and error reporting;Document data issues and provide to the State for resolution; andCoordinate and confirm the State approval of data conversion results.The Contractor must transfer all State-owned data to the State on a quarterly interval until the site transition is complete.3.2 State Owned CapabilitiesThe Contractor must identify and document to the State all State-owned capabilities in the proposed system; this includes work done by the Contractor as well as their subcontractors in support of the State of Ohio. The Contractor working with the State, and the aforementioned State-owned capabilities, will establish a handoff procedure approved by the State. As part of this handoff procedure, the Contractor will work with the State to establish the transfer of the intellectual property (IP) with all that is necessary to have it fully functional in the State’s environment. This handoff will include all environmental information and any proprietary tools needed to allow the State to be able to get the capabilities transferred and fully functional.The Contractor agrees to execute required IP handoff once at a mutually agreed upon point and then again after any final updates are made before the start of the transition; and support the State in getting the transferred functionality up and operational on State facilities.The Contractor must coordinate and confirm the State approval of handoff results.3.3 Site ConversionThe Contractor needs to provide a complete site conversion plan within 3 months of award of the contract. The plan needs to address:the mapping of data from the existing system to the new solution;definition of any new defaults for required data in the new system;the strategy for converting the system – both data and software tools and capabilities;assessment of the need for any manual conversion and plan;backup and rollback strategy due to failed attempt;any outage time for the site while the conversion is in flight;resource requirements;roles and responsibilities;assumptions and constraints; andcapture any additional data required for the initial operation of new Office of UI Operations (OUIO) solution.3.4 ConstraintsAll logins will need to be reestablished on the new solution with the existing login and password;All logins will be driven to a password reset on first login to the new solution;The State of Ohio will provide a small set of data to support a “pilot” conversion onto the new system;All of the current accounts need to be moved in one block before the new site can go into service; andWe have negotiated no more than 4 data drops from the current provider to support this transition; any costs for additional re-transmission will be at the Contractor’s expense.3.5 Automated Conversion Methods: Whenever possible, automated methods will be used to consolidate, validate, and transfer in the approach to converting data:Conversion of External System data;Automated Client Data Consolidation Methods;Automated Data Validation and Editing Methods;Data that contains missing files;Data that contains missing field values;Data that did not pass automated editing routines;Data which requires some manual validation of the values assigned to certain fields;Conversion Clean-up documents will be generated by the system and will be distinguished from exception reports in that the documents themselves will be used to record new or missing data;Automated processes will screen for duplicate clients and cases during building of the Conversion Shadow Databases and the statewide new OUIO databases. Exceptions will be noted and reported for resolution;Other batch programs will be designed to modify data elements by defaults or calculations to assure that values stored in new OUIO databases are accurate; andSpecial on-line and utility programs will provide for the entry of data corrections into the Conversion Databases during the data validation process.3.6 Manual Conversion Methods: One of the primary objectives of this conversion will be to minimize and possibly eliminate the need for any manual data entry or data clean-up whenever it is determined feasible. However, automated conversion methods must be augmented by a series of manual conversion methods to ensure that the data consolidation, validation, and transfer are both comprehensive and valid and are completed in a controlled and organized manner.3.7 Conversion Prerequisites: There are a number of prerequisite conditions which must be met before the entire conversion effort can begin. These are referred to as "conversion prerequisites" as they represent critical dependencies for the start-up of the conversion. A delay or failure to deliver any of these essential elements which follow would require a change in the conversion strategy and schedule. The following conditions must exist before the statewide conversion can begin:The conversion programs must be completed, fully tested, and accepted by the State of Ohio so that conversion activities can lead directly into full production operation using the comprehensive system;All software capabilities and tools are transmitted to the Contractor and placed under source code control for their ongoing maintenance and enhancements;As soon as the transferred software is fully functional, the State staff will have access to an acceptance test area to confirm that it continues to meet the existing requirements. This will happen no later than 3 months before go-live. The transferred software is expected to be production ready at this point;The State staff will be trained in the process for input of that data which is critical to the new operation in order for the full scope of the conversion approach outlined in this plan to proceed as planned;The complete training environment required to support the new installation must be in place, including approved new training guides and materials, a fully equipped and linked central training facility, a group of qualified trainers, and the full commitment of State staff's time to the conversion;A complete system support network must be in place and operational prior to the start of conversion activities, including HELP Desk staff knowledgeable in how to resolve problems arising during conversion and on-going operation of the new solution, qualified operations staff who operate the system during implementation, and a stable processing and communications environment; andThe State will establish and staff a parallel OUIO Help Desk in time for that staff to be trained and available to support the conversion activities.3.8 Conversion Procedures: Data validation must be performed, by the Contractor, locally and corrections must made to the Conversion Shadow Databases through data entry. The contents of the Conversion Shadow Databases will not be migrated to the new OUIO statewide databases until it is confirmed that:All potential duplicates have been eliminated;All outstanding data edits have been researched and resolved; andAll outstanding data validation reports have been handled according to the State-approved conversion approach.3.9 Resource Requirements: 3.9.1 Conversion Responsibilities: The Contractor must be responsible for:The receiving and intake of the existing transferring software and support files to become a part of the supported base of the new site;The development and documentation of an approach to converting data from External System and Current System;The delivery of a detailed Work Plan that will cover the activities and deliverables. Also, it will include effort hours by staff for each activity;The preparation and delivery of Data Mapping documents which display the mapping of data in the old system to the New System;The delivery of conversion specifications for each program needed for conversion or data clean-up;The development (coding and unit testing) of the conversion programs;The function/system testing and delivery of the conversion software for New System;The executing of conversion programs at the proper time, and for cooperating with the State to ensure a smooth transition from Current System to New System statewide; andPlaying a supportive role throughout the conversion and statewide implementation period by jointly monitoring progress, anticipating problems, correcting faults, and facilitating resolutions along with State and the Contractor’s Quality Assurance Team.3.9.2 State Conversion Responsibilities: The State staff will be responsible for:Providing database layouts for the Current System databases and file layouts for both Current System files and External System Client File;Reviewing all delivered documentation from the Company ABC conversion team;Creation of any forms and the procedures required for the manual gathering of missing required data;Determining the defaults, the default calculations and algorithms to be used to populate New System required data that is not available in Current System;User Acceptance Testing (UAT) of the conversion migration and clean-up programs;Monitoring the Pilot test for any changes to previously defined procedures prior to statewide conversion activities;Determining the conversion schedule for the Customer local office after the completion of the Pilot phase; andPlaying a primary role throughout the conversion and statewide implementation period by monitoring progress, anticipating problems, correcting faults, and facilitating resolutions along with the support of Contractor Conversion.Exit StrategyWithin 6 months of the award of the Contract, the Contractor and ODJFS will document the exit strategy for a time when the system no longer is the correct solution for the State of Ohio. This exit strategy will outline the process, timeline intervals, and ongoing commitments for each side for agreements on termination.Future EnhancementsThe Offeror must describe the capabilities of the system to meet the desired future enhancements identified by ODJFS. Future enhancements plans will not be scored, however, will be reviewed by the evaluation team during offeror demonstrations. ODJFS is looking for a solution that is flexible and is able to meet future business needs.Cost ProposalThe Offeror is expected to conform to the following guidelines in addition to those provided in the RFP:General ProvisionsThe Contract resulting from this proposal will be a fixed-price, subscrption-based contract. There will be no payments to the Contractor made ahead of the system going into production. All costs are expected to be incorporated into the subscription rate.The preference is for the delivery of UI Tax capability followed by UI Tax/Benefits capability. If an exception to this is proposed, detailed justification must be included in the proposal. If the Offeror is offering vendor hosting as an interim step, then a implementation plan and timeline for the eventual cloud implementation of the final solution would be requested.Cost Proposal RequirementsCost Proposals will be executed on a five-year basis, to include all costs to ODJFS within those five years. The five year interval will begin with the go-live of the tax function on the new system.ODJFS requires the following of the Cost Proposal:All State costs are to be identified and included in the Cost Proposal;Work done on the Ohio customization must be included in the subscription fee;The Cost Proposal must be free from mathematical error (minor rounding errors are not considered mathematical errors);The Cost Proposal must include all costs; andThe Cost Proposal must be accompanied by a copy of the Work Plan(s).ODJFS is concerned about the total cost of UIST Project to the Department. This includes the price of deliverables and ODJFS costs of the project. To that end, Offerors must price the total cost of the project to the ODJFS, including:Subscription PricingThe Cost Proposal must be in US dollars and not include tax.This Cost Proposal must include what the base charges are, what assumptions the incremental charges will be based on and what would trigger changes in the incremental part of the subscription.Software and Hardware CostsThe Offeror must list all software and hardware provided in the Proposal and include it in the Cost Proposal calculations (all software and hardware).ODJFS Project Operational and Administration SupportProvide your estimate of the number of ODJFS staff hours by category (e.g., subject matter experts, test, technical support, project management), that contribute to the deliverables (ODJFS Hours). Offeror is not expected to provide dollar cost estimates for ODJFS staff hours.Total Cost of ProjectThe total cost of the Project is a summation of the above costs. Offerors must submit the calculations for the total cost of the Project using Supplement 4.7. Table A: System Project Management RequirementsScoring definitions: C is a critical component of the System. D is a desirable component of the System.RequirementScoringOfferor ResponseA.1The Contractor must manage the relationship among its staff and its subcontractors.CA.2The Offeror must describe their approach to working with ODJFS through each phase of the project, describing how they would collaborate with ODJFS on specific project-related functions, including requirements gathering, configuration, testing, and training. The Contractor must pay all expenses for travel to and from ODJFS sites.CA.3The Contractor must verify that all contractor and subcontractor staff have signed ODJFS non-disclosure agreements prior to commencing work on the project. Depending on the role of the individual, there may be several forms to be signed to ensure data is held safe.CA.4The Contractor must provide, as part of the contract resulting from this RFP, a deliverable acceptance process that includes deliverable requirements and expectations with: Acceptance criteria for documentation; andTest certification for software. CA.5The Contractor must use an industry standard Project Management methodology to provide the services as described by the Deliverables and System requirements. ODJFS is interested in an approach (e.g. Agile) that will deliver customer-facing value early in the project and in frequent increments throughout the project. Please describe prior projects where the methodology was able to deliver value in such a manner.CA.6The Contractor must jointly manage the System with the ODJFS Project Management Team including a lead from both the Office of Information Services (OIS) and Office of UI Operations (OUIO).CA.7The Contractor must provide, as part of the contract resulting from this RFP, the following Deliverables: 1.0 Project Planning:1.1 A Project Management Plan including milestones, schedule, communication plan and resources.2.0 Detailed Design3.0 Data Conversion4.0 System Installation and Configuration5.0Training and Knowledge Transfer6.0 Documentation7.0 Project Change Control Process8.0 Final System Acceptance9.0 Escalation plan10.0 Executive Steering Committee – roles and responsibility11.0 Organizational Change Management PlanCA.8The Offeror must outline the tools to be used for management of System in the following areas:Project Planning;Project scheduling; Word processing and spreadsheets [for all document based deliverables];Document repository; Management of the software customization and configuration process [including issues, System deficiencies, and testing documentation]; Requirements and development tracing; andTest planning and tracking.CA.9The proposed Project Plan must include tasks, a schedule and resources from System project initiation to System project implementation in sufficient detail to allow project monitoring.CA.10The proposed Project Plan must be updated and kept current, at least at two week intervals, throughout System customization, configuration and implementation.CA.11Offeror must provide a draft Project Plan for System as a part of the proposal outlining the high level tasks, dependencies, and milestones required to achieve the work described in the RFP.CA.12Offeror must describe approach and philosophy to requirements gathering, along with a description of prior projects where the approach and philosophy was used to collaborate with customers to develop rapid requirements and deliver customer-facing value early in the project.CA.13The Contractor must provide as part of the Contract resulting from this RFP a Test Plan for the System, including the following:How it will conduct Data Conversion, Integration, System, Functional, Performance, Security, and User Acceptance Testing; How it will conduct Mobile Device and Application Testing;How it will conduct Regression Testing;How it will test documentation to ensure that it accurately describes the System functionality; How it will provide certification (including documentation) of completion of Data Conversion, Integration, and System Testing prior to handing the System to ODJFS for User Acceptance Testing;How it will involve ODJFS staff in Integration and System Testing; andHow it will assist ODJFS staff in User Acceptance Testing.Must describe how the Contractor or Subcontractor has successfully tested its solution on prior similar projects.CA.14The Contractor must be responsible for conducting, documenting, and communicating Unit, Data Conversion, Functional, Integration, Security and System Testing.CA.15The proposed solution must be useable by a wide variety of end users. ?Must describe Offeror’s approach to usability and describe usability testing that offeror has conducted with its proposed solution. ODJFS reserves the right to conduct usability testing at its own expense in the State’s usability lab prior to implementation.CA.16Contractor must comply with the ODJFS approach to classifying deficiencies. ODJFS will be responsible for classifying deficiencies.Deficiencies (incidents that impact functionality or performance) will require remediation and retesting before System enters User Acceptance Testing.All deficiencies will require complete remediation and retesting prior to production implementation and System acceptance.CA.17The Contractor must assist ODJFS in the design of the User Acceptance Test(s).The Contractor must assist ODJFS in conducting the User Acceptance Test(s) and providing suitable environments for conducting such tests.CA.18The Contractor must document testing activity including scripts, modules tested, deficiencies detected, and remedies implemented for System and for System Interfaces.CA.19The Contractor must support testing with appropriate data and system configuration changes (including date changes) to support testing of all daily and periodic activities (e.g. rate run, annual FUTA certification).CA.20The Contractor must conduct knowledge transfer to ODJFS’s technology staff including, but not limited to:Content Management;System design and schema;System usage;System testing techniques (manual and automated);System procedures;Application and tools development;Report generation; Data and Database Administration;Utilities;Application Diagnostic Tools; andSystem administration and maintenance.CA.21The Contractor must update the System documentation, including, but not limited to:Reference manuals;Data Conversion process and results documentation; Data Architecture;Dependency documentation;Requirements specifications;Design documentation;Functional specification;User Interface documentation;Technical Interface documentation;Quality Management activities;Test Plans;User Manual;Online Help;System Manual;System Administration Manual;Help Desk Manual;Documentation (i.e., changes to requirements, use cases, business rules);Training Manuals and Materials; andData Maps for Extracts.CA.22The Contractor must make System documentation available in written manuals in electronic form, and online, as part of a help facility for the System.CA.23The Contractor must have an internal quality management function that will use: Internal Quality Assurance (QA) checklists and Quality Audits; andInternal Quality Control (QC) checklists and inspection.Regular QA reports must be provided to ODJFS using the metrics from the above processes.Offeror must provide a description of approach to Quality Management and how offeror or sub-contractor managed quality on prior projects.CA.24Contractor must provide a Risk Management Plan as part of the contract resulting from this RFP for System including:Methodology (approaches, tools, frequency of reviews);How risk documentation will be utilized and populated; How risks will be monitored and controlled; andHow Risk Mitigation and Contingency Plans will be developed and implemented.CA.25Offeror must describe its approach to implementation including, but not limited to:Assumptions;Schedule;Communications;Acceptance and exit criteria;How it will manage multi-staged implementation; andHow it will manage implementation with no disruption to the business or Systems in use by ODJFS.CA.26Offeror must describe its approach to System implementation as utilized on prior similar projects including, but not limited to: Strategy;Support resources required from customer;Responsibilities;Activities; andTiming.CA.27Offeror must provide a brief description of its entity (including business locations, size, areas of specialization and expertise, client base and any other pertinent information that would aid an evaluator in formulating a determination about the stability and strength of the entity), including the Offeror’s organization’s experience and history developing contact center systems of similar size and scope to the UIST Project.CA.28Offeror must provide a Project Organization overview that describes the Project Team structure and the roles and responsibilities of project team members, including:A Project Manager possessing at least thirty-six (36) months’ experience managing large scale SaaS deployments similar those proposed for in this RFP;Identification of each individual proposed to fill a key role for this engagement including the following information, at a minimum, for each person identified:Description of education and training;Description of previous experience fulfilling their assigned role; andDescription of previous direct experience with substantially similar projects.Offeror may include any other experience deemed relevant by the Offeror to adequately convey an individual's experience and qualifications. Responses for each individual must not exceed one (1) typed page; andOfferor must certify its intent to commit the proposed key staff for the project team to the engagement through implementation.CA.29Contractor must be responsible for a training plan and knowledge transfer to users on the functionality of the System. Classroom training is preferable.8. Table B: Unemployment Tax Business RequirementsIn addition to the general requirements outlined in Table D: Common Requirements, a technology solution must provide the capabilities identified in the following business requirements. Please describe the capabilities and functionality that would be provided which will meet these requirements. In the “Offeror Response” Section, offerors must check the applicable box to indicate whether the requested functionality is a core System capability, a configurable option, or requires custom development by offerors. In the “Narrative” box, the Offeror must provide a response describing how the System performs the functions described in each section or subsection.Scoring definitions: C is a critical component of the System. D is a desirable component of the System.Tax FunctionalityScoringOfferor ResponseCheck Applicable BoxNarrativeCore CapabilityConfiguration OptionRequires DevelopmentB.1 Employer RegistrationB.1.1The System must provide employers the ability to electronically register for Ohio Unemployment Taxes through an online business registration application.CB.1.2The System must provide employers the ability to electronically register new acquisitions and business transfers (for UI) through an online business registration application.CB.1.3The System must provide employers the ability to access the business registration application online. CB.1.4The System must provide the capability for staff to initiate an investigation based on a request for benefits from an employee when the System is unable to locate the employer. This activity must result in the creation of an assignment for staff to investigate. CB.1.5The System must be able to electronically process online business registrations and applications/information submitted by paper based on Ohio Revised Code (ORC) and Ohio Administrative Code (OAC).CB.1.6The System must be able to determine the liability date based on information entered and calculate timeliness for both new business and successors according to the ETA-581 business rules. This may include recording and posting the hire date and liability date.CB.1.7The System must allow staff to register a new business with the Ohio Office of Unemployment Insurance Operations (OUIO) using multiple source documents. CB.1.8The System must be able to capture and record the source document used to create an employer account when an employer registers a new business with the Ohio Office of Unemployment Insurance Operations (OUIO). CB.1.9The System must be able to electronically interface with the Ohio Secretary of State to validate business organizational types.DB.1.10The System must provide the ability to accept and process an application for voluntary election for an Ohio unemployment tax account based on the ORC and OAC.CB.1.11The System must be capable of re-determining liability of an account in a status other than liable.CB.1.12The System must be able to automatically create an employer account upon completion of the registration when an employer registers a business with the Office of Unemployment Insurance Operations (OUIO) using the account number sequence currently in place and then allow the employer to get web access. CB.1.13The System must be able to assign a unique employer account number to all created UI employer accounts using the current account number process. CB.1.14The System must evaluate the physical address of the employer and assign the proper county code to the employer’s account. The System must provide a process for the ODJFS Labor Market Information to validate and approve the county code initially assigned.CB.1.15The System must provide a process for the Labor Market Information group to validate, approve and enter the NAICS code initially assigned.CB.1.16The System must be able to automatically process the acquisition or transfer of a business and transfer the appropriate UI business experience/financial data through online and paper submission. The rates will be assigned according to Ohio law. CB.1.17The System must be able to electronically interface with external software (during the employer registration process) to validate address information. CB.1.18The System must be capable of automatically determining whether an employer account exists during the registration process. CB.1.19The System must be capable of determining if a similar account already exists in the System and create a workflow item for review.CB.1.20At the completion of the registration process, the System must provide a list of available resources the employer might find useful.DB.1.21The System must obtain the required information based on the ORC and OAC in order to create a new account. CB.1.22The System must allow a third-party administrator (TPA) to register online for a TPA account with multiple addresses and locations using the current TPA number assignment structure. The TPA process will consist of multiple service functions.CB.1.23The System must provide the capability for an employer to select a TPA and correct associated location. CB.1.24The System must provide the employer the capability to assign or change a TPA and must have the ability to have multiple TPA’s Tax and Benefits with overlapping functions.CB.1.25The System must allow a TPA to gain access to an employer account only after the employer associates the TPA and the service functions for which the TPA may act on behalf of that employer.CB.1.26The System must allow the staff, employer or TPA to disassociate the TPA association.CB.1.27The System must provide employers and staff the ability to create a Power of Attorney. CB.1.28The System must provide employers and staff the ability to register the employer for “seasonal” designation. (A designated seasonal employer is one who does not have to pay UI benefits between seasons.) CB.1.29The System must provide employers and staff the ability to save a partially-completed employer registration. CB.1.30The System must provide employers and staff the ability to complete partially saved employer registrations within a configurable time period. CB.1.31The System must be able to automatically hold the processing of an employer registration until the specific thresholds is met in order to be found liable to pay UI taxes. DB.1.32The System must be able to automatically complete the registration process when the specific threshold is met in order to be found liable to pay UI taxes.CB.1.33The System must be able to identify all accounts that were established that have not met liability and update the liability accordingly.DB.1.34The System must be capable of determining an employer Liable or Non-Liable based on Ohio law.CB.1.35The System must provide employers and staff the ability to modify completed, but not yet processed employer registrations. CB.1.36The System must provide employers and staff the ability to view the status of an employer registration. CB.1.37The System must electronically interface with the federal Internal Revenue Service (IRS) to validate tax exempt status for UI purposes.DB.1.38The System must electronically interface with the Social Security Administration to validate the social security numbers (SSN) of owner/corporate officers for purposes of employer registration.DB.1.39The System must electronically check to see if wages on quarterly reports can be validated for SSN’s with the Social Security Administration.DB.1.40The System must automatically create an employer web account for employers when an employer account number is assigned.CB.1.41The System must allow staff to edit status information (e.g. liability dates, deactivation dates, reactivation dates, transfer dates, etc.) and make the appropriate updates to the employer account, both monetary and non-monetary.CB.2 Rate DeterminationB.2.1The System must automatically calculate and assign tax rates using the appropriate employer experience and tax rate calculation based on Ohio law.CB.2.2The System must automatically assign a tax rate to an employer account when the employer type is changed from 'Reimbursing' to 'Contributing.'CB.2.3The System must automatically assign a new business tax rate to new employers based on Ohio law, and include the first two digits of the North American Industry Classification System (NAICS) code.CB.2.4The System must assign a two digit NAICS code based on information provided during the registration process. The two digit NAICS code will be used to determine the new business rate based on Ohio law.CB.2.5The System must be capable of creating a workflow process providing the Labor Market Information section the ability to assign the NAICS code.CB.2.6The System must be capable of receiving a file from the Labor Market Information section of all NAICS codes changed and adjust the new business rate according to Ohio law and rule.CB.2.7The System must allow staff to view the information used in the calculation of a tax rate for an employer (i.e. history of benefit charges, taxable payroll and taxes paid, credits, adjustments, etc.).CB.2.8The System must allow for annual taxable wage base to be a parameter based on calendar year and calculate the taxable wage base based on the value entered.CB.2.9The System must allow staff to perform 'what if' scenarios to view the outcome of new tax rate calculations prior to the outcome becoming official.CB.2.10The System must allow staff to suspend the automated rate calculation on an employer account.CB.2.11The System must allow staff to manually restart the automated rate calculation on an employer account.CB.2.12The System must be able to automatically calculate the components (history of benefit charges, taxable payroll and taxes paid) used in the rate calculation before calculating the employer tax rate. CB.2.13The System must be able to automatically calculate the tax rate of a successor employer(s) account when there is a full or partial transfer of business based on Ohio law and rule.CB.2.14The System must provide the ability to combine two or more transfers of employer experience/financial data when calculating tax rates.CB.2.15The System must automatically calculate and assign tax rate penalties to the appropriate employer accounts.CB.2.16The System must automatically calculate and add/apply solvency tax to the appropriate employer tax rate.CB.2.17The System must automatically calculate and apply a surcharge tax to appropriate employers tax rate.CB.2.18The System must recalculate tax rates when a benefit charge/credit is applied/moved to or from an employer account based on Ohio law and rule.CB.2.19The System must automatically recalculate the employer's rate upon receipt of a voluntary payment. CB.2.20The System must automatically process the appropriate tax rate recalculation, when multiple liability and tax rate (re)determinations occur on the same business day i.e. liability date changes, reconsidered decisions, etc.CB.2.21The System must automatically recalculate and remove tax rate penalties and solvency tax when applicable.CB.2.22The System must allow staff to modify an employer's rating experience by adjusting values within each category used in the rate calculation, i.e. between fiscal years, between employer accounts, rate balance, etc.CB.2.23The System must allow staff to remove penalties. CB.2.24The System must allow staff to change tax rate component information. CB.2.25The System must allow staff to suppress the generation of a tax rate notice.CB.2.26The System must automatically exclude protested (suspense) charges from the current yearly employer unemployment tax rate calculation.CB.2.27Annually the System must determine the rates for employers based on Ohio law. There will be an annual rate run for all employers and a revised rate run for employers with a change occurring after the annual rate run.CB.2.28The System must determine the trust fund balance, employer account balances and subsidiary account balances and adjustments to the mutualized account. Annually the System must calculate the credits and charges to the mutual account as defined in Ohio law, rule, and procedure in order to calculate the Mutual Rate. CB.2.29The System must provide the capability for employers to apply for, calculate and receive a common rate based on Ohio law. The calculation of the common rate group will be across multiple employers.CB.2.30The System must have the capability to create/edit members or dissolve the common rate group.CB.2.31The System must evaluate annually all current common rate groups and inform them if the common rate group is in jeopardy of being dissolved. CB.2.32The System must provide the ability to exchange rate information on a quarterly basis with employers/TPA’s.CB.2.33The System must be capable of providing TPA’s a file containing the rate factors/transcript for each client. DB.2.34The System must be capable of housing all rate determinations no matter the source in which the rate determination is generated.CB.2.35The System must be capable of annually calculating negative balance adjustments on employer accounts and transferring them during the successorship transaction.CB.2.36The System must be capable of calculating the rate table to include all factors within Ohio law to include the minimum safe level adjustments and calculations.CB.2.37The System must be capable of revising the rate for an employer and then revising the calculation of taxes due.CB.3 Quarterly Reporting B.3.1The System must generate a Quarterly Wage Detail/Quarterly Summary Report form to contributing employers by their preferred delivery method. CB.3.2The System must generate a Quarterly Wage Detail Report form to reimbursing employers by their preferred delivery method.CB.3.3The System must automatically pre-populate the Quarterly Wage Detail/Quarterly Summary Report form or the Quarterly Wage Detail/Payroll Report form with employee/wage information reported for the previous calendar quarter.CB.3.4The System must automatically notify the employer on the Quarterly Wage Detail/Quarterly Summary Report form or the Quarterly Wage Detail/Payroll Report form of any outstanding account balance, credit or missing quarterly reports. CB.3.5The System must provide the ability for employers to submit the Quarterly Wage Detail/Quarterly Summary Report form or the Quarterly Wage Detail/Payroll Report form for Reimbursing Employers online through the employer web portal, file upload, the Ohio Business Gateway, and/or by utilizing the Quarterly Wage Reporting Tool (QWRT).CB.3.6The System must be able to automatically calculate taxable wages and taxes due based on entered wages from the Quarterly Wage Detail/Quarterly Summary Report form. The calculation must take in to consideration out of state wages.CB.3.7The System must be capable of accepting and processing all deposits or payments received without regard to the source.CB.3.8The System must allow an employer to file the quarterly report and defer their payment based on OUIO business rules.CB.3.9The System must allow electronic payments from the field for collection of amounts owed as a result of an audit.DB.3.10The System must be able to automatically calculate any penalties and interest resulting from an untimely filing of the Quarterly Wage Detail/Quarterly Summary Report form or the Quarterly Wage Detail/Payroll Report form.CB.3.11The System must provide the employer the option to electronically pay taxes due upon submission of the Quarterly Wage Detail/Quarterly Summary Report. CB.3.12The System must be able to automatically display a printable payment coupon if the employer elects not to pay taxes due electronicallyCB.3.13The System must provide the ability for employers to submit a file of Quarterly Wage Detail/Quarterly Summary Reports or the Quarterly Wage Detail/Payroll Reports (for multiple employers) through the employer web portal. CB.3.14The System must provide security to prevent an employer from viewing confidential personal information of another employer’s account. The System may mask SSN’s or provide a check and balance when processing a file upload of a quarterly report or amendment from an employer. The check could be a verification of the employer account number and FEIN or the System could require the employer to create their own PIN used when uploading a file.DB.3.15The System must electronically interface with the financial institution vendor to accept a file of Quarterly Wage Detail/Quarterly Summary Reports or the Quarterly Wage Detail/Payroll Reports. CB.3.16The System must automatically calculate any penalties resulting from an untimely filing of the Quarterly Wage Detail/Quarterly Summary Report form or the Quarterly Wage Detail/Payroll Report form.CB.3.17The System must be able to automatically post Quarterly Wage Detail/Quarterly Summary Reports or the Quarterly Wage Detail/Payroll Reports records and payments contained within a file submission.CB.3.18The System must allow staff to enter Quarterly Wage Detail/Quarterly Summary Reports or the Quarterly Wage Detail/Payroll Reports. CB.3.19The System must calculate and post calculated gross wages, taxable wages and the tax due when the Quarterly Wage Detail/Quarterly Summary Report is submitted via an electronic file or entered by staff.CB.3.20The System must create a work item when the System calculated gross wages, excess wages, taxable wages or tax due is different than the reported tax due.CB.3.21The System must be able to prevent the filing of duplicate Quarterly Wage Detail/Quarterly Summary Reports or the Quarterly Wage Detail/Payroll Reports. The System must handle any blocking situations that are preventing the running of other files without manual intervention.CB.3.22The System must be capable of creating a suspense work item when multiple reports are filed. The System must allow staff to edit, change, combine, etc. information contained within the reports.CB.3.23The System must automatically recalculate taxable wages and taxes due based on entered wages from the Amended Quarterly Wage Detail/Quarterly Summary Report form. This form will need to be revised from the current form.CB.3.24The System must process amendments and take in to consideration out of state wages and not include the out of state wages in the calculation of taxable wages and taxes due.CB.3.25The System must be capable of cross referencing benefits paid on an employee whose wages are being amended. The System must create a work item when the employer submits the amendment. The System must alert the staff when processing an amendment.DB.3.26The System must provide the employer the option to electronically pay taxes due upon submission of the Amended Quarterly Wage Detail/Quarterly Summary Report if the amended taxes due is greater than the previously calculated taxes due.CB.3.27The System must automatically generate a Quarterly Wage Detail/Payroll Report form to reimbursing employers by their preferred delivery method.CB.3.28The System must automatically display a printable payment coupon if the employer elects not to pay original or amended taxes due electronically.CB.3.29The System must electronically interface with the financial institution vendor to accept a file of Amended Quarterly Wage Detail/Quarterly Summary Reports or Amended Quarterly Wage Detail/Payroll Reports. CB.3.30The System must automatically post Amended Quarterly Wage Detail/Quarterly Summary Reports or the Amended Quarterly Wage Detail/Payroll Reports records contained within a file submission.CB.3.31The System must calculate and post calculated amended gross wages, amended taxable wages and the amended tax due when the Amended Quarterly Wage Detail/Quarterly Summary Report is submitted via an electronic file, approved form or entered by staff.CB.3.32The System must automatically generate a notice to the employer if the System calculated gross wages, excess wages, taxable wages or tax due is different than the reported amended tax due.CB.3.33The System must automatically generate a notice to the employer if the System calculated amended gross wages, excess wages, taxable wages or tax due is different than the reported amended tax due. CB.3.34The System must calculate the amount of contribution, forfeiture, interest, surcharge and any other penalties based on Ohio law.CB.3.35The System must generate monthly statements containing outstanding debts and credits on both Contributory and Reimbursing employers.CB.3.36The System must automatically create and generate an estimated Quarterly Wage Detail/Quarterly Summary Reports or the Quarterly Wage Detail/Payroll Reports to an employer.CB.3.37The System must automatically post an estimated Quarterly Wage Detail/Quarterly Summary Reports or the Quarterly Wage Detail/Payroll Reports to an employer.CB.3.38The System must automatically inactivate an employer account if an employer indicates that the Quarterly Wage Detail/Quarterly Summary Reports or the Quarterly Wage Detail/Payroll Reports is the final report.CB.3.39The System must automatically generate a Notice of Discontinuance to an employer if an employer indicates that the Quarterly Wage Detail/Quarterly Summary Reports or the Quarterly Wage Detail/Payroll Reports is the final report.CB.3.40The System must auto deactivate after 8 quarters of a combination of no reports or zero reports and create work items if there is an appeal, audit, or a benefit block claim (422) etc.CB.3.41The System must allow staff to flag an employer account with a ‘do not deactivate’ flag.CB.3.42The System must automatically flag an employer account with a do not deactivate if there is an open compliance work item or appeal.CB.3.43The System must automatically post the Quarterly Wage Detail/Quarterly Summary Reports or the Quarterly Wage Detail/Payroll Reports to the successor employer account if the report is submitted by a deactivated employer. This may generate a work item.CB.3.44The System must automatically post the Amended Quarterly Wage Detail/Quarterly Summary Reports or the Amended Quarterly Wage Detail/Payroll Reports to the successor employer account if the report is submitted by a deactivated employer. This may generate a work item.CB.3.45The System must generate a monthly statement to the Employers after a payment, credit or change in balance due is posted to the Employer account.CB.3.46The System must generate a Notice of Failure to File report to the contributing Employers who fail to file their Quarterly Wage Detail/Quarterly Summary report.CB.3.47The System must generate a Notice of Failure to File Wage Detail/Payroll report to the reimbursing Employers who fail to file their Quarterly Wage Detail/Payroll report.CB.3.48The System must be capable of posting prior quarter reports and adjusting the employer account accordingly (e.g. taxes, rates, taxable wages, penalties, interest, etc.)CB.3.49The System must provide the capability for staff, employers and TPA’s to correct wage information during input process and after the acceptance of the data. The System must correct and post the information and calculate and tax and/or benefit changes as a result of the amendment.CB.3.50The System must perform a reconciliation between the wage and quarterly summary reports and create a work item to be processed by staff if not corrected automatically.CB.3.51The System must provide the largest TPA’s the ability to ftp their quarterly wage and summary file to be uploaded in the system and pay through an ACH credit transaction as is currently processed.CB.3.52The System must accept and process supplemental reports according to Ohio law and rule.CB.3.53The System must be capable of allowing certain roles to delete an entire Wage Detail report.CB.3.54The System must be capable of allowing staff to delete individuals or a group of individuals from a Wage Detail report.CB.3.55The System must be capable of flagging an employer that is permitted to file quarterly reports by paper.DB.4 Employer Maintenance - Staff OptionsB.4.1The System must allow staff to view all incoming and outgoing correspondence attached to an employer account.CB.4.2The System must allow staff to search for an employer account using various search criteria.CB.4.3The System must allow staff to view all financial/non-financial information attached to an employer account.CB.4.4The System must allow staff to update contact information attached to an employer account (i.e. address(es), officers, partners, contacts, location(s), phone, etc.).CB.4.5The System must allow the employer, TPA or staff to modify the employer's Federal Employer Identification Number (FEIN). The System must validate and confirm every entry for format and duplication.CB.4.6The System must allow staff to the view the history of modifications to an employer's FEIN. CB.4.7The System must maintain a history of all transactions processed in the system and who processed the transaction.CB.4.8The System must automatically send a request for an FEIN if the account is established without an FEIN. CB.4.9Annually, the system must send a request for an FEIN on any active account that does not have an FEIN.CB.4.10The System must be capable of utilizing the FEIN extract file from the IRS to create letters to mail to employers that do not have an account set up in Ohio. The IRS guidelines on how to use and store the data in the extract file must be followed.DB.4.11The System must allow staff to maintain the liability status for an employer account.CB.4.12The System must automatically update an employer account status (i.e. active, inactive, non-liable, deactivated, reactivate, etc.). CB.4.13The System must allow staff to update/view an employer account status (i.e. active, inactive, non-liable, deactivate, reactivate, cancel). CB.4.14The System must transfer the negative and positive reserve balance of deactivated employer accounts to the mutual account based on the ORC.CB.4.15The System must allow staff to change the employer type from contributing to reimbursing or reimbursing to contributing.CB.4.16The System must be able to apply all financial data (and perform all necessary calculations) when the employer type is changed from contributing to reimbursing or reimbursing to contributing.CB.4.17The System must allow staff to modify non-financial information related to an employer account (i.e. report received/posting dates, number of employees, statute date, etc.).CB.4.18The System must allow staff to modify financial data resulting from a tax appeal, needed edits or waiver determination.CB.4.19The System must allow staff to post, cancel, and adjust penalties and interest on an employer account. CB.4.20The System must be able to automatically (re)calculate employer account balance when transactions have been made on the employer account. CB.4.21The System must allow staff to view the tax payment history for an employer account.CB.4.22The System must allow staff to post a payment from a suspense account to an employer account.CB.4.23The System must allow staff to transfer the posting of a payment to a different tax quarter and employer account. CB.4.24The System must provide the capability to process refunds and other payments to an employer or TPA agent based on Ohio law and rule.CB.4.25The System must provide the ability for an employer or TPA to request a refund through online and paper options.CB.4.26The System must route refund requests through a work queue that are not able to be processed automatically. CB.4.27The System must be able to post and apply credits automatically and manually according to current allocation rules. The System must be able to handle expired credits, hold credits from a refund and adjust the current way employers are notified of credits that expire.CB.4.28The System must be able to automatically refund payment to employers for payments in excess of balance due based on OUIO business rules.CB.4.29The System must allow staff to record information related to a lost, missing or returned refund payment. CB.4.30Any refund greater than a specific threshold must be routed through a process to review and approve.CB.4.31The System must offset a refund by the amount of benefit charges paid to a claimant that is determined to be in excluded employment.CB.4.32The System must allow staff to view and update information relating to lost, missing, or returned refund payments. Information includes the status of a lost or missing payment.CB.4.33The System must be able to automatically place a stop payment on a refund that meets criteria including, but not limited to stale dates.CB.4.34The System must provide the capability to cancel or disallow a refund or correct a discrepancy prior to the issuance of a refund.CB.4.35The System must allow the employer to request a replacement refund via online or paper form.CB.4.36The System must allow staff to view the tax rate history for an employer account.CB.4.37The System must allow staff to view the Quarterly Wage Detail/Quarterly Summary Report (Quarterly Wage Detail/Payroll Report) history for an employer account.CB.4.38The System must allow staff to view the method of how a Wage Detail/Quarterly Summary and Payroll report was filed.CB.4.39The System must allow staff to update/correct a Quarterly/Wage Detail/Summary Report, Quarterly Wage Detail/Payroll Report, Amended Quarterly Wage Detail/Summary Report, or Amended Quarterly Wage Detail/Payroll Report.CB.4.40The System must allow staff to transfer the following completed/correct: Quarterly Wage Detail/Summary Reports and or payment; Quarterly Wage Detail/Payroll Report; Amended Quarterly Wage Detail.CB.4.41The System must allow staff to adjust quarterly wages attached to an employer account.CB.4.42The System must allow staff to transfer a portion of Wage Detail report to another employer account.CB.4.43The System must allow staff to transfer a portion of an individual’s wages to another employer account.CB.4.44The System must prepare an Employer Account Abstract annually for each employer for the annual FUTA certification process. The System must adhere to the IRS guidelines. CB.4.45This system must process the second FUTA run with the IRS electronically and follow the IRS guidelines.CB.4.46The System must allow staff to enter/modify/view requests for FUTA tax credits for an employer account.CB.4.47The System must automatically or manually generate a recertification on a request for a FUTA tax credit for an employer account.CB.4.48The System must allow staff to view benefit charges and credits for an employer account.CB.4.49The System must allow staff to create/modify/view a Power of Attorney and Third-Party Actuary for an employer account.CB.4.50The System must allow for an account to be reactivated according to the reactivation rules in Ohio law and rule.CB.4.51The System must allow an employer, TPA or staff to deactivate an employer account based on Ohio law and rule.CB.4.52The System must prevent the issuance of forfeitures and/or interest or cancel forfeiture and/or interest for quarters after the deactivation date.CB.4.53The System must automatically deactivate an employer account when there have been eight or more quarters of no employment or filing history. CB.4.54The System must generate a notice to the employer when the account is deactivated.CB.4.55The System must provide the capability for an employer or TPA to request a corporate dissolution and the ability to process the corporate dissolution.CB.4.56The System must calculate the amount of contributions, forfeiture, interest, surcharge and assess/provide a monthly statement to include the amount due and/or any credits available. CB.4.57The System must allocate any payments made to employer accounts based on Ohio law and rule.CB.4.58The System must be capable of allocating payments made on the total rate and breaks down the distribution of the payment between the different rate factors. This includes contributions, mutual, surcharge and penalties.CB.4.59The System must allow staff to reallocate payments.CB.4.60The System must provide a process to allow staff to create a coupon for checks received without coupons that can be processed on our check process equipment. CB.4.61The System must allow staff to request and/or view statements for an employer account (i.e. IRS Certification of Accounts, Summary of Benefit Charges and Credits, Monthly Statements, etc.).CB.4.62The System must allow staff to generate employer account statements (i.e. Zero Balance).CB.4.63The System must allow staff to view the tax appeal history for an employer account. CB.4.64The System must allow staff to enter/update/view a tax appeal (tax rate, tax liability, and/or assessment/collection) or an appeal of a an employer account.CB.4.65The System must allow staff to enter/update/view information related to an employer's request/designation as a Seasonal Employer.CB.4.66The System must automatically generate a determination to designate an employer as a seasonal employer.CB.4.67The System must allow staff to enter/update/view yearly school calendar information for an employer (educational institutions).DB.4.68The System must allow staff to enter/update/view information related to classifying an employer as an Employee Leasing Company, PEO, Captive Provider, Common Paymaster, Payroller, Localization, Temp Agency, Management Company or Misclassification.CB.4.69The System must automatically designate/un-designate an employer as an Employee Leasing Company, PEO, Captive Provider, Common Paymaster, Payroller, Localization, Temp Agency, Management Company or Misclassification.CB.4.70The System must be able to process successorships according to Ohio law and rule.CB.4.71The System must allow staff to enter/update/view information for a business transfer (mandatory, voluntary, whole or partial).CB.4.72The System must automatically create a transfer of a business(s) (whole or partial) to an existing employer account(s) (successor).CB.4.73The System must automatically create a new employer account (successor) when creating a transfer of a business(s)CB.4.74The System must accept a request for a transfer online and by paper form and process the transfer automatically if all business rules are met. If not, then the system will create a work item for staff to review and process.CB.4.75The System must establish the contribution rate based on Ohio law.CB.4.76The System must have the ability to process a successorship when a reimbursing employer is included in the transfer.CB.4.77The System must automatically reverse a business transfer.CB.4.78The System must reverse all monetary transactions back to the original account when performing a reversal. CB.4.79The System must allow staff to deactivate an employer account.CB.4.80The System must automatically consolidate a deactivated employer account with an existing employer account.CB.4.81The System must allow staff to un-consolidate a deactivated employer from an existing employer account.CB.4.82The System must allow staff to view assessment/collection cases and associated collection activities attached to an employer account.CB.4.83The System must allow staff to apply court fees and damages on an employer account when a judgment case decision has been rendered.CB.4.84The System must allow Wage Detail reports to be filed on a deactivated account based on OUIO business rules. This may include quarters before the liability date and quarters after the deactivation date. The System will create a workflow item when reports are filed outside of the liability/deactivation dates based on OUIO business rules.CB.4.85The System must allow staff to perform an assessment maintenance function to add, remove or reduce debt.CB.5 Employer Maintenance - ReimbursingB.5.1The System must process an employer’s request to be classified as a reimbursing employer or convert back to a contributory employer based on Ohio law.CB.5.2The System must have the capability to convert a Public Entity to and from Contributory and Reimbursing status.CB.5.3The System must create/edit/deny/dissolve Reimbursing Groups.CB.5.4The System must automatically calculate when a security bond is required of a reimbursing employer account. CB.5.5The System must automatically generate a notice to a reimbursing employer when a security bond is required (for initial security as well as renewal of security). CB.5.6The System must provide the ability for an employer to designate a single security bond to be attached to multiple employer accounts. CB.5.7The System must allow staff to enter/update/view security bond information for a reimbursing employer account. CB.5.8The System must automatically generate security correspondence to all reimbursing employers attached to the security bond. CB.5.9The System must generate an amended security notice when the annual gross payroll for a reimbursing employer is amended based on OUIO business rules. CB.5.10The System must be able to automatically generate a notice to a reimbursing employer who is delinquent in payment on the employer account requesting a cash-in of the security bond. CB.5.11The System must automatically generate reimbursing employer billing statements on a monthly basis. CB.5.12The System must automatically calculate the total payment due on a reimbursing employer billing statement. CB.5.13The System must automatically itemize the charges for an employer on a reimbursing employer billing statement. CB.5.14The System must automatically calculate and itemize penalties and interest due on a reimbursing employer billing statement. CB.5.15The System must allow staff to adjust penalties and interest on a reimbursing employer account through assessment maintenance or waiver process. CB.5.16The System must generate an amended reimbursing employer monthly billing statement when an adjustment in benefits paid/penalties/interest is made on a reimbursing employer account. CB.5.17The System must allow staff to create/update/view a Group Account for reimbursing employers (who elect to share the cost of reimbursing UI benefits paid to former employees.) CB.5.18The System must allow staff to add/remove employers from a reimbursing employers Group Account. CB.5.19The System must allow staff to designate the employer who will serve as group representative/agent for the reimbursing employers Group Account. CB.5.20The System must automatically recognize the representative agent reimbursing employer on a Group Account. CB.5.21The System must automatically generate correspondence to all reimbursing employers within a Group Account. CB.5.22The System must generate reimbursing billing statements to the representative reimbursing employer within a Group Account. CB.5.23The System must itemize the reimbursing billing statement for each employer within the Group Account. CB.5.24The System must include outstanding forfeiture and interest on the Reimbursing Group monthly billing statement.CB.5.25The System must recalculate the bonding requirement and notify each employer of a group when the Group Account is dissolved.CB.5.26The System must allow a Reimbursing Group account to be dissolved.CB.5.27The System must allow certain roles to view the payment transactions processed by day/week/month/year.CB.5.28The System must allow staff to override the calculated bond amount.CB.5.29The System must allow staff to view a history of bonds including expired bonds.CB.5.30The System must allow staff to view a history of Reimbursing groups and changes made over time.CB.6 Employer Self-Service B.6.1The System must provide employers the ability to access information and perform services related to their claim through a secure web portal. CB.6.2The System must dynamically display links within the employer portal based on the services which the web account owner can perform. CB.6.3The System must provide employers the ability to add users to their web account through the employer web portal. CB.6.4The System must provide employers the ability to grant permissions to added users to perform services at a task level. CB.6.5The System must provide employers the ability to view users added to their web account and modify permissions to perform services. CB.6.6The System must provide employers the ability to view all activities performed through their web account by users added to the account. CB.6.7The System must provide employers the ability to view all incoming and outgoing correspondence attached to their employer account through the employer web portal regardless of their preferred delivery method. CB.6.8The System must provide employers the ability to modify contact information attached to their employer account (i.e. address, phone) through the employer web portal. CB.6.9The System must provide employers the ability to change their liability status (liable to nonliable or non-liable to liable) through the employer web portal. This may create a work item based on OUIO business rules.CB.6.10The System must provide employers the ability to view their tax payment history through the employer web portal. CB.6.11The System must provide employers the ability to view their tax rate history through the employer web portal. CB.6.12The System must provide employers the ability to view their Quarterly Wage Detail/Quarterly Summary Report (Quarterly Wage Detail/Payroll Report) history.CB.6.13The System must provide employers the ability to create/modify/view a Power of Attorney/Third Party Actuary through the employer web portal. CB.6.14The System must provide employers the ability to file a Quarterly Wage Detail/Quarterly Summary Report through the employer web portal, file upload, The Ohio Business Gateway, the Quarterly Wage Report Tool (QWRT), or IVR. CB.6.15The System must provide employers/TPA’s the ability to submit a file containing multiple Quarterly Wage Detail/Quarterly Summary Reports through the employer web portal. CB.6.16The System must provide employers the ability to file a Quarterly Wage Detail/Payroll Report through the employer web portal. CB.6.17The System must provide employers/TPA’s the ability to submit a file containing multiple Quarterly Wage Detail/Payroll Reports through the employer web portal. CB.6.18The System must provide employers the ability to file an Amended Quarterly Wage Detail/Quarterly Summary Report through the employer web portal. CB.6.19The System must provide employers/TPA’s the ability to submit a file containing multiple Amended Quarterly Wage Detail/Quarterly Summary Reports through the employer web portal. CB.6.20The System must provide employers the ability to file an Amended Quarterly Wage Detail/Payroll Report through the employer web portal. CB.6.21The System must provide employers/TPA’s the ability to submit a file containing multiple Amended Quarterly Wage Detail/Payroll Reports through the employer web portal. CB.6.22The System must provide employers the ability to make electronic tax payments through the employer web portal. CB.6.23The System must provide employers the ability to submit a file of tax electronic payments through the employer web portal, the Ohio Business Gateway, or the Quarterly Wage Reporting Tool (QWRT). CB.6.24The System must provide employers the ability to file a Discontinuance of Business through the employer web portal. CB.6.25The System must provide employers the ability to Request and/or View Statements through the employer web portal. (i.e. IRS Certification of Accounts, Summary of Benefit Charges and Credits.) CB.6.26The System must provide employers the ability to file a tax appeal (tax rate, tax liability, and/or assessment/collection) through the employer web portal. CB.6.27The System must provide employers the ability to submit an Application for Designation as a Seasonal Employer through the employer web portal. CB.6.28The System must provide employers the ability to request to be classified as an Employee Leasing Company, PEO, Temporary Staffing Agency, Management Company, Captive Provider, Common Paymaster or Payroller through the employer web portal. CB.6.29The System must provide employers the ability to submit a request for a transfer of business through the employer web portal. CB.6.30The System must provide employers the ability to request cancellation of interest and/or penalties through the employer web portal. CB.6.31The System must provide employers the ability to request a refund.CB.6.32The System must be capable of depositing a refund directly to an employer’s bank account through an electronic refund/payment file.D B.6.33The System must provide employers the ability to appeal. CB.6.34The System must provide employers the ability to view assessment/collection activity attached to their employer account through the employer web portal. CB.6.35The System must provide an online 'wizard' for employers to assist in determining future liability/tax account balances. CB.6.36The System must provide an online ‘wizard’ for employers to assist the employer in determining if a worker should be classified as an employee or independent contractor. DB.6.37The System must purge all non-liable and deactivated accounts based on Ohio law and rule.CB.6.38The System must be capable of allowing employers/TPA’s to print confirmation pages.CB.6.39The System must create a work item when the employer reduces wages to zero or removes wages entered from an audit or appeal.CB.7 Fiscal Management B.7.1The System will have at its core a financial system capable of supporting accounts within the UI system. The System will be capable of maintaining and updating employer financial accounts. CB.7.2The System must provide the capability to accept and process a quarterly wage and summary report prior to and independent of the actual receipt of a payment.CB.7.3The System must be capable of accepting and processing all deposits or payments received, without regard to the source.CB.7.4The System must create an entry into an employer’s account of any funds received from the employer, how the funds were received and record the processing and tracking of those funds until deposit.CB.7.5The System must provide the ability to determine, track, and report exception transactions and the ability to resolve exceptions through a workflow process. This includes a suspense account of funds received and not yet allocated.CB.7.6The System must provide the ability for staff to manually modify employer account information, i.e. transfer funds between employer accounts, adjust post mark dates, adjust payments, adjust incorrect quarters, adjust total and taxable/covered wages, cancel debt, etc.CB.7.7The System must be capable of recalculating taxes, penalties, interest and rates based on a post mark date edit.CB.7.8The System must provide the capability to staff to review the results produced by the adjustment and confirm the request.CB.7.9The System must allow TPA’s to make one online payment for multiple client accounts regardless of what is due on the client accounts.CB.7.10The System must be capable to process and secure Federal Tax Information (FTI) to allow Ohio to participate in the Treasury Offset Program (TOP) for tax.CB.8 Proof of Claim - BankruptcyB.8.1The System must provide the ability to electronically interface with the U.S. Bankruptcy Courts Centralized Electronic Bankruptcy Notifying (EBN) system to receive notification and updates of bankruptcy filings for Ohio employers. CB.8.2The System must allow staff to search for (and view) a bankruptcy case by bankruptcy case number. CB.8.3The System must provide the ability to view all bankruptcy cases attached to an employer. CB.8.4The System must allow staff to enter, update, and view bankruptcy case. CB.8.5The System must allow staff to attach multiple employers to a bankruptcy case. CB.8.6The System must associate documents and correspondences with a bankruptcy case. CB.8.7The System must allow staff to maintain the status of a bankruptcy case. CB.8.8The System must suspend normally automated processes if there is an active bankruptcy case attached to an employer. CB.8.9The System must allow staff to file/modify/amend a proof of claim on the bankruptcy case. CB.8.10The System must allow staff to electronically submit a proof of claim with associated attachments to PACER and/or the U.S. Bankruptcy Courts Centralized Electronic Bankruptcy Notifying (EBN) system. CB.8.11The System must electronically interface to the U.S. Bankruptcy Courts Centralized Electronic Bankruptcy Notifying (EBN) system to receive reports when assets have become available or the trustee has filed a Trustee Final Accounting. CB.8.12The System must electronically receive payments from U.S. Bankruptcy Courts Centralized Electronic Bankruptcy Notifying (EBN) system. CB.8.13The System must allow staff to enter notification/updates of bankruptcy filings for Ohio employers. CB.9 Employer Compliance - Field AuditB.9.1The System must distinguish between audit and non-audit for TPS purposes.CB.9.2The System must provide the ability to change the case type from compliance work item to audit.CB.9.3The System must allow staff to create/update/view employer compliance audit cases. CB.9.4The System must allow staff to select the type of employer compliance audit cases. CB.9.5The System must flag the employer account as “under audit.”B.9.6The System must allow staff to maintain the status of an employer compliance audit case, including assignment of due date. CB.9.7The System must provide staff the ability to associate and view documents attached to an employer compliance audit case.CB.9.8The System must automatically assign an employer compliance audit case to staff based on the zip code of the employer's business address. CB.9.9The System must allow for the creation of compliance work items to be processed by staff through an automatic or manual assignment. CB.9.10The System must allow for the auditor to prepare, upload, and process forms.CB.9.11The auditor must have the ability to add multiple employer accounts to an existing case.CB.9.12The System must support the ability to cut and paste or import from for “quick entry” (i.e. cut and paste from another program, export).CB.9.13The System must provide a laptop audit component that is in sync with the audited employer account (bi-directional). CB.9.14The System must allow staff to create and update an online audit action plan for employer compliance audit cases. CB.9.15The System must have the ability for staff to approve/deny/modify the findings resulting from the employer compliance audit case. CB.9.16The System must allow staff to generate a (re)determination on the outcome of the employer compliance audit case. CB.9.17The System must have the ability to clearly show variances between employer reported information and auditor found information, thus meeting the DOL/TPS required audit tests.CB.9.18The System must have the ability to assign due date reminders to staff with escalation functionality.CB.9.19The System must have “notes” functionality within the audit module. The System must have the ability to spellcheck case note entries.CB.9.20The System must enforce validation checks prior to submission to ensure data conforms to Tax Performance System (TPS) requirements.CB.9.21The System must provide the ability to automatically create delinquency work items based upon pre-determined parameters.CB.9.22The System must automatically select a configurable subset of completed employer compliance audit cases for quality review. CB.9.23The System must allow staff to enter time usage and travel (ex. mileage) related to a specific employer compliance audit case. CB.9.24The System must generate random audits of employer accounts based on variable criteria. CB.9.25The System must electronically receive referrals for Benefit Blocked Claims Investigation with auto assigning (aka Liability Assignments and Claimant Affidavit of Wages). CB.9.26The System must automatically update claim information based on the entry/update of the findings of the investigation in the employer compliance audit case. CB.9.27The System will generate a liability assignment when any proof other than Employer supplied tax wage report is used for proof of wages in a claim.CB.9.28The System must be able to electronically interface with the IRS to receive Form 1099-MISC data. CB.9.29The System must be able to generate misclassification determinations to employers based on ORC (20 factors).CB.9.30The System must allow staff to transmit the result of an employer compliance audit case related to employee misclassification to the IRS.CB.9.31The System must be able to crossmatch employer records and quarterly wage data to identify employers who meet the criteria for potential SUTA dumping.CB.9.32The System must interface with SUTA Dumping Detection Software (SDDS) to identify employers who meet the criteria for potential SUTA dumping.CB.9.33The System must provide the ability for staff to associate multiple employers to a SUTA case.CB.9.34The System must be able to identify the core (master) employer when multiple employers are associated with a SUTA case. CB.9.35The System must be able to discontinue automated processes for an employer when a case is created for SUTA investigation.CB.9.36The System must be able to prevent the archiving or deleting of an employer record if the employer account is under SUTA investigation.CB.9.37The System must be able to create a SUTA summary document of the findings of a SUTA investigation. CB.9.38The System must provide the ability for staff to generate a determination to employers with the disposition of the SUTA case.CB.9.39The System must be able to identify successorship cases for ETA 581 reporting purposes.CB.10Tax AppealsB.10.1The System must be able to receive and process a protest/appeal via fax, mail or electronically.CB.10.2The System must be able to automatically associate a protest/appeal to a nonmonetary determination, a monetary determination or a tax-related issue.CB.10.3The System must be able to not allow a protest/appeal to be created when a protest/appeal already exists for the attached nonmonetary determination, monetary determination or a tax related issue.CB.10.4The System must not allow a protest/appeal to be created when the protesting/appealing party has not been adversely affected by the most recent determination on the monetary, nonmonetary or tax related issue.CB.10.5The System must be able to automatically create a 'timeliness' issue when a protest/appeal is not received within a configurable time period.B.10.6The System must allow staff to bypass the redetermination of a nonmonetary issue and process an appeal when all interested parties have consented to the bypass.CB.10.7The System must be able to electronically interface with the appeals division case management system to transmit the information and documents related to the appeal when an appeal is created.CB.10.8The System must provide the ability for staff to manually enter/update/view/delete a protest/appeal.CB.10.9The System must provide the ability for staff to add an additional issue to an appeal. CB.10.10The System must be able to automatically generate a notice of appeals hearing to all interested parties. CB.10.11The System must allow staff to enter/update an advocacy case (to provide claimant representation for an appeal hearing)CB.10.12The System must allow staff to enter/update advocate profile and status information including demographic, employment, and contract information.CB.10.13The System must be able to automatically establish a level of service for the advocacy case and allow staff to override the level of service.CB.10.14The System must be able to automatically generate an informational packet for the claimant including a description of eligible services and list of advocates when an advocacy case is created.CB.10.15The System must allow staff to designate an advocate to an advocacy case.CB.10.16The System must be able to automatically add the designated advocate as an interested party to the appeal.CB.10.17The System must be able to automatically generate the information and documents related to the appeal to the designated advocate.CB.10.18The System must be able to process each of the appeal request types; ALJ hearing, ALJ rehearing, Board of Review, Appeal to Circuit Court.CB.10.19The System must track appeals to include how many are received; how many are completed; how many are outstanding; types of appeals requested; time to complete each appeal; how many were affirmed, no further action or reversed; the reason of the appeal. This tracking should be for Director’s Reconsidered Decisions as well as UCRC and court level appeals.CB.10.20If an account is under appeal and active, the system must automatically flag the account as do not deactivate and do not certify any debt.CB.10.21Once the appeal flag is removed, the system must automatically remove the do not deactivate flag.CB.10.22If any status work/refund is completed on an account that is under appeal, the system must provide a warning message to staff processing the work that the account is under appeal.CB.10.23The System must allow an appeal to be introduced to another queue as a work item. Example would be a waiver that is received as an appeal. The waiver would be removed as an appeal work item and introduced as a waiver work item.CB.10.24Do not have character restrictions on names and email addresses.C9. Table C: Unemployment Benefit Business Requirements Scoring definitions: C is a critical component of the system. D is a desirable component of the system.Benefits FunctionalityScoringOfferor ResponseCheck Applicable BoxNarrativeCore CapabilityConfiguration OptionRequires DevelopmentC.1 Initial ClaimsC.1.1The System must collect enough information (SSN, DOB, etc.) to confirm a claimant's identity real time when filing a new UI initial claim (e.g. after claim is certified, use UIQ to verify identity).CC.1.2The System must allow the filing of UI initial claims in an agent (staff), employer filed, and self-service capacity. CC.1.3The System must automatically identify and establish the type of claim that must be filed (e.g. New Claim, Additional Claim, Reopened Claim, Transitional Claim, Extended Benefits (state or federal), TRA, STC, and DUA). CC.1.4If a claimant has an existing benefit year, and benefits are remaining, determine reason for break in claim .1.5The System must automatically provide specific information to the claimant regarding why an unemployment claim cannot be filed. (E.g. claimant already has an existing benefit year with zero balance and no extensions are available). CC.1.6The System must provide the ability for staff to request (and display) an on-line pre-monetary determination prior to the UI claims filing process to estimate potential benefit entitlement. CC.1.7The System must provide the ability for claimants to request (and display) an on-line pre-monetary determination prior to the unemployment claims filing process to estimate potential benefit entitlement.DC.1.8The System must dynamically display information and perform data capture and edits/validations based on the type of user filing the claim. CC.1.9The System must dynamically display data entry screens based on the claim type and program under which the UI claim is filed. CC.1.10The System must dynamically collect information to establish the claim based on responses to questions asked during the claims filing process. CC.1.11The System must save partially-completed unemployment claims and allow the return for completion of such claim within 48 .1.12The System must allow staff to access partially completed applications (claims in progress). CC.1.13The System must require claimants to certify their claim .1.14The System must capture personal information that allows communication with the claimant (includes but is not limited to: address, contact information, communication preference (text, email, mail)).CC.1.15The System must collect demographic information. (E.g. Ethnicity, Race, Primary Language, Disability, Gender, Education level.)CC.1.16The System must electronically interface with external software (during the UI claims filing process) to validate address information. CC.1.17The System must collect Job information to allow job matching with State labor exchange system (e.g. electronically interface to collect occupational job codes).CC.1.18After claimant's identity is verified, the system must interface with State's labor exchange system to automatically register them for job matching .1.19The System must pay warrants, based upon claimant preference, through Electronic Funds Transfer (EFT) or Debit Card. Paper warrants should be an exception to allow timely .1.20The System must collect all information needed to establish claim type, program of filing, and potential eligibility for benefits (monetary and non-monetary). CC.1.21The System must collect information to establish a claim for unemployment benefits using non-Ohio employment wages. (i.e., Military (UCX), Federal (UCFE), Out-of-State (CWC)) C C.1.22The System must automatically process and electronically transmit interstate unemployment claims where Ohio acts as an agent on behalf of the paying state. CC.1.23The System must automatically process and electronically transmit interstate unemployment claims where Ohio acts as the liable state. CC.1.24The System must automatically set the effective date of a UI claim. CC.1.25The System must allow staff the ability to back date an application for .1.26System must allow staff to reference Withdraw Initial Claim (WIC) functionality, where .1.27The System must automatically assign a claim designation based on source of wages (federal employment, military service, out-of-state or Ohio employment) attached to the unemployment claim (i.e. UCX, UCFE-UCX, Ohio-UCX, etc.). CC.1.28The System must initiate an electronic request to Interstate Connection system (ICON) to validate employment and receive information needed to establish a claim if there is military, federal or out-of-state employment on the UI claim. CC.1.29The System must provide the ability to electronic interface to the Interstate Benefits Inquiry (IBIQ) system to verify claimant wages earned in another state or the status of an unemployment claim filed in another state. CC.1.30The System must allow claimants and staff to attach an employer to a claim for benefits where there is no valid employer account number (employment added to an unemployment claims by claimants or staff.) CC.1.31The System must allow a liability assignment workload item to be created when an employer FEIN/employer account number is not detected in our .1.32The System must automatically create appropriate monetary/nonmonetary issue(s) identified during the claims filing .1.33The System must dynamically display fact finding questions specific to an opened issue (and circumstances attached to the issue) as part of the UI claims filing process. CC.1.34The System must automatically allocate a post-separation employment remuneration payment to a specific future time period. CC.1.35The System must send an Initial Claimant Booklet based upon communication preference identified (email or mail). CC.1.36The System must send a New Claim Instruction Sheet (NCIS) to the claimant after certifying their .1.37The NCIS must include claimant's work search instructions, continued claim filing date, general unemployment information, and required reemployment .1.38The System must track claimant re-employment activities. The status of which will be provided via the interface to the Ohio labor exchange .1.39The System must collect dependent information in the initial claim process that could affect monetary benefit .1.40The System must be capable to verify the identity of any dependents added to the .1.41The System must offer the ability to collect child support .1.42After the claim is certified, the system must interface with the State Child Support system to identify new, adjustments, and terminations of mandatory child support withholding .1.43The System must interface with the State Child Support system and accept adjustments to mandatory child support orders (i.e. terminations and adjustments).CC.1.44The System must allow the ability to identify a claim as a part of a mass .1.45After completing the initial claim filing process, the system must assign a work search designation for the .1.46The System must provide staff the ability to assign work search designations (e.g. extended work search waiver up to 26 weeks).CC.1.47The System must provide a robust search capability when claimants/staff are identifying separating employers in the claim .1.48The System must make wage record and prior separating employers available for staff and claimants when identifying a separating employer for the claim in .1.49The System must obtain detailed information for the separating employer identified (e.g. Employer Name, Address, Dates worked, reason for separation, worked at least 6 weeks and earned a minimum amount of money). CC.1.50For any separating employment identified in the claim process, a request for separation information must be sent to the employer (except for mass layoffs).CC.1.51If an employer or Third-Party Administrator (TPA) is set up for SIDES/SIDES E, the system must interface with SIDES/SIDES-E to process Requests for Separation Information submitted by .1.52The System must allow a claimant to designate whether to withhold 10% for Federal Income Tax Reporting .1.53For statistical reporting, the system must identify all claims with a Claim Program (UI, TRA, EB, DUA, etc.); Claim Type (Regular UI, UCX, UCFE, CWC, etc.); and an Application Type (Initial Claim, Additional Claim, Reopen Claim, etc.).CC.1.54The System must maintain a history of all claimant personal .1.55The System must maintain a copy of certified applications for future reference by .1.56The System must identify Seasonal, Educational and Professional Athlete .1.57The System must allow staff to withdraw claims for benefits and notify interested parties in .1.58The System must determine if the claimant is a commuter to determine the type of claim being .2 MonetaryC.2.1The System must automatically calculate benefit entitlement for all submitted claims for UI benefits. CC.2.2The System must account for Ohio's specific monetary entitlement rules in base period (e.g. work minimum of 20 and average weekly wage at least 27.5% of SAWW).CC.2.3The System must automatically establish the base period within which wages and weeks will be used to calculate monetary entitlement on a claim (base period is first 4 of last 5 completed quarters).CC.2.4If monetary entitlement is unable to be obtained in the base period, the system must automatically switch to the alternate base period to calculate monetary entitlement (Alternate base period is last 4 most recent completed quarters).CC.2.5The System must automatically calculate monetary entitlement based on usable base period wages (usable wages are allowable wages for any part of a benefit year).CC.2.6The System must identify and exclude from the monetary calculation any weeks and wages from an employer where the separation from that employer was due to .2.7The System must automatically exclude wages being used to establish entitlement on a claim if those wages were previously used to establish any claim for UI benefits (either in Ohio or transferred for use in another state). CC.2.8The System must accept ICON Interface information to assist in determining eligibility for Claim(s) in Ohio, other states, and jurisdictions (e.g., non-monetary claim issues, claiming in another state; working in another state and other issues as defined).CC.2.9The System must automatically calculate and add a dependency allowance to the calculated weekly entitlement. CC.2.10The System must automatically calculate the potential employer charge for all base period claim employers. CC.2.11The System must automatically calculate monetary entitlement and employer chargeability for Federal and State extended benefit .2.12The System must automatically calculate monetary entitlement and employer chargeability for Short Term Compensation and Trade .2.13The System must automatically generate a monetary determination to the claimant, the separating employer and all based period .2.14The System must recognize that all 6X6 employers have a non- disqualifying separation before the monetary can be released and the claim is considered valid. CC.2.15The System must automatically deny monetary entitlement if any separation in the initial claim is .2.16The System must automatically recalculate monetary entitlement and employer chargeability when certain claim information is changed (examples: wages, weeks, employer account number, dependency). CC.2.17The System must automatically recalculate monetary entitlement and employer chargeability when wages have been removed from the claim due to a wage exclusion nonmonetary .2.18The System must automatically recalculate monetary entitlement and employer chargeability when the effective date of a claim is modified which results in a change to the base period. CC.2.19The System must automatically recalculate monetary entitlement and employer chargeability if the separation is determined/re-determined/.2.20The System must automatically recalculate the monetary entitlement and employer chargeability when a claim is withdrawn. CC.2.21The System must automatically associate a redetermination with the original monetary determination. CC.2.22The System must notify the transferring state when a claim is withdrawn and there are out-of-state wages transferred for use on the claim. CC.2.23The System must address any open issues associated with a claim when a monetary determination results in the denial of a claim. These issues need to be available to be reestablished if the decision is .2.24The System must automatically charge the State's Mutual Account when an employer is relieved of charges/liability due to a non-charge situation. CC.2.25The System must automatically relieve charges on a subsequent claim for any wages earned during the period of employment for which the employer was granted relief from benefit charges. CC.2.26The System must automatically generate a Trade Readjustment Assistance (TRA) monetary determination when the system determines the claimant is eligible for TRA and there is no remaining entitlement for benefits under any other program. CC.2.27The System must automatically associate the TRA claim with an existing UI claim and calculate the TRA entitlement based on the most recent monetary determination under the regular UI program entitlement that contains the original qualifying separation. CC.2.28The System must automatically generate a monetary determination for additional TRA entitlement upon training contract and exhaustion/expiration of basic TRA benefit entitlement. CC.2.29The System must automatically generate a TRA monetary re-determination when a change is made to a TRA claim or an associated UI monetary determination (examples: changes to the effective date, number of weeks entitlement). CC.2.30The System must automatically generate an additional TRA monetary (completion and remedial if applicable) re-determination when a change is made to an associated training contract (e.g. changes to weeks of entitlement).CC.2.31The System must automatically calculate claimant entitlement and employer chargeability for Disaster Unemployment Insurance (DUA) claims and generate a monetary determination. CC.2.32The System must account for special monetary rules for seasonal, educational, and professional athlete .2.33If the system determines while taking the application that the claimant is monetarily ineligible, both in regular and alternate, then monetary affidavit information must be obtained from the claimant and/or .2.34The System must not release a monetary until issues and work items associated to the initial claim are adjudicated, including any pending .2.35The System must automatically raise an intervening employment eligibility issue if the system detects it hasn't been .2.36After the claim is certified, the system must provide the ability for staff to add employment/wage information to the claim when there is missing base period or separating employer employment and/or wage information. CC.2.37When a monetary correction occurs, the system must generate a determination and include any applicable .2.38The System must establish and utilize military pay grade information (as provided by the Department of Labor) to assist with Unemployment Compensation for Ex-Military Personnel (UCX) monetary .2.39The System must automatically request and retrieve wages that aren't reportable in the state of Ohio to set up Combined Wage and Unemployment Compensation for Federal Civilian Employees (UCFE) .3 Employer Charging C.3.1The System must identify contributory employers and reimbursing .3.2The System must ensure that each claim that is payable must have a chargeable account(s) associated to it. This will include, but is not limited to, all entities responsible for benefits paid for the claim, including UI/STC (reimbursing/contributory/mutual account), CWC transferring states, the UCX account, the UCFE account, TRA/TAA/RTAA accounts, Federal Extended Benefits, State Extended Benefits (EB) accounts and Disaster Unemployment (DUA) .3.3The System must associate employer account(s) to the claim in a proportionate manner based upon wages established in the monetary. CC.3.4The System must automatically recalculate the amount to be charged for all base period and separating employers for each benefit payment based on a monetary recalculation or redetermination. CC.3.5The System must relieve (credit/mutualize) an employer contributory account of benefit charges. CC.3.6The System must automatically charge the employer's liability percentage to the non-chargeable benefits account (Mutual Account) when the employer is found non-chargeable on a claim for benefits. CC.3.7The System must automatically calculate and apply charges and/or credits to the employer accounts or the non-chargeable benefits account (Mutual Account) when a benefit payment is adjusted. CC.3.8The System will debit and credit Benefit Charging Accounts when certain events occur. (e.g., Payments, Appeals, Redeterminations, Issue Resolution, Overpayments, Collections, Employer Penalty and others as defined).CC.3.9The System must mutualize charges for a reimbursing employer account if court-.3.10The System must identify a disqualifying issue that was previously adjudicated in a prior benefit year. (This is the application of the Morrison decision. An adjudicated decision making an employer either chargeable or non-chargeable must carry over the next claim if it is based on the same separation decision.)CC.3.11The System must track the detail of charges and/or credits for the amount of the charge/credit that was associated with the payment disbursements for a given week ending date, including waiting .3.12The System must determine whether an Ohio employer is chargeable for a claim being paid by another state. Ohio employers are only charged if the individual would have been eligible to receive benefits in Ohio. If a claimant could not have qualified separately in Ohio, the system must compute liability to the mutualized .3.13The System will bill other states for Combined Wage Claim(s) paid in .3.14The System must calculate the potential liability to the Federal account in the same manner as for state wages if UCFE or UCX wages were transferred and used. (Note: UCFE and UCX wages transferred from another state are not charged to the transferring state but are charged directly to the federal account.)CC.3.15On a monthly basis, the system must calculate and notify the amount owed by reimbursable employer(s).CC.3.16The System must automatically apply benefit charges and/or credits for non-reimbursing employers to a suspense account when benefit charges and/or credits are in dispute. CC.3.17The System must automatically apply suspended benefit charges and/or credits to the employer account when the determination affecting the employer's chargeability is final. If the employer is not chargeable, then mutual account must be .3.18For UI tax purposes, the tax area must be informed yearly of the charges, as well as the charges held in .3.19The System must automatically reassign and reallocate benefit charges and/or credits as a result of a full, partial, or multiple employer account succession (transfer of business to a new owner). CC.3.20The System must automatically reassign and reallocate benefit charges when a succession of an employer’s account is reversed or otherwise cancelled (transfer of business to a new owner). CC.3.21The System must automatically generate a weekly record of charges and/or credits for benefits paid against an employer account. CC.3.22The System must automatically generate a monthly record of charges and/or credits for benefits paid against an employer account. CC.3.23The System must automatically generate a quarterly record of charges and/or credits for benefits paid against an employer account. CC.3.24The System will sort and filter benefit charging information (e.g., Employer, Benefit Year, Monetary, and others as specified).CC.3.25The System must provide notices to employers of the benefits charged to the employer’s account since the last preceding notice. (Currently done monthly or quarterly depending on type of employer.)CC.3.26When a week is overpaid, the system must immediately credit any contributory Ohio employer accounts. The mutual account must be charged in place of the contributory .3.27Apply cash repayment to reimbursable employer account, including out of state and federal accounts, when payment is received. (Repayments are applied to the Mutual Account for contributory employers.)CC.3.28For fraud and non-fraud overpayment determinations, the system must wait to credit any reimbursing Ohio employer accounts until repayment/offset is .3.29The System must calculate/generate/make available a fund reconciliation report for UI Tax that shows the total dollar amount of activity that occurred in the mutual .3.30The System must account for the prohibition of noncharging (employer penalty) when a pattern of untimeliness/inadequacy is established for responding to requests for separation .3.31The System must have the ability to credit an employer and charge the mutual account when a BWC reimbursement payment is received for a specific claimant, amount, and time .3.32The System must have the ability to credit the mutual account when a BWC repayment can't be credited to an .4 Benefits ProcessingC.4.1The System must provide a method for filing continued claims for the following program; Ohio UI (including all sub-types), State EB, UCX, UCFE, DUA, interstate, TRA, STC, R/ATAA, SharedWork, and federal extension .4.2The System must provide the ability for claimants or staff to file weekly continued claims for benefits by various methods including web and mobile responsive .4.3The System must provide the ability for claimants or staff to certify for multiple weeks during a certification session (i.e. backdating a claim, retroactive eligibility and extended benefits). CC.4.4The System must automatically create a nonmonetary issue when the weeks being claimed are untimely during the certification process. CC.4.5The System must automatically create a nonmonetary issue when the weeks being claimed result in a break in .4.6The System must create a nonmonetary issue when a continued claim week with reported earnings is immediately followed by a week being claimed with of no reported earnings, or a week claimed with reported earnings exceeding the WBA is immediately followed by a week with reported earnings that are less than the .4.7The System must consider a claimant to be in registration for a period of 3 calendar weeks following a claim application (additional, initial and reopen) or a continued claim is filed. Any period of non-registration that exceeds 3 weeks where the claimant didn't re-register with an application, a break in claim must be .4.8If there is a break in the claim series, the system must prevent payment until the issue is .4.9The System must be able to display questions related to other military-sponsored programs that are required for certification of benefits based on criteria such as work search assignment, claim program type and military status. CC.4.10The System must allow for a weekly claiming cycle. CC.4.11The System must ensure that a continued week ending date is within the benefit year for it to be claimed. Exceptions are for other programs (not all inclusive) such as Federal extensions and TRA/.4.12The System must provide the ability for claimants or staff to record a return to full-time employment date during the certification process. If a week is claimed subsequent to this date and an additional claim doesn't exist, the system must create an eligibility issue.DC.4.13If claimant is required to search for work, the system must capture evidence/documentation of the claimant’s work search activities.DC.4.14The System must provide the ability for claimants or staff to enter remuneration payments attached to a week for which the claimant is certifying for benefits (earnings or holiday pay).CC.4.15The System must identify if claimant quit, refused an offer of work, or was discharged from employment during the week being .4.16The System must automatically create an issue based on the responses to the questions answered during the continued claim filing processCC.4.17The System must automatically create an issue when a claimant is certifying for benefits under the TRA program if the claimant is not enrolled in training and there is no valid training waiver for the certified week(s). CC.4.18The System must automatically create an issue when a claimant is certifying for benefits under the additional TRA, including completion TRA program and the weeks being claimed fall within an extended school break period greater than 30 days. CC.4.19The System must automatically prompt claimants or staff to certify responses to continued claim questions prior to final submission during the weekly claim process. CC.4.20The System must provide the ability for claimants or staff to respond to questions specific to an opened issue (and circumstances attached to the issue) as part of the weekly claim process. CC.4.21The System must automatically establish the new (transitional) claim for benefits when the benefit year has ended with the current weekly claim. DC.4.22The System must automatically notify the claimant to file a claim for extended benefits (State or Federal) provided an extension is available. D?C.4.23The System must automatically establish a new claim for benefits, in a quarter change situation, when a claimant can establish eligibility for regular state UI payments when filing under an extended benefit program. D?C.4.24The System must prevent issuance of a benefit payment if a waiting week has yet to be served. CC.4.25The System must not prevent payment if a continued claim issue isn't adjudicated within a defined number of business .4.26The System must automatically sequence benefit entitlement for a claimant based on a monetary program hierarchy. CC.4.27The System must only issue a benefit payment if there is an entitlement balance on the payable monetary determination. CC.4.28The System must automatically calculate the net benefit payment for the certified week, reducing the claimant's weekly benefit amount by any deductible income attached to the payable week (example: severance pay). CC.4.29The System must capture types of deductible income and process different allocation .4.30The System must automatically calculate the net benefit payment for the certified week, reducing the claimant's weekly benefit amount by earnings received (after applying 20% earnings exemption).CC.4.31The System must account for a different earnings exemption under the TRA program if the individual is in full-time training and earnings are less than the UI Weekly Benefit Amount that established .4.32The System must prevent payment if deductible income and earnings exceed the weekly benefit .4.33The System must automatically reduce the net benefit payment by all other deductions/disbursements attached to the claimant (i.e. Federal Income Tax withholding of 10%, child support withholding).CC.4.34The System must automatically generate a benefit payment when an issue is closed and the claimant is found not disqualified or not ineligible and there are no other holds on the weeks payable. CC.4.35The System must automatically remit a benefit payment using the payment method selected by the claimant. CC.4.36The System must automatically recalculate a benefit payment when there is a change to any variable used to calculate .4.37The System must automatically issue a benefit payment adjustment for a week found to be underpaid, if the week is otherwise payable. CC.4.38The System must allow the payment of retroactive benefits for .4.39The System must process pay adjustments to given continued weeks for various reasons, such as, nonmonetary favorable/unfavorable decisions and overpayment repayment .4.40The System must remit payment of funds withheld from benefit payments (i.e. child support.) CC.4.41The System must calculate the total amount of child support to deduct from the Gross Amount Payable (GAP) and ensure that it does not exceed 50% of the .4.42The System must use continued weeks to offset an outstanding principal overpayment balance. CC.4.43The System must use a payable continued week to serve a penalty week resulting from a fraud overpayment. An Ohio overpayment principal balance must be repaid prior to serving a penalty week. Further, the system must offset overpayments and credit penalty weeks during the same week if the amount offset is less than the GAP for that week. CC.4.44If the claimant has elected to have federal taxes withheld, the system must reduce the remaining amount carried forward after reducing the GAP by overpayments (Ohio and Interstate) by 10%. CC.4.45For each week payable, the system must ensure that the weekly benefit amount does not exceed the balance of Total Benefits Payable (TBP).CC.4.46For each week in which a benefit payment is issued, including payments that are offset, the system must deduct the GAP from the Total Benefits Payable (TBP).CC.4.47The System must pay claims for the following programs; Ohio UI (including all sub-type), State EB, UCX, UCFE, DUA, interstate, SharedWork Ohio (Ohio’s version of the federal Short Time Compensation or STC program), TRA, Federal Additional Compensation (FAC), R/ATAA, and any federal extension .4.48The System must automatically generate an Automated Clearing House (ACH) file containing the benefit payment information (examples: claimant information, account information, amount of the payment and payment method) for each certified week to disburse payment via direct deposit. CC.4.49The System must facilitate the payment of benefits through a debit card. This will necessitate the production of electronic interfaces files containing claimant benefit data for debit card .4.50The System must process failed EFTs and notices of .4.51The System must allow for both automated (warrant expires) and manual (lost, damaged, etc.) cancellation of paper .4.52The System must allow for paper warrants to be .4.53The System must allow payments to be issued with no connection to a claimant’s eligibility amount for a given week. E.g. Overpayment Credit balance .4.54The System must move a weekly continued claim from one benefit year to another benefit .5 Non-Monetary AppealsC.5.1The System must establish issues automatically and on demand by staff .5.2The System must allow users to establish potential issues affecting future weeks not yet claimed by the .5.3The System must determine type of non-monetary eligibility issue (separation or non-separation) .5.4The System must identify the detection date of the non-monetary eligibility .5.5The System must capture/determine the duration of the issue by establishing start and end dates. If there is an indefinite disqualification, the end date is .5.6The System must identify and associate any employers to non-monetary .5.7The System must generate requests for information to claimants, employers, TPAs, and other interested .5.8For each non-monetary separation issue, the system must establish the time period for response to requests for .5.9The System must automatically generate a fact-finding questionnaire(s) to claimants for issues opened as part of the claims filing or certification processes, with questions specific to any issue that was created during the claims filing/certification process. CC.5.10The System must allow staff to trigger the generation of fact finding questionnaires independent of system .5.11The System must allow staff to customize fact-finding .5.12The System must be capable to facilitate and document fact finding .5.13The System must document attempts to obtain information from a claimant, employer or other interested party, including rebuttal .5.14The System must provide a workflow for the adjudication of non-monetary .5.15The System must auto-adjudicate particular issue types without staff intervention (system auto-adjudication). CC.5.16The System must automatically set and track the adjudication level for newly-opened issues. Levels include initial, redetermination, appeals and UC Review Commission (UCRC hearings). In addition, the court levels must be accounted for in the .5.17The System must allow data capture of fact-finding responses done in real time or scanned into the system when mail is returned. The fact finding must be captured and associated to the appropriate non-monetary issue. CC.5.18The System must allow staff to enter and attach rebuttal/follow-up responses to the non-monetary .5.20The System must prompt adjudicator to document rebuttal information, or to document that rebuttal information was not required to render a .5.21The System must maintain the status (e.g. open, closed) of the non-monetary issue. CC.5.22The System must indicate and maintain the decision status of non-monetary issues. CC.5.23The System must associate requalification requirements for specific types of non-monetary .5.24The System must track and determine if requalification requirements for lifting a previously-imposed disqualification have or have not been .5.25The System must provide non-monetary policy assistance during the adjudication process.DC.5.26After a determination has been issued but prior to the expiration of the appeal period or the filing of an appeal, system must allow user to vacate a .5.27After a determination is issued and if no appeal has been filed, the system must allow a user to correct a .5.28The System must produce an initial claim determination that includes both the monetary and the separation. The initial claim determination must have these two components if the individual is monetarily .5.29The System must automatically generate a nonmonetary determination to all interested parties attached to the non-monetary issue. CC.5.30The System must be capable of bundling multiple nonmonetary decisions into the same .5.31The System must identify when non-monetary issues require a tally according to Department of Labor .5.32The System must automatically capture appeals in the system at all levels of .5.33The System must only allow interested parties to the particular determination to have the ability to appeal it and provide supporting .5.34The System must provide the ability for staff to manually enter/update/view/withdraw an appeal. CC.5.35The System must process appeals at various adjudication levels, including initial, redetermination, appeals, UCRC, and appeals to .5.36The System must capture particular appeal information such as date appeal received, reason for appeal, appealing party, date of filing (postmark or metered mail), and level of appeal. CC.5.37The System must create a nonmonetary issue if appeals have been filed untimely based upon a configurable time .5.38The System must notify interested parties that an appeal has been .5.39The System must allow for appeals to be remanded to a lower .5.40The System must provide staff the ability to generate earnings eligibility notices that includes the week(s) claimed.DC.5.41For non-monetary issues that involve a claimant that used to work for the Ohio Department of Job and Family Services (ODJFS), the claimant's claim must be flagged so it can be handled by an objective .5.42The System must capture, for a specific business location, a mass layoff's general information and create non-monetary issues after associated claimants file for .5.43The System must process benefit decisions associated to labor disputes (strikes/lockouts).CC.5.44The System must determine if a labor dispute involves more than 25 individuals, if so, a hearing must be .5.45System must allow a user to associate and disassociate claimants with labor .5.46Once a decision is rendered, the system must apply the same labor dispute determination to all similarly-situated .5.47The System must process (add/adjudicate) multi-claimant .5.48The System must issue vital documents in languages other than English, as specified by the .6 Overpayment/Repayment C.6.1If a determination is unfavorable to a claimant and weeks have been previously paid, the system must establish an .6.2For every overpayment, the system must issue a .6.3When an overpayment is established (except where repayment is not required), the system must add the amount of the overpayment back into to the claimant’s Total Benefits Payable balance (TBP).CC.6.4If a waiting week was served, and a determination is unfavorable, the system must cancel the waiting week and a subsequent compensable week becomes a waiting .6.5The System must allow overpayments to be created with no connection to a claimant’s eligibility amount for a given week. (For example, out of state overpayments.)CC.6.6The System must be capable of notifying paying states requesting the recoupment of an Ohio established .6.7The System must capture the method of detection for the overpayment established. CC.6.8The System must capture the cause for the overpayment established. (e.g. state agency error, claimant error, reversals, other, etc.)CC.6.9For each overpaid week ruled fraud, claimant must serve and be ineligible for two otherwise valid weekly claims for benefits (penalty weeks).CC.6.10The System must apply Ohio's statute of limitations to penalty week and .6.11The System must apply a penalty week first in first out with respect to the statute of limitation .6.12For fraud determinations under any of the benefit programs, the system must establish an additional fraud monetary penalty and allow for allocation between funds based upon current .6.13The System must assess interest on fraud .6.14The System must account for the repayment of interest to be applied to funds based upon state and federal .6.15The System must allow for the waiver of interest. CC.6.16The System must capture any court costs/collection costs and add them to an .6.17The System must maintain an order of precedence for offsets in regard to waiting and penalty weeks. CC.6.28The System must certify any overpayment balances to the Ohio Attorney General's (AG) Office for collection after a prescribed number of .6.29The System must process and track repayment transactions from the AG's Office and reduce overpayment .6.30The System must be capable to process and secure Federal Tax Information (FTI) to allow Ohio to participate in the Treasury Offset Program (TOP).CC.6.31The System must allow staff to refer potential fraud cases for prosecution and track outcomes of .6.32The System must capture receipt of court orders, such as court- ordered restitution and bankruptcy .6.33For court-ordered restitution, the system must track the claimant’s progress in adhering to the court ruling in regards to repaying the overpayment. CC.6.34The System must capture the receipt of the repayment and document the type (e.g. Cash, Check, State Tax Offset, and Federal Tax Offset) of repayment .6.35The System must associate offsets, repayments, NSF transactions to overpayments so that staff understand how overpayments were reduced/increased and how the reimbursement was .6.36The System must maintain an order of precedence for applying benefit offsets to overpayment .6.37The System must maintain an order of precedence for applying repayments to overpayment .6.39The System must allow a staff user to manually override the default hierarchy for applying cash repayments to overpaymentsCC.6.40The System must allow repayments to be accepted and applied to overpayments even after statute of limitation on overpayment collection has expired. CC.6.41The System must track anonymous overpayment repayments and apply credit to the mutual account fundCC.6.42If overpayment repayment is rejected/corrected, the system must capture reason for rejection/correction and adjust overpayment balance .6.43The System must allow a user to waive repayment of an overpayment and the remaining monetary entitlement balance of the paying program must not be increased by the amount of principal .6.44The System must allow a user to issue a credit balance refund check to a .6.45The System must allow for cross program .6.46The System must offset at 100% of any amounts payable except if the overpayment originated under other programs that require a different percentage of .6.47The System must routinely notify claimants of their non-AG certified overpayment balances (such as penalty weeks, principal, penalty, etc.).DC.7 Miscellaneous C.7.1The System must allow staff to view and update identification information attached to the claimant's profile. Information includes Name, SSN, Driver's License, State ID, and birth date. CC.7.2The System must allow staff to view and update contact information within the claimant profile. Information includes address, multiple phone numbers, e-mail address, preferred method of communication. CC.7.3The System must allow staff to view outgoing and incoming correspondence attached to the claimant/claim. CC.7.4The System must interface with the State printing agency for all correspondence mailed to claimants and .7.5The System must automatically update all instances of the old SSN with the new SSN in the system when an SSN is updated. CC.7.6The System must allow staff to view and update demographic information within the claimant profile. Information includes citizenship, gender, race, ethnicity, education level, disability, primary language, and occupational code. CC.7.7The System must allow staff to view and update federal income tax withholding information within the claimant profile. CC.7.8The System must allow staff to view the detailed information attached to a nonmonetary issue/determination. Information includes issue type, detection date, start/end dates, decision code, fact finding, contact attempts, status, tally indicator, adjudicator, etc. CC.7.9ODJFS staff must have the ability to manually trigger/retrigger fact finding to be sent to claimant, employer, or .7.10ODJFS staff must have the ability to manually trigger/retrigger rebuttal notices to be sent to claimant, employer, or .7.11The System must allow staff to view the detail of certified continued week applications including all information requested of the claimant at the time of filing the continued week .7.12The System must allow staff to view payment history of continued weeks paid if an overpayment or adjustment exists and provide a side by side comparison. CC.7.13The System must automatically create issues based on claimant responses for eligibility questions on a certified continued claim application. CC.7.14The System must allow staff to make updates to claimant reported earnings on a certified week. CC.7.15The System must allow staff to enter fact finding responses online when changes are made to claimant responses/earnings for a certified week resulting in the creation of an issue. CC.7.16The System must allow staff to view the distribution of benefit charges and credits to employers (including those charged to the Non-chargeable Benefits Account) for each continued claim week, including any amount .7.17The System must allow staff to view the detail of each overpayment for the claimant, including overpayment status, week(s) overpaid, amount of overpayment, reason for overpayment, program under which overpayment occurred, statute of limitations and balances (Fraud, Non-Fraud, Fraud Penalty Trust Fund, Fraud Penalty SAF, Interest, Court Costs, Other penalties, and penalty week balances). CC.7.18The System must provide the ability for staff to view and update information related to the claimant’s benefit payment method. Information includes payment method, account number, routing number, and bank name. CC.7.19The System must electronically submit/receipt any new or modified information related to debit cards or electronic fund transfers to/from the benefits payment vendor. CC.7.20The System must score the likelihood that each new claim will exhaust their benefits. Note - this result will be used in selecting claimants to undergo reemployment services (a.k.a. profiling). CC.7.21The System must generate a list of claimants required to complete reemployment services. CC.7.22The System must track scheduling and completion of reemployment activities for individual .7.23The System must allow staff to update reemployment information within the claimant profile. CC.7.24The System must allow staff to access ICON transactional functionality, such as IBIQ, WIC, IB13, and Interstate Handbook. CC.7.25The System must allow staff to view, resend, add UCX/UCFE .7.26The System must allow staff to view, resend, add IB .7.27The System must allow staff to select a choice between a straight Ohio and Combined Wage Claim on behalf of the .7.28The System must process and produce the yearly federal 1099-G .7.29The System must allow staff to produce a 1099-G .7.30The System must allow staff to administer (add/modify/delete) notes to a claimant's or employer's .7.31The System must allow staff to view separation requests and responses that are processed through the SIDES .7.32The System must allow staff to process repayments to be applied to outstanding .7.33The System must allow staff to view/update DUA certification information. CC.7.34The System must allow staff to view/update information related to a DUA claimant/claim. CC.7.35The System must capture and establish presidentially-declared disaster information (i.e. disaster date, declaration date, disaster number, disaster type, counties affected).CC.7.36The System must capture disaster announcement date, as it is used to determine timeliness of .7.37The System must capture maximum duration of benefits for the declared .7.38The System must establish a disaster-specific benefits fund account for funding estimates and requesting advance of funds through .7.39The System must display fund balance (benefits paid subtracted from disaster-specific funds received from DOL).CC.7.40The System must provide staff the ability to maintain staff user profiles. (e.g. security role levels, etc.)CC.7.41The System must provide staff the ability to maintain (add, remove, modify) fact finding questions, determination text, and characteristics of issues by issue .7.42The System must interface with the Office of Workforce Development to provide data that will allow that office to determine potentially eligibility for the WOTC, WIO Youth, and other available .7.43The System must allow staff to search for, view and maintain external customer web accounts. CC.7.44The System must allow staff to view screens available to claimants/employers within the web portal. CC.7.45The System must allow staff to search by confirmation number for activities performed through the claim/employer web accounts. DC.7.46The System must provide the ability for staff to specify archive/purging rules according to retention policies. CC.7.47The System must display appropriate message(s) to the user when data does not meet the edit/validation requirements. CC.7.48The System must provide a historical reference of staff business activities. For example, identifying who filed an initial application on behalf of a claimant last .7.49The System must be able to maintain (create, update, activate/inactivate) system tables (such as case issues, users, hearing rooms, hearing locations etc.) by business users with the appropriate .8 AccountingC.8.1The System must compute, post, track and display total amount of payments issued by funding source for draw down. Funding sources include but are not limited to: Regular Ohio (including CWC and SWO), UCX, UCFE, EB, Federal EB. TRA, R/ATAA, TAA, Mutualized Account, and DUA. CC.8.2The System must accommodate additional funding .8.3The System must produce a report that lists all payments issued (paper, EFT, debit) ordered by its associated WAR/EFT/Debit .8.4The System must produce a report that lists all payments issued (paper, EFT, debit) by funding source ordered by its associated WAR/EFT/Debit .8.5The System must produce a report that lists all failed EFTs by fund source ordered by its EFT number with information detailing the type of failure (notice of change vs. failed transfer).CC.8.6The System must produce a daily report that summarizes warrant activity by funding source. Activity can include payments issued by method, reissued, canceled, and .8.7The System must produce a monthly report that summarizes warrant activity by funding source. Activity can include payments issued by method, reissued, canceled, and .8.8The System must allow staff to reissue a payment when an account has been credited for a lost/canceled .8.9The System must produce a report that lists all outstanding warrants for a given time period by funding .8.10The System must provide the ability for staff to have access to the amount of child support withheld during a given month by funding .8.11The System must provide the ability for staff to have access to the amount of child support withheld during a given day by .8.12The System must provide the ability for staff to have access to detail (fund, agency, amount, court order #, etc.) information of child support withheld during a given .8.13The System must provide the ability for staff to access the amount of IRS withheld during a given day by funding source with month to date totals .8.14The System must provide the ability for staff to have access to detail (information of IRS withheld) during a given .8.15The System must provide the ability for staff to access Ohio Attorney General (AG) repayment transactions that caused exceptions when attempted to be applied to .8.16The System must notify staff of claimant overpayment credit balances that need released back to the .8.17The System must provide staff a report, including a summary and detail, of all repayments/offsets, by source, and what funding source was reimbursed when repayment/offset was applied in the .8.18The System must provide staff a report that details warrant errors and .8.19The System must provide staff a report detailing the reversal of repayments/offsets on overpayments by fund/.8.20The System must allow staff to receive, track and manage unidentified (employer/claimant) payments. CC.9 Self ServiceC.9.1The System must provide the ability for customers to establish a secure online self-service account that allows them to conduct unemployment .9.2The System must provide the ability for claimants to access information and perform services (initial claim, additional claim, reopen claim, continued claim, etc.) related to their claim through a secure web portal. CC.9.3The System must dynamically display links within the claim portal based on the services which the claimant can perform. CC.9.4The System must provide the ability for claimants to view correspondence to which they are associated to within their claim portal. CC.9.5The System must provide claimants access to file a claim for benefits on all programs and extensions through a secure web portal. CC.9.6The System must provide the ability for claimants to view all claims filed, displaying high level identifying information. CC.9.7The System must provide the ability for claimants to view identification information within the claimant profile. Information includes Name, Driver’s License, State ID, and birth date. CC.9.8The System must provide the ability for claimants to enter/update/view contact information within the claimant profile. Information includes addresses, multiple phone numbers, e-mail address, preferred method of communication. CC.9.9The System must provide the ability for claimants to manually override the validation process when an address cannot be validated. CC.9.10The System must provide the ability for claimants to view certain demographic information within the claimant profile. Information includes citizenship, gender, race, education level, and occupational code. CC.9.11The System must provide the ability for claimants to view and update tax withholding information through the claim .9.12The System must provide the ability for claimants to drill down to view the detail claim information for any claims filed. Information includes BYB, BYE, WBA, TBP, Balance, and overpayment/PW balances.DC.9.13The System must provide the ability for claimants to view a history of all monetary determinations attached to a claim. The view of the history will include the program, effective date, end date and date created. CC.9.14The System must provide the ability for claimants to view employer/employment information, reported wages and wages used to calculate the monetary determination separately. DC.9.15The System must provide the ability for claimants to view separation information. Information includes last day worked, separation date, and separation reason. DC.9.16The System must provide the ability for claimants to view the detailed information attached to nonmonetary including: issue, fact finding code, issue date and status. DC.9.17The System must provide the ability for claimants to view all continued claim applications and payments for any claim. DC.9.18The System must provide the ability for claimants to view the detail and status of certified .9.19The System must allow claimants and employers ability to respond online to all fact-finding .9.20The System must allow employers to respond online to requests for separation .9.21The System must provide the ability for claimants to make same day updates to claimant responses for eligibility questions on a certified continued week. Need to retain all information presented in history .9.22The System must provide the ability for claimants to enter fact finding responses online when a change to the claimant responses for eligibility questions on a certified week results in the creation of an issue. CC.9.23The System must provide the ability for claimants to make updates to claimant reported earnings on a certified week. Need to retain all information presented in history logging. DC.9.24The System must provide the ability for claimants to enter fact finding responses to an issue created as a result of updates to earnings for a paid week. DC.9.25The System must provide the ability for claimants to view all overpayments for a claim. CC.9.26The System must provide the ability for claimants to view all offsets and repayments applied to overpayments on a claim. CC.9.27The System must provide the ability to claimants, employers, and TPAs to file appeals against .9.28The System must provide the ability for claimants to submit supporting documentation tied to fact finding requests, contact attempts, and/or filing of .9.29The System must provide the ability for employers/TPAs to submit supporting documentation tied to fact finding requests, requests for separation information, and/or filing of .9.30The System must provide the ability for customers to view responses entered to fact finding questions, even after certification. DC.9.31The System must provide the ability for claimants to view 1099 G correspondence and ability to opt in/out, and retain history of changes, for only electronic delivery of the .9.32The System must provide a secure ability for claimants to view and update information related to the Claimant’s benefit payment method. Information includes payment method, account number, routing number, and bank name. CC.9.33The System must allow a Third-Party Administrator (TPA) to conduct business online for an employer for business .9.34The System must allow employers and TPAs to review benefit charge statements in different filters such as by week/month or social security .9.35The System must allow employers and TPAs to download benefit charge statements and/or sub-pay .9.36The System must allow employers and TPAs to administer their web user profiles for their online benefit .9.37The System must allow employers to manage and administer SharedWork Ohio (SWO) plans in their self-service account, including filing plans, modifying plans, and filing weekly applications for .9.38The System must interface with State Information Data Exchange System (SIDES) to allow employers and TPAs to respond to Requests for Separation Information via web services and SIDES-E .9.39The System must capture customer specific information (e.g. demographics, contact) to be associated to an external customer .9.40The System must generate a confirmation number to external customers when a transaction is successfully submitted through the web portal. CC.9.41The System must provide the ability for external customers to maintain information and permissions associated with their web account. CC.9.42The System must provide the ability for external customers to reset the password/username associated with their web account. CC.9.43The self-service Benefits functionality must be extended when a claim is appealable to the lower authority appeal level (or higher).CC.9.44The System must allow an appeal of a lower authority appeal decision to be filed when .9.46The System must allow a request for an appeal to be withdrawn (if the user is an appellant) to be submitted when .9.47The System must allow a request for a dismissal of an appeal to be vacated (if the user is an appellant) to be submitted when appropriate. CC.9.48The System must allow a request for a subpoena to be submitted when .9.49The System must display basic information related to the appeal (such as hearing location, date and time).CC.9.50The System must allow selected correspondence (such as decisions, hearing notice etc.) to be .9.51The System must allow a request for a file copy to be submitted when .9.52The System must allow a hearing participant to register for their .10Quality AssuranceC.10.1The System must allow staff to create quality assurance cases for Benefits Accuracy Management (BAM), Benefits Timeliness Quality (BTQ), State Unemployment Tax Act (SUTA) and Tax Performance System (TPS) based on specified criteria. CC.10.2The System must provide a weekly random sample for each of the four different types of claims to be investigated by staff in the Benefit Accuracy Measurement (BAM) .10.3The System must cross-match the BAM paid case sample with the National Directory of New Hires (NDNH) and provide a report to .10.4The System must allow staff to manually adjust the DOL random number and sample size for each BAM batch .10.5The System must electronically transmit a file of BAM cases selected for assessment to the USDOL Federal SUN System. CC.10.6Each quarter, the system must randomly select separation and non-separation issues that were initially determined for Benefit Timeliness Quality (BTQ) .10.7The System must provide a population of employer accounts that were chargeable in a given year so samples can be pulled for employer charging TPS .10.8The System must produce a cross match report that identifies EFT account numbers utilized by multiple .10.9The System must produce a cross-match report that identifies potential fictitious employer schemes.DC.10.10The System must crossmatch benefit payments against the UI Quarterly Wage data. CC.10.11The System must automatically generate forms to employers and/or claimants soliciting information to validate a cross match .10.12The System must crossmatch benefit applications with overlapping incarceration .10.13The System must display the information that is a result of the internal cross match used to identify situations where benefits payments are being issued to multiple claimants with the same mailing .10.14The System must crossmatch benefit payments against the National Directory of New Hires for wages/dates of hire and create a non-monetary issue for adjudication. CC.10.15The System must crossmatch benefit payments against the State Directory of New Hires and create a non-monetary issue for adjudication. CC.10.16The System must crossmatch Interstate Billing (through ICON) with claimants who have outstanding overpayments who may have relocated to another state. CC.10.17The System must crossmatch benefit payments against the State agency payroll system. CC.10.18The System must allow staff to refer potential fraud cases for investigation. CC.10.19The System must crossmatch benefit payments with certain types of Benefit Workers Compensation recipientsCC.10.20The System must capture Internet Protocol (IP) addresses associated to applications to assist staff in detecting fraudulent schemes.DC.10.21Each quarter, the system must randomly select appropriate first level appeals based on the ETA 9057 (Lower Authority Appeals Quality Review) and ETA 382 (Handbook for Measuring UI Lower Authority Appeals Quality) sample selection criteria for .10.22The System must allow the selected cases to be graded base on ETA 9057 (Lower Authority Appeals Quality Review) and ETA 382 (Handbook for Measuring UI Lower Authority Appeals Quality) .10.23The System must be able to generate subpoenas (for a person and/or documents) at designated periods defined by the stateCC.11 Interface InteroperabilityC.11.1The System must automatically export data from the system in multiple formats (e.g., csv, fixed length ASCII, tab delimited).CC.11.2The System must automatically import data into the system in multiple formats (e.g., csv, fixed length ASCII, tab delimited).CC.11.3The System must automatically maintain external system information for interfaces (e.g., connection strings, file paths).CC.11.4The System must automatically transmit/receive imported/exported data through multiple methods (e.g., file output, web service, single and batch transactional (e.g., ICON). CC.11.5The System must automatically generate and execute scripts to import and export data. CC.11.6The System must automatically present a result list for data imports and exports (e.g., success or failure, time started, time completed). CC.11.7The System must automatically report on interface transmissions (e.g., total number of records loaded, date of interface transmission, amount of time to execute the interface transmission, errors, and failures). CC.11.8The System must automatically isolate records within a file that contain an error condition and process the file excluding the error records. CC.11.9The System must automatically create a report of records that could be successfully processed within a batch file. CC.11.10The System must automatically restart an interface transmission from a specific point (e.g., restart at failed record, restart from beginning). CC.11.11The System must automatically associate information received via interface with the line-of-business record which generated the information request. CC.11.12The System must support the exchange of bulk data information to be printed and mailed. CC.11.13The System must support real time data exchange with external systems (i.e. other state agencies, federal government, vendors). CC.11.14The System must support real time and/or batch data exchange with other Job and Family Services systems (i.e. Data Exchange, BI, and OWCMS/OMJ). CC.11.15The System must provide an electronic interface with the Ohio County Finance Information System (CFIS).CC.11.16The System must provide an electronic interface with address validation .11.17The System must provide an electronic interface with occupational coding software. CC.11.18The System must provide an electronic interface with State's Enterprise Resource Planning system - OAKS (Ohio Administrative Knowledge System).CC.11.19The System must provide an electronic interface with Master Client .11.20The System must provide an electronic interface with Office of the Ohio Treasurer (TOS) to process cleared and cancelled .11.21The System must provide an electronic interface with ODJFS’ Interactive Voice Response (IVR) .11.22The System must provide an electronic interface with OUIO’s debit card .11.23The System must provide an electronic interface with OUIO’s electronic funds transfer .11.24The System must provide an electronic interface with the Ohio Bureau of Labor Market Information. CC.11.25The System must provide an electronic interface with the Ohio Workforce Case Management .11.26The System must provide an electronic interface with the State Information Data Exchange System (SIDES).CC.11.27The System must provide an electronic interface with the Ohio Office of Child .11.28The System must provide an electronic interface with the Ohio State Directory of New .11.29The System must provide electronic interfaces with the Interstate Connections Network (ICON) to facilitate Interstate Benefit/UCX/UCFE, LADT, and other benefit .11.30The System must provide an electronic interface with the National Directory of New Hires. CC.11.31The System must provide an electronic interface with the Ohio Attorney General's .11.32The System must provide an electronic interface with United State Social Security .11.33The System must provide an electronic interface with the Federal SUN System. CC.11.34The System must provide an electronic interface with Ohio Bureau of Workers' .11.35The System must provide an electronic interface with OUIO’s Incarceration contracted .11.36The System must provide an electronic interface with Ohio Department of Administrative Services for printing/mailing .11.37The System must provide an electronic interface that provides claimant/claim data for the Office of Family Assistance and Office of Families and Children that will assist them with determining .11.38The System must interface with a texting vendor to facilitate communications through the texting .11.39The System must provide claimant benefit data to employers participating in the sub-pay .11.40The System must interface with OUIO’s online orientation vendor to facilitate self-service online orientation .11.41The System must be capable of providing UI data to entities with which OUIO has a data sharing agreements in .11.42The System must provide an ACH interface to the bank that ODJFS .11.43The System must be able to accept and process credit card .12Federal ReportsC.12.1The System must allow staff to schedule (and manage the schedule for) producing Federal ETA Reports (at an individual report level). CC.12.2The System must automatically produce Federal ETA Reports in adherence to scheduled production dates. CC.12.3The System must allow staff to retrieve and view federal report data on demand and at scheduled intervals. CC.12.4The System must provide a printable view of Federal ETA Reports (with no truncating report data). CC.12.5The System must allow staff to modify the data requirements of Federal ETA Reports. CC.12.6The System must collect the data necessary to produce required Federal ETA reports. CC.12.7The System must automatically retrieve report data and perform the required calculations prescribed in the ETA Federal Reporting Handbook. CC.12.8The System must automatically produce federal reports in the format prescribed in the ETA Federal Report Handbook. CC.12.9The System must automatically produce federal reports that pass all edit checks prescribed in the ETA Federal Report Handbook. CC.12.10The System must electronically interface with the Employment and Training Administration reporting system to electronically submit Federal ETA Reports. CC.12.11The System must produce the data necessary for the State to complete and submit the UI Contingency Report (UI-3).CC.13Special ProgramC.13.1The System must allow staff to enter/update Trade Adjustment Assistance petition certifications under the Trade Act of 1974, as amended in 2002, 2009, 2011, and .13.2The System must allow claimants and staff, on behalf of claimants, apply for Trade Readjustment Assistance (TRA) and ATAA/RTAA. CC.13.3The System must allow staff to choose a petition for TRA on behalf of the .13.4The System must automatically identify potential qualifying separations and whether the claimant has worked in adversely affected employment for 26 weeks earning at least $30 a .13.5The System must identify claimants that are eligible for a choice between UI and TRA/ATRA .13.6The System must allow staff, prior to system electing choice automatically, to select a choice between a claimant continuing on TRA/ATRA program and beginning their UI .13.7The System must generate a monetary determination for Completion TRA .13.8The System must generate a monetary determination for Remedial/Prerequisite TRA .13.9If fraud determinations are issued on TRA claims, the system must disqualify claimant for any trade assistance services under federal TAA program (lifetime and doesn't affect other programs).CC.13.10The System must provide the ability to file, process and determine eligibility for Reemployment Trade Adjustment Assistance and Alternative Trade Adjustment Assistance (R/ATAA) .13.11The System must provide the ability to file and process continued claim applications to determine eligibility to pay R/ATAA benefits. CC.13.12The System must send monetary and nonmonetary determinations for the R/ATAA .13.13The System must process Health Care Tax Credit (HCTC) eligibility under both the TRA/ATRA and R/ATAA .13.14The System must allow staff to file a claim on behalf of the claimant for Disaster Unemployment Assistance (DUA). CC.13.15The System must automatically establish eligibility for a DUA claim. CC.13.16The System must allow staff to enter/update DUA/FEMA certifications for disaster relief (including area for disaster relief, project number and eligible workers, the start and stop date of the disaster period, and work search requirements). CC.13.17The System must allow staff and employers/TPAs to electronically submit a plan application to participate in the SharedWork Ohio (SWO) .13.18The System must allow employers to withdraw SharedWork Ohio plan applications at any .13.19The System must capture data elements and demographic information that will allow staff to approve/deny the SWO plan application (e.g. start/end dates, participating employee lists, reduction percentage, shut down dates, etc.)CC.13.20The System must allow staff and employers/TPAs to add attachments related to the plan to the plan application and weekly claim certifications.? CC.13.21The System must allow staff to approve/deny the plan application and notify the employers/TPAs of such .13.22The System must set up an approved plan to be effective for maximum a defined number of .13.23The System must allow and process multiple SWO plans to affect a single established benefit year for a .13.24The System must allow employees to file SWO initial and additional claim applications and gather specific information to determine eligibility for SWO .13.25The System must allow employees to withdraw SWO initial and additional claim .13.26The System must set up SWO monetary entitlement based upon a prorated percentage of the UI weekly benefit .13.27The System must be able to flip from SWO to UI and pay UI benefits during shut-down periods. CC.13.28The System must send determinations to SWO employees notifying them of their SWO entitlement .13.29The System must charge base period employers for any SWO entitlement that a claimant receives within their benefit year. CC.13.30The System must allow for employer-filed, employee certified continued claims under the SWO .13.31The System must create non-monetary issues based upon answers in the SWO initial, additional, and continued claim filing process. CC.13.32The System must automatically issue SWO benefit payments to employees who meet all eligibility requirements in the initial and continued .13.33The System is not required to withhold child support from SWO benefits (already being withheld by employer). CC.13.34The System must allow staff and employers/TPAs to submit plan modifications to an originally approved SWO plan, including adding to the SWO participating employee .13.35The System must allow a SWO claim to transition to/from other UI programs based upon business factors such as plan is terminated, shut down, .13.36The System must allow staff to terminate a plan for good cause and notify the employees and employers/TPAs of such .13.37The System must not allow breaks in claims under traditional UI rules to impact SWO .13.38The System will allow multiple SWO plans for an employee in a single benefit .13.39The System will move SWO employee data between benefit programs (e.g., SWO, UI, etc.).C Table D: Common Functional RequirementsScoring definitions: C is a critical component of the system. D is a desirable component of the mon RequirementsScoringOfferor ResponseCheck Applicable BoxNarrativeCore CapabilityConfiguration OptionRequires DevelopmentD.1 Labor Market Information SupportD.1.1The System will generate LMI extracts.CD.1.2The System must allow for BLMI-QCEW entry of NAICS, county and ownership codes based on information provided during account registration.CD.1.4The System must create the BLMI claims reports/extracts (weekly, monthly, liable/agent data transfer) and quarterly and non-quarterly, predecessor/successor, and 3 wage records extracts.CD.1.5The System must allow batch loading of NAICS, county and ownership codes.CD.2 Data Validation SupportD.2.1The System must provide an electronic interface with the Federal Data Entry System (SUN System).CD.2.2The System must collect the data necessary to produce required Federal Data Validation extract files (Tax & Benefits).CD.2.3The System must automatically retrieve data validation extract file data as prescribed in the ETA Data Validation Handbooks (Tax & Benefits). CD.2.4The System must automatically produce federal data validation extract files that pass all edit checks prescribed in the ETA Data Validation Handbooks (Tax & Benefits). CD.2.5The System must automatically produce the artifacts necessary to perform data validation Module 4 (Tax & Benefits).CD.2.6The System must automatically produce the artifacts necessary to perform data validation Module 5 (Wage Item Validation – Tax only).CD.2.7The System must automatically export data from the system in multiple formats (e.g., csv, fixed length ASCII, tab delimited).CD.2.8The System must automatically generate and execute scripts to import and export data.CD.3 Review Commission AppealsD.3.1 Lower Authority AppealsD.3.1.1The System must provide an electronic director file function that transfers all the information that ODJFS has on a particular case over to be worked as an appeal by the independent governor’s board tasked with independent review.CD.3.1.2The System will support the Review Commission team by providing case management support for the docketing, scheduling, documentation, and decisions associated with these appeals.CD.3.1.3The System will provide an automatic scheduler to assign cases to hearing officers. The scheduler will accept as input hearing officer related information such as available hearing times, issues and programs available etc.The scheduler will accept as input default parameters like max number of minutes of hearings per day, max number of hearings per day, start and stop times etc. The scheduler will accept as input appeal related information such as location of hearings, length of hearings, dates to avoid, days/times of the week that are not available, agreed dates and/or time and/or hearing officer, link appeals (same time or consecutive) etc.CD.3.1.4The System will support hearing officer decisions-creation using standard desktop tools with MS Word as the primary document editing tool. CD.3.1.5The System will provide common templates for the various decisions and other correspondence generated by this process.CD.3.1.6The System will provide a mechanism to provide a copy of the director’s file to interested parties and higher-level courts. This must include the directors file, appeal documents, correspondence produced for the appeal (hearing notices, decisions etc.).CD.3.1.7The System will provide an administrative interface to collect call back number to allow the hearing officer to call out to all participants to the hearing.CD.3.1.8The System will provide the ability to place the outgoing call with a click on a screen within the system.DD.3.1.9The System will provide a capability to ensure all hearings are recorded and the hearing voice file is immediately associated with the hearing proceeding information on the system.CD.3.1.10The System will provide a capability to produce copies of the hearing recording (physical (such as CD) and electronic).CD.3.1.11The System must provide support for reliably recording all hearings. This would preferably be an integrated solution but would minimally be an interface that would provide the data and calendar information on currently scheduled hearings.CD.3.1.12The System must provide the capability to postpone a hearing which may or may not be scheduled again.CD.3.1.13The System must keep a record of all hearings (and postponements of hearing when applicable).CD.3.1.14The System must provide the capability to reopen an appeal for various reasons. Based on the reason selected the appeal must be placed at the appropriate location within the workflow. The reopen must be restricted to reason acceptable based on the appeal data (an appeal can only be reopen for a court reason if a court record exists for the appeal, an appeal can only be reopened for a new decision if a previous decision exists etc.).CD.3.1.15The System must provide the capability to dismiss an appeal when the appellant does not show for their hearing.CD.3.1.16The System must provide the capability to withdraw the appeal when requested by the appellant.CD.3.1.17The System must provide the capability to close an appeal without a decision. The reason for the closure must be selectable and correspondence must be optionally generated if desired.CD.3.1.18The System must provide the ability to add representative(s) to claimants and employers.CD.3.1.19The System must provide the ability to maintain information related to a representative such as contact name, company name, address, email, phone etc. CD.3.1.20The System must provide the ability to add one or more issues to an appeal.CD.3.1.21The System must provide the capability for one claimant to be associated to the appeal.CD.3.1.22The System must provide the ability to maintain information related to a claimant such as name, address, email, phone, appeal date, appeal filing method etc. CD.3.1.23The System must provide the capability for zero to many employers to be associated to the appeal.CD.3.1.24The System must provide the ability to maintain information related to each employer such as company name, address, email, phone, TPA address, appeal date, appeal filing method etc. CD.3.1.25The System must provide the capability for zero to many parties that are not the claimant nor the employer (such as ODJFS, Attorney General etc.) to be associated to an appeal.CD.3.1.26The System must provide the ability to maintain information related to each party that is not the claimant nor the employer such as contact name, company name, address, phone email, appeal date, appeal filing method etc. CD.3.1.27The System must provide the capability to track appeals made to court (common pleas and appellate courts at both the state and federal levels, the Ohio Supreme Court, the US Supreme Court) for the appeal.CD.3.1.28The System must maintain information related to the appeal such as claim type (UCX/UCFE), program type etc.CD.3.1.29The System must provide a method to link multiple appeals together so that the scheduling program will schedule the appeals at the same time.CD.3.1.30The System must provide a method to link multiple appeals together so that the scheduling program will schedule the appeals consecutively.CD.3.1.31The System must provide a method to indicate specific dates that an appeal should not be scheduled on.CD.3.1.32The System must provide a method to indicate specific days/times of the week that an appeal should not be scheduled on.CD.3.1.33The System must provide a method to indicated a specific date and/or time and/or hearing officer that an appeal must be schedule for.CD.3.1.34The System must provide a manual (user controlled) method for scheduling of appeals which displays conflict information but permits a manual override.CD.3.1.35The System must provide the entry of subpoena requests for an appeal.CD.3.1.36The System must provide work queues so that staff may process self-service requests such as higher authority appeals, withdrawals, vacate of a dismissal and subpoenas. The System must allow the staff to accept the self-service request (in which case the appeal workflow must be updated as appropriate) or reject the appeal. In either instance, a documentation of the request and staff’s action must be preserved within the appeal.CD.3.1.37The System must provide the ability to begin a new appeal based on an existing appeal (claimant, employers etc.). The new appeal must have its own workflow.CD.3.1.38The System must provide the ability to issue interlocutory orders for appeals dealing with a timeliness (or show cause) issue when appropriate.CD.3.1.39The System must interface with the Benefits module. When an appeal is closed, the status and disposition information will be sent to the benefits module.CD.3.2 Higher Authority AppealsD.3.2.1The System must support all options available for lower authority appeals except for D.3.1.1, however the life cycle of an appeal will be different.CD.3.2.2The System must provide the ability to create a higher-level appeal from a lower level appeal.CD.3.2.3The System must support Commission voting processes during the workflow process of an appeal. Depending on the life cycle of an appeal there may be multiple voting rounds (each with different voting options and outcomes as defined in Ohio law.)CD.3.2.4The System must provide a timed queue (configurable number of days) to hold appeals that have been allowed. The System must provide the ability for a user to release the appeal from the hold period (early) or restart the hold period.CD.3.2.5The System must provide the ability to assign rewrite cases to hearing officers.CD.3.3 Multi Claimant Appeals D.3.3.1The System must support all options available for lower and higher authority appeals except for D3.1.1 and D.3.1.19, however the life cycle of an appeal will be different. CD.3.3.2The System must support labor dispute and non-labor dispute multi-claimant appeals, the life cycle of these will be different.CD.3.3.3The System must provide the capability for one to many claimants to be associated to the appeal. CD.3.3.4The System must provide the ability for claimants to be split into multiple groups, once split each group must function as its own appeal. CD.3.3.5The System must provide the ability to assign rewrite cases to hearing officers. CD.3.3.6The System must provide the ability to add a listing of claimants to decisions and other correspondence produced.CD.3.3.7The System must provide the ability for a claimant representative to waive correspondence for the group of claimants.CD.3.4 Tax AppealsD.3.4.1The System must support all options available for lower and higher authority appeals except for D.3.1.1, however the life cycle of an appeal will be different.CD.3.4.2The System must not allow a claimant to be associated to a tax appeal.CD.3.5 Hearing Officer CalendarD.3.5.1The System must provide the ability to view calendars (in daily, weekly and monthly formats) for hearing officers. Data (such as appeal number, date, time, claimant name etc.) related to each hearing must be displayed.CD.3.5.2The System must provide the ability to specify working hours (day of week, start time, end time etc.) that each hearing officer is available for.CD.3.5.3The System must provide the ability to specify working hours (start time, end time) for daytime hearings on days when the hearing officer is scheduled for evening hearings.CD.3.5.4The System must provide the ability to specify a hearing officer’s hearing time preference (morning or afternoon or mix).CD.3.5.5The System must provide the ability to specify which hearing officers are eligible to be scheduled for evening hearings (including which dates/days of week). CD.3.5.6The System must provide the ability for hearing officers to specify time (date and time) that they are not available for hearings (such as vacation, meetings etc.).CD.3.5.7The System must display hearing officer availability in email system (Outlook etc.).DD.4 Client / WorkstationD.4.1The website design rendering must be browser neutral. The website must be thoroughly tested for compatibility with major browsers (Windows: IE, Chrome, Firefox, Opera, Netscape; Mac: Safari, Chrome, Firefox, Opera; Linux: Firefox, Opera, Netscape) and two versions backward compatibility with screen resolution neutrality. CD.4.2Compatible browsers information must display on each page of the site including “white-labeled” or third-party tools.CD.4.3Must ensure system is continually tested for current browsers for updated and/or new content. Must have the site compatible within 6 months of a new browser release date, and remain backward compatibility for two versions back. CD.4.4ODJFS seeks a system which delivers a good experience on multiple devices, including PC's, tablets, and a variety of smartphones. Offeror must describe their strategy and approach to meeting this requirement, including whether the Offeror utilizes a responsive web design approach or dedicated mobile apps.CD.5 Documentation and StandardsD.5.1Provide a logical network diagram that describes how the infrastructure components will meet the functional requirements. CD.5.2Provide conceptual and logical data-flow diagrams. CD.5.3Provide a high-level architecture diagram, including logical and physical components. CD.5.4System documentation must describe error logging and how to access the error logs. CD.5.5System documentation must describe any batch processing requirements for the application.CD.5.6A detailed network/server diagram must be provided illustrating the relative architecture of the proposed system. It must include: Network security zones and firewalls;Server types and network components (e.g., switches);Ports and protocols used to cross security zones;How users will access the system; andClustering of servers CD.5.7Provide conceptual and logical application data-flow models. CD.5.8Provide a technology roadmap for the proposed system showing a five (5) year plan for new software version releases, support window, and sun setting. CD.6 ConversionD.6.1Must describe their strategy and approach for data conversion, including descriptions of prior similar projects.CD.6.2Must provide conversion of data from the current benefits system into the proposed system which is sufficient to provide a historical record of participation episodes based on federal requirements.CD.7 Security and RecoveryD.7.1Must describe how the system security supports role based security and protects access to sensitive data.CD.7.2Must provide a recovery plan for restoring services in the event of a disaster including system and data restoration.CD.7.3Offeror must describe the encryption used to protect sensitive data, both in transit between users and the provider, and while data is stored at rest.CD.7.4Offeror must agree that all ODJFS data that it hosts will be hosted only in data centers located inside the United States.CD.7.5Offeror must agree that all data stored in the application is the property of the State of Ohio. Offeror must also agree to periodically provide copies of the state data to ODJFS and when the contract expires or is terminated. Offeror must certify the destruction of any remaining copies in its systems.CD.7.6Offeror must agree to notify ODJFS in the event of compromise or other unauthorized access to ODJFS data. ?Must describe policies in the event of a privacy breach.CD.7.7Offeror must certify that it will either use discrete data storage for the Service provided to ODJFS or if it collocates ODJFS data with data of other customers, have a documented set of controls that it uses to ensure the separation of data and security information between customer applications.CD.7.8The proposed solution must have a completed Project Security Plan and Assessment.CD.7.9The proposed solution must have built-in security controls and meet or exceed current ODJFS security requirements as described in Supplement 2. CD.7.10Application access must be logged and have a viewable audit trail(s). CD.7.11Changes to user permissions must be logged and have a viewable audit trail(s). CD.7.12Access to audit trail logs must be able to be restricted to approved administrators. CD.7.13Application access and changes to application access must log the following information: Date/time;Nature of operation;Name of changed item; Name of who made the change; andBefore and after value of the changed item.CD.7.14The following application change event(s) must be logged: Changes to individual permission level;Changes to role membership;Changes to role permissions; andChanges to access to application functions. CD.7.15The System Administrator must be able to control access to audit trail logs. CD.7.16Passwords and User ID's must be able to: Protect sensitive data;Restrict access to only those intended;Meet Federal/State/Agency Security Standards; andBe able to be encrypted.CD.7.17Applications and systems must adhere to ODJFS Policy regarding Access to Networks, Systems, Computers, Databases and Applications.CD.7.18Applications and systems must adhere to ODJFS Policy regarding Access to Protected Data Resources. CD.7.19End-user software applications, or components thereof, must not require privileged, super-user or administrator mode in order to function properly. CD.8 Identity ManagementD.8.1Application authentication and authorization must be by individual user. User account information must be stored securely. Users may belong to groups and roles. CD.8.2The application must enforce the following rules on individual passwords for allowable characters, length and expiration period: Standard Window characters allowed;Minimum of 8 characters in length;Expires every 90 days; andCannot reuse passwords for 1 year CD.8.3The application must lock out users after five invalid login attempts due to bad passwords. CD.8.4The application must provide the system administrators with the capabilities to define different roles with different privileges. CD.9 System Performance and CapacityD.9.1The application must provide performance-optimization capabilities. CD.9.2The application must maintain optimum performance over both Wide Area Network (WAN) and Local Area Network (LAN). CD.9.3System documentation must clearly describe all versions of the package that are deployed for different scaling situations. CD.9.4System documentation must clearly describe all activities that affect optimum performance such as service recycling, rebooting, or batch jobs and their frequency. CD.9.5The System must provide a response time of less than 2 seconds for accessing low complexity pages composed of mostly static text and other non-computationally intensive elements. CD.9.6The System must provide a response time of less than 5 seconds for accessing medium complexity pages composed of some static text along with dynamic text related to a single entity retrieved from the database.CD.9.7The System must provide a response time of less than 5 seconds for 90% of all searches. The remaining 10% must complete in less than 15 seconds.CD.9.8The System must provide a response time of less than 15 seconds for accessing any level of complexity pages composed of dynamically generated text, images, multimedia elements, many computationally intensive elements, and calls to external, non-cacheable services.CD.9.9The System must support 1500 simultaneous staff users with an average of 15 seconds think time between page requests.CD.9.10The System must support 4000 simultaneous claimants with an average think time of 30 seconds between page requests.CD.9.11The System must support 800 simultaneous employers with an average think time of 30 seconds between page requests.CD.9.12The System must support 1,500,000 claims per year.CD.9.13The System must maintain 10 years of claim and claimant history.CD.9.14The System must be available to internal staff between 6:00am and 8:00pm Monday through Saturday. Occasional planned Saturday outages are acceptable.CD.9.15The System must be available to claimants and employers 24 hours a day, 7 days a week, with a maximum 2-hour maintenance window per day.CD.9.16The proposed solution must provide real-time data transfer of identified data.CD.10HostingD.10.1The System must be robust, responsive, and highly available. Must describe the hosting and infrastructure used to provide services to ODJFS.CD.10.2A documented Media Protection policy that addresses purpose scope, roles, responsibilities, and procedures, developed and distributed to all employees, must be provided.CD.10.3Media is sanitized and disposed of based on written policies and procedures approved by ODJFS.CD.10.4A documented Physical and Environmental protection policy that addresses purpose scope, roles, responsibilities, and procedures, developed and distributed to all employees, must be provided. CD.10.5The proposed solution delivers standard reports/information useful for assessing the overall status, operation and debugging of the solution.CD.10.6A documented Systems and Information Integrity policy that addresses purpose scope, roles, responsibilities, and procedures, developed and distributed to all employees, must be provided. CD.10.7Must identify, report, and correct information system flaws. CD.10.8Must implement malicious code protection and techniques. CD.11Single Sign-onD.11.1The System must support single sign-on for all functions within the System (i.e. staff must not have to separately logon to conduct case management and job matching functions).CD.11.2The State uses a Microsoft active directory environment; other entities may utilize active directory or other authentication mechanisms for their local domains. Please describe options for importing and synchronizing user accounts with preexisting log on mechanisms.D.12CorrespondenceD.12.1The System must allow staff the ability to control correspondence templates.CD.12.2The System must allow staff the ability to add free form text to correspondence.CD.12.3The System must allow staff to select variable text to insert into correspondence templates.CD.12.4The System must automatically insert variables (data) into correspondence templates. CD.12.5The System must automatically merge file data (i.e. names, addresses) with correspondence templates. CD.12.6The System must automatically generate correspondence. CD.12.7The System must allow staff to generate correspondence. CD.12.8The System must generate correspondence to the employer/claimant defined method of delivery. CD.12.9The System must generate an email notification to the employer/claimant who elects electronic receipt of correspondence when correspondence is posted to their web account. CD.12.10The System must automatically mask sensitive information for correspondences or images being sent to employers, employer representatives, claimants, and other interested parties. CD.12.11The System must automatically create a non-editable format (e.g. PDF) of outgoing correspondence. CD.12.12The System must automatically store all generated correspondence in the document management system and associate the correspondence with the appropriate account and/or record. CD.12.13The System must automatically record transmittal and identifying information on all outgoing correspondence. CD.12.14The System must allow staff to resend correspondence. CD.12.15The System must automatically manage dates that correspondence was generated, reproduced or resent. CD.12.16The System must automatically update 'due dates' when a previously generated correspondence is reproduced. CD.12.17The System must allow staff to send copies of correspondence to additional (not employers, claimants or TPAs in our system) interested parties. CD.12.18The System must interface with the State printing agency for the printing of correspondence.CD.12.19The System must have the ability automatically to bar code outgoing correspondence with identifying information and alignment marks, with appropriate indexes. CD.12.20The System must prefill and bar code identifying information and alignment marks, with appropriate indexes, on all forms requested within the web portals. CD.12.21The System must scan and digitally index incoming correspondence. CD.12.22The System must store images in the document management system in the appropriate files based on indexes attached to the incoming correspondence.CD.12.23The System must allow staff to manually index incoming correspondences which does not contain recognizable or readable information. CD.12.24The System must automatically record the received date for all incoming correspondence. CD.12.25The System must read incoming correspondence using Optical Character Reader (OCR) or Optical Mark Recognition (OMR) technology. CD.12.26The System must maintain an inventory of form templates, associated auto text inserts, date of last update and identification of who made update. CD.12.27The System must allow staff to view attachment information associated to issues.CD.12.28The System must be capable of generating a single mailing to the employer soliciting information for multiple claimants.DD.12.29The System must be able to generate correspondence based on a triggering event (such as subpoena being issued once a hearing is scheduled).CD.13Work FlowD.13.1The System must automatically distribute work items to the appropriate staff using staff's profile and configurable work item attributes. CD.13.2The System must automatically start and stop the distribution of work items when the configurable limits for a work type are reached in the staff's inbox. CD.13.3The System must allow staff to adjust the distribution of work items. CD.13.4The System must allow staff to search, select, and assign selected work items to a staff inbox. CD.13.5The System must allow staff to view work items distributed by team, role, area and staff members. CD.13.6The System must automatically alert staff when a work item is approaching or past the work item's due date of completion. CD.13.7The System must allow staff to search for work items using single or multiple search criteria. CD.13.8The System must allow staff to limit the number of results returned for a work item search. CD.13.9The System must automatically display the results of a search for work items. CD.13.10The System must automatically display the search criteria used for the image/work item search on the search result screen. CD.13.11The System must allow staff to select a work item or multiple work items to perform a selected action. CD.13.12The System must allow staff to add, edit and delete notes to an image or work item. CD.13.13The System must automatically update the status of a work item each time an action is taken on the work item. CD.13.14The System must automatically distribute work items requiring approval to designated staff. CD.14Internal ReportsD.14.1For particular business transactions, the system must automatically produce demographic data that would assist in determining potential bias and discrimination practices.CD.14.2The System must provide a configurable system of reporting, dashboard and score-card reporting capabilities. CD.14.3The System must produce multiple types of internal reports; i.e. production reports, error reports, statistical reports, metrics reports (including performance measurement/key performance indicators reports).CD.14.4The System must produce both on-demand and regularly scheduled internal reports. CD.14.5The System must allow staff to access available internal reports to run via a variety of methods (displayed list of available reports, ability to search for a specific report or type of report, etc.). CD.14.6The System must allow staff to run parameterized on-demand reports. CD.14.7The System must allow staff to maintain a run-time schedule for internal reports.CD.14.8The System must produce internal reports based on staff defined intervals (daily, weekly, monthly, etc.).CD.14.9The System must allow staff to select the delivery method for available internal reports. CD.14.10The System must allow staff to pre-define the number of records to be returned per page on an internal report. CD.14.11The System must provide logical navigation for multi-page reports. CD.14.12The System must allow staff to retrieve on-demand reports real time or in overnight batch mode. CD.14.13The System must regulate the production of on demand report based on system usage/performance. CD.14.14The System must notify staff when an on-demand internal report is available when the generation of the report was delayed due to system usage/performance. CD.14.15The System must automatically route internal report results to staff (both regularly scheduled reports and on-demand reports). CD.14.16The System must display reports in multiple formats (i.e. table, chart, graph). CD.14.17The System must allow staff to save reports in various formats including XLS, DOC, PDF, CSV, TXT, and Image files. CD.14.18The System must provide a printable view of internal reports (with no truncating report data). CD.14.19The System must archive internal reports. CD.14.20The System must provide an adhoc query tool. CD.14.21The System must allow staff to run queries using logical operators. CD.14.22The System must allow staff to export query ad-hoc query results. CD.14.23The System must allow staff to save named queries. CD.15Help SearchD.15.1The System must provide context sensitive, on demand help. CD.15.2The System must provide immediate, searchable and relevant on-line access to all Unemployment Insurance (UI) policy and procedure manuals and new updates. CD.15.3The System must provide an online general subject index, process and procedure guide and field-level help guide. CD.15.4The System must provide a full glossary of all UI terms. CD.15.5The System must allow staff to perform online searches using a variety of parameters (text, dates, etc.). CD.15.6The System must allow staff to perform keyword searches. CD.15.7The System must allow staff to combine multiple search criteria using logical operators such as ‘AND’, ‘OR’, BETWEEN’ and 'LIKE'. CD.15.8The System must allow staff to sort search results returned data. CD.15.9The System must allow staff to filter search results. CD.15.10The System must allow staff to search and retrieve records (or logical groups of records) matching compound search criteria. CD.15.11The System must provide query searching capabilities that can be used to search within a result set. CD.15.12The System must allow staff to perform advanced searches to filter search results. CD.15.13The System must allow staff to configure the number of returned search results. CD.16Security User InterfaceD.16.1The System must enforce security roles at a function level to determine users (internal/external) ability to enter, update, view and/or delete. CD.16.2The System must provide the ability for staff, claimants and employers to logout of the system/web account on all screens/pages. CD.16.3The System must allow staff to establish "user profiles" consisting of one or more security roles from which individual staff may inherit privileges. CD.16.4The System must automatically log security events (e.g., failed/successful login attempts, amendment of user rights, inactivation of users). CD.16.5The System must automatically log staff accessing confidential personal information.CD.16.6The System must be compliant with all TOP and IRS Publication 1075 security requirements.CD.16.7The System must be 508 compliant.CD.16.8The System must have a consistent look and feel for all web enabled user interfaces (for staff, employers/TPAs and claimants) and abide by agency branding standards. CD.16.9The System must provide logical navigation and menuing for each screen. CD.16.10The System must allow full screen display of information without horizontal scrolling. CD.16.11The System must be flexible with dynamic displays of information, data capture, edits/validations, instructional messages etc. based on security roles. CD.16.12The System pre-populate data on screens (eliminate redundant/duplicate data entry). CD.16.13The System must allow the ability for staff to navigate between related functionality within a line of-business record without reentering the original search criteria. CD.16.14The System must automatically display a progress indicator to staff, claimants and employers for all processes requiring multiple steps or screens. CD.16.15The System must automatically display a time out indicator to staff, claimants and employers prior to timing them out of system.CD.16.16The System must have all navigation for self-service applications occur within the application (disable use of back browser button). CD.16.17The System must adhere to all Agency and State security policies and procedures.CD.16.18The System must be capable of offering historical tracking features when critical business information is modified so it can be referenced for future use. CD.17GeneralD.17.1The System must maintain interfaces into current state Systems in the format and frequency approved by ODJFS, including batch transactions that have the ability to:Create a log with job errors; and Schedule jobs and run jobs on-demandCD.17.2Create and maintain new interfaces to external data sources. CD.17.3The availability of a standards Application Programming Interface (API) in the System.CD.17.4Must describe support of multiple language options for core System functions for both staff members and end user interfaces. The System must, at a minimum, support English and Spanish.CD.17.5Must provide testing and training environments which are routinely updated with functionality additions and fixes that reflect the most current version of solution.CD.17.6The proposed solution must meet W3C web accessibility guidelines and comply with Americans with Disabilities Act standards including section 508.CD.17.7The proposed solution must be compatible with assistive technology products, including screen readers, screen enlargement viewers, and text to speech products.CD.17.8The System must allow staff to administer (add/modify/delete) notes to a claimant's or employer's account.CD.17.9The System must create notes automatically based on OUIO business rules.C11. Table E: Trade Case Management Functional Requirements - OptionalScoring definitions: C is a critical component of the system. D is a desirable component of the system.Trade Case Management RequirementsScoringOfferor ResponseCheck Applicable BoxNarrativeCore CapabilityConfiguration OptionRequires DevelopmentE.1 Trade Case Management E.1.1For a given federal fiscal year, the System must allow staff to establish a TAA obligation authority, track a total amount of contract obligations, and expenditures by category. (Examples include: tuition, books, materials, fees)CE.1.2The System must allow for worker lists to be associated to petitions. CE.1.3The System must allow claimants and staff, on behalf of claimants, apply for TAA training.CE.1.4The System must allow staff to choose a petition for TAA on behalf of the claimant.CE.1.5The System must prevent a TAA contract from being established if a qualifying separation is not identified between the impact and expiration date of the petition.CE.1.6The System must allow staff to administer waivers of training under the Trade program, including initials, extensions, revocations, and expirations.CE.1.7The System must allow for staff to conduct an assessment to assist with determining eligibility for a training contract under the TAA program.CE.1.8The System must allow staff to administer TAA training contracts, such as occupational, remedial, third-party, pre-requisite and apprenticeship.CE.1.9System must interface with Ohio Administrative Knowledge System (OAKS) when paying training providers.CE.1.10The System must allow staff to administer, review and process training benchmarks and attendance verification forms.CE.1.11The System must allow for the administration and processing of On-The-Job (OJT) training contracts.CE.1.12The System must allow for the administration of Relocation Allowances.CE.1.13The System must allow for the administration of Job Search Allowances.CE.1.14The System must allow for transportation and subsistence expenses to be calculated and included in TAA contracts when the training is conducted outside the worker’s commuting area.CE.1.15The System must provide staff the ability to maintain TAA training providers and the training programs that offered at their respective sites.C12. Table F: Work Opportunity Tax Credit (WOTC) Requirements - OptionalWOTC RequirementsScoringOfferor ResponseCheck Applicable BoxNarrativeCore CapabilityConfiguration OptionRequires DevelopmentF.1 Work Opportunity Tax Credit (WOTC)F.1.1The System must provide employers the ability to submit a Work Opportunity Tax Credit (WOTC) application through the employer web portal.CF.1.2The System must allow staff to enter/update/view WOTC applications. CF.1.3The System must allow staff to maintain the status of a WOTC application. CF.1.4The System must automatically reject a WOTC application due to untimely submissions. CF.1.5The System must automatically reject a WOTC application when one has already been submitted for the SSN by the employer. CF.1.6The System must automatically reject WOTC applications for employees rehired by the same employer (same FEIN or different FEIN when the employer is a subsidiary with the same owner). CF.1.7The System must automatically reject WOTC applications when the eligibility period for the target group has expired. CF.1.8The System must automatically process WOTC applications when the previously expired eligibility period for the target group is extended. CF.1.9The System must only allow a WOTC application to be submitted by a party other than the employer when there is a valid Power of Attorney for the submitting party. CF.1.10The System must automatically calculate WOTC eligibility based on wage information, rehire status indicator, and claims information. CF.1.11The System must allow staff to prioritize the order in which eligibility is validated with various government entities. CF.1.12The System must electronically interface with the Ohio Department of Human Services to validate target group eligibility for WOTC program. CF.1.13The System must automatically determine eligibility for U.S. military veterans when a claim for unemployment benefits based on military service exists. CF.1.14The System must electronically interface with the U.S. Bureau of Veteran Affairs to validate veterans target group eligibility. CF.1.15The System must be able to electronically interface with the U.S. Department of Veterans Administration (VA) to validate veterans target group eligibility. CF.1.16The System must be able to electronically interface with U.S. HUD Empowerment Zone/Enterprise Community Locator System to validate selected target group eligibility. CF.1.17The System must be able to electronically interface with Ohio Secretary of State to validate selected target group eligibility. CF.1.18The System must be able to electronically interface with Ohio Rehabilitation Services to validate selected target group eligibility. CF.1.19The System must be able to electronically interface with Maximus Ticket to Work System (SSA) to validate selected target group eligibility. CF.1.20The System must be able to electronically interface with the Ohio Department of Corrections to validate selected target group eligibility. CF.1.21The System must update WOTC application status for each employee based upon validation process for each target group selected. CF.1.22The System must allow staff to reverse eligibility status for WOTC based on regulation changes for each target group. CF.1.23The System must provide the ability to automatically generated notices of eligibility for WOTC to employers.C13. Service Level Agreements - Operations13.1 Parties and TimelineThis Service Level Agreement is between the service provider (Contractor) and the State of Ohio from award of this contract and is expected to be renewed with the overall contract. This service level agreement is effective as of the date of award of this work. ODJFS and the service provider must review at least quarterly to determine if any modifications or amendments are needed to reflect the Ohio support requirements and service provider’s services.13.2 Service CatalogueThe service provider will provide the following services to the State of Ohio:ServiceDescriptionExamplesUser Support Receive, document, and prioritize issue tickets and help Ohio job seekers and staff in the use of existing applications or services.Provide help desk supportAnswer queries about applications.Receive and document bug reports.Collect and document requests for changes.Share status of requests.Problem CorrectionBring an application back to its original functionality before the problem arose. This may include a permanent fix or a temporary work around until a permanent fix is found. Fix bugs.Retrieve functionality after abnormal program plete root cause analysis.13.3 DeductionsA 5% deduction from the service provider’s monthly invoice for the month in which one or more of the SLA levels were not met. Logistics of such a payment will be mutually agreed upon between the Contractor and ODJFS.13.4 ReportingThe following processes will be used in order to manage the application maintenance outsourcing agreement. Agenda, schedules and expected content will be discussed and agreed upon at the kick-off meeting for the project.13.4.1 Weekly Status ReportThe service provider to provide ODJFS with a weekly status report that gives an overall summary of the following:Project health;On-going activities;Completed tasks;Upcoming milestones and releases;Bug reports;Risk identification and mitigation plan; andAction items across.13.4.2 Monthly Review MeetingMetrics will be tracked by service provider, summarized in a dashboard format, and discussed in a monthly meeting. This activity includes the following: Tracking unresolved issues from maintenance projects which impact the SLA;Updating maintenance project progress and resolving critical issues; andCapturing agreements and disagreements and items needing escalation.13.4.3 Quarterly Review MeetingA quarterly review meeting will include the following:The SLA will be reviewed with the managers involved and an amendment addendum will be created if required;Review process will be through teleconference or face-to-face meeting session which will be booked in advance;Review document prepared by service provider that will include overall project status, issues list, metrics reporting, supporting reasons for metrics deviation, and items that need adjustment within SLA (e.g. scope, metrics, etc.); andSLA changes will be tracked by version number and date.13.4.4 Reporting Service LevelsTypeMeasurementWeekly Status ReportDelivered at not less than seven calendar day intervalsMonthly Status ReportDelivered at monthly intervals and not less than two business days before scheduled review meetingQuarterly Status ReportDelivered at quarterly intervals and not less than five business days before scheduled review meeting13.5 User Support and Problem CorrectionThe following procedures will be used to respond to production problems that are received by the Contractor’s Help Desk or directly as an escalation from ODJFS. A production problem is defined as an unplanned production system event which adversely affects application processing or application deliverables. Measurement period for User Support and Problem Correction SLAs is a calendar month. For example, if an SLA is not met during the month of April, one 5% deduction (as outlined in the SLA associated with that particular service) will be applied to the invoice for the month of April, and if it is not met for the month of May, an additional 5% deduction will be applied to the invoice for the month of May. 13.5.1 Prioritization ApproachService requests for production problems received by the help desk or ODJFS problem escalation will be given a Severity Code from 1 – 4 based on how important responding to the problem is to the primary business of OUIO as a whole, as well as the availability of workarounds. The Severity Code will be the basis for scheduling work on the backlog and assigning resources to the request. Critical, urgent, and routine application functions are defined in the section below on Application Function Type.Severity CodeDefinition1Severity Level One – there is a complete or severe loss of service in at least one business critical area. The impact is that UI Benefits/Tax program business operations cannot reasonably continue or can continue only in a restricted fashion, and services to customers is disrupted. Repetitive problems at Level One may be grounds for Contract termination.2Severity Level Two – there is a minor loss of service. The impact is an inconvenience and business critical areas are not significantly impaired. The UI Benefits/Tax program business operations continue with minimal disruption to customers. A workaround acceptable to ODJFS may be employed temporarily to restore service and/or business operations.3Severity Level Three – there is a deviation from the Standard of Performance that causes no loss of service. This may be a minor error, incorrect behavior, or a documentation error that does not impede the operation of a system or effect ODJFS business operations. Customers are not impacted.4A problem has diminished routine application functionality or performance. 13.5.2 Application Function TypeThe table below provides examples of critical, important, and supportive application functions. Further conversation with the Contractor will help to ensure all services are mapped to the correct category.Application Function TypeDescriptionExamplesCriticalThese application functions are critical to ensuring business requirements or ODJFS reputation. Extended failure will impact job seekers or damage ODJFS reputation. Register a userSubmit an Initial ClaimSubmit a Continued ClaimReport WagesMake a PaymentEFT/Debit Card InterfacesCall/Adjudication Center InterfacesUrgentThese application functions are important to business productivity, but are not critical UI services nor critical to ODJFS reputation.System InterfacesMail/Document ScanningFile TransfersFile processingClaimant/Employer InterfaceStaff InterfaceRoutineThese applications support productivity, but are not essential to business effectiveness.13.5.3 Response and Resolution TimesSeverity codes are used in order to determine appropriate response and resolution times. Response and resolution times are measured from when the incident is opened by the help desk. If the problem is not resolved within the defined timeframe, continuous effort will be applied until the problem is resolved. Severity CodeInitialResponseEstimation ResponseSubsequent ResponsesResolution115 minutes 2 hoursEvery 30 min.8 hours230 minutes 2 hoursEvery 2 hours2 business days31 hour8 hoursDaily10 calendar days41 hourNext business dayWeekly60 calendar daysInitial Response is when a ticket is opened and acknowledged by help desk staff. This ticket will be conveyed back to the originator with proposed severity level noted. Initial severity level will be set by the Contractor; escalation process will be available however.Estimation Response is when the user that logged the ticket is informed of an estimated resolution time. Subsequent Responses is the frequency with which the user that logged the ticket is updated on the resolution status. Resolution is the point at which the problem is resolved and the application function is returned to a usable and available state. 13.5.4 Response and Resolution Service LevelsIf the system fails to meet any of the following Response and Resolution Service levels in a given calendar month, the response and resolution service will be reported as unacceptable and a 5% deduction will be assessed.TypeMeasurementProblem ResolutionLess than 90% of problems are resolved in the prescribed resolution interval.Response/EstimateLess than 90% of Initial Response, Estimation Response, and Subsequent Response times are met. Maximum Problem AgingNo problem is older than 180 days.13.5.5 Application AvailabilityAvailability is defined as the ability of an end user to access and execute any of the included application functions from a functioning workstation and live network connection. For an application to be available, all of its supporting systems must be operational. “Unavailable” or “Unavailability” means the users are unable to access the Service or use all the Service’s features and functions effectively and efficiently.Scheduled downtime will occur between 10 p.m. and 6 a.m. Eastern Time, Monday through Saturday. The Contractor may change the scheduled downtime to other non-business hours upon reasonable notice to and approval by ODJFS. Scheduled downtime will not be considered times when the Services are Unavailable. System Availability will be measure weekly, Sunday through Saturday and reported monthly. Application availability metrics will be measured/reported Monthly beginning go-live and through the first four months. Weekly measurement begins the fifth month after go-live. Excludes scheduled maintenance.Application LevelBusiness Hour AvailabilityOff-Hour AvailabilityScheduled Down-TimeDefinitionMonday-Friday 8 am – 5 pm ESTMonday-Friday 5:01pm-7:59 am EST; Sat. and Sun.Monday-Friday 10 pm – 6 am ESTCritical99.5% 99.5% To Be mutually agreed uponUrgent99% 98% To Be mutually agreed uponRoutine98% 98% To Be mutually agreed uponAny additional outages must be scheduled and approved by ODJFS at least two weeks in advance, unless there is an emergency.13.5.6 Application Availability Service LevelsIf the system fails to meet any of the following Availability Service levels in a given calendar month, the availability will be reported as unacceptable and a 5% deduction will be assessed. TypeMeasurementCritical Application AvailabilityAvailability falls below 99.5% for more than 2 days of the month during regular business hours.Urgent Application AvailabilityAvailability falls below 99% for more than 2 days of the month during regular business hours. Routine Application AvailabilityAvailability falls below 98% for more than 2 days of the month during regular business hours.13.5.7 Application Responsiveness Service LevelsOnline response time for this application. Response times are only applicable to the System, within the control of the Contractor or their subcontractors, as identified in this Contract.Online response time is measured as the elapsed time from when a request enters the UI Application gateway until the request has been satisfied and leaves the UI Application gateway. This includes processing times of all components covered under this Amendment which participate in fulfilling the request, including but not limited to Firewalls, Load Balancers, WAN/LAN Telecommunications Lines, Web Servers, and Application and Database Servers. The definition of a transaction is any system action that requires a screen to paint, refresh and/or system update to complete during normal operations. Mutually agreed to exception functions will be excluded from measurement.The Measurement interval is Monday through Friday 8 am – 5 pm EST. Metrics will be collected monthly beginning with go-live month 1 through 4, Weekly, thereafter; Measurements are to be reported monthly.If the system fails to meet any of the following Application Responsiveness Service levels in a given calendar month, the availability will be reported as unacceptable and a 5% deduction will be assessed.TypeMeasurementApplication ResponsivenessMore than 5% of transactions complete (via State network) > 4.0 seconds Application ResponsivenessMore than 1% of transactions complete in > 10.0 seconds ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download