Appendix 06.pdf

Functional Requirements: SCDMV Standard Transaction Model

Appendix #:

Subject:

Functional Requirements: SCDMV Standard Transaction Model

Appendix 06 - Standard Transaction Model Page 1 of 23

1 Overview 2 Introduction 3 Standard Transaction 4 Customer Initiated Model 5 SCDMV Employee/Authorized Agent Assisted Model 6 Central Office 7 Standard Transaction Support

See Appendix 15 for a complete list of all abbreviations and acronyms.

Appendix 06 - Standard Transaction Model Page 2 of 23

1 Overview

All SCDMV business transactions in the new SCDMV modern system shall follow a consistent transaction flow based on a standard model. This model is defined as a collection of mandatory and optional steps that comprise the processing for a complete business transaction. These business transactions can be customer initiated/completed via an electronic device, employee assisted (in-person/telephone), or central office processing for regulatory compliance. Adopting this model offers several benefits to the SCDMV. The Standard Transaction Model:

1. Provides a common approach for executing business transactions.

2. Provides for consistency in workflows.

3. Allows maximum reusability of common system components.

4. Establishes a framework by which business transaction’s requirements are gathered and documented with an eye towards development.

5. Supports standardized business operations to allow flexible resource utilization across business units.

Appendix 06 - Standard Transaction Model Page 3 of 23

2 Introduction

As part of the comprehensive system requirements for the SCDMV, the Standard Transaction Model serves as the minimum set of transactional requirements to be fulfilled by the Contractor's proposed solution for implementing future SCDMV systems and components. A tailored Standard Transaction Model, based on the requirements outlined in this document and customized to the Contractor’s solution, shall be defined before the start of requirements-gathering sessions. This model will guide business analysts in consistently documenting requirements across all business modules.

The model consists of mandatory and optional steps that can be configured for any transaction. It shall enable customers to:

1. Initiate and complete transactions through a self-service channel

2. Initiate and complete transactions through an alternative channel (SCDMV employee or authorized agent)

Additional Attributes – For each common transaction the following requirements shall be considered for each step of the transaction:

1. Auditing

2. Event Logging

3. Role-Based Access Controls (RBAC)

4. Error Handling

5. Configuration

6. Security

Appendix 06 - Standard Transaction Model Page 4 of 23

3 Standard Transaction

3.1 General Description

A transaction will typically follow a multi-step process, as depicted in the diagram below.

The standard transaction model includes the steps shown in the diagram above and the following variations shall be supported for the SCDMV.

1. Customer Initiated – The transaction can be initiated by an authenticated/verified customer using the SCDMV portal, self-service terminal, or another self-service channel. These transactions may be initiated and completed in one session, or they may be completed using another channel, or they may be transitioned to a work queue and completed using the other model variations described here.

2. SCDMV Employee/Authorized Agent – The transaction will be processed by a SCDMV Employee/Authorized Agent in one of the following scenarios:

3. Customer initiated the transaction but needed assistance from an SCDMV Employee/Authorized Agent to complete the transaction.

4. Customer walks into an SCDMV or Authorized Agent office where the agent will perform the transaction for the customer.

5. Customer electronically submits a transaction or sends the paperwork for a transaction to the central office location using the U.S. mail or email. Some transactions can be started and completed by contacting the central office SCDMV Employee/Authorized Agent via phone or any other channel available in the future.

3.2 General Configurability

The system shall be configurable and allow SCDMV to modify system, operational, and transaction level functions and options.

Appendix 06 - Standard Transaction Model Page 5 of 23

1. The system shall provide a common global system to manage configuration options.

2. The system shall provide administrative tools that allow the SCDMV to control the availability of each transaction, each business module, or the entire system.

3. Each business module shall have flexibility in defining the user interface (UI) to collect transaction specific data. UI guidelines shall be published to ensure SCDMV standards are followed.

4. The system shall maintain and allow system administrators to manage all error codes and descriptions that can be displayed during a transaction.

Appendix 06 - Standard Transaction Model Page 6 of 23

4 Customer Initiated Model

