# Presentation: 778041

## Session 6

- S2	Deployment State CVISN System Design
- S3	System Design Guidelines/ Pre-Work Review
- S4	Panel Discussion
- S5	Safety Information Exchange
**S6****	****Credentials Administration**
- S7	Conformance Assurance Process/Questions
- S8	Electronic Screening
- S9	Scope Workshop Recap
- S10	Work Session & Consultation
- S11	State Presentations
- S12	Feedback and Next Steps

**Session 6**
**Credentials Administration**

## Session Plan

- Overview: Credentials Administration (20 min)
- Conforming with the CVISN Architecture (10 min)
- State, Carrier, and CVISN Core Infrastructure Credentials Administration Systems (15 min)
- Example scenario (15 min)
- IRP Registration; Supplement, Add Vehicle
- Snapshot updates
- State-to-state fee reconciliation via IRP Clearinghouse
- Breakout Plan (10 min)
- Breakout: State CVISN system design (120 min)
- LUNCH
- State presentations & questions (30 min)
- Total Time =  220 min (3 hrs 40 min) + 55 min lunch

## Session Objectives

- Understand CVISN operational concepts and architectural guidelines related to Credentials Administration:
- Electronic credentialing via Web Site, stand-alone Carrier Automated Transaction (CAT) system, fleet management system “CAT module”
- Use of Web, EDI, XML
- Legacy Modifications (LMs) or Legacy System Interfaces (LSIs)
- Credentialing Interface (CI)
- Clearinghouses
- Walk through a credentials administration example
- Make preliminary design decisions about credentials administration in your state

## Credentials Administration

- The Credentials Administration ITS/CVO capability area includes:
- All aspects of applying for, reviewing, and granting CVO credentials; paying the associated fees
- Credentials include:
- International Registration Plan (IRP)
- International Fuel Tax Agreement (IFTA)
- Intrastate Registration
- Carrier Registration
- OS/OW Permits
- HazMat Permits
- Titling
- Electronic Screening Enrollment
- Filing returns on fuel taxes; paying the associated taxes
- Managing information about credentials and tax payment status
- Providing information to roadside enforcement and administrative users
- Supporting base state agreements and associated fee payment reconciliation

*Overview*

**Notes:**
This is credentials administration in general, not specifically e-credentialing.
A credential is defined to be the authority granted by the issuing jurisdiction.  Today, most credentials are issued in paper form, with supporting records on file in the issuing jurisdiction’s system.   An electronic credential is an electronic record of the credential.  
The authoritative source for an electronic credential is the issuing agency.  The holder of the credential may be issued an electronic copy that represents the same authority as today’s paper copy. 
Operating a commercial vehicle in the United States requires many “credentials.”   Vehicles must be titled and registered.  Some credentials are required for carriers, vehicles, or drivers that will operate only within a single state (intrastate), and different credentials are required for those that will be operate in multiple states (interstate).  Carriers must have adequate liability insurance and be authorized to carry certain types of “cargo” (e.g., hazardous materials, people, and household goods).  Special permits are required to operate vehicles that are over the standard legal weight or size.  Drivers must be licensed to drive whatever size vehicles they intend to operate, and must meet medical standards.  Carriers must pay fuel taxes for operating vehicles in each jurisdiction.  Some states have additional credentialing requirements.
Emphasize that IRP and IFTA are CVISN Level 1

## Major components of Credentials Administration:

- Electronic credentialing
- Interstate credentials data and fee exchange
- Interagency (within your state) credentials data exchange

*Overview*

**Notes:**
Electronic credentialing - the carrier applying for, paying for, and receiving credentials electronically
Interstate credentials data and fee exchange - 
using CVIEW and SAFER to exchange credentials information with other states
using the clearinghouses to support base state agreements and fee payment reconciliation with other states
Interagency (within your state) credentials data exchange
how credentials data is exchanged between legacy systems, CVIEW, etc. within the state

## Electronic Credentialing

**Electronic**
**Application**
**Payment**
**Transmittal**

**Review**
**Edit / Validate**
**Upload**
**Process Payment**
**Credentials Issued**

**Minutes Later............**

**Electronic**
**Credentials Receipt**

**Increased Handling Capacity    /   Focus on Exceptions**
**Increased Accuracy      /      Improved Cash Management**

*Overview*

**Notes:**
Expected benefits are:
Reduced cost and red tape for agencies and carriers
Improved regulatory compliance
Improved carrier efficiency in getting new vehicles on the road
Improved access to credential status information for roadside users. 

With electronic credentialing, the system is taking over many of the routine functions that the state staff previously performed.  The carrier is still doing all the same things, but he is doing them electronically and the payment and application are submitted at the same time.

The system is reviewing, editing, uploading - data entry on the state side is eliminated.  And the system is issuing the credential back to the carrier in a matter of minutes rather than weeks.
The system increases your application handling capacity without increasing your staff.  It allows your staff to focus on exceptions rather than the routine - it makes better use of their expertise.

It reduces the percentage of returned applications and your cash management is improved - you get the money now, not six weeks from now.

## FMCSA Policy for Electronic Credentialing

- FMCSA _requires_ that states implement either a person-to-computer or a computer-to-computer interface.
- FMCSA _recommends_ that states survey their stakeholders to determine whether both interfaces would be appropriate.
- FMCSA _recommends_ that, in the near term (over the next ~2 years), carriers and states use X12 EDI for computer-to-computer interfaces unless the state has evidence that customers support another approach.
- FMCSA _encourages_ the exploration of XML as an alternative to EDI.

*Overview*

## Goals for Electronic Credentialing

- Goals for Smaller Carriers
- Minimal investment and maintenance
- Simple and convenient
- Available to everyone
- Goals for Larger Carriers
- Computer-to-computer interface between state and carrier (in addition to person-to-computer interface via a Web site)
- Use an open interface standard supported by a Standards Development Organization (SDO) or technology consortium (versus a proprietary or closed interface).
- Allow carriers to have the credentialing function integrated into their fleet management software.

*Overview*

## Comparison of E-Credentialing Approaches

- Web Site
- Stand-alone Carrier Automated Transaction (CAT) System
- Fleet Management System “CAT Module”

*Overview*

**Notes:**
Carriers could use their standard Internet browsers to connect to the state’s Web Site and submit and retrieve credential applications and responses. 
Some pilot/prototype states sponsored the development of a stand-alone PC-based program called the Carrier Automated Transaction (CAT) system.  
Carriers may also choose to modify/upgrade their fleet management software systems to support electronic credentialing processes.  The fleet management software would perform the same functions as the CAT with one advantage: the processes would be integrated with other existing capabilities.

## A state Web site approach provides a

**Carrier**
- Or Service Bureau

**State**

**Credentialing**
**Systems with**
**Web Site**

- A state Web site approach provides a
-  person-to-computer interface.

**World Wide Web**

**HTML or XML**
- Web standards;
- no credentialing
- standards used

**Web **
**Browser**

*States can provide electronic credentialing using a Web site.  The carrier would access the Web site using a commercial browser (e.g., Netscape) and manually enter the required data. *

*Overview*

**Notes:**
Electronic commerce in many industries is migrating to the web-site-based solutions.
A carrier would connect to a state credentialing web site using a browser and enter the information on the web-site page(s). 
This solution meets the “Goals for Smaller Carriers”
Minimal carrier investment and maintenance
Simple and convenient
Available to everyone
This solution may not meet the “Goals for Larger Carriers”, as the manual data input may not be efficient

## A stand-alone CAT provides a computer-to-computer interface.

- Or Service Bureau

**State**

- A stand-alone CAT provides a computer-to-computer interface.

**Internet,**
- Dial-up, or VAN

**EDI credentialing**
**standards exist.**

**Stand-alone CAT**

**Stand-alone CAT**

- Optional use for state branch offices

**Credentialing **
**Systems**

*A carrier would enter vehicle information using the stand-alone CAT, where it would be stored locally.  The stand-alone CAT would exchange credentialing information with the state using standards. *

*Overview*

