System Specification. Project: SD Agreement Number:

Transcription

1 Project: SD Agreement Number: Title: International Registration Plan & International Fuel Tax Agreement System Requirements Analysis System Specification Submitted by: Submitted to: South Dakota Department of Transportation Office of Research, Room East Broadway Avenue Pierre, SD February 4, 2008

2 Contents 1. INTRODUCTION PROJECT DESCRIPTION NEW IRP/IFTA SYSTE OVERVIEW PROCUREENT CONSIDERATIONS DOCUENT REFERENCES SYSTE REQUIREENTS REQUIREENT PRIORITIES GR: GENERAL REQUIREENTS SA: SYSTE ADINISTRATION AP: ACCOUNT PROCESSING IF: IFTA PROCESSING IR: IRP PROCESSING F: FINANCIAL ANAGEENT IN: INVENTORY UI: USER INTERFACE WF: WEB FUNCTIONS QR: QUERYING AND REPORTING PR: PRINTING SF: SYSTE FUNCTIONS & SCREEN ELEENTS AR: SYSTE ARCHITECTURE SI: SYSTE INTERFACES DC: DATA CONVERSION SE: SECURITY D: DOCUENTATION, AINTENANCE, TESTING AND TRAINING APPENDIX A: GLOSSARY APPENDIX B: SAPLE CAB-CARD APPENDIX C: SDCARS SAPLE XSD APPENDIX D: SDDORR REITTANCE CENTER FLAT FILE SPECIFICATION APPENDIX E: SAPLE IFTA ADDRESS DATA ELEENTS FOR CEDAR APPENDIX F: IFTA QUARTERLY REFUND FILE DATA ELEENTS Iteris, Inc. I

3 1. INTRODUCTION In September, 2007, Iteris and the South Dakota Department of Transportation (SDDOT), Office of Research entered into Agreement Number This agreement describes a research project structured to perform a detailed requirements analysis for a new South Dakota International Registration Plan (IRP) and International Fuel Tax Agreement (IFTA) System. The current system, which is operated by the South Dakota Department of Revenue and Regulation (SDDORR), is supplied by a vendor and will no longer be supported effective the end of calendar year South Dakota has elected to replace the current system. This research project will provide the definition of system requirements supporting future South Dakota system development or system procurement actions Project Description The South Dakota International Registration Plan & International Fuel Tax Agreement System Requirements Analysis project was split into three phases. Each phase was characterized by an on-site visit followed by a draft and final report. The following table provides an overview of the project milestones and schedule: ilestone Date(s) Kick-Off Teleconference On-Site eeting # [On site meeting #1 encompassed a project kick-off meeting, working meetings with SDBIT, requirements gathering by the Iteris project team which included work with SD Prorate and IFTA License personnel, and one-on-one discussions with SDORR management. This activity formed the basis for Technical emorandum #1, Current Business Practices and System Actions.] Draft Technical emorandum # On-Site eeting # [On site meeting #2 focused on refining the draft version of Technical emorandum #1. This work primarily focused on one-on-one working sessions with SDORR management.] Finalized Technical emorandum # Draft Technical emorandum # On-Site eeting # [On site meeting #3 entailed review of the draft version of Technical emorandum #2, Detailed System Requirements.] Finalized Technical emorandum # Draft System Specification Written Comments from South Dakota Team Review Teleconference Finalized System Specifications On-Site eeting # Project Close-Out & Executive PowerPoint Presentation Iteris, Inc. 1

4 1.2. New IRP/IFTA System Overview System requirements for the new South Dakota IRP and IFTA system reflect the needs of a diverse group of stakeholders, including: SDORR Prorate, IFTA Licensing, Audit, Finance and anagement Personnel SDBIT Technical Personnel South Dakota otor Carriers otor Carrier Reporting Services The International Registration Plan embers & Clearinghouse The International Fuel Tax Agreement embers & Clearinghouse The Federal otor Carrier Safety Administration CVISN & PRIS Programs These stakeholders each have specific requirements which have been blended to provide a common platform from which IRP and IFTA transactions can be accomplished efficiently from within South Dakota agency offices and on the Internet by authorized motor carriers and reporting services. The following general system characteristics have framed development of the system specifications described within the document: odular / Relational / Open Design The new system shall be designed in a modular fashion, built upon a relational SQL database engine. The new system shall use a development environment characterized by use of an object oriented programming language such as C# and shall be compatible with the.net technology framework. Such design considerations shall provide system scalability, and a compatibility with nonproprietary software and hardware tools. Web-Based The new system shall be web browser based providing a consistent, shared, common user interface and navigation toolset. This approach shall provide a consistent look and feel for all system functions and for all users, both agency and public. Thin Client The new system shall employ a thin client network architecture, taking advantage of its web-based design characteristics to allow for system portability and access. Hosted by SDBIT The new system shall be physically hosted within SDBIT server farm facilities, with SDBIT providing physical database administrative and security / firewall functions. Common Customer Database The new system shall employ a common customer database capable of storing customer data for use in both IRP and IFTA processing. Iteris, Inc. 2

5 odern System-to-System Capability The new system shall support modern system-to-system architecture standards in order to provide non-proprietary sharing of IRP and IFTA data with other systems. Vendor Supported & aintained The new system shall be supported and maintained by the vendor in order to insure all business rules and processing functions remain in compliance with third party systems, procedures and specifications Procurement Considerations The success and quality of a project is highly dependant on the quality of the response to the request for proposal (RFP). Therefore, it is essential that the RFP contain the full breadth of requirements in sufficient detail for responders to clearly understand the desired end result and formulate a quality plan and design. Additionally, response quality will generally be improved when sufficient time is provided for questions pertaining to the RFP to be submitted and responses to be developed by the State of South Dakota. Lastly, the decision-making process for selecting the vendor will be enhanced if a common structure for responses is developed and responders closely adhere to this structure. In order to meet the above objectives, the following RFP timeline has been developed. (Note that specific dates are dependent upon the South Dakota procurement cycle.) Written Questions Due Question Responses Provided RFP Issued 10 days 5 days 10 days 25 days Preproposal Conference Call Proposals Due Key Procurement Cycle ilestones 1. RFP is posted and supplied to known vendors that can meet basic selection criteria. 2. Vendors supply written questions (within 10 days of initial RFP posting) 3. Pre-proposal conference call conducted (5 days after initial questions submitted). The purpose of the pre-proposal conference call is for South Dakota and potential vendors to reach a common understanding of questions in order for South Dakota to be able to prepare the most appropriate question responses. Additional questions can also be asked at this time. 4. South Dakota provides question responses. (within 10 days of pre-proposal conference call). 5. RFP responses due 25 business days after question responses have been provided. 6. Additional questions may be asked in writing up until 15 business days prior to proposal due date. South Dakota will endeavor to answer these questions within 5 business days. Iteris, Inc. 3

6 Response Outline The following items provide an example of the outline for vendor responses to the RFP: 1. Executive Summary (2 pages maximum) 2. Statement of qualifications. Provide descriptions of similar deployments in at least one jurisdiction and no more then 3 other jurisdictions. Each statement of qualifications should provide the following: Description of major tasks performed. Duration of project from notice to proceed through full acceptance of product. Reference contact information for jurisdiction: Name, telephone number, and address. 3. Project team. Provide organization chart and statement of experience for each team member (full resumes may be provided in an appendix). The statement of experience should include: Pertinent skills (e.g. software development, database skills, systems administration, systems engineering, software engineering, project management) Years of experience and education. IRP and IFTA process and systems knowledge. 4. Use a standardized requirements checklist that includes the following: Requirement Level of proposed solution adherence (I, P, C) included in base system, partially included in base system, or custom component. Comments. Freeform comments describing how each requirement will be met by the proposed system. 5. Project plan in the form of a icrosoft Project Gantt chart with tasks and subtasks of no less than 20 hours and no more than 80 hours each. 6. Sample maintenance agreement. 7. Cost Breakdown Cost of base system (Includes all requirements marked I) Itemized cost of upgrading partial compliance items to full compliance Itemized cost of providing custom items. Project management End-to-End Testing Training Data igration aintenance Iteris, Inc. 4

7 1.4. Document References Several documents and systems are referenced within these specifications. The following table provides a concise listing of these references and associated hyper-links to specific information sources: Source Document Discussion International Registration Plan International Fuel Tax Agreement Federal otor Carrier Safety Administration (FCSA) South Dakota CVISN Program South Dakota Bureau of Information and Telecommunications International Registration Plan IRP Clearinghouse Website Jurisdiction System Specifications IRP Clearinghouse Website Implementation Guide IFTA Articles of Agreement IFTA Audit anual IFTA Procedures anual PRIS System Specifications PRIS Procedures anual PRIS Cab Card Bar Code Specifications SAFER Interface Control Document SDCVIEW Interface Specifications SDBIT Hardware & Software Standards South Dakota is a member of IRP and the IRP Clearinghouse. South Dakota is a member of IFTA and the IFTA Clearinghouse. South Dakota has fully implemented PRIS requirements through its current IRP system and CVIEW. South Dakota has deployed a SAFER certified CVIEW system for exchange of carrier and vehicle information with SAFER. The current South Dakota IRP and IFTA systems exchange data with South Dakota CVIEW. All hardware and software deployed as part of the new IRP and IFTA system must meet SDBIT standards. 2. SYSTE R EQUIREENTS The tables in the following pages provide a comprehensive set of system requirements. The requirements are organized into sections, representing key IRP and IFTA system functional areas. These sections help provide structure to the variety of requirements, and are described briefly below: General Requirements (GR) Requirements in this section detail high-level system design and operation considerations. In addition, this section is intended to capture all requirements placed upon the new system from outside organizations, such as SDBIT, IRP, Inc., etc. Iteris, Inc. 5