The Customer Initiated Model refers to a standard transaction process where customers start transactions through an online account via the SCDMV Portal, a self-service terminal, or any other available channels. Below are the requirements for each step in this transaction model.

4.1 Customer Identification

The customers will need to identify themselves prior to performing any customer-initiated transaction. This may be accomplished by signing on their online profile or other information that the customer can provide to ensure that the customer is performing is the transaction that they are authorized to perform. This functionality is available for SCDMV Employee/Authorized Agents.

4.2 Authentication and Access Authorization

1. Prior to performing a transaction, the customer shall be authenticated to the level of identity verification commensurate to the requested transaction. The following options shall be available when the customer attempts a transaction:

2. Full Self-service account.

3. One-Time authentication.

4. Anonymous access.

5. Multi-Factor authentication shall be supported.

6. The system shall allow the customer to create and manage a self-service account including with a user-created ID. This approach shall leverage the customers’ cell phone or email address for verification.

7. The system shall support self-service functionality that allows for customer to retrieve forgotten user IDs or passwords.

4.3 Eligibility

1. The system shall determine if the customer is eligible for the services or products they are trying to perform as part of the standard transactions model. The system should also intuitively identify other suggested transactions.

2. The system shall make all applicable transactions available to be started via a self-service channel, such as the SCDMV web portal or self-service terminal, including entry of data and the upload of documents.

4.4 Workflow

1. When completing a transaction, the system will use an automated workflow function to properly route a transaction to completion.

Appendix 06 - Standard Transaction Model Page 7 of 23

2. During transaction selection and options, the system shall identify the mandatory information to be entered.

3. Pre-population of data shall not divulge personal data if the customer has not been fully authenticated.

4. The system shall pre-fill relevant data for the customer.

5. The system shall display incomplete or pending transactions for the customer which may have been started at a prior visit or on-line.

6. The system shall have a capability where the customer may be able to scan the barcode or QR code on their product or correspondence received to start the transaction.

7. All customer provided images shall trigger a workflow to allow an authorized SCDMV Employee/Authorized agent to verify the documentation prior to permanently storing in the content management system.

8. Before committing the transaction to the database, the system shall provide for customer approval/confirmation, except when the transaction needs to be approved by a SCDMV employee or authorized agent.

9. The system shall prevent processing transactions for customers with certain hard stops. The system will display a message to the customer to resolve this hard stop or contact the SCDMV to resolve it. Configurations for hard stops that restrict transactions at county locations or self-service terminals shall be manageable within the system.

4.4.1 Pending Transaction Data Updates

1. A customer shall be able to start a transaction on the web and pend/save the transaction for later retrieval and completion by themselves or a SCDMV Employee/Authorized Agent.

2. The system shall revalidate for pending transactions, depending on the duration of the delay from original entry to actual submission.

3. The system configuration shall allow for purging pending transaction data as defined by business rules.

4. The pending transaction may need the customer and / or the SCDMV Employee/Authorized agent to take appropriate action and the system shall generate the appropriate alert.

4.4.2 Data Validation

1. All input data shall be validated by the system as close to the time of entry as possible, balancing performance and ease of use.

2. Data validation shall be standardized across multiple channels of transaction initiation.

3. If the data validation requires SCDMV Employee/Authorized agent verification, then the system shall send the data entered to the appropriate work queue using the system workflow.

Appendix 06 - Standard Transaction Model Page 8 of 23

4. Once all data for the requested transaction has been captured and initially validated, the system shall process any additional business rules for the transaction and perform any additional validations necessary to ensure the data and transaction integrity.

5. The system shall employ a service-oriented architecture that allows multiple channels and sources of transaction data to use the same business services, rules, and logic without the need for duplication. The business logic shall be maintained centrally and not need to be duplicated for each service channel thereby allowing business rules to become out of sync across the various channels.

6. The system shall allow external system checks at various points in the standard model to accommodate business rule enforcement. This includes performing external system checks multiple times during a transaction.

7. The system shall generate a prompt or notification whenever a deficiency or data error is encountered.

8. Errors and deficiencies shall be communicated in a consistent manner.

