XML Motorist Modernization Project

Florida Department of Highway Safety and Motor Vehicles

June 26, 2018

FRIP Website• https://www.flhsmv.gov/frip/draft-procedure-manuals/

• On this website, you will find the procedure manuals, FAQs and test scripts.

What You Need to Know

The XML Conversion is mandatory.

1We will no longer be accepting FLAT files or manual processing.

2All companies currently submitting in XML format will still need to update processing for the future requirements.

3Our pilot go-live is scheduled for Spring 2019.

4

Structural Testing Data

Test data for reloads and daily files can be a snapshot of production data from June 2016 to March 2017.

If you do not have data for that timeframe, you may use current production data. The data cannot be created data, which means the data must match what we have on our database.

Although you will be using production data to conduct functional and structural testing, all data will be used in a stage environment.

Definitions

Structural Testing: A form of non-functional, white box testing, which allows third-party users to integrate and test the development of code against the department’s services prior to production release. This serves as an advantage to all parties involved, as it mitigates risks during production release.

XML: Extensible Markup Language used to describe data and report files electronically.

XSD: (XML Schema Definition) is a World Wide Web Consortium (W3C) recommendation, which specifies how to formally describe the elements in an Extensible Markup Language (XML) document. This description can be used to verify each item of content in a document adheres to the description of the element in which the content is to be placed.

Procedural Timeline

Development (2018)

Functional Testing(2018)

Structural Testing(Two-week cycle before 12/31/18)

Completion/ Sign Off

(Before 12/31/18)

Example

7/1/2018 Development Functional Testing

Structural Testing Begins

10/1/2018

*These dates are estimated and are not standard for each company/vendor

Day 1 – Submit all successful files

corresponding to test cases submitted.

Today

Step 1 – Development

• During this phase you should 1. Review the draft and final Procedure Manuals –https://www.flhsmv.gov/frip/draft-procedure-manuals/

2. Review the test scripts • Please ensure you have the correct test scripts listed below

3. Modernize your XSDs • The XSDs are located on page 31 in the final Daily Procedure Manual and page 18 in the

final Reload Procedure Manual. 4. Make the necessary internal system adjustments.

Connection to SFTP Server• Host name: Please review the manuals

• Username: This will be your 5-digit FL company code or vendor code assigned by the department.

• Password Requirements: Minimum length (8), requires 1 letter, 1 number and 1 special character.

• Port: 22

If you do not have login credentials for the SFTP server, please email FLHSMVInsuranceLiaison@flhsmv.gov

XMLStage Subfolders

• Archive

• Dailyload

• Output

• Reload

• Test

• Verifications

If you do not see your XMLStagesubfolders, please email FLHSMVInsuranceLiaison@flhsmv.gov

Archive Folder

• This folder is where the files processed from the Daily load folder (Dailyload) placed by the insurance companies are moved after they have been processed.

• This folder also contains the submission files from the insurance companies.

• You will have access to this folder; however, please do not delete from this folder.

• You will not upload files to this folder. It is simply a retention folder.

DailyloadFolder

• The Dailyload folder is used to update the DHSMV information regarding changes to policies, and is processed multiple times a day.

• Daily load files will be processed every hour on the hour Monday through Friday.

Output Folder

• The Output folder is used by the DHSMV to inform the insurance companies of the file transfer results. Insurance companies should delete the files from this folder once they have been retrieved.

• All files will be marked with the date and timestamp for easy retrieval.

Ex: YourFileName_TimeStamp_DL_TransactionReport.pgp• You should expect to see an equivalent amount of

transaction reports from the daily load file submission files sent.

• If you submit one daily load file, you should expect to receive one transaction report returned.

• If you submit a reload file, you could receive between one and three return files.

• Missing, cancelled (error files) and transaction Report. • If the reload was fully imported, then you will receive a

transaction report only.

Reload Folder

• The Reload folder will be used when an insurance company wants to perform a complete reload of their active policies.

• Files will be processed overnight during the hours of 12 a.m. to 6 a.m., EST.

• There will be two error files generated, if necessary. One file will be for cancelled policies and the other will be for missing policies. The file naming convention is as follows:

• YourFileName_TimeStamp_BulkPolicyError_Cancelled.pgp

• YourFileName_TimeStamp_BulkPolicyError_Missing.pgp

• Only transactions 20 (Initiation of Insurance), 31 (Add Vehicle) and 34 (Add Driver/Policyholder) will be accepted.

Test Folder • The Test folder is not used for functional or

structural testing because the test scripts will verify your files are formatted correctly and can be received.

Verifications Folder