8 System Administration (SA) This section discusses system administrator functions for supervisors, including setting system-level preferences, security privileges and other global system options. Account Processing (AP) Requirements for system functions required to create and maintain customer, account, fleet and vehicle records for use in the system. Note that these requirements are based upon both IRP and IFTA sharing a common customer database, while individual accounts for IRP and IFTA would be established. The intent is to allow a unique customer record to be associated with multiple accounts. IFTA Processing (IF) These are functions specific to IFTA processes including issuing of new licenses, renewals, quarterly returns, decal orders, IFTA transmittals, etc. IRP Processing (IR) These are functions specific to IRP processes including issuing new licenses, renewals, supplements, temporary authority, IRP transmittals, etc. Financial anagement (F) This section covers financial and accounting processes which apply to all SDDORR Prorate and IFTA activities, including month end reconciliations, cash receipts, payment processing, and billings. Inventory (IN) These are inventory control functions for both IRP and IFTA, covering prorate plates and IRP / IFTA decals. User Interface (UI) The section lists requirements for staff and public user interface, including screen navigation and transaction processing. Web Functions (WF) Details regarding public-facing web site which could be used by motor carriers and reporting services to accomplish IRP and IFTA functions. Querying and Reporting (QR) Descriptions of system features and tools for querying IRP and IFTA data. Descriptions of stock reporting functions and ad-hoc reporting. Example stock reports are included for information purposes, in Attachments 1, 2 and 3 of this document. Printing (PR) These requirements describe printing functions including IRP cab-cards, IRP and IFTA renewal notices and IFTA quarterly returns. Iteris, Inc. 6

9 System Functions & Screen Elements (SF) This section provides descriptions of screen elements used as part of major IRP and IFTA system functions. Screen shots from the current system are provided for information purposes, in Attachments 4 and 5 of this document. The screen shots are intended to provide some perspective on how the screen elements are used in various system functions. System Architecture (AR) The section provides system technical design considerations including hardware and software requirements, related to SDBIT standards. System Interfaces (SI) The section provides descriptions of all IRP and IFTA system interfaces. Direct, systemto-system interfaces as well as data extract and exchange interfaces are displayed. Data Conversion (DC) Details regarding data conversion requirements. Security (SE) General security requirements for all aspects of the system. Documentation, aintenance, Testing and Training (D) The section includes South Dakota requirements for documentation, maintenance, testing and training of the new IRP and IFTA system Requirement Priorities The following priority designators are used in the requirements tables in order to provide perspective on the relative importance of each requirement and how flexible South Dakota is regarding how each requirement is met: = andatory: andatory requirement that must have the functionality as described. = andatory / Flexible: andatory requirement however the implementation, or, how the requirement is met, is flexible. O = Optional: Optional requirement. Something that is nice to have. Implementation is flexible. Iteris, Inc. 7

10 2.2. GR: General Requirements ID # General Requirements (,,O) The system shall comply with South Dakota Bureau of Information and Telecommunications (SDBIT) standards. GR01 ( ) GR02 The system shall comply, and maintain compliance, with the operational and audit requirements of the International Registration Plan (IRP), as maintained by IRP, Inc. ( ) GR03 The system shall comply, and maintain compliance with the IRP Clearinghouse information exchange protocols and procedures. ( ) GR04 The system shall comply, and maintain compliance with the International Fuel Tax Agreement (IFTA) Articles of Agreement and Procedures anual. ( ) GR05 The system shall comply, and maintain compliance with the IFTA Clearinghouse information exchange protocols and procedures. ( ) GR06 The system shall comply, and maintain compliance with be the Federal otor Carrier Safety Administration (FCSA) Performance Registration Information Systems anagement (PRIS) program. ( )

11 ID # General Requirements (,,O) GR07 The system shall support South Dakota s Commercial Vehicle Information Systems and Network (CVISN) program. ( ) The system shall generate SAFER compliant baseline and update transaction sets for SDCVIEW baseline files and SDCVIEW snapshots (update files). These transaction sets include: GR08 Transaction Set T IFTA License Input Transaction Transaction Set T IRP Account Input Transaction Transaction Set T IRP Fleet Input Transaction Transaction Set T IRP Registration (Cab Card) Input Transaction See for XL specifications. Update transaction sets may be scheduled or on-demand. Baseline generation shall be on-demand. (Note: See IF 28 and IR 21 for more details.) GR09 All data stored and housed in the system shall remain the property of the state of South Dakota. GR10 The system shall be located in South Dakota SDBIT server facilities, Pierre, South Dakota. GR11 System shall rely upon commercial off-the-shelf (COTS) software with minimum modifications.

12 ID # General Requirements (,,O) GR12 The vendor shall have an IRP system already installed and operational in at least one jurisdiction. GR13 System shall be available 24 hours a day, seven days a week. Processing of IRP and IFTA transactions shall be accomplished in either batch or on-line (immediate) mode, selectable by the user. These transactions include: GR14 IRP Fee Calculations Invoice Printing Issuing Credentials Cab-Card Printing Generation of Title & Registration File to exchange with SDCARS (See requirement SI03.) Generation of nightly IRP Registration, IRP Fleet and IRP Account transaction sets for SDCVIEW. (See requirement IR21.) Generation of IRP Audit Address File (See requirement SI06.) IFTA Cab-Card Printing Issuing Decals Generation of nightly IFTA License transaction sets for SDCVIEW. (See requirement IF28.) Generation of IFTA Audit Address File (See requirement SI06.) Generation of IFTA Refund File (See requirement SI06.)

13 ID # General Requirements (,,O) GR15 Batch processing procedures shall allow for skipping failed transactions and allowing subsequent transactions to be processed. GR16 Skipped or failed transactions shall be archived and reported to the System Administrator within an error report. GR17 The system shall create a unique transaction number for all transactions. O GR18 The system shall log all application errors whenever possible to the centralized error logging facilities. The error information, besides containing detailed information about the error and the component that the error occurred shall also include information about the user that received the error and the machine/location of where the problem occurred. The system shall send out auto-notification of error logs and error reports via to system administrators. (Processing failures.) GR19 All transaction dates shall be system generated. GR20 The system shall inactivate accounts and generate accompanying CVIEW snapshot upon expiration of a predetermined timeframe. GR21 The system shall include context sensitive help screens for both agency and public users.

14 ID # General Requirements (,,O) GR22 The system shall provide for metric conversions. GR23 The system shall allow users to access other portions of the application without losing previously entered data and without the user retracing each step of the transaction. GR24 System includes drop down menus, step-by-step instructions or similar features needed to make the system simple to use and understand. GR25 System shall allow users the ability to make corrections based on the user s security level. GR26 The proposed system shall support a core of approximately 6 fulltime internal users, and a potential internet application customer/user base of approximately 700; the system shall be capable and scalable to accommodate the annual growth of the customer base as well as the internal users. The system shall provide for and support the ability to control batch job execution by time of day, date, processing cycle (weekly, GR27 monthly, yearly, quarterly, on request, etc.).

15 2.3. SA: System Administration ID # System Administration Requirements (,,O) SA01 The system shall allow for administrative personnel to view, edit and change previously input information. SA02 The system shall allow administrators the ability to create and maintain access privileges at the individual user, group, menu, and screen levels. SA03 Administrators shall have the ability to check status of pending transactions. SA04 Administrators shall have the ability to create and edit system flags which can be applied to accounts, vehicles and transactions. (Examples include suspension codes related to accounts and vehicles.) SA05 The system shall allow system flags to have either user-selectable expiration dates, or never expire. SA06 System administrators shall have the ability to view all system activity and terminate selected sessions, as required. O SA07 Administrators shall have the capability to view batch queues, cancel or re-prioritize individual transactions within a queue. O

16 ID # SA08 System Administration Requirements The system shall provide an administrative interface to set administrative fees, penalties, interest, excise tax rates and other miscellaneous fees. The following South Dakota fees apply: Plate and Decal $ Lost Plate and/or Decal $ Lost Cab Card $ 3.00 Solid Waste Fee $ 1.00 (Assessed when plate or decal is issued. Not assessed when duplicate is issued.) ailing Fee $ 3.00 (Automatically assigned when plate or decal is issued.) Title Fee $ 5.00 (anually assigned) Lien Fee $ 5.00 (anually assigned.) Transfer Fee $ 3.00 Refund Fee $ 5.00 Notes on Penalties & Fees 1. There is a manually assigned penalty of $20.00 per vehicle that was assigned a temp and the application was not fee calculated within 20 days of the temporary issuance. 2. Excise Tax - Excise tax is charged on a transfer and is calculated as follows: (Purchase Price - Trade in Price) *.03 * South Dakota Percentage. There should be override capability for this fee. Penalty and interest is assessed on the excise tax amount if the title is being transferred late. Interest would be minimum $5.00 the first month or 1.25%, whichever is greater and 1.25% each month thereafter. Penalty is a one time assessment of a minimum $10.00 or 10%, whichever is greater. 3. There is an apportioned plate that will not be tracked in the inventory system. There is no charge for issuance of this plate but there is a $10.00 replacement charge (manual fee). 4. South Dakota charges penalties and interest to carriers that have had temporary authorities issued and have not paid their invoice within 30 days. These penalties are only assessed to the units that have had the temp issued. Interest is assessed at 1.5% of the total unpaid balance for that unit or $5.00 which ever is greater and penalty is 10% of the total unpaid balance for that unit or $10.00 whichever is greater. Some carriers are required to place a deposit per unit for Temporary Authorities. These deposits shall be subtracted from the total unpaid balance for the unit before penalty and interest is calculated. 5. If a title is not transferred by a certain time, a late penalty is charged using the number of late weeks entered at the unit window. The penalty is $1.00 * # of late weeks up to 25 weeks. After 25 weeks, the penalty is a flat $50.00 per vehicle. 6. South Dakota charges penalty and interest for non sufficient funds (NSF) payments. The penalty is $30.00 and interest is assessed at 1.5% beginning 30 days after the Notice of Dishonor is sent. The time period on this will have to be something that is established for billing of interest. (,,O)

17 ID # System Administration Requirements The system shall allow for creation and modification of custom screen edits and messages by the system administrator. (Double check SA09 entry amounts, for example.) Vendors shall list system capabilities for creating and modifying screen edits. SA10 System shall allow for creation of maintenance of multiple Fuel Types. Fuel types used by IRP system must be: A - Alcohol B - Hybrid Gas/Electric C - Convertible Gas D - Diesel E - Electric F - Flex Fuel G - Gasoline H - Ethanol - ethanol N - Natural Gas O - Other P - Propane S - Solar Z - Zero/Not Powered (,,O) SA11 Fuel types used by IFTA system can be whatever the future system is set-up to use. O SA12 The system shall provide the administrator ability to assign account numbers to specific SDDORR Prorate Office staff. O SA13 The system shall allow the administrator to create summary reports showing accounts sorted by SDDORR Prorate Office staff. O