9. The system shall provide help to guide the customer and staff in resolving any errors or deficiencies.

10. The system shall not allow a user to override a properly authorized transaction – unless the appropriate review and authorization process is followed.

11. Error messages communicated shall be free from technical jargon and be easily understood by the average non-technical person.

12. Error messages shall not divulge information about the technology used to develop the system.

13. The system shall maintain and generate analytics on deficiencies found and reported for corrective action.

14. The system shall repeat data validations for pended transactions, depending on the duration of the delay from original entry to actual processing of the transaction.

4.4.3 Final Data Updates

After successful payment, the pending transaction data shall be processed and written to become part of the customer's permanent record. Unfinished transactions shall not be displayed during a customer inquiry of completed transactions but should appear during lookups to find pending transactions or shopping cart transactions.

4.5 Supporting Documents

1. The system shall allow the customer to upload the required documents to SCDMV via the SCDMV customer portal. The documents received electronically shall automatically be indexed by parameters to be determined by the SCDMV.

2. If a document requires review for security features the customer shall be prompted to visit a SCDMV office location.

Appendix 06 - Standard Transaction Model Page 9 of 23

4.6 Payment

1. The system shall calculate the accurate and complete fee due for the transaction.

2. Additional requirements for fee calculations are found in Section 5 of this document.

3. A shopping cart function shall be used to allow a single payment for one or multiple transactions.

4. The items in the shopping cart shall be retained for later retrieval if the payment process fails or cannot be completed for any reason.

5. The system shall allow the customer or the SCDMV Employee to retrieve a customer's shopping cart of pending items and allow the payment to be processed later (duration to be configurable).

6. The system shall repeat data validations for pended transactions, depending on the duration of the delay from original entry to actual submission.

7. The system shall allow the customer or the SCDMV Employee to move transactions from “pended” to or from the shopping cart to accommodate the payments which are currently being purchased. Some shopping cart transactions shall stay grouped together.

8. The system should alert the customer or the SCDMV Employee that transactions or products have been left in the shopping cart if they end a session without the transactions being processed.

9. The system shall support all financial management system requirements.

10. The system shall interface with the SCDMV's payment processing system from Tyler Technologies and with merchant card transactions being processed through First Data Merchant Services, LLC and any ACH transactions to be processed through the State’s designated qualified public depository and record payment for each transaction and the shopping cart.

11. The system shall allow multiple payment methods to be used in total to satisfy the payment for one or more items in the shopping cart.

12. The system shall maintain an account balance for a customer and track pending transactions.

13. The system shall allow receipts to be sent electronically to email, SMS text, and make it available in the customer’s profile with an ability to print if required.

4.7 Product/Service Delivery

1. Documents shall be made available electronically and may be printed by the customer or through a batch process and mailed to the customer if determined necessary or requested by the customer. The customer’s preferred delivery method should be used, as appropriate, and the resulting documents and receipts should be stored and available in the customer’s online portal account.

Appendix 06 - Standard Transaction Model Page 10 of 23

2. Official documents produced for a transaction shall be generated only after the customer records have been updated.

3. All documents shall be created as PDF files, stored in the document repository, and associated with the transaction and indexed by criteria to be identified by the

SCDMV.

4. Any transaction that results in a product being produced via central issuance (not over the counter), shall include the option of printing a receipt that can serve as temporary proof of the product purchase and include a barcode or a QR code.

5. The system shall allow for an alternate delivery address (email, SMS text, or U.S.

Mail address) to be used to deliver the product or document, rather than the customer’s mailing address, if authorized by the SCDMV representative.

4.8 System Reconciliation/Closeout

1. The system shall keep a record of all processed transactions.

2. Each processed transaction that updates customer records shall include audit information detailing who performed the transaction, what changes were made, when the transaction occurred, and where it was conducted.

3. The system will perform a reconciliation of all products provided daily.

4. Upon completion of the transaction(s), the system shall provide the ability to initiate a brief customer survey. The questions shall be configurable, and the answers shall be linked to the specific transaction.