**Notes:**
The updated CVISN Architecture specifies the use of ANSI X12 EDI for a computer-to-computer interface, in the near term.  EDI standards have been developed for e-credentialing.  ANSI maintains the standards, and APL is maintaining the guidance for how to use them for CVO applications.  
The use of a stand-alone PC CAT was a good first step to establishing EDI standards for a computer-to-computer interface.  It solved the “chicken & egg problem” of carriers not wanting to invest in software until states were ready, and vice versa.  It allowed states to make a relatively small investment in developing a CAT in parallel with the development of a CI.
The initial implementation of the architecture was the Carrier Automated Transaction (CAT) system residing on a PC.  A state would accept electronic transactions to the Credentialing System (through the Credentialing Interface (CI)) using EDI standards.  Kentucky, Maryland and Minnesota are implementing or have implemented such an interface.  A state could also make the PC CAT available for carriers on a walk-up basis at a state’s branch offices.
The PC CAT solution may be most useful as an interim step during the next couple years until CAT modules become commonly available as part of Fleet Management System packages.
APL is starting to explore using XML in place of EDI.  Based on the prototype activities and the survey results, FMCSA may decide to direct APL to develop XML usage  guidelines.

## A CAT module could be integrated into

**State**

- A CAT module could be integrated into
-  existing fleet management systems to provide a computer-to-computer interface

**Internet, **
- Dial-up, or VAN

**EDI credentialing**
**standards exist.**

**Fleet Management System (including CAT Module)**

**Credentialing**
**Systems**

*CAT credentialing capabilities are integrated in carrier Fleet Management Systems (FMS) that already contain carrier and vehicle related information needed for credentialing and use EDI for financial information. The CAT module in the FMS would exchange credentialing information with the state using standards. *

*Overview*

**Notes:**
Typically medium and large size carriers have fleet management software (FMS) systems that support many of the tasks associated with their operations.  These systems often exchange financial and billing information using EDI standards.  They also contain inventory information on the carrier’s fleet of vehicles.  
Incorporating CAT capabilities into the FMS would allow the motor carriers to leverage their existing investment in FMS systems by automating and integrating the credentials administration process with other business functions. 
FMS systems may be “home grown”, if the carrier is large enough, or they can be purchased from software vendors.  Software vendors may see that including automated credentialing capabilities provides a  marketing advantage, and develop the CAT capabilities as part of their product.  However, it will not be cost effective for a software vendor to develop the software until a sufficient number of states commit to using automated credential transactions using standards; then the development costs can be spread over their customer base. 
Integrating credentialing into FMS systems is consistent with CVISN Architecture for computer-to-computer interface, if EDI standards are used. From state’s point of view, this is compatible with PC CAT.

## Strategy for Electronic Credentialing

*Overview*

- FMCSA endorses person-to-computer and computer-to-computer solutions for e-credentialing
- Person-to-computer solutions: Web-site
- Computer-to-computer solutions: EDI or XML.  (Note: EDI standards and implementation guides are available now. XML is a potential alternative.)
- Recommend states design for both in workshop process
- Recommend evaluating the market for both among their state carrier population via a survey or other study mechanism

**Notes:**
It is recommended that in this workshop you imagine that you will have the resources to implement both solutions, so design for both. That way, you won’t be locked into design decisions based on the first interface solution, then find out later that those decisions make the second solution impossible. 
In your notebook, under the tab for this session, is an example survey package. It contains two sample surveys - one for carrier and one for service bureaus - and a letter to send to the customer explaining the survey. The questions were based on the survey that we did for FMCSA in April, 2000, and on questions that the state of Oregon used in a recent survey of their customers.

## Electronic CredentialingSummary

**Generic State Commercial Vehicle Administration Systems**

**Carrier Systems**

**Credentialing **
**System **
**(e.g., CAT)**

**Service Providers**

**Internet Tools**
**(e.g. Browser)**

**Other Carrier**
**Systems**

**CV Info Exchange**
**Window (CVIEW)**

**Credentialing**
**Interface (CI)**

**Web Site**

*Breakout*

- Electronic CredentialingSummary

***Electronic Credentialing***: An operational process that uses software under the applicant’s control to send credentials applications (including fuel tax returns) to the state, and to get electronic notification of credentials status in return.  When feasible, the credential itself is returned electronically.  Electronic payment is an option associated with electronic credentialing.

- EDI      Electronic Data Interchange using open standards

**Using EDI now **
**(potentially XML)**

**Using Web browser**

**CVISN Level 1**

**EDI **
**(or XML)**

**Notes:**
This shows the systems and the carrier-to-state interfaces involved in e-credentialing for CVISN Level 1. Basically, this design shows a carrier using a Web Browser and interacting with the State’s Web Site, or a carrier using a purchased or developed software package for credentialing, and sending transactions to a new state software system, called a Credentialing Interface. We will talk more about these systems in a few minutes.
The boxes with dark lines are those state systems involved in credentialing, basically your legacy systems for IRP, IFTA Reg, and IFTA  tax processing, and the new CVIEW system.
Beyond Level 1, a state may want to implement e-credentialing for other credentials, such as intrastate registration, OS/OW, Hazmat, and titling & licensing. 

## Interstate credentials data exchange (1 of 2)

- Credentials information is passed to the state CVIEW (or equivalent).  State CVIEW forms snapshot segments and updates SAFER for interstate snapshots.
- CVISN Level 1
- Data exchanged:
- IFTA: carrier census information, IFTA account information, IFTA check flag and date
- IRP: carrier and vehicle census information, IRP account information, IRP check flag and date

*Overview*

**Notes:**
Credentials information is exchanged among states via SAFER and each state’s own CVIEW.
The IRP and IFTA data sent from the state CVIEW or equivalent to SAFER is the type of data needed at the roadside for screening.
It is not the fee data needed by the Clearinghouses.

## Interstate credentials fee exchange (2 of 2)

- The IRP and IFTA Clearinghouses support the IRP and IFTA base state agreements, respectively.  The state IRP and IFTA products interact with the clearinghouses to accomplish the financial reconciliation functions.
- CVISN Level 1
- Data exchanged:
- IFTA: carrier census information, IFTA account information, fuel tax information
- IRP: carrier and vehicle census information, IRP account information, IRP registration fee information

*Overview*

**Notes:**
States have reached reciprocity agreements on vehicle registration and fuel tax payments for interstate operators.  These are called “base state agreements.”   According to the International Registration Plan (IRP), the states agree that a vehicle registrant can file with a “base state,” and receive one license plate and cab card.  The base state will charge the registrant the sum of the fees due to all states in which the vehicle operates, based on miles driven in each state.  The base state sends apportioned fees to other states.  The International Fuel Tax Agreement (IFTA) is a similar arrangement in which a carrier files quarterly fuel tax returns with a base state on its operations in all states.  The base state apportions the fuel taxes to the appropriate jurisdictions.  All mainland states in the U.S., as well as some Canadian jurisdictions, are part of the IRP and IFTA.  
To support base state arrangements, states must collect fees from operators, apportion the fees collected to other states according to pre-determined criteria, and transfer funds to those states accordingly.  To facilitate that process, the design shown here involves clearinghouses to support those financial reconciliation activities.  This design centralizes the financial reconciliation required by base state agreements.  The clearinghouses could also be used to facilitate other kinds of information exchange.  For instance, the clearinghouses could support audits, and provide a consolidated reporting database.
The IRP and IFTA data sent by the state systems to the Clearinghouses is related to fees. It is not the type of data (check flags) needed at the roadside for screening.

## Interagency (within your state) credentials data exchange

- Credentials information is exchanged within the state via CVIEW and/or by direct interaction among state systems.
- State CVIEW maintains intrastate snapshots.

*Overview*

**Notes:**
Exchange of credentials data within your state supports many CVO functions.

## Conforming with the Architecture: Guidelines for a Carrier-to-State Web Site 

*Conforming with the CVISN Architecture*

- Conforming with the Architecture: Guidelines for a Carrier-to-State Web Site