18 ID # System Administration Requirements (,,O) SA14 The system shall allow for creation of canned correspondence incorporating state letterhead. O SA15 The system shall allow for creation, modification and expiration date, if applicable, of status codes for all account transactions, including IRP supplements and Temporary Authority. (Create code number and associated text.) SA16 The system shall allow for creation of an annual Estimated IRP ileage Listing using previous registration year reported mileage, in accordance with the IRP Plan, maintained by IRP, Inc. SA17 System shall be designed to allow for creation of a set of standard comments to be associated with accounts. Each standard comment will have a unique comment code. SA18 System shall allow generation of reports showing accounts with certain comments. O SA19 System shall allow generation of reports showing accounts, sorted by comments. O SA20 System shall allow for archiving of data.

19 ID # System Administration Requirements (,,O) SA21 The system shall provide for the following IFTA-specific system administrator preferences: Billing System shall generate a billing notice after 30 days of an amount becoming due. A 2nd billing notice shall generate 30 days after the 1st billing notice is generated. Thirty days after the 2nd billing notice is generated, the account shall be revoked and a revocation notice will be generated. System shall allow for setting lead times on various notices and allow for billing thresholds. Returns The system shall allow for setting of high and low PG warning limits and errors and warnings for exceeding gallonage thresholds. Set grace period. Set high and low PG warning limits. Errors and Warning for calculations of gallonage. Interest System shall allow for interest rates to be established and identify how interest will be assessed and frequency. Set annual interest rates. (Receivable Payable) Select compounding parameters. (Applied to principal, penalty, interest. Compounding frequency.) Set interest calculation parameters. (Unpaid balance, original balance.) Penalty Set penalty parameters. (Percentages, fees, penalty assessment calculation rules and parameters.) Refunds inimum refunds limit. Refund approval limits. Payments System shall allow IFTA payments to be prioritized to apply to oldest tax first, then interest then penalty. Payment application prioritization. Remittance Codes Adjustments, Audits, Credits, etc.

20 ID # System Administration Requirements (,,O) SA22 The system shall provide the following general IRP administrative maintenance functions. (Note: Vendors should respond to each of the items listed numbered below by stating how the proposed system provides the administrative maintenance functions.): 1. User ID aintenance: This function allows an administrator to add, delete or change information about a particular user including passwords. 2. Status Code aintenance: User defined status codes. 3. Inventory aintenance: Adjust inventory items. 4. Transmittal Receipt Funds: This allows the user to break apart IRP transmittal receipts and display the various categories to which the fund is distributed. 5. Screen Security: Control screen access and entry based upon security level. 6. Canned Comments: User defined comments. 7. Administrative Overrides: This allows administrators to re-issue IRP credentials and delete or clear pending IRP applications: 8. Escrow and Deposits: anage account escrow or deposit balances. 9. Estimated ileage: This provides the functionality of creating estimated mileage tables for the current processing year. 10. Exchange Rate aintenance: anage exchange rate and date of implementation. 11. ake Table aintenance: This allows an Administrator to enter any new makes to the relational database tables. A list of current makes is displayed and is sorted in alphabetical order. 12. Printer Assignment: This allows an Administrator to select the printers for registration year and designated processes. 13. Yearly Rollover aintenance: This allows the administrator to run the rollover procedure for a new registration period. Information such as the jurisdictions, weight groups and active vehicles are copied into the next registration period. 14. Renewal Reconciliation Process: After the Rollover procedure has been run, customers still have the ability to make changes to the previous period s accounts. The renewal reconciliation allows the user to move any changes from the previous period(s), after the rollover to the current period. 15. Renewal Print: After the rollover procedure has been run, the administrator can launch a renewal print job to print renewal notices and a renewal label print job.

21 ID # SA23 System Administration Requirements The system shall provide for the following IRP system administrator overrides. (Note: Vendors should respond to each of the items listed numbered below by stating how the proposed system provides the administrative maintenance functions.): 1. Change Fleet Registration Cycle (Only for accounts that have no billings associated with it.) 2. Allow for issuance and/or billing of all administrative fees to be turned on or off for individual accounts. 3. Delete / Clear Supplement 4. Undo Plate / Decal Issuance 5. VIN Correction (,,O) SA24 The system shall allow users to create ad-hoc account comments to print on a billing notice or late notice, or both. O SA25 The system shall allow system administrators the ability to design the layout for billing notices and late notices. SA26 The system shall allow users to manually override PRIS checking for specific IRP transactions. SA27 The system shall allow system administrators to enter an account inactivity time frame to be used to automatically suggest account inactivation. SA28 System administrators shall have the ability to assign a customer code to customer accounts. Such codes will be used to determine the level of web interaction allowed the customer. (i.e. Issuing temporaries.)

22 ID # SA29 System Administration Requirements The system shall allow for maintenance of IRP fee tables and IFTA tax tables for jurisdictions. (Vendor will be contracted to provide maintenance of IRP fee tables.) (,,O) SA30 The system administrators shall be able to delete an account SA31 The system shall have the ability to define edits as "hard (stop & correct) or "soft (warning & OK). SA32 The system shall have the ability for remote monitoring and administration of all applications. SA33 Administrative staff shall have the ability to change the status for a range of temporaries or an individual TA. SA34 Administrative staff shall have the ability to assign specific plate number(s) from the available inventory in the system. SA35 Administrative staff shall have the ability to change the status for individual plates or a range of plates.

23 2.4. AP: Account Processing ID # Account Processing Requirements (,,O) AP01 The system shall have the ability to generate unique account numbers for IRP accounts and unique account numbers for IFTA accounts. AP02 System messages should warn staff when IRP or IFTA account status precludes account transactions. The system shall have the following record structure: Customer (Customer is unique based upon TIN.) AP03 Account (Account type shall distinguish between IRP and IFTA Customer can have multiple accounts.) Fleet (Account can have multiple fleets.) Vehicle (Vehicles are unique based upon VIN.) System shall allow for multiple owners and officer information to be associated with a single account. Owner and officer information will include: Title, or Capacity AP04 Social Security Number Name Address Phone AP05 System shall allow for associating Reporting Services to Accounts for purposes of billing and communications. Note: The system shall accommodate different Reporting Services for IRP and IFTA, within an Account, if required.

24 ID # AP06 Account Processing Requirements System shall allow for specifying either the reporting services or account holder, as receiving IFTA renewals and returns. Note: IFTA licenses always to go to the taxpayer. (,,O) AP07 System shall allow for specifying either the reporting services or account holder, as receiving IRP renewals, billings and credentials. AP08 System shall have the capability to save multiple address types for a given customer and account record. (i.e. ailing, Physical, Reporting Service) AP09 System shall allow for user to distinguish between types of TIN. (Employer Identification Number or Social Security Number.) AP10 System should provide an error check to notify staff if new account TIN is associated with another account. AP11 System should prompt user to use standardized naming convention, if entered other than standard. AP12 System shall allow staff to scan documents at any time and attach the file to a customer s account information electronically. O AP13 System shall track all changes to account data. A report reflecting these changes shall be available to view and print electronically from within the system. O

25 ID # Account Processing Requirements (,,O) AP14 The system shall enable a customer record to be saved with one legal name and multiple DBA names. AP15 The system shall enable a customer to be of a Corporation, Partnership, LLC, Individual or Other type Organization. AP16 The system shall enable the customer record to have multiple active addresses of the type IRP or IFTA. The system shall enable the customer record to have multiple active types of contact information, including , fax number, business AP17 phone and home phone. AP18 The system shall enable the account record to have the following types of account identification: USDOT# and FEIN. AP19 The system shall enable users to create and update all customer and account records. AP20 The system shall have the ability to relate an account to multiple fleets and vehicles.

26 ID # Account Processing Requirements (,,O) AP21 The system shall display a history of company and account status including status effective date. Remainder of page left blank intentionally.

27 2.5. IF: IFTA Processing ID # IFTA Processing Requirements (,,O) System shall conduct an up-front edit to determine all required data fields have been completed and when possible, the data entered is IF01 accurate. IF02 System shall provide a unique message for each type of error that clearly defines the error. IF03 System shall allow for the automated import and update of IFTA tax rate information from the IFTA website. ( ) O IF04 Temporaries: The system shall be able to generate and print temporary IFTA licenses as a separate transaction. O IF05 The system shall allow for the issuance and tracking of temporary IFTA decals by account. IF06 System shall allow for IFTA accounts to be designated as annual filers. IF07 System shall allow for processing of quarterly IFTA returns. IF08 The system shall allow for electronic filing of IFTA returns by means of file exchange with third party software. O

28 ID # IFTA Processing Requirements (,,O) IF09 The system shall provide for capturing IFTA mileage from quarterly returns for comparison to IRP reported miles. O IF10 The system shall allow for processing of returns by means of manual entry by IFTA Licensing staff. IF11 The system shall allow for processing of IFTA returns and IFTA payments using files created by the SDDORR Remittance Center. (See Requirement SI05 for more information.) IF12 System shall provide contiguous state checks for both IFTA return processing. O