Appendix 06 - Standard Transaction Model Page 11 of 23

5 SCDMV Employee/Authorized Agent Assisted Model

Customers may require or prefer the assistance of a SCDMV Employee/Authorized Agent to complete a transaction. In this event, they have the following options:

1. Call the SCDMV contact center

2. Schedule an appointment at a SCDMV office

3. Walk into a SCDMV office

If the customer started a transaction through a self-service channel, the SCDMV Employee/Authorized Agent should be able to search for the WIP transaction using the customer’s information.

When considering this model versus the Standard Model, several accommodations shall be made. The following sections identify those steps where significant change will be required.

5.1 Customer Identification

1. The system shall support the ability of the SCDMV Employee/Authorized Agent to scan the barcode or QR code on a DL/ID, transaction receipt, or SCDMV issued document to find the customer or transaction.

2. The system shall support the identification of a customer for whom the transaction is being performed (refer to section 4 of the Functional Requirements SCDMV Common Functions: Identity Management and Access Management).

3. The system shall support, for transactions requiring the selection of multiple customers, a similar search capability integrated within the transaction data entry screen(s).

4. The system shall offer the ability to search for a customer using nicknames or sound-alike names including fuzzy searches.

5. The system shall provide guidance for creating a new customer record after confirming that an existing customer record does not exist.

6. The system shall support, during customer creation, intelligent search algorithms to confirm that the customer is not already recorded in the system. These search algorithms shall be performed without additional input or actions. Possible matches shall be presented before the new customer record is created.

7. The system shall take all available actions to prevent the creation of a customer record for a customer already recorded in the system.

5.2 Authentication and Access Authorization

Authentication and access authorization shall always occur prior to the start of any standard transaction. This applies to all SCDMV employees and authorized agents of

Appendix 06 - Standard Transaction Model Page 12 of 23 the SCDMV. This will include access controls, single sign-on, integration with Active Directory, location awareness (and geofencing capability), central administration of user accounts, and session management.

5.3 Eligibility

1. The system shall identify if a customer has the necessary privileges/license to request the transaction.

2. The system shall suggest alternative transactions that might be appropriate when a customer is not eligible for the selected transaction.

3. The system shall provide meaningful messages to the SCDMV Employee/ Authorized Agent explaining why a customer is ineligible and provide a list of actions to become eligible.

4. The system shall provide a checklist of items the customer shall possess or provide for the transaction to be successful.

5.4 Workflow

1. The system shall provide a context sensitive menu to allow the SCDMV Employee/Authorized Agent to select a desired transaction and suggest potential transactions which can be selected.

2. The system shall display incomplete transactions for the selected customer which may have been started at a prior visit or using the SCDMV portal. The retention period for each type of incomplete transaction shall be configurable to conform to varying requirements for each business unit.

3. The system shall provide access to the configuration settings via Role Based Access Control (RBAC) for appropriate roles.

4. The system shall provide a context sensitive menu to allow the SCDMV Employee/Authorized Agent to select a desired transaction and suggest potential transactions which can be selected.

5. The system shall display incomplete transactions for the selected customer which may have been started at a prior visit or using the SCDMV portal. The retention period for each type of incomplete transaction shall be configurable to conform to varying requirements for each business unit.

6. The system shall provide access to the configuration settings via Role Based Access Control (RBAC) for appropriate roles.

7. The system shall allow authorized SCDMV employees to override specified fees, documents, and other system requirements remotely from their workstation through a workflow, and at the workstation performing the transaction by scanning their fingerprint on the attached fingerprint reader, or by scanning their contactless Fob/Card on the reader.

Appendix 06 - Standard Transaction Model Page 13 of 23

5.4.1 Transaction Data Capture

1. Contractor shall define reusable components that can be building blocks for the UI and therefore offer maximum reusability and standardization.

2. The system shall provide the UI to allow easy transfer of data from a paper application and shall allow input of data by scanning a barcode or QR code.

3. The system shall use previously recorded customer data to pre-populate as much information as possible. Duplication of data input shall be minimized.

4. The system shall support data lookups used to support and ease data entry.