- The State Web Site should only use Web techniques supported by the major browsers, Microsoft's Internet Explorer and Netscape's Navigator.
- The State Web Site should use the CVISN recommended primary identifiers.
- The State Web site should provide end-to-end electronic credentialing functionality, including invoicing and payment.
- The State Web site should be Section 508 compliant.
- More information is available in Chapter 6, Requirements and Design Guidance, of the CVISN Guide to Credentials Administration.

**Notes:**
In this part of the session, we will discuss how the state conforms with the CVISN architecture.
First we will talk about web sites, then we will talk about EDI.
Some states are planning to provide a World Wide Web site for electronic credentialing.  Carriers could use their standard Internet browsers to connect to the state’s Web Site and submit and retrieve credential applications and responses.
A Web site probably meets all needs of small to mid-size carriers, and is useful to even large carriers for individual transactions. 
Technical standards for the Web are now defined by the World-Wide Web Consortium (W3C).   
The Web site should use only techniques supported by the major browsers, namely Microsoft's Internet Explorer and Netscape's Navigator.
Section 508 is a Federal regulation stemming from the Rehabilitation Act of 1973, which has resulted in the development of standards for accessibility of Electronic and Information Technology (EIT) by the Access Board.  These standards were published in the Federal Register on December 21, 2000, and became enforceable on June 21, 2001.  As a result, most Federal agencies (as well as contractors) providing electronic and information technology to the government, must ensure the adherence of said EIT to the standards of 508. It serves disabled employees and prospective employees of the Federal government.and disabled citizens attempting to access information delivered by Federal IT resources.

## Conforming with the Architecture:EDI Standards

- Conforming with the Architecture:EDI Standards

- To conform with the architecture, if the State implements X12 EDI interfaces:
- The State should accept and respond to EDI X12 standard transactions with carriers for CV credentialing and tax filing (286, 813, 151, 997).
- A Carrier Automated Transaction (CAT) software product (or equivalent) should generate and respond to EDI X12 standard transactions with the State (286, 813, 151, 997).
- The State should provide invoice data for credentials using EDI X12 standard transactions (286).
- The State should exchange snapshot data with SAFER using EDI X12 standard transactions (285).
- The State should provide tax credits, tax calculations, and tax rate information to carriers using EDI X12 standard transactions (826, 149, 150; not required for Level 1).

*Conforming with the CVISN Architecture*

**Notes:**
The point is that if the state is going to use EDI, there are certain transaction sets that are applicable to credentialing administration.
Sending invoice data via TS 286 is not the same as an EDI electronic invoice. It is information only and does not move money like the TS 810.
TS 149, 150, and 826 are applicable to IFTA tax exchanges, but are not required for CVISN Level 1. 

## The ANSI X12 EDI transaction sets directly associated with electronic credentialing 

- The ANSI X12 EDI transaction sets directly associated with electronic credentialing

- TS 149*	Notice of Adjustment (state tax calculation)
- TS 150*	Tax Rate Notification
- TS 151	Electronic Filing of Tax Return Data Acknowledgement
- TS 285	CV Safety & Credentials Information Exchange (snapshots)
- TS 286	Commercial Vehicle (CV) Credentials
- TS 813	Electronic Filing of Tax Return Data
- TS 824	Application Advice
- TS 826*	Tax Information Exchange
- TS 997	Functional Acknowledgement
- * not required for CVISN Level 1 IFTA tax exchanges

*Conforming with the CVISN Architecture*

**Notes:**

Note that TS 151 is not being used by any of the states yet, but it is the proper transaction set to use to report data content errors. TS 997 is used to report syntax errors.

## Conforming with the Architecture

- Several design options that conform to the architecture are depicted in Chapter 6, *Requirements and Design Guidance*, of the CVISN Guide to Credentials Administration; the examples do not exhaust the possibilities.

*Conforming with the CVISN Architecture*

## State CVA Systems: States make design decisions about the extent of modifications to legacy systems.

- State CVA Systems: States make design decisions about the extent of modifications to legacy systems.

*State, Carrier & CVISN Core Infrastructure Credentials Administration Systems*

- EDI

**Carrier’s Bank**

**State’s Bank**

**Credentialing**
**Interface**

**State Systems**

**Legacy System 1 (e.g. IRP)**

**Web Site**

**Carrier Systems**

- HTML, XML

- EDI or Non-EDI

**CVIEW**

**EDI**

**LM**

**LSI**

**EDI or Non-EDI**

**Non-**
**EDI**

***snapshots***

**EDI**

**Non-EDI**

***snapshots***

- Legacy systems in the state may require modification (**LM**) to support new CVISN functionality and interfaces.
- If it is impractical to modify a legacy system to handle the EDI interfaces, a legacy system interface (**LSI**) may be added.

**Notes:**
You always need to modify the legacy system to support e-credentialing. The question is, to what extent do you modify the legacy system.
In this diagram, we are looking at a case in which the state chose to implement a computer-to-computer solution.
The interface between the CI and Legacy System 1 uses EDI. The IRP system has been modified to accept and generate EDI.
For Legacy System 2, the state chooses to implement a non-EDI interface with the CI.  The LSI between the CI and Legacy System 2 translates from the carrier’s input to the legacy system’s “native format”.  The LSI may actually be implemented as a component of the CI.  So the IFTA system is modified to handle e-credentialing, but not modified to handle EDI.

## State CVA Systems: The Credentialing Interface provides a convenient interface within the state to accept e-credentialing applications from carriers, and to relay responses from state systems to carriers.

- EDI

- State CVA Systems: The Credentialing Interface provides a convenient interface within the state to accept e-credentialing applications from carriers, and to relay responses from state systems to carriers.

**Carrier’s Bank**

**State’s Bank**

*State, Carrier & CVISN Core Infrastructure Credentials Administration Systems*

**Credentialing**
**Interface**

**State Systems**

**State Credentialing Systems**

**Web Site**

**Carrier Systems**

- HTML, XML

- EDI or Non-EDI

**Notes:**
The CI is a new system that the state will implement to interface between the state’s legacy credentialing systems and the carrier.
For the computer-to-computer solution, the CI will interface directly with the carrier’s CAT.
For the person-to-computer solution, the CI will interface with the web site.
Regardless of the interface used to interact with the carrier, the processing of the carrier-provided inputs should be the same in the CI and the legacy credentialing systems.
The CI may have a user interface to allow for optional manual review of applications.

## State CVA Systems: The State Web Site provides a convenient interface, particularly for small carriers.

- State CVA Systems: The State Web Site provides a convenient interface, particularly for small carriers.

*State, Carrier & CVISN Core Infrastructure Credentials Administration Systems*

**Credentialing**
**Interface**

**State Systems**

**State Credentialing Systems**

**Web Site**

**Carrier Systems**

- HTML, XML

**Carrier’s Bank**

**State’s Bank**

**Notes:**
When the state is designing the web site, remember that the state staff may be users too, as they may be entering applications for walk-ins via the web site, rather than via the legacy system.

## Carrier CVA Systems: The Carrier Automated Transaction (CAT) module allows carriers to apply for and obtain credentials electronically.

**Web Site**

**State Credentialing Systems**

- Carrier CVA Systems: The Carrier Automated Transaction (CAT) module allows carriers to apply for and obtain credentials electronically.

- Data entry screens for credential applications & fuel tax filing
- Validate application
- Specify payment method
- Compute fees (some, not all)
- Print applications
- Initiate payments through banks (future)
- Translate to/from EDI/non-EDI transactions
- Send transactions
- Receive transactions
- Acknowledge transactions
- Print credentials, if authorized
- Archive transactions

***The Carrier Automated Transaction performs these functions:***

**Carrier’s Bank**

**State’s Bank**

- EFT

*State, Carrier & CVISN Core Infrastructure Credentials Administration Systems*

**Credentialing**
**Interface**

**State Systems**

**Carrier Systems**

- EDI

**EDI or Non-EDI**

**Other Carrier Admin/Mgt Systems**