29 ID # IF13 IFTA Processing Requirements The system shall provide the ability to upload flat files of IFTA quarterly returns and to error check the IFTA quarterly returns. (See Appendix C for Remittance Center Quarterly Return Flat File formatting.) The system shall perform the following automated error checks on each record in the Remittance Center Return File at the time of upload: The Filing Date should be within the last 60 days. No valid tax rate found for the given Jurisdiction / Fuel Type / Period. Tax Paid Gallons exceeds Taxable Gallons (Check for all fuel types.). Line item entry has previously been transmitted or amended. Duplicate Line Item. Surcharge Line Item not present. Unknown jurisdiction. Invalid fuel type for jurisdiction. Invalid fuel rate. Total iles is less than Taxable iles. Purchased fuel without driving. Taxable Gallons = 0, Tax Paid Gallons > 0. Taxable Gallons minus Tax Paid Gallons not equal to Net Taxable Gallons. Tax plus Interest not equal to Total. Summary miles not equal to Line Item miles for fuel type. Summary gallons not equal to Line Item gallons for fuel type. iles divided by Gallons not equal to PG. PG for this fuel type equals or exceeds high PG value. PG for this fuel type does not meet minimum PG value. Applied for fuel type but Line Item not present. (issing fuel entry based upon fuel types selected on application.) An error report shall be generated indicating failures by record. (,,O) IF14 The system shall allow for IFTA users to view details of all IFTA reporting periods for each account. IF15 The system shall support split tax rates when uploading tax matrices, printing and processing IFTA returns.

30 ID # IFTA Processing Requirements (,,O) IF16 The system shall allow processing of renewals, generation of IFTA cab cards and issuance of decals on-line or in batch mode. IF17 The system shall allow for annual and ad-hoc renewal of IFTA accounts. IF18 Reinstatement of IFTA account shall use previous account information, auto-populated. IF19 The system shall have provision for storing IFTA cancellation and reinstatement dates for each account. These dates shall be used for determining tax liability and quarterly filing requirements. IF20 System administrators shall have the ability to adjust IFTA total dollar amounts, and add IFTA audit amounts by jurisdiction to be incorporated into IFTA Clearinghouse file. IF21 The system shall maintain account balances for IFTA jurisdictions based upon incoming transmittals and South Dakota activity. O IF22 System shall allow for the manual entry of incoming IFTA transmittals. O

31 ID # IFTA Processing Requirements (,,O) IF23 System shall allow for the automated generation of the IFTA clearinghouse file, weekly IFTA demographic file and summary file. In addition, the system shall allow for generation of paper transmittals for all or one jurisdiction and only non-clearinghouse participants. IFTA transmittal letters shall show, at a minimum, the following information: Jurisdiction name and address. IF24 Transmittal period. South Dakota Transmittal Amount (Amount from SD IFTA activity.) O IF25 Transmittal totals shall be stored on the system and available to view by month, year or jurisdiction. IF26 The system shall have the ability to regenerate any previous transmittal, and to save the transmittal reports to a text file. IF27 The system shall provide the ability to track and maintain IFTA decals by year. IF28 The system shall generate daily SAFER compliant T0019 transaction set based upon the following IFTA system transactions: New License Account Changes (Address, Phone, etc.) Renewals Account Status Changes (Revocations, Reinstatements) (See Requirement SI01 for more information.)

32 ID # IFTA Processing Requirements (,,O) IF29 The system shall have the capability to generate a SAFER compliant T0019 baseline transaction set, on demand. IF30 The system shall have the capability to generate a SAFER compliant T0019 transaction set for one account, without making any changes to the account, on demand. IF31 The system shall able to allow for the capability enter a tax assessment or tax liability owed by a taxpayer who fails to file a tax return. The system must allow the assessment to be reversed if the taxpayer files the delinquent return. O IF32 System shall be capable of automatically printing: Jeopardy Assessment Letters Distress Warrant Letters Tax Lien Letters Tax Lien Release Letters O IF33 System shall be set-up to run monthly interest assessment job to add interest to outstanding IFTA account balances. IF34 The system shall allow for processing of a reverse transaction in the case of a billing error, or any other adjustment on a taxpayer s account, by specifically authorized IFTA Licensing staff.

33 ID # IFTA Processing Requirements (,,O) IF35 The system shall have the ability to create, manage and track bonds posted by IFTA account holders. IF36 The system shall allow for creation of a billing notice for IFTA decal orders. O IF37 The system shall generate quarterly refunds for all carriers who have amounts owed from South Dakota for a specified date range. The refund process shall generate a file for transmission to the State Auditor s staff for generation of a warrant. (See Requirement SI06 for more information.) IF38 The system shall have the following printing capabilities: Renewal Notices Billing Notices IFTA Quarterly Returns IFTA Annual Returns (Annual Filers annual filing of four quarterly returns.) Non-Filer Notices Revocation Notices Refund Notices

34 2.6. IR: IRP Processing ID # IRP Processing Requirements (,,O) IR01 System allows assignment of multiple vehicles as a group from one fleet to another fleet. O IR02 System allows the assignment of one vehicle at a time from one fleet to another fleet. O IR03 The system shall allow for moving vehicles to and from weight groups. IR04 System allows issuance of registration documents (credentials) for each power unit and trailer registered. IR05 System has estimated distance, (distance estimates multiplied by the number of units), contained within the system and calculated according to the IRP Plan. IR06 System allows printing of the estimated distance chart. IR07 System automatically enters the estimates into the distance data fields when an applicant needs an estimate, eliminating the need for users to manually enter the data. ust allow the ability to over-ride for automatically entered estimates. IR08 System automatically calculates second year estimates as required by the IRP plan.

35 ID # IRP Processing Requirements (,,O) IR09 The system shall automatically assign plate numbers, by account number, in numeric order, from the inventory available from the system application. IR10 The proposed system shall prohibit the registration of a vehicle at a weight in excess of the maximum weight allowed by a jurisdiction. System shall automatically change the weight so user doesn t have to determine what the weight should be. IR11 System shall provide contiguous state checks. IR12 System shall have the ability to create and manage weight groups within fleets. IR13 System shall provide an automated warning to staff when an entered weight is ± 10% for each IRP jurisdiction, unless the weight in greater than 80,000 pounds. IR14 System shall have a step to manually enter mileage to validate the mileage calculated matches mileage reported. IR15 Automated error checks shall include no mileage jurisdictions and zero weights in jurisdictions.

36 ID # IRP Processing Requirements (,,O) IR16 The system shall not auto-populate VIN fields. IR17 The system shall use the South Dakota VINA system, or vendor-supplied equivalent, to VIN check data entry. System shall provide onscreen warnings of VIN errors. IR18 The system shall use the South Dakota VINA system, or vendor-supplied equivalent, to auto populate vehicle year, make and model. IR19 PRIS Processes shall include: Capture of USDOT# and Taxpayer ID for the Safety Carrier. Validation of Safety Carrier s USDOT #. Checking CSIP Status of Safety Carrier. Checking Vehicle out of service status. Checking CS-150 last update date of Registrant and Safety Carrier At time of renewal, printing CS-150 forms for those Safety Carriers who have not updated their CS-150 in more than a year. Print PRIS compliant bar code on cab cards and temporaries. (See Requirement PR07 for more information.) IR20 ust be able to upload the Carrier, Census and Target files from the PRIS Central Site. Automated downloading of these files is Optional.

37 ID # IRP Processing Requirements The system shall be designed so that PRIS processes will automatically check account and vehicle status during the following transactions: New Registration IR21 IRP Renewals VIN Changes Add Vehicle Reinstating Vehicles (,,O) The system shall generate daily SAFER compliant T0020, T0021 and T0022 transaction sets based upon the following IRP transactions: New Registration Supplements IR22 Renewals Account Status Changes (Suspensions, Inactivation, etc.) (See Requirement SI01 for more information.) IR23 The system shall have the capability to generate a SAFER compliant T0020, T0021 and T0022 baseline transaction set, on demand. IR24 The system shall have the capability to generate a SAFER compliant T0020, T0021 and T0022 transaction sets for one account, without any changes to the account, on demand. IR25 The system shall be able to generate and print temporaries for new units, added jurisdictions, weight changes, replacement cab cards or plates.

38 ID # IR26 IRP Processing Requirements The system shall provide an automated warning to staff when a temporary IRP registration is being issued within a specified window of time before the end of the account s registration year. (,,O) IR27 System shall have a step to manually enter mileage to validate the mileage calculated matches mileage reported. IR28 Automated error checks shall include no mileage jurisdictions and zero weights in jurisdictions. IR29 The system shall process a Delete Unit transaction. The system shall allow for the unused SD portion to be refunded or a transfer of all jurisdictions fees based on jurisdiction requirements. IR30 The system shall allow for a VIN correction to be processed by an operator. Note: A VIN correction shall be subject to the PRIS process and also create a T0022D (SAFER compliant delete transaction set) and a corresponding T0022 SAFER compliant transaction set, as required. IR31 The proposed system shall provide the capability to issue and print Temporary Authorities (TAs), correspondence and billing notices directly from the system via telephone facsimile, supplied by the vendor, and by . IR32 The proposed system shall provide the capability to void a supplement and provide audit trails for the void of the supplement.

39 ID # IRP Processing Requirements (,,O) IR33 The proposed system shall allow access to unpaid supplements, and modification of non-fee-related information as determined by SDORR Prorate Staff without requiring a recalculation of fees. IR34 The proposed system shall allow more than one unpaid supplement at a time. The system shall allow more than one type of transaction to be processed on the same supplement (for example, add jurisdictions and IR35 vehicles in the same supplement, replace plates on a renewal, and add/delete vehicle with replacement plates). The system shall process the following supplement types: New Account New Fleet Renew Fleet Amend Fleet Add Vehicle Transfer Vehicle IR36 Delete Vehicle Correct Vehicle Add Jurisdiction Change Vehicle Weight Replacement Credentials Change Owner Name Change Fleet Name Refunds

40 ID # IRP Processing Requirements The system shall automatically assign sequential supplement numbers. New Accounts, New Fleets and Renewals are Supplement IR37 Number (,,O) IR38 The system shall use the Canadian exchange rate based on supplement effective date. The system shall provide operators the ability to select or de-select credential indicators when processing transactions. (i.e. Issue decals, IR39 issue plates, etc.) IR40 The system shall allow for issuing of credentials (decals, plates) in batch mode or on demand. IR41 Printing of credentials shall be either by batch mode or immediate, on-line. IR42 Printing credentials shall support multiple printer locations. System shall be set-up to assess run monthly interest and penalty assessment job to add interest to outstanding IRP account balances. IR43 Penalty is assessed once and interest is assessed monthly. System shall allow for processing of deposits. Deposits are applied to a billing, tied to a specific vehicle or fleet and are deducted from IR44 the total billing amount due. IR45 System shall allow for creation of escrow accounts.