5. The system shall allow transactions to be started or progressed by the SCDMV Employee/Authorized Agent or the customer and resumed by another SCDMV Employee/Authorized Agent where data entry will continue using all information previously entered. The time limit on resuming a transaction shall be configurable for each type of transaction.

6. The audit data for a transaction shall be captured and recorded regardless of whether the transaction was started, completed, or cancelled.

5.4.2 Data Validation

1. The system shall ensure that the required data elements are captured by the user and shall be validated within the user interface (UI).

2. The system shall automatically generate prompts for transaction steps needing SCDMV Employee/Authorized Agent verification or document review. The system shall not allow the transaction to proceed until the required step in the workflow is completed.

3. The system shall repeat data validations for transactions, depending on the duration of the delay from original entry to actual processing of the transaction.

4. The system shall interface to external systems, which are required for data validation, and perform such validations as necessary to complete a transaction.

5. The system shall generate alerts to authorized SCDMV Employee/Authorized Agents wherever applicable.

6. To the extent possible, the same business rules should be used for transaction processing irrespective of where the transaction is being performed. Supplemental business rules for a given channel may be specified and shall be accommodated in the standard model.

7. The system shall log all failed external system checks and periodically reattempt these checks until they are successfully completed, allowing the transaction to proceed as appropriate. Transactions will allow for an extended check period. For centrally issued products, the system shall perform the necessary checks after a configurable delay and initiate an appropriate workflow to notify the SCDMV Employee/Authorized Agent or the customer.

Appendix 06 - Standard Transaction Model Page 14 of 23

8. The system shall allow each deficiency to be configured to allow an override by a SCDMV Employee/Authorized Agent performing a transaction, supervisor override, or to disallow override.

9. The system shall use Role-Based Access Control (RBAC) to determine which roles are permitted to override deficiencies (e.g., supervisor only) and ensure that these are properly authenticated and authorized.

10. The system shall create audit data that records when a deficiency is overridden and by whom, where, and why along with proper documentation.

11. An error that is properly overridden shall be ignored by the system for the remainder of the transaction or until the underlying transaction data has been modified by the SCDMV Employee/Authorized Agent.

5.4.3 Final Data Updates

The audit data for a transaction shall be captured and recorded regardless of whether the transaction was started, completed, or cancelled.

5.5 Supporting Documents

1. The system shall provide the appropriate interface to allow scanned document content to be indexed for storage, retrieval, review, commenting, and general management.

2. Scanned document content shall be indexed by multiple parameters such as document type, transaction ID, date/timestamp, transaction type, customer ID, VIN, title number, DL number, plate number, last name, collision case number, and ticket number.

3. The system shall be configured to allow all document imaging functions to be executed during a transaction with optional imaging at the completion of a transaction, if required for confirmation and/or receipt documents.

4. Scanned document content shall be displayed for inspection by the SCDMV Employee/Authorized Agent to confirm that the scan was successful and that the image is readable and complete, and the system shall record this confirmation.

5. The system shall identify that a document was blank or unreadable. The system shall automatically remove the blank documents.

6. The system shall allow a capability to separate or break apart a scanned document into separate files if more than one content type was scanned together.

7. The system shall allow multiple scanned document content types to exist in one file or scan if permissible.

8. Documents may be captured outside of the transaction, associated with the transaction, and retrieved and reviewed when the transaction is processed.

Appendix 06 - Standard Transaction Model Page 15 of 23

9. The system shall allow the use of bar code and QR code scanners and shall decode these formats to populate data elements via the graphical user interface.

10. The system shall support integration with the scanned document content management system as may be required to perform document operations, such as Optical Character Recognition (OCR) and Intelligent Character Recognition (ICR).

5.6 Payment

1. The system shall provide a lookup function where the total fee for any given transaction or item is calculated and displayed. The lookup function shall reference transaction configuration values, if required to calculate the fee. This look-up function shall be available to the SCDMV Employee/Authorized Agents, and customers via the SCDMV Portal.