• The Verifications folder is where the DHSMV places all verification file requests, which are required to be retrieved daily by the insurance company for review and response.

• The verification file requests are sent daily.• Verification file requests are placed in each

company’s SFTP account Monday through Friday and contain all FR sanctions, which have been reinstated with insurance provided by customers including SR21, SR22(BIL), SR22(PIP/PDL) and FR44 policies.

• Also included will be pre-FR crash sanctions (FR1, FR9) and registration sanctions (FR8), where the department cannot find proper insurance coverage for each of these events.

Step 2 – Functional Testing • During this phase you should

• Use the manuals to complete functional testing. • Use a naming convention – “unique” file name and date.• Generate transactions from the test scripts to create an XML file.

• Use the “Revision- Daily” spreadsheet to generate a daily file. • Use the “Revision- Reload” spreadsheet to generate a reload file. • Use the “Revision- Verification” spreadsheet to receive and answer a

verification file.• Submit your files to the appropriate XMLStage subfolders.• Keep copies of the submission and return transaction reports.• All the above spreadsheets must be completed before the start of your structural

testing cycle.

Testing the Reload• In order to complete testing for the reload process, you must successfully submit a reload with

the following:• All policies imported successfully,• A missing policies error file returned, and• A cancelled policies error file returned.

• Once you have successfully submitted a reload file, even if you receive missing and cancelled policies, there is NO REQUIREMENT to reconcile these policies in order to pass structural testing.

• However, reconciling can be used during testing of the daily process by using the missing policies for transaction 20 (Initiation of Insurance) files and a cancelled policies file for transaction 10 (Cancellation/Non-Renewal) files.

Step 3 – Structural Testing

• No development or file submission to the SFTP server should be conducted during this time.

• During this two-week cycle, you will send your submission files and returned transaction reports to your testing liaison.

• If your test scripts do not pass, they will be returned and you will be given the opportunity to fix the errors during the two-week cycle.

• Your testing liaison will validate your files based on the test scripts.

File Submission • Companies and/or insurance vendors will begin submitting files during their development and functional

testing via the SFTP process.• Upon entering structural testing, companies and/or insurance vendors will submit all test scripts

(spreadsheets) to their assigned testing liaison. • Within the test scripts submitted, companies must

• When filling out the comments section, include a “unique” file name, date and policy number for each submitted file.

• The recommended naming convention for files is –InsuranceCompanyCode_Date_FileName_FileNumber (i.e. 01234_0627_Daily_001)

• When submitting multiple files each day, use a different sequence number for each file. The file name with sequence number is the “unique” file name and would be placed on the spreadsheet. See below.

• 01234_0627_Daily_001• 01234_0627_Daily_002• 01234_0627_Daily_003 – If this is the file you will sending for structural testing, then indicate Daily 003, 0627, policy number in the comments

section.

• Companies may• Use files submitted during their development and functional testing to satisfy their structural testing requirements,

OR• May choose to submit separate files specifically for structural testing.

• Additionally, when submitting the test scripts and a particular step does not apply, a comment must be submitted on the spreadsheet stating precisely why they will not be testing and submitting results for that particular step(s).

• For example, if a company is utilizing a vendor to process their verification files, the company will need to clearly communicate that information along with their vendor name to avoid confusion during the structural testing period.

Sample Submission

File a single transaction

reload (or transaction 20 (Initiation of Insurance) daily)

Sample Return File a single transaction reload (or transaction 20 (Initiation of Insurance) daily)

Sample Verification File

Verification XSD

• There is no “XSD” for verifications because it is not an input file; instead, it is the verification file you receive from the department.

• Verification request files are what you receive, translate and send back to the department in a daily file as a transaction 12 (SR21 Verification Responses).

Test Scenarios• Any transaction-specific error can be tested in a combined file with multiple error

transactions per file. One single file is not required for each test step for transaction specific errors.

Step 4 – Completion/Sign Off

• Once your testing liaison has validated your test scripts have passed, each company representative will sign off on the XML Conversion Project.

• For companies using a vendor, once your vendor has completed and passed structural testing on your behalf, you will be notified and your company can sign off on the Florida Financial Responsibility Insurance Data Exchange – XML Conversion with the DHSMV for accountability purposes.

Contacts

If you have any technical questions, comments or concerns regarding the XML Conversion Project, please send them to FRFTPXML@flhsmv.gov.

If you have any reporting or requirement questions, please send them to FLHSMVInsuranceLiaison@flhsmv.gov.

For specific company concerns (non-technical inquiries), please consult with your assigned testing liaison.

Questions?