41 ID # IRP Processing Requirements (,,O) IR46 The system shall allow authorized users to waive or reduce penalties and in limited circumstances fees as needed. The system shall have a mechanism to track and record the reason for waiver and the authorizing party. System operators shall have the ability to specify the level of detail to be printed on billing notices. (i.e. Giving unit specific IR47 information.) IR48 Billing notices should reflect credits on all the detail pages. (i.e. Vehicle credits.) IR49 The system shall have the ability to track credits, deposits and escrow balances, per account. The system shall have the ability to enter IRP audit amounts, by jurisdiction, and include the entered amounts in transmittals. The IR50 entered IRP audit amounts shall be identified as an audit transmission and must be included in the IRP Clearinghouse file. IR51 System shall have the capability to create a reverse application transmittal for submission to the IRP Clearinghouse. IR52 The system shall provide for printing of IRP recaps and transmittals upon demand, for non-clearinghouse jurisdictions. IR53 System provides transmittals/recaps, via both paper and electronic means, for each IRP member jurisdiction, which show the distance and weights declared in those jurisdictions for the fees charged on their behalf in accordance the IRP Plan and in accordance with the Clearinghouse File layout.

42 ID # IRP Processing Requirements (,,O) IR54 Transmittal totals shall be stored on the system and available to view by month, year or jurisdiction. IR55 The system shall have the ability to regenerate any previous transmittal, and to save the transmittal reports to a text file. IR56 The system shall be designed to handle quarterly staggered renewal cycles. (February, ay, August and November.) IR57 The system shall allow for rolling over all active units and jurisdiction for the new registration year. Remainder of page left blank intentionally.

43 2.7. F: Financial anagement ID # Financial anagement Requirements (,,O) The system shall utilize South Dakota s electronic payment system for on-line payment of IFTA and IRP bills. South Dakota has contracted with US Bank to provide E-Payment services. A brief overview of the electronic payment system follows: F01 The IRP / IFTA system shall perform IRP and IFTA specific tasks up to the point where the on-line customer makes a payment. The IRP / IFTA system shall be responsible for authenticating the consumer, determining the total amount due, and uniquely identifying the payment transaction. At the point in the process when the on-line customer is ready to pay, the customer will click a "Pay Now" or similarly named button and be linked to the US Bank E-Payment Service site where the customer is presented with a welcome page that is branded with the SD Department of Revenue banner. The US Bank site will collect detailed payment information and process the payment. The vendor is expected to work with a US Bank EPay Integrator to specify and test the customization of the US Bank E-Payment site and the data that is transferred and received. (See Requirement SI08 for more information.) F02 The system shall allow for processing of IFTA payments to be applied to the oldest outstanding tax. F03 IRP renewals shall be paid before payment may be processed for any outstanding IRP supplement billing notices. F04 The system shall provide separate IRP and IFTA ledgers showing account balances and activities. F05 System shall calculate IRP fees while allowing production work to continue without any decrease in response time. F06 System allows internal users to post multiple IRP supplements/billing notices within the same IRP account at one time.

44 ID # Financial anagement Requirements (,,O) F07 The system shall have the capability to back-out a previously billed IRP transaction. F08 The system shall have the capability to back-out a previously paid IRP bill, if fees have not been transmitted. F09 The system shall allow for creation of ad-hoc billings for IRP administrative fees. F10 The system shall provide a display of all IRP billing notices for review by staff, prior to printing or saving to batch. O F11 The system shall allow for manual adjustments to IRP billing notices, after creation. O At a minimum the system shall allow authorized users, based on the user s security level, to: Reprint an original billing notice. F12 Change/void a payment. Change/void incorrect transmittal information. Change/void a payment adjustment. Void a billing notice. F13 The system shall allow for SDDORR Prorate staff to insert ad-hoc comments for individual billing notices. O

45 2.8. IN: Inventory ID # Inventory Requirements (,,O) The system shall provide inventory control of South Dakota prorate plates and South Dakota trailer plates, by location. The system must be able to identify the number or power unit and trailer plates that have been issued each year. South Dakota issues permanent trailer IN01 plates. Trailer plates are issued on new units or when ownership of the unit changes. Power unit plates are typically for a period of 5 years with new issues occurring in a 5 year cycle or whenever the plate design changes. The yearly validation decals that print with the cab card contain the year and the plate number so no decal inventory is necessary. IN02 The system shall allow for user creation of either one or multiple inventory locations, with effective dates, for each inventory item. IN03 The system shall allow for user creation of either one or multiple inventory years, with effective dates, for each inventory item. IN04 System tracks the plate number issued to the vehicle, and maintains an inventory of plates remaining on hand. Remainder of page left blank intentionally.

46 2.9. UI: User Interface ID # User Interface Requirements (,,O) UI01 System shall be designed with a browser-based interface. The system shall provide users with a user-profile capability in which users store system preferences, ad-hoc reports, and system UI02 queries and manage other profile information. System shall provide an interface to staff programs to provide a seamless method for electronic communication with single or UI03 multiple account holders within the system. An example would be announcements to the general account holders, or asking for further documentation from a particular account holder. O O UI04 System shall be designed to allow for creation of ad-hoc comments at any point in processing. Comment to be applied to the account. O The system shall be scaled to allow for transaction processing, processing of reports, system jobs and system-to-system processes, during UI05 business hours, without degradation to user sessions. The proposed system shall provide the capability to retain entered information on a screen when it becomes necessary to revert back to a UI06 previous screen for some reason. The proposed system shall provide a way to change or remove a vehicle entry when an error is made, prior to processing the billing or UI07 payment.

47 ID # User Interface Requirements The proposed system shall provide "fast path" (shortcut / hot keys) capabilities to eliminate the need to return to the main menu each time UI08 another function is required (for example, enter payment, go directly to credentials processing, and provide billing notice after fee calculation). (,,O) O UI09 The proposed system shall automatically pre-fill the city, state and county fields upon entry of a zip code. O It is desired that the proposed system automatically pre-fill the factory price of a vehicle based on the Colorado Factory List Price (FLP) UI10 or comparable, table. The system shall have edits immediately on each page/screen rather than waiting until the entire supplement is submitted before edits are UI11 performed. UI12 All transactional data shall have time, date, and user ID stamps. A transaction log will be maintained to track processing actions. UI13 The system shall have the ability to open multiple screens/windows/sessions concurrently. UI14 The system shall have the ability to use online drop-down lists of all valid values for each validated field. UI15 The system shall have the ability to highlight or otherwise identify required elements upon transaction entry. UI16 The system shall have the ability to accommodate data validation upon data entry.

48 ID # User Interface Requirements (,,O) The system shall provide for and support a consistent GUI across all components and provides a common look and feel across all modules, including: Consistent function keys UI17 Screen naming functions Navigation patterns enus (as defined by security profile)

49 2.10. WF: Web Functions ID # Web Functions Requirements (,,O) System shall allow for setting public user privileges for changing fields of information on the public facing web site. (i.e. Company WF01 name cannot be changed by public user, while address, phone, etc., may be changed.) WF02 System shall allow for authorization of activity on numerous accounts based upon a single sign-on. WF03 System shall allow for setting which data fields are displayed on the public facing web site. WF04 IRP web functions shall include: Create New Account Create Fleets Add Vehicles anage Fleets New Licenses IRP Renewal IRP Supplements & Temporaries (Apply & Print Temporary Registration) Create Billing Notices (Hard copy & Electronic) Payments (See Requirement F01 for more detail.) Select Electronic Payment Date Report Generation SDORR Prorate Office Staff Track Status of Transactions Track Account Balances Print Hardcopy of All Completed Paperwork Note: Some processes cannot be completed without paperwork being submitted. The system must allow the designation of those items on individual transactions. The system must allow for an interview process so that users may determine what paperwork is required to be submitted to SDORR, before initiating the transaction.

50 ID # Web Functions Requirements (,,O) System shall have process points which will allow for IRP application work to be saved and users to send information into SDORR WF05 Prorate Office before commencing with the next step. WF06 IFTA web functions shall include: Create New Account New Licenses (Allow E-Filers to request no printed IFTA returns.) IFTA Renewals Print Previously Filed Returns File Current Quarter IFTA Returns (Import previous quarterly return to serve as a template for current quarter.) Create Billing Notices (Hard copy & Electronic) Payments Select Payment Date Temporary IFTA Decals (Apply & Print Temporary) Order IFTA Decals Show total amount due or credited. Track Status of Transactions Track Account Balances E-ail SDDORR IFTA Licensing Staff System shall allow for processing and accumulating multiple IRP and IFTA transactions in a shopping cart for review prior to WF07 submission and billing. (For example; a carrier would be able to both renew an IFTA license and add a vehicle to an existing fleet.) WF08 System shall have all edits and checks used for SDDORR Prorate and IFTA Licensing staff processing, functional for public users.

51 ID # Web Functions Requirements System shall allow for notifications of past due paperwork submittals, past due billing notices, account revocations, past due WF09 billing notices, IRP and IFTA renewals and other selectable account activities. System shall allow for notification sent regarding change in transaction status. (For example; a new IFTA license application has WF10 been approved.) (,,O) O O WF11 System shall check IRP and IFTA status before allowing changes or processing of any transactions. WF12 System shall perform PRIS checking on applicable transactions, as noted in Requirement IR20. The system shall have the ability to automatically SD prorate staff when a new account application is received or when a WF13 transaction has occurred requiring SD prorate staff approval. WF14 The system shall have the ability to upload files and attach to transactions to be submitted to IRP and IFTA staff. O The system shall have the ability to automatically users with reminders for upcoming events, such as renewals, expiration of WF15 temporaries, etc. O WF16 The system shall provide users with the ability to track status of various transactions by account. WF17 The system shall be designed to be browser independent.