**Notes:**
Carriers may also choose to modify/upgrade their fleet management software systems to support electronic credentialing processes.  The fleet management software would perform the same functions as the CAT, with one advantage: the processes would be integrated with other existing capabilities.

## Core Infrastructure CVA Systems: The IRP Clearinghouse processes information received electronically from states to compute fees due/owed each jurisdiction, and facilitates periodic funds transfers.   

**State A**

**State B**

- Core Infrastructure CVA Systems: The IRP Clearinghouse processes information received electronically from states to compute fees due/owed each jurisdiction, and facilitates periodic funds transfers.

**IRP**

**IRP**
**Clearinghouse**

**IRP CH **
**Bank**

**IRP**

**State B **
**Bank**

**State A **
**Bank**

*State, Carrier & CVISN Core Infrastructure Credentials Administration Systems*

**Notes:**
The IRP Clearinghouse streamlines the exchange and reconcilement of registration information and fees by:
enabling states to electronically exchange motor carrier and fee information between jurisdictions
providing an electronic remittance netting function with concurrent Electronic Funds Transfer (EFT) capability through a central IRP bank
tracking all amounts due to/from a base jurisdiction, from/to all foreign jurisdictions
providing reports on the information exchanged and netted fees processed
The IRP Clearinghouse is fully operational now. Today, there are 24 jurisdictions that are actively participating in the Clearinghouse, electronically exchanging registration information and fees. 

## Core Infrastructure CVA Systems: The IFTA Clearinghouse provides secure access to tax information for IFTA, Inc clients.

**State A**

**State B**

**IFTA**

**IFTA**
**Clearinghouse**

**IFTA**

- Accept data (demographic & transmittal) submitted by clients (EDI)
- Provide standard reports
- Provide transmittal data entry screens
- Respond to standard & ad hoc queries
- Maintain Tax Matrix & Reference Table

***The IFTA Clearinghouse performs these major functions:***

- EDI

- EDI

- 286, 826, 997

- 286, 826, 997

*State, Carrier & CVISN Core Infrastructure Credentials Administration Systems*

**Notes:**
The IFTA Clearinghouse was devised to replace paper exchange of data with automated exchange to support business processes. The Clearinghouse will store information regarding carrier demographics and transmittal records. This information will only be shared by participating jurisdictions, except for reports that will be generated and distributed by IFTA, Inc. The Clearinghouse will also provide readily available information on carriers.
The IFTA Clearinghouse provides a client/server approach using Dial-up communication access methods. The clients will be able to send their files to the Clearinghouse using the File Transfer Protocol (FTP). The upload process will consist of X12 EDI files created at the jurisdiction, then sent to the IFTA clearinghouse database. Jurisdictions will be responsible for updating the IFTA Clearinghouse database with registration and tax filing information on a timely basis. An Open Database Connectivity (ODBC) connection to the IFTA Clearinghouse database is provided to allow ad hoc query/reports capability. Text files based on in-house IFTA CH reports that can be imported into databases like MS Access may be downloaded as well.
Tax rate information is available to states from the IFTA, Inc. website.

## Credentials Administration Design Decisions:What’s reflected in the sample operational scenario...

- Credentials Administration Design Decisions:What’s reflected in the sample operational scenario...

- 1.	Do you use commercial systems for credentialing?  Which ones, and for what credentials?
- We use the Regional Processing Center (RPC) for IFTA.
- 2.	Do any of the earlier CVISN states use the same system(s)?  Does their design look as if it would fit your state? (Please see Appendix D of the CVISN Guide to Credentials Administration)
- Our system looks very much like State X’s, and we’re modeling our design after theirs.
- 3.	Do you plan to build a Credentialing Interface? Take another approach that doesn’t involve a CI?
- We will build a CI.  We’ll start by reviewing what State X does, and see what changes we need.

*Example Operational Scenario*

## Credentials Administration Design Decisions:What’s reflected in the sample operational scenario...

- 4.	 Will you provide a Web solution?
- Yes, we intend to integrate e-credentialing capabilities into our MVA Web site.
- 5.	Will you sponsor the development of a CAT or CAT module?  Do you know what your carriers want?
- We have established a CVISN steering committee that includes a mix of carriers.  Through the trucking associations, we conducted surveys. We are going to implement a Web solution first, as we believe it will handle 80% of our customers. Our smaller carriers think the Web site will satisfy their needs, while even the large carriers say they will use it for single transactions. Our large carriers would like a computer-to-computer interface for adding fleets. If we can afford it, we will work with one of our large carriers and their fleet management system developer to add an electronic credentialing capability to the FMS package.

*Example Operational Scenario*

## Credentials Administration Design Decisions:What’s reflected in the sample operational scenario...

- 6.	Will you modify all or some of your legacy credentials systems to support EDI?  Which ones?
- We are working with our vendors on this.  The IRP system is definitely being upgraded to handle EDI.  It does not look as though we’ll switch to EDI for IFTA, though.  We may need to develop a legacy system interface (LSI) for IFTA. We are also monitoring developments on XML and would be interested in participating with other states in a working group on using XML in CVO.

*Example Operational Scenario*

## Operational Scenario

- Accept and process electronic IRP credential applications for supplements (e.g., adding a vehicle to an existing account)
- Interact with the applicant electronically, via a Web Browser and Web Site
- Maintain snapshots for interstate operators by providing credential data for carriers and vehicles based in your state to SAFER
- Connect to the IRP Clearinghouse to support the IRP base state agreement

*Example Operational Scenario*

**Notes:**
For credentials-related scenarios, it is often convenient to think of the steps in the operational scenario in three subgroups.
On this and subsequent pages, the groups are highlighted with the colors shown:
Yellow steps support the interaction between the state and the applicant (steps 1-12 and 17-20),
Lavender cross-hatched steps correspond to the maintenance of snapshots (steps 13-16 and 21-24),
Blue steps involve the interaction between the state and the core infrastructure systems (in this case, IRP Clearinghouse) (steps A-D).
The slide show will skip to the thread diagram.  We will walk through the steps of the operational scenario [use overhead projector to show the list].
In the breakout session, you’ll develop operational scenario steps and a thread diagram for how you intend to automate this same IRP process.  
Keep the scenario steps at about the same level of detail as in this example.  Each step should “name” the information being exchanged and what format (e.g., EDI TS 286) will be used for the exchange.  Also describe, at a high level, the processing performed.

## Operational Scenario:IRP Supplement, Add VehicleWeb Site/Web browser configuration

- Operational Scenario:IRP Supplement, Add VehicleWeb Site/Web browser configuration

- 1. 	Carrier enters an IRP credential application via a Web browser to a state-based Web Site.
- 2.	The Web Site passes it to the Credentialing Interface (CI).
- 3.	The CI submits a query to its state database to perform preliminary checks as part of evaluating the application.
- 4.	The state database reports the status, i.e., flags and condition to the CI.
- 5.	If a satisfactory status is received, the application is sent to the IRP system for processing via EDI X12 TS 286.
- 6.	The IRP system processes the application and sends an invoice notice to the CI via EDI X12 TS 286.
- 7.	The CI sends the invoice notice to the Web Site and maintains archival/audit copies of all transactions.
- 8.	The carrier retrieves the invoice notice from the state Web Site using a Web Browser.
- 9.	The carrier reviews the invoice data and verifies that the application data matches the intent.  The carrier indicates payment method information via the Web Browser to the Web Site.

*Example Operational Scenario*

**Notes:**

Read through the steps, referring to the thread diagram.  

## Operational Scenario:IRP Supplement, Add Vehicle Web Site/Web browser configuration

- Operational Scenario:IRP Supplement, Add Vehicle Web Site/Web browser configuration