2. The system shall allow the SCDMV Employee/Authorized Agent to pend or save the transaction, if the customer is not able to complete the transaction for some reason, such as, does not have enough funds to pay for the transaction.

3. Prior to adding a transaction to a shopping cart for payment, pending transaction shall be retained by the system for a configurable period of time, to allow additional transactions to be added to the cart before payment and to ensure that work effort is not lost if the payment process fails or cannot be completed for any reason.

4. The system shall calculate the accurate and complete fee due for the transaction.

5. The individual fees comprising the total transaction cost shall be recorded by the system. The system shall provide for a configuration setting that displays the individual fees and/or only the total transaction fee. This setting shall apply to the UI display as well as any transaction confirmation, receipt, or documents.

6. The business rules and dollar amounts required to calculate fees shall be centrally configured as a shared system-wide module.

7. Fees and calculation formulas shall be easily configured by an authorized SCDMV Employee/Authorized Agent. The system shall be designed to minimize the impact on system changes and testing due to fee changes.

8. The system shall provide for fees to be time-boxed with effective start dates, end dates, grace periods, and shall maintain historical fees, to be used in calculations where arrearages or penalties are to be assessed.

9. The system shall ensure that time-boxed fees do not overlap and that there are no gaps between date ranges. A fee shall be effective on all consecutive days after its first effective date and until its end date.

10. The system shall provide for fees calculated by a schedule, weight, and percentage as well as fees for fixed cost items.

11. Fee calculation logic shall be flexible to address the parameters specified in SCDMV policies, procedures, regulations, and statutes. The system shall accommodate transaction fees that depend upon in-state or out-of-state fee parameters.

Appendix 06 - Standard Transaction Model Page 16 of 23

12. The system shall allow for override of fees and the ability to perform a gratis transaction with appropriate waiver or override which will be recorded. The system shall provide an ability to preapprove gratis transaction that can be performed using the SCDMV Portal. The system shall have a capability to add time-boxed override or adjustment to fees.

13. All changes to fee formulas, parameters, and values will be recorded for audit purposes including individual performing the transaction, location, and date/timestamp.

14. The system shall capture all payer information including if the payer is different from the customer.

5.6.1 Customer Approval

1. Before committing the transaction to the database, the system shall provide for customer approval/confirmation. This may require the printing of a transaction summary sheet or confirmation report that the customer reviews and signs or it may require the capture of an electronic or hand-written signature.

2. By configuration, the system shall not allow the transaction to be completed until the customer approves.

3. Any captured signature shall be stored with the transaction as record of the customer’s approval.

4. The confirmation shall be printable for the customer’s records and may be emailed and/or electronically provided.

5. The system shall have a capability for an authorized SCDMV Employee/ Authorized Agent to override the transaction on behalf of the customer. The system shall log such activities for review.

5.7 Product/Service Delivery

1. The system shall allow the printing of a document or customer product from the stored PDF.

2. The system shall provide an ability to reprint documents due to damage or print quality issues.

3. The system shall maintain records for all controlled stock and account for damaged, missing, backed out and reprinted documents.

4. By configuration for each transaction and document/product, the system shall direct or provide the option to print documents and products via batch through central issuance or for over-the-counter delivery.

5. The system shall enforce, by configuration, if any documents produced need to be scanned to create a final record of controlled stock or other audit information.

Appendix 06 - Standard Transaction Model Page 17 of 23

5.8 System Reconciliation/Closeout

1. An audit search or reporting facility shall be provided, that uses search parameters to display or print the complete audit record for a person, transaction, transaction type, date, date range, location, or combination thereof.

2. The system shall track and record when an audit report is accessed or reviewed by whom, where, and why.

3. The system shall provide reconciliation features to identify any customers that paid for a transaction that was not ultimately provided due to system or browser failures.

4. The system shall provide reconciliation features to identify any transaction data updates that are invalid because of a payment failure or credit-card dispute.

5. The system shall provide reconciliation features to identify any customer transaction that are not completed due to system or browser failures.

6. The system shall provide reconciliation features that support inventory management.

Appendix 06 - Standard Transaction Model Page 18 of 23

6 Central Office