52 ID # Web Functions Requirements (,,O) The system shall have the ability to allow customer users to set up and maintain their own Internet user accounts including setting and WF18 changing their passwords in the system. WF19 The system shall provide a means for sending questions and comments to SDDORR IRP Prorate or IFTA Licensing staff. O The system shall provide users with a history of transactions, including previously filed IFTA quarterly returns and previously processed WF20 IRP transactions. The system shall provide users with the ability to copy previous registration year s fleets, vehicles and jurisdictions into the current WF21 registration year when renewing. WF22 The system shall warn on duplicate VIN records using VINA or equivalent. WF23 The system shall warn on duplicate customer records. The system shall be designed with wizard prompted, step-by-step approach to all web-based transactions. The system shall allow for WF24 users to skip the wizard if desired. WF25 System shall preclude agency comments from being displayed to public users.

53 ID # Web Functions Requirements (,,O) System allows remote web users to attach or include scanned documents as part of their transactions, if the remote user has access to a WF26 scanner. System shall limit carriers to viewing their own accounts. At no time will a carrier be able to view another account. Other than state WF27 administrative staff, only reporting services with limited administrative rights granted through the state shall be able to view more than one carrier account. If a user s browser times out while working in the system, the system shall preserve their data and bring them back to the point they left WF28 off. If a user s browser times out while fees are being calculated, the system shall complete the fee generation and create a payment billing WF29 notice which the user can access after logging back in to the browser. System shall create a daily audit trail detailing Internet transactions performed by IRP customers. This should be date range driven WF30 where the IRP staff can designate either one day or multiple days for the report parameters. The proposed system shall have the capability to modify the timeframe used for any automatic time-out in the system that requires a user WF31 to completely sign back on. The SDDORR system administrator will determine the specific time period. O O WF32 The system shall provide the capability for a carrier to upload IFTA files electronically. O

54 ID # Web Functions Requirements (,,O) WF33 The system shall provide the capability for a carrier to upload a file of registrations and have them batch processed. O WF34 A nightly batch process will check for unfinished supplements and send an to state/carrier/reporting services. O WF35 A Carrier may enter multiple vehicles to be included in one supplement. If a carrier fails to complete a supplement, all data entered will be maintained until the carrier or authorized user completes or deletes the WF36 request. The following IRP documents shall be available for printing from the carrier s web browser: Pre-Filled IRP Renewal Application Form WF37 Billing Notices Temporary Authority The following IFTA documents shall be available for printing from the carrier s web browser: IFTA License Application IFTA Quarterly Tax Returns WF38 Billing Notices Temporary Decal Permit IFTA Cab Card IFTA License Renewal (Auto-Populated with Pertinent Information)

55 2.11. QR: Querying and Reporting ID # Querying and Reporting Requirements (,,O) The system shall be able to produce a SD Prorate Staff Account Distribution Report. The report shall be by IRP Account Numbers and QR01 IRP Renewal Dates, by Staff ember. QR02 The system shall provide the user with the options of having any report displayed on screen, printed and exported in CSV format. QR03 The system shall provide a report for IRP Audit Staff showing: Account Name DBA Name Address FEIN FTA Account # IRP (Prorate) Account # Phone Number Cancelled or Current License Indication License Issued date (Liability Date) License Cancelled date Reporting Service Name Reporting Service Phone Number The system shall allow for development of ad-hoc reporting and querying functions allowing users the ability to generate custom queries QR04 using any available data elements within the IRP and IFTA database, to generate reports.

56 ID # Querying and Reporting Requirements The system shall have the following predefined IFTA Audit Reports, at minimum: (See Attachment 1 for sample reports from the current system.) (,,O) QR05 Selected % of Accts by Taxable iles Detail Carrier Audit Information Audit Average PG Audit Flat/Changed PG (Shows accounts that have a flat or changed PG. Should also have account address, city, state and zip.) Taxable/Tax Pd Gallons Comparison. (Should also have account address, city, state and zip.) QR06 The system shall be able to generate a current company, account and transaction status report. O QR07 The system shall be able to generate a report of accounts payable and accounts receivable for a given time-frame. The system shall have the following IFTA Peer Review Reports, at minimum: List of IFTA Accounts for a Selectable License Year QR08 Aged Receivable Report (Indicating unprocessed tax returns.) List of Active Accounts List of Revoked Accounts List of Withdrawn Accounts

57 ID # Querying and Reporting Requirements The system shall have the following IRP Peer Review Reports, at minimum, run by registration year: Accounts with Addresses Same as Base Jurisdiction Accounts with Addresses Different than Base Jurisdiction Accounts with Supplements in Particular Registration Year QR09 Accounts with Deleted Vehicles Accounts who Report Estimated Distance Accounts of Lessees with Owner-Operators All Household Goods Fleets All fleets with a Weight Variance of 10% Accounts that are New Registrants (less than a year) (,,O)

58 ID # Querying and Reporting Requirements Stock IRP Reports (See Attachment 2 for sample reports from the current system.) Account Listing by South Dakota County and Registration Year Account Listing (Sort selection by any demographic parameter.) Account Activity Report by Time-Frame o Non-Renews o Renews o Temporaries o Supplements Summary and Detailed Billing Activity Report (Showing all fees.) Annual Report of IRP Audit Activity Unpaid Billings (Original Applications Calculated But Not Paid; Applications Not Paid) Total Cab-Cards Printed by Time-Frame (Note: This report must be broken out by registration years.) (No sample included.) Credential / Cab-Card Activity Report by Time-Frame Credit Applied Report (By Account Number, Fleet, Registration Year and Transaction Number) onthly Deposit Distribution by Time-Frame QR10 Deposit Report by Time-Frame Distance Recap Report (Account, Fleet, Year) Duplicate Fees by Time-Frame Exchange Rate History Report Refund Report by Time-Frame (Carrier, Fleet, Unit, Amounts) (No sample included.) Actual Distance by Account (No sample included.) Fleet Remaining Deposit Report Incoming Transmittal Receipt Report Jurisdiction Activity Report Jurisdictional Fee Report Open Temporaries Overpayment / Refund Report Account Paid Report Permitting Services Report Renewal Reminder Revenue Distribution Report PRIS Count Report (No sample included.) (See QR18 for more information.) (,,O)

59 ID # Querying and Reporting Requirements Remaining Inventory (No sample included.) Titles Units Pending Report (Result of information exchange with SDCARS. See Requirement SI03 for more information.) Transmittal Recap Report Unpaid Supplements and Payments Voided Report QR10 Unpaid Supplement Report (cont d) USDOT # Listing Vehicle Refund Report Cycle Volume Report Expired Temporaries by Year (No sample included.) Stock IFTA Reports: (See Attachment 3 for sample reports from the current system.) IFTA Account Listing (Sort selection by any demographic parameter.) Change in IFTA Account Status by Time-Frame IFTA Accounts Added by Time-Frame IFTA Accounts Close or Revoked by Time-Frame IFTA Accounts Receivable Aging Reports QR11 IFTA Annual Filers Listing IFTA Daily Cash Summary (Run by Account #, Name, Posting Date) Daily IFTA Decal Collections Report onthly Cash Summary (Run by Posting Date) IFTA Refunds Issued by Time-Frame Revenue Summary Report by Time-Frame IFTA Annual Report (,,O)

60 ID # Querying and Reporting Requirements Wild card and multiple field searches shall be available. SDORR staff shall be able to search the following data fields: (Wild card searches shall be required for Customer Name, Account Number, FEIN/SSN, Plate and VIN fields only.) Customer / Account Data o Customer Name o DBA (Doing Business As) Name o Customer Status o Account Number o Account Status o FEIN (Federal Employment Identification Number)/SSN (Social Security Number) o USDOT (Registrant) o Addresses stored in the system o County Name or County Code IRP Fleet Data o Fleet Data Fleet Number QR12 o Fleet Registration Year o Fleet Registrant Name (first name last name or organization name) o Fleet Registrant FEIN o Fleet Registrant USDOT o Fleet's Current Registration Expiration Date o Fleet Registrant Physical Address IRP Vehicle Data o Owner Name o USDOT (Safety Carrier) o VIN (Vehicle Identification Number) o Plate Other Data o Billing Notice Number o Date of Application o IRP Supplement Number o IFTA Decal Number (,,O)

61 ID # Querying and Reporting Requirements System s query results shall be returned to the requester in such a way that the requester can arrange the data results, within the system, QR13 in whatever order they choose. In other words, the requester can put the data in different column order, or the data within columns can be ordered in ascending or descending alpha/numeric order. (,,O) O QR14 System s query allows exportation of data to other software such as Excel, Access, and comma delimited formats. QR15 System contains report-writing capabilities based on ad-hoc and pre-defined queries. System includes an ad hoc reporting and query capability that is menu-driven and provides state users the ability to design and save QR16 reports or queries with simple interface, without contractor intervention. QR17 System enables users to save any created reports and queries for future use. System shall provide the numbers of registrations suspended, revoked or denied, by CSIP Step, in order to create PRIS quarterly QR18 reports. O Remainder of page left blank intentionally.

62 2.12. PR: Printing ID # Printing Requirements (,,O) The system shall allow for a print screen function from any screen. The print screen function should print the entire screen with no PR01 cropping of the display. The system administrator shall have the ability to specify printers and trays for specific types of documents and years. (i.e. Registration PR02 year X cab-cards print from printer Y, tray Z. Refund request letters print from printer Y, tray Z, etc.) PR03 System shall have the capability to print to PDF. O PR04 System shall have the capability to print forms to an auto-fax router. O System application shall support the printing of bar-codes on, Billing Notices, IFTA Returns, IFTA Renewals, IRP Renewals, IRP Cab- PR05 Cards, IRP Temporaries and support duplex printing of certain documents. The bar-code shall be AAVA compliant. ( ) System application shall support the printing of bar-codes on Cab-Card in compliance with the PRIS bar-code specification. PR06 ( ) PR07 The system shall be able to schedule print jobs and manage print queue. The system shall have the ability to print on demand.

63 ID # Printing Requirements Address Labels: The proposed system shall print address labels for mailing purposes, for an individual account based on user-specified criteria, or in a batch process for IRP and IFTA renewals and IRP and IFTA cab cards. License labels will be created when cab cards are PR08 generated for mailing purposes. If the billing is a supplement, one label will be generated to go with the registrant mailing address or permitting service address based on indicator. (,,O) PR09 The system shall enable the user to generate correspondence letters based incorporating State / Department letterhead. O PR10 The system shall be able to output correspondence in either portrait or landscape, to be defined per template. Correspondence items shall include, but not be limited to: Suspension Warning Return Check PR11 Jeopardy Assessment Notice Of Lien Tax Warrant Reinstatement Refunds O PR12 The system shall provide an end of business day money settlement, reconciliation, and distribution process. PR13 The system shall support printing of credentials for three registration years.

