Business Requirement Interface to Phoenix Customer Lookup South Carolina Department of Motor Vehicles

Last Update: June 01, 2015

Business Requirement

Table of Contents

Business Requirement

Page i

Project Requirement #2 Interface to Phoenix for customer search at greeter station Business Requirement Overview Interface The Queuing System to Phoenix by initiating a customer lookup via web services against the Phoenix database. Additionally, a staging table will be updated so that the CSR can select the appropriate ticket/customer and populate Phoenix – Credential Number, Title Number, Registration Number, and/or Correspondence Number.

This process will save time and money by eliminating several manual steps and improving the accuracy by utilizing the existing barcodes. The typical error rate for data entry is one error per 300 characters. Barcode scanners are much more accurate; the error rate can be as good as one error in 36 trillion characters depending on the type of barcode used.

Business Process (Business Flow) Process Flow When a customer enters the DMV, the customer is still engaged at a greeter station or kiosk. At an office with a greeter station, the customer’s barcoded credentials will be scanned first, then any other barcoded documents. If the customer does not have a barcoded driver’s license, the greeter will enter their full name and date of birth in The Queuing System and execute the Customer Search Web Service. The Customer Search Web Service will return a maximum of one hundred customers along with the customers’ addresses in Phoenix that match the name and date of birth. The Queuing System will be updated to display the full name and address to the greeter. The greeter will search the records returned and if a matching record is found, the customer is enqueued and the Customer Queue Web Service is called to send information to Phoenix to write a new row in the staging table. If the customer is not found, the customer is a new customer and will be enqueued and the Customer Queue Web Service is called to send information to Phoenix. A new customer will not be created directly in Phoenix. However, the new customer information will be retained in the Staging table until retrieved into Phoenix.

The Customer Queue Web Service will insert a new row in the new staging table in Phoenix. This new table will store the DL number, customer number, VIN, Title number, and Tag number, and Registration number. For a complete list see Appendix 8 - Data Elements for Staging Table on page 26.

When the ticket is closed in The Queuing System, The Queuing System will execute the Customer Queue Web Service to update the status in the staging table and return the Phoenix Customer number to sync the The Queuing System database. See “Closing a Ticket” for more details on this step. For the new customer, this will require Phoenix to determine the customer number and/or the driver’s license number assigned. That number will be returned to The Queuing System so that the database can be updated. The customer number will be prefixed by “CN” in the The Queuing System database. Currently, a credential number is prefaced by “SC.”

Closing a ticket:

The CSR will go into The Queuing System as they do today to close the ticket. However, The Queuing System will then call the CustomerQueue.Read operation to obtain the customer number for the ticket. Once the customer number is retuned to The Queuing System, the CustomerQueue.Update operation will be called to change the status on the staging table to “done.” Next, The Queuing System will call the CustomerRead.Read operation to obtain latest customer information including the Credential (e.g. Driver’s License Number or Beginner’s Permit) Number, DOB, and full name for the customer. The Queuing System, finally, will update its database with the necessary changes.

Phoenix is not going to maintain the staging table other than the single case of creating a new customer for an open ticket. In that case it will update the staging table to track the new customer number.

Name changes, DOB changes, address changes, issuance of a new Driver’s License or Identification card, etc. are not reflected in the staging table. When the ticket is closed the CustomerRead service will provide all the latest information from the Phoenix database. This is being done to simplify the Phoenix changes and to avoid data integrity issues as services are performed, backed out, recovered from crashes, etc.

Summary

The greeter will…

1. Scans the customer’s barcoded driver License or ID.

2. If no DL, enter customer information and / or Driver’s license number

3. Execute the Customer Search Web Service

4. Search the records returned from Phoenix for the customer

5. Scan remaining documents

6. Select a service

7. Enqueue the customer

8. Execute the Customer Queue Web Service Receptionist Console In the Future when a customer enters the DMV, the customer is engaged at a greeter station or kiosk. At an office with a greeter station, the customer’s barcoded driver License or ID will be scanned first.

The The Queuing System Receptionist Console needs to accept the following scanned credentials from the customer.

· SC ID Card

· SC Driver’s License:

· AAMVA 2000 DL/ID Standard (See Appendix 2 – SC License SC Card on page 17)

· AAMVA 2010 DL/ID Standard SC Data (See Appendix 1 – SC License Data Card on page 14)

When the greeter scans their Driver License or ID Card they will execute the Customer Search Web Service, where the customer’s identity is validated and their customer data is returned from Phoenix2.

If the customer does not have a barcoded driver’s license, the greeter will enter their full name in The Queuing System and execute the Customer Search Web Service. The current The Queuing System Receptionist Console will need additional search criteria to limit the number of customers returned from Phoenix2. From the sample below, you can see that using the current search process using first and last name will return more information than can be reviewed in a very short amount of time. The example below returned 170 Barbara Smiths.

Additional optional search criteria needs to be added the The Queuing System Receptionist Console to limit the number of customers returned when the receptionist executes the Customer Search Web Service.

The following search criteria need to be available:

1. Individual Search

a. Customer’s credential (SC Driver License, ID, Beginner’s Permit, or Identification Card)

b. First Name

c. Middle Name

d. Last Name

e. Date of Birth

f. City

g. Zip

2. Business Search

a. Business Name

b. City

c. Zip

Several samples of the additional search criteria are illustrated below.

For business customers, a new search capability will be added by adding a new field labeled “Business Name”. When the Customer Search Web Service is executed, it will search for that business. See Figure 6 – Customer Search using Business Name.

The business’ address will be returned for display in The Queuing System if there are multiple businesses with similar names. If multiple businesses are displayed, the greeter will choose the appropriate selection before enqueuing the customer.

By adding the above optional search criteria to the The Queuing System Receptionist Console, it will greatly limit the number of customers returned when the receptionist executes the Customer Search Web Service. The The Queuing System Search Results screen needs to be modified to display the following data elements for a maximum of one hundred customers returned from the Customer Search Web Service.

1. Individual Customer

a. SC Driver License

b. Customer Number

c. Last Name

d. First Name

e. Middle Initial

f. Date of Birth

g. Address

h. City

i. State

j. Zip

2. Business Customer

a. Business Name

b. Address

c. City

d. State

e. Zip

The receptionist scans the remaining documents.

The The Queuing System Receptionist Console will also need to be updated to accept the following scanned documents from the customer. All alphabetic data stored by The Queuing System will be stored as all capital letters.

· SC Title

· SC Registration

· SC Correspondence

The receptionist enqueues the customer.

The The Queuing System Receptionist Console will be updated to display the following scanned or keyed information displayed before the Customer Queue Web Service is executed. In the sample below, the fields from the scanned documents are displayed plus the Customer number which was returned by the Customer Search Web Service .

If the customer is not found, the greeter needs the ability to treat the customer as a new customer and assign a service and enqueue the customer as is done today ACF will also need to insert new customer record in their database as is done today.

Figure 9 - New Customer panel The The Queuing System Receptionist Console will be updated to execute the Customer Queue Web Service when the customer is enqueued. The New Customer panel will be updated to remove embedded spaces from the Personal ID.

The The Queuing System Service Console will be updated to execute the Customer Queue Web Service when the The Queuing System ticket is closed. The Customer Queue Web Service will update the status in the Phoenix staging table and return the Phoenix Customer number and/or Driver’s License Number to The Queuing System to sync the database. This will eliminate the need for the CSR to manually update the reference fields for new customers.

Business Rules:

1. One Document per type (i.e. one registration). For example: A customer presents two Titles to be processed. Only one title will be scanned.

2. Maximum number of documents is four. If multiples are scanned, return error “One Document per type allowed”.

3. Scan order does not matter

The SC DMV The Queuing System Interface Web Application will consist of the following:

The The Queuing System Receptionist Console will also need to be updated to accept the following scanned documents from the customer. All alphabetic data stored by The Queuing System will be stored as all capital letters.

· SC ID Card

· SC Driver’s License:

· AAMVA 2000 DL/ID Standard (See Appendix 2 – SC License SC Card on page 17)

· AAMVA 2010 DL/ID Standard SC Data (See Appendix 1 – SC License Data Card on page 14)

· SC Title

· SC Registration

· SC Correspondence

Customer Search Web Service The customer search web service will return a maximum of one hundred customers in Phoenix that match the name and date of birth. The greeter will search the records returned and if a matching record is found, the customer is enqueued otherwise the customer is treated as a new customer, with a format of Last_First_Initial_MMDDYY (the same format that is used today) where MMDYY equal their date of birth.

Customer Queue Web Service

a. Insert a new record in the Phoenix Staging Table

b. Update the “Status” in the Phoenix Staging Table

c. Return the Customer Number, and/or Driver License Number, and customer data to sync the The Queuing System database when the ticket is closed.

The customer can present multiple documents to the greeter, so the soap message to Customer Queue Web Service has to contain all the possible key elements from each document. See Appendix 6b – Data to SC DMV Customer Queue WS on page 26.

The bar coded documents that are accepted by DMV are listed below with references to samples of the data encoded and the format / data elements:

1. Driver License (SC Card & Data Card), See Appendix 1 - SC License Data Card – data encoded in the barcode on page 14.

See Appendix 1a - SC DL/ID Data CardMandatory Data Elements on page 15 – format / Data Elements of bar code See Appendix 2 - SC License SC Card on page 15 – data encoded in the barcodes

2. Title See Appendix 3- SC Title on page 18– data encoded in the barcode.

See Appendix 3a - Title Mandatory Data Elements on page 19 – format / Data Elements of bar code.

3. Registration See Appendix 4 - SC Registration on page 21 – data encoded in the barcode.

See Appendix 4a - SC Registration Mandatory Data Elements on page 22 – format / Data Elements of bar code.

4. Correspondence – is scheduled to be bar coded in the future

Staging Table The Data Elements for Phoenix Staging Table are listed in Appendix 8 – Data Element for Staging Table on page 28.