The Central Office Model is utilized by SCDMV agents when the customer is not physically present. This model enables access to customer data for inquiries and customer-specific transaction processing. Typical applications include handling sanctions, mail processing, or providing help-desk support for previously submitted self-service requests. It also encompasses transactions initiated via the SCDMV Portal, mailed-in transactions, and other transactions requiring central office support to complete pending customer requests.

When comparing this model to the Standard Model, specific accommodations shall be made. The following sections outline the steps where significant changes will be required.

Authentication and Access Authorization shall adhere to the approach defined for the Standard Model.

6.1 Customer Identification

Search and selection of a customer may require additional validations to ensure the correct customer record has been retrieved for a given transaction. Some central-office transactions may not require the selection of a specific customer, rendering this step optional for this model.

6.2 Authentication and Access Authorization

Authentication and access authorization shall always occur prior to the start of any standard transaction. This applies to all SCDMV employees and authorized agents of the SCDMV who are performing transactions on behalf of SCDMV. This will include access controls, single sign-on, integration with Active Directory, location awareness (and geofencing capability), central administration of user accounts, and session management.

6.3 Eligibility

The functionality for eligibility shall be provided. See section 5.3.

6.4 Workflow

The functionality for workflow shall be provided. See section 5.4.

6.5 Supporting Documents

The functionality for supporting documents shall be provided. See section 5.5.

Appendix 06 - Standard Transaction Model Page 19 of 23

6.6 Payment

Customer approval is not required. The functionality to process and account for payments shall be provided. See section 5.6.

6.7 Product/Service Delivery

The functionality for product and service delivery shall be provided. The channel for delivery may depend on the product or service to be delivered to the customer. See section 5.7.

6.8 System Reconciliation/Closeout

The functionality for system reconciliation and closeout and shall be provided. See section 5.8.

Appendix 06 - Standard Transaction Model Page 20 of 23

7 Standard Transaction Support

The new systems shall support a range of Batch Jobs and Web Services to meet the needs of the SCDMV.

7.1 Batch Processing Model

The new systems shall support a range of batch jobs to meet the needs of SCDMV business units. Batch interfaces may be required to process incoming files or generate outgoing files for SCDMV business partners. The following requirements apply:

1. Batch applications may be scheduled to run daily, weekly, monthly, or on other predefined schedules, and they may also be executed on demand as needed.

2. Database maintenance activities, such as backups, archiving, and purging, shall typically be executed as scheduled batch processes. These activities must be coordinated with batch jobs supporting various business processes.

3. Batch jobs are expected to produce documents for automated mail processing and bulk extracts. These may include vehicle registration documents, titles, driver license renewals, reminders, postcards, and other items. The batch system shall have the capability to track and report transaction volumes and supply quantities by document type or bulk extract.

4. Batch jobs shall be capable of producing various types of output, including reports, emails, and files.

5. An operations manual shall be prepared, containing a runbook for each batch job. The runbook shall include information on scheduling frequency, dependencies, constraints, inputs, outputs, criticality, error messages, and restart instructions.

6. Batch jobs shall utilize various technologies to transfer data into and out of the SCDMV system, including web services, SFTP, and email.

7. The system shall exchange data with external computer systems, process the received data, and reconcile results by identifying successfully processed records and notifying the other party or external system of any records that could not be processed due to errors.

8. The system shall provide authorized SCDMV employees and agents with the ability to enable or disable batch functions.

Appendix 06 - Standard Transaction Model Page 21 of 23

7.1.1 Scheduling

An enterprise scheduling utility shall be included in the system’s functionality. This utility shall trigger batch jobs on a regular schedule, trigger batch jobs that are dependent on successful completion of other jobs, and/or trigger batch jobs that only run in the event of a failure in a previous batch job. This coordination of dependencies in the execution of a batch job can extend to resource dependencies by starting a batch job only if a required input file is available.

The Contractor shall be responsible for establishing all schedules and dependencies to comply with the requirements for batch processing.

7.1.2 Ad Hoc Jobs