64 ID # PR14 Printing Requirements The system shall support printing of IRP credentials on the South Dakota Cab Card printing system which is currently configured with four Datamax E4303 thermal printers integrated by Intellectual Technology Incorporated (ITI) and SDBIT. Interface to the printers is accomplished using a HP external Jet Direct print server, connected through a SDDORR standard icrosoft print server. Two printers reside in the SDDORR Print Center and two are local within the SDDORR Prorate Office. (,,O) The printers use a custom ITI label measuring 3.90 wide and 11.0 in length. (See Appendix B for an example Cab Card print out.) PR15 In the case of system failure, print jobs should be saved for re-printing if required. Remainder of page left blank intentionally.

65 2.13. SF: System Functions & Screen Elements The following tables are an overview of screen elements populated within the current IRP and IFTA system. Each function relates to a screen shot provided as reference in Attachment 4, for IRP, and Attachment 5, for IFTA. Note: The screen shots are for information purposes only and do not reflect the exact solution desired by SDDORR. Bidder should relate how each function is handled in their respective systems. IRP System Functions and Screen Elements (,,O) Screen Element Issuing Authority FEIN FIEN Indicator Business Type Business Name Secondary Business Name Business Fax ail Code Address City County/Parish Jurisdiction Phone Postal Code Fax SF01 Function: Business aintenance Description Country code. Actual FEIN number. FEIN, SSN, etc. Corporation, LLC, Sole Proprietor, etc. DBA As needed. Fax number. Physical vs. mailing address, one for each. Corresponding physical or mailing address. City. County name. State or province code. Phone number for location Zip or postal code. Fax number for location.

66 Screen Element Registrant Number FEIN FEIN FEIN Ind. Registrant Name Business Name First Operated Customer Representative ail Code Address City County/Parish Jurisdiction Phone Postal Code Fax Title FEIN Indicator Name Address City Jurisdiction Postal Code Phone Fax IRP System Functions and Screen Elements SF02 Function: Registrant aintenance Description anually assigned. FEIN County Code (US) Actual FEIN number or Social Security Number. FEIN, SSN, indicator. Name of registrant. Business name if different. (i.e. DBA) Start date of operations. Name of customer contact. Physical vs. mailing address, one for each. Corresponding physical or mailing address. City. County name. State or province code. Phone number for location Zip or postal code. Fax number for location. Title of officer / owner. (Can be multiple officers for each record.) SSN of officer. SSN, indicator. Name of officer. Address of officer. City. State or province code. Zip or postal code. Phone number for officer. Fax number for officer. (,,O)

67 Screen Element Registrant Number Registrant Name Fleet Number Fleet Name Customer Representative ail Code Address City County/Parish Jurisdiction Phone Postal Code Fax Issuing Authority USDOT Carrier Name Fleet Type Operation Type Expiration onth Contact Name Contact Phone Contact Fax IRP System Functions and Screen Elements SF03 Function: Fleet aintenance Description anually assigned. Name of registrant. Fleet number. Name of fleet. Name of customer contact. Physical vs. mailing address, one for each. Corresponding physical or mailing address. City. County name. State or province code. Phone number for location Zip or postal code. Fax number for location. Country code. DOT number of motor carrier. Name of motor carrier. Prorated or allocated. HH Haul for Hire HG Household Goods PC Private Carrier EX Exempt onth of IRP expiration. (2= Feb, 5=ay, 8=Aug, 11=Nov.) Name of contact person for fleet. Phone number of fleet contact person. Fax number for fleet contact person. (,,O)

68 Screen Element Contact E-ail. WY Intrastate Owner/Operator Interstate Authority Insurance Req d Insurance Expiry Insurance Co. Policy Number Permitting Service FIEN Credentials Sent to Permitting Service Bond Effective Date Bond Expiration Date IRP System Functions and Screen Elements SF03 Function: Fleet aintenance, Continued Description of fleet contact. Y/N indicator if WY intrastate. Y/N indicator. Y/N indicator. Y/N indicator. 00/00/0000 date of insurance expiration. Name of insurer. Policy number of insurance. Name of permitting service, if applicable. FEIN of permitting service, if applicable. Y/N indicator. Not used in SD IRP. Not used in SD IRP. (,,O)

69 Screen Element VIN Vehicle Type ake odel Year odel Fuel Unladen Weight Unit of easure Axles Seats Wheelbase Owner FEIN FEIN Ind. Lessee Pull Trailer Owner Type New / Used Purchase Date Title Jurisdiction Title Number Lease Start Lease End IRP System Functions and Screen Elements SF04 Function: Vehicle Information Description Vehicle identification number. Power Unit, Trailer, etc. ake of vehicle. odel of vehicle. Year of vehicle. Fuel type. Unladen weight of vehicle. Pounds or kilograms. Number of axles for vehicle. Number of seat in vehicle. (Buses) Not currently used. FEIN or SSN of carrier responsible for safety. FEIN, SSN, indicator. Name of lessee, if appropriate. Y/N indicator. Own, lease, etc. New or used. 00/00/0000 date of purchase. Two digit jurisdiction code for vehicle title. Number of title document. 00/00/0000 start date of lease. 00/00/0000 end date of lease. (,,O)

70 Screen Element USDOT USDOT Name Purchase Price Factory Price Trade-In onthly Lease Leased IRP System Functions and Screen Elements SF04 Function: Vehicle Information, Continued Description DOT number of carrier responsible for safety. Name correlating to USDOT number. US dollar purchase price of vehicle. US dollar factory list price. US dollar trade-in value for vehicle. US dollar monthly lease amount. Y/N indicator. (,,O)

71 Screen Element VIN Unit Number Usage Weight Group Date Used Account Year Fleet Recent Appl. Plate Decal Status Title Late Weeks IRP System Functions and Screen Elements SF05 Function: Unit Information Description Vehicle identification number of unit. Unit number of vehicle. BS Bus FT Full Trailer ST Semi Trailer RT Road Tractor TK Straight Truck TR Tractor TT Truck Tractor Weight group of unit. Date unit added to fleet. IRP account number for unit. IRP registration year for unit. Unit s fleet number. ost recent application unit is tied to. South Dakota prorate plate number assigned to unit. South Dakota prorate decal number assigned to unit. (Will be the same as plate.) Status of unit. Number of weeks that the title paperwork was received beyond the due date. (Based on application.) (,,O)

72 Screen Element Weight Group Type Default lbs. Default kgs. Default Axles IRP System Functions and Screen Elements SF06 Function: Weight Group aintenance Description Unique user created number. Power Unit / Trailer / Bus indicator. Default pounds for weight group. Default kilograms for weight group. Default number of axles for weight group. (,,O) Screen Element Weight Group Type Default lbs. Default kgs. Default Axles SF07 Function: Select Jurisdictions / View Percentages Description Unique user created number. Power Unit / Trailer / Bus indicator. Default pounds for weight group. Default kilograms for weight group. Default number of axles for weight group. Screen Element Select Change SF08 Function: Edit of Transmittal Receipts Description Select Jurisdiction and date range, or jurisdiction and receipt date. Change receipt date and amount.

73 Screen Element Select Returns IRP System Functions and Screen Elements SF09 Function: Fleet Units Inquiry Description Account Number, Registration Year, Fleet Number Registrant Name Fleet Name Unit Number(s) VIN(s) Plate(s) Decal(s) Status Latest Supplement Number Supplement Begin Date Latest User (SDDORR Staff) Unit Type (Power Unit, Trailer, Bus) Unit ake Unit odel Year (,,O)

74 Screen Element Select Returns IRP System Functions and Screen Elements SF10 Function: Temporary Permit Inquiry Description Account Number, 00/00/0000 Temporary Expiration Date Account Number Registration Year Fleet Number Application Number Unit Number Temporary Effective Date Temporary Expiration Date Temporary Number Reason for Temporary Closeout Reason (,,O) Screen Element Select Select Returns SF11 Function: Escrow / Deposit aintenance Description Account of Vehicle Level Deposit Account Number, Registration Year, Fleet Number or; VIN Registrant Name FEIN Date/Time Amount Escrow Balance Deposit Balance User (SDDORR Staff member.) Activity Type (Type of activity.) Applied To (Unit number deposit applied to.)

75 Screen Element Select Returns IRP System Functions and Screen Elements SF12 Function: Estimated Distance aintenance Description Registration Year Registration Year Jurisdiction Average Vehicle ileage (Can change.) (,,O) Screen Element Exchange Date Year Exchange Date onth Exchange Rate Canada to US SF13 Function: Exchange Rate aintenance Description 0000 year for exchange rate entry. 00 month for exchange rate entry Canadian dollars per US dollar. Screen Element Transfer Deposit Transfer Escrow From Year To Year Cycle Number Select SF14 Function: Transfer Escrow / Deposit Description Y/N indicator. Y/N indicator registration year registration year. 00 registration cycle. Transfer from Account/Fleet or Vehicle

76 IRP System Functions and Screen Elements SF15 Function: Inventory aintenance Screen Element Description Registration Year Registration year. Inventory Category Plate Vehicle Type Power Unit, Trailer Inventory Type Plates Location Pierre, SD Select Select to add inventory individually or in bulk. Prefix Inventory prefix to be used for each number to be issued. Begin Beginning number of inventory items. Ending Ending number of inventory items. Suffix Inventory suffix to be used for each number to be issued. # of Items Discrete number of inventory items added. Stocked Date Date of inventory add. (,,O) Screen Element New ake Description SF16 Function: ake Table aintenance Description Four alpha character code for make. Description of make. Screen Element Select Select Name Description SF17 Function: aintain Status Codes Description Status Code Identifier Code Status Code Restrictions Create name for status code. Free text description of status code.