- 10.	The Web Site passes it to the Credentialing Interface (CI).
- 11.	If a Temporary Authority (TA) is requested, the CI releases it to the Web Site.
- 12.	The carrier prints the TA from the Web Site.
- 13.	If a TA was granted, the CI sends a vehicle snapshot segment update to CVIEW via EDI X12 285.
- 14.	CVIEW sends updated snapshot data to SAFER via EDI X12 TS 285.
- 15.	CVIEW sends updated snapshot data to  Roadside via EDI X12 TS 285.
- 16.	SAFER sends updated snapshot data to subscribers via EDI X12 TS 285.
- 17.	The CI verifies payment method information (financial system interfaces are not shown) and passes payment approval to the IRP system via EDI X12 TS 286.
- 18.	The IRP system validates payment amount and updates application status to indicate the permanent credential granted and notifies the CI via EDI X12 TS 286.
- 19.	The CI passes the permanent credential to the Web Site.
- 20.	The carrier prints the Cab Cards from the Web Site.

*Example Operational Scenario*

## Operational Scenario:IRP Supplement, Add Vehicle Web Site/Web browser configuration

- Operational Scenario:IRP Supplement, Add Vehicle Web Site/Web browser configuration

- 21.	The CI updates CVIEW with permanent credential information via EDI X12 TS 285.
- 22.	CVIEW sends updated snapshot data to SAFER via EDI X12 285.
- 23.	CVIEW sends updated snapshot data to Roadside via EDI X12 285.
- 24.	SAFER makes updated snapshot data available to subscribers via EDI X12 TS 285.
- A.	Daily, the IRP system sends updates to the IRP Clearinghouse on IRP registration information and fee payments (recaps).
- B.	Monthly, the IRP Clearinghouse makes available the fee information (pre-netting transmittals) to the participating jurisdictions for approval and/or correction. States review  the information interactively using terminals.
- C.	The IRP Office and also other participating jurisdictions report back to the IRP Clearinghouse the approvals or corrections. The approvals/corrections are made via terminals.

*Example Operational Scenario*

## Operational Scenario:IRP Supplement, Add VehicleWeb Site/Web browser configuration

- Operational Scenario:IRP Supplement, Add VehicleWeb Site/Web browser configuration

- D. 	The IRP Clearinghouse performs the actual netting and makes available corrected/approved vehicle and fee actions (post-netting transmittal) and netting results (remittance netting reports) to the participating jurisdictions. The information is reviewed via terminals.
*NOTE: Functional acknowledgment for all EDI messages (except TS 997) is made by responding with a TS 997.  Content errors in a received TS 286 are noted by also replying with a TS 286.  The results of processing an incoming TS 285 are reported via TS 824.  *

*Example Operational Scenario*

## Functional Thread Diagram:IRP Supplement, Add VehicleWeb Site/Web browser configuration

**Generic State Roadside Systems**

**Generic State Commercial Vehicle Administration Systems**

**Carrier Systems**

**Credentialing **
**System **
**(e.g., CAT)**

**CVISN **
**Core Infrastructure**
**Systems**
** ****(National/Regional)**

**CDLIS**

**IRP**
**Clearinghouse**

**IFTA**
**Clearinghouse**

**NMVTIS**

**MCMIS**

**SAFER**

**Compliance **
**Review **
**(e.g., CAPRI)**

**Service Providers**

**Internet Tools**
**(e.g. Browser)**

**Other Carrier**
**Systems**

**CV Info Exchange**
**Window (CVIEW)**

**Credentialing**
**Interface (CI)**

**Transponder**

**Carrier Commercial**
**Vehicle**

**Web Site**

**Licensing &**
**Insurance**

**E-Screening**
** ****Enrollment**

- Functional Thread Diagram:IRP Supplement, Add VehicleWeb Site/Web browser configuration

**Other Jurisdictions**

**IRP Office**

*Example Operational Scenario*

**Notes:**
Note: This slide builds.  First, the yellow numbers come up, next the lavender cross-hatched numbers, and then the blue numbers.

## Breakout Goals

- Set goals and objectives for credentials administration in your state
- Make initial design decisions related to credentials administration
- Illustrate the actions associated with IRP Supplement, Add Vehicle in your state using the operational scenario and functional thread diagram approach
- Make initial allocation of new functions to existing or new computers and networks

*Breakout*

## What inputs are needed?What outputs are created? 

- Input/Pre-work needed:
- COACH Part 1 checklists in 4.1, 4.3
- System Inventory
- IRP
- IFTA Registration
- IFTA Tax Filing
- Keys & IDs
- Electronic Interchanges in Use
- Outputs:
- Revised COACH checklists
- Goals & objectives
- Answers to some key design decisions
- Completed thread diagram
- Updated top-level physical design
- Updated action plan, decision list, issue list

*Breakout*

## Breakout Plan120 minutes

- Using your state’s CVISN system design template and network template, and follow the example just presented:
**Step 1. **~10 min.  Assign roles.**  **Review & update COACH Part 1 checklists 4.1, 4.3.
**Step 2.** ~20 min.  Briefly discuss how you perform credentials-related functions today.  Set the near-term goals and objectives for credentials administration in your state.  Record the goals & objectives on a flip chart.  If necessary for the discussion, pick the credentials you want to work on.
**Step 3.** ~30 min.  Referring to the CVISN Guide to Credentials Administration as needed, discuss design alternatives that support your goals and objectives (please see page 45).  Reach preliminary conclusions for as many questions as possible.  Record actions as needed to answer the questions.

*Breakout*

**Notes:**
The Breakout Plan slides build by bringing up each paragraph separately.
If the group clearly understood the instructions for the previous breakout or gets restless as you begin to go through these instructions, then go through the instructions very quickly, and skip showing the overheads.
There are several pages in this section that will be shown as overhead transparencies, instead of using computer projection.

For step 1, show the Team Roles (page 44).

For step 2, show the blank page for recording goals and objectives (page 45).

For step 3, show the list of Credentials Administration Design Decisions and the blank page for recording answers (page 46-47)

## Breakout Plan120 minutes

**Step 4**. ~30 min.  On a flipchart, tailor the list of scenario steps presented in this session for IRP Supplement, Add Vehicle in your state.
**Step 5.** ~10 min.  Start with a copy of your system design template.  Label it “IRP Supplement, Add Vehicle”.  Connect the boxes with directional lines to illustrate the information flow for the scenario.  Label the lines with the step numbers from the scenario.
**Step 6.** ~10 min.  Start with a copy of your network template.  Label it to match the scenario it will support.  Review the network template to see what new or enhanced processing power or connectivity is needed to support the interactions for your IRP scenario.  As needed, add computers or connections to the diagram.  If a new process is being added to an existing computer, list the software application in that computer’s box.  If you can, identify the communications protocol you will you use for each new connection.

*Breakout*

**Notes:**
Explain step 4

For step 5, show the Generic State Design Template (page 48)

For step 6, show the Generic Network Template (page 49)

## Breakout Plan120 minutes

**Step 7.** ~ 5 min.  Make sure you’ve noted all the open actions on your action plan and preliminary decisions on your decision table.  List the three most important credentials administration-related issues or questions that your state needs assistance with.
**Step 8**. ~ 5 min. Get ready to present your results to the main group.  A sample outline includes:
- Goals and objectives for Credentials Administration (step 2)
- Preliminary design decisions for Credentials Administration (step 3)
- IRP Supplement, Add Vehicle operational scenario and functional thread diagram (steps 4 and 5)
- Physical design diagram for IRP scenario (step 6)
- Actions, decisions, issues (step 7)

*Breakout*

**Notes:**

For step 7, remind them to continue building on the lists they’ve already started.  Show them the blank issues chart on page 50.

Explain step 8  

They should plan on about 10 minutes to present.

## Breakout Plan120 minutes

**Step 8**.  (continued)
- Assemble the material for the presentation:
- If you do it electronically, copy the file onto a floppy disk and take it with you to the main meeting room.
- Otherwise, make transparencies.
- If necessary, carry flip chart pages with you to the main meeting room for reference.
- If you have time, make a copy for each member of your team and for the master book.

*Breakout*

**Notes:**
Explain step 8

## As time permits, or after the workshop, finish the top-level design steps associated with Level 1 functionality. . .