The staging table will be accessed via a new Entry Field (Q-Tkt #) on PhxMenu (see Appendix 9 – PhxMenu on page 29). Primary focus will be the Q-Tkt# entry field. There the CSR will key in the The Queuing System ticket number. Phoenix will read the staging table upon the Q-Tkt# field losing focus (advancing to the next field). Phoenix will then display the customer’s name and photo allowing the CSR to greet the Customer by name (see Appendix 9 – PhxMenu on page 29 for placement of the ticket number and customer’s name). The name displayed on the PhxMenu will be determined from Customer information from the bar coded Driver License or the name entered in The Queuing System. The Staging table status is set to “In Service.” The CSR will select the appropriate transaction and Phoenix will then switch either to Cust Edit or Cust Search if the customer on the Staging table is found. When the CSR flows to the NEXT transaction, Phoenix will prefill the Customer Name, Customer Number, Credential Number, VIN, Title Number, Correspondence Number, etc. depending on the transaction type.

When the ticket is closed in The Queuing System, The Queuing System will execute Customer Queue Web Service to Update the Staging table status to “Closed” and return the Phoenix Customer Number and/or Driver’s License Number to The Queuing System to sync the database, where possible.

In the event the CSR processed the wrong record, they will need the ability to undo the record and select the appropriate record.

At the end of the day, all rows will be copied to the History table and physically removed from the staging table.

Flow Charts

Appendix 3 – SC Title Sample of data encoded in Bar Code Format PDF417 AAMVA Title and Registration Standard

Data encoded in Title Bar Code

AAMVA6360050101TD00290179TDTACSC

TAA0770610285103822D

TAV20141021

VAL2004

VAKNISS

VAD5N1ED28TX4C664813

TAF000000078249

TAU20141008

NAATEST

NAETEST KYLE

NAR6 CAMERON CT

NATCOLUMBIA

NAUSC

NAV292052800

TAG1

Appendix 3a – SC Title Mandatory Data Elements

Appendix 4 – SC Registration Sample of data encoded in Bar Code Format PDF417 SC Document of Registration AAMVA Title and Registration Standard

Data encoded in Registration Bar Code

AAMVA6360050101RG00290166RG

RBB20141021

RAG20161031

RAMKPF602

RBDTEST

RBETEST KYLE

RBI6 CAMERON CT

RBKCOLUMBIA

RBLSC

RBM292052800

VAD5N1ED28TX4C664813

VAKNISS

VAL2004

VAOSU

RBT20151031

RBU

Appendix 4a – SC Registration Mandatory Data Elements

date

date

Appendix 5 – List of Codes and Messages Complete list of codes to be provided by programmer. Wayne.

Appendix 6a – Data to SC DMV Customer Search WS

Data to Customer Search WS

Sample Data to Customer Search Web Service

From Driver License Scan

Sample Data to Customer Search Web Service

From The Queuing System Name / DL Lookup

From The Queuing System Name / DL Lookup

Driver’s License

Last Name

First Name

Middle Initial

Date of Birth

Data to Customer Read WS

Appendix 6b - Data to SC DMV Customer Queue WS

Data to SC DMV Customer Queue WS

Standard Fields

Create TS

Last Update TS

*-VIN and Registration VIN are represented since one or both of the documents can be presented to be scanned.

Appendix 7 - Customer Search WS Data returned to The Queuing System

The Queuing System Sync Data

SC Driver License

Customer #

Last Name

First Name

Middle Initial

Name Suffix

Date of Birth

Address 1

Address 2

City

State

Zip

Note: The CustomerRead service returns the same data elements Appendix 8 – Data Elements for Staging Table

VARCHAR2(32 BYTE)

VARCHAR2(32 BYTE)

VARCHAR2(32 BYTE)

VARCHAR2(3 BYTE)

NUMBER(9)

NUMBER(10)

NUMBER(10)

VARCHAR2(30 BYTE)

VARCHAR2(13 BYTE)

NUMBER(9)

NUMBER(9)

VARCHAR2(32 BYTE)

Middle Initial

Date of Birth

NUMBER(9)

NUMBER(10)

VARCHAR2(8 BYTE)

VARCHAR2(8 BYTE)

VARCHAR2(32 BYTE)

VARCHAR2(32 BYTE)

DATE

Appendix 9 – PhxMenu

Figure 10 image1.emf

Microsoft_Visio_2003-2010_Drawing.vsd Reception

Customer presents documents

Customer has scannable DL?

Scan all documents

Web Service Customer Search

Phoenix

Enter Name and DOB

Customer Found?

Return customer information/list to Q-Flow

Single selection returned?

Enqueue customer

Q-Flow

Display selection list

Select customer from list

Web Service to write staging table

Yes

No image2.emf

Microsoft_Visio_2003-2010_Drawing1.vsd

Text�

Close ticket in Q-Flow

Call Web Service (Customer Que)

Update status on Staging Table

Sync data in Q-Flow (Assign DL Number)

This is the close ticket function from Q-Flow image3.jpeg