77 IRP System Functions and Screen Elements (,,O) Screen Element Printer Identification (ultiple Printers) SF18 Function: Printer Assignment Description Assign for each printer: Default Cab-Card Temporary Permit Billing notice Cab-Card A Cab-Card B Cab-Card C File Not Used

78 IFTA System Functions and Screen Elements SF19 Function: IFTA aster Record Screen Element Description Account System generated account number. Business Name Business name of licensee. Tax Type IF for IFTA. SD TID FEIN or taxpayer s SSN. Liability Date Tax license effective date. Hold Hold date used to hold printing of notices. (00/00/0000) Preferred Payment N/A Withdrawn Date Date account was withdrawn. Collect Collection date. Owner Type Corporation, LLC, Sole Proprietor, etc. Phone Number Phone number of licensee. Renewal Date Date of most recent renewal. Auditor N/A Status User define IFTA account status codes with 00/00/0000 effective date. Fax Number Fax number of licensee. Revoke Revocation indicator. Operations Operations code with 00/00/0000 effective date. Return ail Return mail code with 00/00/0000 effective date. Contact Contact name for licensee. Business Address Business address of licensee. Business City Business address of licensee. Business Postal Code Business address of licensee. Business State Business address of licensee. Business Country Business address of licensee. (,,O)

79 Screen Element ail Address ail City ail Postal Code ail State ail Country ICN Filing Type Bond Required Amount IFTA License SFU License Payment Agreement Date Last Pay Date Prorate Payment Agreement Amount Last Pay Amount Filing Frequency Last Return Period IFTA System Functions and Screen Elements SF20 Function: IFTA aster Record, Continued Description ail address of licensee. ail address of licensee. ail address of licensee. ail address of licensee. ail address of licensee. icrofilm Batch, Roll and Frame number or transaction number used for document retrieval purposes. Type of filer. (Quarterly, Annual) Amount of bond required from licensee. IFTA license code with 00/00/0000 effective date. SFU license code with 00/00/0000 effective date. 00/00/0000 effective date. 00/00/0000 date. Prorate IRP account number, if applicable. Amount of agreed payment. US dollar amount. N/A Date (00/00/0000) quarter ending. (,,O)

80 Screen Element Account SD TID Tax Type Filing Type ICN Business Name DBA Name Contact Name County Phone Fax Special ail Business Address Business City Business Postal Code Business State ail Address ail City ail Postal Code ail State IFTA System Functions and Screen Elements SF21 Function: IFTA Application Description System generated account number. FEIN or taxpayer s SSN. IF for IFTA. Type of filer. (Quarterly, Annual) icrofilm Batch, Roll and Frame number or transaction number used for document retrieval purposes. Business name of licensee. DBA name of licensee. Contact name for licensee. South Dakota county. Phone number of licensee. Fax number of licensee. ail indicator. Business address of licensee. Business address of licensee. Business address of licensee. Business address of licensee. ail address of licensee. ail address of licensee. ail address of licensee. ail address of licensee. (,,O)

81 Screen Element Liability Date Renewal Date IFTA License SFU License Prorate Bulk USDOT Preferred Payment Name Address Social Security Federal ID Phone Jurisdictions Traveled Fuel Types IFTA System Functions and Screen Elements SF22 Function: IFTA Application, Continued Description Tax license effective date. Date of most recent renewal. IFTA license code with 00/00/0000 effective date. SFU license code with 00/00/0000 effective date. Prorate IRP account number, if applicable. Y/N indicator. DOT number of licensee. N/A Name of owner or corporate officer. (ultiple.) Address of owner or corporate officer. (ultiple.) SSN for owner or corporate officer. (ultiple.) FEIN if applicable. (ultiple.) Phone number of owner or corporate officer. (ultiple.) Select year and select jurisdictions. Select year and select fuel type, (Diesel, Ethanol, Natural Gas, etc.) (,,O)

82 Screen Element Select Return IFTA System Functions and Screen Elements SF23 Function: Collections Summary Description IFTA account number. For the account: Account Status and Status Date Liability Date Withdrawal Date For each Period: Period (Begin / End) Assessed Tax Assessed Penalty Assessed Interest Credited Tax Credited Penalty Credited Interest Fuel Tax Balance Remit Balance Balance Column Totals (,,O)

83 Screen Element Select Return IFTA System Functions and Screen Elements SF24 Function: Fuel Tax Transactions by Period Description IFTA Account Number For the account: Period Status Code and Date Period Hold Code and Date Gotcha Hold Code and Date Last Action Code and Date Per Filed Code Next Action Code Warrant Flag Warrant Fee Backout Amount For each transaction: Transaction Code Transaction Date Posting Date Assessed Tax Assessed Penalty Assessed Interest Credited Tax Credited Penalty Credited Interest Balance ICN Column Totals (,,O)

84 Screen Element Select Return IFTA System Functions and Screen Elements SF25 Function: IFTA Return Summary Description IFTA Account Number and Filing Period For the Account: Filing Date ICN Fuel Type Total iles Reported Total Gallons Reported Average PG Other iles For each jurisdiction: Fuel Type Total iles Taxable iles Gallons Tax Paid Net Assessed Tax Assessed Interest Total Column totals. (,,O)

85 Screen Element Select Return IFTA System Functions and Screen Elements SF26 Function: Period Remittance Transactions Description IFTA Account Number and From and To Period For the Account: Period Status Code and Date Period Hold Code and Date Gotcha Hold Code and Date Last Action Code and Date Per Filed Code Next Action Code Warrant Flag Warrant Fee Backout Amount For each transaction date: Transaction Code Transaction Date Posting Date Qty (Decals) Remit Amount Due Amount Cash Amount Check Amount Check Date Check Number Balance ICN Balance Column Total (,,O)

86 Screen Element Select ail Code Address (ultiple) Phone Fax Billing Letter Indicators Other Indicators IFTA System Functions and Screen Elements SF27 Function: Address aintenance Description Account Number Select mail code from drop down list. Street Street City State Zip Code Country (XXX)XXX-XXXX (XXX)XXX-XXXX For each address: 1 st Billing 2 nd Billing Revoke Letter Nonfiler Letter For each address: Renewal Return License Refund (,,O)

87 Screen Element Select Period View Displays IFTA System Functions and Screen Elements SF28 Function: Account Comment Description Account Number Select periods to view. Comments showing: Filing Period Timestamp User ID Source (,,O) Remainder of page left blank intentionally.

88 2.14. AR: System Architecture The following diagram provides a high-level overview of the new IRP/IFTA system. Specific requirements are noted in the table which follows. (Note: System interfaces are detailed in the following section.) File Transfer XL Web Services HTTP SDCVIEW CEDAR Printing Center Database Custom Web Services SDAPS South Dakota Print Servers TCP/IP and ITI Thermal Printing New IFTA/IRP App Server XL Web Services HTTP SDCARS Local Printers FCSA 3 rd Party Payment System SFTP PRIS Central Server Public Interface XL Web Services HTTPS New IFTA/IRP Web Server File Transfer SDORR Remittance Center

89 ID # System Architecture Requirements (,,O) System Configuration Operating system Windows Server 2003 R2, Service Pack 2 Web server icrosoft IIS 6.0 Database Engine icrosoft SQL 2005 High Availability platforms Database AR01 icrosoft Cluster server Web Cisco Content switch Hardware HP Proliant C-Class blade server(s) (Vendor to supply system requirements.) Client platforms icrosoft Windows XPSP2 (Support for Windows Vista recommended) Preferred Client distribution (In order of preference) icrosoft Internet Explorer (6.0 and Higher) Citrix The system shall be developed in a client / server format using a modern object oriented programming language. Bidder is to specify AR02 which programming language was used for development of the system. AR03 The system shall be compatible with.net software web service technologies. AR04 System uses universal icrosoft Windows conventions and data entry methods (i.e., allow for function selection by tabbing, keyboard entry, or mouse clicks; have copy and paste functions enabled, be able to toggle to other Windows applications, etc.).

90 ID # System Architecture Requirements (,,O) AR05 The system shall have the ability to accommodate remote Intranet and Internet access while maintaining strict security of data. AR06 The system shall have the ability to use secure FTP to accommodate file transfers. AR07 The system shall provide a web-based n-tier architecture for field personnel who have minimal bandwidth availability. The system shall be able to handle locally attached printers as well as network printers. To the degree possible, the system shall use AR08 universal printing methods to support the widest range of printing solutions. AR09 The system shall provide for encryption between Web browser and server environment. AR10 The system shall support web standard communication protocols including TCP/IP, HTTP and HTTPS. AR11 The system shall have the ability to work on an Ethernet network. AR12 The system shall have a testing environment provided for use by SDDORR for validation of all system upgrades, patches and bug fixes.

91 ID # System Architecture Requirements All server systems are configured to download but not install patches. Periodic review of patches is performed to determine if a patch is valid for the system. Upon determining the need to apply a patch, testing is performed on the patch in a non-production environment. AR13 Once testing is successfully completed, patches are scheduled and applied to the production environment. The System Administrator then monitors event logs and user experiences to determine if the patch updates have caused any unwanted effects. (,,O) AR14 The system shall have one common database that is shared by all programs and users. AR15 System shall be a thin client deployment with browser-based user interface system. Remainder of page left blank intentionally.

92 2.15. SI: System Interfaces The following graphic provides a systems overview with representations of system interfaces. Circled numbers on each of the interfaces are described in the requirements table which follows. Remainder of page left blank intentionally.

93 Demographic IFTA Clearinghouse 12 Transmittal File 1 XL Web Services HTTP SDCVIEW IRP Clearinghouse Recap/ Transmittal Files 11 Database 2 Custom Web Services SDAPS Printing Center 10 South Dakota Print Servers TCP/IP and ITI Thermal Printing 9 New IFTA/IRP App Server 3 4 XL Web Services HTTP SFTP CS-150 Census SDCARS FCSA Local Printers PRIS Target PRIS Central Server 3 rd Party Payment System 8 5 Shared Drive Flat File Returns Remittances aint. SDORR Remittance Center Public Interface XL Web Services HTTPS 7 New IFTA/IRP Web Server 6 IFTA Refunds IRP & IFTA Addresses Shared Drive CEDAR Iteris, Inc. 91