- If you are implementing the complete set of CVISN Level 1 credentialing capabilities, then you should define each of these scenarios:
- Complete an operational scenario and functional thread diagram for accepting and processing **IRP renewal applications**
- a.	Web Site/Web browser configuration (person-to-computer)
- b.	CAT or FMS system configuration(computer-to-computer)
- Complete an operational scenario and functional thread diagram for accepting and processing **IFTA credential applications** for supplements
- a.	Web Site/Web browser configuration (person-to-computer)
- b.	CAT or FMS system configuration(computer-to-computer)
- Complete an operational scenario and functional thread diagram for accepting and processing **IFTA renewal applications**
- a.	Web Site/Web browser configuration (person-to-computer)
- b.	CAT or FMS system configuration(computer-to-computer)
- Complete an operational scenario and functional thread diagram for accepting and processing **IFTA quarterly tax returns**
- a.	Web Site/Web browser configuration (person-to-computer)
- b.	CAT or FMS system configuration(computer-to-computer)

*Breakout*

## Team Roles

- Facilitator		_________________________
- Presenter		_________________________
- Scribe		_________________________
- Time Keeper	_________________________
- CSA			_________________________
*Change the roles for each breakout session *
*(except facilitator and CSA)*

*Breakout*

## State Credentials Administration Goals & Objectives

*Breakout*

## Credentials Administration Design Decisions

- 1.	Do you use commercial systems for credentialing?  Which ones, and for what credentials?
- 2.	Do any of the earlier CVISN states use the same system?  Does their design look as if it would fit your state? (Please see Appendix D of the CVISN Guide to Credentials Administration)
- 3.	Do you plan to build a Credentialing Interface? Take another approach that doesn’t involve a CI?
- 4.	Will you provide a Web solution?
- 5.   Will you sponsor the development of a CAT or CAT module?  Do you know what your carriers want?
- 6.	Will you modify all or some of your legacy credentials systems to support EDI?  Which ones?

*Breakout*

## Credentials Administration Design Decisions

*Breakout*

## Generic State System Design Template

**Generic State Roadside Systems**

**Generic State Commercial Vehicle Administration Systems**

**Carrier Systems**

**Credentialing **
**System **
**(e.g., CAT)**

**CVISN **
**Core Infrastructure**
**Systems**
** ****(National/Regional)**

**CDLIS**

**IRP**
**Clearinghouse**

**IFTA**
**Clearinghouse**

**NMVTIS**

**MCMIS**

**SAFER**

**Compliance **
**Review **
**(e.g., CAPRI)**

**Service Providers**

**Internet Tools**
**(e.g. Browser)**

**Other Carrier**
**Systems**

**CV Info Exchange**
**Window (CVIEW)**

**Credentialing**
**Interface (CI)**

**Transponder**

**Carrier Commercial**
**Vehicle**

**Web Site**

**Licensing &**
**Insurance**

**E-Screening**
** ****Enrollment**

*Breakout*

**Use Your State’s Template**

## Generic Network Template

- Motor Vehicle Administration

- State Highway Administration

- CVISN Core
- Infrastructure Systems

- Motor Fuel Tax Agency

- State Police (MCSAP Agency)

- Inspections
- (ASPEN)

- IRP

- Carrier Systems

- SAFER

- MCMIS

- IRP
- Clearinghouse

- IFTA
- Clearinghouse

- Credentialing
- System

- Carrier
- Registration &
- Permitting

- Treasury:
- Mainframe DB

- IFTA Registration
- & IFTA Tax
- Processing

- SAFETYNET

- Licensing
- & Titling

- Intrastate
- Registration

- AAMVAnet
- Frame Relay
- (TCP/IP)

- AAMVAnet
- SNA

- Gateway
- (token
- ring)

- sensors

- CDLIS

- Licensing &
- Insurance

- Web Site

- Firewalls

- Gateway

- Credentialing Interface,
- All MVA LSIs,
- E-Screening Enrollment

- CVIEW

- Dedicated dial-up

- Dial-up

- Existing
- Proposed

- dial-up

- dial-up

- TCP/IP

- Ethernet Backbone

- SNA

- Ethernet Backbone

- SNA

- Ethernet Backbone

- Firewall

- Firewall

- Internet

- Internet Tools

- RF
- Link

- Roadside
- Operations

- Sensor/
- Driver Comm

- Screening

- Repeater

- AAMVAnet
- CSN
- (TCP/IP)

- Firewall

- CAPRI

*Breakout*

**Use Your State’s Template**

## Credentials Administration Issues/Questions

*Breakout*

## Background Material

## What is EDI?

- Electronic Data Interchange (EDI) is the electronic exchange of business information in a format that permits computer generation and processing of the message
- Reduces or eliminates paper transactions
- Allows automated processing & storing of data
- EDI standards and user implementation guides define the structure and meaning of messages passed between trading partners.
- American National Standards Institute (ANSI) provides an infrastructure for defining & maintaining open EDI standards.
- Each ANSI standard defines structure for a message serving a defined purpose.  (There are currently about 250 such standards.)
- A common implementation is to couple existing systems to an EDI translator software package & commercial network.

*Conforming with the CVISN Architecture*

## EDI Transmissions Consist of Nested Control and Transaction Segment Information 

**Communications Transport Protocol**

**Functional Group Header**

**Detail Segments**

**Detail Segments**

**Detail Segments**

**Functional Group Trailer**

**Functional Group Header**

**Functional Group Trailer**

**FUNCTIONAL GROUP**

**FUNCTIONAL GROUP**

**COMMUNICATIONS SESSION**

**ISA**

**GS**

**ST**

**ST**

**ST**

**SE**

**SE**

**GE**

**GS**

**SE**

**GE**

**IEA**

**Transaction Set Trailer**

**Transaction Set Trailer**

**Interchange Control Trailer**

**Communications Transport Protocol**

**EDI Transmissions Consist of Nested Control and Transaction Segment Information **

- _Source_:  *EDI X12 Standards*, Version 3 Release 6,
-                published December 1995.

*Conforming with the CVISN Architecture*

**Notes:**
Point out communication protocols/nested convention.
Most of the information is in the Detailed Segments.

## Actual EDI Transmission(Control and Transaction Segments Highlighted)