Aside from normally scheduled jobs, requirements may call for ad hoc or on-demand jobs. The Contractor shall implement a mechanism allowing the authorized SCDMV employees and agents to submit jobs of this type.

7.1.3 Internal Features of Batch Jobs

All batch jobs are expected to include a set of standard features as listed here:

1. Accept input parameters to control execution or processing scope (date, # of records, etc.)

2. Produce control total reports.

3. Produce an audit record.

4. Produce meaningful error messages that are fully documented and uniquely coded.

5. Provide for long-running jobs to be interrupted or paused and restarted without data loss or reprocessing.

6. Provide for roll-back of in progress database updates when an unrecoverable processing error is encountered.

7. Efficiently commit database updates.

8. Produce report output using standardized templates.

9. Communicate success or failure codes to the job scheduling utility.

10. Communicate periodic status information when a job is expected to run for hours with no discernable output or activity.

11. Provide features to prevent processing input more than once.

12. Batch jobs shall leverage common business rules and logic whenever possible.

13. Provide the ability to split batch jobs into different print queues depending on the priority.

Appendix 06 - Standard Transaction Model Page 22 of 23

7.2 Web Services Interface Model

Web services (e.g., XML-RPC, UDDI, SOAP, and REST) are required to allow external entities to request various SCDMV services. These web services may enable external parties or other government agencies to integrate SCDMV functionality and data access into their systems. Update transactions shall also be supported via web services.

As applicable, the same steps used for the other transaction processing channels apply to web services. Exceptions and adjustments are needed and will be outlined below. A standard model offers several benefits for web services provided by the SCDMV and will support the following:

1. Help capture and define requirements in a consistent manner.

2. Maximize reusability of common system components.

3. Help consolidate web services into fewer implementation deliverables.

4. Address security requirements from the outset.

7.2.1 Authentication and Access Authorization

Proper client authentication is critical to the web services infrastructure. The SCDMV anticipates use of one or more of the authentication mechanisms described in this section and is open to alternatives. The SCDMV seeks full encryption of message at its source until its delivery to the recipient. Eligibility requirements could be based on a Service Level Agreement (SLA) with the recipient that covers cost-based request, time-based requests, or volume-based requests.

Regardless of the applicability of an SLA, the recipient shall be pre-authorized for the requested access.

7.2.2 Customer Search and Selection

For web services, the customer search may in fact be the only service required, with no further transaction processing. Optionally, most requests will identify the customer, vehicle, or license for the transaction.

7.2.3 Transaction Configuration

It is expected that some requests will mirror transaction processing available for central office or over-the-counter processing. This is typical when an authorized SCDMV partner processes business transactions on behalf of the SCDMV, using their own proprietary software. The system shall enable this type of request and interaction by leveraging common services. To these common services, a web service request is no different than a request received for an over the counter or the central-office transaction.

Appendix 06 - Standard Transaction Model Page 23 of 23

7.2.4 Customer Qualification

This step is only relevant for transactions that grant privileges to an individual or business and is therefore optional.

7.2.5 Transaction Data Capture

All transaction data is provided as part of the payload for the web service, so this step is not relevant with the exception of input validation, which shall leverage the server-side validations used for over-the-counter transaction processing.

7.2.6 Document Imaging

Document imaging may be performed by the customer, prior to the web service call.

Therefore, images may be included in the web service payload. Document images may also be provided via other means.

All customer provided images shall trigger a workflow to allow an SCDMV employee to confirm/set document type and provide indexing information, prior to permanently storing in the Content Management system.

7.2.7 Business Rules and Transaction Validation

Web Services shall leverage common business rules and logic whenever possible. All transaction processing shall be service oriented to support multiple channels.

7.2.8 Deficiency Reporting & Correction

Web Services shall return detailed error codes that are fully documented.

7.2.9 Finalize Transactions

1. The system shall support SCDMV Financial Management subsystem requirements.

2. Traditional payment processing may not be possible within a web service request.

However, the system shall calculate and account for any costs allocated to a web services client.

3. Documents printed by SCDMV, as a result of a web service transaction, shall be batched for aggregate printing and delivery.