- ~**GS***KM*LMIMSCVISN*MDCVISN*19990505*1149*37*X*004010
- ~**ST***286*1
- ~**BGN***11*00000000000037*19990505*114901*PT*APP:2167~**NM1***41*2*LockheedMartinIMS~**N3***40N.CentralAve.~**N3***Suite2250~**N4***Phoenix*AZ*85004*US~**PER***IC*GeraldHonma*TE*6024136013*FX*602254451~**SPI***90******06*IV~**HL***1**AP*1~**LM***FH~**LQ***T14*201~**N9***IRP*0000012865~**N9***CF*001~**N9***ACF*047~**N9***I5*980000260~**DTM***ABA****CY*1998~**DTM***003*19990504~**NM1***UX*2******SJ*MD~**HL***2*1*35*0~**LM***FH~**LQ***T03*21~**NM1***1B*2*MDCVISNTESTCOMPANY~**N3***123MAINST~**N4***MAINVILLE*MD*13245*USA~**NM1***31*2*MDCVISNTESTCOMPANY~**N3***123MAINST~**N4***MAINVILLE*MD*13245*USA~**HL***3*1*R*1~**LM***FH~**LQ***T14*502~**N9***6P*00020~**YNQ****Y******T14*W2~**NM1***JU*2******SJ*DC~**MEA***WT*S******44~**YNQ****Y******T14*530~**NM1***JU*2******SJ*GA~**MEA***WT*S******44~**YNQ****Y******T14*530~**NM1***JU*2******SJ*MD~**MEA***WT*S******44~**YNQ****Y******T14*530~**NM1***JU*2******SJ*VA~**MEA***WT*S******44~**YNQ****Y******T14*530~**HL***4*3*E*0~**LM***FH~**LQ***T20*BS~**N9***SUB*TESTBUS~**DTM***318*19990426~**MEA***WT*EW*15000*LB~**MEA***WT*G*45000*LB~**QTY***HL*45~**YNQ****Y******T08*3~**YNQ****N******T11*150~**YNQ****N******T17*600~**YNQ****Y******T14*522~**VEH****BUSVIN*1997*NA*INTL****BUS****6600000*N~**DVI***PUR*66000**D8*19990402****MD*CY*1998~**N12***D*ZZ~**NM1***OY*1*CVISNCAT/CITEST~**HL***5*1*PY*0~**LM***FH~**LQ***T11*375~**AMT***BAP*31.93~**AMT***PD*0~**AMT***BD*31.93~**NM1***JU*2******SJ*DC~**QTY***M1*0.06667*P1~**LQ***T11*375~**AMT***BAP*37.5~**AMT***PD*0~**AMT***BD*37.5~**NM1***JU*2******SJ*GA~**QTY***M1*0.06667*P1~**LQ***T11*375~**AMT***BAP*500~**AMT***PD*0~**AMT***BD*500~**NM1***JU*2******SJ*MD~**QTY***M1*0.8*P1~**LQ***T11*375~**AMT***BAP*4.2~**AMT***PD*0~**AMT***BD*4.2~**NM1***JU*2******SJ*VA~**QTY***M1*0.06667*P1~**HL***6*1*R*1~**LM***FH~**LQ***T14*502~**N9***6P*00001~**YNQ****Y******T14*W3~**NM1***JU*2******SJ*MD~**MEA***WT*S******44~**YNQ****Y******T14*530~**HL***7*6*E*0~**LM***FH~**LQ***T20*ST~**N9***SUB*TESTTRL~**DTM***318*19990426~**MEA***WT*EW*8000*LB~**MEA***WT*G*18000*LB~**QTY***R5*2~**YNQ****Y******T08*3~**YNQ****N******T11*150~**YNQ****N******T17*600~**YNQ****Y******T14*522~**VEH****TRAILER*1996*NA*FRUE****TRAILER****2500000*N~**DVI***PUR*25000**D8*19990403****MD*CY*1998~**NM1***OY*1*CVISNCAT/CITESTAC~**HL***8*1*PY*0~**LM***FH~**LQ***T11*375~**AMT***BAP*20.25~**AMT***PD*0~**AMT***BD*20.25~**NM1***JU*2******SJ*MD~**QTY***M1*1*P1~**HL***9*1*R*1~**LM***FH~**LQ***T14*502~**N9***6P*00080~**YNQ****Y******T14*W1~**NM1***JU*2******SJ*DC~**MEA***WT*S*80000*LB~**YNQ****Y******T14*530~**NM1***JU*2******SJ*GA~**MEA***WT*S*80000*LB~**YNQ****Y******T14*530~**NM1***JU*2******SJ*MD~**MEA***WT*S*80000*LB~**YNQ****Y******T14*530~**NM1***JU*2******SJ*VA~**MEA***WT*S*80000*LB~**YNQ****Y******T14*530~**HL***10*9*E*0~**LM***FH~**LQ***T20*TK~**N9***SUB*TESTTR1~**DTM***318*19990426~**MEA***WT*EW*15000*LB~**MEA***WT*G*80000*LB~**QTY***R5*3~**YNQ****Y******T08*3~**YNQ****N******T11*150~**YNQ****Y******T17*600~**YNQ****Y******T14*522~**VEH****TR45*1998*NA*INTL****TR45****12500000*N~**DVI***PUR*125000**D8*19990401****MD*CY*1998~**N12***D*ZZ~**NM1***OY*1*CVISNCAT/CITESTAC~**HL***11*1*PY*0~**LM***FH~**LQ***T11*375~**AMT***BAP*31.93~**AMT***PD*0~**AMT***BD*31.93~**NM1***JU*2******SJ*DC~**QTY***M1*0.06667*P1~**LQ***T11*375~**AMT***BAP*48.34~**AMT***PD*0~**AMT***BD*48.34~**NM1***JU*2******SJ*GA~**QTY***M1*0.06667*P1~**LQ***T11*375~**AMT***BAP*752~**AMT***PD*0~**AMT***BD*752~**NM1***JU*2******SJ*MD~**QTY***M1*0.8*P1~**LQ***T11*375~**AMT***BAP*87.87~**AMT***PD*0~**AMT***BD*87.87~**NM1***JU*2******SJ*VA~**QTY***M1*0.06667*P1~**HL***12*1*FL*0~**LM***FH~**LQ***T09*AP~**QTY***TO*12*MO~**LQ***T20*PW~**QTY***TO*1~**LQ***T20*BS~**QTY***TO*1~**LQ***T20*TR~**QTY***TO*1~**HL***13*1*PY*0~**LM***FH~**LQ***T14*700~**AMT***YF*241.77~**AMT***AD*1530.02~**AMT***FO*0~**AMT***PD*0~**AMT***BM*0~**AMT***BD*1530.02~**LQ***T11*375~**AMT***FE*63.86~**NM1***JU*2******SJ*DC~**QTY***MI*0.06667*P1~**LQ***T11*375~**AMT***FE*85.84~**NM1***JU*2******SJ*GA~**QTY***MI*0.06667*P1~**LQ***T11*375~**AMT***FE*1272.25~**AMT***BAP*1272.25~**NM1***UX*2******SJ*MD~**QTY***MI*0.8*P1~**LQ***T11*375~**AMT***FE*92.07~**NM1***JU*2******SJ*VA~**QTY***MI*0.06667*P1~**LQ***T14*733~**AMT***FE*16~**NM1***UX*2******SJ*MD
- ~**SE***216*1
- ~**GE***1*37
- ~**IEA***1*000000040~

*Conforming with the CVISN Architecture*

- Actual EDI Transmission(Control and Transaction Segments Highlighted)

- EDI messages
- are text files.

**Notes:**
Headers are color-coded from previous diagram.
Segment types are in bold; Segments are separated by a tilde (~).
Each segment type has its own field format, convention.
Elements within each segment are separated by asterisks (*).

## Electronic Data Interchange (EDI)

**Communication**
**Network**
**(e.g., the Internet)**

**Motor Carrier Applications**

**Application Database**

**Custom Data Extract/Insert**

**Commercial EDI Translator**

**MOTOR CARRIER**

**State Applications**

**Application Database**

**Custom Data Extract/Insert**

**Commercial EDI Translator**

**STATE**

**EDI**

**EDI**

**Open ANSI X12 EDI Standards and Implementation Guides allow motor carriers, states, and other trading partners to exchange safety and credentialing information.**
**An EDI interface can be added to existing systems through some custom coding and a commercial-off-the-shelf EDI translator.**

*Conforming with the CVISN Architecture*

## What is XML?

- XML is a metalanguage for creating a customized mark-up language to describe the **structure and content of documents**.  An outgrowth of document publishing and display technologies, XML is becoming popular in WWW applications.  It is a method, not a standard, for data interchange.
- The World Wide Web Consortium (W3C) and OASIS are two of the key organizations involved in developing XML standards.
- Standards organizations and industry experts are working to combine the rich data semantics from 20 years of EDI history with the emerging XML technology for data and document exchange.
- XML is a potential alternative approach for CVO information exchange, but there are no guidelines at this time for the use of XML in the domain of commercial vehicle operations, and no equivalent aids to users as the implementation guides for EDI.

*Conforming with the CVISN Architecture*

## Example of XML

*Conforming with the CVISN Architecture*

- XML messages
- are text files.

## Credentials Administration:  Various approaches enable different 

**LSIs**

**Credentialing**
**Interface (CI)**

***Standardized EDI or Web transactions enable: ***
***	******carriers to file for credentials from their offices,***
***	******states to process applications automatically,***
***	******states to exchange information electronically to support base state agreements***
***	******states exchange interstate credentials with other***
***	******states via SAFER***
*** ******Standardized transactions support:***
***	******fee payments among payers, payees, and financial institutions (banks).******	***

- Credentials Administration:  Various approaches enable different
- carriers to obtain credentials and enable states to process
-  the applications and support base state agreements electronically.

**Motor Carrier**

**IFTA and IRP Clearinghouses**
**(Support base state agreements)**

**Credentialing System (e.g., CAT -  Carrier **
**Automated Transaction, or CAT module)**

**State**

**EDI**

**EDI for IFTA CH**

**EDI**

- EDI: Electronic Data Interchange    LM:  Legacy Modification
- LSI:  Legacy System Interface

**Carrier Bank**

**IRP CH Bank**

**State Bank**

**Legacy Systems**
**Associated with Credential or Fuel Tax Filing**

- 1

- 3

- 5

- 5

**LMs**

- 2

**EDI**

**CI / Legacy **
**Workstations**

**(For manual review or entry of credential / tax filing info)**

- or

- or

- 1

- 2

- 3

- 4

- 5

- 5

**CVIEW**

**Web Site**

- 1

**Web Browser**

- 5

**SAFER**

**Other**
**States**

- 4

- 4

**EDI**

*Credentials Administration *

## Modifications enhance legacy systems to make better use 

**IFTA Clearinghouse**

- Modifications enhance legacy systems to make better use
- of available information and to improve operations.

**Credentialing**
**Interface**
** ****(CI)**

**Service Provider**

**CAT (other vendor)**

**149, 150, 151, 286, 997 **

**IRP Clearinghouse**
**Clearinghouses**

**State**
**CVIEW**

**285, 824, 997**

**CAT**
**Carrier**
**Automated**
**Transaction**

**286, **
**826, 997 **

**149, 150, 151, 286, 997**

**SQL or ODBC**

**1**

**2**

**     **

**OS/OW Permit**

**     **

**Intra-State Veh **
**Registration**

**     **

**     ****Legacy**
**     ****Systems**

**Legacy Mods (LM)**

**IRP Registration**

***	******Legacy systems in the state may require modification (LM) to support standardized information exchange, electronic credentialing, improved safety assurance programs, etc.***
***	******New application plug-ins, legacy system interfaces (LSIs), will be added only if EDI is impractical for data exchange between systems within the state***

**1**

**2**

**or**

**OS/OW**

**Intra-State Veh Reg**

**IFTA Registration**

**or**

**IRP Reg**

**IFTA Reg**
**LSI**

**150, 286, 813, 997 **

**150, 286, 813, 997**

*State, Carrier & CVISN Core Infrastructure Credentials Administration Systems*

## The Credentialing Interface provides a convenient interface within the state to accept electronic credentialing application inputs from carriers, and to provide responses from state systems to carriers.

*The Credentialing Interface:*
*	**Uses EDI ASC X12 standards for external interfaces,*
*	**Does preliminary syntax checks on received transactions,*
*	**Routes applications to the appropriate state credentialing system,*
*	**Routes responses to the carrier.*

**Credentialing  Interface (CI)**

**Carrier Automated Transaction **

- Service Provider

** **
**                           **
**CAT**

** ****User**
** ****Input**

**1**

**2**

**3**

**4**

**1**

**2**

**3**

**4**

**4**

**150, 286, 813**

**149,**** ****150, 151, 286**

**Legacy System**

- Leg Sys Mod

**286, 813 **

- or

- or

**149, 150,**** ****151, 286 **

**1**

**1**

*A state may choose to extend the CI to perform other functions (e.g., snapshot updates) that are allocated to other systems in the generic design.*

- Note:  all EDI messages acknowledged
-            with a 997.

*State, Carrier & CVISN Core Infrastructure Credentials Administration Systems*

## As the state “Web-enables” its credentialing processes, it can re-use the core Credentialing Interface and legacy systems.

- Credentialing
- Web
- Site

- Web
- Files

- Data
- Base

- Carrier

- DMV
- Database

- Browser

- Core
- Credentialing
- Interface

- CI User
- Interface
- Client

- State
- CVIEW

- State Systems

- IRP

- Stand-Alone
- CAT

**Firewall 2**

**Firewall 1**

- IFTA
- Registration

- IFTA Tax
-  Processing

**Legend**:
- solid blue arrows indicate
- access through firewall

*Credentials Administration Systems*

**Notes:**
This illustrates one possible design, and shows the firewalls.

## Keep the same “back end” processes, regardless of the external interfaces for credentialing

- State Systems

- Web & XML-
- Enabled
- Credentialing
- Interface

- IRP

- Stand-Alone
- CAT

**Database**

- IFTA
- Reg

- IFTA
- Tax
- Filing

- CVIEW

**Terminal**
**Server**

- Terminal
- Client

**EDI I/F**

**XML I/F**

- Fleet Management System

**Core CI**

**C**
**A**
**T**

- Browser

**Credentialing **
**Web Site**

**Web Database**

*Credentials Administration Systems*

**Notes:**
In this figure, the focus is on credentialing interfaces.
There are at least three choices for interfaces: EDI or XML file exchanges, or an interactive Web interface.
The first choice shown is the stand-alone CAT.  The CAT exchanges information with the state’s Credentialing Interface.  The carrier (or service provider) owns or leases the CAT product, and data are stored on the carrier’s (or service provider’s) system.
The second approach is for the carrier to access electronic credentialing services through a Terminal Client.  In this approach, the CAT is owned or leased by whoever owns the Terminal Server (the state or a service provider).
Both CAT-based approaches use EDI.
The third approach is a Web site solution.  The carrier uses his browser to access the state’s Web site for electronic credentialing.  A combination of HTML, XML, dynamic HTML, and/or XHTML may be used.
The fourth approach shown is for the carrier to use a fleet management system that has built-in electronic credentialing support.  The interface could be either XML or EDI.
Regardless of the interface used to interact with the carrier, the processing of the carrier-provided inputs should be the same in the CI and the legacy credentialing systems.

## The IRP Clearinghouse processes information received electronically from states to compute fees due/owed each jurisdiction, and facilitates periodic funds transfers.   

***	******Accepts RECAPS input from jurisdictions,***
***	******Computes balance due/owed to/from each jurisdiction,***
***	******Facilitates monthly funds transfer, EFT supporting ******	***

**1**

**2**

**3**

**2**

**2**

- based on information provided by IRP, Inc.

**List RECAPS available (Pre-Netting Notification);**
**Summarize vehicle & fee info from RECAPS and list balance due/owed each jurisdiction (Post-Netting)**

- STATE B
- Bank

- STATE A
- Bank

**Funds Transfer**

**IRP Clearinghouse**

**Funds Transfer**

**Send detailed data (RECAP) from paid-for IRP applications**

**Help Desk**

**STATE A **
**IRP System**

**STATE B **
**IRP System**

**1**

**3**

- The IRP Clearinghouse processes information received electronically from states to compute fees due/owed each jurisdiction, and facilitates periodic funds transfers.

**IRP Bank**

*CVISN Core Infrastructure*

## The IFTA Clearinghouse Central repository provides access to confidential tax information for IFTA, Inc clients.

*CVISN Core Infrastructure*

**IFTA Clearinghouse**
**Central Repository**

**VISTA**
**Jurisdiction**

**RPC**
**Jurisdiction**

**Single**
**Jurisdiction System**

**Daily Update**
** ****via X12 286 and 826,  **
**Query/Response**

**Daily Update**
**via X12 286 and 826**

**Query/Response, Extract of demographic information (286) and transmittals (826)**

***Responds to standard & ad hoc queries***
***Transmittal data entry screens***
***Tax Matrix & Reference Table maintenance***
***Accepts data (demographic & transmittal) submitted by clients (EDI)***
***Provides standard reports***

- based on information provided by RSIS

**Notes:**
RPC is Regional Processing System

## The IFTA Clearinghouse Web Site will provide public access to non-confidential tax information.

**IFTA Clearinghouse**
**Web Site**

**Public**
**User**

***IFTA information***
***IFTA manuals***
***Tax Rate Matrices***
***IFTA news & calendar of events***
***IFTA related sites & e-mail***
***Search capability***

**IFTA, Inc**
**Client User**

- based on information provided by RSIS

*CVISN Core Infrastructure*

## This Page Intentionally Blank