WO2002067175A2 - Extended web enabled multi-featured business to business computer system for rental vehicle services - Google Patents

Abstract

An Internet enabled, business-to-business computerized transaction system is disclosed in its preferred embodiment for use in providing rental car services for high volume users and comprises an Internet web portal through which the high volume user may access a plurality of service providers including an integrated business computer network for at least one rental vehicle service provider. The rental vehicle services provider computer network is configured to interconnect a geographically diverse plurality of branch offices, cataloguing their available rental vehicles and schedules for same as well as handling all transactional data relating to its business. The Internet web portal provides ubiquitous connectivity and portability for a multi-level business organization who regularly places high volumes of rental purchases with its business partner and also those other service providers who may or may not have the same integrated business computer systyem and software. Utilizing the method and apparatus of the present invention large volumes of rental transactions may be placed, monitored, altered during performance, and closed out with financial accounting and payment being made virtually without human intervention.

Description

Extended Web Enabled Multi-Featured Business To Business Computer System For Rental Vehicle Services

Cross Reference to Related Application

This application is a continuation-in-part of Serial No. 09/694,050 filed October 20, 2000, which is a continuation-in- part of Serial No. 09/641,820, filed August 18, 2000.

Introduction

The invention disclosed and claimed in the first filed parent cross referenced above relates generally to the field of an Internet enabled business-to-business intelligent communication link allowing a first business organization to have intelligent interaction witøi'-a second fully integrated business organization to facilitate the placing of orders or reservations for business services or goods, with the services or goods provider having a computer network linking multiple levels of its organization to provide for the smooth conduct of business between the two organizations. More particularly, this field relates to an Internet enabled automatic rental vehicle transaction system to facilitate the conduct of rental vehicle transactions between two multilevel business organizations, one of which provides such rental vehicle transaction services in an integrated manner through business enterprise software to a high volume user of such rental vehicle services wherein an Internet web portal is defined by the rental vehicle service provider which interconnects the two business organizations at multiple levels, providing a graphical user interface (GUI) for the transaction of large amounts of rental vehicle services automatically and virtually without human intervention upon entry. The invention of the second filed parent continuation-in-part application extends the functionality of the first filed parent invention by providing an intelligent portal that is readily configurable to suit any particular customer and any particular provider data requirements or method of doing business. This added functionality allows the invention, for example, to provide the user with access to other suppliers in the same seamless and integrated manner. In other words, the user now has access to not just one integrated business but multiple businesses, some of which may but need not be, integrated businesses thereby extending the invention for use in a generic application to satisfy a user's needs for a good or service not just from one vendor but all vendors connected to the invention. The inventions disclosed in this application add to the functionality of the systems first disclosed in the two parent applications by providing features and advantages which increases its flexibility and adaptability to other business models as might be found in different countries for handling rental vehicle transactions .

Background of the Invention

Computer technology has been embraced by many businesses in order to handle their ever increasing order flow as well as to mitigate the increasing blizzard of paper required to be produced to document this business. A significant benefit which often drives the implementation of technology is its further advantage in increasing productivity to thereby allow fewer people to handle greater volumes of business. One such good example demonstrating the efficiencies and value to be gained by implementing technology is the business model developed and followed by the assignee of the present invention. A rental car company at its heart, the assignee transacts an ever increasing number of time sensitive, relatively low dollar volume, vehicle rentals which in many instances require authorizations to be made in advance, reservations of vehicles from available geographic and vehicle type selections, monitoring of the rental as it progresses including possibly extending the rental under certain circumstances, communications between the various parties involved in the transaction to ensure ultimate customer satisfaction, and financial accounting for the transaction including generating invoices and processing them for payment. While a significant portion of the vehicle rental business involves rental for leisure, business travel, etc., another significant business relationship has developed with insurance companies and the like in what has been termed as the replacement car rental service business. In this business, a vehicle insurance company may have many thousands of policyholders who are eligible to be involved in accidents, and other dislocations of use, requiring that a vehicle be rented for that customer' s use while his own vehicle be made ready again for use. Thus, for this business segment, a multi-tiered business organization such as a vehicle insurance company represents a significant customer for repetitive vehicle rental services. To conduct this business in an orderly, time efficient and cost efficient manner, it is necessary that this insurance company has as its business partner a vehicle rental company which is itself multi-tiered, such as the assignee of the present invention. This is because the needs, both geographically and in volume, are significant which require the dedication of a significant amount of resources. To satisfy these needs and to respond to other business growth, in its embrace of technology the assignee hereof has succeeded in developing an in-house computer system and related software which has integrated its business internally. This business integration has been massive and company-wide as is needed to integrate a company having a central office with literally thousands of individual branches located nationally, and even now internationally, with hundreds of thousands of vehicles available for rental. Furthermore, other business partners including other service providers such as vehicle repair shops have also been given access to this system to allow for input of information relating to progress of vehicle repair, extension of rental time, etc. as the rental progresses. This integrated business computer network and software generally includes a mainframe server at the heart of a wide area network (WAN) which facilitates the transfer of vehicle rental information and orders company-wide. This integrated business model is most efficient and needed in order to satisfy the vehicle rental service needs of a vehicle insurance company which itself may be national or even international in scope.

As a first step in extending the integration of technology into this business model, the present assignee has previously developed and implemented a computer system which has provided improved communication capabilities between the two business partners. This system generally comprised a second mainframe computer linked to the first mainframe of the integrated business network, with dedicated access lines being provided from this second mainframe to various levels of the multilevel business organization comprising the insurance company. In effect, with this additional mainframe and dedicated pipeline access, various individuals at the insurance company were permitted to directly interact with the integrated business computer network of the vehicle rental company as well as other selected service providers such as body shops where wrecked vehicles were being repaired. The implementation of this system provided a great step forward over the people intensive business activity previously required in order to handle the large number of transactions encountered in this business relationship. Historically, the replacement car market engendered large numbers of telephone calls being placed between the insurance company, the rental company, and the body shop where vehicle repair was being performed in order to authorize the rental, select and secure the desired replacement vehicle to be provided, monitor the progress of the repair work so that scheduling of the rental vehicle could be controlled, extending the vehicle rental in the event of delays in repair, authorizing various activities involved in the rental process including upgrades of vehicles or other charges for services, and subsequent billing of the rental service and processing the billing to the insurance company for payment . While the implementation of this system was successful and represented a tremendous step forward in automating the business relationship between the insurance company and the vehicle rental company, it did have certain limitations . For example, a specific communication link had to be established between the rental vehicle company and the particular users at the insurance company designated to have access to this system. Thus, special attention and some modicum of expense was required to establish these "pipelines" and maintain them. Still another aspect to the system implemented was that it was not "browser" based nor did it provide graphical user interface (GUI) menus. Thus, each user had to be specifically trained in the particular "language" used by the system and learn to work with specific menus nested in a specific manner as well as codes for entering commands which were not similar to other computer software programs. This software design thus necessarily required additional training in order to insure that users could gain the full measure of advantage provided by the system and in order to minimize the opportunity for erroneous information or incorrect reservations from being entered or otherwise confusing the business transactions. Furthermore, user efficiency was not immediate and required skill beyond that ordinarily found in casual computer users, as we are all becoming in this computer age. Still another disadvantage to the system was that access was required to a designated entry point in the system in order for a person authorized to be on the system to work with it. As the nature of the insurance and replacement car business requires extreme mobility at multiple levels of both business partners, this represents a limitation to the usefulness and time efficiency with which various business functions could be performed. Therefore, while implementation of the second mainframe allowing for pipeline connections at various levels of the multi-tiered insurance company was a significant step forward in automating the business relationship between the two business partners, significant limitations to this solution were readily apparent to the users thereof.

Summary of the Invention In the first parent application cross-referenced above, the inventors herein have previously succeeded in designing and developing a means for substantially enhancing the business to business communication link between these two businesses which provide significant advantages over its prior embodiment. More particularly, the inventors have succeeded in replacing the dedicated pipeline access of the existing system with a web portal allowing Internet access to the mainframe with a browser based graphical user interface (GUI) presentation. This also made the system more readily accessible to smaller business partners as the expense of the "pipeline" was eliminated. The first parent's invention offers several important technical advantages over the previous system. First of all, by taking advantage of the ubiquitous nature of the Internet, the ultimate in portability and connectivity for this system is now provided in a business environment where mobility and connectivity are at a premium. In other words, a claims adjuster, body shop, or any other business employee authorized to have access to the system may gain access at any site offering Internet access. In present day technology that includes many mobile devices and appliances which are Internet enabled. As technology advances, it is conceivable that this access will extend to permit "24/7" access by any authorized person at any geographic location. This is a marked improvement providing immediate benefit and advantage over the dedicated pipeline access of the prior art system.

One limitation however, is that with this embodiment, this internet access must support a stateful connection. In this context, a stateful connection refers to a "persistent" conversation, meaning that the client side and server side software components establish a connection to one anther once and multiple data transfers may occur without severing that connection. Common examples of a stateful connection include on-line chat, on-line gaming, and for virtually all on-line conferencing. This is distinguishable from the normal operation of web pages which typically establish a connection, transfer the object on the page, and then sever that connection. These types of connections are generally referred to as "stateless" connections. A second major advantage of the first parent's invention is its graphical user interface. The inventors have taken full advantage of this browser based GUI to streamline and organize the presentation of information to a user to actually guide him as he interacts in doing his business. One such example is customized design of the menus such that the user is guided and directed to answer only those questions required to be answered in order to conduct the particular transaction being addressed, and further to present choices to the user for his selection to minimize the need for the user to rely on his own memory or to be familiar with complicated and specialized codes to enter data or request transaction activity. With the recent and continuing explosion of the Internet, more people are becoming familiar with browser programs and their operation through their own daily activities in their personal lives. This familiarity paves the way for easier training and quicker orientation of a new user to the present invention. For large business organizations communicating at multiple levels, this significant advantage cannot be minimized as there are large numbers of people who must be continuously trained due to the growth of the organizations, as well as the replacement of employees due to the inevitable attrition. Thus, the first parent's invention provides an immediate increase in worker productivity, and makes that improved efficiency available to many more workers who are not particularly skilled otherwise in computer usage.

Still another advantage provided by the first parent's invention is through the implementation of additional functionalities which are engendered by the browser/GUI interface. As the system is continuously used, and feedback is continuously monitored and analyzed, additional features that add value through providing management information as well as by speeding transaction activity over the system may be implemented. For example, several of these features include the ability of a user to create an on demand report for transaction activity including summaries of transactions handled by a particular user or group of users which might either be open or closed. Another example of additional functionality which improves the efficiency of a user is the ability to create a repair facility call back list which allows a user to sort existing open vehicle rental reservations by repair facility (body shop) and date such that a user is presented with the list of open reservations at a particular repair facility which can be readily handled in a single telephone call while at the same time having the system on line to implement any needed changes such as extensions of reservations, etc. Additional functionality has also been provided to speed the processing of invoicing which of course also speeds their payment and cash receipts. For example, it was found that even despite the built-in error checking and correction facilities provided to the users of the system, a repetitive pattern of mistakes involving incorrect claim numbers was discovered. To speed the processing of these, an additional functionality was provided as an "electronic audit" known as invoice return which returns an invoice to a particular adjuster upon detection of an incorrect claim number for his human intervention and correction of the claim number. In this manner, problem invoices exhibiting one of the most common problems encountered may be readily handled within the system and in an efficient manner, instead of manually as before.

The first parent's invention also has as a significant advantage the ability to be further customized to meet the individual business partners' needs and desires as well as to provide additional functionality by offering additional features which become desirable upon accumulation of user data based on user experience. Furthermore, once implemented, they are immediately available system wide. While this allows for consistent usage, it is limited in the sense that all of the system users are forced to use the same menus, data definitions, etc. This is not seen as a limitation for the one-to-one business application intended to be primarily addressed by the first parent's invention.

Still another advantage of the first parent's invention is that the graphical user interface incorporates point and click interaction, using buttons and tabs to present or conceal data for the user' s attention or inattention as the case may be, and provide a much more robust interaction capability through the creation of menu designs that allow for access to the most commonly needed features from any point in the menu architecture. This is to be contrasted with the prior system which consisted of a main frame character based interface while the first parent's invention with its GUI interface allows a user to point and click to navigate and to make selections by pull down selection, thereby reducing errors. As users become more experienced with the system, and their confidence level grows, they are much more likely to become bored and aggravated with the rigid structure of the prior system requiring them to follow along a certain menu architecture in order to complete certain tasks. On the other hand, the first parent's invention generally increases the interest of the user in using the system. These advantages of the first parent's invention over the prior interface promote employee productivity by allowing a user more control over his work which is critical in achieving savings in human resources to operate the system which is one of its main goals.

The second parent's invention extends the first parent's invention and expands its capabilities and functionalities. With the second parent's invention, a user may not only have access to its business partner, but also one or more competitors of its business partner through the same Internet portal. In this way, at least two needs are satisfied. First, the user can have access to a variety of providers to choose from where business needs or desires require. This allows the user to use a single portal and not have to sign on to a number of different portals, even should they be available. Furthermore, the user isn't troubled to learn how to access and use different portals even should they be available. Presently, not all providers are operating an Internet portal for offering their services, so by allowing business competitors to be accessible through the same portal, independent development of other portals is forestalled. This is a benefit to the operator of the main portal as it creates and maintains a competitive advantage by handling all of the order flow which creates a data base of useful information for marketing purposes. Although initially the portal services might be offered for no additional cost to a competitor, eventually a fee might be charged which would at least partially offset the cost for owning and operating the portal. The design of the portal is elegant and offers great flexibility for customizing not only the menus for presentation to the user, but also in the design of the data base entries needed or desired by the user and/or the competitive provider. For example, some users might not know or care about the features of a vehicle rented and so those data entries may not be provided space on the menu for the user to fill in. The data base as handled by the networked computer system then need not keep track of that data for that customer. This feature is readily accommodated by the data base programming and is conveniently implemented.

In still another aspect of the second parent's invention, the web portal has the capability to accommodate the varying data requirements also of the various competitive providers, but also the level of their sophistication as evidenced in their respective computer systems and interface facilities. For example, the web portal may be configured to communicate the user's order to the competitive provider via email, phone, or even through a connection directly to an integrated computer system having the same or substantially the same inter-operability as the integrated computer system of the assignee hereof. This capability extends to accommodating and matching the competing data requirements of the user and the competitive providers, and having the flexibility to design and implement menus that readily meet these competing needs . Furthermore, the second parent's invention allows for changes to be implemented by simple re-programming of the web portal which minimizes the effort and enhances the "user friendly" aspect to the present invention.

Not only are these "global" improvements made available with the second parent's invention, there are other more particularized improvements that add functionality within the operating framework of the second parent's invention. For example, one such improvement is the ability to "virtually" assign work groups within the user so that, for example, multiple adjusters might be made into a team with a shared work load so that all of the team members have access to the same pool of work, such as the placing of reservations for the same group of drivers. With this "virtual team" assignment capability, work groups may be readily re-assigned to match changing work loads without worrying about re-configuring hardware or internal network connections. This can be a very valuable feature to accommodate staffing issues over geographical distances that can be nationwide, with access through the web portal to reservation facilities which are themselves nationwide.

Still another feature is the ability to customize an individual user's authorization limits. As can be appreciated, one of the mixed blessings of providing enhanced functionality to the individual users of any integrated computer system is that it places great power in the hands of the user which at the same time creates the potential for abuse. There have been well publicized instances of- "rogue" employees making financial decisions or placing instructions which have far reaching financial consequences well beyond the intended authority of an employee, with disastrous results.

With the second parent's invention, one feature is the ability to limit the financial commitments that a user may make during any pre-selected time period. For example, the user's profile may limit his ability to make only a certain dollar limit of vehicle reservations over any certain number of work days. In this way, added safe guards may be conveniently provided, monitored by reporting capabilities, and changed as circumstances warrant, all with simple programming changes at the web portal . There are still other features that are provided by the second parent's invention that find their genesis in the different approach taken over the first parent's invention and owing to the inherent increased flexibility of using a web based programming for the web portal to interface between the user and the providers on the web server and eliminating the need for any custom software on the user's terminal. The details of these are to be found and described in the detailed description of the preferred embodiment below. Examples include the ability to send confirmatory communications to the user that the reservation has been received and entered into the provider's system for fulfillment, custom report design including the capability to save and re-generate the custom report upon user command, increased flexibility to process and pay invoices, etc. Still other advantages and features have been developed and are newly disclosed and claimed more particularly herein. These advantages and features relate to usage of the present invention both domestically and abroad where there are idiosyncrasies in the business model that need to be accommodated. Still other features provide entirely new functionality. One such new feature involves adapting the present invention as a tool to market replacement vehicles for sale or lease to a customer who has had an accident significant enough that repair of his vehicle is not economically feasible. This is commonly referred to

"totaling" a vehicle. The insurance industry totals about 3 million cars per year, of which approximately 17% are newer models (defined as within three years of current model year) . Once totaled, the owner needs to buy another car. Since car rental companies desire to sell more cars, any opportunity to tap into the total loss market will be bountiful.

The present invention provides a window into the establishment of a total loss for a renter ' s/insured' s/claimant' s automobile. Any car that is deemed to be a total loss would be indicated as such in the present invention for reporting purposes. At this point the stored information could be used to help provide economic benefit to all parties, insurance company, rental car company, and automobile owner.

Once a renter ' s/insured' s/claimant ' s (owner's) car is determined to be a total loss the adjuster will try to ascertain the actual cash value (ACV) to be settled with the owner. The adjuster can use a third party tool, such as CCC's Pathways® product, to determine what ACV is. Today an adjuster must input this information manually into a separate application. The present invention contains much of the necessary information needed to determine ACV: name, car make, model series, year. The present invention need merely send the necessary information electronically to a total loss product and request an electronic response. Once the necessary information is generated, the present invention would in turn take the ACV and cross reference the car rental database of inventory.. Necessary information might include but not be limited to: ACV, year, make, model series, comparable cars, etc.

The car rental inventory can be filtered by geography and "holding requirements". As a reseller of vehicles, the car rental inventory is generally contractually required to be within the fleet as a rental for a predetermined amount of time prior to being available for sale to third parties. Once a car is past the holding requirement it is generally within the discretion of the car rental company to sell. Thus, instead of X% of cars available to the car rental company for retail sale, a virtual inventory of cars is available for retail sale to the owner of the car.

Once the filters for geography and holding requirements are active, the present invention delivers a list of available vehicles for sale. At this point the adjuster and owner review the available cars, decide the cars considered to be attractive, and the owner then decides which one he wishes to purchase .

The user then selects one or more potential vehicles and sends the request to the appropriate car rental location. The car rental location can then contact the owner of the vehicle to buy one of the selected vehicles. In addition, the list of vehicles and ACV information can be sent to the owner for further review and discussion. Once the car rental company contacts the owner and comes to a sufficient conclusion, either to buy or not to buy, the adjuster is notified of the conclusion and the transaction is consummated either through the present invention or off-line. Still other features are disclosed and claimed herein which extend the functionality of the present invention.

These include the following. One such feature is providing for automatic extensions of existing rental authorization, so that some limited extension authority is granted to. permit some flexibility to a particular user without burdening him with the need to obtain approval for the extension. Another feature could be referred to offline usage, and provides the^' functional advantage of permitting processing of reservation data in a computer not connected into the network, and then uploading/downloading between the offline computer as it is connected into the network, such as by dialing into the network over the internet, or through a portal. The type of data which could be processed includes virtually any related to the processing of vehicle rental transactions and other related data such as car repair scheduling, etc. This functionality provides an extension of the usability to the invention to mobile users who travel beyond the reach of the internet, which even further enhances its applicability to those places not covered by wireless coverage. Alternatively, it allows the invention to bypass special connectivity issues which are thought to be disadvantageous for any reason including cost, unavailability, inconvenience, etc. Still another feature includes further integration of the internal data bases kept by permitting a user to automatically update not just one but several data bases with a single command once that new data is entered into a single menu. For example, in what can be referred to as "power templates", a user may enter a multiple number of rental reservations on a single menu and then click a single "approved" icon which would then enter all of them into the system. This represents an improvement over a previous implementation requiring a user to separately "approve" each reservation, and then suffer the system processing time for each reservation. This "batch" processing can result in significant improvement in throughput, and reduction of user interface time for processing multiple transactions. Still another feature provides the added functionality of processing customer satisfaction feedback through the system. This feature provides the capability for a user to enter customer feedback information, both positive and negative but perhaps more importantly negative, so that immediate awareness of any problem can be obtained and corrective action taken to mitigate or eliminate the difficulty. This feature also allows a user to indicate a suggested supervisory level of interaction, or the system may allow for automatic escalation of involvement for succeeding levels of supervisory attention as the dissatisfaction continues or even escalates. This feature can be significant to a service provider as the ultimate success of a service provider is directly dependent on the perception of satisfaction by the end customer. And, it is well known that the sooner a problem is identified and solved, the more likely a customer will have a satisfactory experience. Furthermore, from a strict economic viewpoint, the sooner some problem is addressed and solved, generally the less expensive the solution. A small accommodation can change a frown to a smile, if promptly offered.

Still other features are now disclosed that have applicability perhaps in the domestic business model, but certainly offer needed functionality in other business models found in other countries. One of these includes multiple party involvement/management of a rental transaction. While the flexibility of allowing multiple adjusters within a group to "work on" a rental transaction has been previously described, this particular feature is different in that not only may these multiple adjusters not be within the same group, they might not be employed by the same employer, might not be adjusters themselves, and might have different authority for action on the transaction as is commonly found in different countries. For example, in some countries one adjuster authorizes and manages the rental reservation for the car while another adjuster authorizes and manages the insurance coverage for the rental. Still another feature allows third party or "independent party" management of the rental. In some countries a third party other than an insurance company is involved, such as a "credit hire" or "assist companies" or "repair facility" or "lawyer" or "fleet management company". Each of these third parties, or any other third party, may be permitted access to the system and a user profile created for them that defines their authority to process rental transactions through an administrative profile set up in advance through agreement with the authorizing agent, such as an insurance company. As an enhancement, various individualized features may also provide data indigenous to a particular country, such as electronic access to the Schwackliste book for an adjuster to conveniently view a "class" for a car to determine what replacement vehicle is legally authorized for rental. Still another example of a feature needed to accommodate international capability is a need for a tiered rate system, and an hourly rental charge instead of a daily charge which predominates the domestic market. Processing of electronic signatures to satisfy local custom or legal requirement is yet another example of a feature for which the present invention is uniquely suited to provide .

While the principal advantages and features of the invention have been discussed above, a greater understanding of the invention including a fuller description of its other advantages and features may be attained by referring to the drawings and the detailed description of the preferred embodiment which follow.

Brief Description of the Drawings

Figure 1 is a schematic diagram of the computer systems comprising the first parent' s invention;

Figure 2 is a flow chart of the software programs which communicate over the computer systems of fig. 1 to implement- the first parent's invention; and

Figure 3 is a schematic diagram of the computer systems comprising the second parent's invention.

Detailed Description of the Preferred Embodiment

The overall system architecture for the first parent's invention 20 is best shown in Fig. 1. As shown therein, an insurance company computer system 22, which itself may be virtually any computer configuration or even a stand alone PC accesses the Internet 24 through any convenient access point 26 such as even including an ISP (Internet service provider) , as known in the art. Also connected to the Internet 24 is a web portal 28 which is preferably provided by a server appropriately programmed as explained herein below. This web portal 28 may be appropriately configured as desired to suit any particular business relationship or arrangement, although preferably the inventors herein and assignee of this invention have determined that a 24/7 or full time connection to the Internet 24 is preferable, except for scheduled downtimes for maintenance, etc. The service provider 30 which for purposes of explaining the first parent's preferred embodiment is preferably a vehicle rental organization, has itself an Internet portal mainframe 32 connected by a bi-directional communication link 34 to a second computer network 36 which may itself preferably have a mainframe server 38. This second computer system 36 is preferably a network having a database 40 for communication with what may be thousands of branch offices each of which has its own computer interface 44 which communicates to this second mainframe server 38 to conduct the integrated business functions of a service provider organization. Instead of communicating with the branch offices directly, a reservation may be communicated to a centralized location for further processing, such as a call center, and then relayed on to an appropriate branch office. This might be desirable under certain circumstances, such as if a branch office is closed, or when a purchaser requires some specialized service such as close monitoring of the rental. This may be done electronically and automatically, or with human intervention. It should be noted that the particular computer configuration chosen as the preferred embodiment of the first parent's invention may itself be subject to wide variation. Furthermore, the term "mainframe" as used herein refers solely to a computer which can provide large scale processing of large numbers of transactions in a timely enough manner to suit the particular business application. Preferably, as is presently used by the assignee hereof, an IBM AS/400 mainframe computer is used as each of computers 32, 38. However, as is well known in the art, computer technology is subject to rapid change and it is difficult if not impossible to predict how these computer systems may evolve as technology advances in this art. For example, it is not beyond the realm of possibility that in the not so distant future a network of computers would provide the processing power to conduct these business operations as presently handled by "mainframe" computers. Thus, the term "mainframe" is not used in a limiting sense but merely to indicate that it is descriptive of a computer suited to handle the processing needs for a large scale business application. It should also be noted that the communication link 46 extending between the server 42 and each of the branch offices 44 may have alternative configurations. For example, in some applications access over the Internet may itself be adequate, recognizing the vagaries of Internet service availability, reliability, and processing speed. Alternatively, this communication link 46 could well be a dedicated pipeline providing broadband service connection full time with back up connections to ensure continuous communication between a particular branch office or groups of branch offices and the service providers business operations computer system 36. Some branch offices might even be served through satellite links. Indeed, it is even possible that a mixture of these wide variations of service level be present within a single organization' s structure depending upon communication link cost and availability balanced against service needs. It should merely be noted for present purposes that this communication link 46 serves as the electronic umbilical cord through which branch offices 44 communicate with the business computer system 36 of the invention. Attached hereto as exhibits are functional descriptions of the software programs resident on the computers comprising the two computer systems 32, 38 which implement the first parent's invention. More particularly, attached hereto as Exhibit A is a functional description of the software to implement the integrated business functions resident on the AS/400 or mainframe computer 38. Attached hereto as Exhibits B and C are related flow diagrams and explanatory text, respectively, for the software resident on the mainframe AS/400 computer 32. Attached hereto as Exhibit D is a functional description of the software resident on computer 32 but which also appears on the server 28 which creates the web portal for access to the mainframe 32 and its resident program. Server 28 may use a bi-directional GUI to character based interface translator program, well known to those skilled in the art, to present the displays and information obtained and transmitted between the user and the computer 32. However, the software of Exhibit D could also be run on server 28, as would be appreciated by those of skill in the art. It is believed that these functional descriptions and accompanying text as exemplified in these exhibits are adequate to enable an ordinary programmer to implement corresponding software programs for executing the preferred embodiment of the first parent's invention using ordinary programming skills and without inventive effort. As a further example of the flow of data and the functional advantages provided by the first parent's invention, reference is made to Fig. 2. As shown therein, a right hand column is identified as "ECARS" which represents the integrated business software implemented as part of the mainframe operation 38 in computer network 36. The center column headed "ARMS" is resident on mainframe computer 32 and coordinates the communication of data. The left column headed "ARMS/WEB" represents the software resident on computer but which is presented on server 28 and accessible by users through the Internet. Along the left side of Fig. 2 are designated three separate sections of operational activity. These are "reservation" followed by "open" and concluded by "close". Generally, the functional descriptions are arranged in chronological order proceeding from the top of Fig. 2 to the bottom. However, some functional features are permitted throughout the entirety of one of the three periods designated at the left side of Fig. 2. One such example is the "message" function which allows messages to be sent between users at one business organization 22 and branch offices 44 and others connected to the other business organization 30. Proceeding with a description of the transaction, the first set of communications allow for the reservation of the services. These can include requests for authorization or a rescind , authorization request to be sent from the service provider to the service purchaser. Correspondingly, authorizations and authorization cancels can be sent from the services purchaser to the services provider. Confirmations are communicated upon confirmation of an authorized reservation request. Authorization changes may be made and communicated from the services purchaser to the service provider. Corresponding rental transaction changes may be communicated from the services provider to the services purchaser. As indicated, through the entirety of this process messages may be sent between users and others connected or having access to the integrated business software, as desired. The consummation of this portion of the transaction is a reservation that has been placed, authorized, confirmed, and provision is made for changes as necessary. During the next phase of the transaction, a reservation is opened and services intended to be provided are started. Generally, and preferably for the rental of vehicles, a start and end date are established in the reservation process. However, along the way, transactional changes may be made, such as for changing the type of vehicle provided, extensions may be requested and entered from either business partner, messages may be transmitted between the business partners, and the transaction may be terminated such as by voiding the contract by one business partner or terminating the authority by the other business partner. The term "reservation" has been used herein to refer not only to the act of placing the order but also to filling the order for services including providing the rental vehicle to the ultimate user and even invoicing for those services .

The last phase of the process involves closing the transaction. During this phase of the transaction, the contract is indicated as being closed and invoiced, the services purchaser can approve invoices, reject invoices, and also remit invoices. Such invoice remittance may also include the actual transfer of funds through an electronic funds transfer medium, or otherwise as previously arranged between the business partners.

It should be understood that this is a streamlined description of the handling of a transaction, and by no means is exhaustive. For example, much more functionality is available to the user including accessing the data base to generate production reports regarding status of open or closed reservations, preparing action item lists to allow a user to organize and prioritize his work, obtaining information available in the system from having been entered by others which would otherwise require phone conversations which are inefficient and occupy still another person's time. A more detailed explanation of the functionality provided is found in the exhibits .

In summary, the first parent's invention creates almost an illusion that the services purchaser, and the great number of users at various levels of the multi-tier purchaser users, are actually part of the services provider organization in that immediate online access is provided to significant data which enable the user to make reservations for services, monitor those services as they are being provided, communicate with those providing the services, obtain information relating to the status of services as they are being provided, and close transactions, all by interacting with the services provider business organization over that user's PC and without human interaction required by the business providers personnel. By way of contra-distinction, for many years business has been conducted on a human level by customers picking up the telephone and calling services providers and talking to their human counterparts in order to convey information, place orders, monitor orders, including obtaining information as to status, canceling orders, questioning invoices and paying invoices, along with a myriad of other related interactions. Not only did the conduct of business in this manner entail significant amounts of human resources at both ends of the transaction, but it also led to inefficiencies, mistakes and delays all of which increase the cost of doing business and contribute to an increased risk of services being rendered in an unsatisfactory manner in many instances to the end user. The first parent's invention has taken the preexisting solution of providing electronic communication between the business partners to another level by "web enabling" this system for improved connectivity, improved usability, reduced training, enhanced mobility, and other advantages as described herein. A schematic diagram of the second parent's invention is shown in Fig. 3 and includes three levels of architecture. As shown in the first level of the architecture 50, a user 52 such as an insurance company or other user has access through the Internet 54 to the computer system comprising and incorporating the invention. An Internet provider provides a link 56 through which Internet connections may be made to communicate with the further described system. For convenience, this Internet connection may be considered as an Internet site or portal in that a user enters a URL and arrives at this connection. A firewall 58 as is known in the art is used for security purposes and to prevent hackers and the like from unauthorized access to the system. A first set of servers 60 are interconnected in a network 62 and may preferably include an ancillary server 64 for running load balancing software or the like to balance the load and provide redundancy amongst what may be a plurality of web servers 60. These web servers 60 may preferably be Sun Microsystem servers running Apache web server software, or other such suitable software as would be well known to those of ordinary skill in the art. This first web server network of servers 60, 62 process the random and disorderly communications flowing to and from this system and the Internet before passing them through a firewall 66 as a further precautionary measure. This first layer of architecture, identified as the Internet space/DMZ layer provides a secure interface and creates order out of the chaos of communications flowing between the system and others, as will be described.

With this architecture, stateless connections are accommodated, for the first time. By supporting stateless connections, this embodiment eliminates the implementation difficulties encountered with the first parent' s embodiment on the client. These implementation difficulties include installing extra software on the client side computers, and eliminates the need for special configuration of the internet access method, such as proxy servers or routers. For example, many proxy server are configured to disallow stateful connections for security reasons, i.e. to prevent unauthorized programs from establishing such connections. Another example is that routers are customarily configured with most ports closed and thereby unable to support stateful connections.

The next layer of architecture 68 is noted in the figure as the "Enterprise private network" and is comprised of a plurality of servers 70 network connected with a network connection 72. Again, although the choice of hardware is not considered critical by the inventors hereof, Sun Microsystem's server/work station hardware is preferably used to provide the platform for running the application software for processing the various rental vehicle transactions, as will now be explained. Attached hereto as Exhibit E are a series of functional design specifications for the ARMS/WEB application software resident on servers 70 and which provide the detailed description of the operational features of the software and system. With these functional design specifications for the individual modules, it would be readily apparent to those of ordinary skill in the art that programmers of ordinary skill would be able to write software to execute these functional specifications without using inventive effort. Furthermore, the details of this implementation are not considered to provide any aspect of the best mode for carrying out the invention which is defined by the claims below. Generally, the ARMS/WEB application software permits a user to sign on and, when recognized, provides the series of menus presenting choices for the user to indicate the parameters for his reservation. A plethora of information is provided and accessible to the user through the various menus provided from which the user selects and enters data to process the reservation. An important feature of the ARMS/WEB application software is that it provides the user the opportunity to select to place his vehicle rental reservation not only with the integrated business computer system represented by the third level of architecture 74, described below, but also to route the reservation information back through the first architectural level 50 and into the Internet 54 for transmission to a competitive service provider 76. Although the interconnection is depicted in Fig. 3 as being made through the Internet 54, the network of servers 70 configured in accordance with the ARMS/WEB application software may utilize virtually any electronic means for transmitting the reservation information to a competitive services provider 76. These include email, automated telephone, facsimile, and other forms of electronic communication. Of course, the competitive services provider 76 may itself comprise an integrated business such that the level of interconnectivity provided to the user 52 may parallel that disclosed and described in connection with the integrated services provider system of the invention as well as the first parent's invention. This integrated business capability is represented as the third level 74 of the architectural topography shown in Fig. 3 which parallels portions of that shown in Fig. 1 in that a pair of network mainframe computers, such as AS/400's 78, 80 may process reservations to and from various branch offices 82 which are geographically diverse.

With the invention, the Internet portal provided by the ARMS/WEB network configured servers 70 provide an Internet portal for communication with not only the integrated computer enabled business system of the resident services provider, but also a portal for placing reservations to other competitive services providers 76. Thus, the user 52 enjoys the capability of accessing multiple service providers for competitive services through a single Internet connection using a single set of protocols, menus, etc. for the conduct of this business activity. Furthermore, the software configured network of servers 70 is readily configured in Web Logic to adapt to changing user requirements, data requirements, unique competitive service provider requirements, and other upgrades or modifications in a convenient manner by simply modifying the software resident therein. No special browser software of other interface software is required by the user and any special interconnecting software or server/hardware requirements may be satisfied as between the service providers such that the user is presented with a seamless interconnection. As the invention is configured and works well with the integrated business and computer systems as disclosed herein, it is anticipated that such interconnection and usability may be readily translated to any other such integrated computer system as might be found in other competitive service providers, as would be apparent to those of ordinary skill in the art. Thus, with the invention, a user is provided with among other things Internet access through a single portal to a plurality of service providers and, to the extent possible, to their integrated computer business systems.

The invention is sufficiently flexible to accommodate changes which are intended to adapt it for use with other business models, and especially those encountered in other countries. Furthermore, some of these changes add features that are equally applicable domestically. One such example is an "automated extensions" feature. Typically, there are many occasions when a damaged or inconvenienced vehicle is not made available for use when originally scheduled. In the prior art, many times an extension would then need to be requested through the system, with authorization requested and provided. In order to streamline this process, and to minimize delay and involvement of supervisory authority, the system may provide for some form of automatic extension authority. Preferably, this could be provided in any one of three modalities, or some combination thereof. A first modality would be for the service provider to have automatic extension authority, upon- communication to the customer, within certain pre-determined limits. For example, an initial authorization may be for 12 days of a vehicle rental. A request for an extension of 5 days may be made by the service provider and of that 5 days 3 days may be authorized automatically as being within 25% of the original rental term and a request for the additional 2 days requiring approval may be automatically generated. Still another variation would be for the insurance company to set a limit within the system of the total number of authorized days, which could be based on some other parameter such as labor hours or body shop hours or down time for the repairs to take place. Then, upon request for an extension, one may be automatically granted based on the total authority allowed or initially set into the system by the insurance company, and up to that limit. Still another variation would be for a third party service provider to be involved in the process, such as a body shop, to make direct input into the system of a need for an extension. These authorized third party providers would preferably be pre-selected and their authority limited as described above. This feature may be implemented conveniently in a separate menu, for example as shown in the attached "screen shots" headed "Extend Rental".

Another feature is an offline usage feature which allows a user, such as an adjuster, to work with a laptop having loaded thereon a software program that emulates the connected network software for local processing of data, such as claims data. In use, an adjuster would preferably first connect to the system and download or "synch" his laptop data base with the claims data resident in the system. The adjuster would then disconnect and use his local program to work offline. Such work could include the generation of new reservations, authorization of direct billings, extension of rentals, approval of invoices, and setting of termination dates for ongoing rentals, among other tasks. The user would then reconnect to the system, such as over an internet connection, sign in, and "synch" his laptop to the system which then transmits or executes his commands/communications to the central processor. The central processor checks the users "synch" data against its data file, advises the user of any "synch" data that is older than the current data, and requests the user to specify which data should be processed. After the processor is instructed by the user, it will then act on the "synch" data. For clarity, a first "screen shot" is provided that illustrates a sign in log for a user who wants to initiate a "synch", and a second "screen shot" is provided to illustrate a listing of activity that could have been created offline and which is available to be input to the system upon "synching" . A preferences feature is provided to allow a user to establish defaults for automatic syncing of the data. Also, a history feature will allow the user to display all of the syncing activity from his connection or portal including error messages and conflicts noted. Yet another feature allows for a user to enter, or execute, a full menu of transactions without individually opening them from a summary menu. This has been referred to as a "power template" feature. Instead, a hyperlink is provided to allow a user to jump into another menu of details for an individual item should it need to be changed and not entered as suggested, requested or listed on a user's action list.

Still another feature allows for the collection of user satisfaction feedback, and alerts to be entered for the attention to complaints, by the user right at his terminal. This capability allows for a text message to be entered as well as the name and -contact information of the party making the feedback. As known in the service industry, and as discussed above, customer satisfaction is important and the faster a complaint can be registered and communicated to the proper person for correction, and then corrected, the more likely that a customer will view his experience favorably. By providing a pop up menu item capability, a user may from any one of a number of menus immediately enter the description of the problem and send it to the proper person electronically with a minimal amount of effort and a high degree of reliability. A convenient record may then be made of these "feedback" issues and entered into the system database. With this information stored electronically, it may be conveniently searched and analyzed for any recurring patterns, thereby identifying any particular person, branch, facility, or type of problem that should be addressed for action beyond the solution of the immediate problem. A "screen shot" is provided to illustrate how the "pop up" menu may appear, although it could be varied to allow for entry of other or additional information such as "trouble codes" allowing for the type of problem to be user classified, etc. A flow diagram is also provided to illustrate the flow for complaints, a methodology for processing them including escalating their importance and level of attention as the matter remains unresolved over time.

Still another feature that adds to the flexibility of the invention is a multiple adjuster feature, that can be extended to include an independent party control feature. In some countries, and in some business models either domestically or abroad, it may be preferable to have more than one adjuster be empowered to interact with or authorize certain facets of a vehicle rental transaction. In those situations, the invention can provide the flexibility and control needed to separately empower and control the interaction of multiple adjusters. For each user of the invention, an "Administration" schedule is set up by an authorizing agent, such as someone at the supervisory level of either the insurance company or the service provider, which grants authority for performing certain work activities as well as possibly limiting the amount of monetary authority allowed that adjuster. A "screen shot" is attached which exemplifies such authorization, with work activities including creating/authorizing reservations, maintain/extend rentals, pay invoices, user maintenance, receive unassigned action items, and reporting. This capability could be used to separately authorize different adjusters acting on behalf of the insurance company and the individual. In other words, the individual may need the car for 5 days but the individual's insurance coverage may only apply for 3 days while the insurance may pay for five days rental. This capability may also be further extended to independent third parties.

As extended for independent party management, this capability further adapts the invention for use with agencies such as "credit hire", "lawyer", "fleet management companies", or "repair facility", or "assist companies", all of which are found in other than domestic markets. Included herewith is an attachment which further explains the different types of independent parties routinely found at present, and examples of "screen shots" which provide the additional functionality of customizing authorizations for each of these independent parties for interacting with a rental transaction.

Yet another feature provided by the invention is a facility for marketing cars for sale/lease to customers. As explained above, a customer will occasionally be forced to replace his vehicle at the same time that he is renting a vehicle for temporary use. Furthermore, the value of the replacement vehicle, or the approved value that an insurance company will allow under coverage, many times determines the available vehicles from which a customer will be allowed to select without personal expense. The invention is uniquely designed to provide a listing of available cars, and information about the cars, all from the existing rental car data base as is kept in routinely running the rental car company's main business of renting cars. It is a simple matter to provide a menu which allows a user to specify search through the car inventory with parameters such as zip code, vehicle category, make and model. Using any one or more of these parameters, a search inquiry will then produce a listing of available vehicles matching the parameters, along with additional information about the vehicle including mileage, selling price, and color as well as other accessories. A customer could then be advised of the search results and allowed to select a vehicle. The invention may, if agreed to by the insurance company, and possibly conditioned on the physical inspection of the car by the customer, then authorize the transfer of the vehicle to the customer as an outright settlement of his claim. In implementing the replacement of the customers vehicle, a process preferably comprises the steps of an adjuster identifying the loss as a total loss which is preferably entered at the same time that a replacement vehicle rental is reserved, sending the vehicle data to a third party valuation tool for processing, determining the valuation of the vehicle by a suitable measure such as actual cash value (ACV) , sending the ACV to the system, using the search function to identify possible replacement vehicles available for the customer, finalizing the replacement process with the customer including executing transfer of title documentation if desired, and posting the results of the vehicle replacement in the system for access by the insurance adjuster so that he can confirm that the customer's claim has been satisfied. A flow chart describing this process is attached for further explanation. Various changes and modifications to the preferred embodiment as explained herein would be envisioned by those of skill in the art. Examples of these changes and modifications include the utilization of computer systems configured in any one of a myriad of ways using present technology alone. For example, mobile computers are presently available and wireless technology could be used to extend the integrated business network of the services provider, as well as match the mobility needed by the various users connected to and using the present invention. The particular software, and various aspects and features of its design, have been adapted for particular application to the vehicle rental business. Of course, computer software applications satisfying other business needs would necessarily require adaptation to their particular business models. Thus, it is envisioned by the inventors herein that the various software programs described herein would be matched to the particular business application to which the invention is utilized. These and other aspects of the preferred embodiment should not be viewed as limiting and instead be considered merely as illustrative of an example of the practical implementation of the present invention.

These changes and modifications should be considered as part of the invention and the invention should be considered as limited only by the scope of the claims appended hereto and their legal equivalents .

TABLE OF CONTENTS

Introduction Page II

A brief overview of the ECARS Workbook and Training System. Outlines functions that will be discussed within the workbook.

Getting Started Page III

Sign On Procedures, Key Strokes, General Facts about RALPH, ECARS Training Menu.

Exercises

Exercise 1 Reservations Page 1-1

Exercise 2 Open a Ticket - Calendar Day Page 2-1

Exercise 3 Open a Ticket - 24 Hour Page 3-1

Exercise 4 Specials Page 4-1

Exercise 5 Open Ticket Cross Reference Page 5-1

Exercise 6 Correct a Ticket Page 6-1

Exercise 7 Switching Units/Changing Rates Page 7-1

Exercise 8 Callbacks Page 8-1

Exercise 9 Closing a Ticket Page 9-1

Exercise 10 Cash Management Page 10-1

Error Messages Page VIII

The most commonly seen error messages will be discussed along with corrective actions.

Page I ECARS WORKBOOK

INTRODUCTION

The ECARS Workbook and Training System - AARTOl - have been designed to teach the basic skills for working with ECARS - Enteφrise Computer Assisted Rental System. Don't be alarmed if what you read in this workbook and what you see on the screen is slightly different. ECARS is constantly being improved and enhanced to work more efficiently for you.

Topics Covered

Reservations

Opening rental tickets with various billing types

Ticket Cross Referencing

Correcting ticket information

Switching Units and Changing Rates

Callbacks

Closing rental tickets with various payment and billing types

Computerized CRS (Cash Receipt Summary) and deposits

Training

Workbook requires approximately 3 hours to complete

Self Study

Work at your own pace

Workbook Format

Each exercise guides you through an activity step by step

Most exercises build upon information covered in previous exercises

You will be able to see how different ECARS options are linked together:

Reservation | ^■> I Open a Ticket \ ■> | Callback | • Close a Ticket

Ranges from basic rental functions to refunds. Numbers to Know

The Rental Help Desk may be contacted at 1-800-416-8000. Specially trained ECARS personnel are available to answer questions and help with any problems you may encounter.

Networic Services may be contacted at 1 -800-416-8000. A team ofNetwork Operators, who are RALPH experts, are available to correct any hardware problems experienced by the computer system.

You are now ready to begin!

Page II Rates/ Amounts/ Dates

Use these examples for keying rates/amounts.

$16.50 = 16.5 Field Exit

$16.00 = 16 Field Exit

May 20, 1994 = 052094

Options and Choices

When Yes or No answers are requested, key Y-Yes or N-No.

When several choices are given, key "X" or "1" in the selection field next to the item chosen.

Names

Names must be keyed in the correct format to help RALPH alphabetize names and distinguish between an individual or company name. Use these examples for keying names.

Individual. Smith* Cindy*

Smith* Cindy M*

Company. Enterprise Rent-a-Car** Crawford Company**

(Key an asterisk * by holding down the Shift key and pressing 8*)

Numeric Keypad

Use the numeric keypad, located on the right side of the keyboard, to key mileage, rates, etc. The numeric keypad is designed in the same manner as a calculator; therefore, you may find it easier to work with.

Important Keys

There are several important keys on the keyboard that are essential to using ECARS.

Reset When data is keyed incorrectly, that field will be highlighted and an error message will inform you of the problem. Press Reset and re-key the data.

Enter Press Enter to send the information to be processed.

Fl,2,3...or Command and/or Function keys are used to enter and exit various options. They Cmd 1,2,3.. are located on the top of the keyboard. Command/Function keys are displayed on the bottom of each screen.

Page IV ECARS Training Menu

To access the ECARS Training Menu, key AARTOl at the Enter Request line 1 ENTER The followinα screen will appear.

The ECARS Training Menu consists of the most used options in ECARS . Each of these options will have a corresponding exercise in this workbook.

Option 1 - Open a Ticket: This option is used to open the majority of rental tickets in the office.

Option 2 - Correct a Ticket: This option allows you to correct and/or add information such as an additional driver, claim number, etc

Option 3 - Switching Units/ This option is used to switch units and/or change rates Changing Rates:

Option 5 - Closing a Ticket: This option is used to close all rental tickets.

Option 10 - Open Ticket X-Ref: This option allows you to "look up" an open ticket to retrieve basic information.

Option 11 - Reservations This option is used to create, view, update, transfer, or cancel Branch Rental Reservations.

Option 12 - Callbacks This option is used to authorize or extend rental tickets by the type of callback. (For example Body Shop, Service Department, Insurance Company Adjustor, or Customer.)

Option 15 - Cash Management: This option allows you to balance the cash summary and make deposits. Exit to Enter Request Prompt.

Lease Cust. Information about renting to Lease Customers.

Page VI EXERCISE 1 RESERVATIONS

Exercise 1 will guide you through Option 11 - Reservations - to create, view, update, transfer, or cancel Branch Rental Reservations This option is very helpful in providing the branch(s) with better customer service, pickups, and deliveries

On the ECARS Training Menu, key Option #11 I ENTER The Reservation Menu Screen will appear. (See example screen on the following page)

NOTE: You can key as little or as much information that is available when taking the reservation. Any information keyed into the reservation will automatically forward to the open ticket, saving you time. when the renter is in the office picking up a vehicle or waiting for a "Pick Up."

To update a reservation, any information keyed may be changed by keying directly over that which is displayed. Information may also be added or deleted if necessary

Page 1 - 1 Category #1-Create a New Reservation

Screen 1

1. Key your five-character employee number at top of the screen

2. Key Renter's Name (pretend you're the renter)-Last Name*First Name* and Social Security Number

3. Key rental pickup, date/time, and rental return date Use today's date for both pickup and return date. Key X to select either W in = Walk-in, P/up = Pickup, Deliver = Delivery, or CWC ^β Customer will call. I TAB RIGHT Ito space provided for additional comments, if needed.

4. Key Renter's phone information. I TAB RIGHT Ito description field for any comments, as needed.

5.

next to 999 UNKNOWN** on the Source ID Screen. NOTE: If your name is not on the list, key 999999 as the Bill to Cust# and type your Last Name* First Name* on the name line. Key 999 as the Attention ID and key your name on the Attention Line. Key the Auth Until Date (use today's date), the Maximum Dollar Amount per Day, Claim/Pol/Po#, Date of Loss, Type of Loss, and Insured's Name.

Screen description continued on the following page.

Page 1 - 3 FUNCTION KEYS FOR OPTION 11 - RESERVATIONS

listed on the bottom portion of each screen are several Function (?) keys Each one performs a function that may be used while creating or viewing a Branch Reservation

FI = Exit Allows you to cancel a new reservation While viewing a reservation you can exit to the Reservation Menu Screen

F2 = Cust List Displays a list of customer names and numbers that are to be used for sourcing See example window below

εsτ ;„.. Branch List SMS0Q2A/C1 e isao

Posi ion to description?

3 £»e Op ions _r pres-S Eπ ex. l*Selfec 5*D£splay

Ojt. Cust# Description State Phone

_ GQS433 ADAMS COUNTY CREDIT UNION** IL 618-555-8877

--_ G08246 AEROSPACE CREDIT UNION** MO 314-555-0050

~ 00005 ΑLVXH JACKSON USED CARS** MO 816-555-1277

~^* 1.00171 AMERICAN AUTO MART** IL 618-555-6688

+

F2«Details F3=Exit F6«Branch F7= I F8=Group F10=! State F11*A11 n≥^βPrβ i uβ Roll^sForward/Back

You can press F2=Details again to view a detailed branch list. The detailed list includes the customer name, address, and phone number. This is handy if you are trying to locate a specific customer who has multiple locations or if you need to contact the account in question.

Key " I" in the Opt (option) field to select a customer number. The screen automatically forwards to the contact screen. See example window on the next page

Page 1 -5 See example screen below

1 MORE INFORMATION CCRSiS-,- Renter Name KING* CATHY* hZS<t 100963 Renter Drivers License State Exp. Date

DOE Height Height tyes Ha. r

Employer

2 Additional Driver (V c: N ) Driver Name Address Age

Drivers ticenae* State Exp n»«

3 Out Of State (V or N j

4 Bi ll -To Name (Company Name*"* J

Attention

Address Phσne t \ City State Zip

S Start Chga If Oi-_f Oβt* Time Pickup Date 6/25/ 95 1: 0C PM

6 _ Calendar __ 84 Hdtir. _ S ecia s

7 Rates- .DO /Hou .00 /Da .00 /Keek .00 /Month Mileage 0 Mil* After 0 /Day 0000 /Wee* 0000 /Month _^ Ho Chg Dr p Cho Drop .location Disc 0 % Droj Waiver .00 /Day t>Al .CO /Day

F5«Ratea/Rules F7~AAI F12-Previous Enter-Update

Remember, all information keyed here will automatically transfer to the Open Rental Ticket to save you and the renter time

1. Key Driver's License Information and Current Employer's Name

2. Key Additional Driver Information: Name, Address, Age, Driver's License #, State, and Expiration Date

3. Key Y=Yes, or N=No, if the rental will be going out of state. If yes, key all associated states to which renter plans to travel.

4. Key "Bill To" Information: Company Name, Contact Person, Address. Phone Number, City, State, and Zip Code will be pre-loaded, if valid Customer # is keyed on the first Reservation Screen.

5. Pickup Date and Arrival Time will display, if keyed on the first Reservation Screen, Key new Date and Time to start charges, if applicable.

6. Key X to select billing type: Calendar or 24hr, and Specials, if applicable

7. Key Rate Information and any Discounts, if applicable.

NOTE; This screen is edited in blocks. For example, if the Driver's License Number is entered then the State, Expiration Date, and Birth Date are required. Follow displayed ERROR MESSAGES to guide you as you go!

F9 = Transfer Allo s you to transfer a reservation to another Branch within your Group

This is helpful for location purposes and availability of units. It also allows you to transfer ARMS Reservations to another Group.

F12 = Previous Return to previous screen. NOTE? If F 12 is used, any updates just keyed will NOT be saved.

Page 1 -7 Keys is presseα first Allows access to enter valuable credit information when the reservation is created. This is helpful to determine money deposits or rental approval. See example screen below

Information keyed here will not appear on the Open Rental Ticket. This is reference information to be viewed within the reservation system.

1. Key Renter ID information: Name (Last Name*First Name*), Current Address, Phone Numbers), Social Security Number, Date of Birth, Age, and Length of Time lived at the above address (Years/ Months).

2. Key Current Employer Name, Current Position Held, and Length of Employment (Years Months). Repeat the process for previous employment, as needed.

3. Key Previous Addresses), and Length of Time lived at each location (Years Mønths), if applicable.

4. Key Renter's Spouse Name, Current Employer Name, Cu eπt Position Held, and Length of Employment (Years/Months), if applicable.

5. Key Y^βYes, over default N-No, to print a copy of the Credit Check Screen.

6. Key Y=Yes if credit has been checked.

NOTE; Follow the policies set by your Group when creating a reservation. You can enter as much or as little of the credit information appropriate to the rental situation. The entire Credit Check Screen is optional. Ask your Rental Branch Manager to review situations applicable for Credit Check information to be taken.

Page 1 -9 F21=ID Rntr Allows you to to locate previous renter information without exiting the reservation. See example screen below

Key the Renter's Driver's License Number and State or Provence OR the Home Phone Number (required). The Renter's name may also be keyed (optional). If more than one match is found, the Renter ID Selection screen appears. See example screen below.

Search the screen to see if the customer is on the list. If the customer's name does not appear on this screen, key the driver's name (Last/First) in the Position to field. | ENTER I. The name keyed appears at the top of the list. Key "1 " in the Opt (option) field to select a customer. I ENTER I. The customer's information is protected and loaded into the appropriate fields.

OR

Key "5" to view customer information in greater detail. I ENTER I . The Renter ID Detail screen appears. See example screen on the next page.

Page 1 - 1 1 ENTER to accept your Reservation.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

ou have just created a Branch Reservation! For additional practice, open another reservation using ie following information:

• Use your favorite celebrity's name for the renter's name

• Do NOT key a Social Security Number

• Use today 's date as the pickup and return date

• Make it a Bill To of "N"

• Make it a Callback type of "Cust"

Be sure to key in all necessary information to make a complete reservation, using the above data plus your own chosen information.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Turn to the next page to learn how to view a reservation by Customer Name/Group

(Category #2)

Page 1 - 13 Category #3- View Reservation for Date/Group

To view a Reservation by date, key in the Month/Day/Year in the space provided on the Reservation Menu Screen, #3 Today's date and your Group Branch will already be pre-loaded To view a different date or Group Branch, key desired information over existing A list of reservations will appear in sequential order - starting with the earliest Reservation associated with the date you requested See example screen below

NOTE: This display can also be selected on the Reservation Menu Screen, #3 by Group When only a Group is selected the reservation comments are NOT shown as in the above example

Reminder! Scroll forward backward to view all Customer Reservations To make a revision to a reservation. key X next to the applicable Customer Name, press | ENTER | and make revisions, as needed.

2. Next Time Key Next Time (Hour:Minutes AM/PM) of reservations to be viewed This is optional, as needed ( ENTER( to advance to the new time listings as requested

3. To print a copy of the reservations listed, key Y=Yes, over default N=No

NOTE: The function keys are discussed in detail, starting on page 1-5.

Page 1 - 15 EXERCISE 2 OPEN A TICKET- CALENDAR DAY

This exercise will guide you through Option 1 - Open a Ticket for a Calendar Day. Be sure to follow the format exactly as stated in this exercise. This ticket will be used again later on in the workbook'

If necessary, key AARTOl IENTERI to access the ECARS Training Menu.

t Cxodl^Exit CRidβele se Cust

1. Option # Field: Key Option Number 01

2. D# 000000 This field will remain blank; a ticket number has not yet been created

3. Branch: Your branch number will be displayed in the field. to move the cursor to the next field.

4. Name Key the first three letters of your last name in this field.

5. Home Phone # Key your Home Phone Number in this field and or (see number six) .

6. DL#, ST/PROV: Key your Driver's License number and State or Province.

7. Res#. Thisfield will remain blankforthis exercise. A National Reservation Number or Branch Reservation Number is keyed in this field if one is known.

\ ENTER I to accept the information keyed and advance to the next screen.

You should see a listing of all reservations for customers whose last name begins with the same three letters aswerekeyed. Locate and "X" the reservation you created for yourself. This information will forward to the ticket.

Exit to Enter Request Prompt.

CMD 8 I Lease Customer. Information about renting to Lease Customers.

Pagc2- l NOTE: The information that you had keyed into the reservation should have forwarded to the Open Rental Ticket. For those fields that you left blank, please fill themin appropriately

Section 2 - Renter Information

\

RENTAL TYPE I (I/B/D/R/C/O) S Soouurce Cust # 2 ID Name 3 ^" <Last*First* )

Street 4

City 5 ST Zip

Home Ptione ( ) - 6

Office Phone ( ) - Ext Employer

Other Phone ( 000 ) 000 - 0000 7 Description

V . Local «Addr 8

V

1. Key I - Insurance for Rental Type.

2. Use State Farm as the Source Customer for this exercise. Key " State" in the Source Customer # Field Press F2=Cust List. The following screen appears.

MIDWEST Branch List SMS002AC1

GPBR 1520

Position to description: STATE

Type options, press Enter. l^Select 5=Display

Opt Cust# Description State Phone

STF433 STATE FARM** IL 618-555-8877

STF246 STATE FARM** MO 314-555-0050

STF005 STATE FARM** MO 816-555-1277

STF171 STATE. FARM** IL 618-555-6688

+

1 F2«=Details F3=Exit F6=Branch F7=AAI F8=Group F10»State Fll=All

1 F12«Previous Roll=Forward/Back

You can press F2=Details again to view a detailed branch list. The detailed list includes the customer name, address, and phone number. This is helpful when there are multiple locations for the customer. If there are no customers on the branch list, you can press F8=Gτoup for a Group list, F 1 O^State for a State list, or F 11 -All for a list including all customer numbers

Key " 1 " in the Opt (option) field next to the first State Farm to select a customer number. The screen automatically forwards to the contacts screen. See example screen on the next page

Page2 - 3 Section 3 ■» Driver License

{ DL# 123456789 ST MO Expires 062S94 DOB 032760 SS# 555 555555 (

'Height 6 02 Weight 175 Eyes BROWN Hair BLONDE '

1. Key the Driver License Number (no spaces are necessary).

2. ITAB RIGHT I and key the State abbreviation and Expiration Date.

3. Key Date of Birth.

4. If you keyed your SS# on the Training Menu Screen, it will be pulled forward, lf not, key the SS#.

5. Key Height, Weight, Eye Color and Hair Color.

to move cursor to tbenext section, if necessary.

Pagc2 -5 Screen 2 is broken down into three sections

1. Special Instructions: If Special Instructions exist for the Source Customer Number, they will be displayed

2. Company Bill To: This section requires a YES or NO answer Ifyes, the Customer Number to be billed, the ID # and other company information are required .

3. Claim/Pol/PO#: This section requiresthe Claim, Policy or Purchase Order Number along with information regarding the Damaged/Stolen Vehicle, Insurance Rate and Shop Information.

NOTE: The function keys will be discussed in detail at the end of this exercise, page 2- 14

Page 2 - 7 Screen 3 is broken down into four sections

1. Special Instructions: If Special Instructions exist for your Bill To Customer Number, they will be displayed

2. Callback Type: A "Callback" is a service offered to all customers. The rental branch personnel places calls to Body Shops and Service Departments to check the status of the customer's vehicle. Calls are then made to adjusters for extensions and to customers to pass along information (the car is ready, last day the insurance company will pay is XXX, etc.). This section requires the Callback Type to be marked with an "X". The Callback Type will. help RALPH distinguish the callback list to which this ticket should be assigned.

3. Calendar 24 Hour/ Specials: You can decide here whether billing will be on a Calendar day or 24- hour basis. You can also go to the "Specials" screen by placing an X next to Special .

4. Taxes and Additional Changes: This section will display tax information, fuel charges, and additional charges that have been customized by Group/Branch. You can choose what charges apply by simply placing an X in front of the charge. You can also note if a drop charge applies.

NOTE. The function keys will be discussed in detail at the end of this exercise, page 2- 14

2-9 Screen 4 is bro en down into six sections

1. Car Type Requested/Rate Quoted: This information will be pulled forward from the Branch or National Reservation. If a Car Type was not requested, or a rate was not quoted, NONE will be displayed in this field.

2. Date Out/Current and Customer Ext: Today's Date and Time will be supplied by Ralph. Current Ext Date appears if you placed an "X" in B/S, Adj or Service Callback. Customer Ext date appears if you placed an"X" inCustomerCallback.

3. ECAR#: This section requires an ECAR Number and License or Serial Number to be keyed. You can key this from the key tag or by using F6=Units Available. If the unit information is not available, use F9=Unit Pending. The ticket will print, but you must complete this information, whenavailable, usingoption9 ontheECARSMainMenu, "CompleteaTicket".

4. Rate: Thissection requires infonmationregardingthe daily rate, along with the milejLge limitations andc arges. Estimated Charges, Damage Waiver, PAl and SLP daily rates are also includedjinthis section. All rates are examples only. Please check with your Group for correct rates .

5. Deposits: Thissection requires information regardingthe deposit to be taken at the time of the rental and how it was received.

6. CallbackNote: Key a briefnote in the Callback Note field, as necessary. This note pulls forward to the Rental Ticket for reference.

NOTE: The function keys will be discussed at the end of this exercise, page 2-1 .

Page2 - H Section 5 - Deposits

DEPOSITS CashQgtT Check .00 CC .00

Key 100 jFIELD EXIT )in the Cash field to designate a $ 100 Cash deposit

to move cursor to the next section

Section 6 - Callback Note

'CALLBACK NOTE I ^*\

1 2 date Code _ Emp# 55555 Emp# if Different OOOOO 1

1. Key a briefnote, as necessary.

2. Key your Update code and your 5-digit Employee Number.

\ ENTER j to accept information keyed. Correct any errors, if necessary The EC ARS Training Menu will be displayed when ticket is accepted.

Congratulations!

You havejust completed your first rental ticket. In the "hve" ECARS program, thecompleted rental ticket would print from the DR Ticket Printer.

Page 2 - 13 Screen 1

N

( BRANCH RESERVATION SOMBER 100003 j Print {Y or N) (tT) CCRS01-A

1 Pickup Branch PPGM

Emp#

2 Name <LAST*FIRST*) SSN8

3

SICKUF- Date Time_, RETURN: Date.

W/in P/up Deliver CWC Comment

PHONE: Home {_ Office. ext

Other Description

5 r/ /D/R/CO _ Source Custt ID

BILL "TO; Direct Bill (Y or N) _ Credit Card _ Cash/Check _

Bill To Cust# or Name ~ JCCMPANΪ**)

Attention _{t ... .} Auth Until Max A t LAIM#/Pol/Po Date of Loss.

{C/Claimant, 1/Ins red, T/Theft) Insured

6 SHM-I

CftR HΥPEϊ Class _^ Type *ra ^• Comment _ RATE QUOTED §. Comment

Info

Fθ*=Transfer Fl2=Previαus Fl3=Insurance F15=Res Notes

F21«=ΓD Rntr F22«Clear Rntr ID F23=More Keys

. / he Reservation Screen is very similar to that of Option 1 - Opening a Ticket . Key your five-character employee number at top of the screen.

. Key Renter's Name (pretend you're the renter)-Last Name*First Name* and Social Security Number.

. Key rental pickup, date/time, and rental return date. Use today's date for both pickup and return date. Key X to select either- W/in = Walk-in, P/up = Pickup, Deliver = Delivery, or CWC = Customer will call.l TAB RIGHT Ito space provided for additional comments, if needed.

\. Key Renter's phone information. I TAB RIGHT lto description field for any comments, as needed.

5. Key Rental Type "I" - Insurance. The other rental types are B=Body Shop, D=Dealership, R=Regular, C=Corporate, or O=Other. Key "STATE" in the Source Cust# field. Press F 2=Cust List A Branch List appears. If there are no choices available, press F8=Group for a group list.^' ey "X" next to a State Farm Office. This automatically forwards to the Source ID List Screen (see page 2-3). Key "X" next to the first adjustor name.

Key Y=Yes to set up a Direct Bill. Key "X" to select payment type: Credit Card, Cash/Check. For the Bill to Cust# use the F2=Cust List Window key, again. "X" your name on the list. Key "X" next to 999 UNKNOWN* * on the Source ID Screen. NOTE: If your name is not on the list, key 999999 as the Bill to Cust# and type your Last Name* First Name* on the name line. Key 999 as the Attention ID and key your name on the Attention Line. Key the Auth Until Date (use today's date), the Maximum Dollar Amount per Day, Claim/Pol/Po#, Date of Loss, Type of Loss, and Iπsured's Name.

Screen description continued on the following page.

Page 1 -3 WCTION KEYS FOR OPTION 11 - RESERVATIONS

ed on the bottom portion of each screen are several Function (F) keys. Each one performs a function may be used while creating or viewing a Branch Reservation.

= Exit Allows you to cancel a new reservation. While viewing a reservation you can exit to the Reservation Menu Screen.

= Cust List Displays a list of customer names and numbers that are to be used for sourcing. See example window below.

:rø !ES7- , - XΪ J. , ^% . Branch List A SMS002A/C1 ..

^,GPBR^ \1520

^ osi ion to esc ip ion'. •

^ ^Ty e o io s _r press Enter.

; I Select --5«*Disρlay

Opt cust# Description State Phone

_ -G0S433 ADAMS COUNTY CREDIT UNION** IL 618-555-8877 ._ , - S0S246 AEROSPACE CREDIT UNION** MO 314-555-0050

~ K0OQG5 ALVXK JAC SON VSEO CARS** , MO 816-555-1277

_ _Λ O0171 AMERICAN AUTO MART** IL 61β-55S-66β8

+

F2«Details ^% F3=Exit ,F6=Branch F7=AAI F8-Group F10=State F11=A11 ϊ .≥**Previous Roll-Forward/Back

ou can press F2=Details again to view a detailed branch list. The detailed list includes the customer name, Idress, and phone number. This is handy if you are trying to locate a specific customer who has multiple cations or if you need to contact the account in question.

.ey " 1 " in the Opt (option) field to select a customer number. The screen automatically forwards to the αntact screen. See example window on the next page.

Page 1 -5 See example screen below

MORE INFO KMΛ7ZOI- C RS 25-A

Renter Name KING- CATHY* κεs« loose 3 Renter Drivers -.-.cense Sc ate Exf. Date

DOB Hexght Height Eyes Ho.t

Employer

Additional Driver (Y cr ^N» Driver Name Address Age

Drivers License State Exp Date

Out Of State (Y or ti)

Bi ll -To Name (Company Name""* } Attention

Address Phone | J Ext

City Sta e Zip

Start Chgs If Ei£f State Time - Pickup Date 6 2S 35 1 .0Q EM

_ -Calendar _ 24 Hour _ Specials

Sates. .00 /Hour ' .00 /Day .00 /Meek .00 /Month Mileage 0 Mile After G -jOay 0000 /Heete 0000 /Month _ tiσ Chg Drop Ctvj Drop Location Disc 0 % Dmg Waiver .00 /Day ©Aϊ .00 /Day

F5»Ratea / Rules F7«AAI F12-Previous Ent er—IJpdate member, all information keyed here will automatically transfer to the Open Rental Ticket to save you and

! renter time.

Key Driver's License Information and Current Employer's Name

Key Additional Driver Information: Name, Address, Age, Driver's License #, State, and Expiration

Date

Key Y=Yes, or N=No, if the rental will be going out of state. Ifyes, key all associated states to which renter plans to travel

Key "Bill To" Information: Company Name, Contact Person, Address, Phone Number, City, State, and

Zip Code will be pre-loaded, if valid Customer # is keyed on the first Reservation Screen.

Pickup Date and Arrival Time will display, if keyed on the first Reservation Screen. Key new

Date and Time to start charges, if applicable.

Key X to select billing type: Calendar or 24hr, and Specials, if applicable.

Key Rate Information and any Discounts, if applicable.

OTE: This screen is edited in blocks. For example, if the Driver's License Number is entered then the tate, Expiration Date, and Birth Date are required. Follow displayed ERROR MESSAGES to guide you > you go!

9 = Transfer Allows you to transfer a reservation to another Branch within your Group

This is helpful for location purposes and availability of units. It also allows you to transfer ARMS Reservations to another Group.

12 = Previous Return to previous screen. NOTE: If F 12 is used, any updates just keyed will NOT be saved.

Page 1 -7 Keys is pressed tirst. Allows access to e er vaiuame u cuu nuυiuiαuυn when the reservation is created. This is helpful to determine money deposits or rental approval. See example screen below

formation keyed here will not appear on the Open Rental Ticket. This is reference information to be ;wed within the reservation system.

Key Renter ID information: Name (Last Name*First Name* ), Current Address, Phone Number(s), Social Security Number, Date of Birth, Age, and Length of Time lived at the above address (Years/ Months).

Key Current Employer Name, Current Position Held, and Length of Employment (Years/Months). Repeat the process for previous employment, as needed.

. Key Previous Address(s), and Length of Time lived at each location (Years/Months), if applicable.

. Key Renter's Spouse Name, Current Employer Name, Current Position Held, and Length of Employment (Years Months), if applicable. i. Key Y=Yes, over default N=No, to print a copy of the Credit Check Screen i. Key Y=Yes if credit has been checked. røTE: Follow the policies set by your Group when creating a reservation. You can enter as much or as ittle of the credit information appropriate to the rental situation. The entire Credit Check Screen is optional. \sk your Rental Branch Manager to review situations applicable for Credit Check information to be taken.

Page 1 -9 =ID Rntr Allows you to to locate previous renter information without exiting the reservation. See example screen below

;ENTRAL ID Renter FQS04QA/1

3 # St/Prov tame Phoπe# ( ) _

*ame (Last) (Pirst)

Note: Drivers li cense number and St/Prov or Home Phone number are required. Haute is optional-

_y the Renter's Driver's License Number and State or Provence OR the Home Phone Number ϊquired). The Renter's name may also be keyed (optional). If more than one match is found, the Renter > Selection screen appears. See example screen below.

.ΈNTRA Renter ID Selection FQSOlOA1

Searched by: Phone Number { ) - D/L# St/Prov

Position to: Name (Last) (First)

Type option, press ΕNTE l=Select 5=Vie ,

Opt Name Street Address St Zip

SMITH*KEVIH* 123 HARRISON MO 63101 5684

SMITH*RALPH* 467 MOLOAI ROAD HI 97895

TAVERS*JOSEPH* 4223 VERIAINE AVENUE WI 39667 7421

_ TIPTON*ROBERT* 508 V1ENNETTA DRIVE LA 7046D 6531

F3=Exit F12=Previous

learch the screen to see if the customer is on the list. If the customer's name does not appear on this creen, key the driver's name (Last First) in the Position to field. 1 ENTER |. The name keyed appears it the top of the list. Key "1 " in the Opt (option) field to select a customer. I ENTER The customer's nformation is protected and loaded into the appropriate fields.

OR i ey "5" to view customer information in greater detail. I ENTER | . The Renter ID Detail screen appears. See example screen on the next page.

Page 1 -11 TER to accept your Reservation.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

have just created a Branch Reservation! For additional practice, open another reservation using D-lowing information:

• Use your favorite celebrity 's name for the renter's name

• Do NOT key a Social Security Number

• Use today 's date as the pickup and return date

• Make it a Bill To of "N"

• Make it a Callback type of "Cust"

sure to key in all necessary information to make a complete reservation, using the above data plus your n chosen information.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Turn to the next page to learn how to view a reservation by Customer Name/Group

(Category #2)

Page 1-13 egory #3- View Reservation for Date/Group άew a Reservation by date, key in the Month/Day/Year in the space provided on the Reservation Menu sen, #3. Today's date and your Group/Branch will already be pre-loaded To view a different date or up/Branch, key desired information over existing A list of reservations will appear in sequential order - ting with the earliest Reservation associated with the date you requested See example screen below

RESERVATIONS FOR GPBR 7799 CCRS03-B |

Tuesday JUNE 21, 1S94 Print (Y or m(¥)

Total Reservations : i ^~ ;

[ext Time _ 2

3 Car Rental

Customer Name Time Res#^" Type Status Type 1

^ STSANKLIN*BEN* 100501

^" UENKINS* JOHN* S00 PM A98761 ICAR NRES - R j

~ JONES*KIM* 100066 ECAR DEL I 1 Please meet her in the lobby Λ " j

*

*• l*=Exit F7=AAI F12*' Previous Screen Roll=Forward/ Back / y is screen displays a list of all reservations for a Group/Branch or Group for a sj :date. You can view pecific reservation by keying X next to the applicable Customer Name.

Displays Customer Name, Time of Arrival, Reservation Number, CapType requested, rental Status, Rental Type, and Comments, if applicable. To view a specific reservation, key X on the line next to the Customer's Name.l to move cursor down thς fst of names, as needed. Press

ENTER I to advance you to the selected reservation s) screen

3TE; This display can also be selected on the Reservation Menu Screen, #3 by Group. When only a oup is selected the reservation comments are NOT shown as in the above example ϊminder! Scroll forward ackward to view all Customer Reservations. To make a revision to a reservation, y X next to the applicable Customer Name, press 1 ENTER | and make revisions, as needed.

Next Time. Key Next Time (Hour:Minutes/AM/PM) of reservations to be viewed. This is optional, as needed. | ENTER| to advance to the new time listings as requested.

To print a copy of the reservations listed, key Y=Yes, over default N=No.

QTE: The function keys are discussed in detail, starting on page 1 -5.

Page 1 - 15 ERCISE 2 OPEN A TICKET- CALENDAR DAY s exercise will guide you through Option 1 - Open a Ticket for a Calendar Day. Be sure to follow the nat exactly as stated in this exercise. This ticket will be used again later on in the workbook'

ecessary, key AARTOl | ENTER1 to access the ECARS Training Menu.

Option#Field: Key Option Number 01.

D# 000000 : This field will remain blank; a ticket number has not yet been created.

Branch: Your branch number will be displayed in the field to move the cursorto the next field.

Name Key the first three letters of your last name in this field

Home Phone# Key your Home Phone Number in this field and/or (see number six). DL#, ST/PROV: Keyyour Driver's License number and State or Province. Res#: Thisfieldwillremainblankforthisexercise. ANationalReservationNumber or Branch Reservation Number is keyed in this field if one is known.

ENTER 1 to accept the information keyed and advanceto thenext screen. ou should see a listing of all reservations for customers whose last name begins with the same three letters iwerekeyed. Locate and "X" the reservation you created foryourself. This information will forward to te ticket.

Exit to Enter Request Prompt. CMD 8 I Lease Customer. Information about renting to Lease Customers.

Page2- 1 E: The information that you had keyed into the reservation should have torwarded to the Open ;al Ticket. For those fields that you left blank, please fill them in appropriately ion 2 - Renter Information

\

RENTAL TYPE I (I/B/D/R/C/O) Source Cust # ² ID

Name 3 (Last*First*)

Street 4

City 5 ST Zip

Home ?hone ( ) - 6

Office PhtKie { ) - Ext Employer

Other Rhone ( 000 ) 000 - 0000 7 Description

I±ocal Adr 8

ey I - Insurance for Rental Type.

Jse State Farm as the Source Customer for this exercise. Key "State" in the Source Customer # Field, ress F2=Cust List. The following screen appears.

MIDWEST Branch List SMS002AC1

GRBR 1520

Position -description: STATE

Type options _f press Enter.

IβSelect 5= =Display

Opt Cust# Description State Phone

STF433 STATE FARM** IL 618-555-8877 • - . ,

STF246 STATE FARM** MO 314-555-0050

STF005 STATE FARM**- MO 816-555-1277

_ STF171 STATE FARM** IL 618-555-6688 +

F2*= etails F3=Exit F6=Branch F7=AAI F8=Group F10=State Fll=All F12*?rεvious Roll=For ard/Back

>u can press F2=Details again to view a detailed branch list. The detailed list includes the customer name, idress, and phone number. This is helpful when there are multiple locations for the customer. Ifthere are > customers on the branch list, you can press F8=Group for a Group list, F 1 CH=State for a State list, or 11=A11 for a list including all customer numbers. ey " 1 " in the Opt (option) field next to the first State Farm to select a customer number. The screen itomatically forwards to the contacts screen. See example screen on the next page.

Page 2 -3 tion 3 - Driver License

.# 123456789 ST WΩ Expires 062594 DOB 032760 SS# 555 55 5555 | light 6 02 Weight 175_ Eyes BROWN Hair BLONDE • '

ey the Driver License Number (no spaces are necessary) .

TAB RIGHTl and key the State abbreviation and Expiration Date.

Key Date of Birth.

If you keyed your S S# on the Training Menu Screen, it will be pulled forward. If not, key the SS#.

Key Height, Weight, Eye Color and Hair Color.

_'■ ...I I to move cursorto the next section, if necessary .

Page 2 -5

Special Instructions: If Special Instructions exist forthe Source Customer Number, they will displayed.

Company Bill To : This section requires a YES or NO answer. If yes, the Customer Number to be billed, i ID # and other company information are required .

Claim/Pol/PO#: This section requiresthe Claim, Policy or Purchase Order Number alongwith information »ardingthe Damaged/Stolen Vehicle, Insurance Rate and Shop Information. -

OTE: The function keys will be discussed in detail at the end of this exercise, page 2-14.

Page 2 -7 :en 3 is broken down into four sections

Special Instructions: If Special Instructions exist for your Bill To Customer Number, ;y will be displayed

Callback Type: A "Callback" is a service offered to all customers. The rental branch personnel places lls to Body Shops and Service Departments to check the status of the customer's vehicle Calls are then ide to adjustors for extensions and to customers to pass along information (the car is ready, last day the •urance company will pay is XXX, etc.). This section requires the Callback Type to be marked with an ." . The Callback Type will, help RALPH distinguish the callback list to which this ticket should be as- pied.

Calendar/24 Hour/ Specials: You can decide here whether billing will be on a Calendar day or 24- r basis. You can also go to the "Specials" screen by placing an X next to Special.

Taxes and Additional Charges: This section will display tax information, fuel charges, and additional larges that have been customized by Group/Branch You can choose what charges apply by simply lacing an X in front of the charge. You can also note if a drop charge applies.- ,^{' '}

[OTE: The fimction keys will be discussed in detail at the end of this exercise, page 2-14

Page 2 -9 en 4 is broken down into six sections.

I

I TYPE REQUESTED

-E QUOTED $ .00 F5=Rates

2 & OUT Time (Start Chgs If Diff Date Time Cust Ext Date Time th Until Date 000000

AR # 3 License # Or Serial # Not on File

3JE .00 /Hour •00/Day .00/Week .00/Mσπth Disc%

LEASE Mile After: _ /Day /Week /Month

__ No Charge

J .00 /Day $136.34 Est Charges a .00 /Day JP 5_*99 /Day

DEPOSITS Cash .00 Check .00 CC .00

CλULδACK. MOTE

Update Code EmpS Emp'ft if Different

'3=E it F5*=Rates/Rules F6=Units Avl F7=AAI F8=Prewrite

F9=Unit Pend FI0=CC Approval Fll=Ck Apryl F12=Prev F16=Est Chgs

Car Type Requested/Rate Quoted: This information will be pulled forward from the Branch or National servation. If a Car Type was not requested, or a rate was not quoted, NONE will be displayed in this field .

Date Out/Current and Customer Ext: Today's Date and Time will be supplied by Ralph. Current Ext ite appears if you placed an "X" in B/S, Adj or Service Callback. Customer Ext date appears if you placed "X" in Customer Callback.

ECAR #: This section requires an ECAR Number and License or Serial Number to be keyed. You can y this from the key tag or by using F6=Units Available. If the unit information is not available, use >=UnitPending. The ticket will print, butyoumustcompletethisinformation,whenavώlable,usingoption9 itheECARS MainMenu, "Complete a Ticket".

Rate: Thissection requires information regardingthedailyrate, along with themileageliπdtationsandcharges. stimated Charges, Damage Waiver, PAl and SLP daily rates are also includedjn this section. All rates are camplesonly. Please check with your Group forcorrect rates.

, Deposits: This section requires information regarding the deposit to be taken at the time of the rental and DW it was received.

. CallbackNote: Key a briefnote in the Callback Note field, as necessary. This note pulls forward to the .ental Ticket for reference.

ϊOTE: The function keys will be discussed at the end of this exercise, page 2-14.

Page 2 - l l ion 5 - Deposits

POSITS Check .00 CC . 00

_/ 100 IFIELD EXIT lin the Cash field to designate a $100 Cash deposit.

to move cursor to the next section.

tion 6 - Callback Note

OΛBACK NOTE

2 Update Code Eπtp# 55555 £mp# if Different 00000_. I S

Key a briefnote, as necessary.

Key your Update code and your 5-digit Employee Number.

NTER | to accept information keyed. Correct any errors, if necessary. The ECARS Training Menu will displayed when ticket is accepted.

Congratulations!

You have just completed your first rental ticket . In the " live" ECARS program, the completed rental ticket would print from the DRTicket Printer.

Page 2 - 13 JERCISE 3 OPEN A TICKET - 24 HOUR

exercise will guide you through Option 1 - Open a Ticket for a 24 hour clock Be sure to follow brmat exactly as stated in this workbook. This ticket will be used again later'

iβ ECARS Training Menu is not still on the screen from the previous exercise, key AARTOl on Enter Request line | ENTER The ECARS Training Menu will appear.

Option Field: Key Option Number 01.

Name: Key the first 3 letters ofyour favorite celebrity's last name in thisfield.

Home Phone #: Do NOT key aHomePhoneNumber or Driver's License Number this time.

iNTER I to accept the information keyed and advance to the next screen ocate and "X" your favorite celebrity's reservation you previously created. This information will forward to le ticket.

CMD 1 I Exitto Enter RequestPrompt.

CMD 8 I Lease Customer. Information about renting to Lease Customers.

Page3 - 1 ion 4 - Additional Driver

1 2

ITXOHA1- DRIVER (Y/N) _Y Driver Name TIM HI LMftN Age 25 | r 3 Lic# St Exp I

ey Y - Yes for an additional driver Key the name of a family member or friend r B RIGHT! to move the cursor to the next field. Key the Age of the additional driver. If you do at know the exact age, but know they meet the age requirement, key 25

ey Additional Driver Address.

TAB RIGHT! to move cursor to next field. Key Additional Driver License Information. to move cursor to the next section, if necessary.

:tion 5 - Out of State

)UT OF STATE (Y N) [ ^ ILLINOIS |

y Y - Yes, and key the State(s) to which the renter plans to travel.

ess [ENTER I to accept the information keyed and advance to Screen 2. RALPH will scan the ormation you have keyed from top to bottom. If any errors exist, or if a field has been left blank, an IROR MESSAGE will be displayed. This message will explain exactly what needs to be corrected and e cursor will be placed at that field. See the section on ERROR MESSAGES for more information. ake any necessary corrections and press ) ENTER) again. Repeat this procedure until Screen 2 appears.

Page3 - 3 ion 2 - Callback Type

N

Callback Type B/S _ Adj _ Svc _ Cust

r an "X" to mark this ticket as a Customer Callback.

:tion 3 - Calendar / 24 Hour / Specials

-alendar Day _ 24 Hour Day _ Specials

AB RIGHT to move cursor to next field an Key an "X" in the selection field for 24 hour.

ction 4 - Taxes and Additional Charges

\

Sales Tax % Fuel Charge Per Drop Charge Drop Location

GOVTSCHG 06% AP/ACC 06% LESERTAX 10% ADDLDRVR 2.00 per day Additional Driver Indicated

F3*Exit F5=Rates/Rules Fβ«Pre rite F10_*=CC Approval Fll=Check Approval F12=Previouε

he Sales Tax/Surcharge and Fuel Charges will be preloaded by Ralph. The fields for Drop Charge and >rop Location will remain blank for this exercise. You may see a few other charges in this section. These harges are Group Branch specific and have been customized by your Group Business Manager.

ENTER to advance to Screen 4. If any errors exist, correct them as you did on the previous screen.

Page3 -5 ^' \

WEE _ .-_.00 /Hour . 00 /Day .00 /Week , 00 / Month Disc %

ILEAGE 1 NMile After? Day /Week / Month _ N Cha ge

2 DW _^.0Q /Day

EAl^" .00 /Day

SLP ^ . 00 /Day^Λ

Key 6 JFIELD EXIT] in the Hourly Rate field. Key 24.95 |FIELD EXIT| in the Daily Rate field. The Veekly and Monthly Rate fields will remain blank for this exercise. The field for Discount will remain blank also.

Key 25 in the Mileage Charge field. Key 100 in the Per Day Mileage Allowance field Weekly, Monthly and No Charge will remain blank

to move cursor to Damage Waiver/Day Field.

Key 9 I FIELD EXIT I in the Damage Waiver field. Key 1 I FIELD EXIT ! in the PAl field.

FIELD EXIT over the SLP amount to remove it

Page3 -7 rcise 4 will guide you through opening a ticket with a Weekend/Holiday special rate. You will be the er.

Option 1 - Open a Ticket and complete Screens 1,2 and 3. In the section "Calendar/ 24 Hour/ cials," 24 hour and Specials | ENTER| . The following screen will appear.

vo Options are available for Special Rates. Option 1 - Daily Special. Option 2 - Package Special (one price charged for a specific number of days and miles).

Key an X in the slot to the left of the current date and time. If you wanted to start the special at a date/ tie^{* "}

.her than the current date/time, you could key the appropriate date/time in the field provided. Key the ite and time that the special will end. he Start and Stop Dates are very important, especially ifthe renter has the vehicle for any length of time efore or after the Special Rates apply. or this exercise, we will use a daily rate of $19.95 per day/100 miles per day.

. Key the Rate and Mileage information in the appropriate fields in the section for Daily Special.

ENTER] Screen 4 for a 24 hour rental will appear. ^r3=Main Menu. Return to the ECARS Main Menu.

^;5=Rates/Rules. Allows access the Rates Rules Screen.

⁷7=AAI. Allows access to inquiry programs.

⁷12=Previous Returns to the previous screen.

Pagc4 - l ERCISE 5 OPEN TICKET CROSS REFERENCE

^■rise 5 will show you how to look up an open Daily Rental Ticket by Name or Ticket # This option ry helpful for identifying Gpbr, Unit Number and License Number information

SCARS - ENTERPRISE COMPUTER ASSISTED RENTAL SYSTEM CCR Mϋ-A

dl«Exit C dδ-Lease Cust

Key Option# 10. | TAB LEFT I topositionthecursorintheselectionfieldtotherightoftheOption dumber. See the box marked on the example.

The customer's last name is keyed in Field A. If the ticket number is known, but not the customer name, key the ticket number in Field B . For this exercise, key your last name in Field A IENTER I . The bllowing screen will appear.

A ϊilEJCE-Cϋ'S OMER ^~ K«y«J-rt<mιer'»n«reehiM»<αleo upju«rthfrti --t CCRK14-

CustoroerHaa» ^: \, ,. , »ι J3SBR, Ticket _ TJnifc . , , License -#- SMITH* ROBERT* PP5M ' 999007 ^" P00224 P00224 lmdl«Return C dS^Main Menu-^, Cmd7=AAI

ιe Open Ticket Cross Reference displays the customer's Name, Gpbr, DR ticket number, Unit # id License #. ou may look up another ticket from this screen. Key your favorite celebrity's last name in the section arked Next Customer and press jENTERl . RALPH will locate that name and display the information. fate down the numbers of all the tickets you created. Return to the Training Menu by pressing CMD 1

Page 5 - 1 ERCISE 6 CORRECT A TICKET

ion 2 - Correct a Ticket, allows you to correct/add/delete information on an open Daily Rental Ticket. s option is most commonly used to add claim information, shop information, additional drivers, etc s option is NOT used to switch units or change rates.

Key Option # 02

Key the Daily Rental Ticket Number (use the lowest ticket number from Exercise 5 - Open Ticket Cross Reference).

ENTER] to accept the information and advance to the Correct a Ticket screen.

Page6- 1 Screen 2

Current Rate Effective On 06/13/97

Bill-To Attn

Claim/ OI./ϊ?0#- Loss Date 000000

(C/Claϋfllnt, l/lnsured_f T/T eft) Insured

SHOP: Cust# Name Attn

Car Year 93 Make/Model BUICK/REATTACNV Phone# ( 000 ) 000 - 0000

Surcharge % 5.Θ50 Fuel Charge 5.00 Per RENTAL

Drop Charge S.00 Drop Location

Airport Access _ 1.000 %

SLP 2.00 /DAY ADD DRIV 1.00 /DAY

∑mpi

F2*Cust List F3=Exit E7=AAI F12-Previouε

reen2 includes the sections: •Current Rate Effective Date •Claim/Policy/PO#

•Additional Charges 'Employee Number

ly information may be changed by keying directly over what is displayed. Information may also be added deleted if necessary.

id a $5.00 drop charge and key the Gpbr Number of another branch in your Group as the drop location.

ey your 5-digit Employee Number.

ENTER! to accept information.

F2 I Customer List.

F3 Exit to Main Menu.

F7 I AAI. Access Inquiry programs.

F12 Previous Screen.

Page6-3 ERCISE 7 SWITCHING UNITS/CHANGING RATES

exercise will show you how to switch units and/or change rates on an open Daily Rental Contract, the ticket # from Exercise 3 - Open a Ticket, 24 Hour.

he ECARS Training Menu Screen:

.ey Option # 3.

Ley the DR Ticket Number.

ΠΈR| The following screen will appear.

ιe screen is divided into 2 major sections.

Switching Units: The portion of the screen above the current date and time is used to switch units. Changing Rates: The lower portion of the screen, below current date and time, is used to change rates.

ither one or both options may be used.

[QTE: The command (function) keys will be discussed at the end of this exercise, page 7-4.

Page7- 1 4NGING RATES

HftNGING RATE-1 Original: 6/01/94 8:35 AM Current: 6/02/94 1:31 PM e rate effective date Time

:alendar day 24 Hour Day X Special Discount 00%

tate __ 6_.0__0 /hour 24.95/day .00/week .00/month lileage 625 {/mile after 100/day 0/week 0/moϊith N/C

Jaπage Waiver /day S.00 EAI/day l.OO

2mdl«Return. Ctnd4-Onits Avail C d5«Spec Cπtd6=Rate Cmd7«AAI CπtdlO-Prev Miles

Key the Date and Time the rate change becomes effective Calendar Day, 24 hour and Special may be changed by keying X, if necessary A Special Rate may be added/deleted, e g daily rate or package rate Do not update that information for this exercise

Change the Daily Rate to $32 99 per day, mileage will stay the same

Damage Waiver and PAl may be added/deleted/changed

ENTER I to accept information

Congratulations! ou have finished learning Exercise 7 - Switching Units/Changing Rates. Do NOT press

ENTER I . Turn to the next page and review the "Command" keys applicable to this section.

Page7-3 5=Rate Displays current rental Rate History on top portion of screen, followed by previous rate history information: Date and Time charges started. Rate/per Day, Mileage (unlimited or charged), Damage Waiver orPAI purchased.

RATE HISTORY Ticket « D026921 5PGM CCRHIR-D

C Start Charges 02/20/94 10:00 Mi u Current rate 6.00/Hour 32.99 /Day

R Free Miles 100 /Day

S. Damage Waiver 9.00 ESI 1.00 Excess Miles At 25 MI

Start Charges 02/22/94 08:30 m

Rate «.00/Hour 24.35 /Day

Free Miles 100/Day

Damage Waiver 9.00 PAl 1.00 Excess Miles λt 25 MI

d7=AAI Allows access to the Inquiry Programs.

dlCHPrev Miles Allows you to change previously keyed mileage.

Page7 -5

rcise 8 will guide you through Option 12 - Callbacks - to view or update Open Rental Tickets and ervations for your Branch or for another Branch on your machine. Also, the callback history will ain with the ticket after it has been closed. This is helpful if you have an adjustor or customer > has a question about a closed rental ticket.

ECARS - Eϊ ERERISE COMPUTER ASSISTED SEKTAΣ* SΪSTEM CCRTMU-A

-^ OpeiriA Ticket 11 - Reservations TRAINING

2 - "Correct A Ticket SYSTEM

3 - Swit<?hing Units/ (l2) - Callbacks ._,

Changing "R es & - Closing A Ticket 1$ - cash Management

\ PICKET feErøXCES) v

.113 J ~> Open. Ticket. Jt*Ref " ' Naate ύx. tricketf 060000

Option* — ^s s% 000000 Branch AC

-^■name Home Phone # I ) Rest DI.# ST/FR0V

Cm l-Exit m B- ease Cusst

n the ECARS Traimng Menu, key #12 on the line following Option #. (ENTER | . The Callback [enu Screen will appear. (See example screen on following page).

OTE: It is very important that you pay attention to detail while keying or updating all callback formation. It will eliminate problems if you are careful at the start.

Turn to the next page and learn all about the Callback System.

Good Luck!

Page8- 1 w, let's take a closer look at Section 1 - Review Tickets Needing Extensions. To start, key X to ict Body Shop calls on the Reservation Menu Screen 1 ENTER I to prompt the associated screen, wn below.

tion 1 - Body Shop

le Body Shop Screen lists all body shops alphabetically, including phone numbers and the number calls to be made to that shop.

Next Shop (optional) - Key the Shop Name you chose when you opened the Calendar Day ticket. Press I ENTER| . The next list will appear. - OR -

Shop Name - Key X by the Shop Name you had entered. I -~ * I to move cursor down the list of names, as needed. Press JENTERl . The Body Shop Selection Screen will appear, listing customers who are having their cars repaired at that particular shop. See example screen on the following page.

Shop Number - Displays shop Customer Number.

Shop Phone Number.

Number of Calls - Displays number of calls to be made to Shop.

Ito move cursor to top right of screen. To Print a copy of the Body Shop Callback

Screen, key Y=Yes over default N=No.

Leminder! Use your roll-up and roll-down keys to scroll backward or forward through Shop listings.

Page 8 -3 UIl 1 - DUUJ Oll μ 1 CK111 ϋt.l ..ll

^*S

BODY SHOP CALLBACK DETAIL - D100096 CB50-1

TE OUT 06/10/97 8:19AM CURR EXT 06/15/97 CUST EXT 06/15/97 STOMER DAVIS* TOM* HOME PHONE! 333-333-3333 TE 15.00 /DAY OFFICE PHONE# 333-343-3434 EXT 2323 OTHER PHQNE# 333-343-3435

■L-TO Y BILL-TO CUST* 999999 SHOP# 9999999 FRANK'S AUTO BODY

Λ.-TO HAME LEKKMAN* JANE* HONE# 314-456-9870

IHE# 212-212-2121 EXT7896 ATTOϊ Bob Brown

'ATTENTION 999 JANE LENKMAN YEAR 94 MAKE/MODL ACURA INTEGRA kIM/POL/PO# LOSS SATE 000000

. AMOUNT 25.00 INSURED

06/10/94 11:41 AM RENTAL EXTENDED UNTIL 06/13/94 BY TS 74024 06/13/94 θfOO AM PROBLEM GETTING PAINT TO' RΫ 75026

5RTUS LM X DO OK -5 CALLBACK TYPE X B/S X ADJ SVC CUST

PENSION DATE BY

Cust List F3=Exit F4=ID List F5=0pen Ticket F6=Chgs To Date r=AAI F8=Update Tkt F9=Callback Notes F10=Receipt Depos Roll=F d/Back

L2=Previo-ue F13=Inεurance F14-Credit Check Fl5=Reservation f background information you need to know about the renter is available on this detail screen.

Customer Information - Displays Ticket Number, Rental Date and Time Out, Current approved Extension Date, Renter's Name, Renter's home/office/other Phone, plus Rate the renter is being charged

BilUto Information - Displays the Bill-to Customer Number, Company Name, Phone Number and Extension, ID Number, Attention Name, Claim/Policy/P.O. Number, and Max Amount Bill-to Customer Number will pay. Also, Repair Shop's Customer Number and Name, Phone Number, Contact Person's Nar at the Shop, Year Make Model of renter's vehicle, Loss Date, and Insured's Name is listed|<— ~ to move cursor through the fields. To change ticket information, press F8=Update Tkt, then key new information over the existing information.

New Information - Displays all callback information to date. This is the most important and utilized part of the Callback System. RALPH automatically displays a record of all previous callback messages, date and time call was made, and employee number of the person who made the call. This record remains in the callback history of the closed ticket, for future reference. Use roll-up and roll-down keys to scroll backward and forward through the previous records, as needed.

DTE; To enter new information received from a current call, | C ' 1 to move cursor, key your iployee number in the "EMP#" field highlighted above. Key new information, "Body Shop said it will take 3 ore days."

Screen description continued on the following page.

Page 8 -5 on 1 - Adjustor le Callback Menu, key X next to Adjustor for Tickets needing extensions | ENTER

ADJUSTOR CALLS 6 CC( :BIO- ^■1 |

.Print {Y ox N) NEXT INSURANCE CO. ©

(Bill to Name) 3 4 (Phone Number 5 # OF

CUST# CALLS

_ AMX* TESTING CUSTOMER* AMXTEST 222-222-2222 002 FIREMAN ' S INSURANCE GROUP** FIROOOl 212-212-2121 003

_ HANNOVER INSURANCE GROUP** HAND101 111-111-1111 σαi

*^"

* -+ j •* nw l=Exit Cmd7=AAI ROLL=Fαrward/Ba ck Cmd2 «Jump

Adjustor Screen lists all insurance companies alphabetically, including customer numbers, phone ibers and number of calls to be made to that office

^e t Insurance Co. (optional) - Key your name. The name keyed appears at top of list.

Press [ ENTER I The next list will appear. -OR-

Bill to Name - Key X by the Insurance Company Name you will need to call. to move cursor down the list of names, as needed Press jENTE l The Insurance Company Selection

Screen will appear listing customers who need authorizations or extensions on rentals from that particular company

►TE: To view the Adjustor Selection Screen, key X by your name and | ENTER | See example een.on following page

Customer Number - Displays insurance company "Bill-to Customer Number."

Phone Number - Displays adjustor phone number.

Number of Calls - Displays number of calls to be made to Adjustor(s). to move cursor to top right of screen. To Print a copy of the Adjustor Callback Screen, key Y=Yes, over default N=No.

eminder! Use your roll-up and roll-down keys to scroll backward or forward through the Insurance _>mpany listings.

Page 8 -7 ion 1 - Adjustor Detail Screen

A

ADJUSTOR CALLBACK DETAIL - D100096 CB50-1

3TE: To enter new information received from a current call, 1 C ' | to move cursor, key your iployee number in the "EMP#" field highlighted above. Next, key all pertinent information in the .ssage space provided, using the same abbreviations that were used in previous messages. Change the atus of the call from "DO" to "OK." Key 3 days from today as the Extension Date.

This completes the review for Section 1 - Adjustor! Turn to the next page and continue the Callback Exercise for Section 1 - Customer.

Page 8 - 9 :tion 1 - Customer Cash/Check

Customer option can also provide a list of customers who are paying by cash/check ONLY To v this list from the customer calls, on the Callback Menu Screen, key X in both the "Customer" field

"Cash/Check Only" field ENTER to move cursor down the list of customer names. teeded. Key X to select the customer name to be displayed, press | ENTER the Customer Detail een will appear.

:tion 1 - Customer Detail Screen

Itatus of the call from "DO" to "OK." Key a new Customer Extension Date of 3 days from today ake any required deposits.

This completes the review for Section 1 - Customer! Turn to the next page and continue the Callback Exercise for Section 1 Service.

Page8 - ll >_

SERVICE CALLS 11 CB07-1

PRINT <Y OR N) (N ϊ CALLBACK

)NARCH CHEVY** 3 CURRENT ^' STATUS 37-654-3210 9999999 YEAR/MAKE/KQDEL TICKET# GR/BR EXT DATE SHOP ADJ 4 5 6 7 8 9

ABI.E* ALICE* ^<W KfflT) TMTWlSu * nn??<n s m m ofi/ι s /< m pn

Notes 10

DAVIS* TOM* 95 FORD MUSTANG * D027419 0101 06/17/94 DO DO Notes

JONES* SUE* 90 CHEVY LUMINA * D027420 C101 06/20/ 94 DO DO Notes

* .INDICATES TICKET KITH EXTENSION BATE GREATER THAN 2 DAYS OLD

Displays Service Shop Name Phone Number and 6-digit Customer Number.

Customer Name - Key X by your name. ( I to move cursor down the list of names, as needed.

Press ENTER . The selected Service Shop Detail Screen will appear. See example screen on the following page.

Displays Customer Number.

Displays Year/Make/Model of customer vehicle.

Displays Rental Ticket Number. An extension flag (*) indicates ticket has an extension date that is more than 2 days old. Definitely make all extension flags a priority'

Displays Group and Branch Numbers.

Current Ext. Date - Displays current extension of specific rental ticket.

Callback Status Shop - Displays shop callback status - LM (Left Message), DO (Make Call), OK (Call Made).

Callback Status Adjustor - Displays adjustor callback status - LM (Left Message), DO (Make Call), OK (Call Made).

). Notes - Key Service Shop notes. Notes will forward to Service Shop Detail Screen

OTE: You must still go into each detail screen and update the callback status (LM/DO/OK) for each istomer, even after keying notes.

1.1 C ' Ito move cursor to top right of screen. To Print a copy of the Service Shop Selection Screen, key Y=Yes, over default N=No. eminder! Use your roll-up and roll-down keys to scroll backward or forward through Shop listings.

Page8 - 13 ion 1 - All

N

OPEN TICKETS CB25^1 |

¹ PRINT (Y OR N) (N) 1

EXT CUSTOMER 1

3 14 CURRENT 5 CALLBACK TYPE ⁶ CUSTOMER J

TICKET* EXT DATE B/S ADJ SVC CST EXT DATE

KLSJDFKASJ* LASDF;L D999089

AUCKE* CLAUDIA* D999096 * 11/09/97

AUCKE* SVEN* R111062 * 11/01/97 lENOIT* TRICIA* D999019 * 1/28/97 1

BOMBAY* BILL* D999028 * 3/10/97 I lOND* JAMES* D999080 * 9/10/97

H3C_ --BETTY* D999022 — — — — * 2/20/97_^ j

i LEFT A MESSAGE .

* INDICATES 'TICKET TH EXTENSION DATE GREAT THAN 2 DAYS OLD J

e "All" Callback option provides a list of all Open Tickets, in alphabetical order, that need extensions

Next Customer - Key next Customer Name at which the Callback list should begin Press | ENTER The list will appear. -OR-

Customer Name - Displays name of rental customer.

Ticket - Displays ticket Number An extension flag (*) indicates ticket has an extension date that is more than 2 days old Definitely make all extension flags a priority¹

Current Ext. Date - Displays current extension date of specific rental ticket

Callback Type - Key X to select Callback Detail Record to display B/S (Body Shop), ADJ (Adjustor), SVC (Service), and CST (Customer). A "#" by a Callback Type indicates a message has been left at that Callback Source (Body Shop, Adjustor, etc.). Press 1 ENTER | The-selected Callback Detail Screen will appear.

Customer Ext Date - Displays customer extension date of specific rental ticket. to move cursor to top right of screen. To print a copy of the Service Selection Screen, key Y=Yes, over default N=No.

Leminder! Use your roll-up and roll-down keys scroll backward or forward through the Open Ticket stings.

Continue to the next page and learn how to select the "By Name" Callback option.

Page8 - 15 Λ

le Callback-Incomplete Reservations Screen alphabetically lists all reservations marked as incomplete lien the reservation was originally opened. Reservations are selected from this list to make contact ith the customer and complete the reservation, as needed.

Next Customer - Key next Customer Name at which the Callback list should begin Press | ENTER The list will appear.

Customer Name - Displays name of rental customer

Date - Displays pickup date of rental vehicle.

. Pickup Time - Displays pickup time of rental vehicle.

. Status - Displays rental status - W IN (Walk In), DEL (Delivery), P U (Pickup), CWC (Customer Will Call).

. Car Type - Displays rental vehicle size.

'. Rental Type - Displays rental category - 1 (Insurance), B (Body Shop), D (Dealership), R (Regular), C (Corporate), O (Other).

I. I ⁽ ' I to move cursor to top right of screen. To print a copy of the Incomplete Reservations Screen, key Y=Yes, over default N=No.

Reminder! Use your roll-up and roll-down keys to scroll backward or forward through the Incomplete Reservation listings.

Turn to the next page and learn about the Callback - No Show Reservations!

Page 8 - 17 ACTION KEYS FOR OPTION 12 - CALLBACKS

id on the bottom portion of each screen are several Function (F) keys Each one performs a tion that may be used while creating or viewing Callbacks

^: Cust List Displays a list of customer names and numbers that are to be used for billing purposes.

^: Exit or Main Menu Allows you to exit the program or return to the Main Menu Screen.

'ID List Displays a list of ID numbers for individual adjustors, agents, etc. for each customer number.

= Open Ticket

Displays the Open Rental Ticket for any rental background information.

= Chgs To Date

Displays the total number of rental days, total dollar amount, less deposits, and balance owed.

= AAJ Allows access to the Inquiry Programs.

= Update Tkt Allows you to update Open Rental Ticket information such as claim numbers, shop name, etc., as needed.

= Callback Notes Allows you to key additional information. 0 = Receipt Depos ^' Allows you to update payments on Open Rental contracts

2 = Previous Return to previous screen.

3 = Insurance Allows you to key renter insurance information.

4 = Credit Check Allows you to key credit check information. 5 = Reservation Allows you to continue to the next reservation.

Congratulations! ou have sucessfully completed the entire Callback Exercise. Now, you are ready to update ve Open Rental Tickets at your Office!

Page 8 - 19 ΕRCISE 9 CLOSING A TICKET exercise will guide you through Option 5 - Closing a Ticket. Close the ticket from Exercise 2 - Open ;ket, Calendar Day.

Option # 5 and the Daily Rental Ticket Number on the ECARS Training Menu. | ENTER | The iwing screen will appear.

Screen 1

ere are 5 basic sections to Screen 1.

Closing Ticket #: This section displays the DR Ticket Number, Renter Name and the Date and Time the arges end. The current date and time are provided by the computer, but can bechanged by keying over date awn.

Mileage: This section requires the Starting and Ending mileage for each unit, along with Fuel Charge, isc. Charges, etc.

BUI To: This section allows you to key or delete billing information as necessary. Also displays Current tension Date from callbacks.

Billing Dates (If different): This section allows you to key billing dates if they are different from the rtual dates of the contract.

Page 9 - 1 tion 1 - Closing Ticket #

JLOSING TICKET* 999010 For Renter SMITH* ROBERT* '

2 Charges End On Date 062494 Time 1102 AM ^' i

Nerify the Ticket # and Renter Name

The length of this rental is determined by the current extension date If necessary, adjust the date by eying directly over the information displayed.

)TE: If ticket is close pended, this date may not be changed You will need to unpend the ticket jrderto change the date.

:tion 2 - Mileage

Llβage 1 ait E00326 start 25O0 End 2599 9 Unit Start End ni ,-- Start End - "Onxt ^ Start End

2 uel Charges δ -7.00 Pet RENTAL Amount. To Be Charged 00 ast Unit Returned .Here _ Or To 3 3 Drop charge .nn iac Charges/Refundable Expenses _ (X If applicable) SURCHG .00 /DAY.

.X

Key the Starting and Ending Mileage for each unit.

Key the Fuel Charge as designated by your Group. Each Group will have a standard fuel charge.

This vehicle has been "dropped" at another Group Branch. Key in the Group/Branch Number

OTE: You may see an error message requesting the mileage be confirmed Because this is a training ogram, you may key an "X" in the selection field for mileage confirmation without updating any files. >r everyday branch use - you must verify the mileage you keyed is correct before confirming that mileage.

sction 3 - Bill To

__ _^ ^

3111 To (Y/ΪH Y Cust# 999999_ Hame YOUR NAME** j

Address 555 SOMEWHERE LANE ,

City Anytown ST MO 2ip 12345 ID/Attn 999 CHARLIE BROWN I

Curr Ext 06/24/94 per LNC I

^rerify the billing information. This information may be updated/changed/deleted if necessary.

Page 9 - 3 creen 2

;reen 2 breaks down all charges and displays the grand total. Use this screen to write >wn all charges on the rental ticket when the customer returns the vehicle.

1. Accept or Recompute (when adjustments are needed).

2. Four rate sections. Displays beginning and ending date/time of each rate change.

3. "Number of Miles, rate per mile, total amount of overmileage

4. Number of Hours, rate per hour, total hourly charges.

5. Number of Days, rate per day, total daily charges.

6. Number of Weeks, rate per week, total weekly charges.

7. Number of Months, rate per month, total monthly charges.

8. Number of Days, rate per day, total DW charges.

9. Number of Days, rate per day, total PAl charges.

0. Number of Days, rate, total Special rate.

1. Sales Tax rate and total.

2. Fuel Charge. L3. Drop Charge.

[4. Discount percentage and total. LS. Miscellaneous Charges. 16. Grand Total. .ey "A" 1 ENTER \ to accept the charges and advance to Screen 3.

iiig i i υ cuui t ~ \__^**» «»%»M.# *_***

Screen 3 - continued

.OSING TICKET # 999011 For Renter SMITH* ROBERT*

>tal Charges 89.95

_*ess Deposits .00 0 # Of Deposits jess Amount Billed To 89.95 Your Name** ilance Due (^"l0.05 ^") Refund attlemβnt Of Balance Due aid ^^00 By Cas£ϊ

.00 By Check

.00 By Credit Card ill .00 To Cust# A/R Description ill .00 To Cust# A/R Description ill ,00 Kame <Last*Firεt* ) TTL

Attn

Street City ST Zip

Hoiae Phone 000 000 0000 Office Phone 000 000 0000 A/R Description .

Jvarge . .0000 TToo AAccccoouunntt _ Unit # Desc Charge . .0000 TToo AAccccoouunntt Unit # Desc t fuή ~TOTθ^"5 By Cash X δr ^"cSeck 1

01053 Apprvl

Apprvl

e total charges for this rental ticket are shown There is also an amount that is to be billed to a third "ty - Your Name. An amount due may or may not be shown

there, is an amount due, key the amount in the field before "By Cash " Key your 5-digit Employee imber.

there is a refund due, key the refund amount next to "Refund" and X cash. Key your 5-digit nployee Number.

ENTER j to accept the information and close the ticket. RALPH will receipt the cash you accepted om the customer and bill the third party, Your Name, for their amount.

Page 9 -7 v, let's "unpend" the same 24 hour ticket previously pended

the ECARS Training Menu Screen, key Option 5 and the Ticket Number | ENTER dn, Screen 1 will appear tion 1 - Closing Ticket #

ΛSΪtfø TICKET* 060994 For Renter SMITH* ROBERT*

" ^" , Charges End On Date 061094 Time 09S0 AM

.leage ,. lit PP0027 JStart 0 End 150 ait Start End ύX ^" --\ - - Start End Onit Start End κsl "Charges 8 7.00 Per RENTAL Amount To Be Charged .00 is Unit Re urn Here x or o - - Drop Charge .'0Q

Lstt ~Charge«/Refuhdable Expenses _ (X if applicable)

tø 2-Cst-Ls

Smd4-ID Lst ,.Cιad6=Callback Detail Cmd7=AAI Cmd8=Accident Rpt Cmd9=ϋn-Peπd

ess CMD 9 | to "Unpend" the ticket ey your Employee Number in the Emp# field. Press |ENTER| to confirm that you -wish to unpend the ;ket. The ECARS Training Menu Screen will return.

Turn to the following page to close the 24 hour ticket as normal.

Page 9 -9 Screen 2

;reen 2 breaks down each rate charged on the ticket. ey an "A" to accept the charges. Write down the charges on the rental ticket if available.

INTER I to advance to Screen 3.

Exit to Main Menu.

CMD 3 I Restart.

AAI. Access Inquiry Programs.

Page9 - ll Check Refund Request

HECK REFUND REQUEST

IENTER: SMITH* ROBERT* 123 MAIN STREET ANYTO N MO 63124

Unount: 78.26

?ay To:

Cust # 999999

Name .SMITH* ROBERT*

Address

123 MAIW STREET_ ANYTOWN MO 63124 0000

Reason overpayment - $200. 00 deposit .

Special Instructions

Hold Check - Customer will pick up .

■mdl=Exit Cmd7=AAI

ιe name and address of the renter will be displayed along with the amount of the refund.

If the check should be made payable to another party, key the information in the Pay To section.

, Key the Reason for the refund (overpaid, etc.). . Key any Special Instructions (customer will pick up check, -etc.).

ENTER 1 to accept the information and close the ticket.

CMD 1 I Exit to Closing Ticket Screen 3.

CMD 7 AA1. Access Inquiry Programs.

Page9 - 13 ERCISE 10 CASH MAN A GEMENT

Cash Management Option - Option 15 on the ECARS Training Menu - provides important rmation regarding Credit Card and Check approval procedures It also includes a cash summary ion that will allow you to balance the summary created while you opened and closed rental tickets in previous exercises.

the ECARS Training Menu, key Option 151 ENTER] The following screen will appear

CCRT15-01

CASH MANAGEMENT

1. Credit Card Approval 2. Check Approval 3. Cash Summary

Cmdl'-Exit Cmd7-AAI Cmdl2=Previous

;y Option 1 - Credit Card Approval | ENTER] . Carefully read the two screens displaying credit card proval "Things to Know".

3 the same for Option 2 - Check Approval. Become familiar with the ]CMD 10 1 = CC Approval and MD 11 ]= CK Approval windows, then move onto Option 3 - Cash Summary.

CMD 1 Exit to Main Menu.

CMD 7 AAI. Access Inquiry Programs.

CMD 12 Previous Screen.

Page 10- 1 SH & CHECK SUMMARY - Selection 1, CASH/CHECK REVIEW

Key your Employee Number.

KLey an "X" in the Cash/Check Review selection field. ENTER I The following screen will appear

is screen displays all cash and check transactions. Cash transactions are noted with a cash symbol ($) the right of the dollar amount.

Line Number.

Customer Name.

Customer Number.

Document or Unit Number.

Branch #.

Credit Account 2200 Amount

Credit Account 2210 Amount.

Other Account Number (any Account Number other than 2200 or 2210)

Other Amount (corresponds to Other Account Number keyed in field #8)

Total Cash.

Total Checks.

Cash/Check Summary Total.

Gpbr Number.

Summary Date.

Line #. Key a line number in this field to automatically roll screen to that line

ENTER I to return to the Cash Summary Menu.

CMD 1 I Exit to Cash Summary Menu.

CMD 7 I AAI. Access Inquiry Programs.

Page 10 - 3 SH & CHECK SUMMARY - Selection 3, CASH/CHECK DEPOSIT

Employee # 01053

**** CASH _ -CHECK SUMMARY *****

_ 1. Cash/Check -Review

. Key your Employee Number.

. Key an "X" in the Cash/Check Deposit selection field.

. Key Total Cash Box amount. This is the total amount of cash in your box, including the assigned cash box amount. Assigned cash box amounts vary from Group to Group. For this exercise, use the "Cash" total from the Cash/Check Review plus $100.00. . Key Assigned Cash Box amount - $100.00. i. Chits to Reimburse. There are no chits for this exercise. i. Chits to Remain in the Cash Box. There are no chits for this exercise. ^r. Key the Total Checks to be Deposited. For this exercise, use the "Checks" total from the Cash/Check

Review.

ENTER ] The screen will display a message verifying the cash and checks balanced and a copy of the 3ash Summary will print from the Plainpaper Printer.

I - Checks Balanced

There are several other messages that may be displayed when balancing the cash summary. For a full display of error messages, press the 1 HELP I key.

Page 10 -5 Congratulations! You have now successfully completed the ECARS Workbook!

ΌU feel uncomfortable with any of the options, or just feel you would like a little more practice, you y open and close tickets, switch units, change rates, etc. in the ECARS Training System until you feel l are ready to go "LIVE".

e following list of Error Messages are the most commonly seen while completing the ECARS Drkbook. You may refer to them any time you need a more detailed explanation than is displayed on : screen.

xept or Recompute?: Key A-accept or R-recompute to accept charges as they are, or make changes and recompute.

Jditional Driver?: The field for additional driver has been left blank. Key Y or N.

dditional Driver Name Required: The field for additional driver has been marked Y, but no name has been supplied.

harges Do Not Balance: The payments that have been keyed do not balance to the amount due. Only Balance Due amount should be receipted. onfirm Date/Time Out: Date and Time keyed is not the current date and time. RALPH needs confirmation.

Confirm Unit To Be Rented: Unit rented on another ticket or may be owned by another Branch in your Group. Always has a message explaining the problem.

>ate Out Invalid: Date out has been keyed incorrectly, or field left blank.

lental Type Invalid: Rental Type field has been left blank, or rental type keyed is not valid.

Center Name Invalid, Last*First*: Renter name has not been constructed correctly.

Time Out Invalid: Time out has been keyed incorrectly, or field left blank.

PageVm ARMS Context (CSD) C ι-

Application Areas

07/13/98

1.1.3.*

1.1.1.^* 1.1.2.* AA Office Information

AA Trading Partner AA Rental Systems Synchronization Between

Business Business Transactions Enteφrise and Trading

Transactions Partner

1.1.4.^* AA ARMS Support

jDUSiucss x i αiisαtuuu.

07/13/98

1.1.1.1.*

1.1.1.3.*

BT Request for 1.1.1.2.*

Authorization BT Manage Customer BT Manage Customer

Management by Remittance

Customer

Nu lun

■ -Return from Surcharge to - AM0046

1.1.1.1.3-23

PGM Generate . Return from AM1050 to -

Pseudo-Authorization Change 1.1.1.1.3-25 AM0O46

Transaction Data Set 1.1.1.1.3.26 gn Next 1.1.1.1.3.27(1/2)

(Approved GovtSurcharges) PGM Retrieve Next PGM Assi 1.1.1.1.3.28

(AMO096V1) Transmission Vendor PGM Create Return from AM1080 to elds PGM Generate AM0046

Control Id Number Transaction Id Sensitive Fi Transaction

(AM1099) (AMRVTSQ) Change Log Credits (AM1050V1) (AM1080V1)

DA Next Vendor Transaction Id , (AMSFQfiTI )

»-.υιuμuueuι mavigauoπ uiagram 07/15/98

Activity Modes Diagram 07/15/98

1.1.1.1.5.1.* 1.1.1.1.5.2 *

AUT Interface with AUT Interface with

ECARS Claims Connection

(AT/CN/EX/CM) (AT/CN/EX)

DS ARMS APPLICATION TRANSACTION DISTRIBUTED

DAT-RaSF FILES

1.1.1.1.3.13 PGM Generate External Error

(AM0090V1)

1.1.1.1.5.1.4

PGM Interface EC with

Customer Message

(EC00CMV1)

1.1.1.1.5.1.11(1/2) PGM Print

Reservation DetaH (CCRS10)

>nfkmatlon shutdown confirmation

Activity Modes Diagram

07/16/98

AXK

1.1.1.1.6.1.* 1.1.1.1.6.2.^* AUT Generate Claims AUT Generate ECARS

Connection Authorization Authorization Maintenance Maintenance Request Request

(AC/RA/RC/RE/RN/TR) (AC/RA/RC/RE/RN/TR/VM)

EC - ECARS 1.1.1.1.6-2-22

PGM Generate

Century for DOB

(UTS001Λ)

1.1.1.1.6.2.17

PGM Retrieve ARMS Vehicle

Class end Rate Designation

(AM1070V1)

1.1.1.1.62.7

PGM Generate EC

1.1.1.6-2.8(1/4) Authorization PGM Retrieve Maintenance ferJPJSii schtne Attn utes Request (RTVEMCHA) (EC00RAV1) 1.1.1.1.5.1.6(2/2) PGM Retrieve ARMS Data (AM2090V1)

1.1.1.1.3.19(1/4)

PGM Retrieve

Machine ID

(AM2050V1)

1.1.1.1.3.11(2/2)

PGM Validate Date and Convert Format

1.1.1.1.3.10(1/4) (CCDATE) PGM Perform Internal

Error Paging and Messaging (AMPSSR)

1.1.1.1.6-2.5 PGM Generate EC Authorization Confirmation (EC00ACV1)

RENTAL MANAGEMENT t-uπpuπeπi πavagauυu TRADING PARTNER Diagram

6/21/99

RDS

1.1.1.1.20.1 1.1.1.1.3.5

PGM AADRVR DTQ Input to

Program to AM0025

PASSTHRU to (DQAM25V1)

RARMS (AACHNG)

1.1.1.1.20.2 1.1.1.1.20.3 1.1.1.1.2.8

PGM Program to PGM USAA DTQ Input for Time start AACHGR Authorization Line Inquiry

(AACHNGA) Change (AACHGR) (DQAM70V1)

DS ARMS APPLICATION

TRANSACTION CENTRALIZED , - DATABASE FILES

MANAGEMENT I AUII la TRADING PARTNER PARTNER

:TR Trading Partner :TR Direct Bill Trading Partner

Sends Electronic 1.1.1.1.1.* Sends {Electronic Transmission

Transmission AUT Receive Transmission

1.1.1.1.2.*

AUT Validate AND DS ARMS APPLICATION

Unpackage (CommRcvr TRANSACTION CENTRALIZED

-AM20/AM21) DATABASE FILES

1.1.1.1.3 *

AUT Validate Transaction

(AM25 - AM46)

1.1.1.1.18 *

CR CASH RECEIPTS (A/R) AUT Dispatch

Customer

Authorization

Maintenance

Request

DS ARMS APPLICATION TRANSACTION DISTRIBUTED DATABASE FILES

I

TRADING PARTNER

:TR Trading Partner Sends Electronic Transmission

1.1.1.1.1.* AUT Receive Transmission

1.1.1-1.2.*

AUT Validate AND

Unpackage

(CommRcvr-

AM20/AM21)

1.1.1.1.3.^* DS ARMS APPLICATION

AUT Validate Transaction TRANSACTION CENTRALIZED

(AM25 - AM46) DATABASE FILES

1.1.1.1.4.*

AUT Send Transaction for

Distributive Processing

(AM100-AM101)

1.1.1.1.18 *

DS ARMS APPLICATION AUT Dispatch Customer TRANSACTION DISTRIBUTED Authorization Maintenance DATABASE FILES Request

NR NATIONAL

1.1.1.1.K* RESERVATIO

AUT Interface with

RA RENTAL Rental Systems APPLICATIONS (ECARS) (AT/CN/EX/CM) CN CLAIMS ► CONNECTIO

Business Transactions 07/16/98

1.1.2.1.* 1.1.2.2.*

BT Request for 1.1.2.3.* 1.1.2.4.*

BT Generate & Send

Authorization

Rental Maintenance BT Manage Vendor BT Generate &

Management by Send Electronic

Notification Messages

Vendor Billing Invoice and

Baton Extensions

1.1.2.5 *

BT Close ARMS Authorized Ticket

DS ARMS APPLICATION 1.1.1.1.7.*

TRANSACTION CENTRALIZED AUT Send Transaction DATABASE FILES for Centralized

Processing (AM106 -

AM 105)

1.1.1.1.3.*

AUT Validate Transaction

(AM25 -ΛM46)

1.1.1.1.8.* AUT Package Transaction into Transmission (AM120)

1.1.1.1.19.*

AUT Send

Transmission to

Trading Partner

Company

EE-1

RENTAL

MANAGEMENT

TRADING PARTNER

1.1.1.1.3 *

AUT Validate

Transaction (AM2S •

ΛM46)

1.1.1.1.8.*

AUT Package

Transaction Into

Transmission (AM120)

1.1.1.1.19.*

AUT Send

Transmission to

Trading Partner

Company

EE-1

RENTAL

MANAGEMENT

TRADING

PARTNER Activity Dependency Diaeram

11/17 98

CENTAL GWE

'LICATION

YSTEMS

:TR RentalΛppilcatJon Sends Electronic Request - Real Time

1.1.1.1.9.* AUT Dispatch Vendor

Authorization Maintenance Request

RA RENTAL

APPLICATIONS (ECARS)

1.1.1.1.6.*

AUT Generate Vendor

Authorization Maintenance

ARMS APPLICATION Request RANSACTION DISTRIBUTED (ΛC/RΛ/RC/REfftN/TR/VM ) ATABASE FILES

1.1.1.1.7.*

AUT Send Transaction for

Centralized Processing

(AM 106 -AM 105)

=E-5(1/2)

RENTAL GWE TIME

APPLICATION

RA RENTAL APPLICATIONS SYSTEMS (ECARS) terate aity Rental voices'- Batch TR Generate Claims

Connection Invodes - Real

Time

1.1.2.4.5.* )AT Generate voice - ECARS

I.1.1.1.9.*

AUT Dispatch Vendor

Authorization Maintenance

Request

DS ARMS APPLICATION

TRANSACTION DISTRIBUTED DATABASE FILES

1.1.2.4.3.' JT EdK Outbound

CN CLAIMS CONNECTION

1.I.2.4.2.*

1.1.1.1.7.* AUT Generate CC AUT Send Transaction Rental Bang Invoice for Centralized

Processing (AM106 •

AM105)

DS ARMS APPLICATION TRANSACTION CENTRALIZED DATABASE FILES

1.1.£..*. i.t Dm cnci nc vcπuui r^cqucsi lυi fuunuπέaiiuπ Cλ Jiisiun

Component Navigation Diagram 07/21/98

1.1.1.1.3.11

EE-3 PGM Validate Date

RENTAL and Convert Format

APPLICATION (CCDATE)

SYSTEMS

1.1.1.1.3.10

1.1.2.5.3.1 PGM Perform

PGM Calculate CC Internal Error Paging

CN CLAIMS CONNECTION Billing Charges for and Messaging

ARMS Tickets (AMPSSR)

(CCARMSV1)

07/13/98

1.1.3.1.* 1.1.3.2 * 1.1.3.3.*

BT Synchronize BT Synchronize BT Send Initial or

Office Information for Office Information for Yearly Car Class

X12 Customer Rates and Initail

Office Information for

X12 Customer

^ι. _^■_-._ on ι ϋeneraie Office Locat

Component Navigation Diagram

AXK

07/1*98

1.1.3.2.6.9 MOD Determine Company and Invoke Send SA

Updates (AML833A003)

!.6.6(22) UM ARMS d for Office dates 1.1.3.2.6.10 AMSEND I32A006) MOD Formal and

Send SA Updates

(AML833A004)

1.1.4 AA ARMS Support

1.1.4.1 ^* 1.1.4.3 * SA Manage SA Information Environment System Reports

1.1.4.2.* 1.1.4.4.*

SA Research and SA Tools Fix Problems

01/27/99 GWE

«ompoπeπι Jiavigaπoπ r-iagram

10/23/98

GWE

Activity Dependency Diagram 07/16/98

Component Navigation Diagram

1.1.4.4.1.17.*

1.1.4.4.1.18 *

ONL ARMS

ONL Generate Reservation Detail

Report of Errors Opt - by Company

Sent by a Trading Utilization

Partner on an Management Electonlc Invoice Reports

Screen Navigation Diagram 01/27/99 GWE

Component Navigation Diagram

1.1.4.4.118.2 11/03/98 GM ARMS System Control (AAMAIN)

114.4.8.111

PGM Transaction

Receive Log Inquiry

(CCAM12)

114.4.118.2 GM ARMS System Component Navigation Diagram Control (AAMAIN) 11/03/98

114.4.8.12.1

PGM Receive /

Billing Error Inquiry

(CCAM13)

Component Navigation Diagram

114.4.118.2 11/03/98

PGM ARMS System

Control (AAMAIN)

•*. 114.4.8.13.1

PGM Error Log Inquiry (CCAM14)

Ul/- /l»y l WH,

Component Navigation Diagram

114.4.118.2 11/03/98

PGM ARMS

System Control

(AAMAIN)

114.4.9.8.1

MNU Application

Development Data

Queue Menu

114.4.9.8.3

SCR Add a Data

Queue Entry

01/27/99 GWE

114.4.118.2 Component Navigation Diagram

PGM ARMS 11/03/98

System Control

(AAMAIN)

114.4.10.9.1

MNU ARMS/400

Training

Administration Menu

(A4TRNGMN)

Component Navigation Diagram 11/03/98

1.1.4.4.118.2

PGM ARMS

System Control

(AAMAIN)

114.4.10.10.1

PGM Vehicle Class /

Rate Table

Maintenance

(CCAM11)

ARMS Process Report

EXHIBIT C

ocess erarchical numeric ID: 1 ded name: me: ARMS Context (CSD) mment: ©Definition: Automated Rental Management System is the electronic data terchange (EDI) application and communications bridge between the Enterprise Rent

Car rental applications (ECARS-Enterprise Computer-Assisted Rental System and aims Connection) and the application systems used by Rental Management Trading rtners (mostly insurance companies using ARMS/400, a VAN - Value-Added Network, o: eir own in-house application) and Direct Billing Trading Partners.

©Purpose: To accept EDI transmission envelopes from the trading partnen package the transmissions, perform transaction data set edits, route to the propriate distributed rental location's rental application system host computer atform and update the rental application database with the EDI transaction's formation. To also, generate transaction data sets from the rental applications r sending to the trading partners.

©Notes : ARMS has a centralized data store for progressive transaction ily work files, received and sent transmission logs, error logs, billing logs, αtal transaction database of information passed to date, trading partner ansaction/rental transaction cross-reference, and trading partner profile files. *.S has a distributed data store for transaction daily work files, error logs, ading partner transaction/rental transaction cross-reference and a subset of the plicated images of the centralized trading partner profile files.

Also, the current transaction formats processed with some trading rtners and within the majority of the ARMS software are using documented ^• sprietary EDI transaction data set formats and transmission envelopes. However, ne trading partners are exchanging information using ANSI (American National andards Institute) X12 EDI standards for the 272 Rental Management transaction rmat that require translation to and from these proprietary EDI transaction data b formats, mapping, repackaging/unpackaging, and communication using an installed Lrd-party software package, Any EDI integration software's "EDI Integrator".

acess

-irarchical numeric ID: 1.1 led name: ne: BA Automated Rental Management System ranent: ©Definition: This is a rental business area application system software t of processes that allows Automated Rental Management, rental reservations, rent. nation and rate maintenance notifications, invoice billing and electronic funds ansfer (EFT) remittance advice transactions via EDI (Electronic Data Interchange) nmunications to be routed between trading partners and rental application and lancial software systems within Enterprise Rent-A-Car.

_cess srarchical numeric ID: 1.1.1 led name:

Confidential Page 1 of 246 8/11/00 ARMS Process Report

AA Trading Partner Business Transactions it: ©Definition: This application area represents all EDI transmissions tha /ent from the EDI Rental Management Trading partner users to be routed to the ributed application system for: creating rental reservations; perform rental payment authorization maintenanc for a current rental contract or reservation; or, messages to the rental bran

/ office staff. Also, will process received electronic remittance advice detai in response to electronic billing invoice for a closed rental contract that they had authorized payment to be routed to the Cash Receipts financial application system.

ocess erarchical numeric ID: 1.1.1.1 ded name: me: BT Request for Authorization Management by Customer mment: ©Definition: The set of automated activities that are used in the eation of reservations and maintenance of the rental payment/direct billing thorization from an EDI transmission received from the Rental Management Trading rtner.

©Purpose: To allow the Rental Management Trading Partner an electronic ans of creating rental reservations and managing their rental payment/direct lling responsibility authorization information for a vehicle rental.

ocess erarchical numeric ID: l.l.l.l.l ded name: me: AUT Receive Transmission mment: ©Definition: This represents any of the external (not between the ltiple Enterprise Rent-A-Car AS/400 computer systems) connection-specific munication receiver programs that receive communication transactions from an ectronic data interchange (EDI) trading partner or their VAN - Value-Added Networ rvice provider.

, ©Operational Method:

This program requests a program start from company,^' then continuously ceives data f om company until a record with *DOWN is received indicating that th s the last transmission before the trading partner's sender program shutdown. Fo ery non-shutdown transmission received, a data queue entry is sent to DQAM70V1 so at the received transmission is placed into the Received Transmission Log file MTRNLOG) as an audit trail and then the transmission is then output to the nnection-specific received transmissions for either production or test purposes rk file (AMxxxxxn, where 'xxxxx' is the PROFILE ID of the trading partner or his lue-added network for production or testing, and 'n' is the version number - rrently all are the value ' 1 ' ) .

©Notes: Each direct connect trading partner or VAN (Value-Added Network S a PRODUCTION PROFILE ID and a TEST PROFILE ID.

ocess erarchical numeric ID: 1.1.1.1.1.1 ded name: AMzzzRCV (zzz = Root of Van ID) me: PGM Receive Proprietary Transmission (AMzzzRCV)

Confidential Page2 of246 8/11/00 ARMS Process Report vment: ©Purpose: To receive proprietary EDI transmissions from any ARMS- mected VAN (Value-Added Network) .

©Operational Method:

This program is evoked by a VAN'S sender and then continuously awaits an :eives data from the VAN until a record with *DOWN is received.

The input is logged and put in the appropriate receiver file.

For any program exception error, the *PSSR subroutine is executed to DUM s current program and if the return code is equal to 8196 and the current time is side of the 11:00pm - 3:00am time interval, call AMPSSR program to send a pager isage to the ARMS primary and backup On-Call pagers so that manual intervention ma initiated.

©Notes: For specific ICF operations, see the record formats in the IICF file that this program uses for input.

The "real-time" receiver job abnormally ends execution when the VAN'S itdowns their communication environment at 1:00am nightly, 12:00am Sunday. This >gram would normally end when receiving a *DON request after having sent the VAN ?OP request command from the AMST0P2R program executed nightly at 12:50am. Any lormal halts or ending of the production communication receiver job during their leduled operational time currently notifies the ARMS On-Call staff in order that ;y may manually intervene to notify any ARMS-connected VAN to attempt to restart Ϊ critical communication process job.

>cess ϊrarchical numeric ID: 1.1.1.1.1.2 led name: CLL818 ae: PGM Set Environment to Receive Proprietary Batch Transmission (CLL818) rnient: ©Definition: This is the ARMS Trading Partner Company - to -ARMS..receive

IS-connected Value-Added Network batch communication driver program (written in

'400 - Original Program Model) .

©Purpose: This; program's purpose is to set up the environment and call . necessary program to receive an electronic data interchange' batch transmission relope formatted in Enterprise Rent-A-Car 's ARMS- proprietary EDI formats, over ε ilup communication line, to IBM ARMS-connected Value-Added Network electronic nmunication network mailbox. This mailbox contains one or more transmissions -ended to be received by ARMS, sent from the ARMS Trading Partner Company's rance Claims Management application system's associated batch sender nmunications programs on their IBM mainframe computer network system.

©Operational Method: ■ ^{' '}■^■

- This program is delay until 7:00am prior to any further processing.

- The next step is to vary on (activate) the ARMS-connected Value-Added ;work communication line, EDI controller (includes all downline attached figuration elements) and the EDI integration software device if any of these nmunication elements are found to be not ready.

- Add EDI integration software library to the batch job's library list.

- Then for a production batch receive, call/execute program AM***RCB wil rameter '***01' (ARMS Trading Partner Company production Profile ID) to Receive

Confidential 7 ^'. Page 3 of 246 8/11/00 ARMS Process Report j Trading Partner Company Receive Batch file via ARMS-connected Value-Added twork with EDI integration software. This will write all records to ARMS Trading rtner Company Receive file and ARMS Receive Log file and send all records' ansmission key value to the any ARMS Trading Partner Company Receiver Data Queue.

- The next step is to copy the records from the AM***RCB ARMS Trading trtner Company Received Batch Transmissions file to an archive file, AM***RCBSV anc an clear the AM***RCB file.

- Repeat the call /execute, copy and clear for testing using the rameter 'T***T' (ARMS Trading Partner Company test Profile ID) .

©Notes: Runs on the centralized ARMS application host computer system ze per day, Monday through Saturday, after ARMS Startup's Restore Unprocessed ansaction batch job (L814) has completed, regardless if holiday. Scheduled via BOT/Scheduler REACT mode.

This program was created by the ETD- Emerging Technologies Department's Drmerly Advanced Technologies Department) EDI project team, but is currently intained primarily and the responsibility of the ARMS Application Development partment. This program is used to receive a batch transmission envelope that migl αtain the following Enterprise ARMS proprietary EDI transaction sets: Authorizati( Lntenance (AT-Add and AT-Change) , ER-Error, and PM-Payment Advice.

©Files : (CRUD)

- AM***RCB (-R-D)

- AM***RCBSV (C )

Dcess erarchical numeric ID: 1.1.1.1.1.5 led name: AM***RCB τιe: PGM Receive ARMS-connected Value-Added Network Batch for specified ARMS Tradii rtner Companies (AM***RCB)

Timent: ©Purpose: This program's purpose is to receive an electronic data terchange batch transmission envelope formatted in Enterprise Rent-A-Car 's ARMS- oprietary EDI formats, over a dialup communication line, to IBM ARMS-connected lue-Added Network electronic communication network mailbox. This mailbox contain! e or more transmissions intended to be received by ARMS, sent from the specified MS Trading Partner Companies Insurance Company's ARMS-interfacing application stem's associated batch sender communications programs on their host computer twork system.

©Operational Method: This program is used to receive a batch transmissii velope that might contain the following Enterprise ARMS proprietary EDI transactii ts : Authorization maintenance (AT-Add and AT-Change) , ER-Error, and PM-Payment vice. It will retrieve the EDI integration software Profile record for account RAC and user ID 'ERACARM' from the IEPROFL IBM EDI integration software User ofile File, load the externally-defined local data area with program execution try parameter values, and call the IBM EDI integration software licensed program oduct EDI library's IEIFEXEC main program for IBM EDI integration software BASE, is program will then read the IEIFEXEC program's output AM***SNB file records, th re "pulled" from specified ARMS Trading Partner Companies' send to ARMS mailbox o e IBM ARMS-connected Value-Added Network electronic communication network. Any oduction transmissions will be written to the AM***011 specified ARMS Trading rtner Companies production received transmission output file and its key sent to e DQ***011 specified ARMS Trading Partner Companies' Received Transmission Input ta Queue to its specific AMOOIOVI program for transmission envelope validation. A

Confidential Page 4 of 246 8/11/00 ARMS Process Report

3t transmissions will be written to the AM***011 specified ARMS Trading Partner npanies production received transmission output file and its key sent to the p***T specified ARMS Trading Partner Companies Received Transmission Input Data ≥ue to its specific AMOOIOVI program for transmission envelope validation. For ≥ry input transmission record format received, each record format is written to tl Les AMTRNLOG (transactions received audit trail) and to file AMxxxxxn and sent to a queue DQxxxxxn (company 'xxxxx' and version 'n' specific) for either productioi k**0i^») or test ("T***T") purposes. For any program exception error, the *PSSR ^routine is executed to DUMP the current program and call AMPSSR program to send _< jer message to the ARMS primary and backup On-Call pagers so that manual ;ervention may be initiated.

©Frequency: Once per day, Monday through Saturday after ARMS Startup's ϊtore Unprocessed Transaction batch job (L814) has completed, regardless if Liday.

©Notes: This program is called twice within a batch job's driver CL jgra , CLL818 ETD: ARMS Trading Partner Company Receive Batch program that runs oi Ϊ centralized ARMS application host computer system. The first occurrence for th: }gram execution with entry parameter to cause the program to perform only receive msmissions for the ^«***01" ARMS Trading Partner Company production processing, ϊ second program execution with entry parameter "T***T" to cause the program to rform only receive transmissions for the "τ***T" ARMS Trading Partner Company test icessing. See documentation for CLL818 to determine when processed.

This program should be processing only when the pair of any ARMS- mected VAN communication sender program is active and the centralized ARMS plication host computer system and its ARMS subsystem is active. Usually should ] operation from 3:00am to 1:00am, Monday through Tuesday and on Sunday from 7:30aι

11:00pm.

This program was created by the ETD- Emerging Technologies Department's jrmerly Advanced Technologies Department) EDI project team, but is currently Lntained primarily and the responsibility of the ARMS Application Development jartment. This program is used to receive a batch transmission envelope that mig] itain the following Enterprise ARMS proprietary EDI transaction sets: Authorizati Lntenance (AT-Add and AT-Change) , ER-Error, and PM-Payment Advice.

}cess ϊrarchical numeric ID: 1.1.1.1.1.6 led name: EDMRLUA ne: PGM Receive LU 6.2 Transmission (EDMRLUA) nment: ©Definition: This is the ARMS Receiver LU 6.2 communication program.

©Purpose: This program's purpose is to receive an electronic data terchange transmission envelopes formatted in CIECA drafts for ANSI X.12 standard £ formats, over a leased communication line, with an ARMS Trading Partner Insuram npany's automobile claims application system's associated sender communications Dgram on their host computer network system.

©Operational Method: 1. Capture job attributes and set up library list, aug options, logging, traces, etc. 2. Retrieve parameters from data area with th ne name as the job = same as the device description. (This allows control of rious options without requiring that the initiator of the APPC ALLOCATE send rameters to control them.) 3. Set up communications line trace and/or ICF trace . ≥cified. If the current user does not have sufficient authority, proceed without aces. If any other trace error, proceed without traces. 4. Execute either the ESYS/STRCTLSCRB (API: Start ctl script to call ARMS-connected Value-Added Network

Confidential Page 5 of 246 8/11/00 ARMS Process Report the EDISYS/STRRCVTRNB (API: Start ctl script; rev/unwrap/transmission) command Lng appropriate parameters.

©Frequency: Heavy utilization between 6:00am - 3:00pm (all times are itral time zone), Monday through Friday, especially at 6:00am receiving batch bur. scheduled invoice payment advice (PM) transaction set transmissions. Additional ivy utilization from 10:00pm - 10:10pm receiving batch burst of scheduled invoice (Tnent remittance advice (RM) transaction set transmission batches. Moderate Llization between 7:00am - 9:00am and 3:00pm - 7:00am Monday through Friday. Ligl Llization on all other active times, including weekends and holidays.

©Notes: This program was created and is maintained primarily by the ≥rging Technologies Department (ETD - formerly Advanced Technologies Department) C project team. This program is used to receive all real-time business-event ansaction data tranmission sets for production or test information interchange. Ls is running as a prestart job because this will enable the programs involved in Is job to be pre-started so that the programs and their resources remain open and tive since each trading partner evokes the communication session each time they ad a transmission envelope.

©Process Frequency: This program is used within two never-ending prograi ≥start batch jobs on the centralized ARMS application host computer system. One o is LxxxxxlR (where xxxxx is the full ARMS Company Profile ID) that executes KXXRCI (where xxxxx is the full ARMS Company "root" Customer ID)- ETD: EC/EDI: MS X.12 Trading Partner Receiver Communication for Production. That program is arted by remote via an APPC MC_ALLOCATE. In order for APPC (Advanced Program-to- ogram Call) to trigger it properly, there should be a communications entry in the γ EDI integration software subsystem which associates the device or remote locatii

JOBD EXCMNJOBD and user EDIOWN. This program can be executed from either a estart job command within the AM***COMP (where *** is the Profile ID root value) ogram or by an ARMS subsystem "prestart" job that executes ED***RC1 program, that lls/executes this EDMRLUA program with a single entry parameter for the ARMS ofile ID value to cause the program to perform "receive" production transaction ocessing. The other job, ED***RCT, executes this program with entry parameter ***X' will cause the program to perform only "receive" test transaction processing e production receiver job starts execution at usually on Sunday at 8:00am and sta; tive 24 hours per day through Saturday at 1:00am in order to do RARMS mirrored stems role swap when this "real-time" receiver job is normally ended. Any ception.. errors or abnormal ending that occur during the execution of the products mmunication receiver job on the centralized ARMS application host computer system ring their scheduled operational time currently causes the notification of the ET d ARMS primary and backup On-Call staff pagers. This is done so that they may nually intervene to attempt to restart the critical communication process job.

©Data Areas: (CRUD)

- EX I I Company Id (-R--) (in EDI integration software system library)

- EXDBG (-R--) (in any EDI integration software- system library)

ocess erarchical Numeric Ed. : 1.1.1.1.1.7

■ded name: ΞDMRMQA me: PGM Receive Alternate Protocol Transmission (EDMRMQA) imment: ©Definition: This is the ARMS Receiver for alternate protocol immunication program.

©Purpose: This program's purpose is to receive X12 standard EDI formats ^rer a leased communication line, with ARMS Trading Partner Insurance Company' s

Confidential Page 6 of 246 ^: 8/11/00 ARMS Process Report

.omobile claims application system's associated sender communications program on ϊir host computer network system.

©Operational Method: 1. Capture job attributes and set up library list, >ug options, logging, traces, etc. 2. Retrieve parameters from data area with the ne name as the job = same as the device description. (This allows control of rious options without requiring that the initiator of the APPC ALLOCATE send ra eters to control them. ) 3. Set up communications line trace and/or ICF trace e scified. If the current user does not have sufficient authority, proceed without ices. If any other trace error, proceed without traces. 4. Execute either the -SYS/STRCTLSCRB (API: Start control script to call ARMS-connected Value-Added :work) or the EDISYS/STRRCVTRNB (API: Start control script; receive/unwrap insmission) command using appropriate parameters.

©Notes: This program is maintained by the ETD and is used to receive al] il-time transaction sets for production or test environment. As of July 6, 1998, has not been put into regular scheduled daily use because a specified ARMS EEDI iding Partner Company's application changes to exchange with ARMS has not yet beer Dlemented.

3cess

≥rarchical numeric ID: 1.1.1.1.1.8 led name: EDMRUWA ne: PGM Unwrap Envelope (EDMRUWA) ment: ©Purpose: To unwrap, received X12 EDI Transmission Envelope.

©Operational Method:

- Receive and unwrap an electronic data interchange transmission enveloj rmatted in ANSI X12 standard EDI formats.

- For any program exception error, the ATDPSSR and AMPSSR programs are Lied to send a pager messages to the ETD and ARMS primary and backup On-Call page. that manual intervention may be initiated.

,,; ©Notes: This program is maintained by the ETD. This program is used as ver-ending program batch job on the centralized ARMS application host computer stem.

Currently used to receive transmissions over a leased communication lim th ARMS Trading Partner Insurance Company's automobile claims application system' i sociated sender communications program on their mainframe computer network system sed in Boston, Massachusetts.

ocess erarchical numeric ID: 1.1.1.1.1.9 ded name: EDLRMIA me: PGM Receive Mapper Interface (EDLRMIA) mment: ©Purpose: To drive and control the translation of the X12 EDI formats e incoming transmission to proprietary formats.

©Operational Method:

- Declare programs variables

Confidential Page 7 of 246 8/11/00 ARMS Process Report

- Change the Any EDI integration software communication script name to i passed input parameter field value for COMPANY ID

- Allocate the receive interface files

- Wait for EDI transaction envelope

- IF transactions have been received, execute the any EDI integration itware's Start Translate Connections Command to search for Log of Connection :ords which are eligible for incoming translation.

- IF translation error encountered. Notify ETD and ARMS on-call iff and end job.

- ELSE, Call the ARMS EDI Receive Interface program to write >lication records.

- IF program is running in debug mode, Copy receive interface file- their save files.

- Clear the receive interface files ELSE, (transactions have not been received)

- Deallocate receive interface files.

- Send shutdown data queue entry to the receive unwrap input data ϊue.

©Notes: This program was created and is maintained primarily by the ≥rging Technologies Department (ETD - formerly Advanced Technologies Department) E project team. This uses the any EDI integration software's mapping/translation Llity third-party software package.

This program is submitted as a called never-ending program batch job wit ≥ job name 'LxxxxxlRM' (where "xxxxx" is the Trading Partner Profile ID) and ≥cifies using the any EDI integration software system library's EDISFTWJOBDP job scription on the centralized ARMS application host computer system by the «r**oιiR' receiver job with the following input parameters:

5 Alphameric COMPANY ID

1 Alphameric DEBUG FLAG (possible values: ^πY" (Yes) or "N" (No)

(12/17/98) ^{• )}>

This object which is used in the receive mapper job has been changed to Lay until midnight at shutdown before sending a shutdown data queue entry to the :eive unwrapper job. This change was necessary because transactions received bween 11:45 p.m. and midnight would not get functional acknowledgements sent back ARMS Trading Partner Insurance Company and would not show up on our daily porting because the receive unwrapper job wasn't active until midnight.

ocess erarchical numeric ID: 1.1.1.1.1.10 ded name: EDZRCUA me: PGM Get Mapped Data (EDZRCUA) mment: ©Purpose: This program's purpose is to check if any ANSI X12 EDI data h en received. This program also checks for shutdown. ©Operational Method:

This program is a called program that accepts three (3) parameter field mpany Profile ID (input-5 alpha) , Shutdown Flag (output-1 alpha) and Transactions ceived Flag (output-1 alpha) .

When executed, initialize the SCRIPT ID with the passed COMPANY PROFILE value concatenated with "R" (Receive) .

Default load the TRANSACTIONS RECEIVED FLAG to "N" (No) .

Confidential Page 8 of 246 8/11/00 ARMS Process Report

If the passed COMPANY PROFILE ID is a production profile (ends in "1") , sn change the receive mapping data queue name to 'DQ' + the first three characters the company ID + 'RM1*. Else, change the receive mapping data queue name to 'DQ' .he second through fourth characters of the company ID + 'RMT' . Then continue the .lowing processing until data has been received and mapped or a shutdown data quei. :ry has been received.

Receive a data queue entry from the receive mapping data queue on finite wait. Once a data queue entry is received, change the receive data queue sration from infinite wait to 15 seconds.

Attempt to retrieve records from the Any EDI integration software inection Log logical file by SCRIPT ID with Unwrapped Receive Status. If there ai :ords, change the output transactions flag to 'Y' (Yes) .

If the data entry received is ' *DOWN' , then load the SHUTDOWN FLAG rameter with 'Y* (Yes) and end the program.

For any program exception error, the *PSSR subroutine is executed to DOT i current program and call AMPSSR program to send a pager message to the ARMS .mary and backup On-Call pagers so that manual intervention may be initiated. JO, write the transaction the program was processing to the ERRORS file.

©Files: (CRUD)

- EXLLCPPR (-R--) * Any EDI integration software Connection Log 1 :ipt Name with Unwrapped Receive Status

(in EXTSYSF Any EDI :egration software EDI Integrator Files library.)

- ERRORS (C ) * Errors Log (User-Controlled Open)

©Notes: This program is maintained by ETD. This program is used withii > never-ending program batch jobs on the centralized ARMS application host comput* stem. One job executes this program with entry parameters to cause the program tc rform only "receive" transaction processing, the other job executes this program ;h entry parameters to cause the program to perform only "send" transaction icessing. The receiver jobs usually start execution at Monday through Saturday al -0am and- Sunday at 1:30pm. The "real-time" receiver jobs abnormally end executio. in the EDI trading partners shutdown their communication environment at 11:00pm. ≥se programs will normally end when receiving a *STOP request from the AMSTOP2R jgram executed nightly at 12:50am. Any abnormal halts or ending of these jobs ring their scheduled operational time currently notifies the ARMS On-Call staff i. ϊer that they may manually intervene to attempt to restart the critical nmunication process job.

Dcess

≥rarchical numeric ID: 1.1.1.1.1.12 ied name: AM***COM ne: PGM Receive/Send Proprietary Transmission for ARMS Trading Partner Company

»l***COM) nment: ©Definition: This is the ARMS-to-ARMS Trading Partner Company (and vice rsa) SNUF (SNA Upline Facility) (IBM) 3270 terminal emulation device API ansaction-based (triggered) communication program.

©Purpose: To receive or send an proprietary EDI formats, over leased MS-connected Value-Added Network lines, with the ARMS Trading Partner Company

Confidential Page 9 of 246 8/11/00 ARMS Process Report turance Company's Insurance Claims Management application system's associated ider and receiver communications programs on their host computer system.

©Operational Method:

This program requests a program start from company, then continuously lits and receives data from ARMS Trading Partner Company's computer system until ε :ord with *DOWN is received.

When input is received, each record is written to the files AMTRNLOG ransactions received audit trail) and to file AMxxxxxn (Company Profile ID 'xxxxx' I Version 'n' specific) for either production or test purposes.

For any program exception error, the *PSSR subroutine is executed to DOT Ϊ current program and call AMPSSR program to send a pager message to the ARMS .mary and backup On-Call pagers so that manual intervention may be initiated.

©Files: (CRUD)

- ARMSPR1 (-R--)

- ARMSPR3 (-R--)

- AM***011 (C--) (specified as ANDUMPRD)

- AMT***TT (C—) (specified as ANDUMTST)

- AMSEND (-R--)

- AMTRNLOG (C )

- AMSNDLOG (C )

©Notes : This program is maintained by ETD.

_>cess

≥rarchical numeric ID: 1.1.1.1.1.13 led name: EDxxxRCl ne: PGM Prestart Job by Company for LU6.2 (EDxxxRCl) . ,-, nment: ©Definition: These are any programs that cause the jobs to be restarted" to define the system resources used in the communication prior to bein< it any communications transmissions by a trading partner's remote system. A ≥start, job is a batch job that starts running before a program on a remote system nds a program start request. Prestart jobs are different from other jobs because ≥y use prestart job entries to determine which program, class, and storage pool ti s when they are started. Within a prestart job entry, you must specify attributes at the subsystem uses to create and manage a pool of prestart jobs.

©Purpose: The purpose of this program is to receive EDI formatted ansactions from Rental Management Trading Partner and write them to the inbound ritrol and detail files.

©Notes:

- This program is activated by ARMS Trading Partner Insurance Company, ing an ALLOCATE verb. The corresponding ACCEPT verb makes the connection through MS-connected Value-Added Network using LU62.

- This program will received a complete EDI formatted 272 transaction s one continious long record. This long record is parsed out into 80 byte records d written to the detail file INBDTA. One corresponding control record is written INBCTL for each complete transaction set received.

Confidential Page 10 of246 8/11/00 ARMS Process Report

^~~ - A last batch number is retrieved from dtaara EDIA001 and updated. This

:ch number is the key for the detail and control files.

- A Comm Profile record is also updated with a batch sequence number.

- A Confirm Request is received, and this program replies with a ifirmED response.

- A Deallocate is received and this pgm writes the control file record

1 then returns to the ACCEPT verb and waits for another ALLOCATE from ARMS Tradinc rtner Insurance Company. This sequence is then repeated.

- This program is a PRE-START program and is started with the sbs. It nains active even when not connected to ARMS Trading Partner Insurance Company. It LI set forever on the ACCEPT verb, waiting for ARMS Trading Partner Insurance [tpany to ALLOC.

- This program does NOT go to EOJ when it receives the DEALLOCATE from IS Trading Partner Insurance Company, but re-establishes the connection by jeating the Accept, Receive, ConfirmED, and Deallocate sequence.

- EOJ is indicated when a STOP record is received or a CPI-C return codc- licates an error. It then must be manually restarted by the STRPJ command (start ≥-start job) .

scess

≥rarchical numeric ID: 1.1.1.1.1.14 led name: AMZRMIA ne: PGM Receive X12 Interface (AMZRMIA) nment: ©Purpose: To process X12 transmission set(s) within the receive

;erfaces files by mapping the elements from the transmission set data record to tl sociated ARMS proprietary record formats.

\ ^• >' ©Operational Method:

- Process the Electronic Commerce Customer Preference file (EDPREF3) .

- IF transaction type equals Rental Management for Vehicle Replacement αtals (X12 272)

- Determine application transaction type(AK, AT, CN, EX, or ER)

- Map associated X.12 element to corresponding proprietary recon rmat

- Write data format records to transmission received file ...

(AMTRNLOG)

- IF transaction type equals Rental Management Remittance Advice for hide Replacement Rentals (X12 820)

- Map associated X.12 element to corresponding proprietary recor rmat

- Write data format records to transmission received file MTRNLOG)

- IF transaction type equals Rental Management for Vehicle Replacement ntals (X12 824)

- Determine application transaction type (RM-rejected, ER)

- Map associated X.12 element to corresponding proprietary reco rmat

Confidential ^: Page 11 of 246 8/11/00 ARMS Process Report

- Write data format records to transmission received file 4TRNLOG)

©Notes :

This program was created and is primarily maintained by the ETD - ≥rging Technologies Department's EDI team.

ETD is currently working with the following X12 transaction sets that Eect rental:

272 Rental Management - 2 maps, 1 for ARMS Trading Partner iipany and a CIECA one which will be used by ARMS Trading Partner Company

824 Consolidate Payment - 2 maps, 1 ANSI X12 for ARMS Trading rtner Insurance Company and a CIECA X12 one which also will be used by a differenl S Trading Partner Insurance Company.

820 Payment - CIECA map used by ARMS Trading Partner Company io is a non-ARMS customer)

811 Consolidated Invoice - CIECA map for consolidated invoicini at ARMS Trading Partner Insurance Company and TVA are using.

832 Pricing Catalogue - map for ARMS Trading Partner Insurance Company which we are using to exchange branch rate and availability information. The implementation guide for this was given to us by ARMS Tradi] Partner Company and that is what we used to get this going.

The ARMS system will now enable electronic invoices, payments and mittances (processed here) to be sent/received for non-ARMS Rental Management ading Partners that are Direct Billing/Remittance Trading Partners, such as any terprise Fleet Services customer.

©Files : (CRUD)

R272HDR1 (-R—)

R272NMH1 ( -R—)

.. R272DTL1 (-R—)

R272LQ1 (-R—)

R272COM1 ( -R—)

R272ER1 (-R-)

R997AK1 (-R—)

AMEDI011 (C—)

AMTRNLOG (c- —)

AMPGMERR (C- --)

R820HDR1 (-R—)

R820DTL1 (-R—)

R820ADX1 (-R--)

R820NTE1 (-R—)

AMXREFL1 (-R—)

EDPREF3 (- R—)

AMAUTD (-R—)

ARMSPR1 (-R—)

AM805P01 (CR—)

AM806P01 (CR—)

AMSNDLOG (-R—)

EDPREF3L1 (-R—)

R824HDR1 (-R—)

R824DTL1 (-R—)

Confidential Page 12 of246 8/11/00 ARMS Process Report

R824TED1 (-R-)

R824NAM1 (-R-)

R824NTE1 (-R—)

AM804P02 (-R—)

AMXREF (-R-)

AMCLSTB2 (-R—)

AM801P02 (-R—)

©Embedded Data/Constants:

FILE(AMEDIOll) TOFILE (AM ) Used for override to appropriate tradinc :tner/VAN production/test receive file

©Improvement Opportunity

- Use program status data structure to retrieve program name.

>cess

≥rarchical numeric ID: 1.1.1.1.1.16 led name: AM_001 ne: PGM Retrieve ARMS Trading Partner Company Password (AM_001) nment: ©Purpose: To retrieve the connection password for a ARMS Trading Partn< πpany from the data area so as to restrict the authority to these data areas to a rtain specified number of people.

©Operational Method:

Retrieve data area AMSFPWPR if this is a production request. Retrieve data area AMSFPWTS if this is a test request. Return the password.

acess erarchical numeric ID : 1.1.1.1.1.18 ded name : me : DTQ Input for Receive Unwrapper (DQxxxRUl) mment : , -

ocess erarchical numeric ID: 1.1.1.1.1.19 ded name: me: DTQ Input for Receive Mapper Interface (DQxxxRMl) mment:

ocess erarchical numeric ID: 1.1.1.1.1.20 ded name: EDMRPIA me: PGM Receive X12 Transmission Batch (EDMRPIA) imment: ©Purpose: To receive and unwrap the X12 transmission from a direct lling trading partner.

©Operational Method:

- Receive the actual transmission into a temporary buffer

Confidential Page 13 of 246 ^' 8/11/00 ARMS Process Report

- CALL EDZ001A to retrieve direct billing trading partner's communicatic inection information. If the return code is '1', this means that there is no insmission to process otherwise use the returned communication NETWORK, PORT and 1IPT information to retrieve the transaction data ans put it into the application :erface files.

- CALL AMZRMIA to convert retrieved data in interface files to yprieatary formats for further processing.

©Notes: Currently, this program is called by a scheduled job PVA011RUM) that runs at 2:00 pm to receive a batch of transmissions from Tennessee

Lley Authority (TVA)

≥rarchical numeric ID: 1.1.1.1.1.21 led name: EDZ001A ne: PGM Retrieve Communication Parameters (EDZ001A) nment: ©Purpose: To retrieve the direct billing trading partner's communicatic

Eormation.

©Operational Method:

- Read file EDPREF1 to retrieve the direct billing trading partner's RT, NETWORK and SCRIPT information.

- If no record is found a return code of 1 indicating nothing can be Dcessed.

ocess erarchical numeric ID: 1.1.1.1.2 ded name: me: AUT Validate AND Unpackage (CommRcvr - AM20/AM21) mment: ©Definition: The automatic process of separating from the received and lidated-EDI transmission- envelope the individual transaction data sets so each ba ansaction is processed further individually.

ocess erarchical numeric ID: 1.1.1.1.2.2 ded name: AMOOIOVI me: PGM Validate Transmission (AMOOIOVI) mment: ©Definition: The ARMS never-ending batch program to* validate the mpleteness of a transmission envelope's contents.

©Operational Method:

At startup do the following steps:

1. Read, increment by 1 and update the DASDV1 data area value to indica at another AMOOIOVI NEP job has started.

2. Construct the derived input data queue name from "DQ" concatenated th the TRADING PARTNER/VAN PROFILE ID input parameter value concatenate with the instant "1" .

Confidential Page 14 of 246 8/11/00 ARMS Process Report

3. Override the derived ARMS Input file (AMINPUT) to the ARMS Input DING PARTNER/VAN RECEIVER INPUT FILE Version Number 1. Then open the input file.

4. Override the derived ARMS Hold file (AMHOLD) to the ARMS Hold TRADING TNER/VAN RECEIVER INPUT FILE Version Number 1. Then open the hold file.

After startup, continue to receive the next data queue entry from the ived input data queue until program shutdown.

For a shutdown data queue entry received:

1. Read the DASDV1 data area value, decrement by 1, update it.

2. Send a shutdown data queue entry to the Unpackaging Input Data Queue AMTRN1) .

3. End the program/job.

For each non-shutdown data queue entry received:

1. Use its value to read by key the next TRADING PARTNER/VAN RECEIVER 'UT FILE record.

2. IF not end-of-file, check the retrieved record's FORMAT ID:

A. IF the record's FORMAT ID is part of the packaging (Transmission, ιup, or Set Start/End) , then load the record to that appropriate proprietary recor ^•mat external data structure. i. IF the SETE01 format has been read, check the derived TOTAL ^■AIL FORMATS READ COUNTER is less than 1. a. IF true, reject the transmission envelope

B. IF the record's FORMAT ID is NOT part of the packaging (i.e. the msaction's information), check if at least one Transmission, Group and Set Start lord format was read. i. IF false, then reject transmission with appropriate error code. ii. IF true, then write it to the ARMS Hold TRADING PARTNER/VAN ΕIVER INPUT FILE Version Number 1 and increment by one the derived TOTAL DETAIL -MATS READ COUNTER. '^•• ^'- ■■"

- Validate if received transmission envelope is complete. If not valid, lerate.an Error Transaction (ER) data set record formats to the Transactions to i :kaged for Sending (AMPACK) file and its key to the associated input (DQAMPKG) dat iue, and write an associated record in the AMERRLOG file.

- Generate a return Communication Acknowledgement (AK) transaction set . the valid transmission envelope received.

©Notes:

This program is only executed as an ARMS never-ending batch program in i ARMS subsystem only on the ARMS application centralized host computer system itform. This program is currently submitted by the ARMS Start-Up Job (CLL810) whe ≥cuted on the system known as "RARMS" host computer system platform. This never- ling batch program ends normally when a shutdown data queue entry is received as put. Normally, this can indicate that its corresponding receiver or receiver's pper-interface never-ending program batch jobs that had been previously active th. f have processed a shutdown request.

It is submitted from the CLL810 ARMS Start-Up program with the following put parameter fields:

5 Alpha TRADING PARTNER/VAN PROFILE ID

Confidential Page 15 of 246 8/11/00 ARMS Process Report

8 Alpha TRADING PARTNER/VAN RECEIVER INPUT FILE

©Files: (CRUD)

AMHOLD (CR-D) (HLxxxxxl)

ARMSPR1 (-R—)

AMERRLOG (C )

AMxxxxxl (-R—) (Where 'xxxxx' is the connect-specific Trading ^•tner or VAN production or test Profile ID)

AMTRN (C )

AMPACK (C )

DASDV1 (-RU-) Data Area: number of AMOOIOVI program/jobs runninc id by AM0020V1 to check when last AMOOIOVI program active has shutdown.

©Embedded Data/Constants :

'0123456789* for testing for valid numbers.

OVRDBF FILE (AMINPUT) TOFILE (AMCMPID1) to override to the appropriate cxxxxl file.

OVRDBF FILE (AMHOLD) TOFILE (HLCMPIDl) to override to the appropriate cxxxxl file.

CLRPFM FILE(*LIBL/HLxxxxxl) to execute a clear physical file member < Ϊ appropriate HLxxxxxl file.

jcess

≥rarchical numeric ID: 1.1.1.1.2.3 led name: AM0020V1 ne: PGM Unpackage Transaction from Transmission (AM0020V1) nment: ©Purpose: To unpackage received proprietary transmission and remove th( insmission control formats (also referred to as transmission envelope) TSMS01,

4E01, SETS01, SETE01, GRPS01 and GRPE01.

©Operational Method:

1. Receive the next data queue entry for this program's input data queu 2AMTRN1) . i.-' 2. For every shutdown data queue entry, retrieve, decrement by 1, and iate data area DASDV1 until new value is zero. When it is zero, send a shutdown ta queue entry to the Edit Transaction Group/Set Record Formats data queue 2AM25V1) and end the program. For further details about shutdown, refer to suppo tivity "BAT Shutdown ARMS Environment" .

3. For every non-shutdown data queue entry received:

A. Read all of the associated records (by the key value of the data eue entry) from the received packaged transmissions log file (AMTRN) .

B. For each set start (SETS01) record format: i. Attempt to use its PROFILE ID and its CUSTOMER TRANSACTION ID t trieve an existing associated ARMS Cross-Reference File record. IF found, hold i NDOR TRANSACTION ID and load its MACHINE ID, SOURCE ID, RENTAL LOCATION ID, SERVATION ID, and TICKET ID values, along with the Transmission Group Start recoi rniat's GROUP TYPE CODE and the Transmission Group's Set Start record format's SET TION TYPE CODE values and this PROGRAM ID value and a ROUTING CODE of ^• I ^• , to the sociated fields in the internal format APPD01.

Confidential Page 16 of 246 8/11/00 ARMS Process Report ii. Load the format, APPD01, and all associated subsequent insaction data set record formats' derived key value with the current record's kej .catenated with the Transmission Group Start record format's GROUP CONTROL ID and )UP TYPE CODE, and the Transmission Group's Set Start record format's CUSTOMER iNSACTION ID, and,

IF the ARMS Cross-Reference File record was retrieved successfully, its IDOR TRANSACTION ID value.

C. For each record format read that is not a Transmission, Group, or Set irt/End record format,

If the group transaction type is not 'ER', write the record format ;h the derived key value to the output file, Transaction Sets to be Edited Daily insaction file (AMSET) else

If the group type in error as specified on the ERRDOl record rmat is not 'IN', write the record format with the derived key value to the output Le, Received Errors Log file (AMRCVERR) else

Write the record format with the derived key value to the :put file, Received Billing Errors Log file (AMBILERR) .

D. For each Transmission Group Set End (SETE01) record format, send the rrent transaction data set's derived concatened key value to the Edit Transaction sup/Set Record Formats data qUeue (DQAM25V1) and finish reading the input file :il the next Transmission Start (TSMS01) , Group Start (GRPS01) , or Set Start 2TS01) record format is read for the current read input key value.

©Notes:

This program is only executed as an ARMS never-ending batch program in ≥ ARMS subsystem only on the ARMS application centralized host computer system atform. This program is currently submitted by the ARMS Start-Up Job (CLL810) wii single input parameter, VERSION, with the constant value of "1". This never-endii tch program ends normally when a set of shutdown data queue entries are received « put that indicate that each AMOOIOVI never-ending program batch jobs that was ≥viously active that day have processed a shutdown request. ' ^j!

©Files: (CR

AMTRN ^•' (-R--)

AMSET (C—)

ARMSPR3 (-R-)

AMAUTD (-R—)

AMRCVERR (C —)

AMBILERR (C—)

©Embedded Data/Constants:

»*DOWN0O000000000000SD' is the key value used as output when sending a utdown data queue entry to DQAM25V1.

•*DOWN' and 'SD' are the literal constants used to check the data queue try value loaded into the ARMSKEY external data structure's data elements for MPANY PROFILE ID and GROUP TYPE CODE to determine if a shutdown was received.

»*LIBL' is used as the literal constant to pass as an input parameter eld value for the DATA QUEUE LIBRARY NAME for the calls to the 'QRCVDTAQ' and iSNDDTAQ* programs..

All of the possible ARMS Cross-Reference File Record's STATUS CODE valv e used as literal constants in checking certain codes for conditional logic.

Confidential Page 17 of 246 8/11/00 ARMS Process Report

©Improvement Opportunities:

'♦DOWN00000000000000SD' could be used by many never-ending programs and ! Send Data Queue Entry programs referenced from the Work with Data Queues menu, srefore, place this value in an application system-wide data area and reference s external object.

Replace the literal constant '*LIBL' with this value in an application itern-wide data area and reference this external' object.

icess srarchical numeric ID: 1.1.1.1.2.4 led name: AM0021V1 le: PGM Unpackage Transaction from Transmission (AM0021V1-RM Only) rnient: ©Definition: This is a never-ending batch program to unpackage any littance advice functional groups from a proprietary EDI transmission envelope int lividual internal transaction data sets with one or more record formats.

©Purpose:

This program will edit and unpackage individual remittance detail insaction data sets within Remittance Advice ( 'RM' ) functional groups within jeived transmissions' proprietary EDI envelopes. This program also matches and Lts each transaction set's Profile ID and Customer Transaction ID to an associatec Lsting ARMS Trading Partner Profile File and an ARMS Rental Transaction Cross- ϊerence File record. This is used to validate if the retrieved files' records' tribute indication settings and the Cross-Refernence Status Code value should all< :h action, and outputs each validated individual internal transaction data set wit corresponding internal proprietary (APPD01) header record format and a unique -ociated record key value to ARMS Transaction Sets to be Validated (AMSET) file ai 3 associated data queue (DQAM25V1) . The output transaction set will be processed input by the Validate Transaction Set Record Formats (AM0025V1) program

©Operational Method:

--. '' 1. Receive the next data queue entry for this program's input data queui 3AM21V1) .

, ~ 2. For every shutdown data queue entry, send a shutdown data queue entzr; the Edit Transaction Group/Set Record Formats data queue (DQAM25V1) and end the Dgram.

3. For every non-shutdown data queue entry received:

A. Using the data queue entry's Trading Partner Profile ID value,,., trieve the associated ARMS Trading Partner Profile Application Specific Informatii le record.

B. Read each of the associated records (by their key value of the ceived data queue entry) from the ARMS Validated Received Proprietary EDI ansmission Envelopes to be Unpackaged ile (AMTRN) .

C. For each Transaction Set Start (SETS01) record format processed: i. Load the AMTRN file record's key value (consisting of the TRADI RTNER PROFILE ID and the TRANSMISSION CONTROL SEQUENCE ID NUMBER) to the AMSET fi y and append to it the following: a. the Functional Group Start (GRPS01) record format's GROUP NTROL SEQUENCE NUMBER and the functional GROUP TYPE CODE. b. the Transaction Set Start (SETS01) record format's CUSTOMER ANSACTION ID and VENDOR TRANSACTION ID.

Confidential Page 18 of 246 8/11/00 ARMS Process Report ii. Load the Internal Header Record Format (APPD01) fields with the iropriate data.

D. For each remittance detail (RMTD01) record format: i. Validate its PAYMENT CODE. IF invalid, reject with ERROR IE= • 51 ' .

- Edit to ensure there is a non-blank EFT ID NUMBER on all paid littances .

- Validate that any Rejected Payment Remittance Advice Detail :ord Format does not have a value in the EFT ID NUMBER field. ii. Use the retrieved AMTRN file record's key value's PROFILE ID and 5TOMER TRANSACTION ID to attempt to retrieve an existing associated ARMS Cross- ierence File record. IF found, then validate that the Cross-Reference File recor the proper status. IF the read remittance detail's CUSTOMER TRANSACTION ID value is not match its retrieved ARMS Cross-Reference file record same field value, iect with ERROR CODE='82^». IF the status is valid, hold its VENDOR TRANSACTION II I load its MACHINE ID, SOURCE ID, RENTAL LOCATION ID, RESERVATION ID, and TICKET 3 .ues, along with the Transmission Group Start record format's GROUP TYPE CODE and i Transmission Group's Set Start record format's SET ACTION TYPE CODE values and Ls PROGRAM ID value and a ROUTING CODE of 'I', to their associated fields in the .ernal unpackaged transaction data set (APPD01) record format. iii. Load the internal unpackaged tranaσtion data set (APPD01) and al sociated subsequent transaction data set record formats' derived key value with tl rrent record's key, concatenated with the Transmission Group Start record format'.; )UP CONTROL ID and GROUP TYPE CODE, and the Transmission Group's Set Start record rmat's CUSTOMER TRANSACTION ID, and,

IF the ARMS Cross-Reference File record was retrieved successfully, its TOOR TRANSACTION ID value. iv. Based on the trading partner profile, edit the remittance amount linst the invoiced amount, and error the remittance detail record if the amount Lues are not equal. This comparison will not occur for RM reject or illegal insactions. The value of the profile attribute that indicates whether a trading rtner sends remittances will be "X" for those customers that can short pay and so ≥ totals need not match (e.g. TVA) . v. IF an error is detected, call error program AM0090V1, which will aate an ERRDOl format. vi. For each validated RMTD01 record format read, write the record rmat with the derived key value to the output file of Transaction Sets to be Edit< ily Transaction file (AMSET) and send its key as a data queue entry to DQAM25V1.

E. For a Remittance Advice Total record format (RMTT01) read, IF its TAL AMOUNT or the TOTAL TICKETS does not balance with all of the non-rejected ittance Advice Detail record format records' PAYMENT AMOUNT sum or a derived cord count, error the Remittance Total record format, but continue to process all e detail records which have not errored. Rejected Payment Transactions may exis' thin Paid Transactions batches. *Note, a remittance total format is not required en only one remittance advise is received and it's status is 'R'ejected.

F. For any record formats read other than RMTD01 and RMTT01 and the ansmission, Group and Set Start/End record formats, create an APPD01 format pecially for it. Then write out that invalid format and save the AMSET key to wri

DQAM25V1 when the SETE01 record format is read.

Confidential Page 19 of 246 8/11/00 ARMS Process Report

©Notes :

This program is only executed as an ARMS never-ending batch program in ARMS subsystem only on the ARMS application centralized host computer system tform. This program is currently submitted by the ARMS Start-Up Job (CLL810) wit ingle input parameter, VERSION, with the constant value of "1". This never-endin σh program ends normally when a set of shutdown data queue entries are received a ιut that indicate that each AMOOIOVI never-ending program batch jobs that was ^■viously active that day have processed a shutdown request.

The ARMS system will now enable electronic invoices, payments and littances (processed here) to be sent/received for non-ARMS Rental Management Lding Partners that are Direct Billing/Remittance Trading Partners, such as inessee Valley Authority (an Enterprise Fleet Services customer) .

©Files : (CR

AMTRN (-R—)

AMSET (C—)

AMIEBT (-R—)

AMIEBH (-R—)

ARMSPRl (-R—)

©Embedded Data/Constants:

'0123456789' Named constant to check for numeric fields.

Valid values for BILLING INVOICE STATUS in the RMTD01 record format:

'P' = Payment (Can be in full or a partial payment) .

•R' = Rejected (must have additional ERROR CODES provided)

'X' = Illegal (must have additional ERROR CODES provided)

All of the following are the possible ARMS Cross-Reference File Record'! YTUS CODE values allowable are used as literal constants in checking certain code. r conditional logic to allow remittances to be further processed. However, 'P' i Ly valid when the ARMS Trading Partner Profile (ARMSPRl) flag is set accordingly.

'PABQ'

'B' = Rental Contract Electronically Billed at least once

'A' = Passed Electronic Billing Audit

'P' = Paid in full

'Q' = Rejected for Payment by Trading Partner

'*DOWN' and 'SD' (ShutDown) are the literal constants used to check the ta queue entry value loaded into the ARMSKEY external data structure's data ements for COMPANY PROFILE ID and GROUP TYPE CODE to determine if a shutdown was ceived.

'AM0021V1' is used as a literal constant to pass as an input parameter eld value to the calls of 'AMPSSR' and 'AM0090V1* programs.

'*LIBL' is used as the literal constant to pass as an input parameter eld value for the DATA QUEUE LIBRARY NAME for the calls to the 'QRCVDTAQ' and SNDDTAQ' programs..

©Improvement Opportunities:

Confidential Page 20 of 246 8/11/00 ARMS Process Report

Replace the literal constant 'AM0021V1' with the Program Status Data

Picture's data element for PROGRAM ID.

Replace the literal constant **LIBL* with this value in an application item-wide data area and reference this external object.

>cess irarchical numeric ID: 1.1.1.1.2.5 led name: DQAM21V1 ne: DTQ Input for program AM0021V1 (DQAM21V1) nment: ©Definition: DQAM21V1 is the data queue used to provide input to PGM

)021V1 which processes remittance advises

>cess irarchical numeric ID: 1.1.1.1.2.6 led name: DQAMTRN1 ne: DTQ Input for program AM0020V1 (DQAMTRNl) n ent: ©Definition: DQAMTRNl is the data queue used to provide input for PGM

3020V1 which unpackages transactions.

≥rarchical numeric ID: 1.1.1.1.2.7 led name: ne: DTQ Input for Transmission Validation from Specific trading partner (DQxxxxxl nment: ©Definition: one of several company specific data queues used to providi put to a company specific AMOOIOVI PGM used for transmission validation. Data

≥ues included are DQ***011, DQ***011, DQVN1011, DQVN2011, DQVN3011, and DQTVA011.

Dcess <-' srarchical numeric ID: 1.1.1.1.2.8 ded name: DQAM70V1 me: DTQ, Input for Time Line Inquiry (DQAM70V1) mment: ©Definition: DQAM70V1 is the data queue used to provide input to PGM

0070V1 which provides a support information for oncall work.

ocess erarchical numeric ID: 1.1.1.1.2.12 ded name: AMLCXLT me: PGM Translate Location (AMLCXLT) mment: ©Purpose: To translate a current rental location to an old location or ce versa to deal with any past "Organization Split" or "Machine Split" conversion ojects, such as the "Texas Group Split" of July 1995 or the "Bluegrass Group Spli June 1997 or the "Group 53 split of October 1999". An example would be calling e program with a TRANSACTION DATE = 08/13/1998, LOCATION CODE = 'O' and CURRENT OUP/BRANCH ID = '5211'. The returned TRANSLATED GROUP/BRANCH ID would be '6511'.

©Operational Method:

- This program is called with a single input/output AMLCXLT external de ructure with the following alphameric data elements and their usage:

Confidential Page 21 of246 ^" 8/11/00 ARMS Process Report

1 (Output) Return Code

1 (Input) OLD/NEW CURRENT VALUE

1 (Input) CURRENT MACHINE ID

2 (Input) CURRENT GROUP CODE

2 (Input) CURRENT BRANCH CODE

4 (Input) CURRENT GROUP/BRANCH

10 (Input) CURRENT LOCATION

1 (Input) CURRENT REGION

2 (Input) CURRENT SUB-REGION

2 (Input) CURRENT CITY

3 (Input) CURRENT AREA

20 (Input) VENDOR TRANSACTION ID

5 (Input) ARMS PROFILE ID

20 (Input) CUSTOMER TRANSACTION ID

8 (Input) TRANSACTION DATE

10 (Output) TRANSLATED LOCATION

4 (Output) TRANSLATED GROUP/BRANCH

2 (Output) TRANSLATED GROUP

2 (Output) TRANSLATED BRANCH

8 (Output) TRANSLATED MACHINE NAME

1 (Output) TRANSLATED REGION

2 (Output) TRANSLATED SUB-REGION

2 (Output) TRANSLATED CITY

3 (Output) TRANSLATED AREA

This pgm will accept a parameter list containing current location formation and if a record is found in the ARMS Location Past Conversion Cross- Eerence (AMLCXF) file, will return the translation information.

- IF the attempt to retrieve ARMS Rental Transaction Cross-Reference 4XREF) file record fails, still attempt to perform the translate. Do this by ining a test on the passed parameter's CURRENT TRANSACTION DATE.

IF all tests for transaction date checking fail, then move 'N' to TORN CODE.

IF a test is successful, perform the routine to load the TRANSLATED -HINE ID and LOCATION output parameter data elements.

©Notes: This program was written and is currently maintained by the ARM! alication Development Department. It is currently used by the ARMS Unpackage anεaction from Transmission Envelope (AM0020V1 and AM0021V1) programs, along with ≥ ARMS Package Transmission Envelope (AM0120, AM0150, AM0151) programs along with a Financial Systems' AS Account schedules /JOB # 102 (EL0291) program. An teractive stub tester (TSAMLCXLT) program exists in production for debugging and sting purposes.

©Files: (CRUD)

AMLCXF (-R—) - Keyed by Old Location ID, along with its other gical access views,

AMLCXFLO - Keyed b d Location

AMLCXFLl - Keyed b w Location

AMLCXFL2 - Keyed b d Group/Branch

AMLCXFL3 - Keyed b w Group/Branch

AMLCXFL4 - Keyed b d Group and Old Branch

Confidential Page 22 of 246 8/11/00 ARMS Process Report

AMLCXFL5 - Keyed by

Group and New Branch

AMLCXFL6 - Keyed by

Group, Region and Sub-Region

AMLCXFL7 - Keyed by ' Group, Region and Sub-Region

AMLCXFL8 - Keyed by L Group and City

AMLCXFL9 - Keyed by r Group and City

AMLCXFL10 - Keyed by L Group and Area

AMLCXFL11 - Keyed by r Group and Area

AMLCXFL12 - Keyed by I Group and Region

AMLCXFL13 - Keyed by r Group and Region

>cess irarchical numeric ID: 1.1.1.1.3 led name: le: AUT Validate Transaction (AM25 - AM46) iment: ©Definition: The automatic process of transaction validation and databaε late on the centralized machine prior to dispatch to either the distributed machir the Rental Management Trading Partner. This process is currently used for both tl sound and outbound processing of transactions.

>cess irarchical numeric ID: 1.1.1.1.3.1 led name: AM0025V1 tie: PGM Validate Transaction Set Record Formats (AM0025V1) nment: ©Definition: This is the ARMS Transaction Set Record Format Edit never- ling batch ILE RPG program.

©Purpose:

The program edits a transmission set group type to ensure that the juired formats are present and that no non-allowable record formats exist.

Edit errors from an Inbound (Received) tranaction set will be logged anc LI cause error transaction sets to be generated and sent back to the associated ider.

Edit errors from an Outbound (to be Sent) or Transfer transaction set LI be logged and the ARMS On-call support staff will be notified.

©Operational Method:

This program endlessly receives the non-keyed input data queue entries om the input data queue (DQAM25V1) that the either of the ARMS Unpackage mittance/Non-Remittance Envelope programs (AM0021/AM0020V1) generated as input to is program.

Once a shutdown data queue entry is received, then send this shutdown ta queue entry to the DQAMSET1 data queue and end this program.

Confidential Page 23 of 246 8/11/00 ARMS Process Report

For any non-shutdown data queue entry, check the non-shutdown key Group e Code to be one of the following values:

- Validate Transaction Set Group Type

- Validate Allowable Record Format (s) within Transaction Set for a Groυ >e

©Notes:

This program is submitted for execution by the ARMS Startup Jobs progran 1L8IO) with no entry parameters to execute only on the centralized ARMS host syste .tform ("RARMS") . Currently, all inbound (received), outbound (to be sent) and nsfers are processed processed in this program as the proprietary EDI Transactior s group types.

IF any error is found, then do not process this transaction any further I if is it is an inbound transaction set, then executed the ARMS Generate External ^•or (AM0090V1) program, ELSE, execute the ARMS Handle Internal Error (AM0097V1) igram, passing the input parameters of this data queue entry's key data elements L the currently loaded ERROR CODE value. Do NOT output the transaction set's :ord formats to the outpug file nor send its data queue entry to the output data sue.

Called Programs Summary:

QRCVDTAQ --Read entry from DQAM62V1 data queue

QSNDDTAQ --Send entry to DQANDST data queue AMPSSR --ARMS program error handler AM0097V1 --Handle Internal Error AM0090V1 --Generate External Error

©Files: (CRUD)

- AMSET (-R--)

- AMAUTD (-R—)

■ - ^'■ ©Embedded Data Constants:

•*LIBL' as the DATA QUEUE LIBRARY NAME value used in the execution of t] tCVDTAQ' and 'QSNDDTAQ' programs.

'DQAM25V1' and 'DQAMSETl' are the specified data queue names.

'AM0025V1' as the current PROGRAM ID.

^■AM0090V1' and 'AM0097V1' are the executed programs^', based on the type ror.

'SD' and '*DOWN' are the shutdown request GROUP TYPE CODE and COMPANY DFILE ID values.

•OFF" and ON'

'Ι'(nbound), 'O' (utbound) , and 'T' (ransfer)

ERROR CODES : ' 16 ' , ' 45 , ' 69 ' , ' 70 ' , ' 71 ' , and ' 90 * .

GROUP TYPE CODES for execution of their associated routine:

Confidential Page 24 of 246 8/11/00 ARMS Process Report

^•AT', 'EX', 'CN', 'PM', 'ER', 'AK' , 'AC, 'IN', 'OF', 'RA' , 'RC, 'RE', I', 'CC, 'RM', 'CM', and 'VM'

Compile-Time arrays of:

..Valid transaction set GROUP TYPE CODES

..Valid RECORD FORMAT ID'S for each transaction set's GROUP TYPE CODE

©Improvement Opportunities:

1.) Replace the execution of the ARMS Handle Internal Error ('AM0097V1'] 1 ARMS Generate External Error ('AM0090V1') programs with the execution of the rer ARMS Handle Internal/External Error ('AM0098') program.

2.) Delete the constant 'AM0025V1' and replace its usage with the Progr itus Data Structure data element for PROGRAM ID.

icess

≥rarchical numeric ID: 1.1.1.1.3.2 led name: AM0030V1 ne: PGM Validate Transaction Set Record Formats Data Types (AM0030V1) ment: ©Purpose:

To edit a transaction set to ensure the all the required format data ≥ments have values. Whether a data element is required or not is based on the ading partner profile.

©Operational Method:

- Wait for entry(s) to exist in DTAQ (DQAMSET1) .

- When a shutdown request is received (group type - SD) , log the surrence, pass on the request to DTAQ (DQANDTL1) and wait for the second shutdown

- When the second shutdown request is received (group type - SD) , log ≥ occurrence, pass the request to DTAQ (DQANDTL1) and end.

-When a non-shutdown request is received, read all associated data cord(s) from the ARMS Detail Set Transaction File (AMSET) into the appropriate AR cord format data structures.

- Validate a transaction set's group type record formats' data elements r profilable mandatory values existence.

- Validate data field values with the data format (s) against a domain o lowable values.

-IF any error is found, then do not process this transaction any furthe d if is it is an inbound transaction set, then executed the ARMS Generate Externa ror (AM0090V1) program, ELSE, execute the ARMS Handle Internal Error (AM0097V1) ogram, passing the input parameters of this data queue entry's key data elements d the currently loaded ERROR CODE value. Do NOT output the transaction set' s cord formats to the output file nor send its data queue entry to the output data eue.

©Notes:

This program is submitted for execution by the ARMS Startup Jobs progrε LL810) with no entry parameters to execute only on the centralized ARMS host syst

Confidential Page25 of246 8/11/00 ARMS Process Report itform ("RARMS") . Currently, all inbound (received) , outbound (to be sent) and msfer transaction sets are processed in this program as proprietary EDI insaction Set group types.

The ARMS system will now enable electronic invoices, payments and littances (processed here) to be sent/received for non-ARMS Rental Management iding Partners that are Direct Billing/Remittance Trading Partners, such as messee Valley Authority (an Enterprise Fleet Services customer) ; and AAA of .ifornia.

©Files : (CE

-AMSET (-R—)

-STATE (-R—)

-AMCLSTBL (-R—)

-CCSURCHG (-R—)

-AMERRTBL (-R-)

-AMXBCOL1 (-R—)

-AMICDTBL (-R-)

-ARMMAP (-R—)

-ARMSPRl (-R-)

-ARMSPR4 (-R—)

-AMAUTD (-R-)

©Embedded Data/Constants:

'0123456789' TO CHECK FOR VALID NUMERIC FIELDS VALUES

' 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ • TO CHECK FOR VALID ALPHANUMERIC 2LDS VALUES

'*LIBL' as the DATA QUEUE LIBRARY NAME value used in the execution of tl R.CVDTAQ' and 'QSNDDTAQ' programs.

'DQAMSET1' and 'DQANDTL1' are the specified data queue names.

•AM0030V1' as the current PROGRAM ID.

• -^'• 'AM0090V1' and 'AM0097V1* are the executed programs, based on the type c ror.

'SD' and '*DOWN' are the shutdown request GROUP TYPE CODE and COMPANY DFILE ID values.

•OFF• and 'ON ^■

'Ι'(nbound), 'O'(utbound), and 'T' (ransfer)

All allowable values for each data element

ERROR CODES: '01', '02', '03', '04', '05', '21', '68', '70', '78', and 2'

GROUP TYPE CODES for execution of their associated routine: 'AT', 'EX', 'CN', 'PM', 'ER', 'AK' , 'AC, 'IN', 'OF', 'RA' , 'EC, 'RE', N', 'CC¹, 'RM^«, 'CM', and 'VM'

Compile-Time arrays of:

..Valid transaction set GROUP TYPE CODES

..Valid RECORD FORMAT ID'S for each transaction set's GROUP TYPE CODE

Confidential Page 26 of246 8/11/00 ARMS Process Report

©Improvement Opportunities:

1.) Replace the execution of the ARMS Handle Internal Error ('AM0097V₁') 1 ARMS Generate External Error ('AM0090V1') programs with the execution of the rør ARMS Handle Internal/External Error ('AM0098') program.

2.) Delete the constant 'AM0025V1' and replace its usage with the Progra itus Data Structure data element for PROGRAM ID.

3. ) Convert program from OPM RPG to ILE RPG.

4.) Replace the use of the AM2010V1 program with the AM1010V1 program Lied for "I"nquiry.

acess

≥rarchical numeric ID: 1.1.1.1.3.3 led name: AM0040V1 ne: PGM Validate Transaction Set Record Format Data (AM0040V1) nment: ©Purpose: To perform the detail edits on any transaction set data elemer

Lues against the centralized ARMS database and domain of valid values. Also, to sign a rental location to any new Rental Authorization Add transaction that is not thorizing an existing rental reservation or open ticket.

©Operational Method:

Wait for keys to exist in DTAQ (DQANDTL1) , when key is received, one of ree processes occur. Program terminates when group type (SD) shut down data queu* try is encountered and passed on for the second time to output data queue 2AM46V1) .

For a non-shutdown data queue entry, use its value to read all associat< cords * data values from the ARMS Detail Set Transaction File (AMSET) into the ' propriate ARMS record format data structures.

Validate Transaction Set's record formats' data fields' contents for lowable-values .

Validate Transaction Set's functional group type code and its record rmat's data field's contents against centralized ARMS Rental Transaction Cross- ference Status and its associated database file fields to ensure that this ansaction should be allowed to continue further downstream processing. Send ssage to ARMS On-Call and reject any Authorization Transfer transaction or outboui ansaction to be sent that fails an edit.

IF any received inbound transmission with a specified Branch Claims fice value that does not exist in the Branch Claims Office Cross-Reference file, en assign the first three characters (root customer) of the trading partner's OFILE ID to ENTERPRISE CUSTOMER ID and send a warning message to ARMS Technical nagement (via SNDΞMSG) of a transaction with a missing BCO X-Ref record so that ey can determine if this BCO is to be added. Do NOT reject the transaction.

ELSE, load the internal routing record format (APPD01) with the retriev ternal ENTERPRISE CUSTOMER ID value.

IF any received inbound transmission with a invalid Date Of Birth value iβn set the value to zeros and send a warning message "Invalid DOB" to ARMS ichnical Managemen which is currently not acted upon by them.

Confidential Page 27 of 246 8/11/00 ARMS Process Report

The messages sent to ARMS Technical along with the employee numbers to id the message to exist in file SNDMSG.

IF an authorization-add transaction set or a group-to-group authorized jervation transfer transaction set has a non-blank rental location (Group ID and inch ID) , then validate the rental location against the Daily Rental Office :ations (DROFF) file by the Rental Location ID. IF not found for the :horization-add/transfer, or, for an authorization-add, the location found licates that it does prevent ARMS reservations, then use its non-blank Forward AR jervations To Location. If the Forward ARMS Reservations To Location is blank or : found, then derive the closest available daily rental location and its platform.

IF a received unsolicited Authorization Add rental transaction set is :eived that is to authorize and create a currently non-existent rental reservatior rive and assign closest available rental location and its distributed application ϊt platform for later routing to that platform.

To derive the closest available rental location we use RAS013A.

IF the authorization add/transfer transaction set is for Enterprise set Management VIP rental customer, they will be able to send and generate ARMS :horized reservations to airport branches if that is the closest rental location. f other trading partner authorization add/transfer cannot be routed to an airport :ation.

Derive that rental location's associated distributed application host itform by executing Derive Machine ID for Rental Location (AM2050V1) program for :er routing.

IF a transaction's record formats are validated and processed 2cessfully, then send its associated key value as output to the data queue 2AM46V1) that is input to the next downstream process for ARMS Database Update an< αting (AM0046V1) program.

©Files : (CR

AMSET (CRU-)

ARMSPRl (-R—)

AMAUTD (-R--)

AMIEBT (-R—)

AMXBCO (-R—)

DROFLF1 (-R--)

DROFFL7 (-R--)

FILE80 (C-

©Notes :

This program is submitted for execution as a never-ending batch ogram/job in the ARMS subsystem by the ARMS Startup Jobs program (CLL810) with no try parameters to execute only on the centralized ARMS host system platform RARMS") . It will usually be active from 3:00am to l:00am-Central. Currently, al bound (received) , outbound (to be sent) and transfer transaction sets are process this program as proprietary EDI Transaction Set group types.

IF any error is found, then do not process this transaction any further d if is it is an inbound transaction set, then execute the ARMS Generate External ror (AM0090V1) program, ELSE, execute the ARMS Handle Internal Error (AM0097V1) ogram, passing the input parameters of this data queue entry's key data elements d the currently loaded ERROR CODE value. Do NOT output the transaction set's

Confidential Page28 of246 8/11/00 ARMS Process Report ord formats to the output file nor send its data queue entry to the output data

The ARMS system will now enable electronic invoices, payments and littances (processed here) to be sent/received for non-ARMS Rental Management iding Partners that are Direct Billing/Remittance Trading Partners, such as messee Valley Authority (an Enterprise Fleet Services customer) ; and¹ AAA of .ifornia.

©Embedded Data/Constants:

•7680 • used as the default Claims Connection Rental Location.

' 6A01 ' used for routing to this simulation default rental location :hin the production software environment.

•0123456789' used as valid numeric values in a CHECK operation.

•RTVMSGSTS' is the program executed to check if the e-Message System is lilable for sending messages.

•OVRPRTF FILE (QPPGMDMP) OUTQ(ARMSDUMP) OUTPTY(9) USRDTA(AM40PGMERR) tMTYPE(ARMS) HOLD (*YES) ' to cause generated RPG-formatted dump output to be ained for greater than a one day.

The following are 25-character ERROR MESSAGES subject header and detail le prefixed output to FILE80 for sending when executing MS0010 program:

'An invalid BCO was sent'

'Invalid BCO'

'Profile*

'transaction control ID'

'Invalid DOB was received'

'Invalid DOB'

©Improvement Opportunities:

1. ) Remove as constant and store the default simulation rental location ('6A01') and the default production Claims Connection rental location ID in an :ernal data area to externalize this location information for inquiry into the agram.

2.) Should be able to replace the valid numeric values constant and its age with an ILE built-in function or existing API.

3.) Should be able to duplicate the existing OS/400 Dump printer file PGMDMP to a different ARMSDUMP printer file that is formatted the same but has al! the specified keyword attributes that would allow the removal of the OVRPRTF /400 command execution.

ocess erarchical numeric ID: 1.1.1.1.3.4 ded name: AM0046V1 me: PGM Route Transaction / Update ARMS Centralized Database (AM0046V1) mment: ©Purpose: To update the centralized ARMS database with transaction set ta elements and forward the transaction set to the appropriate destination (tradi rtner, rental application, claims connection, or centralized financial system's sh receipts interface) .

©Operational Method:

Confidential Page 29 of 246 8/11/00 ARMS Process Report

- Maintain centralized ARMS application system database with input msaction set data elements.

- Route outbound transaction data set for external envelope packaging.

- Route inbound or transfer transaction data set for sending to itributed host platform.

- IF processing an RA Change, AT Change or an an Opening Rental .ification RN functional group type, then calculate the renter's age by subtractin sir Date of Birth from the system date. IF the renter is underage for the state c i rental and the ticket is open and authorized, then execute the Generate Surcharg >routine (GΞNSUR) to load the Approved Surcharge Detail (AMSURD) file. This >routine calls AM1085V1 for underage surcharges and AM0096V1 for othe surcharges. RA-Change for an ARMS Trading Partner Company will only be generated if the insaction has been confirmed. (See ©Notes for more detailed information)

- On an open authorized ticket, if a different Rental Location ID is >cessed from an outbound or transfer transaction set, then execute the Add rernment Surcharge (AM0096V1) program to load the Approved Surcharge Detail ISURD) file.

-IF any new approved surcharges were generated, then read this file for -s rental transaction to generate a new automatic pseudo-rental Authorization mge (AT) transaction set for approved surcharges to be routed to a distributed ital application system host platform.

- IF a Customer Extension/Termination, functional group type EX is :eived from a Trading Partner Company for a defined Profile ID AND the BCO or iuster Code is different than on the ARMS centralized database, then generate a ne :omatic pseudo-rental Authorization Change (AT) transaction set containing only ar iuster detail (ADJDOl) record format for an adjuster/BCO change to be routed to a stributed rental application system host platform. This is done to update Bill-Tc stomer information in the rental system database files for this rental transactior the EC00ATV1 program processing, since the EC00EXV1 program processing does not late Bill-To Customer information in the rental system database files. (See improvement Opportunities number 3 below. )

""' -IF processing^' an Extension, move an "E" to the Action Code in the )55V1 external data structure. When a termination date has been sent, update the { Auth (AWAUDY) field in file AMAUTD.

Calculate the total number of days authorized by using the Termination _.e and Rental Start Date adding 1 to the calculated days to receive the correct nber of days authorized. If the calculated amount is greater than the Day Auth ≥ld, move an "E" to the Action Code in the AM055V1 external data structure.

If the calculated amount is less than or equal to the Day Auth field, e a |ξτij$ to the Action Code in the AM055V1 external data structure.

- Based on the trading partner profile, generate new automatic rental tension days transaction set in response to a Request for Extension (RE) to be uted to a distributed rental application system host platform.

- IF processing an Opening Rental Notification {'RN') functional group pe, IF the existing customer number on the transaction set internal header is fou the ARMS BCO for RMS (Rental Management System) file write a record to the ARMS S (Rental Management System) File (AM002P) so that RMS will be notified of the op αtal contract/ticket that they must manage from their centralized location.

IF processing a Rental End ('RN') transaction set AND this is the first osing rental notification (AMAUTD's Rental End Date = 0) AND IF the associated

Confidential Page 30 of 246 8/11/00 ARMS Process Report

ISPRl profile file record's Remittance Indication Flag (P1FG14) field is equal to , then execute the ARMS Generate Transaction Credits (AM1080V1) program passing : Transmission Control Sequence ID Number, Group Control Sequence ID Number, Vendo nsaction ID and the Execution Code of 'R' (for Rental Notification) .

- IF processing a Payment Advice ( 'PM' ) transaction se , then execute th IS Generate Transaction Credits (AM1080V1) program passing the Transmission Contro [uence ID Number, Group Control Sequence ID Number, Vendor Transaction ID and the icution Code of ' ' (for Payment Advice).

-After the file updates and before the next data queue entry is read, an the Group Type is not §OE^.

-Complete the build of the data queue entry record.

-From the APPD01 format, move the Profile Id, Customer insaction Id, Vendor Transaction Id, -Group Type, Date, and Time to sir appropriate fields in DQAM55V1 external data structure, AM055X.

-If Transaction Type (AM055X) is blank, move an glgnternal to field.

-Send the data queue entry to DQAM55V1. -Clear the AM055X format for the next record.

©Notes:

Currently, ALL transaction sets (received from trading partners, receive >m rental systems - i.e., inbound, outbound and transfers) will be processed by .s program, after editing for updating to the database and routing (to a trading rtner or a rental application system) .

When the Rental Management Trading Partner sends an extension transactic : for an existing Vendor Transaction ID with a different Customer Transaction ID in the value in the ARMS Cross-Reference (AMXREF) file record's CUSTOMER INSACTION ID (XACTID) field, then this field change should occur and allow the CREF file record's XACTID field to be updated with the new/different Customer insaction ID value. All incoming transaction sets should allow a change of the stomer Transaction ID. Remittance Advice ('RM') transaction sets will not be :luded because this would require a change in the way RM's are processed.

^• " When a request^' for cancellation ('RC') transaction .set is processed for incompletely open rental contract/ticket (prewrite/unit-pend) , this 'RC insaction set is not sent to the trading partner. In most cases this is correct, /ever when the ARMS Cross-reference file record is made irretrievable by padding ϊ rental location value with the repeating "X" character, the request for icellation transaction set will be sent. For some profiled ARMS Trading Partner npanies, the RC is converted to a CN before being sent.

The ARMS system will now enable electronic invoices,, payments and nittances (processed here) to be sent/received for non-ARMS Rental Management iding Partners that are Direct Billing/Remittance Trading Partners, such as inessee Valley Authority (an Enterprise Fleet Services customer) ; and AAA of Lifornia. Therefore, ARMS will receive a data queue entry to generate an ≥ctronic invoice (and create an associated ARMS Rental Transaction Cross-Referenci 4XREF) file record) when the trading partner never sent to ERAC (via ARMS) any Ltial rental authorization.

When a Request for an Authorization is sent to ARMS Trading Partner Ttpany after the initial request, and the transaction is still in an unconfirmed atus (U) , an RA-Add will be generated. IF the transaction is at a confirmed stati ) but still unauthorized an RA-Change will be generated even if no changes have

Confidential ^: Page 31 of 246 8/11/00 ARMS Process Report m made to the data. If the transaction is at a confirmed and Authorized status , an RA-Change will be generated only if there was a change in the data.

©Files : (CRUD)

- AMSET (-R— )

- ARMSPRl (-R--)

- ARMSPR3 (-R-)

- AMXBCO (-R—)

- AMPGMCTL (-R—)

- AM002P (CR—) ARMS: RMS FILE

- AM003P01 (-R—) ARMS RMS BCO FILE

- AMAPPS (C—)

- AMPACK (C-—)

- AMADJD (CRU-)

- AMAUTD (CRU-)

- AMCOMD (CR—)

- AMIEBD (CRU-)

- AMIEBH (CRU-)

- AMIEBT (CRU-)

- AMINSD (CRU-)

- AMRMTD (CRU-)

- AMRNTD (CRU-)

- AMRPRD (CRU-)

- AMRATD (CRUD)

- AMSURD (CR-D)

©Embedded Data/Constants :

•YES'

'NO •

'AM0046V1 '

•RECORD DELETED'

•XXXXXXXXXX' (to pad ARMS Rental Transaction Cross-Reference File word's RENTAL LOCATION with X's to make it irretrievable)

'AUTHORIZATION EXPIRED' (as COMD01 record format's COMMENT comment te: rrently not referenced, unsure of intent.)

^■ ' Enterprise Customer Numbers for ARMS Trading Partner Insurance Company- s Angeles Area Locations and ARMS Trading Partner Insurance Company's Branch Claii Eice Code for RMS output:

'ALL3233' and '2040' Santa Ana/Tustin, California ^■ALL3221' and '1340' Torrence, California

.and Format Names/IDs::

^■APPD01' 'AD0D01' 'ADJD02' •AUTDOl' 'CANDOl' •CBKC01' 'CBKD01' •CRED01' 'COMD01' • ELCDOl ' 'ERRDOl' ' IEBD01 ' ' IEBH01 '

Confidential Page 32 of 246 8/11/00 ARMS Process Report ⁱ EBT01 ' ^■ INSD01' 'OFFD01 ' • PMTD01 ' 'RATDOl' 'REND01' •RMTD01' •RNTD01' •RNTD02' •RPRDOl' ' SURDOl ' •VEDD01'

©Improvement Opportunities:

1.) Convert from standard ILE RPG program to an ILE program with multipl 5 RPG modules or service programs.

2.) Delete the 'AM0046V1 • constant and use the Program Status Data ructure's left-justified PROGRAM ID value for the same purposes.

3. ) There is hard-coded logic to check IF ARMS Trading Partner Insurance npany Insurance Company customer authorization extension ('EX') transaction set AN ϊ adjuster or BCO change that is different than the centralized ARMS rental insaction database Adjuster Detail (AMADJD) file data, then to automatically lerate a "pseudo-" Authorization ('AT') Change transaction set with only an juster detail (ADJDOl) record. However, since this is information that is only fo specific X12 EDI standard compliant trading partner, that this special logic shoul removed from this program and externally profiled in the EDI Translation and :erface/Mapper software to cause generation of the additional 'AT' Change when an ;ension/Termination transaction set is received. Additionally, this EDI inslation and Interface Mapper software could execute an ARMS centralized database :rieval inquiry service utility program to retrieve specified information from the DJD file. Then this interface/mapper software could determine if this transactic :'s adjuster information is different than the existing database file's informatic ϊ if true, generate the additional 'AT' Change. This would add an 'AT' Change ictional group transaction set to be output, along with the 'EX¹ from the same EDI msmission envelope, and.it would add to the transaction load between AMOOIOVI an )046Vl'ptograms, inclusive. However, the benefit of standardizing the transactior processing within AM0046V1 and moving profile-specific logic to the EDI inslation interface/mapping software would be greater than having hard-coded withi 5046V1 program.

4.) There is currently an undesirable situation that occurs within this Dgram. When any trading partner sends an authorization extension/termination ansaction set, the adjuster detail is required to add callback detail note comment the rental application database with the name of the adjuster, changing the open atal contract/ticket• s CURRENT AUTHORIZATION DATE field value^'. However, the juster making this change in this value may not be the claims adjuster assigned tc αage the direct billing payment authorization for this rental contract. The juster making the extension/termination may be another adjuster taking on the tensions temporarily when the primary assigned adjuster is unavailable (i.e., day f due to vacation, illness, etc.), but that the primary assigned claims adjuster f record" was not intended to be changed. Currently, the adjuster information in e Bill-To information within the rental contract is not updated by an tension/termination transaction set's adjuster information, but the centralized MS database adjuster detail (AMADJD) file is. This is erroneous to update AMADJD an extension and this logic should be removed from AM0046V1 program. (A new issi 11 be submitted by Gina Miller, ARMS Technical Mgmt. staff to request this change

Confidential Page33 of246 8/11/00 ARMS Process Report re er, if AM0046V1 program's extension/ ermination logic is revised, then this me should be considered. )

5. ) Drop the constant detailed below and replace with attributes/field .ues within the ARMS Trading Partner Profile's Branch Claims Office / Enterprise itomer ID Cross-Reference (AMXBCO) file. Likewise, add the maintenance of these slds to the AMXBCO maintenance program and screen display file record format AMIO) .

>cess srarchical numeric ID: 1.1.1.1.3.5 led name: le: DTQ Input to AM0025 (DQAM25V1) iment: ©Definition: DQAM25V1 is a data queue used to provide input for PGM

>025V1 which validates transaction set record formats.

>cess irarchical numeric ID: 1.1.1.1.3.6 led name: ne: DTQ Input Data Queue to AM0030 (DQAMSET1) nment: ©Definition: DQAMSET1 is a data queue used to provide input for PGM

)030V1 which vilidates transaction set record formats data types.

>cess irarchical numeric ID: 1.1.1.1.3.7 led name: tie: DTQ Input Data Queue to AM0040 (DQANDTL1) nment: ©Definition: DQANDTL1 is a data queue used to provide input to PGM

)0 0V1 which validates transaction set record format data.

jcess

≥rarchical numeric ID: 1.1.1.1.3.8 led name: ne: DTQ Input Data Queue to AM0046 (DQAM46V1) nment: ©Definition: DQAM46V1 is a data queue used to provide input to PGM

D046V1 which update the ARMS database and routes the transaction.

Dcess

≥rarchical numeric ID: 1.1.1.1.3.9 ied name: me: DTQ Input to Program AM0100 (DQAMAPl) ranent: ©Definition: DQAMAPl is a data queue used to input data to PGM AM0100 ich distributes routed transactions from the centralized host processing machine.

ocess erarchical numeric ID: 1.1.1.1.3.10 ded name: AMPSSR me: PGM Perform Internal Error Paging and Messaging (AMPSSR)

Confidential Page 34 of 246 8/11/00 ARMS Process Report mment: ©Definition: This is the ARMS *PSSR program exception error paging & ssaging program (written in RPG/400 - Original Program Model) .

©Purpose: This program's purpose is to output the error occurrence to t PGMERR Program Error Log file and if the error is not from a program executing on e "DEV" (development) machine, then to notify the ARMS On-Call and Backup persons a sending a pager message and sending an 'e-message' via call to MS0010 program o e platform name, program name and the error occurrence. This information will aid e ARMS On-Call person responding to resubmit any needed never-ending program job to the ARMS subsystem on the appropriate host computer system. This information 11 also cause them to research the dump taken in the previous program for the icompletely processed transaction specific information that it had been processing ten the program halted or abnormally ended.

©Operational Method: This program outputs the passed entry parameters' ilues error occurrence to the AMPGMERR Program Error Log file. If the error is nc i the "DEV" (development) host platform, then sending a pager message to the ARMS rimary and Backup On-Call pagers and sending an 'e-message' via call to MS0010 rogram of the platform name, program name and the error occurrence.

©Files: (CRUD)

- AMPERT (-R—) , accessed by AMPERTL1 logical access view.

- ANDQER (-R--) , accessed by ANDQERL2 logical access view.

- AMPGMERR (C )

- FILE80 (C )

©Notes: This program is used within every program's *PSSR program icception subroutine.

rocess ierarchical numeric ID: 1.1.1.1.3.11 oded name: CCDATE ame: PGM Validate Date and Convert Format (CCDATE) omment: ©Definition: CCDATE is a date validation, conversion and manipulation allable OPM RPG program. .

©Purpose: Executed from many ARMS programs for many purposes. The mos ommon purposes are: to validate dates; convert formats; derive a future date by omputing the adding provided days to a given date value; or, to derive the age of enter by computing the number of years between the current date and a renter's da if birth. In a majority of programs, this program is executed to retrieve the :urrent system date or timestamp in the MMDDYYYY or MMDDYY format and reforma -it "YYYMMDD format, or, to retrieve the day of week, such as required in the ARMS-to- kRMS Trading Partner Company Communication Sender / Receiver (AM)***COM) program.

Validation is done throughout many ARMS programs, such as in the Valic transmission Envelope (AMOOIOVI) program to validate the Transmission Date or in 1 talidate Transaction Set Record Format Data Types (AM0030V1) program's Edit Dates subroutine specifically to validate the date values for the following record form^; late value fields:

Authorization Detail's (AUTD01) Authorization Expiration Date, Date 3irth and Pickup Date

Renter Detail's (RNTD02) Date of Loss Insured Detail's (INSD01) Policy Expiration Date Cancellation Detail's (CAND01) Cancellation Date Callback Detail's (CBKDOIVI) Callback Origination Date -<—c _*:«ι Page 35 of 246 8/11/00 ARMS Process Report

Extension/Termination Detail's (CRED01) Termination Date and Renter -ified Date

Rental Detail's (REND01) Rental Start and End Dates

Rental Segment Detail's (RATD01) Effective Dates of Rental Segments 1 rough 4

Invoice Header's (IEBH01) Billing Start and End Dates

Payment Detail's (PMTD01) Payment Date

©Operational Method:

Before the CCDATE is called, the parameter fields must be set by the Lling program. It is recommended that you do a clear the DTPARM external data ructure subfields before any field values are loaded to insure that all fields ha ϊn initialized.

If a date conversion from MMDDYY to YYMMDD format, simply move the input :e value to the From-Date (DTFRDT) input field after all the fields have been ϊared and execute the CCDATE program. The outputted To-Date returned in DTTODT LI be in YYMMDD format.

The following fields will be output by CCDATE, so it is not necessary it you fill them in. They are: DTFMTD, DTWKDY, DTMNTH, DTSTNG, DTMSID, and DTMSTX.

DTDAYS is not necessary for action code 'C and will be zeroed out by )ATE. DTDAYS will be filled in by the CCDATE program's exectuion when the action le is 'D' .

However, since AM0030V1 is requiring only date value validation, the jgram is executed after loading the following parameter subfield values in the Llowing manner after all subfields were cleared/initialized:

Load 'C (Convert) to ACTION CODE (DTACCD)

Load the DATE TO VALIDATE (in YYYYMMDD format) field value to FROM- TE( DTFRDT)

Load the number 7 (YYYYMMDD) to the FROM-DATE-FORMAT (DTFRFT)

Load the number 6 (DDMMYYYY) to the TO-DATE-FORMAT(DTTOFT)

Execute the program

Check the contents of the Error Message ID (DTMSID). IF not blanks, =sn the FROM-DATE field value was invalid.

©Notes:

Documentation for usage can be found on the AS/400 in the L.IB/QEISSRC/TLS.DAT text source member.

NEVER Use the DATE MULTiplied. by 1000.01 or 100.0001 to CONVERT! (Lack precision and high overhead mathematical computation overhead* )

It should do hopefully everything anyone would need from such a program r any date value. Below is the explanation of its single parameter and how to usⁱ e program.

The parameters have been set up as in a empty database file called DTPA at is used as an externally defined data structure on an input specification on t ogram' s source code that causes the compiler to copy the subfield names, tributes, and starting positions. This is done so that a programmer can copy the rameters in as an external data structure instead of having to remember what orde e parameters should be in and what length the fields are. The explanation of the ternal data structure DTPARM parameter data elements (subfields) passed as a sing rameter field are:

Confidential Page 36 of 246 8/11/00 ARMS Process Report

DTACCD - (1) - Processing Action Code possible values: *C - avert (DEFAULT)

' - Compute the Days Difference between inputted dates

' - Add inputted Days to inputted From-Date

DTFRDT - (8,0) - From-Date (DEFAULT is UDATE)

DTFRFT - (1,0) - From-Date Format possible values: 1

YMDDYY (Month, Day, Year) (DEFAULT)

- DDMMYY (Day, Month, Year)

- YYMMDD (Year, Month, Day)

- YYDDD (Julian format)

- MMDDYYYY

- DDMMYYYY

- YYYYMMDD

- YYYYDDD (Julian format)

- MMOOYY (Use this format to have the program determine the last day of the ≥cified ath and format it based on the To format. )

STOTE: This format is only valid for this From-format!

DTTODT - (8,0) - To-Date

DTTOFT - (1,0) - To-Date Format possible values:

WIDDYY (Month, Day, Year)

- DDMMYY (Day, Month, Year)

- YYMMDD (Year, Month, Day) (DEFAULT)

- YYDDD (Julian format)

- MMDDYYYY

- DDMMYYYY

- YYYYMMDD

- YYYYDDD (Julian format)

DTDAYS - (7,0) - Number of Days to Add/Subtract or the computed ys Difference (+/-)

DTFMTD - (10) - Displayed Formatted Date

DTSEP - (1) - Display Separator (used in DTFMTD, i.e., ckslash, hyphen, or period)

DTWKDY - (9) - Day of Week (Sunday, Monday, etc.)

DTMNTH - (9) - Month Name (January, February, etc.)

DTSTNG - (30) - Formatted Date String possible values:

^■ - Month Day, Year (i.e., January 01

92)

' (DEFAULT) - Day-of-week Month Day, Year (i . e . , Wednesday January 01 , 1992) Confidential Page 37 of 246 8/11/00 ARMS Process Report

DTMSID - (7) - Error Message ID ^"

DTMSTX - (80) - Error Message Text

©Improvement Opportunity:

The execution of this (CCDATE) program would be unnecessary if all of tl IS programs that currently use this program were converted from the OPM RPG/400 tc S RPG/IV program and these input date fields were attempted to be loaded into date pe work fields. Also, any unsuccessful operation would need to be monitored for ≥cific error exception types.

Dcess

≥rarchical numeric ID: 1.1.1.1.3.12 led name: AM2010V1 ne: PGM Retrieve Cross-reference (AM2010V1) nment: ©Definition: This program is the callable ARMS generic Cross-Reference

Le Record Inquiry program.

©Purpose: To retrieve the associated ARMS Rental Cross-Reference File 2ord when passed one of the following four input combinations: the ARMS VENDOR ANSACTION ID; the ARMS TRADING PARTNER COMPANY PROFILE ID and the CUSTOMER \NSACTI0N ID; the RENTAL LOCATION and the RENTAL CONTRACT/TICKET ID; or, the RENT7 2ΑTION and the RENTAL BRANCH RESERVATION ID.

©Operational Method:

1.) The RENTAL LOCATION is always required and either a non-blank TICKE. or RESERVATION ID must be passed.

IF RENTAL LOCATION, TICKET ID and RESERVATION ID are blanks, then load a RETURN CODE with 'E' (Error) .

2.) IF Rental Location and Reservation ID are passed with the program LI, use AMXREFL2 to retrieve the requested ARMS Cross-Reference File record. a.) IF Ticket number is also passed with the program call, retrieve a recor using AMXREFL2.' Then validate the Ticket number passed with the program call against the Ticket data field XATKNO. b.) IF passed TICKET ID and retrieved TICKET ID are different, then ad the RETURN CODE with 'T' (Ticket ID Mismatch) and return to the calling prograr c.) IF the passed TICKET ID is same as the TICKET ID found for. he servation in the ARMS Cross-Reference File, then update all fields in the parameti st from AMXREFL2, set the RETURN CODE to blanks (blanks indicate successful) and turn to the calling program.

3.) IF non-blank RENTAL LOCATION and TICKET ID are passed with the ogram, use AMXREFL1 to retrieve the data.

IF no record found for RENTAL LOCATION and TICKET ID, then load the TURN CODE with 'E' (Error) .

4.) If an ARMS COMPANY PROFILE ID is passed with the program call and a cord is retrieved, compare this value with XACUID in AMXREFLn.

IF they are different, change the RETURN CODE to 'P' for 'Profile Error d return to calling program.

Confidential Page 38 of 246 8/11/00 ARMS Process Report

5.) IF non-blank ARMS COMPANY PROFILE ID and CUSTOMER TRANSACTION ID an ssed, retrieve record from AMXREFL3. a.) IF TICKET ID / RESERVATION ID is passed, compare these with valu trieved from AMXREFL3.

IF they do not agree, change return code to 'T' / 'R'. b.) IF RENTAL LOCATION is passed, compare this value with value trieved from AMXREFL3.

IF they do not match, change return code to 'L' .

6. ) IF an ARMS VENDOR TRANSACTION ID is passed, retrieve record from XREF. a.) IF an ARMS COMPANY PROFILE ID is passed with the program call am record is retrieved, compare this value with the associated field in the retrievei MS Cross-Reference File.

IF they are different, change the return code to *P' for 'Profile Error d return to calling program. b.) IF RENTAL LOCATION is passed, compare this value with the AMXREF lue. IF they are different,change return code to 'L'. c.) IF TICKET ID or RESERVATION ID is passed, compare these values th values retrieved from AMXREF.

IF they do not agree, change RETURN CODE to 'T' / 'R' .

7. ) IF a record is retrieved from AMXREF or any of these logical files sed upon the file use hierarchy, and additional data fields are passed, and more an one data mismatch occurs, change the return code to 'M' for multiple errors.

Hierarchy for record retrieval:

^■"^'• 1.) IF ARMS VENDOR TRANSACTION ID is passed, and any other data fields, trieve from AMXREF.

2.) IF ARMS COMPANY PROFILE ID and CUSTOMER TRANSACTION ID are passed, d any other data fields (except VENDOR TRANSACTION ID) , retrieve from AMXREFL3.

3. ) IF RENTAL LOCATION and RESERVATION ID are passed, retrieve from

XREFL2. 4.) IF RENTAL LOCATION and TICKET ID are passed,- retrieve from AMXREFL1

RETURN CODE possible values: blank : Successful retrieval / edit

L : Location passed is blank / invalid

# : Ticket/Reservation passed is blank

T : Ticket passed, unmatched on AMXREF record

P : Profile passed, unmatched on AMXREF record

E : No AMXREF record found

M : Multiple errors

Confidential Page 39 of 246 8/11/00 ARMS Process Report

©Notes: No exception error handling is specified.

This executable program is executed by many other ARMS programs that an ocessing a ARMS transaction request to retrieve information from the ARMS Rental oss-Reference File. This program is currently called with parameters by the llowing programs: AMLCXLT, AMRTVSQ, AM0020V1, AM0021V1, AM0030V1, AM0040V1, 0070V1, AM0120, AM0129, AM0150, AM0900, AM1080V1, AM1085V1, AM5010, AM5015, and AM16. The parameters used in calling this program are the following:

Output 1 character RETURN CODE Input/Output 20 character VENDOR TRANSACTION ID Input/Output 5 character ARMS TRADING PARTNER COMPANY PROFI]

Input/Output 20 character CUSTOMER TRANSACTION ID

Input/Output 10 character RENTAL LOCATION

Input/Output 6 character RESERVATION ID

Input/Output 6 character TICKET ID

Output 1 character STATUS CODE

Output 8/0 numeric STATUS CODE LAST CHANGED DATE

Output 6/0 numeric STATUS CODE LAST CHANGED TIME

Output 10 character STATUS CODE LAST CHANGED PROGRAM

Output 1 character MACHINE ID

Output 10 character BRANCH CLAIMS OFFICE CODE

Output 1 character RENTAL SYSTEM SOURCE ID

Output 8/0 numeric RECORD ADD DATE

Output 6/0 numeric RECORD ADD TIME

Output 10 character RECORD ADD PROGRAM ID

Output 8/0 numeric RECORD CHANGE DATE

Output 6/0 numeric RECORD CHANGE TIME

Output 10 character RECORD CHANGE PROGRAM ID

©Files : (CRUD)

- AMXREF (-R—) ARMS Cross-Reference File, keyed by Vendor ansaction ID

- AMXREFL3 (-R—) ARMS Cross-Reference File, keyed by Company Profile and Customer Transaction ID

- AMXREFL1 (-R—) ARMS Cross-Reference File, keyed by Rental Location and Rental Ticket ID

- AMXREFL2 (-R—) ARMS Cross-Reference File, keyed by Rental Location and Rental Reservation ID

©Improvement Opportunities:

Replace the internally defined parameter fields in this program and all ograms executing this program with a database file with no record to be used as ai ternally defined data structure so that only one definition of the parameter's da ements exist, along with comments on their purpose and possible values.

Replacing the execution of this (AM2010V1) program with the ARMS quire/Update Cross-Reference File record (AMIOIOVI) program in many other program, it is called in "Inquiry" mode.

ocess erarchical numeric ID: 1.1.1.1.3.13

Confidential Page 40 of 246 8/11/00 ARMS Process Report

Led name: AM0090V1 ιe: PGM Generate External Error (AM0090V1) mnent: ©Definition: This program is the ARMS called External Error Handler igram.

©Purpose: To generate a single Error (ER) group type transaction data se be sent to the Rental Management Trading Partner to indicate that the ARMS host lected a transaction data set received from their host application system. The ror is also logged to an error log file.

©Operational Method:

- Verifies the passed input parameter error reason codes (maximum 20) it are not equal to ' 99 ' against the ARMS Error Code and Description Table IERRTBL) file for valid error codes and returns an "A" for accepted or an "R" for iected. If the passed error reason code does not exist is this file, the ARMS >gram Exception Handler (AMPSSR) program is executed to notify the ARMS On-Call iff of the program-to-program referential discrepancy and the erroneous error code Lue is concatenated with the text "ERROR CODE IS INVALID" and this resulting value written to the ARMS Error Log (AMERRLOG) file record's FILLER field and its ERROB )E field is loaded with the value "99".

- Write Error (ER) group type transaction data set records to one of twc ssible transaction data set output files. If the program is being executed on the itralized ARMS host computer system platform, it will write the output record rmats to the ARMS Transactions To Be Packaged (AMPACK) transaction file as itralized transactions to be packaged for sending. If this program is executing c Ϊ distributed rental computer system platform, then it will write the output recor rmats to the ARMS Distributed Transactions To Centralized Input (ANDIST) insaction file for the distributed system transaction to be sent to the centralize stem.

- Sends the written Error group type transaction set record formats' kej Lue to the output file's associated data queue. If the records were output to the ?ACK file, then the key is sent its associated Transaction Packaging Input 2AMPKG) data queue. If the records were output to the ARMS (ANDIST) file, then tl is sent its associated Transaction Distributed-to-Centralized Input (DQANDST)

;a queue.

- Before exiting the program, a record is also added to rejected ansactions error log file (AMERRLOG) . that will appear on the ARMS Error Log Repo. CL817/AM5000) and the ARMS Error Log Inquiry Screen (CCAM14) .

©Notes: This program is only executed by other ARMS never-ending agrams that have validated a received transaction data set as being in error.and jected it from further processing to eventually update the Rental Systems plication database. This program is currently called with parameters by the llowing programs: AM0020V1, AM0021V1, AM0025V1, AM0030V1, and'.ECOOEXVl . (NOTE: is program has been replaced in many other programs that it had been called from ] lling the newer ARMS Internal/External Error Handler 'AM0098' program.) The rameters used in calling this program are the following:

Input 5 character COMPANY ID

Input 9/0 numeric TRANSMISSION CONTROL ID#

Input 5/0 numeric GROUP CONTROL ID#

Input 2 character GROUP TYPE CODE

Input 20 character CUSTOMER TRANSACTION ID

Input 20 character VENDOR TRANSACTION ID

Input 6 character FORMAT ID IN ERROR

Confidential Page 41 of 246 8/11/00 ARMS Process Report

Input 40 character ERROR REASON CODE(S) (2 characters per le/20 occurrences maximum)

Output 1 character PROGRAM RETURN CODE (Possible values: Rejected - default, or A=Accepted)

Input 10 character PROGRAM NAME IN ERROR (Rejecting the insaction processing)

©Files: (CRUD)

- AMPACK (C )

- ANDIST (C—-)

- AMERRTBL (-R—)

- AMERRLOG (C )

©Embedded Data: (Constants) "ERROR CODE IS INVALID" as suffix for invalid error code.

©Improvement Opportunity:

Since the text is the same in all of the files, move the constant's errc ssage text into an added record in the AMERRTBL file with the ERROR CODE value of inks that this program, AM0090V1 Generate ARMS External Error and AM0098 ARMS Errc idler program could all retrieve.

jcess ϊrarchical numeric ID: 1.1.1.1.3.14 led name: AM0097V1 αe: PGM Handle Internal Error (AM0097V1) nment: ©Definition: This program is the ARMS called Internal Error Handler pram.

©Purpose: To notify the ARMS Application Development Department On-Call rsonnel of a transaction error condition that requires research and possible manue ;ervention.Error (ER) group type transaction data set in response to a rejected insaction data set received from a Rental Management Trading Partner host plication system and to log the error to an error log file.

©Operational Method:

- Verifies each non-blank passed input parameter error reason code that not equal to '99' or '00' exists in the ARMS Valid Error Codes table file RRTBL) and returns an .'A' for accepted or an 'R' for rejected. If the passed ror reason code does not exist is this file, the ARMS Program Exception Handler ttPSSR) program is executed to notify the ARMS On-Call staff of, the program-to- Dgram referential discrepancy and the erroneous error code value is concatenated th the constant text "ERROR CODE IS INVALID" and this resulting value is written e ARMS Reservation Transfer (and Outbound) Errors Log (AMXFRLOG) file record's LLER field and its ERROR CODE field is loaded with the value '99* (Unknown) .

- If the passed CALLING PROGRAM ID is NOT 'AM0046V1', then execute call the ARMS Program Exception Handler 'AMPSSR' program, passing the CALLING PROGRAM and the Transaction's 96-character key value that is comprised of the passed

ANSMISSION CONTROL ID#, GROUP CONTROL ID#, GROUP TYPE CODE, CUSTOMER TRANSACTION and VENDOR TRANSACTION ID, padded with blanks.

©Note: This program is only executed by other ARMS never-ending progra called programs that cannot process a ARMS transaction request as being in error

Confidential Page 42 of 246 8/11/00 ARMS Process Report not doable and rejected it from further processing. This program is currently Lied with parameters by the following programs: AM0025V1, AM0030V1, AM0047V1, )062V1, AM1080V1, AM2090V1, CC2090V1 and EC2090V1. (NOTE: This program has been ilaced in many other programs that it had been called from by calling the newer IS Internal/External Error Handler 'AM0098' program,) The parameters used_, in Lling this program are the following:

Input 5 character COMPANY ID

Input 9/0 numeric TRANSMISSION CONTROL ID#

Input 5/0 numeric GROUP CONTROL ID#

Input 2 character GROUP TYPE CODE

Input 20 character CUSTOMER TRANSACTION ID

Input 20 character VENDOR TRANSACTION ID

Input 6 character FORMAT ID IN ERROR

Input 40 character ERROR REASON CODE(S) (2 characters per le/20 occurrences maximum)

Output 1 character PROGRAM RETURN CODE (Possible values:

Rejected - default, or A=Acceρted)

Input 10 character PROGRAM NAME IN ERROR (Rejecting the insaction processing)

©Files: (CRUD)

- AMERRTBL (-R--)

- AMXFRLOG (C )

©Embedded Data: (Constants) "ERROR CODE IS INVALID" as suffix for invalid error code.

©Improvement Opportunity:

Since the text is the same in all of the files, move the constant's errc ssage text into an added record in the AMERRTBL file with the ERROR CODE value of anks that this program, AM0090V1 Generate ARMS External Error and AM0098 ARMS Errc idler program could all retrieve.

Dcess

≥rarchical numeric ID: 1.1.1.1.3.15 ied name: CRTF80 ne: PGM Create MS01 (CRTF80) mment: ©Definition: This is the executable OPM CL program to Create and Clear

Es temporary Send "e-Messages" Work (FILE80) Message Detail Lines file.

©Purpose: To duplicate, if necesary, and clear a temporary output -work le prior to outputting "e-message" detail message lines from an executing program be used as input to a subsequent execution of the Send "e-Message" (MS0010) ogram.

©Operational Method:

Checks the existence of a ISS: SM0003 80-position work file (FILE80) in is active job session's QTEMP Temporary Job Session library.

IF the file does not exist, then retrieve the library from this file fr y library within this job session's library list. Then create a duplicate copy o is file in the QTEMP Temporary Job Session library without copying any data withi e file.

Confidential Page43 of246 8/11/00 ARMS Process Report

Clear the 80-position work file (FILE80) in this active job session's EMP Temporary Job Session library.

Execute an override of any specified 80-position work file (FILE80) in iis active job session for the scope of the entire job to 80-position work file ^?ILE80) in this active job session's QTEMP Temporary Job Session library and ϊquentially block its access with 409 records per block.

©Notes:

This program was created and is stewarded by the Information Systems αpport Department's ISA Group.

No parameters are used in the execution of this program.

©Files: (CRUD)

FILE80 ( ) File is created in the QTEMP library if necessary and hen cleared.

rocess ierarchical numeric ID: 1.1.1.1.3.16 oded name: RTVMSGTS ame: PGM Retrieve Message Status (RTVMSGSTS) omment: ©Definition: This is an executed 0PM CL program to retrieve the status he Enterprise Rent-A-Car Message Application System.

©Purpose: To retrieve the status of the Enterprise Rent-A-Car Message pplication System before execution of the Send a Message (MS0010) program.

©Operational Method:

Load the default value 'ER' (Error) to STATUS CODE.

^■"^• IF currently executed on the "DEV" machine, then retrieve production jbjects from ELPRD library instead of the ELLIB library.

Retrieve the logical value of the MESSAGE SYSTEM STATUS from its Statt lata area (DAMSGSTS) .

IF the MESSAGE SYSTEM STATUS is "ON"

('1' or True), then the MESSAGE SYSTEM is UP. Then check the DDM and DPTICONNECT/400 STATUS values on the 'OPTICON' machine/system platform. IF both i DK, then pass 'OK' to STATUS CODE.

IF the MESSAGE SYSTEM STATUS is "OFF" ( • 0 ' or False) , then the MESSAG1 SYSTEM is DOWN.

Check if the Temporary Messages Hold Files (MSHDR, MSTXT, MSNOTIFY) a: exist and in which library they were found. IF they do exist and were found in t ELSYSOVR library, then pass 'TF' to STATUS CODE.

©Notes:

This program was created and stewarded by the Information System Supp (ISS) Department's ISA-Applications Group.

F fi^£ Page 44 of 246 8/11/00 ARMS Process Report

This program is currently executed by the following programs prior to tfc ≥cution of the Send e-Message program:

ARMS *PSSR Program Error Paging & Messaging (AMPSSR) program

ARMS Application Edit/Router (AM0040V1) batch program

ARMS Non-Inbound Format Data Replacement Alteration (AM0047V1) program

ARMS Internal/External Error Handling (AM0098) program

The program is executed with one output parameter value of a 2 character \TUS CODE that has one of the following values:

'OK' - Message System is UP (available) and DDM Connections Tested.

'TF' - Message System is DOWN (unavailable), but the Temporary Messages Ld Files are in place to receive messages that are being requested to be sent.

•ER' - Either Message System is down and the Temporary Messages Hold Les are NOT in place to receive messages that are being requested to be sent or Dl mection FAILED.

©Files: (CRUD) (All are checked for existence and which in library ≥y were found.)

MSHDR - Message System Message to be Sent - Header/Abstract MSTXT - Message System Message to be Sent - Detail Text Lines MSNOTIFY - Message System Message to be Sent - Users/Distribution

Dcess

≥rarchical numeric ID: 1.1.1.1.3.17 led name: SNDEMSG ne: PGM Send Enterprise Message (SNDEMSG) nment: ©Definition: This is the executable ILE RPG command for sending terprise message

©Purpose: To send previously outputted "e-message" to the specified ART -Call Message Distribution List or the ARMS Technical Management from an another Dgram.

©Operational Method:

Using the QTEMP library temporary work files as input for the formateed ssage, read the Message Program - Send Msg to employees file to obtain the messag< stribution.

©Notes:

This program was created and stewarded by the Information System Supporl SS) Department' s ISA-Applications Group.

ocess erarchical numeric ID: 1.1.1.1.3.18 ded name: AM0098 me: PGM Handle Internal/External Error (AM0098) mment: ©Definition: This is the newer ARMS Internal/External Error Handling ogram. This program performs functions beyond both the AM0090V1 and AM0097V1 ogram.

Confidential Page 45 of 246 8/11/00 ARMS Process Report

©Purpose: To notify the ARMS Application Development Department On-Call rsonnel of a transaction error condition that requires research and possible manue ;ervention. Error (ER) group type transaction data set in response to a rejected insaction data set received from a Rental Management Trading Partner host jlication system and to log the error to an error log file.

(NOTE: This program will replace AM0090V1 and AM0097V1 with the new errc idling process. Error records are written to the error files AMERRLOG and ANDQER 1 transaction files ANDIST or AMPACK depending on what machine the program is rrently running on. The program currently contains both the old and new error idling logic.)

©Operational Method:

- Verifies each non-blank passed input parameter error reason code that not equal to '99' or '00' exists in the AMERRTBL Valid Error Codes table file anc

;urns an 'A' for accepted or an 'R' for rejected. If the passed error reason code ΪS not exist is the AMERRTBL file, AMPSSR program is executed to notify the ARMS -Call staff of the program-to-program referential discrepancy and the erroneous ror code value is concatenated with the constant text "ERROR CODE IS INVALID" and Ls resulting value is written to the AMXFRLOG file record's FILLER field and its IOR CODE field is loaded with the value '99 • (Unknown) .

- If the passed CALLING PROGRAM ID is NOT 'AM0046V1', then execute call •AMPSSR' passing the CALLING PROGRAM ID and the Transaction's 96-character key

Lue that is comprised of the passed TRANSMISSION CONTROL ID#, GROUP CONTROL ID#, 5UP TYPE CODE, CUSTOMER TRANSACTION ID and VENDOR TRANSACTION ID, padded with inks.

©Notes: This program is only executed by other ARMS never-ending agrams or called programs that cannot process a ARMS transaction proceccing requei being in error or not doable and rejected it from further processing. This agram is currently called with parameters by the following programs: AM0040V1, 3046V1, AM0060V1, AM0061V1. (NOTE: This program is yet to replace the call to 5097V1 older Internal Error Handler program in many other programs: AM0025V1," 303OV1, AM0047V1, AM0062V1, AM1080V1, AM2090V1, CC2090V1 and EC2090V1.) The rameters used in calling this program are the following:

Input 5 character COMPANY ID Input 9/0 numeric TRANSMISSION CONTROL ID# Input 5/0 numeric GROUP CONTROL ID# Input 2 character GROUP TYPE CODE Input 20 character CUSTOMER TRANSACTION ID Input 20 character VENDOR TRANSACTION ID Input 6 character FORMAT ID IN ERROR Input 40 character ERROR REASON CODE(S) (2 characters per ie/20 occurrences maximum)

Output 1 character PROGRAM RETURN CODE (Possible values:

'=Rejected - default, or Α'=Acceρted) Input 10 character PROGRAM NAME IN ERROR (Rejecting the ansaction processing)

Input 150 character Transaction key value Input 128 character Transaction data value Input 10 character Program ID that is rejecting transaction Input 4 character Enhanced Error Type Code Input 10 character Data Queue Name that provided rejected ansaction key as input.

Input 1 character Error Severity flag

Confidential Page 46 of 246 8/11/00 ARMS Process Report

Input 1 character Error Transaction Type flag (possibli .ues : 'O• =Outbound, 'I'=Inbound, and 'T'=Transfer) (currently not referenced by .s program)

Input 8 character Alpha Add Date (ccyymmdd format) Input 6 character Alpha Add Time (24-hour format) Input 10 character Calling Program ID Input 5 character Add Employee ID

©Files : ( (CRUD)

- AMPACK (C—)

- ANDIST (C—)

- ANDQER (CRU-)

- AMPERT (-R-)

- AMERRTBL (^• -R—)

- AMERRLOG (C- —)

©Constants:

"ERROR CODE IS INVALID" as suffix for invalid error code.

'RTVMSGSTS' is the called program to check if the Message System Status active.

'ARMS TEST MESSAGE' is the Test Message Header Text that in not ϊerenced within the program.

icess irarchical numeric ID: 1.1.1.1.3.19 led name: AM2050V1 ne: PGM Retrieve Machine ID (AM2050V1) nment: ©Purpose: To return the associated MACHINE ID (host platform name) for ό ren rental location.

©Operational Method:

- This program attempts to retrieve a branch information record from the Eice Directories Branch Office (OFFDRB) file for the passed GROUP ID and BRANCH I] ≥cified as input in the parameter list.

- IF both the passed GROUP ID and BRANCH ID are blank, then return **ERROR' as MACHINE ID to the calling program.

- IF the passed BRANCH ID is blank, then attempt to retrieve the first sord associated for the passed GROUP ID.

..IF found, then return its MACHINE ID value.

IF the passed BRANCH ID is not blank, then attempt to retrieve the reco sociated for the passed GROUP ID and BRANCH ID values.

..IF branch is found, then return its MACHINE ID value for that branch fice location record to the calling program.

©Notes :

Executed with the following parameters:

Input 2 character GROUP ID Input 2 character BRANCH ID Output 8 character MACHINE ID

Confidential Page 47 of 246 8/11/00 ARMS Process Report

©Ebedded Data/Constants:

•***ERROR' is the constant value loaded if no OFFDRB file record is trieved successfully.

ocess erarchical numeric ID: 1.1.1.1.3.20 ded name: AM2051V1 me: PGM Check for Holiday / After Hours (AM2051V1) mment: ©Definition: This program determines if a given rental location is not le to accept new ARMS authorized reservations and detours it to Claims Connection

©Purpose: To return the associated MACHINE ID (host platform name) for ven rental location's passed GROUP ID and BRANCH ID.

©Operational Method:

- Receives three (3) input parameters:

2 character GROUP ID

2 character BRANCH ID

1 character ARMS Profile ID "Send to Claims After Hours?" Flag

- Returns a single output parameter:

8 character MACHINE ID (NAME)

- The following decision table/grid shows which location a new or ansferred authorized reservation will be routed based on this flag setting and her criteria: tive ntal

Send to Claims Holiday 1 Weekend | Claims Branch | Routed

After hours I 1 | Open | Opa

Location |

Claims |

Y N Y | N/A 1

A | Claims 1

Y N N 1 ^γ 1

| ECARS

Y N N 1 Y 1

| Claims 1 Y N N 1 ^N I

| ECARS

Y N N 1 ^N 1

| ECARS

N N/A | N/A 1 N/A | N/A

ECARS I

Retrieve the current system date, day of week and time (adjusted to tha 'cation' s time zone) .

Confidential Page 48 of 246 8/11/00 ARMS Process Report

IF the passed input parameter value for the ARMS Profile flag "Send to lims After Hours?" is "N" (No) , then do the processing to determine if the passed DUP ID and BRANCH ID is an active daily rental branch location.

Attempt to re-retrieve the associated record's BRANCH BUSINESS TYPE FOR ELY RENTAL INDICATION field in the Office Directory Branch Master (OFFDRB) file bj =s passed GROUP ID if the passed BRANCH ID is blank, or use GROUP ID and the BRANCI

Also, IF a record exists for just the passed GROUP ID, then indicate the =s branch supports daily rental business, ELSE use the retrieved OFFDRB file -lord's BRANCH BUSINESS TYPE FOR DAILY RENTAL INDICATION field value.

Additionally, IF an OFFDRB file record was retrieved successfully AND 3 STATUS CODE is "A" (Active) and its BRANCH BUSINESS TYPE FOR DAILY RENTAL DICATION is "Y" (Yes) , then load the MACHINE ID output parameter field with blank, today is NOT a national holiday, then,

IF the associated OFFDRB file record was not successfully retrieved, OR =s retrieve record's STATUS CODE is NOT "A" (Active), OR its BRANCH BUSINESS TYPE R DAILY RENTAL INDICATION is NOT "Y" (Yes) , then load the returned MACHINE ID tput parameter field with '***ERROR'.

ELSE, load the MACHINE ID field with blanks

IF the passed location is not found, or not a daily rental business cation, or its status is not active, then return "***ERROR" in the MACHINE ID ramete .

IF the passed input parameter value for the ARMS Profile flag "Send to aims After Hours?" is "Y" (Yes), then do the processing to determine if today is « tional holiday:

- Attempt to retrieve the associated Office Directory Branch Master FFDRB) file record using the passed GROUP ID and BRANCH ID.

- IF unsuccessful, then indicate that today is a holiday.

- IF successful, then using the retrieved OFFDRB file's MACHINE ID vali cess the associated ISS: Global Attributes (GACTL) File record to retrieve this anch's platform's associated COUNTRY NAME. Then use today's system date and thii trieved COUNTRY NAME value to attempt to access an existing record in the ECR: tional- Holiday (RA005P00) file. IF a record exists, then indicate that today is . tional holiday.

Attempt to re-retrieve the associated record's BRANCH BUSINESS TYPE FOR ILY RENTAL INDICATION field in the Office Directory Branch Master (OFFDRB) file b; e passed GROUP ID if the passed BRANCH ID is blank, or use GROUP ID and the BRANC

Also, IF a record exists for just the passed GROUP ID, then indicate th e branch supports daily rental business, ELSE use the retrieved OFFDRB file cord's BRANCH BUSINESS TYPE FOR DAILY RENTAL INDICATION field^' value.

Additionally, IF an OFFDRB file record was retrieved successfully AND s STATUS CODE is "A" (Active) and its BRANCH BUSINESS TYPE FOR DAILY RENTAL DICATION is "Y" (Yes) , then load the MACHINE ID output parameter field with blank today is NOT a national holiday, then,

IF the associated OFFDRB file record was not successfully retrieved, OR e retrieve record's STATUS CODE is NOT "A" (Active), OR its BRANCH BUSINESS TYPE R DAILY RENTAL INDICATION is NOT "Y" (Yes) , then load the returned MACHINE ID tput parameter field with '***ERROR*.

ELSE, load the MACHINE ID field with blanks.

Confidential Page 49 of 246 8/11/00 ARMS Process Report

IF today is NOT a national holiday, then check the date to determine s day of week is Saturday or Sunday.

IF not found, then Also, check if the today is a national holiday by ecking for the existence of a record in the ECR: National Holiday (RA005P00) file today's system date and the Country Name from retrieving the ISS: Global tributes (GACTL) File by the MACHINE NAME from the retrieved Office Directory anch Master (OFFDRB) file. This is to determine if the office is open and will cept new business.

IF it is a holiday, it is Saturday or Sunday, or the branch office is osed at the branch's current local time, then attempt to retrieve the Office rectory Branch File record for GROUP ID = "76" and BRANCH ID » "80" and check if is Claims Connection location is currently open with the current time adjusted to s local time zone. IF it is open, then return this GROUP ID and BRANCH ID, along th its current MACHINE ID value. IF it is not open, then return the original ssed rental location's MACHINE ID for the previously retrieved closed branch offii cation record.

The ARMSPRl Send to Claims After Hours flag (P1YN18) to determine wheth send a new reservation to Claims Connection or the closest Group/Branch. If this ag is set to 'N' for a trading partner, the new reservation will not be sent to aims Connection whether it is a holiday or not. This will prevent authorizations r Canadian locations being sent to Claims Connections on U.S. national holidays.

©Files: (CRUD)

OFFDRB (-R—) Office Directories Branch Office File, keyed by GROUP : d BRANCH ID.

GACTL (-R—) ISS: Global Attributes File RA005P (-R—) ECR: National Holiday File

(Example: '19980701' &NADA' is the Canadian national holiday for their Independence Day.)

©Notes:

Executed with the following 4 input parameters:

Input 2 character GROUP ID

Input 2 character BRANCH ID

Input/Output 8 character MACHINE ID (distributed application tabase host platform logical identifier/identifying name)

Input 1 character SEND TO CLAIMS CONNECTION AFTER

DRS INDICATION FLAG

Currently only executed from the ARMS Application Edit/Router Batch M0040V1) program.

©Embedded Data/Constants:

•***ERROR' is the constant value loaded if no active daily rental siness type Office Directory Branch Location (OFFDRB) file record is retrieved σcessfully.

'Mon', 'Tue', 'Wed', 'Thu', 'Fri' are used to associate the correct FDRB file record's Open Time and Close Time for each Day of the Week.

•Sat' and 'Sun* are constant values used to determine if the current da the week is on a weekend.

Confidential Page 50 of246 8/11/00 ARMS Process Report

76 is the constant overriding value for the Claims Connection GROUP ID. 80 is the constant overriding value for the Claims Connection BRANCH ID.

©Improvement Opportunities:

Only attempt to retrieve the associated OFFDRB file record in a single αtine. Currently done in both the $OFFDR subroutine to Retrieve OFFDRB (Office rectory File) Record and the $HOLDY subroutine to Check RACNTR to determine if Liday.

ocess

≥rarchical numeric ID: 1.1.1.1.3.21 led name: AM2053V1 ne: PGM Retrieve State Code (AM2053V1) nment: ©Definition: This is the callable OPM RPG program to Retrieve State Coc r a given Rental Location ID.

©Purpose: To extract and return the associated State Code from the Dai! atal Office Location Directory file for a given Rental Location ID.

©Operational Method:

Program accepts a two parameter list, composed of an input field, NATION ID (10 character) , and an output field, STATE CODE (2 character) . A recori attempted to be retrieved from Daily Rental Office Directory (DROFLFl) file with nation ID as its access key.

IF a record is found, the State Code will be extracted from the retrievi Ξord's ADDRESS LINE 2 (CITY, STATE, ZIP) field value and will be loaded to the tput parameter STATE CODE to be returned to the calling program. ELSE, set the \TE CODE to '**' and return to the calling program.

©Notes: This callable program is executed by the following ARMS'- " ograms :

ARMS Application Edit/Router Batch (AM00 0V1) ARMS Add Surcharge (AM0096V1) . -. ' ARMS Generate Underage Surcharge (AM1085V1)

©Files: (CRUD)

DROFF (-R--)

©Embedded Data/Constants:

'**' is the returned output STATE CODE if record is not retrieved.

©Improvement Opportunities:

1. Convert from OPM RPG/400 to ILE RPG/400 service program that is over 1 Office Directory files (internal and external organizations' rental locations) at will provide also Office Name, Street Address #1, Telephone Number and other formation so that the ARMS application is separated from the Office Directories tabase access software tier.

ocess erarchical numeric ID: 1.1.1.1.3.22 ded name: AM0047V1 me: PGM Enforce rules of Data Exchange for Outbound Transaction (AM0047V1)

Confidential Page 51 of 246 8/11/00 243

Overriden file Override to file Droffl2 Droffl3

Droffl7 Droffl9

In order to exclude Ford locations, the calling program must do the following overrides.

Overriden file Override to file

Droffl2 Droffl4

Droffl7 DroffllO

©Files (CRUD)

DROFF (-R—)

Process

Hierarchical numeric ID: 1.1.1.1.3.35

Coded name: AM2020V1

Name: PGM Retrieve ARMSPR5 Information (AM2020V1)

Comment: ©Purpose: To access ARMSPR5 (ECARS Profile) and ARMSPRl (Trading Partner

General Profile) record and return the details to the calling program.

©Operational Method:

Executed with the following entry parameters and their usage:

Output 1 alpha Program Return Code

Input 5 alpha Trading Partner Profile ID

Output 10 alpha ECARS Closing Calculations to Compute the

Direct Bill-To Total Due

Output 11, 2 numeric Payment Total Amount

Output 1 alpha Underaged Drivers Allowed (Y/N) indication flag

Output 1 alpha Insurance pays underage driver indication flag

Output 1 alpha Trading Partner has capability to recieve

Electronic Billing indication flag

©Files: (CRUD)

ARMSPRl (-R—) ARMSPR5 (-R—)

©Improvement Opportunity:

This program and AM2030V1 could be combined into a single program, especially if the ARMS Trading Partner Profile database files are further normalized.

Process

Hierarchical numeric ID: 1.1.1.1.3.36

Coded name: AM2030V1

Name: PGM Retrieve ARMSPR5 Information (AM2030V1)

Confidential Page 72 of 246 8/11/00 ARMS Process Report omment : ©Purpose: To generically enforce the rules specified by the ARMS Rent; anagement Trading Partners for data exchange on transaction data sets sent to djusters from Enterprise Rent-A-Car or Claims Connection. This can comprise eplacing data in a transaction data set's record formats' data elements that were rom the rental application database with values retrieved from the ARMS centralizi atabase files' data that had been populated by the transactions received from the djuster. This will then "echo" back information to the trading partner's pplication that had been sent to ARMS.

©Operational Method:

Using the passed TRADING PARTNER PROFILE ID and ARMS DATABASE FILE FIE IAME, attempt to retrieve the associated ARMS Trading Partner File/Field Control D ARMSPR4) file.

IF record not found, return to calling program without loading the R0GRAM RETURN CODE parameter.

IF record is found, then based on the two flags in the trading partner >rofile, use the following decision table:

CASE 1 : FORMAT field is blank DATABASE field is NOT blank.

Mandatory To Send Allow Field Changes Action Y N/A assign latabase field format field error :ode 04, missing corrected from latabase

N N assic latabase field Eormat field if rental status not Waiting and not unconfirmed

CASE 2 BOTH fields are Non-Blank

Mandatory To Send Allow Field Changes Action N/A N assigi database field format field if rental status not Waiting and not Unconfirmed

CASE 3 BOTH fields are Blank.

Confidential Page 52 of 246 8/11/00 ARMS Process Report

Mandatory To Send Allow Field Changes Action

Y N/A error le 01, missing ild not correct

In all other cases, the format field remains unchanged regardless of the abase field value.

©Notes :

This program is currently only called by the ARMS Database update and iting (AM0046V1) program with the following multiple parameters:

Input 50 character ARMS Database File field value

Input/Output 50 character Transaction Set Record Format field l/Replaced value

Input 6 character ARMS Database File Field Name

Input 1 character ARMS Rental Cross-Reference File lord's STATUS CODE

Input 5 character COMPANY PROFILE ID

Input 9/0 numeric TRANSMISSION CONTROL ID

Input 5/0 numeric GROUP CONTROL ID

Input 2 character GROUP TYPE CODE

Input 20 character CUSTOMER TRANSACTION ID

Input 20 character VENDOR TRANSACTION ID

Input 6 character FORMAT ID IN ERROR

Output 40 character ERROR REASON CODES (20 occurrences cimum © 2 characters, however, only first occurrence used.)

Output 1 character PROGRAM RETURN CODE (Not loaded by is program, but passed on from executed AM0097V1 program.)

Input 10 character CALLING PROGRAM ID IN ERROR

©Files: (CRUD) '^■■ ^■"

ARMSPR4 (-R-) ARMS Trading Partner File/Field Control Data file FILE80 (C ) Send a Message 80-position work file (created empt

1 overridden to in the QTEMP library by the execution of 'CRTF80' program, then ϊned explicitly.)

©Embedded Data/Constants:

'RTVMSGSTS' is the constant defined in order to execute the program :ore calling the Send e-Message (MS0010) program.

The following compile-time array "SBJ" is composed of 10 constant text les (47 characters each) used for loading e-message header and detail lines for an idatory data to be sent that is missing from the record format and the ARMS :abase:

1.) MANDATORY TO SEND FIELD IS MISSING

2. ) Format:

3. ) Program:

4.) Company:

5.) Transmission Control ID:

6. ) Group Type:

7. ) Cust Tran ID:

8.) Vndr Tran ID:

9.) is missing-corrected from database

Confidential Page 53 of 246 ^~ 8/11/00 ARMS Process Report

10. ) is missing-could not be corrected from database

©Improvement Opportunities:

1.) Convert this OPM RPG/400 program to an ILE RPG module and have thii ata replacement enforcement logic used as the transaction data set's record formal ield are being loaded.

2.) Replace the execution of the ARMS Handle Internal Error ('AM0097V1 rogram with the execution of the newer ARMS Handle Internal/External Error 'AM0098') program.

rocess ierarchical numeric ID: 1.1.1.1.3.23 oded name: AM0096V1 ame: PGM Generate Pseudo-Authorization Change Transaction Data Set (Approved ovt.Surcharges) (AMO096VI) omment: ©Purpose: To generate proprietary approved surcharge formats from the ormats stored in the pre-approved surchages file, AMSURTBL, based on the state an< ental location.

©Operational Method:

- Delete all automatically generated (ORIGIN CODE = 'A') in Authorized urcharge Detail file, AMSURD that are associated with the passed VENDOR TRANSACTK D and generate AMMNTLOG ARMS Database Maintenance Log file records via call to M1050V1.

- Pass the CURRENT RENTAL LOCATION ID to the called program AM2053V1 t< etrieve the STATE CODE.

- Search AMSURTBL file for any records with BLANK COMPANY PROFILE ID hose LOCATION ID field value matches with the passed CURRENT RENTAL LOCATION Grou] D or Group/Branch ID value. For every blank Location ID record or matches the assed CURRENT RENTAL LOCATION ID read, write an AMSURD Approved Surcharge Detail ile record for that retrieved AMSURTBL file record's SURCHARGE CODE, SURCHARGE MOUNT and SURCHARGE CHARGE FREQUENCY field values.

- Search AMSURTBL file for any records with the passed COMPANY PROFILE that was embedded within the passed Transaction Data Set Key) whose LOCATION ID ield value matches with the passed CURRENT RENTAL LOCATION ID Group ID or roup/Branch ID value. For every blank Location ID record or matches the passed URRENT RENTAL LOCATION ID read, write an AMSURD Approved Surcharge Detail File ecord for that retrieved AMSURTBL file record's SURCHARGE CODE, SURCHARGE AMOUNT . URCHARGE CHARGE FREQUENCY field values.

- Using the passed CURRENT RENTAL LOCATION ID Group/Branch ID, retriev he associated BC026P00 file record. For any non-zero miscellaneous government urcharges that are applicable for this rental location, write an AMSURD Approved urcharge Detail File record for that SURCHARGE AMOUNT and SURCHARGE CHARGE FREQUE1 ield values loading the SURCHARGE CODE with ' 05' (Government) .

- Return to calling program by explicit SETON *INLR.

©Notes: This program is called from AM0046V1 program when processing a ransaction data set for the following conditions: an Authorization (AT) group typ or an add, change, or transfer that contain a SURD01 record format; an opening ental Notification (RN) group type; or, an Request for Authorization (RA) Change

Confidential Page 54 of246 8/11/00 ARMS Process Report roup type where the Date of Birth or the Rental Location value has been changed fi previous value. This called program is completed and removed from the job's rogram stack completely when *INLR is SETON.

©Files: (CRUD)

- AMSURTBL (-R--)

- BC026P (-R—)

- OFFDRB (-R—)

- AMSURD (CR-D)

- RAGBCHBT (-R--) * TEXAS GOVT SURCHARGE TO PRINT FOR 'I'nsurance CPE CUSTOMERS

©Constants:

'RECORD DELETED' is the message text for a value passed to AM1050V1 Adc lintenance Log Record program.

©Improvement Opportunities:

1.) If this program remained resident in the job's program stack, the rerhead in opening all of the files could be reduced by making the file opens user >ntrolled to only occur if they are closed.

2. ) Convert this OPM RPG/400 program to an ILE RPG module and have this ita surcharge automatic generation logic executed as the transaction data set's scord format's fields are being interfaced with the rental system database on the .stributed rental application system host platform.

rocess

.erarchical numeric ID: 1.1.1.1.3.25

)ded name: AMRVTSQ one: PGM Assign Next Vendor Transaction Id (AMRVTSQ) ''^{■ '}"^'■^■"

>mment: ©Definition: This is the ARMS Assign Next Vendor Transaction ID OPM RPG

Lllable program.

©Purpose: To construct the next unique Vendor Transaction Identifier Llue for use in creating a new ARMS Rental Transaction Cross-reference File record

©Operational Method:

Attempt to retrieve the LAST USED VENDOR TRANSACTION ID from the data ^■ea AMSEQCTL and lock it for update.

IF there was an error accessing this data area, load, VENDOR TRANSACTION > with 'ERROR' and return to the calling program.

IF there was no error in accessing and locking this data area, then tcrement its IDENTIFICATION NUMBER value by 1 and concatenate this 9 digit integer i the passed input 1 character MACHINE ID value and load the first 10 of 20 laracters of a candidate VENDOR TRANSACTION ID.

Then, for every IDENTIFICATION NUMBER that is non-zero, ensure that an MS Rental Cross-Reference File record does not exist for the this derived Vendor ^■ansaction ID by execution of the ARMS Cross-Reference Inquiry (AM2010V1) program loop until a return code of 'E' (No Cross-Reference Found) is sent, continuing t Lcrement by 1 the numeric portion of this candidate VENDOR TRANSACTION ID.

Confidential Page 55 of246 8/11/00 ARMS Process Report

Update the data area with the last derived Vendor Transaction ID valu when the RETURN CODE of 'E' was returned to this calling program along with the L Changed Date, Time and Program ID.

Return the new Vendor Transaction ID to the calling program.

©Notes:

This program is executed by following ARMS never-ending programs (NEP

ARMS Database update and routing (AM0046V1) ARMS Dispatch Outbound Transactions (AM0060V1)

ARMS Outbound transaction editor (AM0062V1) (For non-ARMS Rental Management Trading Partners' Electronic Invoicing.)

It is executed with the following parameters:

Input 1 character MACHINE ID

Input 10 character PROGRAM ID

Output 10 character VENDOR TRANSACTION ID (to be used cross-reference file record creation)

©Embedded Data/Constants: 'ERROR' •E' •AM2010V1'

©Improvement Opportunities:

Convert this OPM RPG/400 program to an ILE RPG service program.

Process

Hierarchical numeric ID: 1.1.1.1.3.26

Coded name: AMI099

Name: PGM Retrieve Next Transmission Control Id Number (AM1099)

Comment: ©Purpose: To retrieve, generate and return the next ARMS internal

Transmission Control ID number for use in transmissions from the distributed mach to the centralized host or to another distributed machine as in a transfer. This number is unique on its originating machine but is not unique across the whole ARl

©Operational Method:

The program is called passing two parameter fields, the first input a the second is output:

Input CALLING PROGRAM ID Output TRANSMISSION CONTROL ID

Attempt to retrieve the next internal TRANSMISSION CONTROL ID value f the ARMS Next Outbound/Transfer Internal Transmission Control Seqeunce Number (AMRNAKSQ) file's single record and lock it for update.

If there is a database error, then load the output parameter for TRANSMISSION CONTROL. ID NUMBER with the current timestamp's day of month, hour, minute and second (in the format: Oddmmhhss, with a zero in the first leading position, followed by the 2-digit dd = day of month, followed by 6-digit current hour time to the whole second.).

Confidential Page 56 of 246 8/11/00 ARMS Process Report

If the record does not exist, then load the output parameter for

.NSMISSION CONTROL ID NUMBER with the numeric value of 1, increment that number b^ ind write a single AMRNAKSQ file record.

If the record does exist, then check if the retrieved NEXT TRANS SEQUENC zero, then load the output parameter for TRANSMISSION CONTROL ID NUMBER with the neric value of 1. Else, load the output parameter for TRANSMISSION CONTROL ID !BER with the current NEXT TRANS SEQUENCE field value. Increment that NEXT TRANS JUENCE number field value by 1. If the updated NEXT TRANS SEQUENCE number field Lue is now zero, then set that value to 1. Update the single AMRNAKSQ file :ord.

Return the INTERNAL TRANSMISSION CONTROL ID TO BE USED to the calling jgram.

©Files: (CRUD)

- AMRNAKSQ (CRU-)

©Notes: When a transmission is to be sent to the trading partner, it is iced in the packaging file, AMPACK from where the packaging program, AM0120 picks up and retrieves the next external transmission control id from a data area to sign it to this transmission. This external transmission control id exists only or ϊ centralized host as opposed to the internal id that exists on all computer itforms and is unique only by machine.

©Improvement Opportunities:

- The file should be changed to a data area since there will always be Ly one record in the file, similar to AMSEQCTL (and use the empty file as a layout Ly for external data structure purposes) . This may require an exclusive lock Location (via an API or ILE RPG pointers) to wait less than 5 seconds, then ittempt until successful locking for input and writing the updated data storage, ϊn issuing a deallocate/unlock. Also, this program should be duplicated to an RPC S service program once some of the calling programs are converted to RPG-ILE \ - >< jgrams. Additionally, CCARMSVl no longer calls this program, therefore remove th. jendent code. Lastly, this program is missing any program exception handling, liJ ^kPSSR subroutine calling AMPSSR. However, it may not be needed.

- 'CCARMSVl' used to check if is the value of the CALLING PROGRAM ID out parameter, then SETON *INLR since this program is being called by an -eractive program. (CCARMSVl no longer calls this program, this processing juirement was moved to CC00INV1, therefore remove this code.)

ocess

2rarchical numeric ID: 1.1.1.1.3.27 led name: AM1050V1 ne: PGM Create Sensitive Fields Change Log (AM1050V1) nment: ©Purpose: To generate an ARMS Rental Transaction Database Files' Changi i Deletes (Maintenance) audit log file record with the passed input Vendor ansaction ID, File Prefix Code, Field Name suffix, the previous "before-change" ,

3 current "after-change" and the Functional Group Type values for ARMS database

Les' field value changes. This is used for auditing or troubleshooting purposes.

©Operational Method:

This program will accept a parameter list composed of most of the data ≥lds in the AMMNTLOG record, excluding the Record Added Date and Time audit field

Confidential Page 57 of 246 8/11/00 ARMS Process Report

(There are no record change stamp fields since this is a history of database chanc or deletes log file.) The parameters (all input) are:

20 character Vendor Transaction ID 2 character File Code-File prefix

4 character Field Code-Field suffix 50 character Data - New value

50 character Data - Previous value

2 character Group Type Code

10 character Calling Program ID

5 character Employee ID

This program will accept input parameters provided and add a record t< VRMS Rental Transaction Database Files' Changes and Deletes (Maintenance) audit lc (AMMNTLOG) file. The record add stamp fields are loaded along with the passed ini oarameters values.

©Files :

AMMNTLOG (C ) Keyed by Vendor Transaction ID

©Improvement Opportunities :

- If any ARMS Database file fields increase in length beyond 50 :haracters, then the previous and current data value fields in AMMNTLOG and this .arameter list (along with the programs that execute this program) will need to me his increase and the existing data will need to be converted to the changed form* files. Likewise, if any of the ARMS Database file field names increase beyond 6 :haracters or the first 2 characters no longer denote file prefix, then these jarameters, programs using this program and the AMFLTBL and AMFLDTBL fields will i ;o be changed also.

?rocess

/. lierarσhical numeric ID: 1.1.1.1.3.28

:oded name: AM1080V1 lame: PGM Generate Transaction Credits (AM1080V1)

Comment : . - ^■• ©Purpose: To generate transaction credit log records and to accumulate

:he TOTAL CUMULATIVE REVENUE and TOTAL CUMULATIVE TRANSACTION COUNT for a trading jartner.

©Operational Method:

1) Attempt to retrieve the associated Transaction Cross-Reference.fi: AMXREF, record by the passed Vendor Transaction ID to retrieve its Company Profi. CD, Customer Transaction ID, Rental Location ID and Ticket ID. _. If unsuccessful retrieval, execute AM0097V1 program with passed Error Code equal to '98' and retu] ;o calling program.

2) Determine if an associated Transaction Volume Discount Profile (ARMSPR7) exists for this trading partner. If the associated profile record does sxist, then return to calling program.

3) If the last 6 characters of Location ID is blank, then the first - jharacters contain an ECARS Group/Branch ID. Therefore, use the Company Profile : :o attempt to retrieve the associated ARMSPR5 ARMS Company Profile ECARS Rental System Variables file record. Else, use the Company Profile ID to attempt to retrieve the associated ARMSPR6 ARMS Company Profile Claims Connection Rental Sysl Variables file record. If an associated Company Profile file record was not

Confidential Page 58 of246 ^{" '} 8/11/00 ARMS Process Report retrieved, execute AM0097V1 program with passed Error Code equal to '67' and retu- to caller program.

4) If the passed Processing Code is 'P'ayment Advice, then perform detail calculations to compute the total amount billed to the trading partner.

5) If the passed Processing Code is 'P' or 'R', then perform detail calculations to compute the TRANSACTION CREDIT AMOUNT.

6.) Increment the retrieved ARMSPR5 or ARMSPR6 file record's PAYMENT ADVICE ACCUMULATED PAYMENT TOTAL COUNT (this is essentially the cumulative transaction count) and ACCUMULATED PAYMENT TOTAL AMOUNT (this is essentially the cumulative revenue) .

8) Write record to AMTRNCR (Month-to-Date transction credit file) afti loading the following fields, including current date/time stamp fields:

- Populate the INSURANCE TOTAL RATE/DAY with the BILLED DAILY TOTAL AMOUNT (calculated above) .

- Load the TRANSACTION CREDIT AMOUNT f om the retrieved ARMSPR7 file record's DISCOUNT AMOUNT A field.

- IF the passed Processing Code is 'P', then load the TOTAL TICKET AM< and the AMOUNT BILLED CUSTOMER from their associated fields from the retrieved AM file record's fields' values. ELSE (Processing Code = 'R' - Closing RN) , clear tl fields to zeros.

IF the passed Processing Code is •P' , then load the INSURANCE TOTA RATE/DAY field with the previously computed INSURANCE MINIMUM TOTAL AMOUNT value. ELSE (Processing Code = 'R' - Closing RN) , clear the field to zeros.

- If the retrieved ARMSPR7 file record's DISCOUNT AMOUNT B field valu not zero, then do the following to calculate the ESTIMATED UTILIZATION FEE: If th retrieved ARMSPR7 record's DISCOUNT FREQUENCY B value is 'P' (Percent), then mult the DISCOUNT AMOUNT B by the decimal ratio of the DISCOUNT FREQUENCY B field'valu If the DISCOUNT FREQUENCY B value is 'L' (Lump) then use this value.

- Load the BILLED DATE from the retrieved AMIEBD record's ADD DATE.

- Load the following date subfields with the current system date: APPROVAL CENTURY/YEAR, APPROVAL MONTH, APPROVAL DAY.

©Complex Calculations:

BILLED DAILY TOTAL AMOUNT calculation:

1.) Attempt to retrieve the associated AMAUTD Authorization Detail f record for this Vendor Transaction ID to obtain the AUTHORIZED DAILY RATE, NUMBER DAYS AUTHORIZED, MAXIMUM DAILY RATE COVERED, POLICY MAXIMUM COVERED, BILL-TO PERC If unsuccessful retrieval, execute AM0097V1 program with passed Error Code equal '68' and return to caller program.

2.) If the NUMBER OF DAYS AUTHORIZED is greater than zero, then retr each associated AMIEBD Invoice Detail file record that has an ITEM CODE equal to (Daily Rate Detail) . a.) For each record daily charge invoice detail record read, i. ) Save the least of ITEM RATE (Rental Rate Charged) , AUTHORI DAILY RATE, MAXIMUM DAILY RATE COVERED as the RATE AMT. ii.) Save the lesse ITEM QUANITY (Days Charged) or NUMBER OF DAYS AUTHORIZED as the DAYS QUANTITY.

Confidential Page 59 of 246 8/11/00 ARMS Process Report iii.) If saved DAYS QUANTITY is greater than zero, then calculate CLLED AMOUNT = RATE AMT * DAYS QUANTITY.

Subtract DAYS QUANTITY from NUMBER OF DAYS AUTHORIZED. Accumulate BILLED DAILY TOTAL AMOUNT by BILLED AMOUNT. c.) Multiply BILLED DAILY TOTAL AMOUNT by AUTHORIZED BILL-TO PERCI AMAUTD) to give a new BILLED DAILY TOTAL AMOUNT value. d.) If the POLICY MAXIMUM COVERED amount is not zero, compare it t CLLED DAILY TOTAL AMOUNT. Add the lesser value to the appropriate retrieved ARMSI ARMSPR6 file record's ACCUMULATED PAYMENT TOTAL AMOUNT value giving a new ^CUMULATED PAYMENT TOTAL AMOUNT field value.

TRANSACTION CREDIT AMOUNT calculation.

1.) Retrieve (without update) the other rental system's Company Profi! ile (ARMSPR5 or ARMSPR6) for this Profile ID. Add together the new ACCUMULATED &.YMENT TOTAL COUNT fields from the two files (ARMSPR5 and ARMSPR6) with the αcrement of 1 for this transaction, giving a TOTAL ACCUM. COUNT (If not found, hen set Error Code equal to • 67 ' ) .

2.) Use the current Company Profile ID and TOTAL ACCUM. COUNT result rom (1) to SETLL on ARMSPR7 and retrieve the next record to get the amount of the ransaction credit.

3.) If ECARS invoice, then retrieve the Group/Branch's associated Reg ode from the OFFDRB Office Directory Branch File associated Group/Branch record, lse, it is a Claims Connection invoice, then leave region blank and use '7680' as roup/Branch ID.

4. ) Retrieve the associated AMIEBT Invoice Total File record to get t ental Ticket Total Amount and the Amount Billed to the Direct Bill Customer (erro ode 68 if not found) .

©Notes :

This program is only executed as a called program from the AM0046V1 lever-ending batch program in the ARMS subsystem only on the ARMS application lentralized host computer system platform whenever it processes the first closing RN' Rental Notification transaction data set for a non-zero Bill-To Percent Luthorized rental whose profile indicates auto-generation of a (PM) (currently as 5EICO using ARMS/400) , or, whenever it processes a 'PM' Payment Advice transactior lata set.

Executed with the following passed input parameters :_t

9/0 packed numeric Transmission Control ID Number

5/0 packed numeric Transmission Group Control ID Number 20 character Vendor Transaction ID

1 character Functional Group Transaction Type Process:

Ctode ('P'-PM or 'R' -Closing RN) .

©Files: (CRUD)

ARMSPR7 (-R—) AMAUTD (-R—) AMIEBD (-R-)

Confidential Page 60 of 246 8/11/00 ARMS Process Report

AMIEBT (-R—)

OFFDRB (-R—)

ARMSPR5 (-RU-)

ARMSPR6 (-RU-)

AMTRNCR (C—)

©Embedded Data/Constants:

'7680' is loaded as default non-ECARS location in the Group/Branch ID ta structure field to load the Group ID and Branch ID fields in the written AMTRN le record.

PGMNAM and PPRPGM are both set to 'AM1080V1 • . (Suggest using the ogram Data Structure subfield for Program ID in future.)

©Improvement Opportunities:

1.) Convert this OPM RPG program to an ILE RPG module that is part of t rrent AM0046V1 program.

2.) Since this program is attempting to do the same calculations that w ne at Close a Rental Contract calculation time, I suggest that the computation of e Daily Rental Direct Billing Sub-Total Amount on each rental contract be stored new Rental Authorization Detail file's associated Sub-Total Amount for Daily ntal, along with Approved Surcharges Charged Sub-Total Amount and Taxes Charged b-Total Amount. Then, if the centralized ARMS database needs to retain this formation for transaction credit purposes, a new internal format, IEBT02, can be aded during "Generate Electronic Billing Invoice" in the transaction set and can . ilized and stripped off from the outbound transaction set that is sent to the ading partner. However, it would be simple if these new fields were interrogated om a centralized archive repository of closed rental contracts for the ARMS ansaction Credit Reports run monthly that primarily use the AMTRNCR file.

3.) Replace the execution of the ARMS Handle Internal Error ('AM0097V1' ogram with the execution of the newer ARMS Handle Internal/External Error ' AM0098 ' )■ program.

4.) Delete the constant 'AM1080V1' and replace its usage with the Progr atus Data Structure data- element for PROGRAM ID.

5.) Convert program from OPM RPG to ILE RPG.

6.) Replace the use of the AM2010V1 program with the AMIOIOVI program lied for "I"nquiry.

ocess erarchical numeric ID: 1.1.1.1.3.29 ded name: AMIOIOVI me: PGM Inquire/Update Cross - Reference (AMIOIOVI) mment: ©Purpose: To retrieve for inquiry or update an existing associated ARMS ntal Transaction Cross-Reference File record when passed with the appropriate rameters.

©Operational Method:

- The following four input combinations can be passed to this program: ARMS VENDOR TRANSACTION ID; ARMS TRADING PARTNER COMP.PROFILE ID and CUSTOMER TRANSACTION ID;

Confidential Page 61 of 246 8/11/00 ARMS Process Report

RENTAL LOCATION and the RENTAL CONTRACT/TICKET ID; or RENTAL LOCATION and the RENTAL BRANCH RESERVATION ID.

Likewise, records may be updated or added to the ARMS Rental Cross- erence File by executing this program in "Maintenance" mode. Only inquiry is owed if executed in "Inquiry" mode.

1.) The RENTAL LOCATION is always required and either a non-blank TICKET or RESERVATION ID must be passed.

IF RENTAL LOCATION, TICKET ID and RESERVATION ID are blanks, then load RETURN CODE with 'E' (Error) .

2. ) IF Rental Location and Reservation ID are passed with the program 1, use AMXREFL2 to retrieve the requested ARMS Cross-Reference File record. a.) IF Ticket number is also passed with the program call, retrieve record using AMXREFL2. Then validate the Ticket number passed with the program 1 against the Ticket data field XATKNO. b.) IF passed TICKET ID and retrieved TICKET ID are different, then d the RETURN CODE with 'T' (Ticket ID Mismatch) and return to the calling program c.) IF the passed TICKET ID is same as the TICKET ID found for the ervation in the ARMS Cross-Reference File, then update all fields in the paramete t from AMXREFL2, set the RETURN CODE to blanks (blanks indicate successful) and urn to the calling program.

3.) IF non-blank RENTAL LOCATION and TICKET ID are passed with the gram, use AMXREFL1 to retrieve the data.

IF no record found for RENTAL LOCATION and TICKET ID, then load the URN CODE with 'E' (Error) .

4.) IF an ARMS COMPANY PROFILE ID is passed with the program call and a ord is retrieved, compare this value with XACUID in AMXREFLn. • "

IF they are different, change the RETURN CODE to 'P' for 'Profile Error' return to calling program.

5.) IF non-blank ARMS COMPANY PROFILE ID and CUSTOMER TRANSACTION ID are sed, retrieve record from AMXREFL3. a.) IF TICKET ID / RESERVATION ID is passed, compare these with value rieved from AMXREFL3.

IF they do not agree, change return code to 'T' / 'R' . b.) IF RENTAL LOCATION is passed, compare this value with value rieved from AMXREFL3.

IF they do not match, change return code to 'L' .

6.) IF an ARMS VENDOR TRANSACTION ID is passed, retrieve record from -REF. a.) IF an ARMS COMPANY PROFILE ID is passed with the program call and ecord is retrieved, compare this value with the associated field in the retrieved IS Cross-Reference File.

Confidential Page 62 of 246 8/11/00 ARMS Process Report

IF they are different, change the return code to 'P' for 'Profile Erro. nd return to calling program. b.) IF RENTAL LOCATION is passed, compare this value with the AMXRE] alue. IF they are different, change return code to 'L' . c.) IF TICKET ID or RESERVATION ID is passed, compare these values ith values retrieved from AMXREF.

IF they do not agree, change RETURN CODE to 'T' / 'R'.

7. ) IF a record is retrieved from AMXREF or any of these logical files ased upon the file use hierarchy, and additional data fields are passed, and more nan one data mismatch occurs, change the return code to 'M' for multiple errors.

Hierarchy for record retrieval:

1. ) IF ARMS VENDOR TRANSACTION ID is passed, and any other data fields etrieve from AMXREF.

2.) IF ARMS COMPANY PROFILE ID and CUSTOMER TRANSACTION ID are passed, nd any other data fields (except VENDOR TRANSACTION ID) , retrieve from AMXREFL3.

3. ) IF RENTAL LOCATION and RESERVATION ID are passed, retrieve from

MXREFL2. 4.) IF RENTAL LOCATION and TICKET ID are passed, retrieve from AMXREFL

RECORD MAINTENANCE FUNCTIONS:

1.) ACTION CODE passed is 'M' for maintenance. It is required to pass he VENDOR TRANSACTION ID for all maintenance transactions. Additional fields are ptional, but only the physical file AMXREF is used for maintenance. ADD/CHANGE 'ROGRAM ID should also be sent.

2.) IF any existing AMXREF record is being maintained, the data fields .re updated with the passed values along with record change stamp fields.

3.) IF new AMXREF record is being written, the data fields are updated rith the passed values along with record add stamp fields.

4.) IF an AMXREF record is retrieved, compare the contents of each dat lield in the record with parameter containing that field.

IF they are different, create a maintenance log for the change. This lone only if parameter value is not blanks. Any non-blank value contained in the >arameter list is logged and mapped to the AMXREF. AM1050V1 is- called to create iMMNTLOG record.

RETURN CODE possible values: blank: Successful retrieval / edit

L: Location passed is blank / invalid

#: Ticket/Reservation passed is blank

T: Ticket passed, unmatched on AMXREF record

P: Profile passed, unmatched on AMXREF record

E: No AMXREF record found

M: Multiple errors

Confidential Page 63 of 246 8/11/00 ARMS Process Report

ACTION CODE possible values:

I: Inquiry

M: Maintenance

- IF the passed CALLING PROGRAM ID is NOT 'AM0046V1', then execute call the ARMS Program Exception Handler 'AMPSSR' program, passing the CALLING PROGRAM and the Transaction's 96-character key value that is comprised of the passed NSMISSION CONTROL ID#, GROUP CONTROL ID#, GROUP TYPE CODE, CUSTOMER TRANSACTION I) VENDOR TRANSACTION ID, padded with blanks.

©Notes:

This program is only executed by other ARMS never-ending programs that processing a ARMS transaction request to inquire or update the ARMS Cross- erence File.as being in error or not doable and rejected it from further cessing. This program is currently called with parameters by the following grams:

ARMS Database Update and Routing program (AM00 6V1)

ARMS Dispatch Rental Systems Request program (AM0060V1)

ARMS Distributed Edit and Dispatch Inbound Transactions program

0061VI)

ARMS Distributed Edit of Generated Transaction Sets program (AM0062V1)

The parameters are internally defined in this program and programs cuting this program are the following parameter fields:

Output 1 character RETURN CODE

Input/Output 20 character VENDOR TRANSACTION ID

Input/Output 5 character TRADING PARTNER CO. PROFILE ID

Input/Output 20 character CUSTOMER TRANSACTION ID

Input/Output 10 character RENTAL LOCATION

Input/Output 6 character RESERVATION ID

Input/Output 6 character TICKET ID

Output 1 character STATUS CODE

Output 8/0 numeric STATUS CODE LAST CHANGED DATE

Output 6/0 numeric STATUS CODE LAST CHANGED TIME

Output 10 character STATUS CODE LAST CHANGED PGM ID

Output 1 character MACHINE ID

Output 10 character BRANCH CLAIMS OFFICE CODE

Output 1 character RENTAL SYSTEM SOURCE ID

Output 8/0 numeric RECORD ADD DATE

Output 6/0 numeric RECORD ADD TIME

Output 10 character RECORD ADD PROGRAM ID

Output 8/0 numeric RECORD CHANGE DATE

Output 6/0 numeric RECORD CHANGE I E

Output 10 character RECORD CHANGE PROGRAM ID

Input 2 character GROUP TYPE CODE

Input 1 character ACTION CODE

©Files: (CRUD)

- AMXREF (CRU-) AMXREFLl, L2, L3

©Embedded Data: (Constants)

'AM1010V1 ' is used as the program's name.

Confidential Page64 of246 8/11/00 ARMS Process Report

The following values are named constants used for sending the ARMS Cross ference File (AMXREF) record's field name suffix for the passing of any field vali lified as a FIELD CHANGED parameter field value in the call to the ARMS Transactic abase Maintenance Logging (AM1050V1) program.

^■CUID"

'CUTI'

'RNLC

'RENO'

'TKNO'

•STCD'

•STDT'

'STTM'

'STPG'

•MCID'

'SOID'

•TEID•

'ADDT'

'ADTM'

'ADPG'

•CGDT'

'CGTM'

'CGPG^»

Also, there is a compile-time array to store the values for the formattc ^400 commands:

CLOF OPNID (AMXREF )

OPNDBF FILE (AMXREF ) OPTIO (*ALL)

©Improvement Opportunities:

Converting this OPM RPG program to ILE RPG service program. It might ate the need for the OS/400 command execution OPNDBF and CLOF of the AMXREF file

Replace the 'AMIOIOVI ' constant with the PROGRAM ID field of the ogram Status Data Structure.

Replace the internally defined parameter fields in this program and all ograms executing this program with a database file with no record to be used as ai :ernally> defined data structure so that only one definition of the parameter' s da1 ≥ments exist, along with comments on their purpose and possible values.

This program can replace the call to the ARMS Cross-Reference File juiry (AM2010V1) program in many other programs if it is called in "Inquiry" mode

ocess

Brarchical numeric ID: 1.1.1.1.3.30 ied name: RTVMCHA ne: PGM Retrieve Machine Emulation Attributes (RTVEMCHA) nment: ©Purpose: To retrieve the emulated system (machine) platform attributes portant for Enterprise programs that have been standardized for a machine.

This program is executed when executing the user-written command of the me name, "RTVEMCHA" (Retrieve Emulated Machine Attributes) .

©Operational Method:

To avoid adversely impacting performance, all of these steps are execut ly the first time a job executes the RTVEMCHA program. Subsequent execution in

Confidential Page 65 of 246 8/11/00 ARMS Process Report reduction will bypass the program initialization steps, only returning previously ded values.

Upon program initialization, do the following: executes the program to retrieve the system (machine) name (RTVSYS)

- opens GACTL and MACHID files

- retrieves the system name's records from both GACTL and MACHID

- moves data from both GACTL and MACHID into its parameter list

- closes GACTL and MACHID files

- execute the /Q Check DEV's machine without emulation program (ERTVDE determine IF actually on "DEV". IF true, return the previously derived values tc

≥ calling program and end program and return to caller.

After program initialization has been performed and this inactive progr. 3 re-executed by the same job's calling program, only do the remaining processing ≥p, return the previously derived values to the calling program.

©Files (CRUD)

MACHIDENPF (-R—) Machine Information File, via keyed access path HID#1 by key element MACHINE ID (8 character)

GACTL (-R--) Global Attributes file, by key element MACHINE ID (8 a acter)

©Notes:

This program is a Internal Systems Support Group utility tool software Liable program, executed with a single parameter defined in an external data ructure in its physical file ($#EMACH) . All its output parameter subfield data ≥ments, their attributes and a description can be found in source text member LiIB/QDOCSRC/RTVEMCHA.

This program is especially important for each of our software plications needs the flexibility to accommodate the multi-national differences we LI encounter in day-to-day business dealings since E-R-A-C in now operating outsit ≥ North American continent. For example, what we consider a standard method of splaying the date (MM/DD/YY) is not the standard in the United Kingdom; they expe< see it- displayed as DD/MM/YY.

To facilitate expansion of business operations into the United Kingdom, i eventually into other European countries, a Global Attributes file (GACTL) was eated to contain information that varies from country to country. By using the stem name obtained through RTVSYS, a program can access the GACTL file and use th formation to tailor display screens and reports to its needs. For example, the CTL file contains a field to tell programs to display the date as MM/DD/YY or /MM/YY.

ocess erarchical numeric ID: 1.1.1.1.3.31 ded name: AM1085V1 me: PGM Generate Underage Driver Surcharge (AM1085V1) mment: ©Purpose: To delete any preexisting and write any needed ARMS Pre- proved Authorized Surcharge Detail file (AMSURD) records with the CHARGE TYPE COD

•20' (Underage Driver Surcharge) and the CHARGE ORIGIN CODE = 'U' (Underaged Driv rcharge Generation program) .

©Operational Method: Confidential Page 66 of246 8/11/00 ARMS Process Report

1. Call the Retrieve ARMS Cross-Reference File Record (AM2010V1) progra sing the passed VENDOR TRANSACTION ID field value and its required parameters to strieve the associated ARMS Profile ID value.

2. IF the returned SOURCE ID = 'B' (Branch Reservations), then call the strieve ARMS ECARS-Specific Profile File Record (AM2020V1) program to retrieve fro le associated ARMS ECARS-Specific Profile File (ARMSPR5) record its flag field val >r automatically generating underage driver approved surcharge authorizations :NSURANCE WILL PAY UNDERAGE=Ύ') .

ELSE (SOURCE ID = 'C - Claims Connection), call the Retrieve ARMS lARS-Specific Profile File Record (AM2030V1) program to retrieve the same iformation from the associated ARMS-Claims Connection Specific Profile file -RMSPR6) record.

3. IF this retrieved profile's flag field value is 'Y' (Yes), then do t illowing: a. Using the passed VENDOR TRANSACTION ID, retrieve the associated ithorization Detail file (AMAUTD) record. IF successful, derive (compute) the DIVER'S AGE by subtracting the DATE OF BIRTH from the RENTAL START DATE. b. Call the Retrieve Rental Location's State Code Inquiry (AM2053V1) ogram, passing the called Retrieve ARMS Cross-Reference File Record (AM2010V1) ogram's returned parameter value for RENTAL LOCATION ID to retrieve the RENTAL •CATION'S STATE CODE value. c. Using the retrieved PROFILE ID value and RENTAL LOCATION'S STATE »DE value, retrieve the associated ARMS Profile Control Fields by State Code file LRMSPR8) record.

IF unsuccessful, reattempt using the value '**' in place of the RENTAL 'CATION'S STATE CODE value. If still unsuccessful, execute return processing below d. IF the derived DRIVER'S AGE is greater than or equal to the the trieved ARMS Profile Control Fields by State Code file (ARMSPR8) record's UNDERAG RESHOLD AGE value, then use the passed VENDOR TRANSACTION ID value and SURCHARGE PE CODE = '20' (Underage Driver) to retrieve and delete any associated AMSURD fil cord. • For each record deleted, the program will write a record to the ARMS intenance Log file by the calling of Generate ARMS Maintenance Log Records M1050V1) program with loaded parameter values. e. IF the derived DRIVER'S AGE is less than the the retrieved ARMS ofile Control Fields by State Code file (ARMSPR8) record's UNDERAGE THRESHOLD AGE lue and the INSURANCE WILL PAY UNDERAGE is equal to 'Y' , then write an associated MS Surcharge Detail file (AMSURD) record, using the passed VENDOR TRANSACTION ID lue, SURCHARGE TYPE CODE = '20' (Underage Driver Surcharge Authorization Type de) , the retrieved ARMS Profile Control Fields by State Code fiie (ARMSPR8) cord's UNDERAGE CHARGE AMOUNT value with a CHARGE FREQUENCY set to 'D' (Daily arge) and the CHARGE ORIGIN CODE = 'U' (Underaged Driver Surcharge Generation ogram) .

©Notes:

ARMSPR8 is currently empty.

This program is called from the AM0046V1 ARMS update never-ending progr ecuting in a batch mode on the centralized ARMS application host computer system atform when processing a transaction data set for the following conditions: an thorization (AT) group type for an add, change, or transfer that contain a AUTD01

Confidential Page 67 of 246 8/11/00 ARMS Process Report cord format; an opening Rental Notification (RN) group type; or, an Request for thorization (RA) Change group type where the Date of Birth or the Rental Location lue has been changed from a previous value. This called program is completed and moved from the job's program stack completely when *INLR is SETON and RETURN is ecuted.

IMPORTANT: ARMS Profile Control Fields By State Code File (ARMSPR8) is rrently empty in the production environment. Therefore, this program is called, aded and initialized, then explicitly is ends, removed from the program stack and ntrol is returned to the calling program.

©Files: (CRUD)

- AMAUTD (-R—) ARMS Authorization Detail File

- ARMSPR8 (-R-) ARMS Profile Control Fields by State Code File

- AMSURD (CR-D) ARMS Approved Surcharge Detail File

ocess erarchical numeric ID: 1.1.1.1.3.32 ded name: AM0052 me: PGM Determine Nearest Location by Phone Number (U.S. Only) (AM0052) mment: ©Purpose: To determine the closest United States rental branch to a ecified telephone number's area code and exchange using the Horizontal and Vertic. re Coordinates locator database.

©Operational Method:

At the start, file VERHOR gives the vertical and horizontal coordinates a specified area code and exchange number.

These coordinates are given in "units". There is 316 units per mile.

This program scans a 30 mile area around the VERHOR coordinates. This is accomplished by calculating 4 new coordinates. 2 Horizontal and 2 Vertical.

The specified area code and exchange generates coordinates X2 and Y2 fn e VERHOR file.

To "draw" the 30 mile box we subtract 9,480 units (30 miles) from X2 am to get XI and Yl.

We then add 9,480 units to X2 and Y2 to get X3 and Y3.

Using the XI and Yl coordinate, attempt to retrieve the closest next cord in the Daily Rental Offices (DROFF) file. This file contains the name,.. dress etc. of all daily vehicle rental office locations. Along with this formation, the vertical and horizontal coordinates of each office are found in th le. By comparing these coordinates to the "box" coordinates we decide whether or t this office falls within the specified 30 mile area as read in as an input rable from the Search Input Parameters for Locator System (RANGE) data area.

The number of miles from the originally specified area code/exchange to ch rental office is arrived at by calculating the square root of the combined rizontal and vertical coordinates of each rental office.

VWIRE = the vertical coordinate of the rental office.

HWIRE = the horizontal coordinate of the rental office

DVWIRE = the vertical coordinate of the original Area Code/Exchange

DHWIRE = the horizontal coordinate of the original Area Code/Exchange

Confidential Page 68 of 246 8/11/00 ARMS Process Report

When a location is found that is within boundaries, check the "Prevent IS Reservations" flag. IF this flag is 'N' , include the location. If this flag i and there is no "Forward To Location" (DROAGB) field value, skip this location, this flag is 'Y' and there is a forwarding location, save the first forwarding :ation. IF no other Enterprise location is found, use the saved forwarding :ation.

All office information is stored in array "AC" , which is sorted in lending sequence according to mileage. The closest Enterprise office is used if . exists.

©Notes:

This program is currently executed only by the ARMS Detail Set Edits anc sign Location (AM0040V1) OPM RPG program called with the following parameters:

Input 3 character AREA CODE (comprised of non- iding zero integers only)

Input 3 character EXCHANGE (comprised of non- iding zero integers only)

Input 1 character COMMISSION CODE

Output 10 character RENTAL LOCATION CODE

Output 1 character MACHINE ID

Output 1 character SOURCE ID

©Files: (CRUD)

OFFDRGRPPF (-R—) OFFDG#2

VERHOR (-R-)

DROFF (-R--) DROFLFl, DROFFL2

©Embedded Data/Constants:

30 miles is the maximum radius/distance for closest Enterprise rental inch to pickup a renter.

©Improvement Opportunities :

Change the calling program to execute the AM0053 program instead for al] iding partners but specifically profiled ARMS Trading Partner Company.

ocess

≥rarchical numeric ID: 1.1.1.1.3.33 led name: AM0053 ne: PGM Determine Nearest Location by Longitude / Latitude using Phone Number or stal Code (Canadian Only) (AM0053) ) nment: ©Purpose: To locate offices in a specific area based on the telephone nber provided and return the results and distance from point of inquiry to the guesting program. The request can be made for any Canadian Enterprise offices.

©Operational Method:

-This program has four main logic sections that:

1) Draws a variable size box around a centerpoint of a phone number, ogram is passed phone number and a 30 mile box is drawn around this number. Program calls AT_002 and passes the

Confidential Page 69 of 246 8/11/00 ARMS Process Report phone# and size in the parm. AT_002 chains to the phone# file, gets the basepoint coordinates, and sends back via the parms the basepoint coordinates for that phone#, and the upper right and lower left longitude/latitude coordinates of the box, and a return code to indicate any errors. AT_002 adjusts and corrects the box size for the curvature of the earth and is accurate to within 400 ft on Ave.

2) Retrieves all the records from the branch office file that fall with: box.

3) Calculates the distance (in miles), from the phone number centerpoint, of all the records retrieved.

The program calls 'AT_001' program and passes a parameter that has th< iterpoint (basepoint) and the longitude and latitude points of all records ≥viously retreived, and gets returned in the parameter the distances in miles for :h set of points, and a PROGRAM RETURN CODE for errors. This is currently limite 30 sets of points on each execution. IF more than 30 records are needed, a :ond(or third, fourth, etc.) execution can be made until all distances are Lculated. This program scans a 30 mile area around the retrieved lgitude and latitude coordinates and returns the .

4.) Find the rental location needed for this transaction. IF one does ; exist, then send transaction to Claims Connection.

Make use of "Prevent ARMS Reservations" flag field (DROAMF) of the DROF] Le. This field indicates whether unsolicited ARMS authorizations are to be sent 1 jroup/branch. IF this field is 'Y', then send the authorization to the forwardin; oup/branch (if not blank) from the DROFF record. IF this flag is 'N', include thi nation. IF this flag is 'Y' and there is no "Forward To Location" field (DROAGB) Lue, skip this location. IF this flag is *Y' and there is a forwarding location, re the first forwarding location. IF no other Enterprise location is found, use ≥ saved forwarding location.

©Notes :

This program is currently executed only by the ARMS Detail Set Edits an sign Location (AM0040V1) OPM RPG program called with the following parameters:

Input 10 character TELEPHONE NUMBER

Output 10 character RENTAL LOCATION CODE

Output 1 character MACHINE ID

Output 1 character SOURCE ID

It executes the following programs:

AT_002 - Draw box around a centerpoint. AT_001 - Calculate Distance between points. ** Will notify the application department when .problem occurs executing programs.

©Files: (CRUD)

OFFDRGRPPF (- —) Office Directories Group Master file, accessed by the FDG#2 access path key element, GROUP ID (2 character)

DROFF (-R-) Daily Vehicle Rental Office Locations file, cessed by the DR0FFL7 access path key element, LONGITUDE and LATITUDE (both 9/6 numeric)

©Embedded Data/Constants :

Confidential Page 70 of 246 8/11/00 ARMS Process Report

30 miles is the maximum radius/distance for closest Enterprise rental inch to pickup a renter.

'7680' is the default rental location for Claims Connection.

'C is the default MACHINE ID host platform (System ID='CENTRAL' ) and JRCE ID (Claims Connection) values.

'ARMS' is the constant TERMINAL ID value for input parameter to the ϊcution of the 'AT_001' program.

©Improvement Opportunities:

Change the calling program (AM0040V1) to execute this program for all :ation once all rental locations have been loaded into the Longitude and Latitude :ator by Telephone Number database for all trading partners but specifically ifiled ARMS Trading Partner Companies.

icess irarchical numeric ID: 1.1.1.1.3.34 led name: NUS017A ne: PGM Determine Nearest Enterprise Location by Phone or Postal Code (NUS017A) nment: ©Purpose: To locate 1 to 9 offices in a specific area based on the Lephone number or postal code provided and return the results and distance from Lnt of inquiry to the requesting program. The request can be made for any office. om the DROFF (NR : Daily Rental & Non-Enterprise Office Loc's) file, only :erprise offices, or only Enterprise airport offices.

©Operational Method: The following parameters must be passed to the ogram with appropriate values set based on task at hand.

Input Parms:

Location Phone#

Location Postal Code

Open Only Flag

Maximum Allowable Distance

Airport Branches Only Flag

Department ID

Accepting Reservations Flag

Retrn Forward-to Locatn Flag

Requested Date/Time

Time Zone Group/Branch ID

Opening Time Allowance

Closing Time Allowance

Return Code

Branches to Return 1-9

Output Parms:

Location ID Array - these are the locations that satisfy the input sear iterion.

Mileage Array - these are the corresponding distances for the locations om the reference point.

©Notes:

1) A testing stub called LOCTRUT exists in library ELARMS to test the ogram.

2) In order to receive only Enterprise offices, the calling program mus the following overrides :

Confidential Page 71 of 246 8/11/00 ARMS Process Report

Overriden file Override to file Droffl2 Droffl3

Droffl7 Droffl9

In order to exclude Ford locations, the calling program must do the following overrides.

Overriden file Override to file

Droffl2 Droffl4

Droffl7 DroffllO

©Files (CRUD)

DROFF (-R--)

ocess

≥rarchical numeric ID: 1.1.1.1.3.35 led name: AM2020V1 ne: PGM Retrieve ARMSPR5 Information (AM2020V1) nment: ©Purpose: To access ARMSPR5 (ECARS Profile) and ARMSPRl (Trading Partnc leral Profile) record and return the details to the calling program.

©Operational Method:

Executed with the following entry parameters and their usage:

Output 1 alpha Program Return Code

Input 5 alpha Trading Partner Profile ID

Output 10 alpha ECARS Closing Calculations to Compute the rect Bill-To Total Due

Output 11,2 numeric Payment Total Amount

Output 1 alpha Underaged Drivers Allowed (Y/N) indication

Output 1 alpha Insurance pays underage driver indication ag

, . • Output 1 alpha Trading Partner has capability to recieve ectronic Billing indication flag

©Files: (CRUD)

ARMSPRl (-R—) ARMSPR5 (-R—)

©Improvement Opportunity:

This program and AM2030V1 could be combined into a single program, pecially if the ARMS Trading Partner Profile database files are further normalize

ocess erarchical numeric ID: 1.1.1.1.3.36 ded name: AM2030V1 me: PGM Retrieve ARMSPR5 Information (AM2030V1)

Confidential Page 72 of 246 8/11/00 ARMS Process Report mment: ©Purpose! To access ARMSPR6 (Claims Connection Profile) and ARMSPRl rading PArtner General Profile) record and return the details to the calling ogram.

©Operational Method:

Executed with the following entry parameters and their usage:

Output 1 alpha Program Return Code

Input 5 alpha Trading Partner Profile ID

Output 10 alpha Claims Connection Closing Calculations to npute the Direct Bill-To Total Due

Output 11,2 numeric Payment Total Amount

Output 1 alpha Underaged Drivers Allowed (Y/N) indication ag

Output 1 alpha Insurance pays underage driver indication ag

Output 1 alpha Trading Partner has capability to recieve

≥ctronic Billing indication flag

©Files: (CRUD)

ARMSPRl (-R—) ARMSPR6 (-R-)

©Improvement Opportunity:

This program and AM2020V1 could be combined into a single program, pecially if the ARMS Trading Partner Profile database files are further normalizet

ocess

≥rarchical numeric ID: 1.1.1.1.3.37 led name: RAS013A ne: PGM Determine Nearest Enterprise Location by Phone or Postal Code (RAS013A) nment: ©Purpose: To locate 1 to 9 offices in a specific area based on the Lephone. number or postal- code provided and return the results and distance from Lnt of inquiry to the requesting program. The request can be made for any offices om the DROFF (NR : Daily Rental & Non-Enterprise Office Loc's) file, only -.erprise offices, or only Enterprise airport offices.

©Operational Method: The following parameters must be passed to the ogram with appropriate values set based on task at hand.

Input Parms:

Location Phone# t Location Postal Code Country Code Open Only Flag Maximum Allowable Distance Airport Branches Only Flag Department ID

Accepting Reservations Flag Retrn Forward-to Locatn Flag Requested Date/Time Time Zone Group/Branch ID Opening Time Allowance

Confidential Page 73 of 246 8/11/00 ARMS Process Report

Closing Time Allowance

Return Code

Branches to Return 1-9

Output Parms:

Location ID Array - these are the locations that satisfy the input seari iterion.

Mileage Array - these are the corresponding distances for the locations om the reference point.

©Notes:

1) A testing stub called LOCTRUT exists in library ELARMS to test the ogram.

2) In order to receive only Enterprise offices, the calling program mus the following overrides :

Overriden file Override to file Droffl7 Droffl9

In order to exclude Ford locations, the calling program must do the following overrides.

Overriden file Override to file

Droffl7 DroffllO

©Files (CRUD)

DROFF (-R--)

ocess erarchical numeric ID: 1.1.1.1.3.38 ded name: NUS018A me: PGM Verify Branch is Open (NUS018A) mment: ©Purpose: To send a GPBR and have the open/closed status returned. The quest time can be the current date and time or a time in the future. The program es the three Nat Res policy files, NRALPA2, NRPCDG, and NRGBM. It also uses GPBRT d a time zone reference field must be sent.

©Operational Method: The following paramters can be passed to the ogram:

Requested Group/Branch ID

Requested Date/Time

Time Zone Group/Branch ID •

Opening Time Allowance

Closing Time Allowance

Within Opening Time Allowance

Within Closing Time Allowance

Open Flag

Return' Code

The Open Flag and Return Code are the only return fields. The program checks the Nat Res Policy Files to determine if the request anch is open or closed.

Closing Time Allowance is available but not currently used by ARMS.

Confidential Page 74 of 246 8/11/00 ARMS Process Report

©Files (CRUD)

NRALPA2 ( -R- ) NRPCDG ( -R-) NRGBM ( -R- )

icess irarchical numeric ID: 1.1.1.1.3.39 led name: DQAM55V1 le: DTQ Input for Program AM0055V1 (DQAM55V1) iment: ©Definition: DQAM55V1 is a data queue used to provide input to PGM

I055V1 which maintains the files used for ARMS Online Reporting, accessed via

IS/400 (green screen or gui) .

>cess irarchical numeric ID: 1.1.1.1.3.40 led name: AM0055V1 ne: PGM Online Reporting File Write/Update Program (AM0055V1) nment: ©Purpose: To update and write records to the ARMS Group Type Summary Le AM096P which keeps track of the number of times a group/type is transmitted foi customer profile and its vender transaction ID. Also to update and write record. the ARMS Online Reporting Detail file AM095P which keeps details on a rental keyc customer profile and vender tran ID. To log transactions to ARMS Current days insaction for Sync program AM097P.

©Operational Method:

- Wait for entry(s) to exist in DTAQ (DQAM55V1) .

- When a shutdown request is received (group type - SD) , end program.

-When a non-shutdown request is received:

-Create a record in AM096P01 to keep track of the number of transactions r a vendor tran id. If a record already exists add 1 to the total and update.

-Check to see if a record exists in any of the following files by keyinc Vender Tran ID: AMAUTD, AMRPRD, AMRNTD, AMSURD, AMIEBT, AMADJD, AMXREF

-If a matching record is found move all of the appropriate data from CREF, AMAUTD, AMRPRD, AMADJD, AMRNTD, AMSURD, AMIEBT to the ARMS Online Reporting :ail File AM095P.

-If there is not an existing record in AM095P00 -one' will be created, lerwise the existing record will be updated. All previous data in an existing Ξord will be replaced with all data found in the files.

-Check to see if a record exists in AM097P01. If record exists, skip sord. If record is not found, write a record to the file.

©Files: (CRUD)

- AMXREF (-R—)

- AMADJD (-R-)

- AMAUTD (-R--)

Confidential Page 75 of 246 8/11/00

- AMRNTD (-R—)

- AMRPRD (-RU-)

- AMSURD (CR-D)

- AM0095P00 (CRU-)

- AM009601 (CRU-)

- AM009701 (CR—)

©Embedded Data/Constants :

' YES ' ' NO '

ocess erarchical numeric ID: 1.1.1.1.4 led name: ne: AUT Send Transaction for Distributive Processing (AM100-AM101) nment: ©Definition: The automatic process of sending the transaction from the αtralized machine to the distibuted machine for processing, via ICF files.

ocess

≥rarchical numeric ID: 1.1.1.1.4.1

3ed name: AMOIOO ne: PGM Distribute Routed Transaction from Centralized Host System (AMOIOO) nment: ©Purpose: To send a received (inbound) or transferred ARMS transaction t from the centralized host platform to the distributed host platform.

©Operational Method:

Execution is started with a single MACHINE ID (1 character) input rameter field value.

... • For program initialization:

- Retrieve the current platform's CURRENT SYSTEM (MACHINE) NAME by acution of the Retrieve System Name (RTVSYS) program.

- Concatenate the Recieve Routed Ditributed Transaction on Distributed st System Program Name, 'AM0101', with the passed input MACHINE ID value for. riving the specific Program Device Name.

- IF CURRENT SYSTEM NAME = 'DEV' , change the ICF workstation device fill ORE program's library to 'ELARMS', ELSE, make the EVOKE program's library 'ELLIB'

- Attempt to acquire this Program Device. Attempt 5 times before gnalling an error. Introduce a delay of one minute between each attempt.

- IF the Program Device is acquired successfully, Evoke the derived ARM stribution Incoming Receive Program.

After program initialization has completed, for a repetitve cycle until utdown data queue entry is received, the following is performed:

Confidential Page 76 of 246 8/11/00 ARMS Process Report

- Receive the next keyed data queue entry from the specific keyed data sue for the key equal to the passed input MACHINE ID parameter value. Immediately >m the DQAMAPH data queue until empty, then infinitely wait for DQAMAPl data queue .ries.

- Attempt to retrieve an associated record from the AMAPPS file using th .a queue entry as the retrieval key value.

- IF at least one associated AMAPPS file record exists, then do the .lowing:

- - Send the key to the ARMS Distribution Incoming Receive program.

- - Read all ARMS Set file records with the ARMS Application Data Queue r .

- - Send each data record to the ARMS Distribution Incoming Receive >gram. when all records are read and sent, send a blank record.

©Files: (CRUD)

- AMAPPS (-R-) ©Embedded Data/Constants:

'AM0101' is the evoked program's specified name.

'ELARMS2' and '*LIBL' for the evoked program's specified possible libra- lies.

'DEV' to determine if being executed on the development (not production) tware environment platform.

'*DOWN' and 'SD* as the Profile ID and Group Type Code to indicate a dat iue entry of a shutdown request.

•DQAMAPH' and 'DQAMAPl' are the Hold Distribution Input and the insactions to Distribe Input data queue names.

^■DLYJOB DLY{60) • is the OS/400 command executed to cause 1 minute delay. ;ween the 5 Attach attempts.

©Improvement Opportunities:

Convert this OPM RPG program to ILE RPG program.

Possibly change this communication method from ICF to CPI-C.

ocess

≥rarchical numeric ID: 1.1.1.1.4.2 led name: AMOIOI ne: PGM Receive Routed Distributed Transaction on Distributed Host System (AMOIOI nment: ©Purpose: To receive routed transaction set from the centralized host atform.

©Operational Method:

- Acquire the program device 'AMOIOI'

- Receive routed transaction input from the centralized ARMS host platform.

- IF data was received

- Write records to the distributed Application Transaction File

(AMAPP)

- Send data queue entry to Edit/Update/Distribute Transaction

(DQAM61) ELSE

Confidential Page 77 of 246 8/11/00 ARMS Process Report

- Send data queue entry to Edit/Update/Distribute Transaction

(DQAM61)

- Release Device. ENDIF

©Files: (CRUD)

- AMAPP (C )

©Notes: The centralized ARMS host platform EVOKES the receive job on t] 3tribuited rental system host platform using an ICF connection. Presently, the 3tributed rental system host platform, excludes BIRELAND, VGERMANY, and UK.

ocess

≥rarchical numeric ID: 1.1.1.1.4.6 ied name: RTVSYS ne: PGM Retrieve System Name (RTVSYS) nment: ©Purpose: To retrieve the system name to pass back to another calling ogram.

©Operational Method:

Executed with the single output parameter, RETRIEVED SYSTEM NAME (8 aracter)

Retrieve the current system's network attribute of system name.

IF the RETRIEVED SYSTEM NAME = 'DEV', then execute the ISS DEV Machine lation (DEVMCHE) OPM CL program.

ocess

≥rarchical numeric ID: 1.1.1.1.5 ied name: ne: AUT Interface with Rental Systems (AT/CN/EX/CM) mment :•--^■ ©Definition: The automatic process of dispatching a data queue entry fo appropriate program to update the Rental database be it either ECARS or CLAIMS NNECTION.

ocess erarchical numeric ID: 1.1.1.1.5.1 ded name: me: AUT Interface with ECARS (AT/CN/EX/CM) mment: ©Definition: The automatic process by which the ECARS Rental database les are updated due to a request received from the Rental Management Trading rtner (AT, CN, EX, CM) .

ocess erarchical numeric ID: 1.1.1.1.5.1.1 ded name: EC00ATV1 me: PGM Interface EC with Rental Authorization (EC00ATV1) mment: ©Purpose: This is an ARMS-to-ECARS database update interface program at processes Rental Direct Billing Authorization 'AT' Functional Group Type for

Confidential Page 78 of 246 8/11/00 ARMS Process Report s or Changes sent by ARMS insurance Customers or automatically generated ^~~ horization changes. This program will also process previously authorized ervation Rental Location's Group-to-Group 'AT' transfers.

©Operational Method:

This NEP receives the 'ATB' keyed input data queue entries from the inpu a queue (DQAM61V1) that program AM0061V1 generated as input to this program.

Once a shutdown data queue entry is received, then send this shutdown a queue entry to the DQANDST data queue and end this program.

For any non-shutdown data queue entry, read all of the associated ARMS lication Interface Input Transaction file (AMAPP) records.

IF the flag for Centralized Adjuster Phone number is 'Y' then retrieve m CUSTMAST the office phone number from that file record based upon customer ber and use this phone number to populate ECARS data files, else the adjuster ne number supplied in the ADJD01 format will be used. This flag is retrieved via • call to AM2090V1.

IF any COMD01 or SURD01 record formats were found, execute the Update ctronic Messages program (ECMSGVl) with 3 input parameters, the APPD01 record mat's Reservation ID (6 character), the data queue entry value (96 character), an

CALLING PROGRAM ID (10 character) to write the electronic messages to ECARS sage database.

IF while attempting to retrieve any existing records that are locked for ate, the transaction is deferred by sending the data queue entry to a secondary ut data queue (DQAM6BV1) to be reedited by the AM0061V1 program for later cessing and a deferral notice data queue entry is sent to the primary input data ue (DQAM61V1) to notify that program that a deferred transaction exists (both dat ue entries sent with key = 'DIS') . This will trigger the program AM0061V1 to rt the wait timer so that when the wait is elapsed it can receive from the ondary data queue.

IF an authorization transfer is received, then a new ARMS authorized nch reservation is created, along with any applicable instructions, callback and write¹ ihformation, such' as date of birth.

IF an authororization add is received that has an invalid or no open tal contract/ticket or reservation identifier in it, then a new authorized rental ervation is created, along with any applicable instructions and prewrite ormation, such as date of birth.

IF an authorization add or change is received that has a valid open .tal contract (ticket) and a reservation identifier in it, then update both the sting unauthorized open rental ticket and its "linked" branch reservation with th horization information.

IF an authorization add is received that has a valid open rental itract (ticket) but no reservation identifier in it, then update the existing open ital ticket with the authorization information, a new authorized rental reservatic created, and this reservation is "linked" to the open contract. However, IF the m rental contract was opened using another non-ARMS authorized branch reservatior national reservation, then break the "link" of the previous open rental contract intifying information from the previous reservation. When a NatRes link is broker ecord is created in the file, NRDBTRAN, to appropriately credit NatRes.

Confidential Page 79 of 246 8/11/00 ARMS Process Report

In all cases that an existing branch reservation is updated with an .horization for the first time or an authorized branch reservation is created, a CS' keyed data queue entry is sent to the DQAM60V1 data queue as input to the .patch Rental Systems Request (AM0060V1) program. This should cause an .horization confirmation (AC) group type transaction data sent to be dispatched fc leration and sent.

In all cases that an existing open rental contract is updated with an .horization add or change, the associated adjuster callback direct billing .horization information is updated. For an authorization add only, the EXTENSION .E is recomputed by adding this input transaction's data set's authorization detai JTD01) record format's AUTHORIZED DAYS to the open rental contract's START CHARGES CE.

IF, however, the resulting EXTENSION DATE is a Saturday or Sunday, check ϊ Trading Partner Profile's WEEKEND SLIDE FLAG. ..IF the WEEKEND SLIDE METHOD COI "Y"es and the EXTENSION DATE is Saturday or Sunday, then "slide" (change) the TENSION DATE to the date for the following Monday.

..IF the WEEKEND SLIDE METHOD CODE is "M"odified and the EXTENSION DATE Sunday, then "slide" the EXTENSION DATE to the date for the following Monday.

Likewise for an authorization add only, callback detail notes are lerated to indicate the recomputed EXTENSION with an "Authorized Until mm/dd/yy" 1 "By: AdjusterLastName*AdjusterFirstName*" formatted text where the "mm/dd/yy" iε Ϊ computed new extension date and the Adjuster's name is derived from the data ovided in the Adjuster Detail (ADJDOl) record format.

©Notes:

This program is submitted for execution by the ARMS Startup Jobs progran JL810) with no entry parameters.

This program was changed to not remove the *TX REMB miscellaneous remment tax unconditionally on open contracts, but to instead check a flag in the Lid Business Types that the special TEXAS GOVERNMENT SURCHARGE is applied to VGBCHBT) file (via logical access path RAGBBT, by Business Type, Group ID and inch ID) to see whether or not this tax should be charged.

— ©Files: (CRUD)

AMAPP (-R—) ARMS Application Interface Input Transaction

Le

RACPENDC (-R—) Open ECARS Rental Contracts/Tickets in progress of

Lng changed or closed control file

RACBRNUM (CRU-) Branch Reservation ID Control File

RACBRMST (CRU-) Branch Reservation Master File

RACBRWRT (CRU-) Branch Reservation Prewrite File ,

RACINS (CRU-) Branch Reservation/Open Rental Contracts Insurant

Eormation File

RACBRIST (CRU-) Branch Reservation Special Instruction

ECSURCHG (CR-D) ECARS Authorized for Rental Direct Billing Surcharge!

Le

RACMAST (-RU-) Open Rental Contract/Ticket File

RACSMAST (CRU-) ECARS Open Rental Contract/Ticket Supplemental formation File

CB007P (CRU-) Rental Callback Control File, accessed by

CCBCTL logical view, by Group/Branch ID and Document ID

RACCBDET (CR--) Rental Callback Detail Notes File

RACCCK (-RU-) Branch Reservation Credit Check File

CUSTMAST (-R-) Customer Master File

Confidential Page 80 of 246 ^: 8/11/00 ARMS Process Report

RACCBCOC (-R—) Rental Consolidated Callback Control File

RACCBK3 (CRUD) Rental Consolidated Callback Control File

RACCBB3 (CR-D) Rental Callback Consolidation Skeleton File - Shop

OFFDRB (-R--) Office Directories Internal Organization Brand ster File

NR025P (-RU-) National Reservations Master File, accessed by

)25L00 logical view, by National Reservation ID

NRDBTRAN (CRU-) National Reservations Database Transactions Update Fil

©Embedded Data/Constants :

'Until' used to provide a preformatted Callback Detail Notes phrase.

'/' used to as a date separator for date output into a Callback Detail ;es text.

'ARMS CUST-' used to provide a preformatted RACBRIST File Sequence 001 word's comment text.

Process/shutdown codes: •AT' 'SD'

Format IDs:

^■APPD01' •ADJDOl' •ADJD02' 'AUTDOl' 'COMD01' ' INSD01 ' 'RNTD01' •RNTD02' •RPRD01' •SURD01• •RATD01'

Comments i

•VEHICLE NEEDED IMMEDIATELY •

•UNIT NEEDED AT OTHER# ' ■-^• 'UNIT NEEDED AT HOME# '

'UNIT NEEDED AT OFFICES' •INS CO WILL PAY '

'/DY' used as a Branch Reservation Rate Quoted Comment for the quoted ily rental rate.

^■Non numeric data received in Transmission/Group Control ID'

'LECOOATVl' is used as the JOB NAME.

•ECOOATVl' used as the CALLING PROGRAM ID.

•ATB' as the input key used for receiving keyed data, queue entries.

Constants for formatting numeric fields to text: '/DAY' ^■/MAX'

'0123456789' all valid numeric characters to use for validation of al meric character data element fields. 'RATE + TAX' ' + TAX' •RATE +SCHG' • +SCHG'

Confidential Page 81 of 246 8/11/00 ARMS Process Report

The following OS/400 Override Printer file commands are executed througl ≥cution of the 'QCMDEXC' program to change the output queue names by insertion of ≥ Group/Branch ID (4 character) in the output queue name to cause the printing of open rental contract/ticket or the executed Print a Branch Reservation to print - ≥ associated rental location's office plain paper printer:

OVRPRTF FILE(QPRINTP ) OUTQ(P P) FORMTYPE (PLAINPAPER) DLTOVR FILE (QPRINTP)

The following OS/400 database file override commands are executed throuc ≥cution of the 'QCMDEXC* program to decrease the locked record/object wait times r update files from the object default of 1 minute to 5 seconds:

OVRDBF FILE (RACBRNUM) WAITRCD(5

OVRDBF FILE (RACBRMST) WAITRCD(5

OVRDBF FILE (RACBRWRT) WAITRCD(5

OVRDBF FILE(RACINS) WAITRCD(5

OVRDBF FILE (RACBRIST) WAITRCD(5

OVRDBF FILE (ECSURCHG) WAITRCD(5

OVRDBF FILE (RACMAST) WAITRCD(5

OVRDBF FILE (RACCBCTL) WAITRCD(5

OVRDBF FILE (RACCBDET) WAITRCD(5

OVRDBF FILE(RACSMAST) WAITRCD(5

OVRDBF FILE(RACCCK) WAITRCD(5

OVRDBF FILE(RACCBK3) WAITRCD(5

OVRDBF FILE(RACCBB3) WAITRCD(5

OVRDBF FILE(NR025L00) WAITRCD(5

OVRDBF FILE (NRDBTRAN) WAITRCD(5

©Improvement Opportunities :

1.) Convert this OPM RPG program to an ILE RPG program.

2.) Delete the 'ECO0ATV1' program name and 'LEC00ATV1' job name constan d specify/use the Program Status Data Structure's PROGRAM ID and JOB NAME data ements for these purposes.

3.) Move the "Authorized Until mm/dd/yy" and "By: justerLastName*AdjusterFirstName*" formatted text comment templates into an ternal ARMS Table File that contains the preformatted callback detail note tomated comments.

4.) Add a new executable program to check for an associated existing cord in the file RACPENDC (CRU-) "Open ECARS Rental Contracts/Tickets in progress being changed or closed control file" for checking if OK to process and if .so, tput a record until the operation is complete, then delete the RACPENDC record th s written to clear way for other transactions.

ocess erarchical numeric ID: 1.1.1.1.5.1.2 ded name: EC00EXV1 me: PGM Interface EC with Rental Extension/Termination of Authorization (EC00EXV. imment: ©Purpose:

To update the rental database with the authorized extension days or irmination date received from the trading partner.

©Operational Method:

Confidential Page 82 of 246 8/11/00 ARMS ProcessReport

This program endlessly receives the 'EXB' keyed input data queue entrie om the input data queue (DQAM61V1) that program AM0061V1 generated as input to th ogram.

Once a shutdown data queue entry is received, then send this shutdown ta queue entry to the DQANDST data queue and end this program.

For any non-shutdown data queue entry, read all of the associated ARMS plication Interface Input Transaction file (AMAPP) records.

IF the any COMD01 or SURDOl record formats were found, execute the Upda ectronic Messages program (ECMSGVl) with 3 input parameters, the APPD01 record rmat's Reservation ID (6 character), the data queue entry value (96 character), a e CALLING PROGRAM ID (10 character) to write the electronic messages to ECARS ssage database.

IF while attempting to retrieve any existing records that are locked fo date, the transaction is deferred by sending the data queue entry to a secondary put data queue (DQAM6BV1) to be reedited by the AM0061V1 program for later ocessing and a deferral notice data queue entry is sent to the primary input data eue (DQAM61V1) to notify that program that a deferred transaction exists (both da eue entries sent with key = 'DIS ' ) .

IF the received transaction set's STATUS CODE is not "E"xtend nor "erminate, then reject the transaction set back to the trading partner's adjuster a "data domain error" .

In all cases that an existing open rental contract is updated with an thorization extension or termination, the associated open contract file record's d its adjuster callback file record's direct billing authorization information is dated if the adjuster information is changed.

IF this transaction is an authorization termination (CRED01:CRESTS='T' ) en update the callback's current EXTENSION DATE is replaced with this input ^*' ansaction's data set's customer request for extension detail (CRED01) record rmat's non-zero TERMINATION DATE, regardless if the new value of the EXTENSION DA a Saturday or Sunday date. Likewise, a callback detail note record is generated indicate the replaced EXTENSION DATE with an " Rental Terminated On: mm/dd/yy" a y: AdjusterLastName*AdjusterFirstName*" formatted text where the "mm/dd/yy" is th placed EXTENSION DATE and the Adjuster's name is derived from the data provided i. e Adjuster Detail (ADJDOl) record format. Update the number of authorized days in e Reservation record.

IF this is an authorization extension (CRED01:CRESTS='T' ) , with DAYS TO TEND is zero, then the current EXTENSION DATE remains. This will allow ARMS ading Partner Insurance Company to send a termination request., (The second phase 11 allow ARMS Trading Partner Insurance Company to receive "RE" and send "EX" ansactions.) Likewise, a callback detail note record is generated to indicate th me value EXTENSION DATE with an " Rental Terminated On: mm/dd/yy" and "By: justerLastName*AdjusterFirstName*" formatted text where the "mm/dd/yy" is the rrent value of the callback's EXTENSION DATE and the Adjuster's name is derived om the data provided in the Adjuster Detail (ADJDOl) record format. Update the ber of authorized days in the Reservation record.

IF this is an authorization non-zero extension, then the non-zero TENSION DATE is recomputed by adding this input transaction's data set's customer quest for extension detail (CRED01) record format's DAYS TO EXTEND to the open ntal contract's current EXTENSION DATE.

Confidential Page 83 of 246 8/11/00 ARMS Process Report

Likewise for an authorization extension for a non-zero DAYS TO EXTEND ily, a callback detail note record is generated to indicate the recomputed EXTENSI th an "Rental Extended Until: mm/dd/yy" and "By:

[justerLastName*AdjusterFirstName*" formatted text where the "mm/dd/yy" is the rnputed new extension date and the Adjuster's name is derived from the data provid . the Adjuster Detail (ADJDOl) record format.

Update the number of authorized days in the Reservation record.

©Notes:

This program is submitted for execution by the ARMS Startup Jobs progra LL810) with no entry parameters.

©Files: (CRUD)

AMAPP (-R-) ARMS Application Interface Input Transaction le

ECEXTCTL (CRU-) ECARS Pending Extension Request Control File

RACMAST (-RU-) Open Rental Contract/Ticket File

RACCBDET (C ) Rental Callback Detail Notes File

RACCBCOC (-R—) Rental Consolidated Callback Control File

RACCBK3 (CRU-) Rental Consolidated Callback Control File

CB007P00 (-RU-) Open Rental Contracts Callbacks Control File

CB032P00 (-RU-) RMS Callback Contracts by Group/Branch/Ticket

RACBRMST (-RU-) ECR Branch Reservations Master File

©Embedded Data/Constants:

'Rental Extended Until:' used to provide a preformatted Callback tail Notes phrase. .

'Rental Terminated On: ' used to provide a preformatted Callback tail Notes phrase.

'Rental Extended 0 days' used to provide a preformatted Callback tail Notes phrase.

'DQAM61V1 '

'ECOOEXVl •

OVRDBF CB007POO WAITRCD(*IMMED) '

'OVRDBF RACMAST WAITRCD(*IMMED) '

OVRDBF RACMAST WAITRCD(*IMMED) '

'/' used to as a date separator for date output into a Callback Detail tes text. Logicals:

'Y* 'N* '0' •1'

Process/shutdown codes: •EX' 'SD'

Format IDs:

•APPD01' •ADJDOl' •CRED01' 'COMD01'

Comments:

Confidential Page 84 of 246 8/11/00 ARMS Process Report

'LECOOEXVl' is used as the JOB NAME. •ECOOEXVl' used as the CALLING PROGRAM ID.

'EXB' as the input key used for receiving keyed data queue entries. •0123456789' as all valid numeric characters to use for validation of al leric character data element fields.

The following OS/400 Override Printer file commands are executed through icution of the 'QCMDEXC program to change the output queue names by insertion of s Group/Branch ID (4 character) in the output queue name to cause the printing of open rental contract/ticket or the executed Print a Branch Reservation to print a . associated rental location's office plain paper printer:

OVRPRTF FILE(QPRINTP ) OUTQ(P P) FORMTYPE (PLAINPAPER) DLTOVR FILE (QPRINTP)

©Improvement Opportunities:

1.) Delete the 'ECOOEXVl' program name and 'LECOOEXVl* job name constant I specify/use the Program Status Data Structure's PROGRAM ID and JOB NAME data iments for these purposes.

2.) Change the program's use of the database files used for update rposes before opened for update via the following OS/400 database file override miands are executed through execution of the 'QCMDEXC program. This would be to :rease the locked record/object wait times for update files from the object defaul 1 minute to 5 seconds.

3. ) Add a new executable program to check for an associated existing :ord in the file RACPENDC (CRU-) "Open ECARS Rental Contracts/Tickets in progreε being changed or closed control file" for checking if OK to process and if so, :put a record until the operation is complete, then delete the RACPENDC record th 3 written to clear way for other transactions.

4.) Move the "Rental Extended Until:", "Rental Terminated On:", "Renta. .ended 0 days" and "By: AdjusterLastName*AdjusterFirstName*" formatted text commer ciplates into an external ARMS Table File that contains the preformatted callback :ail note automated comments.

5.) Prior to opening the user-controlled open files that are used to RE- CHAIN for UPDATE, execute an "Override Data Base File" command to change the lord-lock wait times from the default 60 seconds to 5 seconds as was done in the )0ATV1 and ECOOCNVl programs.

ocess

≥rarchical numeric ID: 1.1.1.1.5.1.3 * A ied name: ECOOCNVl ne: PGM Interface EC with Rental Cancellation / Denial of Authorization (ECOOCNVl mment: ©Purpose:

To update the rental database with the cancellation information receive om the trading partner to either cancel a previously ARMS-authorized open contrac i/or open branch reservation, or, to deny billing responsibility in response to a guest for authorization on a branch reservation or an open rental contract icket) .

©Operational Method:

Confidential Page 85 of246 8/11/00 ARMS Process Report

This program endlessly receives the 'CNB' keyed input data queue entrie om the input data queue (DQAM61V1) that program AM0061V1 generated as input to th ogram.

Once a shutdown data queue entry is received, then send this shutdown ta queue entry to the DQANDST data queue and end this program.

For any non-shutdown data queue entry, read all of the associated ARMS plication Interface Input Transaction file (AMAPP) records.

IF there are no deferred transactions while processing, then execute th date Electronic Messages program (ECMSGV1) with 3 input parameters, the APPD01 cord format's Reservation ID (6 character), the data queue entry value (96 aracter) , and the current CALLING PROGRAM ID (10 character) to write the electron stomer messages to ECARS message database.

IF while attempting to retrieve for update any existing file records th e locked for update, then the transaction is deferred by sending the data queue try with key = 'DIS' to a secondary input data queue (DQAM6BV1) and a deferral tice data queue entry with key = 'DIS' to a primary input data queue (DQAM61V1) t reedited by the AM0061V1 program for later processing.

IF the received transaction set's reservation is not found, the servation is closed, or closed ticket that had been opened using the ARMS- thorized reservation, then error the transaction and page ARMS On-call.

IF the received transaction set's reservation is closed, then execute t ternal/External Error Handling Program (AM0098) to Reject the transaction.

IF the received transaction set's retrieved unauthorized reservation ha en voided, discontinue any further processing of this transaction.

IF the received transaction set' s retrieved rental contract has been ided, then the transaction is deferred by sending the data queue entry with key = IS' to a secondary input data queue (DQAM6BV1) and a deferral notice data queue try with key = 'DIS' to a primary data queue (DQAM61V1) to be reedited by the 0061V1 program for later processing. AM0061V1 will then handle the Ticket record t being found appropriately.

IF the received transactions set's retrieved reservation is authorized, en do the following:

..IF the received transaction set's reservation is found, is ARMS thorized, and, a ticket is currently being opened using the reservation (BRTKT = 9999) , then defer this transaction as stated previously.

..IF the received transaction set *s open ticket and/or reservation is und, is/are ARMS authorized, and available, then reset its direct billing dication (leave the Bill-To ID and related information) , load the RATE QUOTED MMENT with "ARMS Direct Bill Canceled By AdjusterLastName,AdjusterFirstName, and ear the ARMS authorization information from Branch Reservation File (RACBRMST) ar om Ticket Master Files (RACMAST & RACSMAST) file records and its associated llback Control and update. Create a Callback Control for the Reservation if it es not exist. Generate a Callback Detail Note file record with the comment "ARM. rect Bill Canceled By AdjusterLastName,AdjusterFirstName" in NOTE #1, along with ιe associated adjuster's claim center internal CUSTOMER NAME from the Customer .ster File (CUSTMAST) as "At customername" in NOTE #2. Update or create the msolidated callback control files. Callbacks for a reservation attached to an tcomplete Ticket will be created or updated using the Reservation number.

Confidential Page 86 of 246 8/11/00 ARMS Process Report

..IF the received transaction set's reservation is found, is NOT ARMS thorized, and is available for update (regardless if linked to open contract/ticki not) , then reset its (and its associated open rental contract/ticket) direct lling indication (leave the Bill-To ID and related information) , load the servation's RATE QUOTED COMMENT with "ARMS Direct Bill Denied By justerLastName,AdjusterFirstName", in the Branch Reservation File (RACBRMST) and e Ticket Master File (RACMAST) file records and its associated open rental ntract/ticket file and update. Update the callback and the consolidated callback ntrol files, using the open rental contract/ticket identifier if it is completely en (has a non-zero CONTRACT DATE), else use the reservation's identifier. Create llback Control for the Reservation if it does not exist. Generate a Callback tail Note file record with the comment "ARMS Direct Bill Denied By justerLastName,AdjusterFirstName" in NOTE #1, along with the associated adjuster'! aim center internal CUSTOMER NAME from the Customer Master File (CUSTMAST) as "At stomername" in NOTE #2.

©Notes:

This program is submitted for execution by the ARMS Startup Jobs prograi LL810) with no entry parameters.

©Files: (CRUD)

AMAPP (-R--)

RACBRMST (-RU-)

CB007P00 (CRU-)

RACCBDET (C )

RACMAST (-RU-)

RACCBCOC (-R-)

RACCBCTK (C-U-) ECR Callback Consolidation Skeleton File, by Group ID, Branch ID, Rental Contract/Document ID via the RACCB] gical access path.

RACCBCBS (C-U-) ECR Callback Consolidation Skeleton File - Shop, by Group ID, Branch ID, Rental Contract/Document ID via the RACCB] jical access path.

CUSTMAST (-R--)

RACSMAST (-RU-)

EMSG (C )

©Embedded Data/Constants:

•ARMS'

•ARMS Direct Bill Denied By'

'ARMS Direct Bill Canceled By'

©Improvement Opportunities :

ocess erarchical numeric ID: 1.1.1.1.5.1.4 ded name: ECOOCMVl me: PGM Interface EC with Customer Message (ECOOCMVl) mment: ©Purpose:

To update the rental database with any text messages received from the ading partner in the functional group type 'CM' .

©Operational Method:

Confidential ^: Page 87 of246 8/11/00 ARMS Process Report

This program endlessly receives the 'CMB' keyed input data queue entriei om the input data queue (DQAM61V1) that program AM0061V1 generated as input to th ogram.

Once a shutdown data queue entry is received, then send this shutdown ta queue entry to the DQANDST data queue and end this program.

For any non-shutdown data queue entry, read all of the associated ARMS plication Interface Input Transaction file (AMAPP) records.

IF any COMD01 or SURD01 record formats were found, execute the Update ectronic Messages program (ECMSGVl) with 3 input parameters, the APPDOl record rmat's Reservation ID (6 character), the data queue entry value (96 character), a e CALLING PROGRAM ID (10 character) to write the electronic messages to ECARS ssage database.

©Notes:

This program is submitted for execution by the ARMS Startup Jobs prograi LL810) with no entry parameters.

©Files: (CRUD)

AMAPP (-R- -)

RACBRMST (-R-)

RACMAST (-R—)

©Embedded Data/Constants:

'ECOOCMVl' used as the CALLING PROGRAM ID.

'CMB' as the input key used for receiving keyed data queue entries.

©Improvement Opportunities :

1.) Convert this OPM RPG program to an ILE RPG program.

2.) Delete the 'ECOOCMVl' program constant and specify/use the Program atus Data Structure's PROGRAM ID data element for this purpose.

ocess erarchical numeric ID: 1.1.1.1.5.1.6 ded name: AM2090V1 me: PGM Retrieve ARMS Data (AM2090V1) mment: ©Purpose:

To retrieve specified information from the ARMS database.

©Operational Method:

This program is executed using a single 256-byte data structure paramet r both input and output (see ©Notes for a detailed description) .

- Determine which type of information is being requested using the pass put parameter identification code.

-- Passed input parameter's data element for Data Structure ID Code ecifies the associated information retrieval processing description:

Confidential Page 88 of 246 8/11/00 ARMS Process Report

'Bl' - Retrieves AMXBCO file record trading partner's branch claims fice (BCO) information by the passed ENTERPRISE CUSTOMER ID

'B2' - Retrieves AMCLSTBL file ARMS Vehicle Class Description and Rate de Table information by the passed ECARS VEHICLE CLASS CODE

'B3' - Retrieves AMXREF Rental Transaction Cross-Reference, AMXBCOLl anch Claims Office*, and ARMSPRl Trading Partner attributes information by the ssed ENTERPRISE CUSTOMER ID, RENTAL LOCATION ID and RESERVATION//TICKET ID

'B4' - Retrieves AMXREF, AMXBCOLl*, ARMSPRl, along with the Rental Syst plication Specific** (ARMSPR5 or ARMSPR6) information by the passed RENTAL LOCATI and RESERVATION//TICKET ID

'B5' - Retrieves AMXREF, ARMSPRl, along with the Rental System plication Specific** (ARMSPR5 or ARMSPR6) information by the passed RENTAL LOCATI and RESERVATION//TICKET ID

•B6' - Retrieves AMXREF, ARMSPRl information by the passed RENTAL CATION ID and RESERVATION//TICKET ID

'B7' - Retrieves AMXBCOLl, ARMSPRl file information by the passed TERPRISE CUSTOMER ID

'B8' - Retrieves ARMSPRl file record information by the passed ENTERPRI STOMER ID

^■B9' - Retrieves AMXREF file record information by the passed RENTAL CATION ID and RESERVATION//TICKET ID

(*Note: Branch Claims Office information is retrieved only when the trieved Rental Transaction Cross-Reference indicates that it is not currently thorized or the Identificaiton Code is 'B4'. This condition was needed since ading Partner Profile ID was stored in two places. Undesirable results occurred ior to this condition.)

(**Note: Rental Application System Profiles consists of two files: One r ECARS used by ERAC branches for the rental administration of their group' s hides; and one for Claims Connection used by the National Reservations Call Cent aff for- the administration of third-party non-ERAC vehicle rentals . The Source I the Rental Transaction Cross-Reference ('B' = Branch ECARS; 'C = Claims nnection) determines which file the information is retrieved.

- IF the passed Identification Code does not match those accepted by th ogram, generate a program exception error and return an unsuccessful Completion atus Code ('D') to the calling program.

- IF the requested information record(s) are successfully retrieved, turn the values from those file(s) record(s) along with a successful Completion atus Code ('A') to the calling program.

- IF any record was not found, return blank value(s) from the specific le record along with a successful Completion Status Code ('A') to the calling ogram.

- IF a database error occurred, then generate a program exception error d return an unsuccessful Completion Status Code ('D') to the calling program.

- When the passed Identification Code is . 'B4 ' , determine if the trading rtner's branch claims office is currently active for electronic billing.

Confidential Page 89 of 246 8/11/00 ARMS Process Report

©Notes :

This program is currently executed with a single 256 character string out/output parameter that is further redefined using the empty ANDSB#V1 file as ai :ernal data structure. The external definition contains two important input ≥lds. The first is the Data Structure Identification Code, which is always a two 3ition alpha field in the first two positions of the data structure. The second nediately follows the first and is a one position Program Return Code. A value oJ ' returned in this position to the calling program indicates the processing requef 3 completed successfully. The total maximum length is 256 positions, and the unust ice has been defined as a "filler" (future expansion) field.

The data structure data elements descriptions are:

Input 2 character ARMS Identification Code

Output 1 character Program Return Code

Input 7 character Enterprise Customer ID

Input 10 character Rental Location ID

Input 6 character Reservation ID

Input 6 character Ticket ID

Input 2 character ECARS Vehicle Class Code

Input 8, 0 numeric Transaction Date (in CCYYMMDD rmat)

Input 10 character Calling Program ID

Output 20 character Vendor Transaction ID

Output 20 character Customer Transaction ID

Output 5 character ARMS Profile ID

Output 1 character ARMS Rental Transaction Cross-

Eerence File Record Status Code

Output 1 character Machine ID

Output 1 character Source ID - Branch Reservations / aims Connection

Output 10 character Branch Claims Office - AMXBCO

Output 14 character Enterprise Car Class Code

Output 20 character ARMS Car Class Description

Output 10 character Billing Program

Output 1 character Generate Extensions from Rental -

PG10

Output 1 character Generate Batch Extensions from ntal - P1FG11

Output 1 character Electronic Bill(Y/N)- P1YN12

Output 1 character Generate Policy Max Note P1YN17

Output 1 character View Ticket/Reservation 1 Day Ear

P1YN21

Output 1 character Only Days Needed For New Callback quest - P1YN22

Output 1 character Electronic Messaging - P1FG24

Output 1 character Allow Cust Tran^' Id on Fax Documen

P1YN25 .

Output 1 character Allow Underaged Driver - P1YN26

Output 1 character Send ELCDOl Format on RA - P1YN27

Output 1 character Generate Electronic & Paper Bills

YNBL

Output 1 character Insurance Pays Underage Surcharge

Output 1 character Weekend Slide Y=Sat/Sun M=Sun Onl

No Slide - PI

Output 1 character R=RA I=IN B=Both N=No

Output 1 character How to Populate RATD01?

Output 1 character ARMS Special Condition

Output 1 character Send Adjuster Name on RA Y/N

Confidential Page 90 of246 8/11/00 ARMS Process Report

Output 1 character Centralized Adjuster Phone # Output 1 character Expansion Flag Field Output 1 character Expansion Flag Field Output 1 character Expansion Flag Field Output 1 character Expansion Flag Field Output 1 character Expansion Flag Field Output 1 character Expansion Flag Field Output 1 character Expansion Flag Field Output 1 character Expansion Flag Field Output 1 character Expansion Flag Field Output 1 character RC Cancel Assignment Surchage adling

Output 73 character Filler (Future Expansion)

NOTE: New functions desired by this program have to be closely ordinated with the rental company application (ECARS or Claims Connection) guesting the new function desired in this program. All objects involved with the rf function must be moved into production at the same time.

IF this program is executing on a development platform, terminate the ogram when returning to the calling program for deallocation of resources among ny testers within an ARMS testing environment.

The ARMS system will now enable electronic invoices, payments and mittances (processed here) to be sent/received for non-ARMS Rental Management ading Partners that are Direct Billing/Remittance Trading Partners, such as αnessee Valley Authority (an Enterprise Fleet Services customer) . Therefore, ARM! 11 receive a data queue entry to generate an electronic invoice (and create an sociated ARMS Rental Transaction Cross-Reference (AMXREF) file record) when the ading partner never sent to ERAC (via ARMS) any initial rental authorization.

©Files: (CRUD)

AMXBCO (-R—) ARMS Branch Claims Office Cross-reference File, ing access path AMXBCOLl by Enterprise Customer ID.

AMXREF (-R—) ARMS Cross-reference File, accessed by Vendor ansaction ID cessed, by Rental Location ID, Ticket ID cessed by Rental Location ID, Reservation ID

ARMSPRl (-R--) ARMS Profile File - Application Specific Flags

ARMSPR5 (-R-) ARMS Profile File - ECARS Application Specific ta

ARMSPR6 (-R--) ARMS Profile File - CLAIMS Application Specific ags

AMCLSTBL (-R—) ARMS Vehicle Class/Rate code file

©Embedded Data/Constants :

•AM2090V1' as the PROGRAM ID

•Bl' through 'B9' are the ARMS Identification Code for the type of formation retrieval requested.

©Improvement Opportunities

1.) Convert from OPM RPG program to ILE RPG service program.

2.) Delete the 'AM2090V1' constant and use the Program Status Data ructure's left-adjusted PROGRAM ID value for the same purposes.

Confidential Page 91 of 246 8/11/00 ARMS Process Report

3. ) Replace the execution of the current ARMS Handle Internal Error ΑM0097V1') program with the execution of the newer ARMS Handle Internal/External rror ('AM0098') program.

rocess

[erarchical numeric ID: 1.1.1.1.5.1.8 jded name: MILMATH ime: PGM Manipulate Ambiguous Dates (MILMATH) >mment: ©Purpose:

To compare, add or subtract any passed input dates parameter field ilues. This program handles everything that the 'CCDATE' program does, with new .andards, plus a module/program to handle addition/subtraction and comparison of libigous dates in different formats.

©Operational Method:

This program accomplishes the same thing as any of the RPG operation >des it replaces (ADD, SUBTRACT, etc., see FUNCTIONS) except that it makes century irt of the equation. Basically, any dates calculated through MILMATH are expanded > include Century first and the fields in the program remain unchanged. Century i stermined for all Standard Dates by comparing the year portion to 40. Century is ϊtermined for all Date Of Birth Dates by assuming no Birth dates can be in the iture and no one is older than 100.

FUNCTIONS :

ADDITION: Of numbers representing dates to numbers representing dates id of numbers to numbers representing dates.

SUBTRACTION: Same as Addition only MILMATH also will handle ibtracting a number representing Date Of Birth from a number representing a standa

COMPARISON: Between numbers representing dates. Using COMP opcode.

EXPANSION: Of numbers representing dates with YY^'to YYYY.

Is currently executed with the following parameters:

Action: Input 1 Character - flag for the type of operation that ILMATH is to perform. (see FUNCTIONS.)

(YY is YYMM or YYMMDD

.pending on Length 2, 4 or 6. ) . • ^{■ '}

(A) = YY + # of Years

(B) = YY + YY

(C) = YY COMPARE to YY

(1) = YY Expand to YYYY

(S) = YY SUBTRACT # of Years

(T) = YY SUBTRACT YY

(U) = YY SUBTRACT Date Of Birth

Length: Input 2,0 Numeric - This parameter describes the lenc . data being sent in DATE1 and DATE2 .scribed below.

(2) = YY format- 2 digits.

Confidential Page 92 of 246 8/11/00 ARMS Process Report

(4) = YYMM format- 4 gits.

(6) = YYMMDD format- 6 digits.

Datel : I/O 8, 0 Numeric - This parm receives factor 1 of a lculation to be done and sends it back with ntury added.

Sent: Returned:

YY CCYY YYMM CCYYMM

YYMMDD CCYYMMDD

Date2: I/O 8,0 Numeric - This parm receives factor 2 of a lculation to be done and sends it back with ntury added.

Sent: Returned:

YY CCYY YYMM CCYYMM

YYMMDD CCYYMMDD

Result: Output 8,0 Numeric - This parm returns the result of th lculation if applicable.

HI Indie: Output 1 Character - This parm returns the HI indicator suit of all applicable calculations.

LO Indie: Output 1 Character - This parm returns the LO indicator suit of all applicable calculations.

EQ Indie: Output 1 Character - This parm returns the EQ indicator suit of all applicable calculations.

©Embedded Data/Constants :

Possible valid ACTION CODE values: 'A' = Add Number of Years 'B' = Add Years _Λ , *C' = Compare Years

'I' = IF Compared Years

•S' = Subtract Number of Years

*T' = Subtract Year from Year

•U' = Subract Date Of Birth Year from Current Year to compute age

©Improvement Opportunities:

Convert the programs that execute this program to ILE RPG and do all da nipulation by converting the values to the same format Date data types and rforming like data type operations on the dates.

ocess erarchical numeric ID: 1.1.1.1.5.1.9 ded name: CCRAXZ me: PGM Retrieve GPBR Tax Detail / Cvt Sys Time to Br Time (CCRAXZ) mment: ©Purpose:

To retrieve a rental branch tax accounting information and convert the stem time and date (currently United States Central Time Zone for all computer

Confidential Page 93 of 246 8/11/00 ARMS Process Report atformsj to the rental branch's local time and date by using the TIME ZONE JUSTMENT field value (that is +n or -n hours from the Central Time Zone time) .

©Operational Method:

This program is only executed when called by another program using two rameter fields: Group/Branch Tax Data for 215 characters, and Time Zone Conversi ta for 41 characters.

The Time Zone Conversion Data 41 characters are further redefined as:

1 alpha Input Action Code (possible values: A B G R T) 4 alpha Input Group/Branch ID

6 alpha Input Time (hhmmss - where "ss" is optional) 8 alpha Input Date (mmddccyy)

1 alpha Input Time Format Flag (possible values: M - litary/23-hour or S - Standard/12-hour with AM/PM)

6 alpha Branch Military Time (hhmmss)

6 alpha Branch Standard Time (hhmmAM)

6 alpha Branch Modified Date (mmddyy)

2 alpha Century (cc)

1 alpha Program Return/Error Code (possible values: B G blank)

Input Action Code dictates what this program is to return to the callin ogram. The codes are listed as follows:

A = Sent Group ID and Branch ID. Retrieve associated Group/Branch Ta le information and convert/adjust passed time/date according to time flag.

B = Sent Group ID and Branch ID. Only check if that Group/Branch ID lue exists in Group/Branch Tax file. If not, load 'B' to the PROGRAM RETURN/ERRO DE parameter subfield.

G = Sent Group ID only. Check if that Group ID value exists in ι, oup/Branch Tax file. If not, load 'G' to the PROGRAM RETURN/ERROR CODE parameter bfield.

R = Sent Group/Branch ID. Retrieve associated Group/Branch Tax file cord's information. Do not convert/adjust time/date. If not, load 'R* to the OGRAM RETURN/ERROR CODE parameter subfield.

T = Time conversion only. (Not used by any program currently calling RAXZ.)

Based on the outcome of the input codes and the data provided to the ogram, one of the following return codes will be generated:

(blank) = No error

B = Group/Branch ID record not found in the ECARS Group/Branch x File.

G = Group ID not found.

R = Group/Branch ID record not found for Group/Branch Tax file cord information retrieval request. T = Standard Input time invali cannot be interpreted because none of the characters "AaPp" (for AM/PM or am/pm) e in the passed TIME field's position 5. Impossible since this program does not it for time errors. It assumes time sent for conversion is correct.

Confidential Page 94 of246 8/11/00 ARMS Process Report

Retrieves the associated GPBRTZ Group/Branch Time Zone Adjustment file 3ord that indicates the time zone difference (in hours and fractions of hours) frc Lted States Central time.

Program CCRAXZ will expect the following implied questions from the Lling programs:

"What is the branch time/date equivalent to the system time/date?" "What are the individual government charge computation requirements r this branch?"

No editing occurs in this program - otherwise calling program is 3ponsible for validity of input data.

A record for the branch code must exist in the BC026P file. The value c s time zone adjustment field TZADJ must be -5 to less than 19.

©Files: (CRUD) ( signifies the file usage is only as an external a structure.)

- BC026P00 (-R--)

- GPBRTZ (-R—)

- DTPARM ( )

©Constant / Embedded Data:

AaPp - CHK array to check for a valid AM(am)/PM(pm) indication value.

©Improvement Opportunity: If the internal data structures were defined ;ernally, then any changes to the structure would be prone to less errors and onl recompile of all programs that utilized them would need to be performed to olement the change. (NOTE: The data structure to copy into each program is in JIB/QDOCSRC/CCRAXZ. However, some comments are out of date because they are no iger valid. This includes the specifications in the ARMS NEPs that check if the X3RAM RETURN/ERROR CODE = "A", but no code in the CCRAXZ program will load this Lue to that parameter subfield.)

There are several problems with the "time zone adjustment" field. )26P:TZADJ. While these pose no problem under the current range of time zones rered by existing branches, there are basic conceptual errors which show up when 2 data is applied on a global basis. The first problem is the existing range, -i:

+12, specified for the field. This iε a set of 25 values to be applied to 24 tii res; taking St Louis/Central time adjustment as 0, the -12 arid +12 values overlap the (global) 18th zone. Because the above set of values does not take into :ount the International Date Line, its use returns date errors. For systems whicl ≥ Central Standard (global time zone 6) as the system time, the correct value is ≥ offset from St Louis time; -5 to less than 19. However, the UK machine uses ≥enwich as its system time (global time zone 12) . In this case values from -12 t< 3S than +12 are correct. The meaning of the field and its values needs to be give. 3ingle definition. This has been accommodated by the two fields in the newer 3RTZ file. . • ^{' •}

GPBRTZ File Description: This file holds the time zone information for Ξh Enterprise Rental group/branch. Time Zone information includes: a.) Time zone offset from the International Date Line (was Greenwich Me. ne - GMT or UTC - Universal Coordinated Time) used to determine in which time zom branch exists, (e.g., Eastern, Central, Hawaii). b.) Time zone adjustment with respect to the Central Time used by the T -lock programs and to print time on the tickets. c.) Day Light Savings Observe indicator to indicate if branch observes plight Savings time period (from first Sunday in April through last Sunday in tober.)

Confidential Page 95 of 246 8/11/00 ARMS Process Report

©Notes:

Programs ECOOATVl, ECOOCNVl, ECOOEXVl, ECMSGVl, AM2051V1 and module Z004A use this program to adjust the St. Louis (System) time value to the local Dup/branch's time for the transaction data set being processed. ECOOATVl also ust is program during a different execution to retrieve the Sales Tax/Surcharge Accoui value to use for the decision of which formatted text should be used in the Brant servation file record's MAXIMUM AMOUNT text field.

ocess erarchical numeric ID: 1.1.1.1.5.1.10 ied name: ECMSGVl me: PGM Update Electronic Message (ECMSGVl) mment : ©Purpose:

To update ECARS Electronic Message database files with the received ssages from the trading partner.

©Operational Method:

This program is called from ECARS NEP's that run in the ARMS system thai ocess COMD01 or CBKD01 formats. It uses the transaction's passed key value ceived from the DQAM61V1 input data queue to access AMAPP file data and load the PD01, ADJDOl, COMD01, CBKD01 and SURD01 proprietary EDI record formats' data into e appropriate external data structures used within this program. This information then used to update an existing or write a new ECARS Message Control File (RACMSi cord and write corresponding new Message Detail (RACMSD) file records. No data ii turned to the calling program.

©Notes:

This program is executed with the following 3 input parameters:

6 character Reservation ID 96 character AMAPP Application Interface Input Transaction File key 10 character Calling Program ID

This program does not Set On *INLR so that it can be reexecuted without performing the program retrieval, memory loading/addressing and program itialization.

©Files: (CRUD)

AMAPP (-R--) Distributed APPLICATION INTERFACE input ansactions file

RACBRMST (-R—) Branch Reservations Master .File

RACMAST (-R—) ECARS Open Rental Contracts/Tickets Master File

RACCBCOC (-R—) ECARS Rental Callbacks Consolidation Control File

RACMSC (CRU-) Electronic Message Control File

RACMSD (C ) Electronic Message Detail File

©Embedded Data/Constants:

Actual Constants: ' - Sent by' 'Sent by'

'Surcharge Authorized: ^■ • /Day '

Confidential Page 96 of 246 8/11/00 ARMS Process Report

• /Rental *

' Percent '

Embedded Data:

'ECOOCMVl' 'ECOOATVl' 'AT' (Authorization Maintenance proprietary EDI transaction group type ie)

*T' (Authorization Transfer proprietary EDI tranaction set type code] ^■APPDOl' (Internal ARMS routing header proprietary EDI record format)

'ADJDOl' (Adjuster Detail proprietary EDI record format) 'CBKD01' (Callback Detail proprietary EDI record format) 'COMD01' (Comment proprietary EDI record format) 'SURD01' (Surcharge Approved for Direct Billing proprietary EDI record πmat)

•R' (Rental Document ID Reservation Type Prefix)

'D' (Rental Document ID Rental Contract/Ticket Type Prefix)

'*' (LastName*FirstName* delimiter)

•ARMS' (Record Created By Employee)

'D' (Per Rental-Daily Amount Surcharge)

'L' (Per Rental-Lump Amount Surcharge)

'P' (Per Rental-Percentage Surcharge)

'+' (Surcharge Amount Positive Sign)

' - ' (Surcharge Amount Negative Sign)

' 05 ' (Government Surcharge Type Code)

'I'

•E'

'Y' (Yes)

•N' (No)

'A'

'M' ('CCRAXZ' program execution input parameter for Action Code)

©Improvement Opportunities:

Convert this OPM RPG program to an ILE RPG service program comprised of Ξ RPG modules.

ocess

-irarchical numeric ID: 1.1.1.1.5.1.11 ied name: CCRS10 ne: PGM Print Reservation Detail (CCRS10) nment: ©Purpose:

To notify and alert the rental branch that a rental- authorization has en received from the rental management trading partner. Furthermore, display ecific information about the reservation: Renter's name; address; phone number; surance replacement information and any special requests (Vechile-Van, requires ckup date/time) .

©Operational Method

- Retrieve branch reservation detail record

- IF reservation was created thru ARMS

Print fields and headings. Calculate renter pay percent

- Convert flag fields to constants (pickup status, loss type)

- Build sucrcharge print lines

Confidential Page 97 of 246 8/11/00 ARMS Process Report

- Retrieve last 10 messages ONLY

- Override the printer file to the Group/Branch output queue. Change rmtype to PLAINPAPER

©Files : ( CR

RACBRMST (-R--)

RACPAYOP (-R-)

LIFEM#1 (-R- -)

ECSURCHG (-R—)

RACMSG1 (-R—)

>cess ϊrarchical numeric ID: 1.1.1.1.5.2 led name: ne: AUT Interface with Claims Connection (AT/CN/EX) nment: ©Definition: The automatic process by which the Claims Connection

.abase files are updated as a result of a request sent by the Rental Management iding Partner (AT, CN, EX,).

ocess ϊrarchical numeric ID: 1.1.1.1.5.2.1 ied name: CC00ATV1 ne: PGM Interface CC with Rental Authorization (CC00ATV1) nment: ©Purpose:

To update the claims connection database with any authorization Eormation received from the trading partner.

©Operational Method:

- Wait indefinitely for the next DQAM61V1 data queue entry with a key o rc^» .

- IF the receive data queue entry is a shutdown request, send that juest to data queue DQANDST to inform the distributed send program it has ended.

- IF the receive data queue entry is a non-shutdown request THEN

- Open programs files, if not previouly opened.

- Read the transaction data set records from AMAPP and and populate the associcated record format.

- IF authorization is a change request and there's no ticket updat the reservation.

- IF authorization is a change request and .there is a ticket, upda the ticket. Communicate this change to ARMS by forwarding a data queue entry to DQAM60V1.

- IF authorization is an add or transfer request and there's no ticket, create the reservation. Communicate this change to ARMS by forwarding a data queue entry to DQAM60V1.

- IF authorization is an add or transfer request and there is a cket, create the ticket. ***Can't happen. ENDIF

©Impovement Opportunity:

Confidential Page 98 of 246 8/11/00 ARMS Process Report

- Use program status data structure to retrieve program name.

©Files (CRUD)

ZLIFM#1 (-R—)

CCEMP (-R-)

CUSTMAST (-R-)

DROFLFl (-R—)

CCEXTCTL (C—)

CCEXTDTL (C—)

AMAPP (C—)

CCINST (C—-)

CCSURDTL (CR-D)

CCRES (CRU-)

CCNUM (-RU-)

CCMASTER (CRU-)

©Notes:

- This programs only runs on the Central machine.

- The request (s) sent by the Rental Management Trading Partner can eit >e an authorization adds (AT-Add) or authorization changes (AT-Chg) . There are thr .ypes of authorization adds: 1) An unsolicited authorization. 2) Authorization i prior vendor authorization request. 3) Authorization for an open ticket (Vendor >ver-ride)

- Presently there is a business limitation where you can not authorize ixisting open ticket.

>rocess lierarchical numeric ID: 1.1.1.1.5.2.2

?oded name: CC00EXV1 lame: PGM Interface CC with Rental Extension/Termination of Authorization (CC00EX\

Commen : ©Purpose:

To update the claims connection database with any rental extension information received from the trading partner in the function group type 'EX'.

©Operational Method

- Wait indefinitely for the next DQAM61V1 data queue entry with a key

'EXC

Open programs files, if not previouly opened.

- IF the receive data queue entry is a shutdown request, send that request to data queue DQANDST to inform the distributed send program it has ended

- IF the receive data queue entry is a non-shutdown request THEN

- Read the transaction data set records from AMAPP and and populate the associcated record format.

- Retrieve ARMS trading partner profile information through the use of ARMS data retrieval program(AM2090V1)

- IF extension is an extension request THEN

- Calculate new extension date.

- Generate associated text message for the history file.

- Re-calculate bill-to and bill-from dates. ENDIF

- IF extension is a termination request THEN

Confidential Page 99 of 246 8/11/00 ARMS Process Report

- Validate termination date received ^~~~

- Generate associated text message for the history file

ENDIF

ENDIF

©Files:

CCEXTCTL (CRU-)

CCEXTDTL (C—)

CCMASTER (-RU-)

AMAPP (-R- -)

REQSTCTL (CRU-)

©Improvement Opportunity

- Use program status data structure to retrieve program name.

©Constants

CONS ( 'Rental Extended Until: ' )

CONS ( 'Rental Terminated On: ' )

CONS ( «OVRDBF FILE (CCMASTER) WAITRCD{*IMMED) ' )

CONST( •DLTOVR FILE(CCMASTER) ' )

CONST( 'OVRDBF FILE(CCEXTCTL) WAITRCD(*IMMED) ' )

CONST( •DLTOVR FILE(CCEXTCTL) ' )

CONST( •OVRDBF FILE (CCEXTDTL) WAITRCD(*IMMED) • )

CONST( •DLTOVR FILE(CCEXTDTL) ' )

©Notes:

- This program only runs on the centralized finicial system(Central)

- The request (s) sent by the Rental Management Trading Partner can either be an extension or termination.

"rocess

Lierarchical numeric ID: 1.1.1.1.5.2.3 toded name: CCOOCNVl

Tame: PGM Interface CC with Rental Cancellation of Authorization (CCOOCNVl) tomment: ©Purpose:

To process cancelation requests received from the trading partner in t lunctional group type 'CN'.

©Operational Method

- Wait indefinitely for the next DQAM61V1 data queue entry with a key

CNC

- Open programs files, if not previouly opened.

- IF the receive data queue entry is a shutdown request, close prograπ iiles and send that request to data queue DQANDST to inform the distributed send >rogram it has ended.

- IF the receive data queue entry is a non-shutdown request THEN

- Read the transaction data set records from AMAPP and and populate the associcated record format.

- IF record not available THEN

Confidential Page 100 of 246 8/11/00 ARMS Process Report

- send transaction request back to DQAM61V1. ^~

ELSE

- Delete reservation record from file(CCRES) .

- Generate associated text message for the history file. ENDIF

ENDIF

©Improvement Opportunity:

- Use program status data structure to retrieve program name

©Constants/Embedded Data

FILE( ) WAITRCD (*IMMED)

©Files:

AMAPP (-R—)

CCINST (CR—)

CCRES (-R-D)

CCDIRBIL (-R-D)

>cess irarchical numeric ID: 1.1.1.1.5.2.43 led name: VFYOBJ ne: PGM Verify Objects Existence (VFYOBJ) nment: ©Purpose:

To determine if the specified object exists on the host platform.

©Operational Method:

- Check for the objects existence, return a code of '1' when object not ind.

©Notes :

• - - This program' is used by programs written in languages other than the ( take advantage of the CHKOBJ CL command.

ocess ararchical numeric ID: 1.1.1.1.6 ied name: me: AUT Generate Vendor Authorization Maintenance Request (AC/PA/RC/RE/RN/TR/VM) mment: ©Definition: The automatic process of dispatching delta queue entries fo propriate programs to generate the required record formats (data set) to be sent t Rental Management Trading Partner in response to an action by the Rental System o response to some communication received from the Rental Management Trading rtner. (This includes ECARS and Claims Connection)

ocess erarchical numeric ID: 1.1.1.1.6.1 ded name: me: AUT Generate Claims Connection Authorization Maintenance Request

C/RA/RC/RE/RN/TR)

Confidential Page 101 of 246 8/11/00 ARMS Process Report mment: ©Definition: The automatic process of dispatching data queue entries fo propriate programs to generate the required record formats (data set) to be sent t Rental Management Trading Partner in response to an action by the Rental System o response to some communication received from the Rental Management Trading rtner.

ocess erarchical numeric ID: 1.1.1.1.6.1.1 ded name: CC0OTKV1 me: PGM Generate CC Transfer Request (CC00TRV1) mment: ©Purpose:

To generate authorized reservation transfer (functional group type AT- ansfer) group type transaction data sets for sending to another Rental applicatio: Btem in response to a Claims Connection Rental System user requesting a transfer < authorized reservation to an Enterprise Rent-A-Car rental group's rental nctional site/branch.

©Operational Method:

- Receive the next DQAM60V1 data queue entry with the key value of 'TRC or Claims Connection) in infinite wait mode.

- If the received data queue entry is a shutdown request, send that dat eue entry to the DQANDST data queue to inform the AM0106 program that this ogram's shutdown has been completed and end the program.

- If the received data queue entry is a non-shutdown request, then from e data queue entry's Rental Location's Group ID and the Reservation ID passed, trieve record from the CCRES rental reservation file.

- Populate the associated record formats' fields as follows:

- Load the retrieved reservation's Transferred To Location Group/Branc to the COMD01 Comment Format's Comment Text with the COMTX data structure eformatted comment text immediately after the word "to" .

- Populate the ADJDOl data structure with the reservation's Bill-To tention-Name, Phone and Extension, the Bill-To Street Address, City, State and Btal Code.

- If adjustor name or phone/extension fields of the ADJDOl record forma e blank or zeroes, then retrieve the reservation's associated instructions file cords for sequence 001 and extract and load this adjustor information from that struction text line.

- Load every non-blank reservation's associated CCINST Instruction fil cord's Instruction text field value to a COMD01 comment record format's comment eld.

- Load the RNTD01 Renter Detail and AUTD01 Authorization Detail record rmats' fields with the associated fields' values of the retrieved CCRES file cord.

- If the retrieved CCRES file record's Repair Shop Name is not blank, en load that field value and its associated contact name and telephone number to e RPRDOl Repair Detail record format.

- Load the retrieved CCRES file record's Renter's Car (Vehicle being placed) Year (of Manufacture) and associated Make/Model and Date of Loss field lues to their associated fields in the RNTD02 Renter Detail #2 record format.

- Load the retrieved CCRES file record's Work Phone, Home Phone and cial Security Number field values to their associated fields in the RNTD02 Renter tail #2 record format's fields.

Confidential Page 102 of 246 8/11/00 ARMS Process Report

- If this transfer is NOT going to Claims Connection, transfer each sociated electronic message detail file records field value to their associated KD01 record format's fields.

- If attempt to retrieve the associated CCEXTCTL Callback Control file cord is successful and its record type is "R" (Reservation) , transfer each of its llback Type Codes and their associated Status Code field values to their associati KC01 Callback Control record format's fields. Likewise, if such a callback contrt rmat was loaded, then for every associated CCEXTDTL Callback Detail file record trieved, transfer its Note #1 and Note #2 field values, along with the note's typi iginal creation date, time, Employee ID and Program ID, to their associated CBKDi llback Detail record format's fields.

- Delete all associated CCSURDTL Surcharge Detail file records.

- Delete all associated CCEXTDTL Callback Detail file records.

- Delete the associated CCEXTCTL Callback Control file record.

- Write all of the non-blank record formats of the authorized reservatit ansfer (AT-Transfer) group type transaction data set to ANDIST transaction data s< tput file for sending from the distributed rental application system host platfon the ARMS centralized host computer system platform.

- Sends the written authorized reservation transfer (AT-Tiransfer) group pe transaction data set record formats' key value to the ANDIST output file's sociated DQANDST data queue.

- Sends the received input data queue entry back to the DQAM60V1 Dispatt ta queue with the key value of 'DIS' as a feedback method to the AM0060V1 dispatcl ogram to indicate that the dispatch task has been completed.

©Files: (CRUD) [When is shown as ( ), this is used as externally-defined data structure.]

ARMSDATA ( )

ARMSKEY _{( )}

DQAM60V1 ( )

APPD01V1 ( )

ADJD01V1 ( )

AUTD01V1 ( )

COMD01V1 • _{( )}

INSD01V1 ( )

RNTD01V1 ( )

RNTD02V1 ( )

RPRDOIVI ( )

CBKC01V1 ( ₎

CBKD01V1 ( )

$#EMACH ( )

CCINST (-R- -)

CCRES (-R- -)

CCSURDTL (-R-D)

CCEXTCTL (-R-D)

CCEXTDTL (-R-D)

ANDIST (C— -)

©Embedded Constant:

COMTX 'ARMS reservation transferred from Claims Connection to

©Notes:

Confidential Page 103 of 246 8/11/00 ARMS Process Report

- This program does not use the INSD01 format, but the ECOOTRVl program es.

- This program is only executed as an ARMS never-ending batch program i: e ARMS subsystem only on the distributed host computer system platform where Claii nnection Rental System application database resides. This program is currently bmitted by the ARMS Start-Up Job (CLL810) when executed on the system known as ENTRAL" host computer system platform. This never-ending batch program ends rmally when a shutdown data queue entry is received as input.

ocess erarchical numeric ID: 1.1.1.1.6.1.2 ied name: CC00RNV1 ne: PGM Generate CC Rental Notification (CCOORNVl) nment: ©Purpose: To generate an opening or closing rental notification, fictional group type 'RN' transaction data sets for sending to the Trading Partner

3t application system in response to a renter starting or ending the rental atract with a third-party rental vendor other than Enterprise Rent-A-Car.

©Operational Method:

- Receive the next DQAM60V1 data queue entry with the key value of *RNC infinite wait mode.

- If the received data queue entry is a shutdown request, send that dati 2ue entry to the DQANDST data queue to inform the AM0106 program that this ogram's shutdown has been completed and end the program.

- If the received data queue entry is a non-shutdown request with an ;ion code of '3 ' , then retrieve the record from the CCMASTER open rental itract/ticket file and populate the associated record formats' fields, leaving th< ϊ Date and End Time fields initialized to zeroes.

- If the received data queue entry is a non-shutdown request with an ;ion code of • ' , then retrieve the record f om the CCCLSC closed rental itract/ticket file and populate the associated record formats' fields, leaving tht irt Date and Start Time fields initialized to zeroes.

- Load the OFFD01V1 format with the passed data queue entry's itract/ticket ID and its location, along with the retrieved shipping name, street iress, city, state, postal code and toll-free telephone number for the Claims nection office.

- Write Rental Notification (RN) group type transaction data set record! transaction data set output file for sending from the distributed rental olication system host platform to the ARMS centralized host computer system itform.

- Sends the written Rental Notification group type transaction set reco: trmats' key value to the ANDIST output file's associated DQANDST data queue.

- Sends the received input data queue entry back to the DQAM60V1 Dispati ;a queue with the key value of *DIS' as a feedback method to the AM0060V1 dispatcl ogram to indicate that the dispatch task has been completed.

©Files:

Confidential Page 104 of246 8/11/00 ARMS Process Report

OFFDRB (-R-)

CCMASTER (-R—)

CCCLSC (-R—)

ANDIST (CRU-)

©Embedded Constant :

' 7680 ' is the sole Group/Branch ID key value used to access its reet/city/state address from the Branch Office Directory file (OFFDRB) at the finning of the program.

8002277800 as the overridding telephone number loaded into all D01 :ELCPHN fields .

jcess irarchical numeric ID: 1.1.1.1.6.1.3 led name: CCOORCVl ne: PGM Generate CC Request for Authorization Cancellation (CCOORCVl) nment: ©Purpose:

To generate a requests for authorization cancellation, functional group )e 'RC* , transaction data sets for sending to the Trading Partner host applicatio. stem.

©Operational Method:

- Receive the next DQAM60V1 data queue entry with the key value of 'RCC infinite wait mode.

- If the received data queue entry is a shutdown request, send that dat; ϊue entry to the DQANDST data queue to inform the AM0106 program that this jgram's shutdown has been completed and end the program.

- If the received data queue entry is a non-shutdown request with an ;ion code of '6', then load the APPD01V1 record format's Add/Change/Transfer Code ;h "P", else load it with a blank. (Unsure this is currently needed since AM0046¹ ΪS not reference any actions base on APPCDE with a "P" or blank value.)

- Write request for authorization cancellation (RC) group type insaction data set records to transaction data set output file for sending from tl 3tributed rental application system host platform to the ARMS centralized host nputer system platform.

- Sends the written request for authorization cancellation (RC) group oe transaction set record formats' key value to the ANDIST output file's associati \NDST data queue.

- Sends the received input data queue entry back to the DQAM60V1 Dispat a. queue with the key value of 'DIS' as a feedback method to the AM0060V1 dispatc ogram to indicate that the dispatched task has been completed.

©Notes: This program is only executed as an ARMS never-ending batch ogram in the ARMS subsystem only on the host computer system platform where Clai onection Rental System application database resides. This program is submitted b ≥ ARMS Start-Up Job (CLL810) when executed on the "CENTRAL" host computer platfor Ls never-ending batch program ends normally when a shutdown data queue entry is neived as input.

©Files:

Confidential Page 105 of 246 8/11/00 ARMS Process Report

- ANDIST (C )

©Improvement Opportunity:

There is no real difference in this program and the CCOORCVl program, th a minor change in the retrieved data queue entry key value' s third position (" . "C") and the loading of the APPSRC field with that same value, there is no fferences between these programs.

ocess erarchical numeric ID: 1.1.1.1.6.1.4 ded name: CC00REV1 me: PGM Generate CC Request for Authorization Extension (CC00REV1) mment: ©Purpose:

To generate rental extension request, functional group type, 'RE' ansaction data set for sending to the Trading Partner.

©Operational Method

- Wait indefinitely for the next DQAM60V1 data queue entry with a key o EC .

- IF the receive data queue entry is a shutdown request, close program les and send that request to data queue DQANDST to inform the distributed send ogram it has ended.

- IF the receive data queue entry is a non-shutdown request THEN

- Retrieve the necessary data base records

- IF extenstion request criteria met THEN

- Build the record formats, write the record to the distribution transaction file (ANDIST) .

- Send a data queue entry on to the Distributed Send to Centralized data queue (DQANDST) .

ENDIF

- Send a data queue entry to Dispatch Data Queue (DQAM60V1) with a key of 'DIS' to finish the request.

ENDIF

©Files:

CCEXTCTL (-R-)

CCEXTDTL (-R-)

CCMASTER (-R—)

REQSTCTL (CRU-)

ANDIST (C— -)

©Notes:

- This program only runs on the centralized finicial system(Central)

- Application Data Set Formats

- APPDOl - Enterprise internal format -VEDD01 - Vendor Extension format

- COMDOl - Comment detail format

- RPRDOl - Repair detail format

Confidential Page 106 of 246 8/11/00 ARMS Process Report cess rarchical numeric ID: 1.1.1.1.6.1.5 ed name: CCOORAVl ιe: PGM Generate CC Request for Authorization Maintenance (CCOORAVl) ment: ©Purpose:

To generate an Authorization Request, functional group type, 'RA' nsaction set for sending to the Trading Partner.

©Operational Method

- Wait indefinitely for the next DQAM60V1 data queue entry with a key of .C .

- IF the receive data queue entry is a shutdown request, close program es and send that request to data queue DQANDST to inform the distributed send gram it has ended.

- IF the receive data queue entry is a non-shutdown request THEN

- Using the action code set the routing for the transaction

- IF request is on a ticket THEN

- IF ticket is 'open' then

- Retrieve the open ticket data base records

(CCMASTER)

- Retrieve the Rental Management Trading Partner profile specifics

- Build the applicable record format (s) , writing the records to the distribution transaction e (ANDIST)

(Only build RATDOl record format if trading tner profile indicates it) . ELSE

- Retrieve the closed ticket data base records

(CCCLSC)

- Retrieve the Rental Management Trading Partner profile specifics

- Build the applicable record format (s), writing the records to the distribution transaction

.e(ANDIST)

(Only build RATDOl record format if trading rtner profile indicates it) . ENDIF

ELSE

- Retrieve the reservation data base, records (CCRES)

- Retrieve the Rental Management Trading Partner profile specifics

- Build the applicable record format (s), writing the records to the distribution transaction file (ANDIST) ENDIF

- Send a data queue entry on to the Distributed Send to Centralized data queue (DQANDST) .

- Send a data queue entry to Dispatch Data Queue

(DQAM60V1) with a key of 'DIS' to finish the request. ENDIF

©Files:

Confidential Page 107 of 246 8/11/00 ARMS Process Report

CCMASTER (-R- - )

CCCLSC (-R— )

CCRES ( -R— )

CCINST (-R— )

OFFDRB (-R- -)

ANDIST (C- — )

©Notes :

- This program only runs on the centralized finicial system(Central)

- Application Data Set Formats

- APPDOl - Enterprise internal format

- AUTD01 - Authorization detail format

- COMD01 - Comment detail format

- RATDOl - Rate detail format

- RNTD01 - Renter detail 1 format

- RNTD02 - Renter detail 2 format

- RPRDOl - Repair detail format

- INSD01 - Insured detail format

- ELCD01 - Arms vendor location

>cess irarchical numeric ID: 1.1.1.1.6.1.11 led name: CCOOACVl ne: PGM Generate CC Authorization Confirmation (CCOOACVl) nment: ©Purpose:

To generate an Authorization Confirmation, functional group type (AC) , insaction set that informs the Trading Partner of the authorization confirmation liber and the Enterprise location that is handling the insurance replacement.

©Operational Method:

- Wait indefinitely for the next DQAM60V1 data queue entry with a key oj -C .

- IF the receive data queue entry is a shutdown request, close program Les and send that request to data queue DQANDST to inform the distributed send jgram it has ended.

- IF the receive data queue entry is a non-shutdown request THEN

- Construct the necessary record format, write the record to the distribution transaction file(ANDIST)

- Send a data queue entry on to the Distributed Send to Centralized data queue(DQANDST) .

- Send a data queue entry to Dispatch Data Queue (DQAM60V1) with a key of 'DIS' to finish the request.

©Improvement Opportunity:

- Use program status data structure to retrieve program name

©Embedded Constant:

'7680' - default location •8002277800' - default location phone# •CCOOACVl' - Program name

Confidential Page 108 of 246 8/11/00 ARMS Process Report

©Fil s :

OFFDRB (-R—) ANDIST (CRU-)

©Notes :

- This program only runs on the CENTRAL machine.

- Application Data Set Formats

- APPDOl - Enterprise internal format

- ELCD01 - Arms vendor location

ocess

-.rarchical numeric ID: 1.1.1.1.6.2 ied name: ne: AUT Generate ECARS Authorization Maintenance Request (AC/RA/RC/RE/RN/TR/VM) nment: ©Definition: The automatic process of dispatching data queue entries fo: propriate programs to generate the required record formats (data set) to be sent ti Rental Management Trading Partner in response to an action by the Rental System o: response to some communication received from the Rental Management Trading rtner.

ocess

≥rarchical numeric ID: 1.1.1.1.6.2.3 ied name: ECOOVMVl ne: PGM Generate EC Vendor Message (ECOOVMVl) nment : ©Purpose:

To generate a vendor message functional group type, 'VM' , transaction ta sets for sending an electronic message from the rental agent to the trading rtner.

©Operational Method:

• ~ - Receive the next DQAM60V1 data queue entry with the key value of 'VMB infinite wait mode.

- If the received data queue entry is a shutdown request, send that dat. sue entry to the DQANDST data queue to inform the AM0106 program that this ogram*s shutdown has been completed and end the program.

- If the received data queue entry is a non-shutdown request, then load ≥ APPD01V1 record format and for every RACMSD record read by the passed oup/Branch ID and the non-blank Ticket ID prefixed with a "D" ,(or if ticket is ank the passed Reservation ID prefixed with a "R") , load a COMDOIVI record format i update the RACMSD file record's MESSAGE STATUS field with the value 'O' (Output

- Write vendor message (VM) group type transaction data set records to DIST transaction data set output file for sending from the distributed rental plication system host platform to the ARMS centralized host computer system atform.

- Send the written vendor message (VM) group type transaction set recor rmats' key value to the ANDIST output file's associated DQANDST data queue.

Confidential Page 109 of 246 8/11/00 ARMS Process Report

- Send the received input data queue entry back to the DQAM60V1 Dispatcr :a queue with the key value of 'DIS' as a feedback method to the AM0060V1 dispatcl >gram to indicate that the dispatched task has been completed.

©Files : (CRUD) ( signifies usage as an external data ructure)

RACMSD1 (-RU-)

ANDIST (C—

APPD01V1 ( )

COMDOIVI ( )

DQAM60V1 ( )

©Embedded Constant : Program name ' ECOOVMVl ' . (Could be replaced by usc- the program status data structure ' s subf ield for program. )

jcess irarchical numeric ID: 1.1.1.1.6.2.4 led name: ECOORCVl ne: PGM Generate EC Request for Authorization Cancellation (ECOORCVl) nment: ©Purpose:

To generate a request for authorization cancellation functional group >e, 'RC, transaction data sets for sending to the trading partner.

©Operational Method:

- Receive the next DQAM60V1 data queue entry with the key value of 'RCB' infinite wait mode.

- If the received data queue entry is a shutdown request, send that date lue entry to the DQANDST data queue to inform the AM0106 program that this >gram's shutdown has been completed and end the program.

- If the received data queue entry is a non-shutdown request with an ;ion code of '6', then load the APPD01V1 record format's Add/Change/Transfer Code :h "P";~else load it with a blank. (Unsure this is currently needed since AM0046 ΪS not reference any actions base on APPCDE with a "P" or blank value.)

- Write request for authorization cancellation (RC) group type insaction data set records to transaction data set output file for sending from tl stributed rental application system host platform to the ARMS centralized host nputer system platform.

- Send the written request for authorization cancellation (RC) group tyj insaction set record formats' key value to the ANDIST output file's associated NDST data queue.

- Send the received input data queue entry back to the DQAM60V1 Dispatcl :a queue with the key value of 'DIS* as a feedback method to the AM0060V1 dispatcl ogram to indicate that the dispatched task has been completed.

©Files: (CRUD)

- ANDIST (C )

Confidential Page 110 of 246 8/11/00 ARMS Process Report

©Improvement Opportunity: There is no real difference between this jgram and the program, CCOORCVl. With a minor change in the retrieved data queue ry key value's third position ("B" vs. "C") and the loading of the APPSRC field ;h that same value, there is no differences between these programs.

jcess irarchical numeric ID: 1.1.1.1.6.2.5 led name: ECOOACVl ne: PGM Generate EC Authorization Confirmation (ECOOACVl) nment: ©Purpose:

To generate an Authorization Confirmation, functional group type, 'AC, insaction data set that informs the Rental Management Trading Partner of the .horization confirmation number and the Enterprise location that is handling the 3urance replacement.

©Operational Method

- Wait indefinitely for the next DQAM60V1 data queue entry with a key oi * .

- IF the receive data queue entry is a shutdown request, close program Les and send that request to data queue DQANDST to inform the 'distributed send jgram it has ended.

- IF the receive data queue entry is a non-shutdown request THEN

- Construct the necessary record format, write the record to the distribution transaction file (ANDIST)

- Send a data queue entry on to the Distributed Send to Centralized data queue (DQANDST) .

- Send a data queue entry to Dispatch Data Queue (DQAM60V1) with a key of 'DIS' to finish the request.

©Files (CRUD)

OFFDRB (-R—)

ANDIST (C—)

©Notes

- Application Data Set Formats

- APPDOl - Enterprise internal format

- ELCD01 - Arms vendor location

©Improvement Opportunity

- Use program status data structure to retrieve program name

©Constant/Embedded Data 'ECOOACVl' - Program name

ocess erarchical numeric ID: 1.1.1.1.6.2.6 ied name: EC00REV1 me: PGM Generate EC Authorization Extension Request (EC00REV1) mment: ©Purpose:

To generate an Extension Request, functional group type 'RE', transacti< ta set for sending to the Rental Management Trading Partner in response to the

Confidential Page 111 of 246 8/11/00 ARMS Process Report tal System speaking with the bodyshop and changing the contract's estimated npletion date.

©Operational Method

- Wait indefinitely for the next DQAM60V1 data queue entry with a key o: SB' .

- IF the receive data queue entry is a shutdown request, close program Les and send that request to data queue DQANDST to inform the distributed send ogram it has ended.

- IF the receive data queue entry is a non-shutdown request THEN

- Retrieve the necessary data base records

- IF extenstion request criteria met THEN

- Build the record formats, update the database records, write the record to the distribution transaction file (ANDIST) .

- Send a data queue entry on to the Distributed Send to Centralized data queue (DQANDST) .

ENDIF

- Send a data queue entry to Dispatch Data Queue (DQAM60V1) with a key of 'DIS' to finish the request.

ENDIF

©Notes

- Application Data Set Formats

- APPDOl - Enterprise internal format

- VEDD01 - Vendor Extension format

- COMD01 - Comment detail format

- RPRDOl - Repair detail format

©Files (CRUD)

CB007P00 (-R—)

CB012P01 (-RU-)

RACMSG2 (-RU-)

RACMAST (-R—)

RACSMAST (-R—)

ECEXTCTL (CRU-)

ANDIST (C—)

©Improvement Opportunity

- Use program status data structure to obtain the program name.

©Constants/Embedded Data

- 'ECOOREVl' - pgm name

ocess erarchical numeric ID: 1.1.1.1.6.2.7 ded name: ECOORAVl me: PGM Generate EC Authorization Maintenance Request (ECOORAVl) mment : ©Purpose:

To generate an Authorization Request functional group type, 'RA' ansaction data set for sending to the Rental Management Trading Partner in respor the Rental System creating/changing a rental contract.

Confidential Page 112 of 246 8/11/00 ARMS Process Report

©Operational Method ^{~ ~~}

Wait indefinitely for the next DQAM60V1 data queue entry with a key of 'RAB'.

IF the receive data queue entry is a shutdown request, close program files and se_¬ at request to data queue DQANDST to inform the distributed send program it has ded.

IF the receive data queue entry is a non-shutdown request THEN

- Attempt to retrieve the reservation data base records (RACBRMST)

- IF request is on a ticket THEN

- Retrieve the open and closed ticket database records (RACMAST, RACSMAST, RACCLSC, RACSCLC)

- Using the action code set the routing for the transaction Retrieve the Rental Management Trading Partner profile specifics

- Build the applicable record format (s) from the database files, writes the cords to the distribution transaction file. (Only build RATDOl record format if ofiled.)

- Send a data queue entry on to the Distributed Send to Centralized data queue (DQANDST) .

- Send a data queue entry to Dispatch Data Queue (DQAM60V1) with key of 'DIS' to finish the request.

ENDIF - IF request is on a reservation THEN

- Using the action code set the routing for the ansaction - Retrieve the Rental Management Trading Partner profile specifics

- Build the applicable record format (s), writing the records to the distribution transaction file. (Only build RATDOl record format if profiled) Send a data queue entry on to the Distributed Send to

Centralized data queue (DQANDST) .

- Send a data queue entry to Dispatch Data Queue (DQAM60V1) with a key of 'DIS' to finish the request.

ENDIF ENDIF

©Files (CRUD)

RACMAST ^• (-R—)

RACSMAST (-R-)

RACBRMST (-R-)

RACBRIST (-R—)

RACINS (-R—)

RACBRWRT (-R-)

OFFDRB (-R— )

RACCLSC (-R—)

RACSCLC (-R—)

ANDIST (C-—)

ocess erarchical numeric ID: 1.1.1.1.6.2.8 ded name: RTVEMCHA me: PGM Retrieve Machine Attributes (RTVEMCHA) mment : ©Purpose:

To retrieve the machine attributes for the machine that this program is lining on.

Confidential Page 113 of246 ^: 8/11/00 ARMS Process Report

©Operational Method:

- Retreive the current system name (factor in emulation) .

- Retreive attributes associated to host platform.

- Return data elements to calling program.

©Notes:

- $#EMCAH is an external data structure used as a template for the data passed to and from.

©Files (CRUD)

MACHID#1 (-R—)

GACTL (-R—)

jcess irarchical numeric ID: 1.1.1.1.6.2.17 led name: AM1070V1 ne: PGM Retrieve ARMS Vehicle Class and Rate Designation (AM1070V1) nment: ©Purpose:

To retrieve the associate rental rate amount for a given vehicle class le, OR, to retrieve an associated vehicle class code for a specified rental rate >unt.

©Operational Method:

The input parameters are: Group ID, Branch ID, Vehicle Class Code >tional) , Daily Rental Rate Amount (Optional) , Effective Date (Optional - Else rrent system date will be used), and Control Mode ('T¹ = for rental contract :ket; 'R' = for rental Reservation) .

- IF an Effective Date value is not received, then retrieve and use stem date for Effective Date.

- IF request is on a rental contract/ticket (Control Mode = 'T'), a val: iicle Class Code will be returned for the effective date sent. (Daily Rental Rate irged Amount will always- have a value when sent since it is an open or closed ital contract. )

— Validate the rate received by comparing effective date to the :e date ranges. Then retrieve the associated vehicle class code for that rate ii ϊ National Reservations Standard Rates (NRXRAT1) file, for "I" Insurance type ϊtomers only by Group/Branch IDs, Daily Rental Rate Amount and Effective Start :e, comparing the Effective Date to being on or within the rental rate amount's Eective Start and Stop Date ranges.

IF all of the records are read within a Group/Branch ID and no Lid records are found, then retrieve a vehicle class code by reading backwards rough NRXRAT1 until a valid record is found. IF no valid record is found, then return blanks in the Vehicli ass Code. IF a valid record is found, then verify its vehicle class cod valid by retrieving an associated record in National Reservations Car Type (NRCT^"

Le. A valid record in the NRCTY file is a record where the Effective te is within the Effective Start and Stop dates, inclusive. IF rate and vehicle class do not match, then retreive the cla r the previous rate with a valid effective date.

- ENDIF

- IF request iε on a reservation (Control Mode = 'R' ) Confidential Page 114 of 246 8/11/00 ARMS Process Report

— When Vehicle Class Code and Daily Rental Rate Amount iσted/Authorized) has been received Only validate that the Daily Rental Rate Amount (Quoted)

:eived is compatible with the Vehicle Class Code by retrieving the daily rental :e amount's associated vehicle class code for that rate in the National servations Standard Rates (NRXRATl) file, for "I" Insurance type customers only bv >up/Branch IDs, Daily Rental Rate Amount and Effective Start Date, comparing the .ective Date to being on or within the rental rate amount's Effective Start and >p Date ranges. Then find the associated vehicle class code for that daily renta :e amount. IF the Daily Rental Rate Amount's Vehicle Class Code and th ssed Vehicle Class Code do not match, then do not return either the rate nor iicle class code, replace them with blanks.

- When Vehicle Class Code received, the associated Rate Amount wii returned if a valid record is found within the effective date.

- Validate the Vehicle Class Code received, then find the sociated vehicle daily rental rate for that class.

IF rate and vehicle class do not match, then do not retui ;her rate or class.

** This option is not return values when found. Issue will written and submitted.

- When Rental Rate Amount received, an attempt will be made to fir ralid vehicle class.

- Validate the rate received by comparing effective date to i rate date ranges. Then find the associated vehicle class code for that rate.

IF rate and vehicle class do not match, then do not retui :her rate or class. ENDIF

©Notes :

When indicating that Vehicle Class Code and Rental Rate Amount not .urned, it means that these fields will be cleared to their lowest possible value, inks and zeroes respectively.

Sometimes there are multiple vehicle types for any given Group ID, Branc , and Vehicle Class Code'. However, this program has been changed to allow a rate be returned correctly when this situation occurs.

©Files: (CRUD)

NRXRATES (-R-) by both logical access paths: NRXRATl and NRXRAT2. NRCTYP (-R—) by both logical access paths: NRCTY and NRCTL2-.

ocess

.irarchical numeric ID: 1.1.1.1.6.2.20 ied name: ECCBBSM ne: PGM Maintain Consolidated Body shop Callbacks Control File for ARMS (ECCBBSM) nment: ©Purpose: To maintain the consolidated body shop callback information.

©Operational Method:

- This program accepts a parameter list that contains specific data ≥ments as it relates to the callback (group, branch, ticket #, type, status, npletion date, shop info, etc.) and updates the rental system (ECARS) data base le.

Confidential Page 115 of 246 8/11/00 ARMS Process Report

- Determine tasks to be performed based on the control field value

- *X^» = Exit program

- 'C = Retrieve callback information from database and return to Lling program

- 'D* = Delete callback

- 'K' = Check if callback exists

'L' = Lock callback from other users

- 'U' = Update callback with the passed information

©Files:

RACCBBS (CRUD)

ocess

-irarchical numeric ID: 1.1.1.1.6.2.22 ied name: UTS001A ne: PGM Generate Century for DOB (UTS001A) nment: ©Purpose: To convert a six character date of birth to an eight characti te with the correct century.

©Operational Method:

- this program accepts a parameter list from which a date is received as «D and converted to CCYYMMDD.

- Set base line date (current date minus 1)

- Load current date century into output date of birth century.

- IF the passed date of birth with the concatenated century is greater an the base line date, subtract 1 from the date of birth century.

- Return converted (CCYYMMDD) date of birth.

ocess

≥rarchical numeric ID: 1.1.1.1.6.2.24 ied name: EC00TRV1 me: PGM Generate EC Transfer Request (EC00TRV1) mment: ©Purpose:

To generate authorized reservation transfer (AT-Transfer) functional oup type transaction data sets for sending to another Rental application system i: 3ponse to a rental user transferring an authorized reservation to a different ntal functional site (group) .

©Operational Method:

- Receive the next DQAM60V1 data queue entry with the key value of 'TRB ransfers from Enterprise Branch Rental System) in infinite wait mode.

- If the received data queue entry is a shutdown request, send that dat eue entry to the DQANDST data queue to inform the AM0106 program that this ogram' s shutdown has been completed and end the program.

- If the received data queue entry is a non-shutdown request, then from e data queue entry's Rental Location's Group ID and the Reservation ID passed, trieve record from the RACBRMST rental reservation file.

Confidential Page 116 of 246 8/11/00 ARMS Process Report

- Populate the associated record formats' fields as follows:

IF the retrieved reservations closing Group/Branch ID is '7680' (Claims Connection), then load the COMD01 Comment Format's Comment Text with the COM002 data structure preformatted comment text and insert the reservation's Pickup Group/Branch immediately after the word "from", else load the COM003 data structure preformatted comment text with the inserted reservation's Pickup Group/Branch ID immediately after the word "from" and insert the reservation's closing Group/Branch ID after the word "to" .

- Populate the ADJDOl data structure with the reservation's Bill-To Attention Name, Phone and Extension, the Bill-To Street Address, City, State and Postal Code.

- IF adjustor name or phone/extension fields of the ADJDOl record format are blank or zeroes, then retrieve the reservation's associated instructions file records for sequence 001 and extract and load this adjustor information from that instruction text line.

- Load every non-blank reservation's associated instruction file record that has a sequence number 002 through 096 as a COMD01 comment record format.

- Load the associated RACINS Renter Insurance Coverage file record's Policy ID and Policy Expiration date to the INSD01 Insured record format.

- Load the retrieved RACBRIST file's 996 - 998 record's Insured name, address to the INSD01 record format fields.

- IF the INSD01 record format's Policy ID and its expiration date is blank/zero, then load them from the RACBRIST file records' Policy ID and Expiration Date.

- Load the RNTD01 Renter Detail and AUTD01 Authorization Detail record formats' fields with the associated fields' values of the retrieved RACBRMST file record.

- If the retrieved RACBRMST file record's Repair Shop Name is not blank, then load that field value and its associated contact name and telephone number to the RPRDOl Repair Detail record format.

- Attempt to retrieve the associated RACBRWRT Reservation Pre-Write file record and load its Date of Birth field value to the same field in the AUTDOl record format's same field.

- If the retrieved RACBRMST file record's Renter's Car (Vehicle being replaced) Year (of Manufacture) is non-blank, then load that field value and its associated Make/Model and Date of Loss field values to their associated fields in the RNTD02 Renter Detail #2 record format.

If the retrieved RACBRMST file record's Work Phone, Home Phone or Social Security Number field values are not zeros or blanks, then also load those values to their associated fields in the RNTD02 Renter Detail #2 record format.

- For every associated RACCBDET Callback Detail file record retrieved, transfer its Note #1 and Note #2 field values, along with the note's type original creation date, time. Employee ID and Program ID, to their associated CBKD01 Callback Detail record format's fields.

- If this transfer is NOT going to Claims Connection, transfer each associated electronic message detail file records field value to their associated CBKD01 record format's fields.

- If attempt to retrieve the associated CB007POO Callback Control file record is successful , transfer each of its Callback Type Codes an their associated Status Code field values to their associated CBKC01 Callback Control record format's fields .

- Write all of the non-blank record formats of the authorized reservation transfer (AT-Transfer) group type transaction data set to ANDIST transaction data set output file for sending from the distributed rental application system host platform to the ARMS centralized host computer system platform.

- Sends the written authorized reservation transfer (AT-Transfer) group type transaction data set record formats' key value to the ANDIST output file's associated DQANDST data queue.

Confidential Page 117 of 246 8/11/00

Delete all associated ECSURCHG Surcharge Detail file records. Delete all associated RACMSC Electronic Message Control file records. Delete the associated CB012P Electronic Message Detail file record. Delete the associated RACCBK3 Callback Consolidation Skeleton file record.

Delete all associated RACCBDET Callback Detail file records. Delete all associated RACPAYOP Open Payments file records.

- Sends the received input data queue entry back to the DQAM60V1 Dispatch data queue with the key value of 'DIS' as a feedback method to the AM0060V1 dispatch program to indicate that the dispatch task has been completed.

©Notes:

Do not write INSDOl format for a transfer of an authorized reservation for a claimant, since the AT-Add had updated the claimant's insurance information to create a RACINS (ECR Renter's Insurance Detail) record without loading the INSURED NAME and CITY/ST/ZIP. However, when the branch reservation is transferred, this program loaded the INSDOl record format with this insured information from RACINS but the INSURED NAME, CITY/ST/ZIP and RECORD FORMAT ID were not loaded since they are blanks. This is because that information is not available at the time of the transfer. This is to prevent the AT-Transfer from being rejected in AM0025V1.

©Files: (CRUD) [When is shown as ( ) , this is used as an externally-defined data structure.]

ARMSDATA ( )

ARMSKEY ( )

DQAM60V1 ( )

APPD01V1 ( )

ADJD01V1 ( )

AUTD01V1 ( )

COMDOIVI ( )

INSD01V1 { )

RNTD01V1 ( )

RNTD02V1 ( )

RPRD01V1 ( )

CBKC01V1 ( )

CBKD01V1 ( )

$#EMACH ( )

RACBRMST (-R-) Opened with the OVRDBF

RACBRIST (-R--) Opened with the OVRDBF

RACINS (-R--) Opened with the OVRDBF

RACBRWRT (-R--) Opened with the OVRDBF

RACCBK3 (-R-D) Opened with the OVRDBF

RACCBCOC (-R-D) Opened with the OVRDBF

RACPAYOP (-R-D) Opened with the OVRDBF

ECSURCHG (-R-D) Opened with the OVRDBF

CB007P00 (-R-D) Opened with the OVRDBF

RACCBDET (-R-D) Opened with the OVRDBF

RACMSC (-R-D) Opened with the OVRDBF

CB012P00 (-R-D) Opened with the OVRDBF

RACPAYCL (C ) Opened with the OVRDBF

ANDIST (C ) Opened with the OVRDBF

©Constants as Compile-Time Data: OVRDBF FILE( ) WAITRCD (*IMMED)

Confidential Page 118 of 246 8/11/00 ARMS Process Report .

YES C CONST ('Y') ^{" "}

NO C CONST('N')

OFF C CONST ( • 0 ' )

ON C CONST ( ' 1 ' )

Process/shutdown < ies

TR C CONST('TR')

SD C CONST( 'SD• )

TSTDWN c CONSTC*DOWN •)

Format Names

APPDF1 c CONST ('APPDOl')

ADJDF1 C CONS ('ADJDOl')

AUTDF1 C CONST('AUTDOl')

INSDF1 C CONST ('INSDOl')

RNTDF1 C CONST ('RNTD01')

RKTDF2 C CONS ('RNTD02')

RPRDF1 C CONST ('RPRDOl')

COMDF1 C CONST('COMD01')

Pre-formatted comment text: COM002 'ARMS reservation transferred from to Claims ' COM003 'ARMS reservation transferred from to •

Process

Hierarchical numeric ID: 1.1.1.1.6.2.25 Coded name: ECOORNVl

Name: PGM Generate EC Rental Notification (ECOORNVl) Comment : ©Purpose:

To generate an opening or a closing rental notification functional group type, 'RN', transaction data sets for sending to a Rental Management Trading Partner host application system.

©Operational Method:

- Receive the next DQAM60V1 data queue entry with the key value of 'RCB' in infinite wait mode.

- If the received data queue entry is a shutdown request, send that data queue entry to the DQANDST data queue to inform the AM0106 program that this program's shutdown has been completed and end the program.

- If the received data queue entry is a non-shutdown request with an action code of • 3 • , then attempt to retrieve the record from the RACMAST open rental contract/ticket file first. If not found attempt to retrieve from QRACCLSQ. Populate the associated record formats' fields including loading, the Contract Date to Start Date field and Time Out of Rental Segment #1 to the Start Time field, leaving the End Date and End Time fields initialized to zeroes to signify this is an opening rental notification.

- If the received data queue entry is a non-shutdown request with an action code of ' 4 • , then retrieve the record from the QRACCLSQ closed rental contract/ticket file and populate the associated record formats' fields including the End Date and End Time fields, leaving the Start Date and Start Time fields initialized to zeroes to signify this is a closing rental notification.

- If the received data queue entry is a non-shutdown request with an action code of ' 5^■ , then attempt to retrieve the record from the RACMAST open rental contract/ticket file first. If not found attempt to retrieve from QRACCLSQ.

Confidential Page 119 of 246 8/11/00 ARMS Process Report .

Populate the associated record formats' fields including the End Date and End Time fields, leaving the Start Date and Start Time fields initialized to zeroes to signify this is a closing rental notification.

- If the received data queue entry is a non-shutdown request with an action code of other than the previously specified values or there was no successful database retrieval, then generate a formatted program dump,^" call/execute AM0097 program to notify the ARMS On-Call of this failure and reject the transaction for further processing.

- Load the OFFD01V1 format with the passed data queue entry's contract/ticket ID and its location, along with the retrieved shipping name, street address, city, state, postal code and the telephone number for that Enterprise Rent- A-Car rental office.

- Write Rental Notification (RN) group type transaction data set records to transaction data set output file for sending from the distributed rental application system host platform to the ARMS centralized host computer system platform.

- Send the written Rental Notification group type transaction set record formats' key value to the ANDIST output file's associated DQANDST data queue.

- Sends the received input data queue entry back to the DQAM60V1 Dispatch data queue with the key value of 'DIS* as a feedback method to the AM0060V1 dispatch program to indicate that the dispatch task has been completed.

©Files: (CRUD)

- OFFDRB (-R--)

- RACMAST (-R—)

- QRACCLSQ (-R—)

- ANDIST (C )

©Constants:

'7580' is the sole Group/Branch ID key value used to access its street/city/state address from the Branch Office Directory file (OFFDRB) at the beginning of the program.

8002277800 as the overridding telephone number loaded into all ELCD01:ELCPHN fields.

Process

Hierarchical numeric ID: 1.1.1.1.7

Coded name:

Name: AUT Send Transaction for Centralized Processing (AM106 - AM105)

Comment: ©Definition: The automatic process of sending the transaction data set from the distibuted machine to the centralized machine for processing, via ICF files.

Process

Hierarchical numeric ID: 1.1.1.1.7.1

Coded name: AM0106

Name: PGM Send Transaction for Centralized Processing (AM0106)

Commen : ©Purpose:

To send transaction data sets from the Distributed machine to the Centralized machine for processing.

Confidential Page 120 of246 8/11/00 ARMS Process Report

©Operational Method:

- Acquire the program device 'AM0106'

- Wait indefinitely for the next DQANDST data queue entry

- IF the receive data queue entry is a shutdown request

- Increment counter. When the count equals the number of ARMS never ending transaction programs running on that host platform close program files and send that request to ICF device AM0106 to inform the centralized receive program that AM010S has ended.

- Submit job for error report and history file update (CLL797) . ENDIF

- IF the receive data queue entry is a non-shutdown request

- Retreive the application transaction data set records

- Write the data set to ICF device AM0106 to send transaction data set to the centralized ARMS host platform ENDIF.

©Notes: This program is currently evoked from the executing Receive Transaction from Distributed Host System (AM0105) program on the centralized ARMS host platform to be the source of the sender linked ICF communication session. Presently, the distributed rental system host platform are all systems excluding BIRELAND, VGERMANY, and DK.

©Files : (CRUD)

- ANDIST (-R--)

- AMVRGTST (-R—)

Process

Hierarchical numeric ID: 1.1.1.1.7.2

Coded name: AM0105

Name: PGM~Receive Transaction from Distributed Host System (AM0105)

Comment: ©Purpose:

To receive transacation data sets from the distributed rental system host platform on the ARMS centralized host platform.

©Operational Method:

- When starting the program, attempt to acquire the device up to 5 times with a one minute delay between each try before signalling an error.

- Receive input transaction from the distributed rental system host platform

- IF data was received IF transaction data set is equal to Vendor Error (ER) or Vendor

Office Information(OF)

- Write records to pre-package file(AMPACK)

- Send data queue entry to pre-package

(DQAMPKG) ELSE

- Write records to Edit Transaction file (AMSET)

- Send data queue entry to Transaction Editor (DQAM25) ENDIF

Confidential Page 121 of 246 8/11/00 ARMS Process Report

ELSE

- IF shutdown request receive

- Send data queue entry to Transaction Editor (DQAM 5) ENDIF

- Release Device ENDIF

©Files : (CRUD)

- AMPACK (C )

- AMSET (C-- - )

©Notes: It is currently submitted by the Start-Up ARMS Jobs (CLL810) program on the centralized ARMS host platform to be executed with a single 1- character input parameter of the distributed System (Machine) ID to start linked ICF communication session. Presently, the distributed rental system host platform are all systems excluding BIRELAND, VGERMANY, and UK.

Process

Hierarchical numeric ID: 1.1.1.1.7.3

Coded name:

Name: DTQ Input to AM10S (DQANDST)

Comment: ©Definition: DQANDST is a data queue used to provide input to PGM AM0106 which sends transactions from the distributed machine to the cetralized processing machine.

Process

Hierarchical numeric ID: 1.1.1.1.7.7

Coded name: CLL 97

Name: PGM Completed Errors Report (CLL797)

Comment: ©Purpose: This program is one of the programs along with AM0797- and

AM0099 that were intended to implement Tom Stratton's error handler system for error capture and response.

.. ©Operational Method:

- Read files ANDQER and AMERDT to gather the details for any error that was marked as completed in AM0099.

©Notes: These programs are not used at this time even though they are on production systems. Essentially this was an implementation failure due to complexity and user friendliness issues.

Process

Hierarchical numeric ID: 1.1.1.1.8

Coded name:

Name: AUT Package Transaction into Transmission (AM120)

Comment: ©Definition: The automatic process of preparing a transaction for transmission by putting it in a transmission envelope.

Process

Hierarchical numeric ID: 1.1.1.1.8.1

Confidential Page 122 of 246 8/11/00 ARMS Process Report

Coded name: AM0120 ~^"

Name: PGM Package Transaction (AM0120)

Comment: ©Purpose: To add control start and end record formats to the transaction data sets to create an enveloped transmission. These control formats are used to route the transmission and indicate the type of transaction set being sent.

©Operational Method:

- Receive the next communication acknowledgement, authorization maintenance request, rental maintenance recognition or authorization maintenance error from data queue DQAMPKG until a shutdown request is received.

- Upon receipt of shutdown requests, pass request to time line

DQAM70V1.

- For each transaction data set Build the control start record formats (Transmission, Group &

Set) and write record formats to send file (AMSEND) For each transaction data set record format Transalate the location(AUTD0l/ELCD0l/lEBH01) Write record format to send file (AMSEND) Build the control end record formats (Set, Group, &

Transmission) and write record formats to send file (AMSEND) Send a data queue to the connect-specific communications sender

©Files: (CRUD)

- AMPACK (-R--)

- ARMSPR3 (-R--)

- AMXBCO (-R--)

- AMSEND (C---)

Process

Hierarchical numeric ID: 1.1.1.1.8.6

Coded name: DQAMPKG

Name: DTQ Input for Program AM0120 (DQAMPKG)

Comment: ©Definition: DQAMPKG is a data queue used to provide input to PGM AM0120 which packages a trasactioh in preparation to sending it out to an EDI Trading

Partner.

Process

Hierarchical numeric ID: 1.1.1.1.9

Coded name:

Name: AUT Dispatch Vendor Authorization Maintenance Request

Comment: ©Definition: The automatic process of updating the ARMS database on the distributed machine and dispatching the data queue entry for the appropriate format generator program in response to some action by the Rental System.

Process

Hierarchical numeric ID: 1.1.1.1.9.1

Coded name: AM0060V1

Name: PGM Dispatch Rental Systems Request (AM0060V1)

Comment: ©Purpose:

Confidential Page 123 of 246 8/11/00 ARMS Process Report . i

To accept requests from the rental systems to maintain the distributed ARMS Rental Transaction Cross-Reference and dispatch transaction set generation requests.

©Operational Method:

- Override the printer file outq to ARMSDUMP so that the dump can be retained for as long as needed. The default outq ERRDUMPS is cleared daily.

- Receive authorization management or rental notification requests (AC, IN, RA, RC, RE, Opening RN, Closing RN, TR and VM) from the RENTAL SYSTEMS. All requests or notifications as output from the rental systems with a key of 'DIS' will be read from the input data queue (DQAM60V1) by this program.

- Based on externally described rules (AMPGMTBL, AMPGMRUL and AMPGMCTL) , dispatch the request to the appropriate request handler process (format generator program e.g., ECOORAVl) dispatching an output data queue entry that has been modified from the input data queue entry to the correct rental system transaction set generator never-ending program/job, based on the key information found in the AMTRNCTL file (ACB, ACC, RAB, RAC, RCB, RCC, REB, REC, RNB, RNC) .

- A transaction set generation request may lead to another request. After each request is sent out, a feedback entry to this program informs that the dispatched request has been completed.

- Edit to check for valid Program ID, Rule ID and dispatch execution condition. Generate an error message for an invalid dispatch execution condition. No page is generated for invalid dispatch execution condition. However, for invalid Program ID or Rule ID, ARMS On-Call pager will be sent an informational message. In all cases, transaction request is rejected.

- Receive and process environment change requests which allow the program to dynamically adapt for load balancing during heavy transmission load (Group Type = 'WT') or to shutdown the format generators and itself.

- Log the received data queue entry for audit and problem resolution.

- Retrieve the information required to process the request via appropriate retrieval module (EC2090V1 for ECARS and CC2090V1 for Claims Connection requests) . If the retrieval program detects a lock on the ticket, defer processing the request.

- A request may need to be processed in more than one pass through the program. The current step being processed is logged externally (in AMTRNCTL) . All requests related to this transaction id are deferred while a step for the transaction id is in progress. When the logged request has been completely processed, the log for that transaction is removed so that the deferred requests can now be processed.

©Files :

ARMSPRl (-R-)

AMPGMTBL (-R—)

AMPGMRUL (-R—)

AMPGMCTL (-R—)

AMTRNCTL (CR-D)

AMXBCO (-R—)

AMVRGTST (-R—) AMVRGTL2

AMQUETBL (-R—)

AMSTSX (-R-)

AM0060LG (C—)

Confidential Page. 8/11/00 ARMS Process Report

ARMSKEY (-R--) ANDSG1V1 (-R--) $#EMACH (-R--)

AMPGMCTL (-R--)

DQAM60V1 (-R--) DQAM60V1 (-R--)

©Notes :

- AC (Authorization Confirmation)

- IN (Invoice)

- RA Add (Request to Authorize a reservation or an open ticket)

- RA Change (Request to Change an Authorization for a reservation or an open ticket)

- RC (Request to Cancel an authorization)

- RE (Request to Extend a rental)

- Opening RN (Rental Notification of an OPEN ticked)

- Closing RN (Rental Notification of a CLOSED ticket)

- TR (Request to Transfer Authorization from one location to another)

Process

Hierarchical numeric ID: 1.1.1.1.9.10

Coded name: DQAM6AV1

Name: DTQ Secondary Input to AM0060 (DQAM6AV1)

Comment: ©Definition: DQAM6AV1 is a data queue used as a backup queue for PGM

AM0060V1 when it receives a request that can not be processed due to work in process as represented by a record in file AMTRNCTL. This secondary queue is periodically checked when there has been a set period of inactivity in the primary data queue for

PGM AM0060V1.

Process

Hierarchical numeric ID: 1.1.1.1.9.12

Coded name: DQAM60 1

Name: DTQ Primary Input for AM0060 (DQAM60V1)

Comment : ^; - ' ©Definition: DQAM60V1 is a data queue used to provide the primary source of input to PGM AM0060V1 which handles processing needed as a result of requests and or actions taken by the Rental System (ECARS) and routes requests for formats to be generated to the correct format generator programs.

Process

Hierarchical numeric ID: 1.1.1.1.9.13 Coded name: EC2090V1

Name: PGM Retrieve ECARS Data (EC2090V1) Comment : ©Purpose:

To retrieve specified information from the ECARS rental database.

©Operational Method:

- If the passed ARMS DS Identification code is 'Gl', attempt to retrieve the data otherwise if the code is 'GO¹ , return to calling program.

- If the reservation number is passed, get the reservation data.

Confidential Page 125 of246 8/11/00 ARMS Process Report

- If the ticket number is passed, get the ticket data.

©Files:

- RACBRMAST (-R--)

- NR025L01 (-R—)

- RACMAST (-R-)

- RACSMAST (-R--)

- QRACCLSQ (-R--)

- RACSCLD (-R—)

- RACPENDC (-R—)

- ANDSG1 1 (-R--) EDS

- DTPARM (-R--) EDS

©Notes:

A reservation created by National Reservations has the routed Machine ID as the first character of the RESERVATION ID.

This program is called by a variety of non-ECARS programs. Each program calling this program may have a different parameter list associated with the program call. Each different parameter list, defines a different type of function required by this progam.

Functions desired for this program must be closely coordinated with any NON-ECARS rental application development staff. All objects involved with any desired function must be moved into production at the same time.

This program has been designed and written to be as modular as possible. All logic for each type of transaction is contained in a single subroutine. The required files are opened at the beginning of each subroutine, the other files are not opened.

©Improvement Opportunities :

1.) Replace the execution of the ARMS Handle Internal Error ('AM0097V1') program with the execution of the newer ARMS Handle Internal/External Error ('AM0098') program.

2.) Delete the constant 'EC2090V1' and replace its usage with the Program Status Data Structure data element for PROGRAM ID.

3. ) Convert program from OPM RPG to ILE RPG.

Process

Hierarchical numeric ID: 1.1.1.1.9.14

Coded name: CC2090V1

Name: PGM Retrieve Claims Connection Data (CC2090V1)

Comment : ©Purpose:

To retrieve specified rental information from the Claims Connection database.

©Operational Method:

- Retrieve the Claims Connection reservation or ticket data from the CC database and return the information using pre-defined external data structure.

Confidential Page 126 of 246 8/11/00 ARMS Process Report

©Files:

CCMASTER (-R—)

CCCLSC (-R—)

CCRES (-R—)

ANDSG1V1 (-R—) EDS

©Note: When a ticket is opened, the reservation is deleted from the reservation master file.

©Improvement Opportunities :

1.) Replace the execution of the ARMS Handle Internal Error (^■AM0097V1¹) program with the execution of the newer ARMS Handle Internal/External Error ('AM0098') program.

2.) Delete the constant 'CC2090V1' and replace its usage with the Program Status Data Structure data element for PROGRAM ID.

3. ) Convert program from OPM RPG to ILE RPG.

Process

Hierarchical numeric ID: 1.1.1.1.9.15

Coded name: CLDQINFO

Name: PGM Retrieve Data Queue Information (CLDQINFO)

Comment: ©Purpose :

This program receives a parameter and using the Application Program interface (API) QMHQRDQ, retrieves a data queue description.

©Operational Method:

- Prepare the parameters used by the API then call the API

- Parse each attribute retrieved:

- Length (binary)

- Key length (binary)

- Sequence type (FIFO, LIFO, KEYED)

- Sender ID (Y or N)

- Force Indicators (Y or N)

- Description

- Number of messages on the queue (binary)

- Max. number of message on queue (binary - not used)

- Convert binary values to decimal

- Return to values to calling program.

Process

Hierarchical numeric ID: 1.1.1.1.18

Coded name:

Name: AUT Dispatch Customer Authorization Maintenance Request

Comment: ©Definition: The automatic process of updating the ARMS database on the distributed machine and dispatching the data queue entry for the appropriate program to then update the Rental database.

Process

Confidential Page 127 of 246 8/11/00 ARMS Process Report

Hierarchical numeric ID: 1.1.1.1.18.3

Coded name: AM0061V1

Name: PGM Edit and Dispatch Customer Request (AM0061V1)

Commen : ©Purpose:

To perform the distributed Edits and Dispatch a Customer Request transaction to the appropriate Rental System never-ending program/job or Financial System Interface daily batch transaction files.

©Operational Method:

- Execute as a never ending program on the distributed host machine.

- Receive the next data queue entry with a key value of 'DIS' from data crueue DQAM61V1 or DQAM6BV1.

- If a 'WT' (Wait Time) group type is received, change the amount of time the primary data queue must elaspe before switching to the secondary data queue to the value in group type. However if the value = 99999, set the wait time to -1, infinite.

- If a 'DF' (Deferred) group type is received, execute the program to return the number of entries in secondary data queue.

- IF a 'SD' (Shutdown Request) group type is received, 1 pass is made through the secondary data queue. Any entry not processed will remain deferred. After passing through the secondary data queue, generate shutdown request for the necessary rental interface program(s) .

- If an 'RM' (Remittance Advice) group type is received at the distributed host machine that is not the financial systems host, only update the cross-reference status.

-If a daily rental transaction (excluding RM) is received at the distributed host machine that is the financial systems host, the program dumps and invokes error logging process, AM0098.

- If the authorizing customer iε different from the original customer on an old style vendor override, generate a request for cancellation for the original customer who received the original request for authorization.

- After business rules have been validated, the request is either, rejected back to the trading partner, passed on the appropriate interface request handler process, and in certain cases the request is deferred. (A key comprised of the transmission group type and business type is created when passing the request to the interface program)

- Log the rejection of a request for authorization for an open ticket (in file AMSTSX) .

- If the ticket referenced in the vendor override request is not found, generate standardized comment stating that the vendor override failed (data area AMATTCDA, format COMD01 in ile AMAPP) .

©Files:

AMAPP (CRU-)

AMVRGTL1 (-R--)

AMQUETBL (-R-) AMSTSX (CR--)

Confidential Page 128 of 246 8/11/00 ARMS Process Report

©Notes :

- AT (Authorization Add/Change/Transfer)

- CC (Customer Confirmation)

- CN (Customer Cancellation Request)

- CM (Customer Message)

- EX (Rental Extension)

- PM (Customer Payment Advice)

- RM (Customer Remittance Advice)

The printer file for error DUMPS QPPGMDMP is overridden in this program to go to outq ARSMDOMP instead of the Enterprise default of ERRDUMPS because the outq ERRDUMPS is cleared on a daily basis and sometimes the ARMS on call staff can not get around to fix the problem under consideration for more than a day. This way the dump is retained until explicitly deleted.

************ External Data Structures ****************

ANDSGIVI

ARMSKEY

APPD01V1

CRED01V1

COMDOIVI

PMTD01V1

RMTD01V1

DQAM60V1

AMATTCDA (-R--) Data Area

$#EMACH

Process

Hierarchical numeric ID: 1.1.1.1.18.4

Coded name:

Name: DTQ Secondary (Deferred) Input to AM0061 (DQAM6BV1)

Comment: ©Definition: DQAM6BV1 is a data queue that is used as a source of deferred input to PGM AM0061V1 which routes Trading Partner transactions to the correct Rental System interface program. This data queue iε input to by ECOOATVl and

AM0061V1.

Process

Hierarchical numeric ID: 1.1.1.1.18.5

Coded name: DQAM61V1

Name: DTQ Primary Input to AM0061 and Rental System interfaces (DQAM61V1)

Comment: ©Definition: DQAM61V1 is a data queue used to provide input to PGM-

AM0061V1 and Rental System Interface programs which process inbound transaction requests from the EDI Trading Partner.

Process

Hierarchical numeric ID: 1.1.1.1.18.8

Coded name: AM0049V1

Name: PGM Update Financial Services Files with Remittance Detail (AM0049V1)

Comment : ©Purpose:

To write or update records to batch transaction header and detail holding files that are used to update the FINANCIAL SYSTEMS' Cash Receipts application database files with the detailed information of EFT remittance advice detail transaction data sets that were sent and processed through the ARMS system. This

^~~- Confidential Page 129of246 8/11/00 ARMS Process Report information will be used by Financial Systems to process Electronic Funds Transfer and to distribute and apply the incoming funds. There will be one header record for each EFT batch received.

©Operational Method:

Using the passed input parameter field values for COMPANY PROFILE ID for Ins. ID, EFT IDENTIFICATION, and a SEQUENCE NBR. starting at l through 9 as a key, attempt to access for update an existing associated Cash Receipts EFT Remittance Advice Header File (CREFTH) record.

IF no record is found, write a new record, using this key value. Load the passed input parameter PAYMENT AMOUNT field value to the output BATCH TOTAL field and load GROUP ID with "76" and BRANCH ID with "99" and load the RECORD ADDED audit fields appropriately.

IF a record is found, check its STATUS, being one of the following values : blank = Unprocessed

I = In use by another user

P = Pending

S = Submitted to batch

O = Processed or Posted

D = Deleted

IF this batch record's STATUS is submitted ("S") , posted ("O") , or, deleted ("D"), then the record is unavailable to ARMS interface. Increment the key's SEQUENCE NBR. by 1 and reattempt update access. However, IF there were 9 records found that all were unavailable, then DUMP and notify ARMS On-Call of the exception error by calling 'AMPSSR' with the passed input parameter field being a concatenation of the passed input parameter fields' values to this program.

ELSE, update this record's accumulated BATCH TOTAL with the passed input parameter field, PAYMENT AMOUNT.

IF no exception error has occurred, then attempt to access for update an existing associated Cash Receipts EFT Remittance Advice Detail File (CREFTD) record, using the same key values last used for the Header File.

• - ^'■ IF no record is found, write a new record, using this key value and a LINE NBR value of 1. Load the passed input parameter field, PAYMENT AMOUNT value to the output PAYMENT TOTAL field and load the passed GROUP ID, BRANCH ID and TICKET ID prefixed with "D" and load the RECORD ADDED audit fields appropriately.

IF a record is retrieved, compare the retrieved record's GROUP ID, BRANCH ID, and TICKET ID to the passed GROUP ID, BRANCH ID and TICKET ID prefixed with "D" .

IF they match, then add the passed input parameter PAΪMENT AMOUNT field value to the current PAYMENT AMOUNT field and update the RECORD,CHANGED audit fields appropriately.

IF no records are found whose GROUP ID, BRANCH ID and TICKET ID match, then write a record to this file using the same key fields' values and set the LINE NBR. to l or 1 more than was last retrieved. Load the passed passed GROUP ID, BRANCH ID and TICKET ID prefixed with "D", ENTERPRISE INTERNAL CUSTOMER ID, PAYMENT AMOUNT to their associated fields and load the RECORD ADDED audit fields appropriately.

©Files: (CRUD)

Confidential Page 130 of 246 8/11/00 ARMS Process Report

CREFΪΉ (CRU-) Cash Receipts EFT Payment Remittance Advice Header File, ^bY i by Ins. ID, EFT ID#, and Sequence Nbr.

CREFTD (CRU-) Cash Receipts EFT Payment Remittance Advice Detail File, by Ins. ID, EFT ID#, Sequence Nbr., and Line Number.

©Notes:

This program is called by the ARMS Distributed Edits and Dispatch (AM0061V1) program with the following input parameter fields:

5 Alphameric Company Profile ID

20 Alphameric EFT Identification

2 Alphameric Group ID

2 Alphameric Branch ID

6 Alphameric Rental Contract/TICKET ID

7 Alphameric Enterprise Internal Customer ID

15/5 Numeric Payment Amount

For any program exception error, the *PSSR - ERROR HANDLING SUBROUTINE will be executed that will output a spooled RPG formatted DUMP and CALL 'AMPSSR' with the passed input parameter field being a concatenation of the passed input parameter fields' values to this program to notify the ARMS On-Call staff.

The ARMS system will now enable electronic invoices, payments and remittances (processed here) to be sent/received for non-ARMS Rental Management Trading Partners that are Direct Billing/Remittance Trading Partners, such as Tennessee Valley Authority (an Enterprise Fleet Services customer) . Therefore, ARMS will receive a data queue entry to generate an electronic invoice (and create an associated ARMS Rental Transaction Cross-Reference (AMXREF) file record) when the trading partner never sent to ERAC (via ARMS) any initial rental authorization.

©Embedded Data/Constants:

'AM0049V1' is used as a literal constant to pass as an input parameter field value to the calls of 'AMPSSR' program and the output of the PROGRAM ID audit field in the CREFTD and CREFTH files' records.

'7699' (Host) s always used to load the GROUP and BRANCH ID fields of the Cash- eceipts EFT Payment Remittance Advice Header File

©Improvement Opportunities:

Replace the literal constant 'AM0049V1' with the Program Status Data Structure's data element for PROGRAM ID in the RECORD ADDED and RECORD CHANGED audit fields . .

Process

Hierarchical numeric ID: 1.1.1.1.19

Coded name:

Name: AUT Send Transmission to Trading Partner Company

Comment: ©Definition: The automatic process of translating (if necessary) and sending a transmission to the Trading Partner through one of several EDI mediums.

Process

Hierarchical numeric ID: 1.1.1.1.19.2 Coded name: EDZSCWA

Confidential Page 131 of 246 ^~ 8/11/00 ARMS Process Report - I

Name: PGM Check for Wrapped Transactions to Send (EDZSCWA) ~~ ^{~~ "}

Comment : ©Purpose:

To check for Outbound wrapped EDI transactions for Any EDI integration software sender processing. These transactions have been wrapped by program EDLSIMA in collaboration with program AMZSIMA.

©Operational Method:

This program receives a data queue entry keyed by the trading partner communications port id and if it is not a shutdown entry, it will read the Any EDI integration software Connection Log file to determine if there are any outbound wrapped messages ready to be sent for this trading partner.

Based on the above information the return parameters are set.

©Files:

EXLLCPP (in library EXTSYSF) (-R--)

Process

Hierarchical numeric ID: 1.1.1.1.19.7

Coded name: AMSCPIC

Name: PGM Send Proprietary Transmission to an ARMS-connected VAN (AMSCPIC)

Comment: ©Purpose:

To request a program start communication conversation from an ARMS trading partner, then continuously sends proprietrary EDI data set transmissions to the trading partner. These transmissions are triggered by the receipt of their key value via an input data queue entry until a data queue entry of *D0WN is received from the input data queue.

©Operational Method:

For any error exception condition that occurs (including CPI-C errors) , output a¹ spooled RPG formatted dump and CALL 'AMPSSR to notify .ARMS On-Call staff of the condition and end the program.

At program startup: . . ._

- Derive ARMS to an ARMS-connected VAN Transmissions to be sent input data queue name by concatenating 'DQ' with input parameter COMPANY PROFILE ID value (example 'DQVN101'). ...

- Call QCMDEXC to execute the ADDLIBLE QSYS2 command to access the OS/400 System CPI-C objects.

After startup has completed, repetitively perform the following steps:

- Receive the next data queue entry from the derived input data queue into the ARMSKEY external data structure, waiting infinitely for an entry.

- IF after any of the subsequent program executions, the returned PROGRAM RETURN CODE is not equal to 0 (zero) , then execute the program exception error routine.

- Initialize a CPI-C communication conversation by executing 'CMINIT' program with the following parameters:

Confidential Page 132 of 246 8/11/00 ARMS Process Report

8 Character (Output) CONVERSATION ID 5 Character (Input) CONVERSATION SYMBOLIC DESTINATION ID (CSI) , loaded with the input parameter COMPANY PROFILE ID.

9/0 Binary (Output) PROGRAM RETURN CODE

- Allocate a CPI-C communication conversation by executing '^■CMALLC program with the following parameters:

8 Character (Input) CONVERSATION ID 9/0 Binary (Output) PROGRAM RETURN CODE

- Set a CPI-C communication session/conversation send type by executing 'CMSST' program with the following parameters:

8 Character (Input) CONVERSATION ID

9/0 Binary (Input) CONVERSATION SEND SET TYPE, loaded with the value 1.

9/0 Binary (Output) PROGRAM RETURN CODE

- IF the received data queue entry's COMPANY ID = '*DOWN', or the GROUP TYPE CODE = 'SD', or the CUSTOMER TRANSACTION ID = '*STOP', then execute the following two programs, then end this program.

- - The first is to set the CPI-C Deal Type by executing 'CMSDT' program with the following parameters:

8 Character (Input) CONVERSATION ID

9/0 Binary (Input) CONVERSATION DEAL SET TYPE, loaded with the value 1.

9/0 Binary (Output) PROGRAM RETURN CODE

- - The second is to DeAllocate a CPI-C communication conversation by executing 'CMDEAL' program with the following parameters:

8 Character (Input) CONVERSATION ID 9/0 Binary (Output) PROGRAM RETURN CODE

Jr

- IF a non-shutdown data queue entry is received, then use its value to repetitively read each corresponding record in the ARMS Transmissions to be Sent (AMSEND) file. Load each retrieved record's ARMS format to a temporary DATA TO BE SENT array of 128 character elements and 68 elements, increment the RECORD COUNTER by 1 and the SENT DATA LENGTH by 128.

- - IF the RECORD COUNTER is greater than 69 (68 x 128 = 8704 characters, full communication buffer) , or at least 1 record was read from the ARMS Transmissions to be Sent (AMSEND) file, then execute the 'CMSEND' program with the following parameters :

8 Character (Input) CONVERSATION ID 8704 Character (Input) DATA TO BE SENT ARRAY 9/0 Binary (Input) SENT DATA LENGTH (loaded with the current increments of 128 bytes per record) .

9/0 Binary (Output) REQUESTOR ID, loaded with 0 (zero) . 9/0 Binary (Output) PROGRAM RETURN CODE

- - Read from the loaded DATA TO BE SENT ARRAY, starting at the first element for every element loaded, write a record to the ARMS Transmissions Sent (AMSNDLOG) file and then send a data queue entry for these written records to the

ARMS Time Line Input Data Queue (DQAM70V1) .

- - Reset the SENT DATA LENGTH and the RECORD COUNTER to 0 (zero) and clear the DATA TO BE SENT ARRAY.

Confidential Page 133 of 246 8/11/00 ARMS Process Report

©Files: (CRUD)

AMSEND (-R--) AMSNDLOG (C )

©Embedded Data/Constants:

'ADDLIBLE LIB(QSYS2) ' for use in the execution of the program QCMDEXC to execute this command so that the IBM System Library for CPI-C programs' objects would be available for use.

■*LIBL' used as the input parameter for the LIBRARY NAME for the execution of the Receive Data Queue and Send Data Queue programs.

Process

Hierarchical numeric ID: 1.1.1.1.19.8 Coded name: EDMSLUA

Name: PGM Send X12 Transmission (EDMSLUA) Comment: ©Purpos :

To send any wrapped EDI X12 transactions that are ready to be sent.

©Operational Method:

- This program runs in an infinite loop from the time it is submitted until a shutdown flag is returned by the called program EDZSCWA. The program is submitted by the ETD: EC/EDI: ARMS Trading Partner Insurance Company Comm. /Mapping Submitter (AM***COMP) program to run in the ARMS subsystem on the centralized ARMS- host computer platform and is passed the following input parameters:

5 character COMPANY PROFILE ID with transactions to be sent (such as ι***01' )

15 Character NETWORK ID, as defined in Any EDI integration software, for this ARMS Company Profile ID to be used for this network communication session, (such as 'ProfileName')

6 Character PORT ID, as defined in any EDI integration software, to be used for this network communication session (such as 'xxxxx') .

*-^'' 10 Character SCRIPT ID, as defined in any EDI integration software, as the communication script to be used for this company in the ARMS connected network, (such as 'xxxxxS')

1 Character VERSION FLAG, Either '0' = Test or ^«1' = Production.

- Repetitively execute the ARMS ANY EDI INTEGRATION SOFTWARE Generic Send Transaction Notify Program (EDZSCWA) with the following parameters, until the *DOWN FLAG indicates a shutdown has been received:

5 Character (input) passed input parameter, COMPANY PROFILE ID with transactions to be sent (such as 'xxxxx')

6 Character (input) passed input parameter, PORT ID, as defined in any EDI integration software, to be used for this network communication session, (such as i ***oi' )

1 Character (output) *DOWN FLAG shutdown data queue entry received. (Values are Υ' = Yes or 'N' = No)

1 Character (output) TRANSACTIONS PROCESSED TO BE SENT FLAG, (Either 'Y' = Yes or 'N' = No)

1 Character (input) passed input parameter, VERSION FLAG (Either '0' = Test or ' 1 • = Production)

Confidential Page 134 of246 8/11/00 ARMS Process Report

IF the returned TRANSACTIONS PROCESSED TO BE SENT FLAG is Yes, then Send transactions to trading partner based on Company ID, Network, Port, and Communication's Script by execution of the any EDI integration software's command for API: Send connections ready to send - batch.

- Upon return of control from EDZSCWA, if the shutdown flag has been set, end the program.

- IF there is an error is due to communications error line ARMS-CONNECTED VALUE-ADDED NETWORK - (UEX0567) , or,

IF there is an error is due to communication's failure, (UEX0573) ,

IF there is an error is due to no connections ready to send which match the selection parameters, (UEX0517) , or,

IF there is an error while processing a connection, (UEX0519) , or, IF there is any other error escape message, then execute the error routine.

The error routine consists of: Output a spooled CL program dump; Notify ETD and ARMS On-Call personnel, end the program.

©Notes:

Program EDZSCWA waits on the data queue that indicates the presence of wrapped transactions and returns the indicator for the presence of these transactions to this program.

Process

Hierarchical numeric ID: 1.1.1.1.19.12

Coded name: EDLSIMA

Name: PGM Map Proprietary to X12 Transmission (EDLSIMA)

Comment: ©Purpose:

To drive the translation of the ARMS proprietary transaction set into the ANSI X12 EDI transmission set.

©Operational Method:

IF translation errors are encountered or any unspecified escape error messages are generated, Dump the CL program, Call both the ETD PSSR and the ARMS PSSR programs, passing the current job's JOBNAME, 'EDLSIMAl', and a single blank character to notify ETD and ARMS On-Call staff. Then End the program.

Retrieve the EC/EDI Send Mapper Debug Flag 1 character data area to check the DEBUG FLAG value.

IF the passed input parameter field VERSION is *T', .then perform overrides to the "test" interface files for 272 set to the ELEDITST E's EDI Test Data Library for the following 272 transaction set files and their associated test interface save files: S272DTL1, S272DTP1, S272HDR1, S272ER1, S272K21, S272NAM1, and S272PER1. Additionally for the following 824 transaction set files: S824HDR1, S824ER1, S8240TI1, S824N1, S824NTE1, S824ME1, and S824PER1. Also, IF not on the "DEV" (development) platform, then override the following DDM (distributed data management) remote file on the "DEV" platform in the ELEDITST EDI Test Data Library for the ARMS Cross-Reference File (DAMXREFLl) and the ARMS Authorization Detail File (DAMAUTD) .

Allocate the following output sender segment detail interface work files for exclusive use:

Confidential Page 135 of246 8/11/00 ARMS Process Report

S272DTL1

S272DTP1

S272ER1

S272HDR1

S272K21

S272NAM1

S272PER1

S824HDR1

S824ΞR1

S8240TI1

S824N1

S824NTE1

S824ME1

S824PER1

Derive the Trading Partner (COMPANY ID) Send Communications Version 1 output data queue name. IF the passed VERSION is '1' (production), then build the data queue name by the concatenation of the first three (3) characters of the passed input parameter field COMPANY ID, the constant "SE" (to SEnd) , and the passed input parameter field VERSION.

ELSE (is test) , then build the data queue name by the concatenation of the characters from position 2 through 4 of the passed input parameter field COMPANY ID, the constant "SE" (to SEnd) , and the passed input parameter field VERSION.

Perform the following until SHUTDOWN FLAG or an exception error occurs :

- Call the ARMS X12 Send Interface Version 2 program (AMZSIMA) with the following parameters:

1 Character (Output) Shutdown Flag (possible values: 'N'=No or ^■Y'=Yes)

3/0 Decimal (Output) Number of 272 Transaction Sets

3/0 Decimal (Output) Number of 824 Transaction Sets

5 Character (Input) Company ID, passed input parameter field value to this program

- IF transactions were written to the interface files (NUMBER OF 272/824 TRANSACTION SETS > 0) , then execute the EDI integration software Create Application Data Batch (batch) command for the Property and Casualty Loss Notification Outbound Version 1 application ID for the production or test data processed, depending on the value of the input parameter VERSION. Then send a '*DATA' (meaning "data is available to be sent") 5-character data queue entry to the derived output Trading Partner (COMPANY ID) Send Communications Version 1 data queue.

- IF the retrieved data area's DEBUG FLAG is 'Y' (program is running in debug mode) , the copy/add the transaction set segment detail interface work files to their associated save archive files.

- Clear these transaction set segment detail interface work files.

- IF the called ARMS X12 Send Interface Version 2 program (AMZSIMA) returned with SHUTDOWN FLAG parameter = 'Y' , then send three (3) '*DOWN' 5-character data queue entries to the derived output Trading Partner (COMPANY ID) Send Communications Version 1 data queue and end this program.

- ELSE, repeat the above steps.

©Files: (CRUD)

Confidential Page 136 of 246 8/11/00 ,, ' ARMS Process Report

EDEXTDBUG (-R--) 1 character data area ETD: EC/EDI Send Mapper Debug Flag (possible -values: "N"=No or "Y"=Yes)

, ©Notes :

This program is maintained by the Emerging Technologies Department (ETD) .

This program is submitted as a never-ending program batch job with the job name 'LxxxxxlSM* (where "xxxxx" is the Trading Partner Company Profile ID) and specifies using the any EDI integration software JOBDP job description on the centralized ARMS application host computer system with the following input parameters :

1 Alphameric VERSION (possible values: "1"-production or "T" -testing) 5 Alphameric COMPANY ID

Process

Hierarchical numeric ID: 1.1.1.1.19.30

Coded name: AMZSIMA

Name: PGM Create Send Interface Work Files for Any Transactions to be Sent (AMZSIMA)

Comment : ©Purpose:

To receive any outbound transmission to be sent and format it into the appropriate send transaction interface work files for mapping by the EDI integration software (any third-party software package) .

©Operational Method:

- Set the delay time for gathering transactions from data area AMEXTSM. To improve performance, the EDI integration software is not invoked for each transaction. The delay time is the duration for which the program will wait to see if any more transactions are available to be sent before returning to the calling program.

- Receive data to be sent to insurance company in ARMS proprietary format and convert the format to send interface file format for X12 transaction sets 272 {property and casualty loss notification and work assignments (rentals) } and 824 {application advice designed to accommodate the business need for reporting the acceptance, rejection, or acceptance with change of any transaction set}.

- Use file EDPREF3 to determine which insurance company expects which X12 transaction set for a particular ARMS proprietary group type.

©Files: CRUD)

- AMSEND (-R—)

- AMTRNLOG (-R-)

- S272HDR1 (CRU-)

- S272NAM1 (CRU-)

- S272DTL1 (CRU-)

- S272DTP1 (CRU-)

- S272ER1 (CRU-)

- S272K21 (CRU-)

- S272PER1 (CRU-)

- AMSNDLOG (-R—)

- EDPREF3 (-R-)

- S824HDR1 (CRU-)

- S824ER1 (CRU-)

- S824N1 (CRU-)

Confidential Page 137 of 246 8/11/00 ARMS Process Report

S8240TI1 (CRU-) ^"

S824PER1 (CRU-)

S824NTE1 (CRU-)

S824ME1 (CRU-)

AMAUTD (-R--)

AMXREFL1 (-R--)

AMEXTSM (-R--) Data Area

©Notes : State

Currently, this used for the ANSI X12 '272' Rental Management Transaction Set used for Trading Partner Company and for the ANSI X12 '824' Consolidated Payment Transaction Set used for a different Trading Partner Company.

Currently only one ARMS Trading Partner Company will be sending 824 transactions but CIECA standards will be used in the future by other insurance companies to process status type transactions such as: 'AC , 'RN' , 'ER' .

Process

Hierarchical numeric ID: 1.1.1.1.20

Coded name:

Name: AUT Generate Authorization Maintenance in Behalf of R.M.T.P.

Comment: ©Definition: This automated process allows for an Enterprise In-House person to perform Authorization Management Maintenance on behalf of a Rental

Management Trading Partner. Currently this is restricted to the processing of

Authorization Changes and Cancellations. Only one ARMS Trading Partner Company is using this currently.

Process

Hierarchical numeric ID: 1.1.1.1.20.1

Coded name: AACHNG

Name: PGM AADRVR Program to PASSTHRU to RARMS (AACHNG)

Comment: ©Definition: This program is used to pass through to the Centralized ARMS machine. It is used by In-house Enterprise Rental management personnel to access an interactive screen for use' in processing AT-C, and or CN's on behalf of an ARMS

Trading Partner Company.

©Operational Method: All this program does is start pass-through and starts the AACHNGA program. End program.

Process '

Hierarchical numeric ID: 1.1.1.1.20.2

Coded name: AACHNGA

Name: PGM Program to start AACHGR (AACHNGA)

Comment: ©Definition: This program is used to facilitate In-house Enterprise

Rental management personnel access to an interactive screen for use in processing AT-

C, and or CN's on behalf of a ARMS Trading Partner Company.

©Operational Method: This program is started by AACHNG on the Centralized ARMS machine. This program will call program AACHGR and then when control is returned it will end Pass-Through returning the user to the distributed machine.

Process

Confidential Page 138 of 246 8/11/00 ARMS Process Report

Hierarchical numeric ID: 1.1.1.1.20.3 '

Coded name: AACHGR

Name: PGM ARMS Trading Partner Company Authorization Change (AACHGR)

Comment: ©Definition: This program is used to allow In-house Enterprise Rental management personnel to access an interactive screen for use in processing AT-Changes

, and/or Cancellations on behalf of a ARMS Trading Partner Company.

©Operational Method: The System Name is retrieved and the users authority to the program is validated. If the user is not authorized, *INLR is turned *ON and the program exits.

If the user is authorized, all screen values and indicators are reset and Screen 1 is displayed. F3-Exit will exit the program. F5-Next will reset all screen values and indicators and redisplay the screen. FlO-Process will begin processing, if all edits pass, an authorization change or cancellation. Fll-Cancel will display Screen 2, if all edits pass.

After the user enters a valid combination of Group, Branch, Reservation, and Ticket, the ARMS cross-reference record is retrieved and the current status is used to determine possible transaction types. Authorization change requests are only allowed when the cross-reference status is 'R*, *0', or 'I*. Cancellation requests are only allowed when the cross-reference status is either 'R* or 'I*.

If an authorization change request is being processed, the new values are compared with the old values to ensure a change is made and edited for validity. If edits pass, necessary formats (APPDOl, ADJDOl, AUTD01, SURDOl, COMDOl) are loaded for an AT-C. Records are written to AMSET. A transaction log entry is written to AM004P. Data queue entries are sent to DQAM25V1 and DQAM70V1. Screen 1 is then redisplayed.

If a cancellation request is being processed, necessary formats (APPDOl, ADJDOl, CANDOl, COMDOl) are loaded. Records are written to AMSET. A transaction log entry is written to AM004P. Data queue entries are sent to DQAM25V1 and DQAM70V1. Screen 1 is then redisplayed.

©Notes: This is a temporary program for use until the ARMS Trading Partner Coinpany completes development of their system.

©Files: (CI 1U

- AMXREFL1 (-R-- -)

- AMXREFL2 (-R-- -)

- AMRNTD (-R--)

- AMADJD (-R—)

- AMAUTD (-R—)

- AMSURD (-R-)

AMXBCO (-R—) CUSTMAST (-R--)

AMSET (C )

AM004P01 (C )

Process

Hierarchical numeric ID: 1.1.1.2

Coded name:

Name: BT Manage Customer Remittance

Confidential Page 139 of 246 8/11/00 ARMS Process Report

Comment^": ©Definition: The set of automated activities that are used in management of remittances, this is the result of an inbound transmission received from the trading partner who is engaged in electronic invoicing with us.

©Purpose: To allow EDI Trading Partners to receive and manage billing invoices electronically.

Process

Hierarchical numeric ID: 1.1.1.3

Coded name:

Name: BT Manage Customer Message

Comment: ©Definition: The set of automated activities that are used in management of customer messages, this is the result of an inbound transmission received from the trading partner who is engaged in electronic messaging with us.

©Purpose: To allow the Rental Management Trading Partner to send messages to the Rental location electronically without the need of using the telephone.

Process

Hierarchical numeric ID: 1.1.2

Coded name:

Name: AA Rental Systems Business Transactions

Comment: ©Definition: This application area represents all EDI transmissions that are sent from any of the Enterprise Rent-A-Car current internal rental application systems to the Rental Management Trading Partner system for: authorization requests, notification, cancellations, and extension; Vendor messages; Vendor Invoices

Process

Hierarchical numeric ID: 1.1.2.1

Coded name:

Name: BT Request for Authorization Management by Vendor

Comment: ©Definition: The set of automated activities that are used in the request for authorization and extehsion of a rental that is seen as an outbound transmission directed toward the trading partner.

©Purpose: To provide the rental offices an automated /electronic way to request authorizations and extensions for rentals from Rental Management Trading Partners without having to use the telephone.

Process

Hierarchical numeric ID: 1.1.2.2

Coded name:

Name: BT Generate & Send Rental Maintenance Notification

Comment: ©Definition: The set of automated activities that are used in the creation of and transmission of rental notification seen as an outbound transmission directed toward the trading partner.

©Purpose: To notify the trading partner of the open or close of an authorized rental.

Process

Confidential Page 140 of 246 8/11/00 ARMS Process Report

Hierarchical numeric ID: 1.1.2.3 »

Coded name:

Name: BT Manage Vendor Messages

Comment: ©Definition: The set of automated activities that are used in management of vendor messages, this is the result of an action on the part of a rental agent and results in a transmission sent to a trading partner that engages in electronic messaging with us.

©Purpose: To allow the rental office to send electronic messages to the rental trading partner without the need to pick up the telephone.

Process

Hierarchical numeric ID: 1.1.2.4

Coded name:

Name: BT Generate & Send Electronic Billing Invoice and Batch Extensions

Comment: ©Definition: The set of automated activities that are used in the creation and transmission of electronic invoices to the trading partner.

©Purpose: To allow for paperless billing of rentals to customers that are set up for EDI billing.

Process

Hierarchical numeric ID: 1.1.2.4.1

Coded name:

Name: BAT Package and Send Transaction / Generate Vendor Extension Request

Comment: ©Definition: Package information held on the Centralized ARMS System into a batch package and send the information to the rental management trading partner or the direct bill trading partner. Or on the distributed rental systems generate requests for authorization extensions (RE's) based upon specific conditions of rentals as determined from the Rental Database

©Purpose: To prepare and send outbound transactions to the EDI Trading Partners. And to insure that rental extensions are requested in a timely fashion.

©Notes: The information held could be invoices, office location updates, service area updates and/or location rate updates.

Process

Hierarchical numeric ID: 1.1.2.4.1.1

Coded name:

Name: BAT Package and Send Transactions to specified ARMS Trading Partner Companies

Comment: ©Definition: Package information held on the Centralized ARMS system into a batch package and send the information to specified ARMS Trading Partner Companies other than ANSI X12.

©Purpose: To prepare and send outbound transactions to the specified ARMS Trading Partner Companies other than ANSI X12 EDI Trading Partners.

©Notes: The information held could be invoices, office location updates, service area updates and/or location rate updates.

Process

Confidential Page 141 of 246 8/11/00 ARMS Process Report

Hierarchical numeric ID: 1.1.2.4.1.1.5

Coded name:

Name: DTQ Connect-Specific Communications Sender Input (DQxxxxx)

Comment: ©Definition: DQxxxxx Connect Specific Communications Sender data queues are used to provide input to the programs that send transmissions to our EDI Trading

Partners.

Process

Hierarchical numeric ID: 1.1.2.4.1.1.15 Coded name: AM0150

Name: PGM Package Batch Transaction (AM0150) Comment: ©Purpose:

To package control start records before and control end records after each Vendor Invoice (IN) and each Vendor Extension Request (RE) data set, to form a complete transmission set. Control start and end records are used to route the transmission and indicates the type of transaction set being sent to the Trading

Partner.

©Operational Method:

- For each transaction data set Build the control start record format (Transmission, Group, &

Set) and write record formats to send file (AMSEND) For each transaction data set record format Translate the location (AUTDOl/ELCDOl/lEBHOl IF record format NE to Insured Detail (INSDOl)

Write record format to send file (AMSEND) IF transaction data set EQUALS Vendor Invoice (IN)

Write record format to ARMS Billing Log Build the control end record format (Set, Group, &

Transmission) and write record formats to send file (AMSEND) Sends a data queue to the connect-specific communications sender

©Notes :

- Control start/end records must match: Transmission start

Group Start

Set Start

Set End

Group End

Transmission End

©Files (CRUI

L811C (-R—

ARMSPR3 (-R—)

AMSEND (C—)

AMBILLOG (C—)

Process

Confidential Page 142 of 246 8/11/00 ARMS Process Report

Hierarchical numeric ID: 1.1.2.4.1.2

Coded name:

Name: BAT Package and Send Transactions for X12

Comment: ©Definition: Package information held on the Centralized ARMS System into a batch package and send the information to theX.12 trading partner.

©Purpose: To prepare and send outbound transactions to the X-12 EDI Trading Patners.

Process

Hierarchical numeric ID: 1.1.2.4.1.2.1 Coded name: UT 999M

Name: PGM Generic ILE Error Handler (ErrHandler) Comment : ©Purpose:

To handle exceptions for application programs, by determining the proper response reacting in a predetermined way. These responses include sending a MSOl message and sending pages to the appropriate personnel.

©Operational Method:

Applies To: (ILE) Toolbox Error Handling

This generic application program error handler may be executed by an OPM (Original Program Model) program by executing an intermediate ILE RPG wrapper program, "UT_999M" - ISS:IS Global Error Handling Module (OPM Callable). This program was created with the bound service program "ISLIB/UTJH05S" - ISS: Universal Toolbox (*CALLER) that was created with the bound module "ISLIB/UT_H05S012" that perform the necessary service functions. This program is executed with the following parameters :

Parameter Type-Usage Size Description programID Char - Input 10 Program issuing the error errorlD Char - Input 7 Error ID found in- the UT991P file for the associated Program ID msgDta Char- Input 75 Substitution data for message description

Return Code Char - output 1 Returns 1 for failure, 0 for success

Before using this function/procedure, three files must be updated. ith the necessary information. These files are UT991P, UT992P, and UT993P.

The existing entries must be used as examples to follow. Syntax: re = ErrHandler ( <programID> :<errorID> [:<msgDta>] [ : <errorNoAction>] ) Elements :

Argument Type Size Description re (Return Code) Char 1 Returns 1 for failure, 0 for success programID Char 10 Program issuing the error

Confidential Page 143 of246 ^: 8/11/00 ARMS Process Report errorlD Char 7 Error ID found m the

UT991P file for the associated Program ID msgDta Char 32767 Substitution data for message description errorNoAction Char 1 Parameter for future update. currently has no function

©Notes :

This ILE RPG wrapper program is currently executed only by the AMZ811A program.

The following necessary records were placed into the UT991P ISS: IS Error Message ID File in order to execute the error handling functions properly:

Program Message Message Issuing Error File Description Error ID Name ID

AMZ811A NORECFD AMMSGF AMM0003 AMZ811A SEQERR AMMSGF AMMOOOl AMZ811A INVCMP AMMSGF AMM0002 AMZ811A *PSSR AMMS' AMMO004

The following necessary records were placed into the UT992P ISS: IS Error Message Response File in order to execute the error handling response functions properly:

Program Error

Issuing Error Sequence Response

Error ID ID Code

AMZ811A *PSSR 1 ARMSPAGE

AMZ811A *PSSR 2 ARMSMSOl

AMZ811A INVCMP 1 ARMSPAGE

AMZ811A INVCMP 2 ARMSMSOl

AMZ811A NORECFD 1 ARMSPAGE

AMZ811A NORECFD 2 ARMSMSOl

AMZ811A SEQERR 1 ARMSPAGE

AMZ811A SEQERR 2 ARMSMSOl

The following necessary records were placed into the UT993P ISS:IS Response/Program File in order to specify the execution of the error handling response mode functions:

Response

Response Exit Code Program

ARMSPAGE UT_999M005 ARMSMSOl UT 999M006

Process

Hierarchical numeric ID: 1.1.2.4.1.2.19

Coded name: AMZ832A

Name: PGM Send Interface X12 Transaction Set 832 (AMZ832A)

Comment: ©Purpose:

Confidential Page 144 of 246 8/11/00 ARMS Process Report -

To convert Enterprise proprietary EDI formats held on the Centralized ARMS System into X.12 standard formats (transaction Bet 832) which will then be sent to the X.12 trading partner

©Operational Method:

- IF transaction have been written to application database (AMSNDLOG) , clear application work files .

- Attempt to receive the next DQ832S data queue entry with a key of Company Id.

- IF a data queue entry was not received, close program files (if applicable) and end program

- IF a data queue entry was received THEN

- IF no records were retrieved from the application database send file(AMSEND) , using the received data queue entry - page the on-call staff and get next data queue entry.

- IF records were retrieved from the application database send file

(AMSEND) , using the received data queue entry THEN

- IF the transaction is in the correct sequence, notify the on- call staff

- Use the Rental Management Trading Partner electronic commerce profile to determine if they receive X12 standard format - 832 for this specific application group type. IF not exit the program.

- For each invoice, attempt to load the EDI integration software work files:

- Retrieve records from application database

- IF the invoice charge code or unit of measure is not found, skip this invoice and notify ARMS on-call.

- Load the 832 extol work file and writing them to the send log file (AMSNDLOG) .

- Update 832 header work file.

- Send a data queue entry to timeline (DQAM70)

©Files : (CRUD)

AMSEND (-R-)

AMSNDLOG (CR-D)

AM811P01 (-R—)

S832HDR1 (CR-D)

S832LIN (CR-D)

S832PER (CR-D)

S832CTP (CR-D)

S832N1 (CR-D)

EDPREF3 <-R—)

AM832ERR (C—)

Process

Hierarchical numeric ID 1.1.2.4.1.2.20

Coded name:

Name: DTQ Input for X12 Transaction Set 832 (DQ832S)

Comment: ©Definition: DQ832S is a data queue used to provide input for X.12 transaction set 832 to PGM AMZ832A.

Process

Confidential Page 145 of 246 8/11/00 ARMS Process Report

Hierarchical numeric ID: 1.1.2.4.1.2.23

Coded name: AMZ811A

Name: PGM Send Interface X12 Transaction Set 811 (AMZ811A)

Comment: ©Purpose:

To convert Enterprise proprietary EDI formats held on the centralized ARMS application system host platform into X12 standard format (transaction set 811) which will then be sent to the X12 trading partner. .

©Operational Method:

- IF the transaction set has been written to the application database for Sent Transaction Log (AMSNDLOG) file, then clear the application work files.

- Attempt to receive the next DQ811S data queue entry with a key of Trading Partner Company ID.

- IF a data queue entry was not received, close program files (if applicable) and end program

- IF a data queue entry was received THEN

- IF no records were retrieved from the application database send file (AMSEND) , using the received data queue entry - page the on-call staff and get next data queue entry.

- IF records were retrieved from the application database send (AMSEND) file, using the received data queue entry, THEN:

- IF the transaction is in the correct sequence, notify the on- call staff

- Use the Rental Management Trading Partner electronic commerce profile to determine if they receive X12 standard format - 811 for this specific application group type. IF not, then exit the program.

- For each invoice, attempt to load the Extol work files: -- Retrieve records from application database

-- IF the invoice charge code or unit of measure is not found, skip this invoice and notify ARMS on-call. -- Load the 811 Extol work file and writing them to the send log

(AMSNDLOG) file.

-- Update 811 header work file.

-- Send a data queue entry to timeline (DQAM70)

©Notes:

- This program run with in CLL811 between 3:00am and 5:00am Central time zone.

- This program only processes invoice transmission sets.

The ARMS system will now enable electronic invoices, payments and remittances (processed here) to be sent/received for non-ARMS Rental Management Trading Partners that are Direct Billing/Remittance Trading Partners, such as Tennessee Valley Authority (an Enterprise Fleet Services customer) .

©Files: (CRUD)

AMSEND (-R—)

AMSNDLOG (CR-D)

AM801P01 (-R--)

AM802P01 (-R—)

AM811P01 (-R--)

Confidential Page 146 of 246 8/11/00 ARMS Process Report

ARMSPRl (-R-)

AMAUTD (-R-)

S811HDR1 (CR-D)

S811NAM1 (CR-D)

S811DTL1 (CR-D)

S811IT1 (CR-D)

S811VEH1 (CR-D)

EDPREF3 (-R—)

AM811ERR (C—)

Process

Hierarchical numeric ID: 1.1.2.4.1.2.24

Coded name:

Name: DTQ Input for X12 Transaction Set 811 (DQ811S)

Comment: ©Definition: DQ811S is a data queue used to provide input for X.12 transaction set 811 to PGM AMZ811A.

Process

Hierarchical numeric ID: 1.1.2.4.1.2.26

Coded name: EDMSOFA

Name: PGM Create Extol Envelope for Office Data (EDMSOFA)

Comment : ©Purpose:

To create the transmission envelope for rental location/rates maintenance transaction sets for the sender interface to the Extol EDI Translation Software.

©Operational Method:

- Call this program after the interface program AMZ832A has already put the data in AMSEND. This program will create the necessary EDI transmission' envelope and transmit it to the insurance company.

©Notes: Set Environment as ADDLIBLE ELEDIxxx where "xxx" is the first 3 characters of the TRADING PARTNER PROFILE ID.

This program is executed only on the centralized ARMS host application system platform.

This program is currently stewarded by the Emerging Technologies Department's (ETD) Electronic Data Interchange (EDI) projects team.

Process

Hierarchical numeric ID: 1.1.2.4.1.2.27

Coded name: EDMSINA

Name: PGM Create Extol Envelope for Invoice Data (EDMSINA)

Comment: ©Purpose:

To create the transmission envelope for rental billing invoice transaction sets for the sender interface to the Extol EDI Translation Software.

©Operational Method:

- Call this program after the interface program AMZ811A has already put the data in AMSEND. This program will create the necessary EDI transmission envelope and transmit it to the insurance company.

Confidential Page 147 of246 8/11/00 ARMS Process Report

©Notes: Set Environment as ADDLIBLE ELEDIxxx where "xxx" is the first 3 Characters of TRADING PARTNER PROFILE ID.

This program is executed only on the centralized ARMS host application system platform and is executed from the ARMS Packaging Translation Job (CLL811) program.

This program is currently stewarded by the Emerging Technologies Department's (ETD) Electronic Data Interchange (EDI) projects team.

Process

Hierarchical numeric ID: 1.1.2.4.1.2.28

Coded name:

Name: DTQ Input for X12 Sender (DQxxxSCl) "xxx" = Company

Comment: ©Definition: DQxxxSC is a data queue used to provide input for X.12 transaction sender (xxx = Company) .

Process

Hierarchical numeric ID: 1.1.2.4.1.3

Coded name:

Name: BAT Package and Send Transactions to specified ARMS Trading Partner Companies

Comment: ©Definition: Package information held on the Centralized ARMS System into a batch package and send the information to specified ARMS Trading Partner Companies.

©Purpose: To prepare and send outbound transactions to specified ARMS Trading Partner Companies.

Process

Hierarchical numeric ID: 1.1.2.4.1.3.7

Coded name: AM***SNB

Name: PGM Send Batch Transmission (via ARMS-connected Value-Added Network AM***SNB)

Comment: ©Purpose:

• - '• To send from ARMS to specified ARMS Trading Partner Companies a Batch EDI Transmission of proprietary transaction data sets via ARMS-connected Value-Added Network. The transaction set functional group types sent are rental billing invoice documents ("IN") and rental location/rates maintenance documents ("OF") .

©Operational Method:

Clear the EDI integration software Local Data Area data structure.

Retrieve the EDI integration software user Profile Fi e record for ACCOUNT = ' ERAC • and USERID = 'ERACARM• .

Load the entire retrieved record value to the EDI integration software Local Data Area data structure's subfield for PROFILE RECORD.

Load the remainder of the EDI integration software Local Data Area data structure's subfields as follows:

'IEERACARM ' User files library (E4LBLB) 'IESTRM • Stream file name (E4LBST)

'IERCVD ' Received file name (E4LBRC)

Confidential Page 148 of246 8/11/00 ARMS Process Report

' IEMSGS ' Messages file name (Ξ4LBMS) ^~ ~ ~

'IEFILE ' Received files file name (E4LBFL)

•IESLOG ' Session log file name (E4LBLG)

•0' Base submit flag (E4LSBF)

•0' Base calling code (E4LBCL)

IF the passed input COMPANY PROFILE ID parameter is a specified ARMS Trading Partner Companies production ('***01'), load the COMMAND FILE NAME with 'IE***SND' .

IF the passed input COMPANY PROFILE ID parameter is a specified ARMS Trading Partner Companies testing ('T***T'), load the COMMAND FILE NAME with •IE***SNDT' .

Output to this program's Local Data Area (to be used by the EDI integration software) from the loaded EDI integration software Local Data Area data structure.

Execute the EDI integration software base ( • IEIFEXEC' ) program to execute the receive file according to the information just loaded in the current batch job's Local Data Area.

Retrieve the EDI integration software Local Data Area and load into the EDI integration software data structure.

IF the EDI integration software Local Data Area data structure's Base Return Code is not a normal completion ( ' 00 ' ) , then execute the Program Status Subroutine (*PSSR) to produce a formatted RPG dump and execute Perform Internal Error Paging and Messaging {'AMPSSR') program.

Retrieve the current time and date and load into the appropriate Send Log File record fields.

Position the ARMS specified ARMS Trading Partner Companies Send Batch file at beginning of file and then read each record and perform the following until . end of file:

..IF the retrieved record's Record Format ID is Transmission Start (TSMS01) , move the retrieved record to the Transmission Start record format's data structure^'. Move the Transmission Start record format's TRADING PARTNER ID and TRANSMISSION CONTROL ID to the appropriate Send Log File fields and to the appropriate ARMS Time Line Data Queue data structure subfields.

..Write each retrieved record to the ARMS Send Log File.

.IF the retrieved record's Record Format ID is Transmission End (TSME01) , then send a data queue entry to the ARMS Time Line data queue (DQAM70V1) that is associated with the send details written out to the ARMS Send Log.

©Notes:

This program is executed by the CLL811 CL batch program and is executed on the centralized ARMS host system platform ("RARMS") in the ARMS subsystem. It is passed a single input parameter of a 5-character COMPANY PROFILE ID.

©Files: (CRUD)

AM***SNB (-R-- ) ARMS Transactions to be Sent to specified ARMS ₍

Trading Partner Companies via Send Batch

Confidential Page 149 of 246 8/11/00 ARMS Process Report .

IΞPROF (-R--) EDI integration software User Profile File (in the IBM EDI integration software Production Library for *USER)

AMSNDLOG (c ) ARMS Transmissions Sent Log File

Files used as externally-defined data structures:

EX40LD EDS ETD: EDI integration software Local Data Area External Definition

TSMS01V1 EDS Transmission Start Record Format

DQAM70V1 EDS ARMS Time Line Input Data Queue external description

©Embedded Data/Constants :

■AM***SNB' PROGRAM ID

Used as output to the job's Local Data Area for the execution of the EDI integration software base ('IEIFEXEC') program to execute the receive file:

'IEERACARM ' User files library

'IESTRM ' Stream file name

'IERCVD ' Received file name

¹ IEMSGS ' Messages file name

'IEFILE ' Received files file name

•IESLOG • Session log file name

'0' Base submit flag

' 0 ' Base calling code

>IE***SND a ARMS Trading Partner Companies production (^ι***oi') COMMAND FILE NAME iIE***SNDT a ARMS Trading Partner Companies testing ('τ***T') COMMAND FILE NAME

©Improvement Opportunities:

1.) Convert from OPM RPG to ILE RPG program.

2.) Replace the constant 'AM***SNB' with the Program Status Data Structure subfield PROGRAM ID.

Process

Hierarchical numeric ID: 1.1.2.4.1.3.10

Coded name: AM0125

Name: PGM Create Customer Batch Time Work File (AM0125)

Comment: ©Purpose:

To load a temporary job work file with each of the financial management or rental management trading partners preferred batch packaging/sending start times for production and test transaction data sets.

©Operational Method:

- Using the billing times from the ARMS profile and whether a company receives electronic bills, create the billing times work file for each company id in the ARMS profile (ARMSPR3) . If the company is on a VAN (Value Added Network) , get the billing time from the corresponding VAN profile.

©Files :

Confidential Page 150 of246 8/11/00 ARMS Process Report

ARMSPRl (-R--) ARMSPR3 (-R--)

L811D (C ) ARMS Company Profile IDs and Batch

Packaging/Sending Time preferences job work file, unsorted.

©Notes :

The following Trading Partner (Company) Profile ID values are specific ARMS communication connections that multiple trading partner utilize to exchange information with ARMS:

VN101 - an ARMS-connected VAN Information Systems Value-Added Network (VAN) software

VN201 - PC-ARMS VN301 - ARMS/400

This is executed by the ARMS Batch Packaging/Send Job (CLL811) program on the centralized ARMS application system platform.

The ARMS system also enables electronic invoices, payments and remittances (processed here) to be sent/received for non-ARMS Rental Management Trading Partners that are Direct Billing/Remittance Trading Partners, such as _ Tennessee Valley Authority (an Enterprise Fleet Services customer). Therefore, ARMS will receive a data queue entry to generate an electronic invoice (and create an associated ARMS Rental Transaction Cross-Reference (AMXREF) file record) even though the trading partner never sent to ERAC (via ARMS) any initial rental authorization.

©Embedded Data/Constants :

"AM0125 ' as PROGRAM ID input parameter for execution of the ARMS Program Status Subroutine Exception Handler (AMPSSR) program.

©Improvement Opportunites :

1.) Convert this OPM RPG to ILE RPG.

2.) Replace the constant 'AM0125' with the Program Status Data Structure's subfield defined for PROGRAM ID.

Process

Hierarchical numeric ID: 1.1.2.4.1.3.13

Coded name: AM01 0

Name: PGM Create Batch Transactions Work File (AM0140)

Commen : ©Purpose:

To copy batch transaction data sets to a job file for batch packaging and sending for a specified trading partner.

©Operational Method:

- rite the *EOBD (End of Batch Data) APPD02 blank data record format to the AMPACK file for the current input parameter TRADING PARTNER PROFILE ID as the COMPANY PROFILE ID portion of the key and the '*EOBD' as the key's CUSTOMER TRANSACTION ID.

- Retrieve all the data ready to be packaged and sent for a specified insurance company (until the End of Batch Data) is retrieved, written to a job work file, except the End of Batch Data record.

Confidential ^: Page 151 of 246 8/11/00 ^~ ARMS Process Report

©Notes: This is executed by the ARMS Batch Packaging/Send Job (CLL811) program on the centralized ARMS application system platform with one 5-character input TRADING PARTNER PROFILE ID.

©Files:

AMPACK (CR--) Transaction Data Sets to be packaged for sending

L811B (C ) Batch Packaging Job Work File

ARMSKEY (-R--) EDS APPD01V1 (-R—) EDS

Process

Hierarchical numeric ID: 1.1.2. .1.3.14

Coded name: AM0151

Name: PGM Package Batch Transaction for specified proprietary and ANSI X12 ARMS EDI

Trading Partner Companies (AM0151)

Commen : ©Purpose:

To package control start records before and control end records after Vendor Invoices (IN) and Vendor Extension Request (RE) data set records, to form a complete transmission set. Control start and end records are used to route the transmission and indicates the type of transaction set being sent.

©Operational Method:

- For each transaction data set Build the control start record formats (Transmission, Group,

& Set) IF company ID EQUALS '***oi'

Write record formats to specified ARMS Trading Partner Companies send Batch

(AM***SNB) ELSE

Write record formats to send file (AMSEND) For each transaction data set record format

.^.. Translate the location (AUTDOl/ELCDOl/lEBHOl). IF company ID EQUALS '***01'

Write record format to ARMS Trading Partner Companies send

Batch

(AM***SNB) ELSE

Write record format to send file (AMSEND) -- IF transaction data set EQAUL Vendor Invoice (IN)

Write record format to ARMS Billing Log, Build the control end record formats (Set, Group, &

Transmission) IF company ID EQUALS <***01'

Write record formats to an ARMS Trading Partner Companies send

Batch

(AM***SNB) ELSE

Write record formats to send file (AMSEND) Sends a data queue to the connect-specific communications sender

©Notes:

Confidential Page 152 of 246 8/11/00 ARMS Process Report

- Control start/end records must match: Transmission start

Group Start (IN) Set Start

Set End Set Start

Set End Group End(IN) Transmission End

The ARMS system will now enable electronic invoices, payments and remittances (processed here) to be sent/received for non-ARMS Rental Management Trading Partners that are Direct Billing/Remittance Trading Partners, such as Tennessee Valley Authority (an Enterprise Fleet Services customer) . Therefore, ARMS will receive a data queue entry to generate an electronic invoice (and create an associated ARMS Rental Transaction Cross-Reference (AMXREF) file record) when the trading partner never sent to ERAC (via ARMS) any initial rental authorization.

©Files (CRUD)

L811C (-R--)

AM***SNB (C )

AMSEND (C---)

AMBILLOG (C )

Process

Hierarchical numeric ID: 1.1.2.4.1.4

Coded name:

Name: BAT Generate Vendor Request for Authorization Extension

Comment: ©Definition: To generate requests for authorization extensions (RE's) based upon specific conditons of the rentals as determined from the Rental Database.

This process is triggered by TIME.

©Purpose: To insure that rental extensions are requested in a timely fashion independantly of the manual call back process of the branch without the need of calling a bodyshop or adjustor, for those Trading Partners that allow the receipt of RE's.

Process

Hierarchical numeric ID: 1.1.2.4.1.4.8 Coded name: CLL811

Name: PGM Transmit Batch Transactions (CLL811) Comment : ©Purpose:

To perform certain requests/services for our trading partners base on the host platform.

When on the Centralized ARMS system, to package any held information(invoices, office location) into batches and send the transmission to the trading partner.

When on the Distributed Rental Management system, to generate requests for authorization extension.

Confidential Page 153 of246 8/11/00 ARMS Process Report

©Operational Method:

- IF the host platform is the distributed rental system (includes claims connection system on CENTRAL) , execute the procedure for generating authorization extension request (s).

- IF the host platform is the centralized ARMS system, batch package and send transmission to the trading partner.

1.) Use the Rental Management Trading Partner Profile - billing time, to initiate the batch package process at the predetermined time.

2.) At each scheduled time batch package any held information: a) Use the Rental Management Trading Partner Profile to set the Trading Partner Company Profile ID. b) IF Company ID flagged for production, retreive company specific records from application database (OPNQRYF) . c) IF Company ID flagged as test

- IF DEV host platform not available Send error message ELSE

Retrieve company specific records from application database on DEV host platform.

ENDIF d) Copy Vendor invoices (IN) and office information (OF) to job file and insert 'bookmark' in application database file. e) For each company id determine if there are records to package and how to package them:

- Single invoice per transmission (ANY ARMS-CONNECTED VAN )

- Multiple invoices per transmission

- IF Company ID = ARMS Trading Partner Company then EDI format is proprietary

ELSE • ->' Convert proprietary format to X12

ENDIF

3. ) Reorganize the EDI integration software User Profile file when the file contains at least 10% of deleted records.

©Files: (CRUD)

L811E (CR-D)

L811D (-R-D)

L811C (C--D)

L811B (C-D)

AMPACK (-R- -)

AM***SNB (-R-D)

AM***SNBSV (C- -)

Process

Hierarchical numeric ID: 1.1.2.4.1.4.9

Coded name: CC0BREV1

Name: PGM Send Claims Connection Vendor Extension Requests (CC0BREV1)

Confidential Page 154 of 246 8/11/00 ARMS Process Report

Comment : ©Purpose:

For those Rental Management Trading Partners that want this service, to interrogate the extension control file and determine if an authorization extension is needed. A data queue entry will be created for all contracts that have expired.

©Operational Method:

- For each extension control record

- Verify the contract is authorized with the Rental

Management Trading Partner having bill-to responsibility.

- Determine if the extension / Due Back date has sired and the

Rental Management Trading Partner hasn't sent a termination date.

- Verify the Rental Management Trading Partner allows / is setup for this service - Generate request for extension.

©Files (CRUD)

CCEXTCTL (-R--)

CCMASTER (-R—)

REQSTCTL (-R--)

©Notes :

- Batch jobs runs during the startup of ARMS (L811) between 3:00am and 5:00am cst.

- This program only runs on the centralized financial system(Central) .

Process

Hierarchical numeric ID: 1.1.2.4.1.4.16

Coded name: EC0BREV1

Name: PGM Send ECARS Vendor Extension Requests (ECOBREVl)

Comment : ©Purpos :

For those Rental Management Trading Partners that want this service, to interrogate the callback control file and determine if an authorization extension is needed. A data queue entry will be created for all contracts that have expired.

©Operational Method:

- For each callback control record

- Verify the callback is an authorized open ticket with the Rental

Management Trading Partner having bill-to responsibility.

- Determine if the extension date has expired and the Rental

Management Trading Partner hasn't sent a termination date.

- Verify the Rental Management Trading Partner allows / is setup for this service - Generate request for extension.

©Files (CRUD)

CB007P00 (-R—)

RACSMAST (-R—)

ECEXTCTL (-R—)

RACSUSP (-R—)

©Notes :

- Batch jobs runs during the startup of ARMS (L811) between 3:00am and

5:00am cst.

Confidential Page 155 of 246 8/11/00 ARMS Process Report

Process

Hierarchical numeric ID: 1.1.2.4.2

Coded name:

Name: AUT Generate CC Rental Billing Invoice

Comment: ©Definition: The automatic process of generating billing invoices for rentals from third parties via CLAIMS CONNECTION.

Process

Hierarchical numeric ID: 1.1.2.4.2.1

Coded name: CC00INV1

Name: PGM Generate Electronic Invoice Detail (CC00INV1)

Comment: ©Purpose:

To generate Vendor Invoice(IN) data set for sending to the Rental Management Trading Partner in response to the Claims Connection System closing the rental contract.

©Operational Method

- Wait indefinitely for the next DQAM60V1 data queue entry with a key of 'INC' .

- IF the receive data queue entry is a shutdown request, close program files and send that request to data queue DQANDST to inform the distributed send program it has ended.

- IF the receive data queue entry is a non-shutdown request THEN

- Rental contract meets authorization criteria

- IF the necessary data base records are retrieved THEN

- Build the applicable record forma (s) and write the record to the distribution transaction file (ANDIST) . Only build

RATDOl record format if trading partner profile indicates^ it .

ENDIF - Send a data queue entry on to the Distributed Send to

Centralized data queue (DQANDST) . ENDIF - Send a data queue entry to Dispatch Data Queue

(DQAM60V1) with a key of 'DIS' to finish the request. ENDIF

©Constants/Embedded Data:

- DAILY RENTAL - constant

- SALES TAX - constant

- MISC EXP - constant

- SURCHARGE - constant

- 43-0724835 (tx id)- constant

© improvement Opportunity - Use program status data structure when referring to program name.

©Files (CRUD)

CCCLSC (-R—)

Confidential Page 156 of 246 8/11/00 ARMS Process Report

CCSURDTL (-R—)

ANDIST (C—)

OFFDRB (-R-)

©Notes

- This program only runs on the centralized financial host platform.

- Application Data Set Formats

- APPDOl - Enterprise internal format

- IEBH01 - Invoice header format

- RATDOl - Rate detail format

- RNTD01 - Renter detail 1 format

- REND01 - Rental Notification format

- INSDOl - Insured format

- IEBD01 - Invoice detail format

- IEBT01 - Invoice total format

- ELCD01 - Arms vendor location

Process

Hierarchical numeric ID: 1.1.2.4.3

Coded name:

Name: AUT Edit Outbound Transaction

Comment: ©Definition: The automatic process of validating or editing the invoice formats and also updating the distributed ARMS database.

Process

Hierarchical numeric ID: 1.1.2.4.3.1 Coded name: AM0062V1

Name: PGM Edit Outbound Transaction (AM0062V1) Comment: ©Purpose:

To perform the distributed edit processing on any generated proprietar . EDI transaction sets in the ARMS Distributed Transactions Sets to be Centralized (ANDIST) file prior to being sent to the centralized ARMS application host platform for routing.

©Operational Method:

This program endlessly receives the non-keyed input data queue entries from the input data queue (DQAM62V1) that the ARMS Dispatch Rental Systems Request program (AM0060V1) generated as input to this program.

Once a shutdown data queue entry is received, then send this shutdown data queue entry to the DQANDST data queue and end this program..

For any non-shutdown data queue entry, check the non-shutdown key Group Type Code to be one of the following values:

'AC (Rental Transaction Authorization Confirmation)

'ER' (Rejected Transaction in Error)

'IN' (Completed Rental Billing Invoice)

'OF' (Rental Office Location/Rates Maintenance)

•RA' (Rental Transaction Request for Authorization)

■RC (Rental Transaction Request for Cancellation of Authorization)

'RE' (Rental Transaction Request for Authorization Extension)

'RN' (Rental Transaction Rental Notification Start/End)

Confidential Page 157 of246 8/11/00 ARMS ProcessReport

IF the data queue entry's Group Type Code is NOT one of the above, then error the transaction set with the ERROR CODE = '16' ("Invalid Group Type Code").

Read each of the input data queue entry's associated Transaction Sets File records (currently only AMINTR is processed) .

IF any record format read is not valid for the validated Group Type, then error the transaction set with ERROR CODE = '70' ("Invalid Format Specified in Set")

IF any following Record Format ID'S are read, check:

..IF its associated record format data structure has already been loaded, then error the transaction set with ERROR CODE = ' 71 ' ("Only One Format of This Type Allowed in Set"):

•ADJDOl' 'ADJD02' 'APPDOl' 'AUTDOl' ^•CANDOl' •ELCD01'

ΈRRDOI'

* IEBH01 ' • IEBT01 ' ' INSDOl ' 'OFFDOl' 'RENDOl' 'RNTD01' 'RNTD02' •RPRD01' 'VEDD01'

.ELSE, load the read record format into the record format's data structure.

..IF more than two (2) 'RATDOl' record formats are read, then error the transaction set with ERROR CODE = '90' ("Invalid Format - Not Agreed Upon").

..Only allow loading and output of the following maximum occurrences of these Record Format ID'S per transaction set, however, do not error the transaction if more are found, just do not allow loading, editing and output of them:

10 'COMDOl' Comment Detail

35 'IEBD01' Invoice Detail

30 'SURD01' Approved Surcharge Detail

IF GROUP TYPE CODE = 'IN' (Invoice), then do the following:

..Validate that the required formats for this Group Type Code exist ('APPDOl', 'ELCDOl', • IEBH01 • ; 'IEBT01'; 'INSDOl'; 'REND01'; 'RNTDOl'; at least one ■IEBD01'), and IF the 'IEBT01' record format's TOTAL AMOUNT DUE (IETDUE) is not zero. ELSE, error the transaction set with ERROR CODE = '69' ("Required Format Missing from Set") .

..Per orm transaction set group type specific record format's data element (field) value edits.

..IF no errors are found, then:

Confidential Page 158 of246 8/11/00 ARMS Process Report IF the data queue entry's VENDOR TRANSACTION ID is blank, then do the following (This is for any Financial Management Trading Partner who is able to receive any rental transaction's EDI Invoices but is not a Rental Management Trading Partner - Non-ARMS participating customer) : Add a new ARMS Rental Transaction Cross-Reference File record by executing the ARMS Assign Next Vendor Transaction ID ('AMRTVSQ') program to retrieve the next VENDOR TRANSACTION ID value Execute the ARMS Inquire/Update Rental Cross-Reference Record

(AMIOIOVI) program for update to add the record passing this rental contract (ticket) identifier, rental location, the retrieve VENDOR TRANSACTION ID and a CUSTOMER TRANSACTION ID comprised of the current date in ccyymmdd format. IF its PROGRAM RETURN CODE is not blank, then error the transaction set with ERROR CODE = *82' ("Request Rejected - Cannot Identify Transaction ID") . ELSE, Update each loaded record format's key values data elements with the new CUSTOMER TRANSACTION ID and VENDOR TRANSACTION ID values. ENDIF ENDIF .Execute the ARMS Inquire/Update Rental Cross-Reference Record

(AMIOIOVI) program for inquiry to check its STATUS CODE value.

....IF its PROGRAM RETURN CODE is not blank, then error the transaction set with ERROR CODE = '82' ("Request Rejected - Cannot Identify Transaction ID") ELSE, its PROGRAM RETURN CODE is blank, then IF the STATUS CODE is not currently 'B' (Billed), 'A' (Audited),

•P' (Paid), 'Q' (Invoice Rejected by Customer), then Execute the ARMS Inquire/Update Rental Cross-Reference Record (AMIOIOVI) program for inquiry to update its STATUS CODE value to *B' (Billed) ENDIF ENDIF .Write the record formats read to the ARMS Distributed Generated

Transaction Sets to be sent to the centralized ARMS system for routing file (ANDIST) Send the input data queue entry as an output data queue entry to data queue (DQANDST) for subsequent transmission to the centralized ARMS host platform/machine.

. -• ..ENDIF

©Notes :

This program is submitted for execution by the ARMS Startup Jobs program (CLL810) with no entry parameters to execute only on the ECARS host system platform (NOT "CENTRAL" nor "RARMS") . Currently, the only (non-shutdown) transaction set group type code processed in this program is the proprietary EDI, invoice Transaction Set Invoice ("IN") group types. These invoice transaction sets.were generated within a non-ARMS stewarded program. Generate ECARS Daily (Nightly) Billing batch (RBOOIO) program.

This is currently not performed on the Claims Connection host platform ("CENTRAL") because the Claims Connection process for Closing a Third-Party Rental Ticket sends a data queue entry to the ARMS Dispatch Rental Systems Request (AM0060V1) program to dispatch a data queue entry to the ARMS Generate Proprietary EDI Electronic Invoice Detail Transaction Set (CCOOINVl) program, stewarded by ARMS.

IF any error is found, then do not process this transaction any further and execute the ARMS Handle Internal Error (AM0097V1) program, passing the input parameters of this data queue entry's key data elements and the currently loaded

Confidential Page 159 of 246 8/11/00 ARMS Process Report

ERROR CODE value. This will notify ARMS On-Call of the errored transaction set's data queue entry value and the applicable ERROR CODE. Do NOT output the transaction set's record formats to the ANDIST file nor send its data queue entry to DQANDST.

The ARMS system will now enable electronic invoices, payments and remittances (processed here) to be sent/received for non-ARMS Rental Management Trading Partners that are Direct Billing/Remittance Trading Partners, such as Tennessee Valley Authority (an Enterprise Fleet Services customer) and AAA of California. Therefore, ARMS will receive a data queue entry to generate an electronic invoice (and create an associated ARMS Rental Transaction Cross-Reference (AMXREF) file record) when the trading partner never sent to ERAC (via ARMS) any initial rental authorization.

©Files: (CRUD)

ANDQINFO (-R—) ARMS Data Queue Information File AMINTR (-R—) ARMS Unedited Invoice Transaction Sets File ANDIST (CR--) ARMS Distributed Generated Transaction Sets to be sent to the centralized ARMS system for routing.

©Embedded Data/Constants:

•0123456789'

O123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ ' 'AM0062V1' •AM0062V1 '

©Improvement Opportunities :

1.) Convert this OPM RPG program to an ILE RPG program.

2.) Delete the 'AM0062V1' program name constants and specify/use the Program Status Data Structure's PROGRAM ID data element.

3. ) Delete the constants for valid numbers and use the TESTN operation for testing numerics.

^■ -^• . ) Add the submission of this program for execution on the Claims Connection host platform ("CENTRAL") because the mandatory field data values loaded from its rental system database must also be performed. The transaction set generation and editing processes should only be different in the fact that they access different rental systems databases.

5.) Replace the execution of the ARMS Handle Internal Error ('AM0097V1') program with the execution of the newer ARMS Handle Internal/External Error ('AM0098') program.

Process

Hierarchical numeric ID: 1.1.2.4.3.4

Coded name:

Name: DTQ Input to AM0062 (DQAM62V1)

Comment: ©Definition: DQAM62V1 is a data queue used to provide input for PGM

AM0062V1 which processes invoices read from file AMINTR to be sent to an EDI Trading

Partne .

Process

Confidential Page 160 of 246 8/11/00 ARMS Process Report

Hierarchical numeric ID: 1.1.2.4.5

Coded name:

Name: BAT Generate Invoice - ECARS

Comment: ©Definition: The batch process of generating invoice formats required for electronic billing in response to ECARS closing a rental. This process is triggered by TIME.

©Purpose: To be able to generate invoices for closed rentals in an automated fashion.

Process

Hierarchical numeric ID: 1.1.2.4.5.1 Coded name: RB0010

Name: PGM Create ECARS Invoice Detail (RBOOIO) Comment: ©Purpose:

To generate the initial billing invoices for closed rental contracts/tickets that have billing customers assigned that have a balance due that were closed on the previous business day.

Will also generate duplicate billing invoices for any closed rental contracts/tickets that have billing customers assigned that have a balance due that were selected fo rebilling.

©Operational Method:

- IF on "DEV" development platform, then retrieve the associated host platform Machine Name for the rental contract/ticke ' s Group and Branch ID.

ELSE retrieve the current application host platform's Machine Name where this program is executing.

- Set any special machine related attributes.

- For each customer's closed rental tickets selected for generation of the billing invoices in the job file, RACBILLJ (ECR: Facsimile Billing Master File, sorted by Customer) , perform the following steps:

<-' 1) Retrieve the closed rental contract/ticket information from the closed closed rental contract/ticket and its supplementary files.

2) Retrieve the ARMS profile and attempt to retrieve an associated ARMS Rental Transaction Cross-Reference information by executing the Retrieve ARMS Data (AM2090V1) program.

3) Check if the Bill-To Customer attributes returned from AM2090V1 indicates that the trading partner has the capability to receive electronic billing invoices or should be sent paper billing invoices . (Paper bills are default . )

4) IF electronic billing for ARMS, a) Generate formats APPDOl, IEBH01, ELCD01, -RNTDOi, RENDOl. b) IF the profile dictates that the RATDOl format needs to be generated, generate it with 3 different information contents - units and rates, units only and units and rates without relating to each other. c) Write the data queue entry to DQAM62V1 to send of the invoice transaction. d) Delete the original bill from RACBILL. e) Maintain electronic bills generation counts. ELSE electronic billing for non-ARMS customer. a) Generate formats APPDOl, IEBH01, ELCD01, RNTDOI, and RENDOl. b) For invoicing only customers also generate the AUTD01, and ADJDOl formats .

Confidential Page 161 of 246 8/11/00 ARMS Process Report c) Write the data queueu entry to DQAM62V1 to send the invoice transaction. d) Delete the original bill from RACBILL. e) Maintain electronic bills generation counts. ELSE paper bills a) Print the bill to appropriate medium (tape file, physical file) (Tape is turned over to a third party firm for sorting by ZIP/Postal Code, grouping and printing, envelope stuffing, postage and mailing.) b) Delete the original bill from RACBILL if bill was printed. c) Maintain paper bill generation counts

5) If unsupported version of billing type (type greater than 4), print on exception report and update the bill in RACBILL to a daily frequency so that the bill may be generated the day the error has been fixed.

6) IF ticket is not found in the closed ticket files, print on exception report and delete the bill from RACBILL.

7) At customer total time, maintain number of envelopes needed and reset paper billing counter.

- Repeat the above steps for the next customer until there are no more customers to process.

©Notes :

The various ticket types are : I=Insurance B=Bodyshop D=Dealer R=Regular

0=0ther.

The various billing types are : l=Tot Less 2=Dy Tax 3=Dy NoTax 4=0ther

5=Rebill .

The ARMS system now enables electronic invoices, payments and remittances (processed here) to be sent/received for non-ARMS Rental Management Trading Partners that are Direct Billing/Remittance Trading Partners, such as Tennessee Valley Authority (an Enterprise Fleet Services customer) . Therefore, at the initial billing invoice generation occurrence, no ARMS Rental Transaction Cross-Reference file record will exist at that time.

©Files: (CRUD)

RACBILLJ ( R • )

RABMSG ( R )

FEDTAXID ( R )

QRACCLSQ ( R )

RACSCLD ( R )

OFFDRB ( R )

CUSTMAST < R )

ECSURCHG ( R )

RACBRIST ( R )

RACBILL ( RU )

RACINS ( R )

BCPECG ( R )

AMXCLS ( R )

OFGBLN ( R )

RACILN ( R )

RACDJD ( R )

RACBILLT (C )

AMINTR (CRU )

RAGBBT (_R_>

Confidential Page 162 of 246 8/11/00 ARMS Process Report

Process

Hierarchical numeric ID: 1.1.2.4.5.2

Coded name: CHKZP

Name: PGM Format ZIP (CHKZP)

Comment: ©Purpose: To place the passed Zip Code into proper country format for printing or display.

©Operational Method:

This program expects the following parameters: (EDS CHKZPI)

ZPZIPS - SHIPPING Zip Code ZPEDTS - Edit Code Type

If not provided, format of edited zip code is determined by state. If provided, determines the format desired for the passed zip code and ignores state code. Valid action codes are:

1: 5 dash 4 (xxxxx-xxxx) U.S.

2: 5 blank 4 (xxxxx xxxx) U.S.

3! ** NOT USED **

4: only ( xxxx MEXICO 5: blank (xxx xx CANADA 6: blank (xxxx xx EUROPE 9: blank ( xxxxxxxx GENERIC

ZPSTS - State. If passed, and edit code is blank, is used to retrieve proper edit format from state code file. If state not found, edit format defaults to #9.

ZPNUMS Edit Code (Blank, "A", "B", "N" or "Z") Blank = A thru Z & 0 thru 9 A = A thru Z

B = A thru Z, 0 thru 9 & blank N = 0 thru 9 z = Anything

ZPZIPM - MAILING Zip Code ZPEDTM - Edit Code Type

If not provided, format of edited zip code is determined by state. If provided, determines the format desired for the passed zip code and ignores state code. Valid action codes are:

1: 5 dash 4 (xxxxx-xxxx) U.S.

2: 5 blank 4 (xxxxx xxxx) U.S.

3: ** NOT USED **

4: 5 only (xxxxx ) MEXICO

5: 3 blank 3 (xxx xxx ) CANADA

6: 4 blank 3 (xxxx xxx ) EUROPE

9: 9 blank (xxxxxxxxx ) GENERIC

ZPSTM - State. If passed, and edit code is blank, is used to retrieve proper edit format from state code file. If state not found, edit format defaults to #9. ZPNUMM - Edit Code (Blank, "A", "B", "N" or "Z") Blank = A thru Z & 0 thru 9 A = A thru Z

B = A thru Z, 0 thru 9 & blank N = 0 thru 9 Z = Anything

Confidential Page 163 of246 8/11/00 ARMS Process Report

The program returns the following parameters: (EDS CHKZPO)

ZOZIPS - SHIPPING Zip code, formatted for print. 10 pos. ZOCNTS - Country code. Retrieved from State file if not passed. ZONAMS - Country Name. Retrieved from State file. ZOMSGS - Error Message. If field is greater than blank, indicates an error. ZOZIPM - SHIPPING Zip code, formatted for print. 10 pos. ZOCNTM - Country code. Retrieved from State file if not passed. ZONAMM - Country Name. Retrieved from State file. ZOMSGM - Error Message. If field is greater than blank, indicates an error.

©Notes: Program moves input ZIP to output ZIP before performing edits. This serves as a default in case that an error occurs, program will always return a value. Calling program should but is not forced to look at the error message.

Process

Hierarchical numeric ID: 1.1.2.4.5.3

Coded name: VTS012A

Name: PGM Retrieve Vehicle Licensing Fee Charge Detail (VTS012A)

Comment : ©Purpose:

To retrieve the Vehicle License Fee Days, Daily Unit Charge, and Total Charge for all input units for a group, branch, and ticket number.

©Operational Method:

The program expects the following data elements as the parameters (EDS VT024X1) with group, branch, ticket and the four unit numbers filled in:

Processing Mode

Ticket

Calendar Rental Flag

Ticket End Date

Renting Group

Renting Branch

Init Total Days

Unit Total Days

Unit 1

Unit 2

Unit 3

Unit 4

Date Out 1

Date Out 2

Date Out 3

Date Out 4

Date In 1

Date In 2

Date In 3

Date In 4

Init VLF Days Unit 1

Init VLF Days Unit 2

Init VLF Days Unit 3

Init VLF Days Unit 4

New VLF Days Unit 1

New VLF Days Unit 2

New VLF Days Unit 3

Confidential Page 164 of 246 8/11/00 • ARMS Process Report

New VLF Days Unit 4

Segment 1 Days

Segment 2 Days

Segment 3 Days

Segment 4 Days

Segment 1 Weeks

Segment 2 Weeks

Segment 3 Weeks

Segment 4 Weeks

Segment 1 Months

Segment 2 Months

Segment 3 Months

Segment 4 Months

Daily VLF Unit 1

Daily VLF Unit 2

Daily VLF Unit 3

Daily VLF Unit 4

Total VLF Unit 1

Total VLF Unit 2

Total VLF Unit 3

Total VLF Unit 4

Total Rental VLF

CA Branch

Employee Number

Start Charges 1 Time

Ticket end time

VLF Bill To Flag

CA License Renewal No-Unit 1

CA License Renewal No-Unit 2

CA License Renewal No-Unit 3

CA License Renewal No-Unit 4

Bill To Less VLF

Bill To Plus VLF

Return Code 1

Return Code 2

Return Code 3

Return Code 4

Process

Hierarchical numeric ID: 1.1.2.4.5.6

Coded name: CCRAVN

Name: PGM Retrieve VIN (CCRAVN)

Comment: ©Purpose: To return the Vehicle Identification Number (VIN) for a unit.

©Operational Method:

The program expects the following input parameters: unit number, ticket type ('D'ealer) and Option ('1'= Open a Ticket). VIN is returned along with the print flag. The parameter list is as follows:

UNIT NUMBER TICKET TYPE VIN#

PRINT FLAG TICKET OPTION

Process

Confidential Page 165 of 246 8/11/00 L ARMS Process Report

Hierarchical numeric ID: 1.1.2.4.5.7

Coded name:

Name: RPT Exceptions of ECARS Rental Contracts Not Invoiced

Comment: ©Purpose: To create a report of all the ECARS closed tickets that were not invoiced during this invocation of the invoice generator, RBOOIO, because of an error so that it can be investigated and the error fixed before the ticket is resubmitted for invoicing.

©Report Distribution: Not defined.

Process

Hierarchical numeric ID: 1.1.2.4.5.8

Coded name: CLJ340

Name: PGM Driver Program for Invoice Generation (CLJ340)

Comment: ©Purpose: Prepare and bill closed / re-billed tickets for all trading partner based on their frequency.

©Operational methods:

- Collect requests for any ticket to be re-billed.

- Total the number of records for a given control group

- Update the detail records with the total for the control group

- Generate the invoices

- Generate listing of invoices not created.

Process

Hierarchical numeric ID: 1.1.2.4.5.9

Coded name: RB0030

Name: PGM Create Total Record for Control Group (RB0030)

Comment: ©Purpose: Create a total record for each control group, to be used later in the process for sorting and processing.

©Opertational Method:

- Read every detail record, incrementing a number per control group.

- Write a record to work file with the total for control group.

©Notes: This pertains to invoices that are faxed.

Process

Hierarchical numeric ID: 1.1.2.4.5.10

Coded name: RB0031

Name: PGM Update Detail Records with Control Group Total (RB0031)

Comment: ©Purpose: Update detail records with control group total.

©Operational Method:

- Read every detail record, updating it with the control group total ©Notes: This pertains to invoices that are faxed.

Confidential Page 166 of 246 8/11/00 ARMS Process Report

Process

Hierarchical numeric ID: 1.1.2.4.5.11

Coded name: RB0037

Name: PGM Calculate the actual number of Facsmilie (RB0037)

Comment: ©Purpose: Update the individual detail records with the number total number control records for a givien group.

©Opertaional Method:

- Read the file counting the number of control records for a given group

- When the control group changes, update each detail record with that number.

©Notes :

- This number is used for determining if a cover page is to be generated with the invoices.

Process

Hierarchical numeric ID: 1.1.2.4.5.12

Coded name: F20114

Name: PGM Generate Facsimile Spool File for Control Group (F20114)

Comment: ©Purpose: Distribute the spool file based on language code

©Operational Method:

- Read to work file group all records for a customer together.

- When the total page count is less than 6 no cover page is generated.

- When the total page count is 6 - 9, generate cover page - Portrait.

- When the total page count is greater than 10, generate cover page - landscape.

- Generate report.

Process

Hierarchical numeric ID: 1.1.2.5

Coded name:

Name: BT Close ARMS Authorized Ticket

Comment: ©Definition: The set of online activities that are used to calculate the billing totals for an ARMS Authorized Ticket that has closed.

©Purpose: Process that is executed to calculate the Trading Partner amount due.

Process

Hierarchical numeric ID: 1.1.2.5.2

Coded name:

Name: ONL Close ARMS Authorized ECARS Ticket

Comment: ©Definition: The process that close goes through to calculate the billing charges for an ARMS ticket.

Process

Confidential Page 167 of 246 8/11/00 ARMS Process Report

Hierarchical numeric ID: 1.1.2.5.2.1

Coded name: ECARMSV1

Name: PGM Calculate EC Billing Charges for ARMS Tickets (ECARMSV1)

Comment: ©Purpose: To calculate the amount to be billed to the renter and the amount to be billed to the insurance company at closing time for an ARMS authorized ticket .

©Operational Method:

This program when called will receive the ticket information as parameters .

For the passed ticket, perform the following steps:

1) Calculate the number of days to bill and total days authorized.

2) Get the group branch tax information to determine what surcharges apply and if the surcharges are taxable.

3) Load the approved surcharges from the file ECSURCHG, Surcharges Approved by Insurance Company File, into arrays based on the surcharge type, i.e., daily, lump and percent. Add the daily rate augmentor surcharges ( ' 02 ' =city/state and '20'= underage) to the calculated authorized daily rate. Similarly, add the lump surcharge with code 'll*=Miscellaneous to the calculated authorized lump total field. These special surcharges are not loaded to the surcharge arrays.

4) Check for any government surcharge, airport charge, additional charges (baby seat, additional driver charge etc) per rental charged on the ticket against the lump array to see if the insurance company has authorized that surcharge. If the amount in the ticket information matches the amount in the array, it means that this surcharge amount was authorized by the insurance company as the arrays were loaded from the approved surcharges file. If authorized, add this to the calculated lump total or the taxable lump total field if the charge is taxable for this ticket.

5) Check for any government surcharge, airport charge, additional charges (baby seat, additional driver charge etc) , damage waiver for each unit, personal accident insurance for each unit, per day, charged on the ticket against the daily array to see if the insurance company has authorized that surcharge. If the amount in the ticket information matches the amount in the array, it means that this surcharge amount was authorized by the insurance company as the arrays were loaded from the approved surcharges file. If authorized, add this to the calculated daily authorized rate total or the dialy taxable total field if the charge is taxable for this ticket.

6) Similarly, check for percentage surcharges in tlie percent array.

7) Apply any discount to the calculated rates and compare against authorized maximum amounts for the ticket. If the calculated charges exceed the maximums, select the maximums as the charges to be billed to the insurance company.

7) If the claim type is "claimant", policy maximums are ignored otherwise the lesser of the bill-to amount and the policy maximum is chosen.

8) Retrun with the amount to be billed to the insurance company and the amount to be billed to the renter.

©Notes: Some ARMS Trading Partner Companies does not send us the amounts for the surcharges. They simply send us flags indicating which surcharges they will pay for ,e.g., PAl, DW, SLP etc. Any charge that the branch charges for the ^• surcharge flag sent by them will be considered authorized subject to the maximums.

©Files :

GPBRTX ( R )

ECSURCHG ( R ) VT010P00 ( R )

OFFDRB ( R )

Confidential Page 168 of246 8/11/00 ARMS Process Report

Process

Hierarchical numeric ID: 1.1.2.5.3

Coded name:

Name: ONL Close Claims Connection Ticket

Comment: ©Definition: The process that close goes through to calculate the billing charges for an ARMS ticket.

Process

Hierarchical numeric ID: 1.1.2.5.3.1

Coded name: CCARMSVl

Name: PGM Calculate CC Billing Charges for ARMS Tickets (CCARMSVl)

Comment: ©Purpose: To calculate the amount to be billed to the renter and the amount to be billed to the insurance company at closing time for an ARMS authorized ticket .

©Operational Method:

1) Retrieve the ticket data.

2) Determine how many and which rental locations were used.

3) For each location perform the following steps:

* Calculate number of billing days for this location.

* Determine Bill-To days and the remaining authorized days

* Determine Bill-To Daily Rate

* Calculate total surcharge amount for this ticket/location

* Calculate Daily Maximum

* Select the lesser of the daily rate or the daily maximum

* Multiply bill-to daily rate times the number of bill-to days to '•' determine extended bill-to rate.

* Add taxable authorized lump totals

* Calculate tax percentage. Multiply extended bill-to rate time tax percent to determine bill-to taxable amount

* Calculate markup per day amount, extend it and add to the bill-to amount

* Add in percentage surcharges to total bill-to.

* Percentage surcharges are non-taxable and are applied only to the base amount

* Add approved non-taxable lump, daily, and percentage surcharges ... to the total bill-to ticket amount.

* If loss type is NOT a claimant, select the lesser of the authorized amount and the calculated bill-to amount. ■ . ^{■ '}

* Calculate the bill-to percentage and the amount due from the trading partner.

* If loss type is NOT a claimant, select the lesser of the amount due from the trading partner or the policy maximum.

©Files:

CCCLSC (__R ) CCMASTER ( R ) CCSURDTL ( R )

Confidential Page 169 of 246 8/11/00 ARMS Process Report

Process

Hierarchical numeric ID: 1.1.3

Coded name:

Name: AA Office Information Synchronization Between Enterprise and Trading Partner

Comment: ©Definition: The application area responsible for keeping the Enterprise office information database on the insurance companies host computer in synch with the database on Enterprise computer with regard to any new additions, changes or deletions to the office or the predefined rental rates information.

Process

Hierarchical numeric ID: 1.1.3.1

Coded name:

Name: BT Synchronize Office Information for specified ARMS Trading Partner Companies

Comment: ©Definition: The set of automated activities that are used to create and transmit Rental Location office information to a specified ARMS Trading Partner

Company's host computer.

©Purpose: Communicate Enterprise existing rental location office information (telephone and/or rates) to the trading partner.

Process

Hierarchical numeric ID: 1.1.3.1.5

Coded name:

Name: BAT Generate Office Maintenance Transactions for specified ARMS Trading Partner

Companies

Comment: ©Definition: The batch process that generates required office and predefined rental rates maintenance transactions to be sent to specified ARMS Trading

Partner Companies host computer. This batch is triggered by TIME and scheduled in the automated job scheduler.

©Purpose: To allow for timely updated information of office and rate info to specified ARMS Trading Partner Companies.

• - ' ©Notes : Rental Location Office changes are made by the Rental Application Systems during the day. These changes are process when this processes runs.

Process

Hierarchical numeric ID: 1.1.3.1.5.1

Coded name: CLL900

Name: PGM Distribute Office and Rate Updates (CLL900)

Comment: ©Purpose:

To collect office and predefined rental rates information changes and generate maintenance transactions to synchronize this information on the insurance company's host computer. Also, to consolidate these transactions from the distributed systems to the centralized ARMS system.

©Operational Method:

1) CALL CLL042 to generate rate maintenance transactions in file AMLOCTRN, Location/Rate Change Transactions.

Confidential \ Page 170of246 8/11/00 ARMS Process Report

2) IF the returned run status is ^■Y* , CALL AM00 1V1 to generate the ARMS proprietary formats and send them to the centralized system. ELSE end the program.

Process

Hierarchical numeric ID: 1.1.3.1.5.2 Coded name: CLL042

Name: PGM Gather Rate Updates (CLL042) Comment: ©Purpose:

To determine if there are any changes to the predefined rental rates in file NRXRATES (national reservation exception rates) for insurance type customers and to generate synchronizing transactions for maintaining the rates on specified ARMS Trading Partner Company's host computer.

©Operational Method:

- Retrieve job run date and add one day to get tomorrow's date. Subtract one day to get yesterday's date.

1) Retrieve the last job completed date from data area DAL900STS and compare this date to yesterday's date. a) IF this is not a rerun and the dates are not equal, notify ARMS On- Call (backup and primary) . Set the run status flag to 'N' and return, so that the calling program, CLL900, does no further processing. b) IF this is a rerun or the dates are equal (i.e. the job was completed yesterday) , continue.

2) Open a query file selecting those rates from NRXRATES that become ineffective today and those that become effective tomorrow. Then CALL AM0042 to create rate maintenance transactions in AMLOCTRN for these selected records.

Process

Hierarchical numeric ID: 1.1.3.1.5.3

Coded name: AM0042

Name: PGM Create Rate Update Transactions (AM0042)

Comment: ©Purpose:

To create predefined rental rate maintenance transactions for a location. Each location may have rates specified for each type of car that the location hosts with effective dates.

©Operational Method:

1) Read NRXRATES (Query file over NRXRATES, national reservations exception rates opened by CLL042) in a loop until end of file. The selection criteria for the query are: {Pre-arranged discount type = 'I' (Insurance)} AND {(Start Date = Job Date + 1) OR (Stop Date = Job Date)}. This will select any rates for a location that are ending today and/or any rates that are effective tomorrow.

2) In order to determine which type of maintenance (add, change or delete) to perform; this program holds the previous records key while it sequentially reads the query ile (Key: Group + Branch + Car Type + Start Date) . Remember we are dealing with only those records that are selected by the query.

Confidential Page 171 of 246 8/11/00 ARMS Process Report a) IF the current record' s Group+Branch+Car Type matches the previous record's, then this signifies a 'Change. Create rate change transaction in AMLOCTRN for this location and car type. b) IF the current record's Group+Branch+Car Type does not match the previous record's, then : i) IF the start date is tomorrow, this is an 'A'dd. Create rate add transaction in AMLOCTRN for this location and car type. ii) IF the stop date is today, this is a 'D'elete. At this point, this condition HAS to be true. Create rate delete transaction in AMLOCTRN for this location and car type.

©Files:

NRXRATES (_R )

NRCTY (_R )

AMLOCTRN (C )

Process

Hierarchical numeric ID: 1.1.3.1.5.4

Coded name: AM0041V1

Name: PGM Format and Distribute Office and Rate Updates (AM00 1V1)

Commen : ©Purpose:

To read the office and rate change transactions and generate appropriate ARMS proprietary formats for the synchronizing maintenance transactions that need to be sent to the insurance customer.

©Operational Method:

1) Read the ARMS Profile Application Specific Data (ARMSPRl) file starting with the first record and for each profile that specifies that the insurance company receives office and rate updates, perform the following steps.

2) Read the AMLOCTRN file and for each location in this file, check to make sure that the location is set up to receive ARMS reservations. IF the location is not set up, skip this record and read the next record ELSE continue.

3) Get the effective predefined rental rates for this location from the NRXRATES file and generate the office and rate maintenance transaction sets (format OFFDOl) for this profile and write to file ANDIST for transmission to the centralized system. A data queue entry to the data queue DQANDST will trigger the transmission.

4) Get next record from AMLOCTRN and repeat steps 2,3,4 until all. records in AMLOCTRN are read.

5) Finally, delete all records from file AMLOCTRN. '..

©Files:

ARMSPRl (_R )

AMLOCTRN (CR_D) NRXRATES ( R ) DROFF (_R___) NRCTY ( R ) ANDIST (C )

Process

Confidential Page 172 of 246 8/11/00 ARMS Process Report

Hierarchical numeric ID : 1.1.3.2

Coded name:

Name: BT Synchronize Office information for X12 Customer

Comment: ©Definition: The set of automated activities that are used in the creation and transmission of Rental Location Office information to be sent to X.12 customers .

©Purpose: Communicate Enterprise existing rental location office information to the trading partner.

Process

Hierarchical numeric ID: 1.1.3.2.6

Coded name:

Name: BAT Generate Office Location / Rates Maintenance Transaction Set 832 for X12

Comment: ©Definition: The batch process of generating required office maintenance transactions (which includes office information and rates information) to be sent toX.12 customers. This batch is triggered by TIME and scheduled in ROBOT.

©Purpose: To allow for timely updated information of office and rate info to X-12 customers.

Process

Hierarchical numeric ID: 1.1.3.2.6.1

Coded name: AML832A001

Name: MOD Convert Journal Entries to Transactions (AML832A001)

Comment : ©Purpose:

To convert office directory information journaled changes to a change transactions for futher processing.

©Operational Method:

- Read the job file, AML832JA (created via the DSPJRN command in the calling procedure) sequentially.

- Based on the before and after images of the office directory records in the journal entries, construct the change transactions with the appropriate business case into file, AM830P (AM Office change transactions) . This will handle two business cases :

1 = Add/Update Rental Car Company Branch Number 6 = Delete Branch Number

©Notes:

1. Only U.S. Daily Rental locations will be processed.

2. If an error occurs, generate and error/page, then return and 'Exit Code' of '1' so the caller can detect that an error occurred.

Note also that this program module reads from AML832JA which is a file created by the DSPJRN command.

©Files :

AM830P (C_UD) MACHID ( R )

Confidential Page 173 of 246 8/11/00 ARMS Process Report

Process

Hierarchical numeric ID: 1.1.3.2.6.2

Coded name: AML83 A002

Name: MOD Determine Company & Invoke Send Office Updates (AML832A002)

Comment: ©Purpose:

To determine which companies have requested for the office and predefined rental rate change transactions to be sent to them and to send the change transactions to the company if requested.

©Operational Method:

1) Read the profile data to determine which company has requested to receive the X.12 synchronizing office and rate maintenance transactions.

2) For each company that has requested office updates, perform the following (procedure PrσCstOfcUpdts) : a) Build the beginning transmission envelope using procedures BldArmsKey, BldTSMSOl, BldGRPSOl and BldSETSOl in that order into AMSEND. b) Invoke the GetCarClasses procedure with appropriate parameters to get the Enterprise and X12 car classes for this customer from file AMCLSTBL. c) For all records in file AM830P (Office change transactions) , invoke the procedure FmtSndOfcϋpdts with appropriate parameters to write office update records to AMSEND. If a new office location is being added and the GetCarClasses procedure returned car classes, invoke the FmtSndRateUpdts procedure with appropriate parameters to write Rate Format records to AMSEND for the customer. d) Build the ending transmission envelope using procedures BldSETEOl, BlsGRPEOl and BldTSMEOl in that order into AMSEND. e) Send a Data Queue to DQ832S to initiate the sending of this transmission.

;-' ©Notes:

If an error occurs, generate an error/page, then return an 'Exit Code' of '1' so the caller can detect that an error occurred. If an 'Exit Code' of '1' is returned from a called procedure, return the 'Exit Code' to the caller immediately.

©Files:

AM830P (-R--)

AM831P (-RU-)

ARMSPRl (-R--)

ARMSPR3 (-R--)

AMSEND (C )

Process

Hierarchical numeric ID: 1.1.3.2.6.3

Coded name: AML832A003

Name: MOD Format and Send Office Updates (AML832A003)

Commen : ©Purpose:

Confidential Page 174 of 246 8/11/00 ARMS Process Report

To format the information passed from the transaction file record to prepare it for sending.

©Operational Method:

Procedure FmtSndOfcUpdts

1) Use procedure BldArmsKey to build the key for AMSEND.

2) Use procedure BldLocFmt (Build location format) to build the office maintenance transaction proprietary format X832F2 and write to AMSEND.

3) IF the location format is a business case 6 (delete branch) , additional formats need to be generated to handle the service area updates as a result of the delete. a) Retrieve all the service areas served by this branch (rental location) by reading the service area/location file AM831P01 in a, loop using the rental location as the key. b) For each of these service areas, call the locator procedure, AMRtnUSLoc, passing the service area to get the new branch for this service area. Update service area file, AM831P01 with the new location returned from AMRtnUSLoc unless a return code of '06' is received or the location returned is blank In these cases, generate an error/page and skip to the next service area. c) Use procedure BldSvcFmt to create the service area update format X832F1 and write to AMSEND.

©Files :

AMSEND (C )

AM831P (-RU-)

©Notes :

1. The service area formatting is shared with job AML833A and as such must be considered for a service program. . In general, if an error occurs generate an error/page; then return an •Exit Code' of '1' so the caller can detect that the error occurred. If an 'Exit Code' of '1* is returned from a called procedure, return the 'Exit Code' to the caller immediately. There may be alternative handling of some errors noted in the operational method.

Process

Hierarchical numeric ID: 1.1.3.2.6.4 Coded name: AML832A004

Name: MOD Maintain data area AM832A (AML832A004) Comment: ©Purpose:

To maintain data area AM832A with the starting (from) date and time to be used for filtering the DSPJRN command in program AML832A on the next scheduled run. This is the last task performed after all processing for the job has been completed.

©Operational Method:

Procedure SetNxtFrmDtTm.

Retrieve and lock data area AM832A. It will contain the starting (from) date and time used in the DSPJRN command for the current job.

Add 1 second to the date and time passed to this procedure, which

Confidential Page 175 of246 8/11/00 ARMS Process Report will contain the ending (to) date and time used to filter the DSPJRN command for the current job.

Update data area AM832A with the new value and unlock.

©Notes :

In general, if an error occurs generate an error/page; then return an ■Exit Code' of '1' so the caller can detect that the error occurred.

Process

Hierarchical numeric ID: 1.1.3.2.6.5

Coded name: AML832A005

Name: MOD Format and Send Rates/Car Classes (AML832A005)

Comment : ©Purpose:

To format the rates for retrieved car classes for any new Enterprise location being sent to the specified insurance company.

©Operational Method:

Procedure Fm SndRateUpdts .

1) Use procedure GetClassRates to get the rates for the specified customer for the specified location.

2) Use procedure SndRateFmts to write rate format X832F3 records to AMSEND for each X12 Class and Rate. Handle return codes as follows:

ALLRATES ' 00 ' Rates for all classes were found and sent for loc . INVALPARM '01' Generate error/page and process next location.

NORATES '02' Generate error/page and process next location. •"'^• SOMERATES '03¹' Rates for some of the classes were found and sent. LOCKEDRECORD '99' Generate erro /page and process next location.

©Files:

AMCLSTBL (-R-) AMSEND (C )

©Notes:

1) In general, if an error occurs generate an error/page; then return an 'Exit Code' of *1' so the caller can detect that the error occurred. There may be alternative handling of some errors noted in the operational method.

Process

Hierarchical numeric ID: 1.1.3.2.6.6

Coded name: AML832A006

Name: MOD Build ARMS Start/End for Office Updates (AML832A006)

Comment: ©Purpose:

Confidential Page 176 of246 8/11/00 ARMS Process Report

To build the key and data fields for the transmission, group, and set start and end envelope for office and rate updates.

©Operational Method:

The following procedures are exported for use by other procedures. when building the office and rate update transactions, these procedures provide the ARMS proprietary transmission envelope formats.

The file AMSEND consists of two parts, the key and the proprietary format. These procedures will return the key and envelope proprietary formats in the AMSEND data structure, AMSENDDS.

1) Procedure BldArmsKey: a) Clear the ARMSKEY and AMSEND data structures. b) Populate the ARMSKEY (Data Structure) fields and move the ARMSKEY data structure to the ASNKEY field of the AMSEND data structure c) Return

2) Transmission Start procedure BldTSMSOl: a) Clear the TSMS01 data structure. b) Populate the TSMS01V1 (Data Structure) fields and move the TSMS01V1 data structure to the ASNDTA field of the AMSEND data structure c) Return

3) Group start procedure BldGRPSOl: a) Clear the GRPS01 data structure b) Populate the GRPS01V1 fields and move the GRPS01V1 data structure to the ASNDTA field of the AMSEND data structure c) Return

4) Set start procedure BlsSETSOl: a) Clear the SETS01 data structure b) Populate the SETS01V1 fields and move the SETS01V1 data structure to the ASNDTA field of the AMSEND data structure c) Return

.'•' 5) Transmission end procedure BldTSMEOl: a) Clear the TSME01 data structure b) Populate the TSME01V1 fields and move the TSME01V1 data structure to the ASNDTA field of the AMSEND data structure c) Return

6) Group end procedure BldGRPEOl: a) Clear the GRPE01 data structure b) Populate the GRPE01V1 fields and move the GRPEOpLVl data structure to the ASNDTA field of the AMSEND data structure c) Return

7) Set end procedure BldSETEOl: a) Clear the SETE01 data structure b) Populate the SETE01V1 fields and move the SETE01V1 data structure to the ASNDTA field of the AMSEND data structure c) Return

©Notes :

1. This module has been bound by copy into two different ILE programs AML832A and AML833A and such must be converted into a service program at some point.

Confidential Page 177 of246 8/11/00 ARMS Process Report

2. If an error occurs, generate an error/page, then return an 'Exit Code' of ' 1 * so the caller can detect that an error occurred.

Process

Hierarchical numeric ID: 1.1.3.2.6.7

Coded name: AML833A001

Name: MOD Select Unique Service Areas (AML833A001)

Comment: ©Purpose:

To select each unique ARMS Trading Partner Company service area (area code + exchange) from all the phone numbers in the US, associate a location, and record the combination.

©Operational Method:

1) The first parameter to this module specifies the service area to start processing from. If it is blank, process all service areas.

2) Since the service areas consist of the phone number, area code, and prefix; the maximum service area is '999999'. For each sequential possible service area from 1 through 999999, try positioning file AT001P01 to the record for that service area. If successful, send a data queue containing that service area to DQ834Q.

3) Monitor data queue DQ834Q while processing. Any time the data queue accumulates more than 1000 entries, delay the job for 45 seconds repeatedly until there are 1000 or less entries. If 30 delays are executed before the count falls to 1000 or less, return a value of Υ' (Abnormal end) to AML833A so it will generate an error/page .

4) After service area '999999' is processed, return to AML833A. ©Files:

AT001P01 (-R--)

Process

Hierarchical numeric ID: 1.1.3.2.6.9

Coded name: AML833A003

Name: MOD Determine Company and Invoke Send SA Updates (AML833A003)

Comment: ©Purpose:

To determine which companies have requested to receive the service area updates and then invoke the send routine for each such company.

©Operational Method:

1) Determine which company has requested to receive office and rate changes and for each such company, invoke procedure SndSvaUpd to send the updates.

©Notes:

If an 'Exit Code' of '1' is returned from a called procedure or an error occurs, generate an error/page and end the program immediately.

©Files:

Confidential Page 178 of 246 8/11/00 ARMS Process Report

ARMSPRl (-R--) ARMSPR3 (-R--)

Process

Hierarchical numeric ID: 1.1.3.2.6.10 Coded name: AML833A004

Name: MOD Format and Send SA Updates (AML833A004) Comment : ©Purpose:

To format and send the service area change transactions to the specified company in the input parameters.

©Operational Method:

Procedure SndSvaUpd using specfied company.

1) Use procedure BldArmsKey to build the key portion in file AMSEND.

2) Use transmission envelope procedures BldTSMSOl, BldGRPSOl and BldSETSOl to build the beginning envelope.

3) For each service area in file, AM833P (AM Changed Service Areas) build proprietary format X832F1 with the appropriate business case into file AMSEND.

4) Build the ending envelope using procedures BldGRPEOl, BldSETΞOl and BldTSMEOl .

5) Send a data queue entry with the ARMSKEY to data queue DQ832S. This data queue entry will be picked up by the send interface program for actual mapping and sending.

6) Return to caller.

©Notes :

If an 'Exit Code' of '1' is returned from a called procedure or an error occurs, generate an error/page and end the program immediately.

©Files:

AM833P (-R—) AMSEND (C )

Process

Hierarchical numeric ID: 1.1.3.2.6.11 Coded name: AML833A005

Name: MOD Return a U.S. Location (AML833A005) Comment: ©Purpose:

To return a U.S. location for a passed service area (Area Code and

Exchange)

©Operational Method:

1) Initialize the data structure that iε passed to the locator program,

RAS013A.

Confidential Page 179 of246 8/11/00

2) Execute appropriate overrides to make the locator retrieve Enterprise branches only.

3) Use the locator program to determine the best case rental branch that could serve the service area passed to the program.

5) To determine if the returned branch is usable, we check DROFLFl.

IF prevent ARMS, use forward to location. IF No forward to location, keep looking. IF country code is 'CA', keep looking.

6) The return value for procedure AMRtnUSLoc should be 12 characters. The first 2 positions are the return code (same codes as RAS013A) . The other 10 positions are the location (as returned from RSA013A) .

7) If there is an unexpected error, use *PSSR to page, on call staff after dumping the program

8) RETURN.

©Files :

DROFLFl (-R--) DROFFL7 (-R--)

Process

Hierarchical numeric ID: 1.1.3.2.6.12 Coded name: AML833A

Name: PGM Send Service Area Updates (AML833 ) Comment: ©Purpose:

To control the various procedures to synchronize the service areas (area code + exchange) representing Enterprise locations in the ARMS Trading Partner Company database with the Enterprise office directory database.

^{• •} ©Operational Method: l)τhe first input parameter specifies the number of never ending jobs which this program submits; each of these jobs calls program AML834A (Process Service Areas) . These jobs will share the processing of entries sent to data queue AM834Q by this program (module AML833A001) by repeatedly receiving the next available data queue entry and processing it. This method is used to speed up processing.

2) If the second parameter is blank, this is not a restart; clear files AM833P (changed service areas) and AM834P (Claims Connection service areas) .

3) Once the jobs are submitted, call procedure AML833A001 to process service areas. The second parameter to this program specifies the starting service area from where this procedure will start processing in the global phone number file. If it is blank, all service areas will be processed. The procedure will sequentially select all service areas from the starting point and send them to data queue AM834Q for processing by the AM834A jobs.

4) Generate an error/page if AML833A001 returns a value of 'Y' (Abnormal end) . Otherwise, send a *D0WN data queue to each of the AML8334A jobs to end them.

5) End this program when all the submitted jobs have shutdown. Confidential Page 180 of246 8/11/00 ARMS Process Report

©Notes :

1) This job runs only on the ARMS Centralized system.

2) This program clears file AML833DA but the file is not used for anything. It is in the evolution plan to remove it and update the comments in all associated modules.

3) If an error occurs or an 'Exit Code' of ' 1 ' is returned by a called procedure, generate an error/page and end the program immediately.

Process

Hierarchical numeric ID: 1.1.3.2.6.13 Coded name: AML832A

Name: PGM Update Office Directory (AML832A) Comment : ©Purpose:

This is a CLLE program module and will serve as the entry point module for the ILE program AML832A which will consist of bound modules that will synchronize the office information between Enterprise and X.12 customers (i.e., any ARMS Trading Partner Company) .

©Operational Method:

1) Make sure the machine that this module executes is "RARMS". If not RARMS, end the program.

2) Get the last process date and time for the job from the data area AM832A. This is where the last process ran left off and this run should now get the entries from this date and time to the current date and time.

3) Convert the journal entries available in the OMS journal, ©JRNLIB/OMSJRN for file OFFDRB to a job file, AML832JA. The job file has been created using command DSPJRN and essentially has the format the same as QADSPJRN (IBM supplied outfile format) except that the last field called JOESD (Entry Specific Data) is of length 480 which is the record length for OFFDRB. The command syntax will be as follows:

.-> DSPJRN JRN(©JRNLIB/OMSJRN) FILE( (*LIBL/θFFDRB *FIRS ) ) RCVRNG(*CURCHAIN) FROMTIME(J-FROMDATE &FR0MTIME) TOTIME (&T0DATE &T0TIME) JRNCDE ( (R *ALLSLT) ) OUTPUT (*OUTFILE) 0UTFILFMT(*TYPE1) OUTFILE (QTEMP/AML832JA) ENTDTALEN(480)

The field JOESD will contain the after image of the entire OFFDRB record. Journal code (JRNCDE) of *R" means only those journal entries that relate to operations at the record level (add, update, delete) . The journal receiver range needs to be *CURCHAIN which means that all the receivers that are ON LINE since the last break in the receiver chain. OMS deletes OMSJRN journal repeivers when they are 48 hours old. A new journal receiver is created whenever the current receiver is 200 Megabytes in size and a new receiver is created every day whether the last receiver reaches its threshold or not.

4) CALLPRC CnvtJrnlToTrns (Module AML832A001) to convert the journal entries to change transactions.

5) CALLPRC PrcOfcUpdates (Module AML832A002) which will determine all the companies that have requested office information to be sent to them and will then invoke the send module for each company.

Confidential Page 181 of 246 8/11/00 ARMS Process Report -r

6) CALLPRC SetNxtFrmDtT (Module AML832A004) with the converted 'to date' and 'to time' in CYMD and HMS format. This procedure will maintain the data area AM832A for processing dates.

©Notes :

If an 'Exit Code' of '1' is returned from a called procedure or an error occurs, generate an error/page and end the program immediately.

This program module creates the file AML832 A as a result of the DSPJRN command.

Process

Hierarchical numeric ID: 1.1.3.2.6.15

Coded name:

Name: DTQ Service Areas to Send - Input to Sender (DQ832S)

Comment: ©Definition: The data queue that initiates the sending of the X.12 synchronizing office and rate maintenance transactions to the x.12 insurance customer.

Process

Hierarchical numeric ID: 1.1.3.2.6.16 Coded name: AML834A

Name: PGM Process Service Areas (AML834A) Comment : ©Purpose:

To create a service areas update file containing service areas that have been changed since the last time these service areas were sent to the insurance customers .

©Operational Method:

1) Receive the service area from the input data queue, AM834Q.

2) Use procedure AMRtnUSLoc to get the Enterprise US location that will service this service area.

3) IF the service area exists in file AM831P (all US service areas file) a) if the location on file is the same as the location returned.by AMRtnUSLoc, skip this service area else update the file with the correct location. b) add this service area to file, AM833P (changed service areas file) c) if the returned location is Claims Connection,^' add the service area to file AM834P (Claims connection service areas) .

4) IF the service area does not exist in file AM831P (all US service areas file) a) add the service area to file AM831P. b) add this service area to file, AM833P (changed service areas file) c) if the returned location is Claims Connection, add the service area to file AM834P (Claims connection service areas) .

5) When a shutdown entry is received from the data queue, update data area AM832A to reflect that this job is shutting down.

Confidential Page 182 of246 8/11/00 ARMS Process Report

©Files:

AM831P (CRU-) AM833P (CR--) AM834P (C )

Process

Hierarchical numeric ID: 1.1.3.2.6.17

Coded name:

Name: DTQ Service Areas to Process (AM834Q)

Comment: ©Definition: This data queue is used to feed job AML834A with unique service areas for all US phone numbers. There can be several AML834A jobs running that feed off of this data queue.

Process

Hierarchical numeric ID: 1.1.3.3

Coded name:

Name: BT Send Initial or Yearly Car Class Rates and Initail Office Information for

X12 Customer

Comment: ©Definition

The initial/yearly process of sending car class rates and office information to insurance customers who recieve this information in X.12 format.

©Purpose

Provide insurance customers with Enterprise office information and car class rates initially. Provide them with car class rates both initially and at yearly intervals.

Process

Hierarchical numeric ID: 1.1.3.3.1

Coded name: AML831A

Name: PGM Send Car Class Rates (Initial/Yearly) and Office Info (Initial) (AML831A)

Comment: ©Purpose

To control the procedure to send initial or yearly rates for car classes and initial office information to insurance customers who receive this information in X.12 format.

©Operational Method:

This program only runs on RARMS or DEV. On other computer platforms, it will exit immediately without processing.

Call procedure AML831A001 to retrieve rates and send them for the insurance customer specified.

Process

Hierarchical numeric ID: 1.1.3.3.2

Confidential Page 183 of 246 8/11/00 ARMS Process Report

Coded name: AML831A001 ~ ^"

Name: MOD Send Rates (Initial/Yearly) and Office Info (Initial) (AML831A001)

Comment : ©Purpose

To send initial or yearly car class rates and initial office locations to the specified insurance customer in X.12 format. •

©Operational Method

1) Retrieve a transmission ID from data area AMTCID.

2) Call procedures in module AML832A006 to build the key and write the start formats to file AMSEND.

3) Call procedure GetCarClasses (module AML832A005) to retrieve car classes for the customer.

4) Call procedure LoadMachArray to retrieve all U.S. computer platforms.

5) Read through file OFFDRB, and process only U.S. office locations.

6) Call procedure FmtSndRateUpdts (module AML832A005) to send rates for the car classes retrieved. These will be written to AMSEND in X832F3 formats. If this is the initial load, specify business case ' 1 ' . If this is a yearly load, specify business case ' ' .

7) If this is the initial load, call subprocedure SndOfcUpdt to send the office location information. This will be written to AMSEND in X832F2 formats using business case *1'.

8) Call procedures in module AML832A006 to build the key and write the end formats to file AMSEND.

9) Send a data queue to DQ832S containing the key with the transmission ID to initiate sending the information to the insurance customer when batch program. AMZ832A runs.

©Files : (CRUD)

OFFDBB (-R-)

ARMSPRl (-R--)

ARMSPR3 (-R-)

MACHID (-R—)

AMSEND (C )

Process

Hierarchical numeric ID: 1.1.4

Coded name:

Name: AA ARMS Support

Comment: ©Definition: The application area responsible for supporting ARMS communications environment, producing reports for customers and handling any operational problems that are discovered.

Process

Hierarchical numeric ID: 1.1.4.1

Confidential Page 184 of 246 8/11/00 ARMS Process Report

Coded name :

Name: SA Manage Environment

Comment: ©Definition: The activity that initiates the ARMS application and performs a controlled shutdown when needed. It also involves tasks to handle transactions bound for a machine that is currently unavailable.

Process

Hierarchical numeric ID: 1.1.4.1.1

Coded name:

Name: BAT Purge Application Database

Comment: ©Definition: This activity archives and reorganizes the application database, including some of the transactions work files.

Process

Hierarchical numeric ID: 1.1.4.1.1.1

Coded name: AML992

Name: PGM Purge Cross-Reference and Associated Database File(s) by Vendor Id (AML992)

Comment : ©Purpose:

To maintain the ARMS database by purging (deleting) old records.

©Operational Method:

- Calculate the oldest date for retained data.

- For each cross-reference record:

- Delete all records, in the database, associated to the cross-reference where the status code and date criteria are met.

- Delete records as above until a shutdown request is detected.

©Notes: files AM095P and AM096P are retained for 25 months. ©Files : CRUD

AMXREF (-R-D)

AMMNTLOG (-R-D)

AMAUTD (-R-D)

AMADJD (-R-D)

AMCOMD (-R-D)

AMINSD (-R-D)

AMIEBH (-R-D)

AMIEBD (-R-D)

AMIEBT (-R-D)

AMRATD (-R-D)

AMRMTD (-R-D)

AMRNTD (-R-D)

AMRPRD (-R-D)

AMSURD (-R-D)

AMTIME (-R-D)

AMMSCLOG (-R-D)

AM990P (-RUD)

AM095P (-R-D)

AM096P (-R-D)

Process

Confidential Page 185 of 246 8/11/00 ARMS Process Report

Hierarchical numeric ID: 1.1.4.1.1.3

Coded name: AML994A

Name: PGM Stop cross-Reference and Associated Database File(s) Purge (AML994A)

Comment : ©Purpose:

To change the control data area (AM006A) for the purge (program AML992A) , instructing it to shutdown.

©Operational Method:

- Change the contents (position 1 - 8) of the data area to cause the program to shutdown.

Process

Hierarchical numeric ID: 1.1.4.1.1.4

Coded name: AML993A-

Name: PGM Purge Orphan Transaction / Database Records (AML993A)

Comment: ©Purpose:

To delete every record in the ARMS database, that does not have a corresponding cross-reference record.

©Operational Method:

- For each database file:

- Read the file, deleting any record that does not have an associated cross-reference record.

©Note:

- Files AM0060SV, AMXFRLOG, and AMPGMERR are purged using a date obtained from the control file. Files AM095P and AM096P are retained for 25 months.

©Files

- AMERRHST (-R-D)

- AM990P (-R—) •-- AM0060SV (-R-D)

AMADJD (-R-D)

AMAUTD (-R-D)

AMBILERR (-R-D)

AMBILLOG (-R-D) AMCOMD (-R-D)

AMIEBD (-R-D)

AMIEBH (-R-D)

AMIEBT (-R-D)

AMINSD (-R-D)

AMMNTLOG (-R-D)

AMMSCLOG (-R-D)

AMPGMERR (-R-D)

AMRATD (-R-D)

AMRCVERR (-R-D)

AMRMTD (-R-D)

AMRNTD (-R-D)

AMRPRD (-R-D)

AMSNDLOG (-R-D)

AMSTSX (-R-D)

AMSURD (-R-D)

AMTIME (-R-D)

Confidential Page 186 of 246 8/11/00 ARMS Process Report

AMTRNLOG (-R-D) ^—

AMXFRLOG (-R-D)

AMXREF (-R-D)

AM095P (-R-D)

AM096P (-R-D)

Process

Hierarchical numeric ID: 1.1.4.1.1.5

Coded name: AML995A

Name: PGM stop Orphan Transaction / Database Records Purge (AML995A)

Comment: ©Purpose:

To change the control data area (AM008A) for the purge (program AML993A) , instructing it to shutdown.

©Operational Method:

- Change the contents (position 1 - 8) of the data area to cause the program to shutdown.

Process

Hierarchical numeric ID: 1.1.4.1.1.6

Coded name: AML996A

Name: PGM Reorganized Application Database File(s) (AML996A)

Comment : ©Purpose:

To maintain the size of the database files by reorganizing the objects, thus reducing amount of time required when accessing the data.

©Operational Method:

- Update the controlling data area with the file name to be reorganized. That way when the job ends in mid stream it can pick up where it let off.

Process

Hierarchical numeric ID: 1.1.4.1.1.7 Coded name: AML997A

Name: PGM Archive Transaction File Data (AML997A) Comment: ©Purpose:

Based on a practical experience of the Application Support Staff, data within certain transaction files are archived for trouble shooting purpose.

©Operational Method:

- Create the archive files when they don't exist for the host machine running the program.

- Each file follows the same archiving procedure:

Second month rolled to temporary Third month First month rolled to Second month Current month rolled to First month Empty Third month inserted as Current month

Confidential Page 187 of 246 8/11/00 ARMS Process Report

©Note: Presently the data is kept for two months.

Process

Hierarchical numeric ID: 1.1.4.1.2

Coded name:

Name: BAT Startup ARMS Environment

Comment: ©Definition: This activity reorganizes the transactions work files, data queues, archives needed information and prepares the environment for starting the

ARMS application.

©Notes: The ARMS rejected transactions report is also generated by this activity.

Process

Hierarchical numeric ID: 1.1.4.1.2.1 Coded name: CLL813

Name: PGM Delete and Rebuild Data Queues (CLL813) Comment: ©Purpose:

To delete and rebuild data queues. This is an IBM recommended procedure to improve data queue performance.

©Operational Method:

- CALL CLL813HIST to archive file, AMSET.

- CALL AM0038V1 to save data queue entries (for all data queues except DQAM62V1) and associated data to work files for restoring at a later time

- CALL AM0037V1 to save AMPACK (ARMS Transactions ready to be sent) records that have not been processed to a work file for restoring at a later time

- Read records from ANDQINFO file in a loop and for each data queue in the file, perform the following steps: i) IF data queue name is DQAM62V1 and the machine is NOT DEV, skip this record and read the next record ELSE continue ii) IF the associated data queue file name is blank, skip this record and read the next record ELSE continue iii) IF the machine is RARMS and "RARMS Only" flag is 'Y'es, OR IF the machine is DEV OR IF the machine is NOT RARMS AND the RARMS only flag is NOT

'Y'es

IF the data queue name is blank, reorganize the data queue file

IF the VAN is not specified OR IF the VAN is specified AND this is the weekly run, clear the data queue file. IF the file is in use, message ARMS On Call - IF on the DEV machine, CALL CLL814 (as it is not submitted by ROBOT on DEV) . On DEV CLL813 is called by CLL991.

Process

Hierarchi cal numeric ID : 1.1.4 .1.2.2

Coded name: CLL813HIST

Name : PGM Backup ARMS Critical Files (CLL813HIST)

Confidential Page 188 of 246 8/11/00 ARMS Process Report

Commen : ©Purpose:

To backup files ANDIST, AMSET and AM0060LG. ©Operational Method:

- On the DEV machine, archive all three files with the *REPLACE option on the CPYF command to keep the archived file size small.

- On the RARMS machine, archive the set file, AMSET with the *ADD option to append to the previous archive

- On the distributed machine, archive the files ANDIST and AM0060LG to ANDIST_HST and AM0060SV respectively with the *ADD option to append to the previous archives .

Process

Hierarchical numeric ID: 1.1.4.1.2.4

Coded name: AM00 8

Name: PGM Save / Restore Data Queue Entries and Associated Data (AM0038)

Comment : ©Purpose:

To save the data queue's data to a work file and then delete and recreate the data queue to improve its performance.

©Operational Method: Three parameters are passed to this program: the processing code ('S'ave or 'R'estore), the data queue name and the run type ('D'aily or 'Weekly) .

For 'S'ave processing do the following:

- If the data queue name parameter is *ALL, read file, ANDQINFO in a loop Else read the file with the data queue name as the key and for each data queue that meets the following conditions : is not DQAM62V1 is not blanks, the VAN id is blanks OR the VAN id is not blanks and the run type is 'Weekly, the machine is RARMS and the "RARMS Only" flag is 'Y'es, the machine is 'DEV' the machine is distributed and the RARMS Only flag is NOT 'Y'es;

Do the following:

IF the key length is greater than zero receive all keys greater than blank ELSE simply receive each entry sequentially.

For each entry except the *DOWN, *STOP and *WAIT entries, write the data queue key and data to a work file until all entries have been received.

For each entry that has associated records in a database file, write the records to a work file.

Then delete the data queue and recreate it.

For 'R'estore processing:

Confidential Page 189 of246 8/11/00 ARMS Process Report

- If the data queue name parameter is *ALL, read the work file in a loop ELSE read the work file with the data queue name as the key and for each data queue entry found in this file, i) Read the file, ANDQINFO to get the data queue information ii) Send the queue entry to the corresponding data queue via one of the two subroutines, one for keyed and one for non-keyed data queues. iii) Write any associated database records in the work file back to the appropriate database file.

For any chain failing in the above, CALL AMPSSR and message ARMS On Call.

Process

Hierarchical numeric ID: 1.1.4.1.2.5

Coded name: AM0037V1

Name: PGM Backup Unprocessed Transactions in Package file AMPACK (AM0037V1)

Comment: ©Purpose:

To save unprocessed AMPACK records.

©Operational Method:

Job L813 creates a work file, L813A by sorting AMPACK by company id.

Read previous L813A starting from the last record and save all 'IN'voice and 'OF' fice batch transactions that have not been sent .

Any company that has a format 'APPD02' record in AMPACK has already been processed and so do not save that company's data. Look for *EOBD in the data portion and the format name 'APPD02'. This format is written by program AM0140 (called in CLL811) for each company that the batch transmission is sent to.

Process

Hierarchical numeric ID: 1.1.4.1.2.6

Coded name: CLL810

Name: PGM_, RMS Startup (CLL810)

Comment : ©Purpose:

To start up the ARMS application system programs that make the ARMS system handle transactions on a continuous basis until a shutdown is initiated.

©Operational Method:

- Call program CC0006 to reset the callback control status flags from "OK" to "DO" in CCEXTCTL Claims Connection Callback file. '

- Reset the Number of Transmission Envelope Validation NEP jobs currently active to zero.

-Allocate file AMXREF to determine if there iε lock on this file. If there is no lock DeAllocate file and continue. If the file is locked and not available delay job and try again. If on the third attempt the file is still locked page the ARMS onσall.

- Submit the proper Never-Ending Program (NEP) batch jobs to the ARMS Job queue for the centralized ARMS external transaction-based ("real-time") communications (separate sending and receiving jobs for each specific connection) ,

Confidential Page 190 of 246 8/11/00 ARMS Process Report centralized ARMS processing, centralized internal host platform distribution communications, distributed ARMS processing, distributed rental interface and distributed rental extraction transaction set generation processes. (This is based on the current host system name that this startup processing is being executed.)

©Notes :

This processing is initiated daily around 3:30am. Shutdown: 11:50pm (all times for Central Time Zone)

©Files (CRUD) none

Process

Hierarchical numeric ID: 1.1.4.1.2.8

Coded name: CLL817

Name: PGM Copy / Print Rejected Transactions Report & Start Subsystem (CLL817)

Comment: ©Purpose :

To consolidate all the transactions rejected by ARMS edits and generate an rejected transactions report after archiving the error log file, AMERRLOG. Also, start the ARMS subsystem if not already started.

©Operational Method:

- IF on the distributed machine, copy file AMERRLOG to the same file on the ARMS host via DDM and then clear the file. If DDM link is unavailable, message on call staff.

- IF on the ARMS host, archive consolidated file AMERRLOG and generate rejected transactions report by calling program AM5000. Reorganize file AMERRLOG to remove deleted records.

- Start the ARMS subsystem if not already started.

Process ι ■■ ^'-

Hierarchical numeric ID: 1.1.4.1.2.9 Coded name: AM5000

Name: PGM Print ARMS Error Log Report (AM5000) Comment : ©Purpose:

To generate the report for all the inbound and outbound transactions that were rejected by ARMS edits.

©Operational Method:

- Read file AMERRLOG sequentially. The file is keyed by Company Id, Transmission Control Id, Group Control Id, Group Type and Customer Transaction Id.

- For every record in this file, write the header and all error codes and associated detail. For error codes 68 (Invalid Vendor Transaction Id) and 82 (Request Rejected : can not identify transaction) on an Authorization (AT) group type, retrieve the SET 9formats beginning with "SET") and Renter (formats beginning with "RNT") detail formats from the received transactions log, AMTRNLOG and write them to the detail portion of the report.

Confidential Page 191 of246 8/11/00 ARMS Process Report

Process

Hierarchical numeric ID: 1.1.4.1.2.11

Coded name: AM0032V1

Name: PGM Write Saved AMPACK records to AMPACK (AM0032V1)

Comment: ©Purpose:

To restore the saved AMPACK records.

©Operational Method:

This program starts at the bottom of the work file where AMPACK records were saved and does a read prior to restore the data to the file, AMPACK in the proper sequence.

Process

Hierarchical numeric ID: 1.1.4.1.2.12

Coded name: AML002A

Name: PGM File Transfer and Archive RMS ARMS Trading Partner Insurance Company

Transaction File (AML002A)

Comment : ©Purpose:

To transfer the daily RMS (Rental Management System) transaction file record on the centralized ARMS host platform to the RMS interface file on the RMS centralized host platform.

©Operational Method:

This program is submitted to run as a batch job on the centralized ARMS host platform after the CLL814 program batch job has completed and before the CLL810 program batch job has been submitted. The program will attempt to allocate exclusively and if successful, then copy the ARMS RMS Daily Transaction file (AM002P) to an FTP (File Transfer Protocol) remote site and an archive data set.

Retrieve the current platform (machine) name.

IF the platform name is not 'RARMS' (centralized ARMS host), or 'CENTRAL' (centralized RMS host), or 'DEV' (IS development host), then end this program/job.

Retrieve the current executing job's SUBSYSTEM DESCRIPTION name, JOBNAME and JOBDATE.

Clear the RMS staging area file (AM002PFTP) .

IF the current platform is RARMS or DEV, then do the following:

.. Check for an empty RMS Daily Transactions (AM002P) file.

.. IF the RMS Daily Transactions (AM002P) file is empty (no records) , then end program/job.

.. ELSE, Attempt to Allocate file AM002P to prevent all other access.

.... IF unable to allocate exclusively the AM002P file, then end the program and send a corresponding Enterprise Message System message to the ARMS On- call staff along with a pager message to the ARMS Primary and Backup On-Call pagers indicating "AM002P File is in use" .

AND: Copy the AM002P file to the currently empty RMS interface staging area file (AM002PFTP) sequentially from the beginning of the file.

AND: Clear and Deallocate the AM002P file, making it reusable.

Confidential Page 192 of246 8/11/00 ARMS Process Report

IF the current platform is CENTRAL or DEV, then do the following:

.. IF RARMS is remotely unavailable ( "platform or intersystem communications link is down" ) , then send a corresponding message of the remote communications failure to the current platform's system operator (QSYSOPR) and resubmit this job on hold for execution later on this platform, using the previously retrieved JOBNAME, JOBDATE and SUBSYSTEM DESCRIPTION name as the JOB QUEUE name and then end this program/job.

..ELSE (RARMS platform is remotely available) , then do the following:

....Perform a "copy-pull" with replacement by copying the records sequentially from the AM002PFTP file on centralized RARMS platform to the current platform's AM002PFTP file.

....Check for an empty RMS Daily Transactions Interface Staging Area (AM002PFTP) file.

....IF the RMS Daily Transactions Interface Staging Area (AM002PFTP) file is empty (no records), then end program/job.

. ELSE, do the following: Retrieve the 4 character day of week abbreviation (current OS/400 system value) (Example: 'THUR', 'WED ', 'TUES') Append the first 3 character of the -character day of week to the

'AM002P' file name to derive the correct archive file for each day of the week. Copy (sequentially with replace) the file to be transferred via FTP to the derived archive file for today's day of the week. Retrieve the AM007A data area to get the Local Area Network FTP site name for RMS download. (Example: 'FTPCORPOl

') Execute the FTP (File Transfer Protocol for AS/400 to Personal

Computer) for downloading using the QTXTSRC Text Source File's AMRMSFTPO member for the File Transfer Input Specifications to transfer/copy with append the records on the AS/400 platform in the RMS Daily Transaction Interface Staging Area (AM002PFTP) file into the AM002P.TXT file in the "\rms\" directory on the FTPCORPOl LAN server's public drive.

©Files: (CRUD)

AM002P (-R-D)

AM002PFTP (CR--)

AM002P.TXT (C ) (in the \rms directory of the FTPCORPOl specified drive of the LAN server's public drive)

©Improvement Opportunities :

Change this process from a batch process to a real-time process to send/push any qualified transaction into the RMS database files'.

Process

Hierarchical numeric ID: 1.1.4.1.2.13

Coded name: CLL814

Name: PGM Restore Unprocessed Transactions (CLL814)

Comment : ©Purpose:

To restore the data queue entries and associated file data that was saved in job L813.

Confidential Page 193 of246 8/11/00 ARMS Process Report

©Operational Method:

The run type 'D' aily or 'W eekly is passed to this program as a parameter .

- CALL AM0032V1 to restore file AMPACK

- CALL AM0038V1 with the processing code set to 'R'estore to restore the data queues (these data queues contain the key and the data in the data queue itself e.g. DQAM60V1)

- Save the work files and then clear them

Process

Hierarchical numeric ID: 1.1.4.1.3

Coded name:

Name: BAT Shutdown ARMS Environment

Comment: ©Definition: This activity shuts down all the ARMS never ending programs that constitute the main ARMS transaction processing stream.

©Notes: The transactions processing stream consists of the following:

- Translators (AM10)

- Host Processing (AM20/21-AM46)

- Distributed Sending (AM100-AM101) from host

- Distributed Inbound Processing (AM61-EC(AT,EX,CN,CM,CC) )

- Distributed Outbound Processing (AM60-EC(AC,RA,RE,RC,RN,VM,TR)

- Distributed CC Inbound Processing (AM61-CC(AT,EX,CN,CC) )

- Distributed CC Outbound Processing (AM60-CC(AC,RA,RE,RC,RN,IN,TR)

- Distributed Receiving (AM105-AM106) to host

- Host Sending (AM120)

The receiver jobs remain active 24 X 7 hours except when a roll swap is done to switch all processing to the backup ARMS host machine.

The first shutdown entry is sent to each of the translators running (via program AMSTOP2X which is called from CLL812 which is a scheduled job ) so that all input to the stream can be stopped. The translator decrements data area DASDV1, passes shutdown to AM20 and ends itself. AM20 monitors data area DASDV1 and when it becomes zero, it passes the shutdown to AM21 and ends itself. AM21 in turn passes the entry to AM25 and ends itself. AM25 then reads data area AM001A to get the number of computer platforms to shutdown and sets on an internal flag to indicate to itself that one shutdown entry has already been received. After this AM25 passes the entry to AM30 and so on up to AM46. These programs do not end with the first shutdown entry in order that they be able to process any data coming from the distributed computer platforms.

AM46 then passes the entry to each of the distributed sending jobs (AMIOO) so that the distributed streams can be stopped. AMIOO passes the shutdown to AM101 with a detach signal. When AM61 receives the shutdown entry, it reads file AMVRGTST, keyed by group type and source type (e.g. ATB, ATC etc.) to shutdown each of the inbound format generators and then sends the shutdown to AM60 which in turn stops the outbound format generators before ending itself. Each of the format generators, AM61 and AM60 send a hutdown entry to AMI06 before ending. AMI06 maintains a count of all applicable records in AMVRGTST and when that count is met, it passes the shutdown entry to AM105 along with a detach signal before ending.

Note that AM101 and AM105 can distinguish between a single machine shutdown and a complete syεtem shutdown. For e.g., AM105 will not pass the shutdown to AM25 if it was a single machine shutdown.

Confidential Page 194 of246 8/11/00 ARMS Process Report

AM25 then increments the data area, AM002A, that contains the count of computer platforms that have shutdown. When this count equals the machine count in data area AM001A (manually maintained) , AM25 knows that the required number of computer platforms are down and now it can end the remaining host processing stream that is still up by passing on the entry until it reaches AM46.

AM46 then passes the entry to AM120 which stops each of the senders based on the file ARMSPR3 and then ends itself.

Process

Hierarchical numeric ID: 1.1.4.1.3.1

Coded name: CLL812

Name: PGM Stop ARMS Never-Ending Programs (CLL812)

Comment : ©Purpose:

To initiate the automated and orderly process for ARMS system shutdown in order to completely process any transactions that have already been started and then shutdown the whole system.

©Operational Method:

- Send Shutdown Request transaction to Trading Partners so profiled to be able to receive a shutdown request.

- After five (5) minutes, then end the remaining communication jobs via an ENDJOB command.

- Send a Shutdown Transaction to each connect-specific receiver output data queue.

©Notes :

Upon the receipt of the first shutdown transaction by the centralized validation activity component programs (AM0025, AM0030 and AM0040) and the centralized database update activity component process program (AM0046) , the first shutdown transaction is indicated and the shutdown transaction is passed along to the next program. After receiving the second shutdown transaction, the shutdown transaction is passed to the next program and causes the current program to end in an orderly manner.

Process

Hierarchical numeric ID: 1.1.4.1.3.2

Coded name: AMSTOP2X

Name: PGM Stop All Active Translator jobs (AMSTOP2X)

Comment: ©Purpose:

To shutdown all translator and any receive mapper jobs running in the ARMS subsystem.

©Operational Method:

- Retrieve all companies and technical connection information for each company from the profile file, ARMSPR3 and send a shutdown entry to the appropriate receive data queue to shutdown the translator (AM10) job for each company or VAN as the case maybe.

Confidential Page 195 of246 8/11/00 ARMS Process Report

- Then send a shutdown entry to the ARMS Trading Partner Insurance Company receive mapper job. This is hard coded in this program.

Process

Hierarchical numeric ID: 1.1.4.1.3.3 Coded name: RSWAPSTR

Name: PGM End ARMS jobs if necessary (RSWAPSTR) Comment : ©Purpose:

To shutdown the ARMS processing stream on the current machine as part of the preparation for the role reversal betweeen the current and the backup machine.

©Operational Method:

- Check the ARMS and A4BAT subsystems for jobs to see if jobs L812 and LAMSTOP2R have run.

If there are jobs running in either subsystem do the following: i) if the time is between 0300 and 2345, submit a job to perform an immediate end of the ARMS processing stream by callling CLL812 with a delay of zero, ii) if the time is between 0300 and 2200, end jobs L811 and L749. iii) if the time is between 2245 and 2530, call AMSTOP2R with a zero delay to immediately end all the receiver communication jobs. iv) once all the above steps have been performed, end the ARMS subsystem to flush any remaining jobs.

Process

Hierarchical numeric ID: 1.1.4.1.3.4

Coded name: CLSR01

Name: PGM Role reversal CLP (RARMS1 <-> RARMS2) (CLSR01)

Comment : ©Purpose:

To shutdown all processing on the current machine and start the ARMS processing on the backup machine.

©Operational Method:

- This CL is executed by operations when there is a need to perform a role reversal between the current and the backup ARMS machine.

©Notes:

This CL includes a lot of processing for ending several subsystems that may be running on the current machine and the code is maintained by operations.

The source for this CL can be found in the SPLIB/QCLSRC.

Process

Hierarchical numeric ID : 1.1.4.1.3.5

Coded name: AMSTOP2R

Name: PGM Stop All Active Comm. Receive Jobs (AMST0P2R)

Confidential Page 196 of 246 8/11/00 ARMS Process Report

Comment: ©Purpose:

To shutdown the communications receiver jobs for all companies and to end the pseudo sender job, A4200RB for the special case of ARMS/400.

©Operational Method:

- Retrieve the profile information to construct the receiver job name for each company and end the job.

- For ARMS/400, send a data queue entry to DQ4200RB to end the A4200RB (ARMS/400 pseudo sender) NEP.

Process

Hierarchical numeric ID: 1.1.4.1.3.6

Coded name: DQ4200RB

Name: DTQ Input for ARMS/400 Application (DQ4200RB)

Comment: ©Definition: This is the input data queue to the pseudo sender for

ARMS/400, program A4200RB that simulates sending to the ARMS/400 customers.

Process

Hierarchical numeric ID: 1.1.4.1.4 Coded name:

Name: ONL Reroute Unsolicited Authorizations Comment: ©Definition:

To activate the rerouter job for any unavailable machine.

©Operational Method:

When a production machine goes down, the ARMS OnCall staff is notified and then the OnCall staff manually submits this job to reroute or hold any transactions that were meant for that machine.

. _^ . ©Note:

- Runs on RARMS only

Process

Hierarchical numeric ID: 1.1.4.1.4.1 Coded name: AMREROUTE

Name: PGM Submit ARMS Rerouter (AMREROUTE) Comment: ©Definition:

This is a batch process triggered manually as a result of a distributed production machine that has been abnormally shut down to allow for certain transactions that would have been routed to that machine to instead be routed to CLAIMS CONNECTION and the remainder of the transactions intended for that machine to be held for later processing.

©Purpose:

To allow Enterprise a means of fulfilling contractural ARMS obligations in event .of a distributed machine failure.

Confidential Page 197 of 246 8/11/00 ARMS Process Report

©Operational Method:

- Submits the AMREROUT never-ending program with all of the necessary values.

©Files : None

Process

Hierarchical numeric ID: 1.1.4.1.4.2

Coded name: AMREROUT

Name: PGM Reroute Transactions for Unavailable Machine (AMREROUT)

Comment: ©Purpose:

To handle transactions that are bound for a machine that is unavailable so that the transactions are not lost. If the transactions are new authorizations, someone needs to attend to them as most trading partners have agreements with Enterprise to respond to customer authorization requests within a specified time interval .

©Operational Method:

IF the received transaction set is an unsloicited authorization add (AT) ;

- Call AMIOIOVI to update the XREF with Machine & Source Id, update the AMAPP record and route to Claims Connection

IF the received transaction set is an authorization change (AT-C) OR a cancellation (CN) , and the Source or Machine from the APPDOl doesn't match that found in the XREF;

- update the AMAPP record and route the transaction to Claims Connection

ELSE

- route to hold data queue.

At SHUTDOWN, reroute all held transactions to the production machine that went down. ->

©Files :

- AMAPPS (-RU-.)

- MACHIDENPF (-R—)

Process

Hierarchical numeric ID: 1.1.4.1.4.3

Coded name: DQAMAPH

Name: DTQ Hold Unavailable Machine Transactions (DQAMAPH)

Comment: ©Definition: DQAMAPH is a data queue used during reroute for holding all transactions that are not unsolicited AT-Adds (which are routed to CLAIMS CONNECTION) for the affected machine which is down, and then at reroute shutdown for the that machine these entries are then used as input to allow for their normal processing.

Process

Hierarchical numeric ID: 1.1.4.2

Coded name:

Name: SA Research and Fix Problems

Confidential Page 198 of 246 8/11/00 ARMS Process Report

Comment: ©Definition: The activity to handle any problems that are reported via a page, a phone call or an MSOl message. It also involves daily tasks to examine exceptions and fix them or to create issues if they can not be fixed.

Process

Hierarchical numeric ID: 1.1.4.2.1 Coded name:

Name: MAN Respond to On-Call Message Comment : ©Purpos :

To research and determine how to solve a problem that was notified via a pager, a phone call or an MSOl message.

©Operational Method:

- The On-Call staff (primary and backup) are notified in the following situations :

1) ARMS job's program halt or termination via pager message to investigate why and to respond and possibly resubmit job for never-ending program (NEP) execution.

2) ARMS transaction set transmission being rejected for processing by an ARMS NEP job via a pager message and/or via e-mail (currently MSOl) .

- The primary only On-Call staff is notified by ARMS Rental Management Trading Partner technical contact of their host system availability or connect problems or for transaction research for a perceived problem via pager message

(8063) . The contact actually dials in (314) 512-ARMS and is appropriately directed via four options :

1 - Enterprise Rental Branch Personnel

2 - Questions about Vehicle Messaging System

3 - Insurance Company Contacts

4 - Other

The primary only On-Call staff is also notified by the ARMS Programming Help Desk, staff via pager message (8064) of problems where they need further assistance.

- To retrieve the 8063 and 8064 mail box messages, perform the following steps : i) Dial phonemail - x2696 ii) When asked, enter the mailbox number from the pager (8063 or 8064) and the password iii) After listening to the message, always save it iv) Call the concerned party and always keep .them apprised of the status of the investigation.

©Notes:

A top priority is to resubmit/restart any abended ARMS NEP job to ensure transaction data flow throughput between the trading partners and the rental systems. Another high priority is to notify ARMS Technical to contact all affected trading partners of any communication termination occurrences that are estimated to be longer that thirty (30) minutes in duration. Likewise, they are also to be notified of any similar delays of transaction throughput. A lower priority is to research the cause of any transaction being rejected or causing program halt/termination, correct and resubmit the transaction.

Confidential Page 199 of246 8/11/00 ARMS Process Report |

Process

Hierarchical numeric ID: 1.1.4.2.2

Coded name:

Name: MAN Perform Daily Exception Checks (Checklist)

Comment : ©Purpos :

To use the check list and perform daily tasks that have been identified as routine to make sure that the application processes any exceptional transactions.

©Operational Method:

- If any printed detail lines exist on the ARMS Cross-Reference Discrepancy Reports spooled file in the ARMSRPTS output queue on the RARMS centralized host platform, print the reports. Then research all ARMS activity to- date of the rental transaction via the ARMS Time-Line Inquiry (CCAM16) and the ARMS centralized database report (AM0800) . Manually correct the files' records or generate the necessary transaction set for the needed group type.

- Display the RARMS host platforms distribution data queue (DQAMAPl) to determine if there is any old (older than today's date) or hung transaction that has never been sent. Research the associated transaction set's transmission and data queue entry for invalid host system platform ID value. Correct and reprocess if necessary.

- Display the distributed rental systems' host platforms ARMS Application Interface Transaction Set file (AMAPP) , the ARMS Format Generation Dispatcher In- Progress Transaction Control File (AMTRNCTL) , and all distributed ARMS application system data queues (DQAM6AV1, DQAM6BV1, DQAM60V1, DQAM61V1, and DQECATVl) to determine if there is any old (older than today's date) or hung transaction that has never been processed. Research the associated transaction set's transmission and data queue entry (along with the existing rental contract transaction) for invalid rental contract IDs values or status. Correct and reprocess if necessary.

- Check the spooled print file archive system's spooled file for the latest J340X Daily Rental Billing Job runs' Billing Exception Report for rejects due to ARMS status code or missing ARMS Cross-Reference file record error message. If any exist, note the rental location and contract ID. Research all ARMS activity to- date of the rental transaction via the ARMS Time-Line Inquiry (CCAM16) and the ARMS centralized database report (AM0800) . Manually correct the files' records or generate the necessary transaction set for the needed group type.

- Check if any printed detail lines exist on the query reports from last execution of job AML900 in two spooled files in the ARMSRPTS output queue on the RARMS centralized host platform, print the reports. Then research all ARMS activity to-date of the rental transaction via the ARMS Time-Line Inquiry (CCAM16) and the ARMS centralized database report (AM0800) . Manually correct the files' records or generate the necessary transaction set for the needed missing opening "RN" group type.

- Every weekday morning, change the centralized Job Monitor switch (on CENTRAL) for the ARMS On-Call Pager to "YES" so that ARMS On-Call pagers will be immediately sent notification messages of any ARMS job halts or abends.

- Every business weekday afternoon around 4:00pm, except the last business day of the week, change the centralized Job Monitor switch (on CENTRAL) for the ARMS On-Call Pager to "NO" so that ARMS On-Call pagers will NOT be sent

Confidential Page200of246 ^'■ 8/11/00 ARMS Process Report notification messages of any ARMS job halts or abends. These notification pager messages will be sent instead to the Operations On-Site Pager.

Process

Hierarchical numeric ID: 1.1.4.2.3

Coded name:

Name: MAN Research and Resolve Network Problem Ticket

Comment : ©Purpose:

To research and resolve and problem for which a network ticket has been created by the technical support center.

©Operational Method:

- Any time a Network Problem Ticket is passed to the Technical Support Center's Programming Help Desk (TSC-PHD) staff require further research and/or suggestions on correcting a deficient transaction situation with a rental transaction that had been processed through ARMS, then they call the ARMS Technical Support Line that generates an "8064" mailbox pager message to indicate the Application Development Department primary on-call person that a new voice mail message has been placed into the "8063" mailbox. The on-call person will listen to the voice mail message and then contact the caller to discover more details that might aid in their research. Then the on-call person (or can pass the task to the backup on-call if the primary has no time available for such a task) does the research into the problem and reports back to the caller the necessary intervention that the on-call person, TSC- PHD person. Rental Systems Help Desk staff, rental user, or trading partner system user must perform to correct the deficient situation.

Process

Hierarchical numeric ID: 1.1.4.3

Coded name: '^■. " >•

Name: SA Information System Reports

Comment: ©Definition: The activity that prints the various reports provided for in the ARMS application. The reports are as follows:

- Insurance company referral closed rental contracts revenue

- Management report for direct billed invoices

- Month-end ARMS youthful drivers surcharge discount report

- ARMS transaction exception report

- Reservation detail by company utilization management report

Process

Hierarchical numeric ID: 1.1.4.3.1 '.

Coded name: CLJ470

Name: BAT Print Insurance Company Referral Closed Rental Contracts Revenue Reports (CLJ470)

Comment: ©Definition: The batch process for printing of various Insurance reports, as specified in the Operational method and run on the Query machine. Thie process is triggered by TIME.

©Purpose: To report on various ARMS and Rental data in support of the Marketing function.

©Operational Method:

Confidential Page 201 of 246 8/11/00 ARMS Process Report

- Print Insurance Referral Report of Gross Revenue

- Print Insurance Referral Report of Income

- Print Bill-To Customer Report by Group

- Print Referral Reports by State (Gross and Net Revenue)

- Print Bill-To Customer Report by state

©Files: (CRUD) (Unless noted, all files used reside on QUERY system)

- OFFDRB (-R-)

- IR470P (-R—) (on CENTRAL system)

- INSRMOYR (-RU-) (on CENTRAL system)

- INSRMOYR (CRU-)

- INSRGGP (-R—) (on CENTRAL system)

- INSRGGP (CR-D)

- INSRRPHD (-R-) (on CENTRAL system)

- INSRRPHD (CR-D)

- RACCLSC (-R-)

- RACCLS01 (-R—)

- RACCLS02 (-R—)

- RACCLS03 (-R-)

- RACCLS04 (-R—)

- RACCLS05 (-R—)

- RACCLS06 (-R-)

- RACCLS07 (-R—)

- RACCLS08 (-R—)

- RACCLS09 (-R—)

- RACCLS10 (-R—)

- RACCLS11 (-R—)

- RACCLS12 (-R-)

©Notes :

These reports are confidential and are used by the Rental Operations - National Marketing Departement staff.

Process

Hierarchical numeric ID: 1.1.4.3.2

Coded name:

Name: BAT Transaction Credit Discount

Comment: ©Definition: The batch process for printing the month end transaction credit report. - _, ^'

©Purpose: For ARMS Technical Management and Rental Operations National Marketing Department staff to compute ARMS utilization for any transactions credit rebate checks sent to the Rental Management Trading Partner from closed direct billing payment authorized rental contracts.

©Notes:

Report is used by ARMS Technical Management and Rental Operations National Marketing Department staff to compute ARMS usage for any transactions credit rebate checks sent to the Rental Management Trading Partner.

Confidential Page 202 of 246 8/11/00 ARMS Process Report

Process

Hierarchical numeric ID: 1.1.4.3.2.1

Coded name: AML968A001

Name: PGM Create Missing OUTQs for Credit Transactions Report (AML968A001)

Comment: ©Purpose:

To create missing output queues on the RARMS machine at the beginning of the Credit Transaction Report driver job (CLL968) program so it can complete normally.

These output queues are named: Pgg, PggPC, or PggrPC where "gg" is the Group ID and "r" is Region ID and are created in library QUSRSYS using the CRTOUTQ command with default parameters except for the OUTQ name.

©Operational Method:

Repetitively read through Office Directories Group Master File by GROUP ID (file OFFDG#2) .

For every record read, do the following only IF the record's GROUP ID field value is not equal to '76' (Claims Connection) AND the GROUP ID field value is equal to the GROUP'S OUTPUT QUEUE NAME:

- IF the record's Distributed Printing Capable indication field is 'Y¹ (Yes - a PC printer output queue is located at this Group adminstration office) , then check if that Group's PC output queue name ("PggPC" - where "gg" is the Group ID) ^• exists on this platform. IF is does not exist, then create the missing personal computer (PC) output queue (OUTQs) for this Group Administrative office.

- ELSE (Yes - a PC printer output queue is NOT located at this Group adminstration of ice), then check if that Group's normal output queue ("Pgg" - where "gg" is the Group ID) exists on this platform. IF is does not exist, then create the missing normal peripheral output queue (OUTQs) for this Group Administrative office.

- IF the retrieved record's Regionalized indication field is 'Y' (Yes - this Group is administrated by other regional adminstration offices) , then execute the ARMS Retrieve Regions for Office Group (AML968A002) program, passing two parameters. This first is the input parameter of the current record's GROUP ID. The second parameter is the blanked 132 element, 1 character output parameter of a Region ID array of all regions that are part of a Group office. Then, looping through each non-blank array element, check if the Regional Office's of the Group personal computer output queue name ("PggrPC" - where "gg" is the Group ID and "r" is the Region ID) exists on this platform. IF is does not exist, then create the missing personal computer (PC) output queue (OUTQs) for this Group's Regional Administrative office.

©Files : (CRUD)

OFFDRGRPPF (-R—) Office Directories Group Master File (by Group ID, using logical access path OFFDG#2) .

Process

Hierarchical numeric ID: 1.1.4.3.2.2

Confidential ^' Page 203 of 246 8/11/00 3%

ARMS Process Report

Coded name: AM1081V1 ^—

Name: PGM Print Detail and Summary Transaction Credit Reports (AM1081V1) Comment : ©Purpose:

To print ARMS Transaction Credit summary and detail reports by Trading

Partner.

©Operational Method:

Positions and reads the ARMS Transaction Credit Transaction History (AMTRNCR) file records whose Year and Month Approved for Payment/Rental Closed correspond to the previous month/year from the current system date.

This physical file's indexed/keyed access path is sequenced by:

Year Approved for Payment or Rental Closed

Month Approved for Payment or Rental Closed

Trading Partner Profile ID

Group ID

Region ID

Branch ID

Ticket ID Number (of closed rental contract)

Regionalized the Transaction Credit summary report. This report matches the report that is sent to the Group output queues except that it includes total information for branches within a region and total information for the region itself, but does not include Group total information.

A total line to the Transaction Credit Detail report exist just for ARMS Trading Partner Insurance Company. The total will be the sum of the transaction credit and the utilization fee.

(If there is a Trading Partner with no utilization fee, this total line will not print . )

The hierarchy of breaks are: Trading Partner Profile Group Region Branch

Accumulate Branch, Region (if applicable) , Group and Trading Partner

Totals for:

Total Count of (Rental Contracts) Tickets Closed (Managed via ARMS) Total Insurance Charged Extended Daily Rental Rate Revenue Amount of (Rental Contracts) Tickets Closed (Managed via ARMS)

Total Transaction Credit (Discount) Amount (to be rebated) Total (ARMS) Estimated Utilization Fee Amount

Print detail report lines . (used for auditing when necessary)

Print report break totals on detail and summary report printer files.

Page breaks on: Trading Partner Profile ID or GROUP ID changes.

©Files: (CRUD)

AMTRNCR (-R—) ARMS Transaction Credit transaction history file

ARMSPR7 (-R--) ARMS Trading Partner's Transaction Discount

Volume Break Control Levels

Confidential Page204 of246 8/11/00 ARMS Process Report

ARMSPR2 (-R--) ARMS Trading Partner's Customer Address Data

OFFDRGRPPF (-R—) Office Directories Group Master File, by GROUP ID (using the OFFDG#2 logical access path)

QSYSPRT (C ) System Default PRINTER FILE for Detail Report by

GROUP ID, REGION ID, and BRANCH ID

QSYSPRT2 (C ) System Default PRINTER FILE for Summary Report by

GROUP ID, REGION ID, and BRANCH ID

QSYSPRT3 (C ) System Default PRINTER FILE for Detail Report by

GROUP ID, REGION ID, and BRANCH ID for the Group Administration Office Output Queue

QSYSPRT4 (C ) System Default PRINTER FILE for Detail Report by

GROUP ID, REGION ID, and BRANCH ID for the Regional Administration Office Output Queue

©Embedded Data/Constants :

Program Constants:

^■GROUP SUMMARY - FINAL TOTALS'

'UTIL FEE $•

'UTIL FEE'

•UTIL %•

'TOTAL'

** CMD - Commands To Be Executed OVRPRTF FILE(QSYSPRT3) OUTQ (QPRINT) OVRPRTF FILE(QSYSPRT3) OUTQ (PggPC) OVRPRTF FILE(QSYSPRT3) OUTQ (Pgg) DLTOVR FILE(QSYSPRT3) OVRPRTF FILE(QSYSPRT4) OUTQ (PggrPC) DLTOVR FILE(QSYSPRT4)

** Month Names for report column headings.

JANUARY

FEBRUARY

MARCH

APRIL

MAY

JUNE

JULY

AUGUST

SEPTEMBER

OCTOBER

NOVEMBER

DECEMBER

©Notes :

Utilization fee is the amount paid by Enterprise to the customer for sending rentals using ARMS as specified in the contract with the company. For ARMS TRADING PARTNER INSURANCE COMPANY, currently they are paid a utilization fee of 1.8 % of any revenue generated via ARMS that is over 55 million.

The report is broken down by group and branch so that corporate can recover these fees from the appropriate group-branch based on the revenue that each branch genrated via ARMS.

Confidential Page 205 of 246 • 8/11/00 ARMS Process Report

©Improvement Opportunities :

Convert program from OPM to ILE.

Remove the compile-time array for the months' names and replace with the logic to execute a built-in function utility or service program that you can pass the date and the month name will be returned as output.

After having printed and saved the spooled printer files, if specified, then move the spooled files to another specific output queue for interception for archival by the Broderick Spool Archival utility software system. This would prevent the need for any reruns for the sake of a reprint.

Move the logic that provides the month and year values to select records for reporting from this program to the calling program, CLL968, and pass the derived last month's month and year as input parameters to this program. This would enable rerunning this program for a different past month that data was still retained online.

Optimum: Capture and retain all necessary information in a revised closed rental contracts file and use this type report over any closed rental contracts files by a past month and year for any rerunning.

Process

Hierarchical numeric ID: 1.1.4.3.2.3

Coded name: AML968A002

Name: PGM Retrieve Regions for Office Group (AML968A002)

Comment : ©Purpose:

To return all associated Region IDs for a given Group ID so that the AML968A001 program can check if the regional administrative office's personal computer output queue exists on the current platform and if not existing, create them prior to the execution of the Transaction Credit Report (AM1080V1) program.

©Operational Method:

This program accepts two parameters, the first is the input 2 character GROUP ID. The second is the 132 element, 1 character each output REGION ID LIST array.

Starting at the first record in the Office Directories Branch Of ice Master File for the passed GROUP ID, read every record for this passed GROUP ID value until it changes or is end-of-file, do the following for each associated record retrieved:

- IF the REGION ID is NOT blank, then load the next available REGION ID LIST array element.

End the program and return the loaded REGION ID LIST array to the calling program.

©Files : (CRUD)

OFFDRB (-R—) Office Directories Branch Office Master File, by Group ID, Region ID, Area ID & BranchID (via OFFDRB7 logical access path) .

Confidential Page 206 of246 8/11/00 ARMS Process Report

©Improvement Opportunities:

Condition loading the array only after checking to ensure that the retrieved OFFDRB7 file's non-blank REGION ID field value is different than the last loaded value, since the file access sequence is in GROUP ID and REGION ID ascending order. This will avoid loading the array with repeating values. Likewise, the 132 element REGION ID LIST array would not need the maximum of 132 and could be reduced to a smaller size such as the 94 characters (upper and lower case alphabetic, numeric, and special characters) that exist on the computer terminal's keyboard.

Process

Hierarchical numeric ID: 1.1.4.3.2.5

Coded name: CLL968

Name: PGM Drive Transaction Credit Discount Report (CLL968)

Comment: ©Purpose:

To print summary and detail reports, by Rental Management Trading Partner companies, of ARMS authorized transactions count and amounts that became closed authorized rental contracts and include the amount electronically invoice billed, excluding government taxes and surcharges.

These reports assist ARMS Technical Management and Rental Operations National Marketing Department staff to compute amount of ARMS utilization by Rental Management Trading Partner so that appropriate rebate checks may be sent to the trading partner.

©Operational Method:

Determine the current emulated or real hardware platform upon this program is executing.

IF the current hardware platform is "RARMS", then do the following:

Override the default system printer files QSYSPRT and QSYSPRT2 to have the attributes of COPIES set to 2.

Execute the ARMS Create Missing Output Queues for Credit Tranactions Reports (AMLOOIAOOI) program.

Execute the ARMS Print Detail and Summary Transaction Credit Reports (AM1080V1}- program.

©Notes:

Submitted for execution from ROBOT/Scheduler as "L968C05" every month on the fifth calendar day of the month only on the RARMS system.

Report is used by ARMS Technical Management and Rental Operations National Marketing Department staff to compute ARMS usage for any transactions credit rebate checks sent to the Rental Management Trading Partner.

Process

Hierarchical numeric ID: 1.1.4.3.3

Coded name: CLL 80

Name: BAT Print Management Report for Direct Billed Invoices (CLL480)

Comment: ©Purpose:

Confidential Page 207 of 246 8/11/00 ARMS Process Report

To report on various ARMS and Rental data relating to direct billed invoices in support of the Marketing function.

©Operational Method:

- Prints or sends to National Marketing representative (via FTP) the Rental Management Trading Partner Company Generic Insurance Direct Billed Report, for Selected Customers or a set of standard Branch Claims Office Customer Numbers.

©Files : (CRU

- INSRL480 (-R- -)

- IR002P (CR-D)

- IR003P (CR-D)

- OFFDRB (-R- --)

- RACCLSC (-R—)

- RACCLSOl (-R—1

- RACCLS02 (-R--

- RACCLS03 (-R—]

- RACCLS04 (-R--

- RACCLS05 (-R—

- RACCLS06 (-R-

- RACCLS07 (-R—

- RACCLS08 (-R—

- RACCLS09 (-R—

- RACCLS10 (-R—

- RACCLS11 (-R—

- RACCLS12 (-R—

©Notes :

These reports are confidential and are used by the Rental Operations - National Marketing Department staff.

FTP process - Reports being downloaded are written to members in file IR002P. The names of these members are written as records in file IR003P. Program. IR_018M is then called by CLL480 to send the data to the internet location. IR_018M is made of 4 modules: CL IR_018M001 which calls IR_018M002 (BUILDER) to build the FTP copy commands (one per member) and to separate the members in IR002P into files in library QTEMP (module IR_018M004 does this piece) and then calls IR_018M003 (CHECKER) to read the FTP log to see if errors occurred. A batch job then runs on the internet location which checks for data in the appropriate directory and, if data exists, creates an executable that appears on Cindi Loomis of National Marketing's PC desktop. This batch job runs hourly Monday through Friday during normal business hours. There will be one executable for each downloaded file. When Cindi selects these, they are copied to diskette.

Process

Hierarchical numeric ID: 1.1.4.3.4

Coded name:

Name: BAT Youthful Drivers Surcharge Discount Report

Comment: ©Purpose: The batch process of generating and printing the month end management report that deals with youthful drivers surcharge discounts

©Notes:

Distributed to Mary Mahoney, Rental Operations - National Marketing Departmment Assistant Vice President

Confidential Page 208 of246 8/11/00 ARMS Process Report

Process

Hierarchical numeric ID: 1.1.4.3.4.1

Coded name: AM1087V1

Name: PGM Generate Youthful Drivers Surcharge Discount Report (AM1087V1)

Comment : ©Purpose:

To generate youthful drivers surcharge discount report.

©Operational Method:

- Print ARMS Youthful Driver Approved Surcharge Discount Detail Report by Group/Branch.

- Print ARMS Youthful Driver Approved Surcharge Discount Summary Report by Group.

- Print Exception Report of ARMS Transaction Credit Discount Records with closed rental contract (ticket) file record not found.

©Notes :

This report is used by National Marketing to determine discount benefit levels. Essentially, if the underage driver surcharge is not paid by the trading partner, it a discount for them and this report lists the actual discount amounts by trading partner.

This report is currently hard coded to be produced only for ARMS TRADING PARTNER INSURANCE COMPANY. The surcharge amount used for calculating the discount is $5.00 per day per qualified rental. Any rental in AMTRNCR is qualified. The number of days for the rental is calculated from information retrieved from the closed ticket files on the QUERY machine.

Process

Hierarchical numeric ID: 1.1.4.3.4.2

Coded name: CLL987

Name: PGM Setup Youthful Drivers Surcharge Discount Report (CLL987)

Comment: ©Purpose:

To prepare the environment and run the program to generate the youthful drivers surcharge discount report.

©Operational Method:

1) Retrieve the current date and construct the REPORT DATE in format CYYMMDD using the previous month with the appropriate century and year.

2) Retrieve the machine name.

- If currently running on centralized ARMS host, retrieve the QUERY machine status If DDM is not available.

Submit the job so that when the machine is available, the job can be released by operations

Confidential Page209 of246 8/11/00 ARMS Process Report

Else

Return.

3) Change the printer file attributes so that 2 copies are generated for each report.

4) CALL program AML1087V1 with the REPORT DATE as the parameter.

5) Return

Process

Hierarchical numeric ID: 1.1.4.3.5

Coded name:

Name: BAT Cross-Reference Exception Reports

Comment: ©Definition: This is a batch process that generates a report of the discrepancies that exist in the ARMS XREF files between the centralized machine and the distributed computer platforms.

©Purpose: To maintain and keep the centralized and distributed XREFS in synch.

©Notes :

Reports used by the ARMS On-Call staff on daily basis for research and possible manual intervention to fix or resynchronize the centralized and distributed ARMS Cross-Reference database files.

Process

Hierarchical numeric ID: 1.1.4.3.5.1

Coded name: CLL749

Name: PGM Consolidate Transaction Data (CLL749) • "

Comment : ©Purpose:

To set up the environment and run the program to generate the cross- reference, discrepancy report.

©Operational Method:

- When on the centralized host machine:

1) Check all distributed computer platforms that are ARMS active - defined in system list ACTVARMS, for DDM availability.

If all computer platforms are not available end the program.

2) For each distributed host system that is included in ACTVARMS system list, copy the cross-reference file to the centralized host machine, where it is consolidated into ZAMXREF.

- When on the DEVelopment machine:

1) For each simulated (dummy DDM) distributed file that is ARMS active - defined in system list ACTVARMS, copy the cross-reference file to the consolidated file, ZAMXREF.

- If not on either of the above mentioned host computer platforms, send program message 'YOU ARE NOT ON THE DEV OR RARMS MACHINE, PROGRAM CLL749 ENDING' .

Confidential Page 210 of 246 8/11/00 ARMS Process Report

- Check if there are any records accumulated in ZAMXREF.

If there are no records, send message 'THERE WERE NO RECORDS TO PROCESS, PROGRAM CLL749 ENDING' Else

Override to print to output queue ARMSRPTS

CALL program AM0749 to compare the cross references and generate the discrepancy report.

- Return

Process

Hierarchical numeric ID: 1.1.4.3.5.9

Coded name:

Name: RPT Exception of Discrepancies Between Centralized Cross-reference and

Distributed

Comment: ©Purpose:

Report use by the Application Support Staff for the sake of keeping the database in synch.

©Report Distribution:

No automatic distribution. The staff on call has to go to the output queue ARMSRPTS to retrieve the report.

Process

Hierarchical numeric ID: 1.1.4.3.5.11 Coded name: AM07 9

Name: PGM Print Discrepancies Between Centralized Cross-reference and Distributed (AM0749) Comment : ©Definition: j,ι This is a batch process that generates the ON-CALL report of discrepancies that exist in the ARMS XREF files between the centralized machine and the distributed manchines.

©Purpose:

To maintain and keep the centralized and distributed XREFS in synch.

©Operational Method:

- Process the data in the consolidate file against the data in the centralilzed file. Each record will fall into one of the following categories:

1) Record(s) exist on the distributed system only.

2) Record(s) exist on the centralized system only and no error associated with the transaction.

3) Record(s) exist on both centralized and distributed system, but data not in synch.

- Print the three reports.

Process

Confidential Page 211 of 246 8/11/00 ARMS Process Report

Hierarchical numeric ID: 1.1.4.3.7

Coded name:

Name: BAT Added 'I'nsuranσe Customer

Comment: ©Definition: This activity generates the report listing all the insurance type customers that were added to file CUSTMAST using customer maintenance program

AACM07 since the report was last generated.

Process

Hierarchical numeric ID: 1.1.4.3.7.1

Coded name: CLL010

Name: PGM Generate Report of Added Insurance Customer (CLL010)

Comment : ©Purpose:

To set up the environment and invoke the program to generate a report listing all the insurance type customers that were added to file CUSTMAST using customer maintenance program AACM07 since the report was last generated.

©Operational Method:

- Consolidate the data (file CIADDS) from all distributed computer platforms on to the financial application system's host platform and then generate a report from the consolidated data.

Process

Hierarchical numeric ID: 1.1.4.3.7.8 Coded name:

Name: RPT Added ' I 'nsurance Customer Comment: ©Purpose:

To inform the user of all the insurance type customers that were added in the last week using program AACM07 (ECS Customer Maintenance) .

©Report Distribution:

Cindy Loomis

Process

Hierarchical numeric ID: 1.1.4.3.7.10

Coded name: IR0100

Name: PGM Print Weekly Report of Added 'I 'nsurance Customer (IR0100)

Comment: ©Purpose: . . ^' ■'

To generate the report of all the insurance type customers that were added in the last week using program AACM07 (ECS Customer Maintenance) .

©Operational Method:

1) Read through file LD010 (work file with consolidated data from file CIADDS on each machine) and write one detail line for each customer in this file to generate the report.

Confidential Page 212 of246 8/11/00 ARMS Process Report

Process

Hierarchical numeric ID: 1.1.4.3.12

Coded name:

Name: BAT Missing Open Rental Notification

Comment: ©Definition: A batch process that generates a discrepancy report of authorization and associated ticket that are linked yet not completely updated or in synch with the transaction cross-reference file.

©Purpose: To inform the application staff of contracts that are linked to authorizations yet do not contain the authorization information or are not in sync with the transaction cross-reference file.

©When all the pieces are in place the program is capable of generating the necessary request to ARMS to generate the opening rental notification.

Process

Hierarchical numeric ID: 1.1.4.3.12.1 Coded name: AML901A

Name: PGM Submit Report Program (AML901A) Comment: ©Purpose:

To submits the report program to generate missing RN report.

©Operational Method:

- Submit the job to call program AMZ001A to detect the missing opening RNs and generate the report for the on call staff to investigate.

©Notes:

- This program is called by a scheduled job (AML901A) in ROBOT at 2100 hrs.

Process , „

Hierarchical numeric ID: 1.1.4.3.12.2

Coded name: AMZ001A

Name: PGM Detect / Generate Missing Open Rental Notification Report (AMZ001A)

Comment: ©Definition:

A batch process that generates a discrepancy report of authorization and associated ticket that are linked yet not completely updated or in sync with the transaction cross-reference file.

©Purpose:

To inform the application staff of contracts that are linked to authorizations yet do not contain the authorization information or are not in sync with the transaction cross-reference file.

©Operational Method:

- For every ticket in the file RACMAST that is completely open i.e. CONTRACT DATE has a valid date, STATUS is blank, RMRNO (reservation number) is not blank and TYPE is • I ' :

Confidential Page213 of246 8/11/00 ARMS Process Report

1) Retrieve the reservation master file RACBRMST with the reservation number as the key and compare the ticket numbers in the two files:

CASE 1: If the ticket number in RACBRMST is = 999999, then ignore this ticket and go to the next ticket.

CASE 2: If the ticket number in RACBRMST is not equal to ticket number in RACMAST, then generate message "Ticket linked to Res, but Res points to different Ticket."

CASE 3: If the ticket numbers in the two files match, then: a) Retrieve supplemental ticket file RACSMAST. - If no record found, then go to next ticket Else

- If ARMS Flag in RACSMAST (RMARMS) and RACBRMST (BRARMS) both are blank, then go to the next ticket Else

- If the flags are different, then report message "Ticket and Res linked to each other, however ARMS Flags are different" Else call cross-reference retrieval program, - If call fails, report message

"cross-reference retrieval failed" Else use the following decision table.

- Cl : Xref found C2: Xref not found C3: Xref status = 'O'

C4: Xref status <> '0' and <> 'R'

C5: Xref status = 'R'

C6: Transaction exists in AMTRNCTL

C7: Transaction does not exist in AMTRNCTL

,„. If C2; report message "No cross-reference found" If Cl and C3, go to next ticket

If Cl and C4, report message "Cross-reference status not R" If Cl, C5 and C6, report message "Record exists in file AMTRNCTL" If Cl, C5 and C7; send the opening RN data queue entry and report message "Missing open RN sent to ARMS".

- When the program reports the first message it encounters based on the condition, the next step is to go to the next ticket.

Process

Hierarchical numeric ID: 1.1.4.3.12.3

Coded name:

Name: RPT Exception of Missing Open Rental Notification

Comment: ©Purpose: Synchronize the ECARS and ARMS database by reporting the inconsistency.

©Report Distribution: Not Defined.

Confidential Page 214 of 246 8/11/00 ARMS Process Report

Process

Hierarchical numeric ID: 1.1.4.3.13

Coded name:

Name: BAT Online Reporting Sync Report

Comment: ©Definition: A batch process that generates a discrepancy report for the

ARMS Online Reporting function. This looks at the data stored in file AM095P which is the primary file for the Online Reporting Screens and compares it with ARMS and

ARMS/400 detail files to determine if an out of sync condition exists and needs to be addressed.

©Purose: To inform the ARMS application staff of any out of sync conditions that might cause Trading Partner adjusters to see incorrect information on the Online Reporting screens.

©When: This process is run via ROBOT scheduling in the evening.

Process

Hierarchical numeric ID: 1.1.4.3.13.1

Coded name:

Name: PGM CL Wrapper for AMS530A (AML530A)

Comment: ©Purpose: This is a CL Wrapper used for the sole purpose of calling

AMS530A for creation of the Online Reporting Sync Report.

©Operational Method:

This program does an OVRDBF on file AM097P00 for blocking purposes, adds A4LIB to the library list, OVRPRTF of the report to OUTQ ARMSRPTS, CALLs the program AMS530A and when it returns clears the file AM097P00.

©Files: (CRUD) -AM097P00 (-R-D)

Process

Hierarchical numeric ID: 1.1.4.3.13.2

Coded name-: AMS530A

Name: PGM Online Reporting Sync Report Program (AMS530A)

Comment: ©Purpose: This program will look at transactions processed for that day and compare select values between ARMS/400 and ARMS looking for discrepancies. When a difference is found a detail line is written to the report for the use by Oncall personnel to use to be sure that the online report feature stays in sync with ARMS.

©Operational Method:

This program reads through file AM097P00 which is a transactional log created by AM0055V1. This file contains records for both ARMS and ARMS/400 customers and currently the Online Reporting is only used by ARMS/400 customers. Therefore a check is done by reading A4PRF1 to determine if this is a record for an ARMS/400 customer. IF not skip to the next record. If it is an ARMS/400 customer read the associated file record from AM095POO. If a record is found proceed with a sync check. Read the required detail files and those listed in the ©Files section. The following data elements are sync checked:

Customer Tran. ID

Branch Claims Office ID

Claim Number

Claim Type

Rental Status

Adjuster last and first name

Confidential Page 215 of 246 8/11/00 ARMS Process Report

Body Shop name

Rental start date

Rental close date

Rental termination date

Daily authorized rate

Number of days Authorized

Dollars covered per Day

Policy Maximum Dollars

Bill to % verify correctness of the Surcharge flag

IF Invoiced:

Total Charges

Total Amount Received

Billed Amount

Calculated filelds checked against AM095POO Number of days in Rental Number of days Behind Number of Extensions received

If any of the above mentioned fields are in an out of sync condition write a detail record to the Sync Report. Continue with the above process until the file AM097POO is at End of File.

©Notes: Currently the program only checks transactions that are at Open Rental status and is not processing the code for invoiced transactions.

©Files: (CRUD)

- A4XREFL7 (-R—)

- A4AUTD (-R—)

- A4RPRD (-R—)

- AMFDTBL <-R—)

- AM095P00 ⁽-R--J

- AM097P00 (-R—)

- A4SURD (-R—)

- A4PRF1 (-R—)

- A4IEBT (-R— )

- AMTIMELl (-R—)

- AMTRNLOG (-R—)

©Embedded Data/Constants

Surchgl ^■Flag is Yes'

Surchg2 'No A4SURD reσ. found'

Surchg3 'Surchg flag'

RntDysl 'Days in Rental'

RntDys2 'Value in AM095P is not'

RntDys3 'correct please verify'

Dysbhndl 'Rental Days Behind'

Dysbhnd2 'Value in AM095P is not'

Dysbhnd3 •correct please verify'

AdjName 'Adjuster Name'

NoXref ^■No A4XREF for this Tran'

Process

Hierarchical numeric ID: 1.1.4.3.13.3 Coded name:

Confidential Page 216 of 246 8/11/00 ARMS Process Report

Name: RPT Online Sync Report Comment:

Process

Hierarchical numeric ID: 1.1.4.3.14

Coded name:

Name: BAT Nightly Update Open Tickets for AM095P

Comment: ©Definition: A batch process that will update the ARMS Online Reporting database to keep select data elements such as number of days in rental current.

©Purpose: There exists several calculated fields in the database which would become incorrect if a nightly update did not occur. This process maintians the validity and integrity of this data. The file updated is AM095P.

©When: This process is run via ROBOT scheduling in the evening.

Process

Hierarchical numeric ID: 1.1.4.3.14.1

Coded name: AML520A

Name: PGM Nightly Update/Write Open Tickets (AML520A)

Comment: ©Purpose: To update all open tickets in the ARMS Online Reporting database file to show the correct number of days in rental and the number of days behind if the extension date has been passed. This will ensure that open rentals that do not have a transaction processed on a given day will be kept up to date.

©Operational Method:

- Retrieve a record from ARMS Online Reporting Detail File AM095P.

- Determine the total number of days in the rental by calculating the difference between todays date and the rental start date.

-IF the termination date is greater than zero, zero out the days behind. Otherwise., . the days behind^' will be equal to the total number of days in the rental less the number of authorized days.

-Update ARMS Online Reporting Detail File AM095P.

©Files: (CRUD) - AM0095P01 (-RU-) ©Embedded Data/Constants:

Process

Hierarchical numeric ID: 1.1.4.4 Coded name: Name: SA Tools

Confidential Page 217 of 246 8/11/00 ARMS Process Report

Comment: ©Definition: The activity that encompass the manual processes that are performed by various Application Support staff. These processes range from keeping the environment up and running, troubleshooting transaction problems, to requesting reports .

Process

Hierarchical numeric ID: 1.1.4.4.1 Coded name:

Name: ONL Generate Application Reports Comment: ©Definition:

This activity is performed by ARMS Help Desk and ARMS Technical for generating system utilization by Trading Partner and dailly billing error report.

Process

Hierarchical numeric ID: 1.1.4.4.1.1

Coded name:

Name: MNU ARMS Application Reports

Comment: ©Definition: see ONL Generate Application Reports

Process

Hierarchical numeric ID: 1.1.4.4.1.17

Coded name:

Name: ONL ARMS Reservation Detail by Company Utilization Management Reports

Comment: ©Definition: This activity provides the Application Support Staff the means to produce a utilization management report for a specific Trading Partner.

Process

Hierarchical numeric ID: 1.1.4.4.1.17.1

Coded name:

Name: ONL Utilization Management Report for Specific Trading Partners BCO (Opt -1)

Comment: ©Definition: Generate a report showing ARMS Trading Partners Utilization of the Automated Rental Management System for specific Branch Claims Office.

Process

Hierarchical numeric ID: 1.1.4.4.1.17.1.1

Coded name: AM0135

Name: PGM Print Cross - Reference Utilization Report (AM0135)

Comment: ©Purpose:

To print daily utilization report including total reservation, cancelled reservation and rentals, by Trading Partner.

©Operational Method:

- Read entire file printing those records that meet the date range supplied to the program.

Confidential Page 218 of246 8/11/00 ARMS Process Report

Process

Hierarchical numeric ID: 1.1.4.4.1.17.1.2

Coded name: AMS002A

Name: PGM Select Transactions by Trading Partner and BCO (AMS002A)

Comment: ©Purpose:

To select transactions from the cross-reference file, to report for a specified trading partner or branch claims office.

©Operational Method:

- Select those records that meet the date and status criteria.

Process

Hierarchical numeric ID: 1.1.4.4.1.17.1.4

Coded name: CLL003

Name: PGM Gather / Print Cross - Reference Statistical Report (CLL003)

Comment: ©Purpose:

To generate a statistical transactions report using the cross-reference file.

©Operational Method:

- Execute the process that selects those records that meet the criteria for the utilization report, program AMS002A

- Override printer file to outq ARMSRPTS.

- Execute the process that print the utilization report, program AM0135.

Process

Hierarchical numeric ID: 1.1.4.4.1.17.1.5

Coded name: AM0136

Name: PGM Display / Select Available Trading Partners Claims Office (AM0136)

Comment : ©Purpose:

To display a list of available claims offices from which the Application Support Staff can select from.

©Operational Method:

- Build a file / list of available Trading Partners-.

- When requested, display the filter allowing the user to select specific Trading Partners Banch Claims Office.

Process

Hierarchical numeric ID: 1.1.4.4.1.17.1.6 Coded name: CLL001

Name: PGM Gather / Print ARMS Reservation Detail Utilization Management Reports (CLL001)

Confidential Page219 of246 8/11/00 ARMS Process Report

Comment : ©Purpose:

To allow the "ARMS Technical" staff to monitor trading partner's usage of the ARMS system via a cross-reference report of authorizations approved through ARMS. The filter criterion can specify the trading partner profile (all BCO's, Branch Claims Offices) or particular BCO's within a profile

©Operational Method:

- Print a detailed report by Rental Management Trading Partner company of the current statistics of approved authorizations via ARMS.

©Files: (CRUD)

- AMXREF (-R--)

- ARMSPR2 (-R—)

- AMCLSTBL (-R—)

- AMAUTD (-R—)

- OFFDGRPPF (-R--)

- AMMNTLOG (-R--)

©Note: Used by ARMS Technical Manager to see increase or decrease in ARMS usage volume by each Rental Management Trading Partner.

Process

Hierarchical numeric ID: 1.1.4.4.1.17.2

Coded name:

Name: ONL Utilization Management Report for Trading Partner (Opt - 2)

Comment: ©Definition: Generate a report showing ARMS Trading Partners Utilization of the Automated Rental Management System.

Process

Hierarchical numeric ID: 1.1.4.4.1.17.2.1

Coded name: AMS003A

Name: PGM Select Transactions for a Trading Partner (AMS003A)

Comment: ©Purpose:

To select transactions from the cross-reference file based on certain criteria specified via a job file AML136JA.

©Operational Method:

- Select those records that meet the date and status criteria.

Process

Hierarchical numeric ID: 1.1.4.4.1.17.2.3

Coded name: CLL001A

Name: PGM Gather / Print Cross - Reference Statistical Report (CLLOOIA)

Commen : ©Purpose:

To set the environment and execute the programs that select transactions from the cross-reference file, and print the actual report.

©Operational Method:

Confidential Page 220 of 246 8/11/00 ARMS Process Report

- Execute the program to select the transactions specified by the user.

- Override the print file for the report generator

- Execute the program to print the utilization report.

Process

Hierarchical numeric ID: 1.1.4.4.1.18

Coded name:

Name: ONL Generate Report of Errors Sent by a Trading Partner on an Electronic

Invoice

Comment: ©Purpose: A process where the Application Support Staff can generate a list of all the sent electronic invoices that were rejected by the trading partner.

Process

Hierarchical numeric ID: 1.1.4.4.1.18.1

Coded name: CLL015

Name: PGM Generate Daily Billing Error Report (CLL015)

Comment : ©Purpose:

To control the generation of the daily billing error report.

©Operational Method:

- Execute the program to build the work file with the billing error information

- Execute the program to print the billing error report.

Process

Hierarchical numeric ID: 1.1.4.4.1.18.2

Coded name:

Name: PGM ARMS System Control (AAMAIN)

Comment: ©Definition: A single source driver for the entire ARMS System Control

'menu'. Allowing the Application Support Staff to maintain the ARMS environment;

Trading Partner profiles; application tables;

Process

Hierarchical numeric ID: 1.1.4.4.1.18.6 Coded name: AM5010

Name: PGM Construct Billing Error File (AM5010) Commen : ©Purpose:

To build a work file, selecting records according to the specified date range of error records received from the Trading Partners for sent invoices.

©Operational Method:

- Read entire received bill error file selecting those records that match the date range criteria.

- When a match is found retrieve the associated sent transaction.

Confidential Page 221 of 246 8/11/00 ARMS Process Report

Process

Hierarchical numeric ID: 1.1.4.4.1.18.7 Coded name: AM5015

Name: PGM Print Billing Error report (AM5015) Comment : ©Purpose:

To print a list of errors including comments received from the Trading Partner that fall in the specified date range.

©Operational Method:

- process the work file, print the transaction that rejected and why.

Process

Hierarchical numeric ID: 1.1.4.4.2 Coded name:

Name: SCR Work with Robot Scheduler (RBM) Comment: ©Definition:

This activity routes the ARMS on-call staff to the job scheduler main menu where inquiry about specific jobs can be made.

Process

Hierarchical numeric ID: 1.1.4.4.3 Coded name:

Name: ONL Work with Transaction Exception Comment: ©Definition:

This activity is performed by the ARMS on-call staff to be both reactive and proactive to data base discrepancies between the centralized ARMS system and distributed system as well as ARMS system and Rental system and ARMS/400.

Process

Hierarchical numeric ID: 1.1.4.4.3.1

Coded name:

Name: SCR Work with Job (LAMZ001A)

Comment: ©Definition: Provides the ARMS on-call staff an option for retrieving the missing rental notification report.

©Notes :

- This report is presently the proactive approach to the missing rental notification problem. The problem is the result of deficiencies in handling certain scenarios;

- Report is generated on the AEFIKLMNPSTWY host computer platforms.

Process

Hierarchical numeric ID: 1.1.4.4.3.2

Coded name:

Name: SCR Work with Job (AML900)

Confidential Page 222 of 246 8/11/00 ARMS Process Report

Comment! ©Definition: Provides the ARMS on-call staff an option for retrieving the discrepancy report between ARMS and Rental.

©Notes:

- This program runs a series of queries that compares the data found in the Ticket file to ARMS cross-reference, as well as the data found in the reservation file to ARMS cross-reference.

- The report based on the reservation file contains many of transaction that should not be include. This is the result of using the open ticket date on the reservation file instead of the contract date from the ticket.

- The report does show when two reservation points to only one ticket.

- Report is generated on the AEFIKLMNPSTWY host computer platforms.

Process

Hierarchical numeric ID: 1.1.4.4.3.3

Coded name:

Name: SCR Work with Job (L749)

Comment: ©Definition: Provides the on-call staff an option for retrieving the

ARMS cross-reference discrepancy report.

©Notes:

- Report is generated on RARMS machine.

Process

Hierarchical numeric ID: 1.1.4.4.3.4

Coded name:

Name: SCR Search for Spool Entries (DSPOLE)

Comment: ©Definition: Provides the ARMS on-call staff an option for retrieving the electronic billing error report that has been archived

©Notes:

- Report is generated on AEFIKLMNPSTWY host computer platforms.

Process

Hierarchical numeric ID: 1.1.4.4.3.5

Coded name:

Name: SCR Work with All Spooled Files (A4ERROR)

Comment: ©Definition: Provides the ARMS on-call staff an option for retrieving the discrepancy report between ARMS and ARMS/400.

©Notes :

- Report runs on RARMS only.

- Libraries A4LIB and ELPGMR required.

Process

Hierarchical numeric ID: 1.1.4.4.3.6

Coded name:

Name: SCR Work with All Spooled Files (A4XREF)

Confidential Page 223 of 246 8/11/00 ARMS Process Report

Comment: ©Definition: Provides the ARMS on-call staff an option for retrieving the report of ARMS/400 transactions at a sent status.

©Notes :

- Reactive approach for handling errors.

- Report runs on RARMS only. ■ ,

- Libraries A4LIB and ELPGMR required

Process

Hierarchical numeric ID: 1.1.4.4.3.7

Coded name:

Name: MNU ONCALL Reports

Comment: ©Definition: see ONL Work with Transaction Exception

Process

Hierarchical numeric ID: 1.1.4.4.4

Coded name:

Name: SCR Access ARMS/400 Software (A4000RMS)

Comment: ©Definition: This activity allows the ARMS on-call staff to access the

ARMS/400 software for researching problems.

©Notes: This access path to the ARMS/400 interactive system allows a user to see the screens and information in the same way that the adjuster or in-house Enterprise employee would. Further this was created initially for use by the Rental Management Services team headed by Jim Hillerman.

Process

Hierarchical numeric ID: 1.1.4.4.5 Coded name:

Name: ONL Perform ARMS Environment Maintenance Comment:... ©Definition:

This activity is performed by the ARMS on-call staff for managing the application environment (ARMS subsystem) .

Process

Hierarchical numeric ID: 1.1.4.4.5.1

Coded name:

Name: ONL Start Individual Trading Partner Communication Programs

Comment : ©Definition:

This activity is performed by the staff on call to select and re-start the communication programs for a given Trading Partner when they have abnormally ended.

©Notes :

- Runs on RARMS

Process

Confidential Page 224 of 246 8/11/00 ARMS Process Report

Hierarchical numeric ID: 1.1.4.4.5.1.1 Coded name: CCARMS

Name: PGM Select Company / Machine (CCARMS) Comment: ©Purpose:

To allow to select and return the selected Trading Partner send and/or receive detail to provide a way to re-start the communication programs for a given Trading Partner when they have abnormally ended.

©Operational Method:

- Display the list of computer platforms where ARMS can be started.

- For each machine selected, read the ARMS profile attributes for that trading partner and diaplay the send and receive and associated translator and mapper program START FLAGS for the user to select which programs to start.

- Return the flag values as selected by the user.

Process

Hierarchical numeric ID: 1.1.4.4.5.1.2

Coded name: AMSTARTR

Name: PGM Start Specific Trading Partner Send & Receive pgms (AMSTARTR)

Comment: ©Purpose:

To submit jobs to start the send and receive and associated programs for each Specified Trading Partner without a VAN in the profile file (ARMSPR3) .

©Operational Method:

- If the company id is passed, retrieve the communication program technical detail for the passed company id Else all companies programs to be started read the file ARMSPR3 (ARMS Technical Profile) sequentially and perform the following steps for each qualified company

,,,> - Based on the profile, the passed flags and some hard coded logic, submit jobs to start appropriate communication programs at appropriate scheduled times .

Process

Hierarchical numeric ID: 1.1.4.4.5.2

Coded name:

Name: ONL Start Transaction Distribution Programs for Specific (s) Machine

Comment: ©Definition: A tool which provides the Application Support Staff the means necessary to start the distribution program from the centralized host machine to the distributed host machine.

©Notes:

- Runs on RARMS

Process

Confidential Page 225 of 246 8/11/00 ARMS Process Report

Hierarchical numeric ID: 1.1.4.4.5.2.2

Coded name: DQAAARMS

Name: DTQ Selected Computer platforms with start Flags

Comment : ©Definitio :

This data queue is created by program AAMAIN in library QTEMP to retrieve the selected computer platforms and associated start flags. The computer platforms are selected in program CCARMS where the entries are sent to this data queue.

Essentially this data queue acts as a data area to communicate between the two programs AAMAIN and CCARMS.

Process

Hierarchical numeric ID: 1.1.4.4.5.3

Coded name:

Name: ONL Start the ARMS to Rental Systems Interfaces

Comment: ©Definition: A tool which provides the Application Support Staff the means necessary to start all of the ARMS to Rental Systems Interfaces for a single distributed host machine.

©Note:

- Runs on A,C,E,F,I,K,L,M,N,P,S,T,W,Y

Process

Hierarchical numeric ID: 1.1.4.4.5.3.1

Coded name: AMSTARTE

Name: PGM Start the ARMS - Rental System Interfaces (AMSTARTE)

Comment : ©Purpose:

To allow the user to start the rental system interface programs for a particular machine. ><

©Operational Method:

, .. - Submit jobs to start each of the ECARS interface programs.

©Notes: Interface include: EC/CCOOATVn, EC/CCOOCNVn, EC/CCOOEXVn, EC/CCOOACVn, EC/CCOORAVn, EC/CCOORCVn, EC/CCOOREVn, EC/CCOORNVn, EC/CCOOTRVn, ECOOCMVn, ECOOVMVn, CCOOINVn, AM0061Vn, AM0060Vn

Process

Hierarchical numeric ID: 1.1.4.4.5.4 ■ . • ^{■ '}

Coded name: WRKCFGSTS

Name: ONL Work with a Specific Trading Partner Communication Line (WRKCFGSTS)

Comment: ©Definition: A command that allows the Application Support Staff to display and work with the status of a Specific Trading Partner's communication line.

©Notes :

- Run on RARMS

Process

Hierarchical numeric ID: 1.1.4.4.5.5

Confidential Page 226 of 246 8/11/00 ARMS Process Report

Coded name: WRKLIND

Name: ONL Work with a Specific Trading Partner Communication Line Description (WRKLIND)

Comment: ©Definition: A command that allows the Application Support Staff to display and work with the line description of a Specific Trading Partner.

©Notes :

- Run on RARMS

Process

Hierarchical numeric ID: 1.1.4.4.5.6

Coded name: WRKHDWRSC

Name: ONL Work with Local Communication Resources (WRKHDWRSC)

Comment: ©Definition: A command that shows information about local communications resources on the system and the associated configuration objects, including all comunication IOPs, IOAs, and ports installed on the system.

©Notes :

- Run on RARMS

Process

Hierarchical numeric ID: 1.1.4.4.5.7

Coded name:

Name: ONL Work with the ARMS Subsystem (WRKSBSJOB)

Comment: ©Definition: A command that shows all jobs running in the Application

Specific subsystem (ARMS) .

©Note: Subsystem is the same on all computer platforms. Jobs running in the susbsystem differs from centralized host computer platforms to distributed host computer platforms to the Finanical Application systems host computer.

- Runs everywhere

Process

Hierarchical numeric ID: 1.1.4.4.5.8

Coded name: NΞWARMS

Name: ONL Start new Subsystem Program (NEWARMS)

Comment: ©Purpose: A command that allows the Application Support Staff to start a user specified, non-data required program.

©Notes : - Runs everywhere

Process

Hierarchical numeric ID: 1.1.4.4.5.9

Coded name:

Name: ONL Shutdown ARMS Environment for a Specific Computer platforms

Comment: ©Purpose: The process by which the ARMS Application Support Staff ends the processes running on a specific distributed computer platforms.

©Notes: This usually is the result of a computer platforms that is experiencing hardware difficulties and OPS is wants to bring it down.

Confidential Page 227 of246 8/11/00 ARMS Process Report

- Run on RARMS only

Process

Hierarchical numeric ID: 1.1.4.4.5.9.1 Coded name: AMSHUTDWNl

Name: PGM Send Shutdown Request (AMSHUTDWNl)

Comment: ©Purpose: The process where a shutdown request is sent by the ARMS on- call staff, for a specific distributed computer platforms, to end the manning ARMS environment .

©Operational Method:

- If running on the RARMS computer platforms, send data entry to DQAMAPl with the specified computer platforms prefix as the key.

©Notes :

- *DOWN00000000000000SD*DOWNl = Shutdown data queue entry.

Process

Hierarchical numeric ID: 1.1.4.4.5.10

Coded name:

Name: ONL Display the Number of Shutdown the Network Requires

Comment: ©Definition: Process by which the ARMS Application Support Staff can see the number of shutdown records the ARMS network requires before shutting down.

©Notes :

- The number of shutdown records is derived from the number of distributed computer platforms it is running on. Presently, the number is 14.

- DSPDTAARA AM001A

- Runs on RARMS only

Process

Hierarchical numeric ID: 1.1.4.4.5.11

Coded name:

Name: ONL Display the Number of Shutdown Network Received

Comment: ©Definition: Process by which the ARMS Application Support Staff can see the number of shutdown records the ARMS network has received.

©Notes:

-If note enough shutdown records have been received the on-call sta can generate the missing records to cause the ARMS network to shutdown.

**The most common cause for insufficient shutdown records happens when one of the distributed computer platforms is brought down at an unscheduled time.

- DSPDTAARA AM002A

- Runs on RARMS

Process

Confidential Page 228 of 246 8/11/00 ARMS Process Report

Hierarchical numeric ID: 1.1.4.4.5.12

Coded name:

Name: ONL Work with the ARMS Job Queue (WRKJOBQ)

Comment: ©Definition: Process by which the ARMS Application Support Staff can monitor the ARMS job queue.

©Notes :

- Run everywhere

Process

Hierarchical numeric ID: 1.1.4.4.5.13

Coded name:

Name: ONL Display the Number of any ARMS-connected VAN Receivers Started

Comment: ©Definition: Process by which the ARMS Application Support Staff can see the number of ARMS-connected VAN communication receiver jobs started.

©Notes:

- This count is usually 1. However, if a second receiver is started the data queue and file that the received transmissions are placed into is AMVNIOIT instead of AMVN1011.

- DSPDTAARA AM003A

- Run on RARMS

Process

Hierarchical numeric ID: 1.1.4.4.5.14

Coded name:

Name: ONL Display the Number of Transaction Translators Running

©Definition: The process by which the ARMS on-call staff can see the number of translators running. ■ <<

©Notes:

- This is important when shutting down the ARMS network normally. If the value in, not equal to zero then a translator is active and the ARMS network will NOT shutdown.

** If the translator was ended abnormally the count is not adjusted.

- DSPDTAARA DASDV1

- Run on RARMS

Process

Hierarchical numeric ID: 1.1.4.4.5.15

Coded name:

Name: MNU Work with ARMS Environment

Comment: ©Definition: see ONL Perform ARMS Environment Maintenance

Process

Hierarchical numeric ID: 1.1.4.4.6

Coded name:

Name : ONL Perform ARMS/400 Environment Maintenance

Confidential Page 229 of 246 8/11/00 ARMS Process Report

Comment: ©Definition:

This activity is performed by the ARMS on-call staff for managing the ARMS/400 application environment.

©Notes :

- Runs on RARMS only

Process

Hierarchical numeric ID: 1.1.4.4.6.1

Coded name:

Name: ONL Work with the ARMS/400 Subsystem (WRKSBSJOB)

Comment: ©Definition: A command that shows all jobs running in the Application

Specific subsystem (A4BAT) .

©Note: Subsystem only on RARMS

Process

Hierarchical numeric ID: 1.1.4.4.6.2

Coded name:

Name: ONL Work with the ARMS/400 Job Queue (WRKJOBQ)

Comment: ©Definition: Process by which the ARMS Application Support Staff can monitor the A4BAT job queue.

©Notes:

- Run RARMS only

Process

Hierarchical numeric ID: 1.1.4.4.6.3 • -^■/

Coded name: NEWARMS 00

Name: ONL Start new Subsystem Program (NEWARMS400)

Comment: ©Purpose: A command that allows the Application Support Staff to start a user spepified, non-data required program.

©Notes : - Runs RARMS only

Process

Hierarchical numeric ID: 1.1.4.4.6.4

Coded name: •

Name: MNU Work with ARMS/400 Environment

Comment: ©Definition: see ONL Perform ARMS/400 Environment Maintenance

Process

Hierarchical numeric ID: 1.1.4.4.7

Coded name: AAMAIN

Name: MNU ARMS Main Menu (AAMAIN)

Comment: ©Definition: A consolidated menu where by the ARMS on-call staff can find and access support tools needed to perform their daily activities.

Confidential Page230 of246 8/11/00 ARMS Process Report

©Notes : ^"

-Rental System Help Desk and ARMS Application Support Service use the menu.

- Tools are group into four main categories, with the further group into subcategories and so on based on their related functions:

- Reports

- Application

- On-call

- Applications

- Robot Scheduler

- ARMS/400

- Maintenance / Inquiry

- ARMS Environment

- Startup Controls

- Shutdown Controls

- Communication Status

- Other

- ARMS/400 Environment

- Transaction Log

- Data Queue

- Reservation/Ticket Information

- Purge Progress

- File

- Other

Process

Hierarchical numeric ID: 1.1.4.4.8 Coded name:

Name: ONL Inquire on Transaction Log Comment: ©Definition:

This activity is used by on-call and help desk when troubleshooting discrepancies between the Trading Partner and Rental Systems

Process

Hierarchical numeric ID: 1.1.4.4.8.1

Coded name:

Name: MNU ARMS System Control Transaction Log

Comment: ©Definition: see ONL Inquire on Transaction Log

Process

Hierarchical numeric ID: 1.1.4.4.8.11

Coded name:

Name: ONL Inquiry of Transactions Received from a Trading Partner

Comment: ©Definition: The process which allows the Application Support Staff to select specific transactions received from the Trading Partner's for inquiry.

Process

Hierarchical numeric ID: 1.1.4.4.8.11.1

Coded name: CCAM12

Name: PGM Transaction Receive Log Inquiry (CCAM12)

Confidential Page 231 of 246 8/11/00 ARMS Process Report

Comment : ©Purpose:

To allow the Application Support Staff to select specific transactions received from the Trading Partners for inquiry.

©Operational Method:

- Display a list of all the transmission received from specific Trading Partners.

- Upon the select of an individual transmission, display the control/data records the make up that transmission.

Process

Hierarchical numeric ID: 1.1.4.4.8.12

Coded name:

Name: ONL Inquiry of Error Transactions Sent by Trading Partner

Comment: ©Definition: A process where the Application Support Staff has the ability to view error transactions sent by Trading Partners.

Process

Hierarchical numeric ID: 1.1.4.4.8.12.1 Coded name: CCAM13

Name: PGM Receive / Billing Error Inquiry (CCAM13) Comment: ©Purpose:

To display either the billing errors received from the Trading Partners or the non - billing errors. This is helplful for troubleshooting.

©Operational Method:

- Based on the parameter passed to the program open either the received error log file or the billing error log file.

- Read all records from the file, displaying the records on screen.

- Upon the selection of an individual transmission, display the error code received.

Process

Hierarchical numeric ID: 1.1.4.4.8.13

Coded name:

Name: ONL Inquiry of Transaction sent by the Trading Partner but Erred / Rejected

Comment: ©Definition: The process where the Application Support Staff can display the errors that have been sent to the Trading Partners.

Process

Hierarchical numeric ID: 1.1.4.4.8.13.1

Coded name: CCAM14

Name: PGM Error Log Inquiry (CCAM14)

Confidential Page 232 of 246 8/11/00 ARMS Process Report

Comment : ©Definition: The process where the Application Support Staff can display the errors that have been sent to the Trading Partners.

©Purpose: Used in trouble shooting problems

©Operational Method:

- Display a list of the errors received by Enterprise from a specific Trading Partner.

- When a specific transmission is selected, display the data records associated with that transmission.

Process

Hierarchical numeric ID: 1.1.4.4.8.14

Coded name:

Name: ONL Inquiry / Resend of Transaction(s) ARMS Sent to Trading Partner

Comment: ©Definition: A process where by the Application Support Staff can display transaction sent to the Trading Partner.

Process

Hierarchical numeric ID: 1.1.4.4.8.14.1

Coded name: CCAM15

Name: PGM Send Log Inquiry and Resend (CCAM15)

Comment: ©Definition: A program where by the Application Support Staff can display transaction sent to the Trading Partner. It may, if needed, select a sent transaction, alter the data, and resend the transaction to the Trading Partner for processing.

©Purpose: This is useful when troubleshooting a problem

©Operational Method:

- Read the sent transaction log file, display a list on screen for the user.

- Upon the selection of one of the sent transmissions, display the data/control record that make up that single transmission.

- Once a transmission has been selected, the user has the option of changing the data in the transmission and resending it.

Process

Hierarchical numeric ID: 1.1.4.4.8.15

Coded name:

Name: ONL Audit of Transaction Activity

Comment: ©Definition: A process where by the Application Support Staff is able to display the electronic history of a specific transaction.

©Purpose: Very useful in problem determination.

Process

Confidential Page 233 of 246 8/11/00 ARMS Process Report

Hierarchical numeric ID: 1.1.4.4.8.15.1

Coded name: CCAM16

Name: PGM Timeline Inquriy (CCAM16)

Comment: ©Definition: A program that will display the electronic history of a specified transaction.

©Purpose: Very useful in problem determination.

©Operational Method:

- Retrieve the transaction information via 1 of 4 ways:

- Vendor Transaction Id

- Company & Customer Transaction ID

- Location £. Reservation

- Location & Ticket

- Retrieve all sent and received transaction with the same vendor transaction id and display this information.

- When the user selects and individual transmission, display the details of that transmission.

- When F2 is pressed, a printout is generated with all the information associated to the transaction.

Process

Hierarchical numeric ID: 1.1.4.4.8.15.2

Coded name: CLL800

Name: PGM Cross-reference Maintenance Log Driver (CLL800)

Comment: ©Purpose: The driver program that sets up the print file before executing the program to print the cross-reference maintenance log.

©Operational Method:

- Override print file

... ■ - Execute program that generates the maintenance log report

Process

Hierarchical numeric ID: 1.1.4.4.8.15.3

Coded name: AM0800R

Name: PGM Print Database / Cross-Reference Maintenance Log (AM0800R)

Comment: ©Purpose: To take a 'snapshot' of the existing database for a single transaction.

©Operational Method:

- Retrieve all associated database records for the single vendor transaction id and print the information.

Process

Hierarchical numeric ID: 1.1.4.4.8.16

Coded name:

Name: ONL Inquiry / Resend of an Electronic Invoice

Confidential Page 234 of 246 8/11/00 ARMS Process Report

Comment : ©Description: A process where by the Application Support Staff can correct an electronic invoices and send it to the Trading Partner.

Process

Hierarchical numeric ID: 1.1.4.4.8.16.1

Coded name: AAAM15

Name: PGM Billing Log Inquiry and Resend (AAAM15)

Comment: ©Purpose: To select/display records for billing corrections and to

RESEND to the customer.

©Operational Method:

- The user must first select the order in which the data will be displayed (GPBR, TICKETS or LOCATION, TICKET*) .

- Then the user will select the item to be changed and make the change. The program then recalculates the totals for the trailer record and redisplays all. The user can then choose to resend this billing to the customer by pressing CMD-9 twice.

- This will write the header, all corrected detail, and the trailer records to AMPACK. Also will write the APPDOl record before the header record.

Process

Hierarchical numeric ID: 1.1.4.4.9 Coded name:

Name: ONL Perform Data Queue Maintenance Comment: ©Definition:

This activity is performed by the ARMS on-call staff to support the application by manipulating the data (transactions) in the environment.

Process

Hierarchical numeric ID: 1.1.4.4.9.1

Coded name: ARMSONCL

Name: SCR ARMS Data Queue Monitor (ARMSONCL)

Comment: ©Definition: A process from which the ARMS on-call staff can monitor the number of messages waiting to process and where.

©Notes :

- Run everywhere

Process

Hierarchical numeric ID: 1.1.4.4.9.2

Coded name: A40NCL

Name: SCR ARMS/400 Data Queue Monitor (A40NCL)

Comment: ©Definition: A process from which the ARMS on-call staff can monitor the number of messages waiting to process and where.

©Notes:

- Run RARMS only

Confidential Page 235 of 246 8/11/00 ARMS Process Report

Process

Hierarchical numeric ID: 1.1.4.4.9.3

Coded name: ANDQLDDQ

Name: ONL Load Data Queue with Message from Data Queue (ANDQLDDQ)

Comment: ©Definition: A process where the ARMS on-call staff can read and load data queue message from and to a specified data queue.

©Purpose: Provide the application development staff a way to perform load balancing when problems with external communications has resulting if a backlog of un-sent transactions.

©Note:

- User specifies the number of messages to read, starting at the first entry.

Process

Hierarchical numeric ID: 1.1.4.4.9.4

Coded name: ANDQLDPF

Name: ONL Load Data Queue with Message from a Physical File (ANDQLDPF)

Comment: ©Definition: A process where the ARMS on-call staff can read record from a specified physical file and load data queue message to a specified data queue.

©Purpose: Provide the application development staff a way to generate the corresponding data queue entry for the data records.

©Notes :

Process

Hierarchical numeric ID: 1.1.4.4.9.5

Coded name:

Name: ONL Retrieve Data Queue Information

Comment: ©Definition: A process that allows the ARMS on-call the option to retrieve. information about^' the data queue, particularly the number of messages.

Process

Hierarchical numeric ID: 1.1.4.4.9.6

Coded name: RGZDTAQ

Name: ONL Reorganize Data Queue (RGZDTAQ)

Comment: ©Definition: The process where by the ARMS on-call staff can delete and recreate a data queue without destroying the data queue entries- that might still exist.

©Purpose: Data queue processing some known traits - If the number of messages grow to more than 100, the size of the data queue expands. The only way to reclaim the space is to delete and recreate the data queue. Its a performance issue.

Process

Hierarchical numeric ID: 1.1.4.4.9.7

Coded name:

Name: MNU ARMS System Data Queue Maintenance

Confidential Page 236 of 246 8/11/00 ARMS Process Report

Comment : ©Definition: see ONL Perform Data Queue Maintenance

Process

Hierarchical numeric ID: 1.1.4.4.9.8

Coded name:

Name: ONL Work with Application Data Queues

Comment: ©Definition: A process that provides the Application Support Staff easy access to manage / manipulate the data being passed between processes.

©Purpose: Provide easy access of the APIs to display, dump, and clear a data queue as well as add a data queue entry through the use of a display screen.

Process

Hierarchical numeric ID: 1.1.4.4.9.8.1

Coded name: ANDQMNEU

Name: MNU Application Development Data Queue Menu

Comment: ©Definition: A menu that provides the Application Support Staff easy access to manage/manipulate the data being passed between processes.

©Purpose: Provide easy access of the APIs to display, dump, and clear a data queue as well as add a data queue entry through the use of a display screen.

Process

Hierarchical numeric ID: 1.1.4.4.9.8.3

Coded name:

Name: SCR Add a Data Queue Entry

Comment: ©Definition: A tool that allows the Application Support Staff to enter , data queue entries as needed.

Process ..

Hierarchical numeric ID: 1.1.4.4.10 Coded name:

Name: ONL Perform Application File Maintenance Comment: ©Definition:

This activity is performed by ARMS Technical to maintain various application table files (i.e. BCO, Trading Partner Profile)

Process

Hierarchical numeric ID: 1.1.4.4.10.1

Coded name:

Name: ONL Maintain Trading Partner Profile Global Attributes

Comment: ©Definition: The ARMS Technical Staff uses this activity to maintain the

ARMS customer global profile information like how the customer connects to

Enterprise, what types of transactions the customer receives and/or sends, what is the time window for the customer during which batch invoices can be sent etc.

Confidential Page 237 of246 8/11/00 ARMS Process Report

Process

Hierarchical numeric ID: 1.1.4.4.10.1.1

Coded name: AM0700

Name: PGM Maintain ARMS Trading Partner Profiles (AM0700)

Comment: ©Purpose:

To allow the user to maintain all the company profile attributes related to transactions and communications.

©Operational Method:

This program displays a list of all the companies that have been set up in the ARMS system and has options for the user to add, change, copy, delete or display profiles.

There is a separate function key for each classification of the profile attributes and a separate program maintains each classification. The following functions are available:

F7=Appl Specific F8=Name Addr F9=Tech Data F10=File/Field Ctrl F14=ECARS Data F16=Claims F17=Discount F18=Underage Driver

Process

Hierarchical numeric ID: 1.1.4.4.10.1.2

Coded name: AM0701 ^: "

Name: PGM Maintain ARMS Trading Partner Profile Application Specific Information (AM0701) Comment: ©Purpose:

To maintain the ARMS Application Specific Data that defines how the trading partner host system interacts with the ARMS system. This file is essentially contains an electronic agreement between the two.

©Operational Method:

- This program gets invoked when the user presses function key F7 to maintain the application specific data from the main screen displayed by controlling program AM0700. ^■

- The user can change all the profilable attributes for any company. The attributes and their description are retrieved from the ARMS field table file AMFDTBL.

©Files :

ARMSPRl (-RU-) ARMSPR2 (-R-) AMFDTBL (-R—)

©Notes:

Confidential Page 238 of 246 8/11/00 ARMS Process Report

The changes are then made online to the distributed files via DDM links.

Process

Hierarchical numeric ID: 1.1.4.4.10.1.3

Coded name: AM0702

Name: PGM Maintain ARMS Trading Partner Profile Contact Information (AM0702)

Comment: ©Purpose:

To maintain the ARMS Customer Address Data for the insurance company.

©Operational Method:

- This program gets invoked when the user presses function key F8 to maintain the company name and address information from the controlling program AM0700 main display.

- The user can change the customer's name, address, phone and fax number of the insurance company's corporate office.

- The file ARMSPR2 is keyed by company profile and customer code which allows for more than one recor for every profile.

©Notes:

The changes are then made online to the distributed files via DDM links.

Process

Hierarchical numeric ID: 1.1.4.4.10.1.4

Coded name: AM0703

Name: PGM Maintain ARMS Trading Partner Profile Technical Information (AM0703) >■^■

Comment: ©Purpose:

To maintain the ARMS technical connection information for connecting Enterprise- ARMS hostsystem-^' to trading partner host system.

©Operational Method:

- This program gets invoked when the user presses function key F9 to maintain the company technical information from the controlling program AM0700 main display.

- The user can change the customer's connection specific information. ©Notes :

The changes are then made online to the distributed files via DDM links.

Process

Hierarchical numeric ID: 1.1.4.4.10.1.5

Coded name: AM0704

Name: PGM Maintain ARMS Trading Partner Profile File/Field Controls (AM0704)

Comment: ©Purpose:

Confidential Page 239 of 246 8/11/00 I ARMS Process Report

To maintain the insurance company's field control table that determines which fields are mandatory to send and or receive.

©Operational Method:

- This program gets invoked when the user presses function key F10 to maintain the field control information from the controlling program AM0700 main display.

- The user can change the customer's field control table, ARMSPR4. ©Notes:

The changes are then made online to the distributed files via DDM links.

Process

Hierarchical numeric ID: 1.1.4.4.10.1.6

Coded name: AM0705

Name: PGM Maintain ARMS Trading Partner Profile ECARS-Specific Information (AM0705)

Comment : ©Purpose:

To maintain the insurance company's ECARS application system specific data like which billing program to call when closing a ticket.

©Operational Method:

- This program gets invoked when the user presses function key F14 to maintain the ECARS information from the controlling program AM0 00 main display.

- The user can change how ECARS system interacts with the customer company's authorized rentals.

©Notes :

The changes are then made online to the distributed files via DDM links.

Process

Hierarchical numeric ID: 1.1.4.4.10.1.7

Coded name: AM0706

Name: PGM Maintain ARMS Trading Partner Profile claims Connection Specific

Information (AM0706)

Comment : ©Purpose :

To maintain the insurance company's Claims Connection' application system specific data like which billing program to call when closing a ticket.

©Operational Method:

- This program gets invoked when the user presses function key F14 to maintain the Claims information from the controlling program AM0700 main display.

- The user can change how Claims Connection system interacts with the customer company's authorized rentals.

©Notes :

Confidential Page240 of246 8/11/00 ARMS Process Report ^~~|

The changes are then made online to the distributed files via DDM links .

Process

Hierarchical numeric ID: 1.1.4.4.10.1.8

Coded name: AM0707

Name: PGM Maintain ARMS Trading Partner Profile Volume Discount Levels (AM0707)

Comment : ©Purpose:

To maintain the insurance company's discounts based on transaction volumes .

©Operational Method:

- This program gets invoked when the user presses function key F17 to maintain the Discount information from the controlling program AM0700 main display.

- The user can change how much discount a company gets at what threshold levels of transactions.

©Notes :

The changes are then made online to the distributed files via DDM links.

Process

Hierarchical numeric ID: 1.1.4.4.10.1.9

Coded name: AM0708

Name: PGM Maintain ARMS Trading Partner Profile Underage Control by State/Province

(AM0708)

Comment: ©Purpose:

To maintain the underage surcharge amount and age that is considered underage for each profile and state combination.

©Operational Method:

- This program gets invoked when the user presses function key F18 to maintain the Underage information from the controlling program AM0700 main display.

- The user can change the amount to charge for underage drivers and the legal age for that state by company profile.

©Notes :

- This file is currently empty and no company has been so customized.

- The changes are then made online to the distributed files via DDM links.

Process

Hierarchical numeric ID: 1.1.4.4.10.3

Coded name:

Name: ONL Maintain Application Transaction Error Code Table

Comment: ©Definition: A process by which the application support staff can maintain ARMS transaction error code table

Confidential Page 241 of246 8/11/00 ARMS Process Report

Process

Hierarchical numeric ID: 1.1.4.4.10.3.1

Coded name: AAEC01

Name: PGM Maintain Error Code Table (AAECOl)

Comment: ©Purpose: Allow the application support staff to maintain the transaction error code table.

Process

Hierarchical numeric ID: 1.1.4.4.10.4

Coded name:

Name: ONL Maintain Car Class Cross-Reference

Comment: ©Definition: A process whereby the application support staff maintains the car class (make/model) cross-reference for every Trading Partner.

Process

Hierarchical numeric ID: 1.1.4.4.10.5

Coded name:

Name: ONL Maintain Trading Partner Profile Geographic/Regional Attributes

Comment: ©Definition: This activity is used by the ARMS Technical Staff members to maintain the cross-reference between the ARMS customer branch claims office (BCO) and Enterprise customer assigned to the BCO.

Process

Hierarchical numeric ID: 1.1.4.4.10.5.1 Coded name: AAAM10

Name: PGM Maintain Trading Partner Profile Individual Office Locations Attributes (AAAMIO) Comment :, ©Purpose:

To maintain the cross-reference table between the insurance customer's branch claims offices and Enterprise customer numbers assigned to those branch claims offices.

©Operational Method:

This program reads file AMXBCO and displays the company id and branch claims offices in that order in a subfile display along with the' assigned Enterprise customer numbers and claims office description.

The user can position to a particular profile and then choose to maintain details for or delete a particular company id-claims office pair.

When the user selects to maintain, another screen displays the following attributes for the pair:

ARMS Profile ID

Customer Branch claims Office Enterprise Customer Number. . BCO Description

Confidential Page242 of246 8/11/00 ARMS Process Report

Country Code :

Electronic «- Paper Bills. . . . : (Yes or No)

Include Airport Locations

ARMS Special Condition :

Default Node ID ^••

ARMS Active Control Effective start and end dates

ARMS Billing Active Control . ARMS Payments Active Control.

The user has the ability to delete a pair by selecting a 'D' against the pair or another pair can be added by function key F6.

Process

Hierarchical numeric ID: 1.1.4.4.10.6

Coded name:

Name: ONL Maintain Application Master Files/Tables

Comment: ©Definition: This activity allows the user to maintain the master files that may contain customized data for a certain company or certain default information to use when generating transactions.

Process

Hierarchical numeric ID: 1.1.4.4.10.6.1 Coded name: AMS004

Name: PGM Maintain Surcharge Table (AMS004A) Comment : ©Purpose:

To allow the user to set up automatic surcharge proprietary formats (SURD01) by company profile and state. These are surcharges that the company authorizes Enterprise to automatically charge against a rental authorized by that company.

©Operational Method: ■ The program displays the surcharge format detail fields for a profile in the header section and all the states in the detail section using a standard subfile approach and allows the user to add, change, copy or delete records.

Process

Hierarchical numeric ID: 1.1.4.4.10.7

Coded name:

Name: MNU Maintain Application Files

Comment: ©Definition: see ONL Perform Application File Maintenance

Process

Hierarchical numeric ID: 1.1.4.4.10.9

Coded name:

Name: ONL ARMS/400 Training Administration

Comment: ©Definition: Process by which the Application Support Staff manage the

ARMS/400 Tranining System.

Confidential Page 243 of 246 8/11/00 ARMS Process Report

Process

Hierarchical numeric ID: 1.1.4.4.10.9.1

Coded name: A4TRNGMN

Name: MNU ARMS/400 Training Administration Menu (A4TRNGMN)

Comment: ©Definition: A process which enables the Application Support Staff to manage the training environment / data. From setting up claims office and testing scenarioes to checking the status of the system.

Process

Hierarchical numeric ID: 1.1.4.4.10.10

Coded name:

Name: ONL Maintain Vehicle Class / Rate Table

Comment: ©Definition: Provide the means for the Application Support Staff to maintain Trading Partner's rate to Enterprise's car classes.

Process

Hierarchical numeric ID: 1.1.4.4.10.10.1

Coded name: CCAM11

Name: PGM Vehicle Class / Rate Table Maintenance (CCAM11)

Comment: ©Purpose:

To provide the means for the Application Support Staff to maintain Trading Partner's rate to Enterprise's car classes cross-reference table (including ARMS/400 Customers) . ©Operational Method:

- Display the details in file AMCLSTBL or A4CLSTBL and allow the user to maintain the data and synchronize the data on all computer platforms via DDM links.

The first screen displays the Company ID, ARMS class. Enterprise class, Class description and the X12 car class.

Options available from this screen:

1. Position to a particular Company ID

2. Add a new ARMS class to an existing Company ID or a new Company ID, in which the Company will be created.

3. Change a current ARMS class for a Company ID.

4. Delete a current ARMS class for a Company ID.

5. Copy an existing ARMS class to a new or existing Company. ID.

When the user selects to add or change an ARMS class another screen is displayed. This screen will allow the user to change or input an ARMS class, Enterprise class, class description and X12 car class. when the user chooses to copy one or more ARMS classes, a screen will be displayed with the chosen ARMS classes. Enterprise classes, class descriptions and X12 car class, from which the user can choose a company ID, new or preexisting, to copy all of the classes to.

©Files:

AMCLSTBL (C )

A4CLSTBL (C )

DCSPCL ( R )

DCSPTY (_R_

Confidential Page 244 of 246 8/11/00 ARMS Process Report

DCSPSH ( R ) DCSPAC ( R ) ARMSPRl ( R ) ARMSPR3 ( R )

Process

Hierarchical numeric ID: 1.1.4.4.11 Coded name: AM0900

Name: SCR Create Invoice Request (AM0900) Comment : ©Definition:

This activity is performed by the help desk to generate paper and electronic bills for previously errored invoices.

©Operational Method:

The user input fields include group, branch, and ticket number. AM0900 first verifies that the ticket is in the file, QRACCLSQ (closed ticket file) . Secondly, it verifies that it is an ARMS ticket be checking a field in RACSCLD. Finally AM0900 calls AMIOIOVI that retrieves the corresponding AMXREF record.

Based on the status code returned, the program allows the user to proceed in AM0900. The next screen allows the user to hit a function key for re-billing and selecting of either paper of electronic billing method. A record is then written to RACBILL to reflect the rebill choice and an AMBILL record id written to log the rebill.

©Notes :

- Runs on A,E,F,I,K,L,M,N,P,S,T,W,Y

©Files: (CRUD)

-QRACCLSQ (C ) (Logical over RACCLSC and past 12 monthly files)

-RACSCLD ( R ) (Logical over RACSCLC and past 12 monthly files)

-RACBILL (C )

-AMBILL (C ) ^■ '

Process

Hierarchical numeric ID: 1.1.4.4.12

Coded name: ARMSEDT

Name: SCR Display Reservation / Ticket Information (ARMSEDT)

Comment: ©Definition: A process that provides the ARMS on-call staff the option of retrieving specific data elements from multiple Rental files.

©Notes :

Process

Hierarchical numeric ID: 1.1.4.4.13 Coded name:

Name: ONL Monitor Purge Activity Comment : ©Definition:

This activity is used by ARMS on-call to monitor the progress of the ARMS application database purge.

Confidential Page 245 of 246 8/11/00 I ARMS Process Report

Process

Hierarchical numeric ID: 1.1.4.4.13.1

Coded name:

Name: ONL Display Database Transaction Set Controls

Comment: ©Definition: A process where by the ARMS on-call staff can monitor the database purge.

©Notes:

- DSPDDTAARA AM006A

- Three steps involved in the entire purge process.

Process

Hierarchical numeric ID: 1.1.4.4.13.2

Coded name:

Name: ONL Display Orphaned Transaction Set Controls

Comment: ©Definition: A process where by the ARMS pn-call staff can monitor the database purge. i

©Notes : .

- DSPDDTAARA AM009A \

- Three steps involved in the entire purge process.

Process

Hierarchical numeric ID: 1.1.4.4.13.3

Coded name:

Name: ONL Display Reorganize File Control

Comment: ©Definition: A process where by the ARMS on-call staff can monitor the database purge.

©Notes:

- DSPDDTAARA AM009A

- Three steps involved in the entire purge process.

Process

Hierarchical numeric ID: 1.1.4.4.13.4 !

Coded name:

Name: MNU Display Purge Programs ^

Comment: ©Definition: see ONL Monitor Purge Activity.

Process

Hierarchical numeric ID: 0

Coded name:

Name: Rental and ARMS

Comment: ©Definition: This is the Automated Rental Management Systems (ARMS) application context as it currently is.

Confidential Page246 of246 8/11/00 ARMS Web User Guide

Automated

Rental

Management

System

Introduction i-v

Create Reservation 1 -5

Change Reservation/Rental 1-12

Enterprise Requests-by Adjuster 1 -8

Enterprise Requests-Unassigned 1 -5

View4teservation/Rental 1-6

On-Line Reporting 1 -6

Process Approved Invoices 1 -7

Setup and Maintenance 1 -7

Buttons Appendix

EXHIBIT Introduction

Welcome to ARMS Web! i

What is ARMS Web? i

User Guide Overview ii

Helpful Hints ii

Common Definitions ii

Function Keys iii

Other Information iii

On-screen Information iii

Sign On iv

ARMS Web Main Menu v Introduction

Welcome to ARMS Web!

This User Guide offers step-by-step instructions that clearly guide you through each function of ARMS Web. It also shows you how to maximize the benefits of the system. Enterprise encourages you to keep the User Guide handy for future reference.

What is ARMS Web?

It is the Internet-based version of the Automated Rental Management System. ARMS Web forms a web-based computer link between your company and Enteφrise Rent-A- Car. You can create reservations to set up rentals for your insured or claimants directly through the Enterprise computer system. You also have the ability to change existing reservations and rentals, view rates, extend authorizations, receive authorization requests and extension requests, send messages back and forth with Enterprise, and much more.

Page i Introduction User Guide Overview

Keep these important points in mind when reading your User Guide:

The screens shown throughout this guide are reproduced directly from the ARMS Web system and are accurate reflections of the actual screens. Field buttons appear in bold type. They can be clicked to access information or move to another screen.

Helpful Hints

♦ Remember to key your claims office code in the Office field on the main menu (shown above). Your name will already be set in the Adjuster field after you log on to the system. Once you enter the office code here, it is carried forward throughout the program for you. _ .

♦ If yo r are monitoring or making changes to another adjuster's files, be sure to enter his or her last name in the Handling for Adjuster field.

♦ Whenever a button is highlighted (see Create Reservation above), you can press [ENTER) or click the button to select it. You can highlight a button by pressing [TAB] to move from one button to the next Though there are three methods by which to select the screen, the User Guide will use only the highlight and click OK method. Remember that you can use any of the methods at any time.

Common Definitions

♦ A finger is what the cursor turns into when it is positioned over a button. Click to select that button. vCresrte Reservation

A button is an area on the screen that allows you to access, view, and/or change information.

Introduction Page ii Sign On

Depending on the type of link your company has with Enterprise, the following screen may or may not appear. If it does not appear, consult your supervisor for sign-on procedures.

If the Sign. On screen does appear,

1) Key your User ID and Password. This user ID and password will be issued to you by

Enterprise. These allow Enterprise to confirm that you are authorized to use ARMS Web.

2) Press (ENTER) or click Logon. The ARMS Web main menu appears (page v).

Introduction Pageiv 444

Create Reservation

When should I Use this section use Create to authorize

Reservation?

a rental.

Create a Reservation - Main Menu 1

Select a Reservation 2

Select an Adjustor 3

Create a Reservation 4

Create a Reservation - Rate Selection 5

Create a Reservation - Main Menu

1) Key your claims office code in the Office field.

2) Key your last name in the Adjuster field.

3) Key the first three letters of the renter's last name (required).

4) Click Create Reservation.

5) If Enterprise has already requested a reservation authorization for a renter whose last name matches the three letters keyed, the Select Reservations/Rentals screen appears when you click Create Reservation (page 2). If there is no match for the letters keyed, the Create Reservation screen appears (page 4).

The Select Reservations/Rentals screen prevents duplicate authorization requests. You will probably see it often.

Page 1 Create Reservation Select an Adjustor

This Adjuster Selection pop-up window appears when no adjuster has been assigned to the selected claim.

1)" Key the desired adjuster name in the Adjuster Last Name field and click Search. OR

Click to highlight the desired adjuster in the Adjuster name field, and click OK. 2) The Create Reservation screen appears (page 4).

Click Change Claims Office to find a new claims office.

Page 3 Create Reservation Create a Reservation - Rate Selection

This pop-up window appears when you click Rates from the Create Reservation screen (page 4).

The window shown below displays an example of vehicle classes and the associated rates. The rates displayed in this window are determined by the telephone number keyed in the Phone Where Rental Is Needed field on the Create Reservation screen. ARMS Web uses this telephone number to locate the Enterprise office closest to where the renter needs the car. The vehicle classes and rates that display are valid only at that particular Enteφrise office.

This window also displays the Enterprise office location and phone number that you may wish to give to the renter.

If there are no Enterprise offices found, based on the Phone Where Rental Is Needed field, the reservation will be sent to Claims Connection in St. Louis.

1) Click to highlight the car class you wish to select, and click OK. ARMS Web automatically places the selected rate in the appropriate field and returns you to the Create Reservation screen (page 4).

2) Click Back to return to the Create Reservation screen without selecting a car class.

Page 5 Create Reservation 449

Change Reservation/Rental

Use this section to ■<>]

extend a

Rental? rental or change information on an existing reservation.

Authorization Status Definitions 1

Change a Reservation/Rental - Main Menu 2

Use a "Filter" Screen fo Select a Reservation/Rental 3

Select a Reservation/Rental 4

Change an Unconfirmed Reservation/Ticket 5

Change an Unconfirmed Reservation/Ticket 6

Renter, Vehicle, Repair Facility, and Claim Information

Change and Process an Unconfirmed Reservation/Ticket 7

Authorization, Rental Delivery Information, and Message

Change and Process a Reservation or an Open Rental 8

Extend an Open Rental 9

Send a Message on an Open or Unconfirmed Reservation or Rental ...10

Cancel a Reservation 11

Terminate an Open Rental Ticket 12 Authorization Status Definitions

RESERVATION A rental has been authorized, but the customer has not yet picked up a rental car or started a rental ticket/contract.

OPEN RENTAL The customer has picked up a car and has opened a rental ticket/contract.

DIRECT BILL REQUEST The customer has reserved or rented a car through Enterprise, and Enterprise is requesting that you confirm whether you will authorize the rental.

EXTENSION An extension request is pending on an open contract.

MESSAGE An incoming message is pending on an open reservation/rental. EXTN/MSG (Extension and Message) - An extension request, along with an additional message, is pending on an open contract.

SENT You have sent an authorization to Enteφrise, but the office has not yet sent back a confirmation.

CLOSED (Closed Ticket) - The customer has returned the rental car and ended the contract. REJECT (Authorization Rejected) - An unconfirmed ticket or reservation has been denied authorizatioa

CANCEL (Cancelled Reservation) - A previously authorized reservation has been cancelled.

UNASSIGNED RESERVATION A direct bill request from Enterprise has yetto be assigned to an adjustor.

The following status definitions apply only to those companies that use the ARMS Web Electronic Invoicing feature: _ .

INVOICE - The rental ticket has been closed and is awaiting approval for payment.

REJECTED INVOICE - Authorization for payment of the invoice has been denied.

INVOICE RETURNED - An invoice has been returned to the adjustor because the home office' s system could not find a matching claim number and cannot issue payment.

PAID -The invoice has been approved and processed for payment.

The invoice is marked "PAID" in the ARMS Web system only. Your account will be

credited upon receipt of payment.

Page 1 Change Reservation/Rental Use a "Filter" Screen to Select a Reservation/Rental

1) Key specific criteria to narrow the list of all reservations/rentals from which to choose. J For example, if you know the renter's claim number and date of loss, key that - - information in the appropriate fields.

^" 2) Click Next.

3) If an exact match is not found, the Select Reservations/Rentals screen appears (page 4). If an exact match is found, the Change Reservation/Rental screen appears (page 5) .

Any combination of information may be used to narrow the search for reservations/rentals.

Use the Status field in conjunction with the other information keyed to further narrow the search. If the Status field is left blank, the system searches all reservations/rentals.

Use the Status drop-down menu to search for open reservations only or open rentals only.

The Last Authorized Day field allows you to select rentals authorized up to and including the date provided.

You can also click any of the following option buttons (Appendix, page 1):

Home - Return to themainmenu (page 2).

Adjustor Lookup - Display a list of adjusters (Appendix, page 5).

Page 3 Change Reservation Rental Change an Unconfirmed Reservation/Ticket

This Change Reservation/Rental screen displays whenamatch is found for an unconfirmed reservation/ticket. The status displays in the upper left-hand corner of the screen.

The information on each of the tabs (Authorization Information, Rental Location, Repair Information, Renter Information) depends upon the status of the reservation/rental.

1) Click on any of the tabs to alter renter, vehicle, repair facility, and/or claim information.

2) Click Finish to complete your change and return to the main menu.

You can also click any of the following option buttons (Appendix, page 1):

Rates - Display a list of vehicle rates.

Home - Return to the main menu (page 2).

Detail - Advance to the next Change Reservation/Rental screen (page 6).

Message - Send a message to an Enterprise office (page 10).

Change Adjuster - Change the adjustor handling the file (Appendix, page 5).

Additional Charges - View additional charges on the rental contract (Appendix, page 7).

Cancel - Cancel the reservation (page 11).

Page 5 Change Reservation/Rental Change and Process an Unconfirmed Reservation/Ticket

Authorization, Rental Delivery Information, and Message

This Change Reservation/Rental screen displays when you click Next on the previous Change Reservation/Rental screen (page 6).

- 1) Key additional information, or key over any existing information you wish to change.

TheNumber of Days and the Vehicle Rate fields are required to confirm the authorization/reservation. If you do wot key the number of days authorized, the reservation/ticket remains unconfirmed.

2) Click Finish to process the changes to this unconfirmed reservation/ticket and return to the Select Reservations/Rentals screen (page 4).

You can also click any of the following option buttons (Appendix, page 1):

Rates - Display a list of vehicle rates (page 5).

Home - Return to the main menu (page 2).

Message - Send a message to an Enteφrise office (page 10).

Change Adjuster - Change the adjustor handling the file (Appendix, page 5).

Additional Charges - View additional charges on the rental contract (Appendix, page 7).

Page 7 Change Reservation Rental Extend an Open Rental

This Change Reservation/Rental screen appears when a match is found for an open rental. The status displays in the upper left-hand corner of the screen.

To extend a rental,

1) Key the desired number in the Number of Days to Extend field.

2) Key a message if desired.

3) Click Extend Rental.

4) Click Finish to process the extension and return to the Select Reservations/Rentals screen (page 4). Click Back to return to the Select Reservations Rentals screen (page 4) without processing any extension.

The next time you access this rental, the S/R message displays "EXTENSION SENT BY ADAMS,KYLE @ 10:46:21." The Total column will also reflect the extended number of days.

For an explanation of the buttons, please refer to page 8.

Page 9 Change Reservation/Rental Cancel a Reservation

The Cancel Reservation pop-up window appears when you click Cancel on the Change Reservation/ Rental screen (page 5) if the status is "Unconfirmed Reservation" or "Reservation."

- 1) Key a comment that explains why this unconfirmed reservation or reservation is being cancelled.

2) Click OK to process the cancellation and return to the Select Reservations/Rentals screen (page 4). Click Back to return to the Select Reservations/Rentals screen (page 4) without cancellingthereservation.

The status changes from 'unconfirmed Reservation" or "Reservation" to "Cancelled."

Page 11 Change Reservation Rental 457

rentals.

Enterprise Requests-by Adjuster - Main Menu 1

Select a Reservation/Rental 2

Respond to Authorization Requests from Enterprise for an Unconfirmed Reservation (Direct Bill Request) 3

Review and/or Change an Unconfirmed Reservation (Direct Bill Request) 4

Renter, Vehicle, Repair Facility, and Claim Information

Review and/or Change an Unconfirmed Reservation 5

Authorization, Rental Delivery Information, and Message

Extend an Open Rental 6

Terminate an Open Rental Ticket 7

Send a Message on an Open or Unconfirmed Reservation or Rental 8 Enterprise Requests-by Adjuster - Main Menu

1) Key your claims office code in the Office field.

2) Key your last name in the Adjuster field.

3) Click Enterprise Requests - by Adjuster.

4) The Select Reservations/Rentals screen appears (page 2).

If you key an adjuster's last name in the Handling for Adjuster field, Enterprise requests for only that adjustor display on the Select Reservations/ Rentals screen (page 2). Records appear in alphabetical order according to the renter name.

If you leave the Handling for Adjuster field blank, requests for all adjustors display on the Select Reservations/Rentals screen (page 2). Authorization requests appear in alphabetical order according to the adjustor name.

If you want to display requests for one particular adjustor, leave your name in the Adjuster field and input the other name in the Handling for Adjuster field.

Page 1 Enterprise Requests-by Adjuster Respond to Authorization Requests from Enterprise for an Unconfirmed Reservation (Direct Bill Request)

This Change Reservation/Rental screen appears when you select an unconfirmed reservation/ticket on the Select Reservations/Rentals screen (page 2).

1) Key the number of days and the amount you are authorizing. This includes the daily rate, the maximum dollar amount allowed on the rental, and the number of days allowed.

2) Click Next to continue to the next Change Reservation/Rental screen (page 4). Click Back to return to the Select Reservations Rentals screen (page 2).

If the claim type is Insured or Theft, the Number of Days field and the Policy Coverage fields must be filled in (required). If the claim type is Claimant, the Number of Days field, the Vehicle Rate field, and the Direct Bill

Percent field must all be filled in (required).

Youcanalso click any ofthe following option buttons (Appendix, page 1):

Rates - Display a list of vehicle rates.

Home - Return to the main menu (page 1).

Message - Send a message to an Enterprise office (page 8).

Change Adjuster - Change the adjustor handling the file (Appendix, page 5).

Additional Charges - Niew additional charges on the rental contract (Appendix, page 7).

Cancel - Delete any information updated on this screen and return to the previous screen.

Page 3 Enterprise Requests-by Adjuster Review and/or Change an Unconfirmed Reservation

Authorization, Rental Delivery Information, and Message

This Change Reservation/Rental screen appears when you click Next on the previous Change Reservation/Rental screen (page 4).

1) Review the screen to ensure that all information is accurate. If you need to make changes, key over the existing information.

2) Click Finish to send this authorization request to Enterprise and return to the Select Reservations/Rentals screen (page 2).

Click Back to return to the previous Change Reservation/Rental screen (page 4).

You can also click any of the following option buttons (Appendix, page 1 ):

Rates - Display a list of vehicle rates.

Home - Return to the main menu (page 1).

Message - Send a message to an Enterprise office (page 8).

Change Adjuster - Change the adjustor handling the file (Appendix, page 5).

Additional Charges - View additional charges on the rental contract (Appendix, page 7).

Page 5 Enteφrise Requests-by Adjuster Terminate an Open Rental Ticket

This Terminate Rental pop-up window appears when you click Terminate on a Change Reservation/ Rental screen (page 6) if the status is Open Rental.

-1) Key the last date for which you authorize payment. This date cannotbeprior to the current date if the rental is already extended through today. If the date keyed is greater than the current date, ARMS Web automatically extends the rental through that date.

You will not receive any more extension requests from Enterprise on a rental after that rental is terminated. However, you can still send extensions on rentals that you terminate.

2) Click the box to indicate whether the renter has been notified of the last date for which this payment is authorized (required). If the box is left blank, this indicates that the renter has not been notified.

3) Key a comment to explain why you are terminating the open rental ticket.

4) Click OK to process the termination.

The status still displays as "Open Rental"; however, a message displays in the Message field stating that the rental has been terminated and by whom. If necessary, you can extend a rental past a termination (see page 6).

Page 7 Enterprise Requests-by Adjuster 463

Enterprise Requests-Unαssigned

When should I Use this use Enterprise section to

Requests-

assign Unαssigned? Enterprise authorization requests to an adjuster or another claims oftice.

Enterprise Requests-Unassigned - Main Menu 1

Select Unconfirmed Reservations/Rentals to Assign 2

View Authorization Request 3

Assign an Adjuster from Your Office 4

Assign an Adjuster from Another Office in Your Company 5

Enterprise Requests-Unassigned - Main Menu

1) Key your claims office code in the Office field.

2) Key your last name in the Adjustor field.

3) Click Enterprise Requests-Unassigned.

4) The Assign Reservations/Rentals screen appears (page 2).

Page 1 Enterprise Requests-Unassigned View Authorization Request

This Assign Reservation/Rental screen appears when you click and highlight a name and click OK on the previous Assign Reservations/Rentals screen (page 2).

1) Review thereservation/rental authorization request.

2) Click Assign to continue to the Adjustor Selection pop-up window (page 4), or click Back to return to the previous Assign Reservations Rentals screen (page 2).

The Adjustor field is blank because this unconfirmed reservation has not yet been assigned to an adjustor.

You can also click any of the following option buttons (Appendix, page I):

Home - Return to the main menu (page 1 ).

Message - Send a message to an Enterprise office (Appendix, page 4).

Page 3 Enterprise Requests-Unassigned Assign an Adjustor from Another Office in Your Company

This Claims Office List pop-up window appears when you click Change Claims Office on the Adjustor Selection pop-up window (page 4). ,

- 1 ) Click to highlight the office you wish to select, and click OK.

2) The Adjustor Selection screen (page 4) from the office you chose appears.

Follow the instructions on page 4 to assign an adjustor from the office you selected.'

Page 5 Enterprise Requests-Unassigned 468

View Reservation/Rental

When should Use this use View section to

Reservation/

review a Rental? reservation without making any changes.

View a Reservation/Rental - Main Menu 1

Use a "Filter" Screen to Select a Reservation/Rental 2

Select a Reservation/Rental 3

View a Reservation/Rental 4

View a Reservation/Rental 5

Renter, Vehicle, Repair Facility, and Claim Information

View ^"a Reservation/Rental 6

Authorization, Rental Delivery Information, and Message

View a Reservation/Rental - Main Menu

1) Key your claims office code in the Office field.

2) Key your last name in the Adjuster field.

3) Click Niew Reservation/Rental.

4) The Select Reservation/Rental "filter" screen appears (page 2).

Page 1 View Reservation/Rental Select a Reservation/Rental

This Select Reservations/Rentals screen appears under the following circumstances:

♦ More than one match is found for the information keyed on the Select Reservation/Rental - "filter" screen (page 2).

♦ ^" No match is found for the information keyed on the Select Reservation/Rental "filtef screen

(page 2).

1) Click to highlight a name in the Renter Name column, and click OK to select the renter whose reservation or rental you want to change.

2) The first View Reservation/Rental screen appears (page 4).

You can also click any ofthe following option buttons (Appendix, page 1):

Home - Return to the main menu (page 1).

Refresh - Remo e all updated information from the current page.

Page 3 View Reservation Rental View a Reservation/Rental

Renter, Vehicle, Repair Facility, and Claim Information

This Niew Reservation/Rental screen appears when you click Next on the previous View Reservation/Rental screen (page 4).

" Click Next to continue to the next View Reservation/Rental screen (page 6) to view authorization, rental delivery information, and comments.

You can also click any ofthe following option buttons (Appendix, page 1):

Home - Return to the main menu (page 1 ).

Additional Charges - View additional charges on the contract (Appendix, page 7).

Page 5 View Reservation/Rental 473

On-Line Reporting

When should Use this use On-Line section to

Reporting?

review reports on rentals, broken down by category.

On-Line Reporting - Main Menu 1

Select Report View Options 2

Open Detail - By Adjustor 3

Open Detail - By Body Shop 5

Open Detail - By Office 6

On-Line Reporting - Main Menu

1) Key your claims office code in the Office field.

2) Key your last name in the Adjuster field. .3) Click On-Line Reporting.

4) The Select Report View Options screen appears (page 2).

Page 1 On-Line Reporting Open Detail - By Adjustor

This Open Detail - By Adjustor screen appears when you select Adjustor in the Report Sorted By field and Auth Days in the Additional Sort field on the Select Report View Options screen (page 2).

1) Click to highlight the name of the renter whose file you want to access, and click OK to select that file

2) The first View Reservation Rental screen appears (Niew Reservation/Rental, page 4). The following columns and fields are display-only.

Adjustor Name - The adjustor in charge of the claims listed below.

Claim Number - The claim number assigned to a particular renter.

Type - The type of claim (Insured, Claimant, Theft)

Rate Authorized - The rate of the vehicle authorized by the adjustor.

Rent Days - The number of days the vehicle has been on rent.

Authorized Days - The number of days authorized by the adjustor.

Days Behind - The difference (if any) between the number of days authoπzed and the number of days on rent

If Auth Days was selected in the Additional Sort field, the claims will appear in descending order by the total authorized days.

Pase 3 On-Line Reporting Open Detail - By Body Shop

This Open Detail - By Body Shop screen appears when you select Body Shop in the Report Sorted By field and Auth Days in the Additional Sort field on the Select Report Niew Options screen (page 2).

1) Key the first few letters of the desiredbody shop in the Position to Body Shop Name field, and click Search. The list refreshes with your selection at the top.

2) Click to highlight the name of the renter whose file you want to access, and click OK to select that file.

3) The first View Reservation/Rental screen appears (View Reservation/Rental, page 4). For details on the column headings and fields, please refer to pages 3-4.

Page 5 θπ-Line Reporting 478

Process Approved Invoices

When should Use this use Process section to

Approved

process and Invoices? pay all invoices at your claims center.

Process Approved Invoices - Main Menu 1

Password Screen 2

Process Approved Invoices 3

Invoice Review/Approval 4

View Reservation/Rental 5

Send-to Adjuster 6

Batch Payment Confirmation 7

Process Approved Invoices - Main Menu

1) Key your claims office code in the Office field.

2) Key your last name in the Adjuster field.

3) Click Process Approved Invoices.

4) A password screen appears (page 2).

Page 1 Process Approved Invoices Process Approved Invoices

This Process Approved Invoices screen appears when you enter the correct password on the Process Approved Invoices password screen (page 2).

1) Click to highlight the invoice you wish to view, and click OK to select the invoice.

2) The Invoice Review/Approval screen appears (page 4).

3) Click Back to return to the main menu (page 1). m S If you click Accept Batch, the Batch Payment Confirmation screen appears (page 7).

You can also click either of the following option buttons:

Home - Return to the main menu (page 1 ).

Refresh - Remove all updated information from the current page.

Page 3 Process Approved Invoices View Reservation/Rental

This Niew Reservation/Rental screen appears when you click View Rental on the Invoice Review/ Approval screen (page 4).

ES^* This screen is view-only. You can review the information on the screen to determine whether to process the adjustor-approved invoice.

Click Next or Back to return to the Invoice Review/ Approval screen (page 4).

You can also click either of the following option buttons:

Home - Return to the main menu (page 1 ). ,

Additional Charges - View additional charges on the contract (Appendix, page 7).

Page 5 Process Approved Invoices Batch Payment Confirmation

This Batch Payment Confirmation screen appears when you click Accept Batch on the Process Approved Invoices screen (page 3 or 6).

1) In the Payment Date field, enter the date you wish to make payment.

-2) Click OK to process the payment and return to the main menu (page 1).

Click Back to return to the Process Approved Invoices screen (page 3 or 6) without processing the payment. fjtJSj Be sure your office includes the reference number with payment.

Page 7 Process Approved Invoices 1 "

Setup and Maintenance - Main Menu 1

Key Password to Access Setup and Maintenance - Main Menu 2

Choose a Selection from the File Maintenance Menu 3

Customer Profile Maintenance (Customize ARMS Web) 4

Adjuster Selection - Maintain Adjuster Files 5

Maintain Adjuster Files 6

Add an Adjuster 7

Setup and Maintenance - Main Menu

1) Key your claims office code in the Office field.

2) Key your last name in the Adjuster field.

3) Click Setup and Maintenance.

4) A password screen appears (page 2).

The zr_?t time you use the Setup and Maintenance screens, you will be prompted to create a password on the Customer Profile Maintenance screen (page 4). You can also change a password on the Customer Profile Maintenance screen. Once you have created a password, you will not be prompted on the Customer Profile Maintenance screen again.

Page 1 Setup and Maintenance Choose a Selection from the File Maintenance Menu

This File Maintenance Menu screen appears after the ARMS Web system accepts your password. There are two buttons from which to choose.

♦ Customer Profile File - Advance to the Customer Profile Maintenance screen to customize ARMS Web for your company's specific needs. Create or change your password (page 4).

♦ Adjuster Master File - Maintain adjustor mformation such as address and telephone number. You may also activate and deactivate an adjustor from the system (page 6).

1) Click the button (see descriptions above) you wish to choose.

2) Click Back to return to the mam menu (page 1 ).

Page 3 Setup and Maintenance Adjuster Selection - Maintain Adjuster Files

This Adjustor Selection pop-up window appears when you click Adjuster Master File on the File Maintenance Menu screen (page 3). There are two functions from which to choose.

♦ Maintain files for adjusters already authorized to ARMS Web.

♦ Add new adjusters to ARMS Web.

You can do one of the following:

1) Key the first few letters of a name in the Adjuster Last Name field, and click Search to find a particular adjustor.

OR

2) Click to highlight the adjuster you wish to select, and click OK to continue to the Adjuster Maintenance screen (page 6).

OR

3) _.Click Add an Adjuster to continue to the Adjuster Add screen (page 7). OR

4) CHck Back to return to the File Maintenance Menu screen (page 3) without selecting or adding an adjustor.

Page S Setup and Maintenance Add an Adjustor

This Adjuster Add screen appears when you click Add an Adjustor on the Adjustor Selection pop-up window (page 5).

1) Key the new adjuster's information on the appropriate lines.

All information is required except the last four digits of a nine-digit ZIP code and a telephone extension.

2) Click OK to add the adjustor to the ARMS Web system and return to the File Maintenance Menu (page 3). Click Back to return to the Adjuster Maintenance screen (page 6).

You can also click the following option button (Appendix, page 1):

Home - Return to the main menu (page 1 ).

Page 7 Setup and Maintenance 490

screens throughout ARMS Web.

Buttons - Overview 1

Rates : 2

Detail .....3

Message 4

Change Adj^'uster 5

Change Claims Office 6

Additional Charges 7

i »

Buttons - Overview

Buttons can guide you through the ARMS Web system quickly. This overview describes those buttons that are the same throughout each option. Screens that can be accessed only through a button are described on the following pages. Other buttons are defined within the options in which they are used.

Rates - Niew the rates, address, and phone number of the Enterprise office receiving the reservation.

Home - Return to the ARMS Web main menu.

Detail - Access screens to key or view more detail in a reservation/rental.

Message - Said a message to an Enterprise office.

Change Adjuster - Change the adjuster handling the file.

Change Claims Office - Change a claims office.

Additional Charges - Niew additional charges on a rental contract.

Appendix - Page 1 Buttons Detail

Additional Information in a Reservation Renter, Vehicle, Repair Facility, and Claim Information

This Create Reservation screen appears when you click Detail on the previous Create Reservation screen (Create a Reservation, page 2). It is also available in the Change Reservation/Rental and View Reservation/ Rental sections.

1) Key the renter's Last Name, First name, and work and/or home telephone numbers (required).

2) Key any other information you wish to include about the renter, vehicle, repair facility, or

coverage in the appropriate fields. Any previously keyed & information is retained and

3) Click Next to save this displays in the appropriate information and continue to fields. This applies to both the next Create Reservation detail screens. screen (below).

Additional Information in a Reservation Authorization, Rental Delivery Information, and Message

This Create Reservation screen appears when you click Next on the 1) If the Type is Insured or Theft, previous Create, Change, or View Reservation/Rental screen. the Daily and Maximum fields under Policy Coverage and the Number of Days field must be filled in. Click Rates to view rates (optional). If the type is Claimant, the Number of Days and Vehicle Rate fields must be filled in. Key the Phone Number Where Rental Is Needed, and use the drop-down arrow to select Yes if the rental is needed immediately or No if not (required).

2) Key any other information you wish to include about the authorization, rental delivery, and message.

3) Click Finish to process the reservation and return to the ARMS Web main menu (Introduc

tion, page v).

Appendix - Page 3 Buttons Change Adjustor

Use this Adjustor Selection screen to look up or change an adjustor assigned to a reservation/rental.

1) Click to highlight the name of the adjustor you wish to select.

To search for an adjustor by last name, key in the desired name and click Search.

2) Click OK to insert the adjuster's name m the appropπate fields. TTie name is locked in and carries forward to other screens of the authorization. Chck Back to return to the previous screen without selecting an adjustor.

Click Change Claims Office to transfer the reservation/rental to another claims office. A pop-up wmdow with a list of claims offices within your company displays (page 6).-

Appendix - Page 5 Buttons Additional Charges

Use this Additional Charges screen to authorize charges in addition to the price of the rental.

1) Click to select the type of surcharge in the Type column. Select from these three types:

♦ Daily (the amount authorized is charged on a daily basis).

♦ Rental (the amount authorized is charged once during the rental).

♦ Percentage (the amount authorized is a percentage charge, e.g., airport access fee).

2) Key the dollar amount or percentage you are authorizing in the Amount or Percent column to the right of the Type column.

3) Click OK to save these charges and,return to the previous screen. Click Back to return to the previous screen without authorizing any charges.

Once recorded, the information will be saved in the system but displays on this snjESionly when you click OK. Key over any existing information to make changes.

Appendix - Page 7 Buttons 496

Please be advised of the following update to the ARMS/400 program:

ARMS/400 adjusters now have a new way to view open rentals. We have added a new feature that allows adjusters to sort claims by repair facility when searching for rentals by the last authorized day. This enhancement will enable adjusters to proactively manage their files (or the entire office's files) by consolidating all of the rentals that require follow-up by repair facility.

This is what the Select Reservation/Rental screen currently looks like after you select Option 2 - Change Reservation Rental on the ARMS/400 Main Menu:

On the current screen, there is no way of sorting rentals by repair facility. The only sort available is by adjuster last name or the status of the rental.

08/15/00 Page 1

Updated Screen

The updated screen includes the field Sort by Repair Facility (see highlighted below).

All other filter options on this screen will remain the same. Please refer to your ARMS/400 User Guide for instructions on the other fields on this screen.

For this new feature, key the desired date in the Last Authorized Day field and Y (Yes) in the Sort by Repair Facility field. Press [ENTER]. Another new screen, Select Open Rentals by Repair Facility, appears (page 3).

08/15/00 Page 2

Select Open Rentals by Repair Facility Screen

The repair facilities appear in alphabetical order. To view a different repair facility, key the name in the Position to Repair Facility field and press [ENTER] .

To select a file, key 1 in the Sel (Select) field and press [ENTER]. The Change Reservation/Rental appears (page 4).

IF3| Exit

Return to the ARMS/400 Main Menu.

1_^~5| Previous Repairer

Move back to the previous repair facility (in alphabetical order).

[F6] Next Repairer

Move to the next repair facility (in alphabetical order).

[FI 2] Previous

Return to the Select Reservation/Rental screen (page 2).

08/15/00 Page 3

Change Reservation/Rental Screen

The Change Reservation/Rental screen has also been updated (see highlighted below).

The phone number of the repair facility and the vehicle being repaired have been added. For detailed instructions on the other fields, please refer to your ARMS/400 User Guide.

Note: These new fields will also be available on the View Reservation/Rental screen.

08/15/00 Page 4

Please be advised of the following update to the ARMS/400 program:

ARMS/400 is being enhanced with additions to Option 15 - On-Line Reporting. With these new features, more reports on rentals, broken down by adjuster, repair facility, or claim center, can be displayed on the screen.

Two new choices appear on the Select Report View Options screen:

• Closed in the Status field

• Summary in the Report Type field

The screen below is what the Select Report View Options screen currently looks like after Option 15 is selected on the ARMS/400 Main Menu.

On the current screen, closed ticket reports or summary report types were not available.

08/15/00 Page 1

Updated Screen

From the updated Select Report View Options screen, adjusters can now select summary reports and reports on closed tickets — in addition to all of the other reports they could previously access with Option 15 The fields still automatically default to I. You must key 2 to access the new choices on the menu

1 Key the desired sorting method.

2 Press i NTERl.

If 2 is keyed in the Status field and 1 is keyed in the Report Type field, a Closed Detail screen appears (page 3).

If 2 is keyed m the Status field and 2 is keyed in the Report Type field, a Closed Summary screen appears (page 5).

> Note: These are the only two screens that will be shown in this update Both will be sorted by Adjuster and Authorized Days For instructions on other screens, please refer to the ARMS/400 User Guide

08/15/00 Page 2

Closed Detail Screen

From the Closed Detail screen, adjusters can select an individual claim or simply look at the information provided on this screen.

1. Position to Adjuster Last Name - Key the first few letters of the last name of the adjuster whose claims you wish to view.

2. Press j ENTE R| to display the selected adjuster's name. The following fields are display-only (unless noted below):

Office Active - The first month with available reporting data. Range - The range of dates for the reporting data. These are two new fields on the screen. They are both prefilled in with default values. You can edit the Range field, but the Office Active field is view-only.

Adjuster Name - The adjuster in charge of the claims listed below. Claim Number - The claim number assigned to a particular renter. Typ - The type of claim (Mnsured, C=Claimant, T=Theft). Rate Auth - The rate of the vehicle authorized by the adjuster. Rent Days - The number of days the vehicle has been on rent. Auth Days - The number of days authorized by the adjuster. # of Ext - The number of extensions the adjuster has sent. Total Chgs - The total amount of charges on the rental contract.. Amt Rcvd - The amount of the payment received by Enterprise.

08/15/00 Page 3

Bill Amount - The amount of the rental bill.

Total - The number of contracts the adjuster is handling at this time

Avgs - The average numbers from the columns above.

3. Key 1 in the Sel (Select) field to choose a particular claim.

4. Press | ENTER|. The View Reservation/Rental screen appears Please refer to the ARMS/400 User Guide to view the View Reservation/Rental screen

Return to the Main Menu (page 1).

|F5| Previous Adj

Display the previous adjuster's (alphabetically) claims (if applicable)

|F6| Next Adj

Display the next adjuster's claims (if applicable)

|F9| Show Rentei

Display renters' names in place of the claim numbers

Return to the Select Report View Options screen (page 2).

08/15/00 Page 4

Closed Summary Screen

This Summary screen contains average totals for adjusters.

Position to Adjuster Last Name - Key the first few letters of the last name of the ad uster whose claims you wish to view

The following fields are display-only (unless noted below)

Office Active - The first month with available reporting data Range - The range of dates for the reporting data.

These are two new fields on the screen They are both prefilled in with default values. You can edit the Range field, but the Office Active field is view-only

Adjuster Name - The adjuster in charge of the claims. Tot Inv - The total number of invoices for this adjuster Rate Auth - The rate of the vehicle authorized by the adjuster. Rent Days - The number of days the vehicle has been on rent. Auth Days - The number of days authoπzed by the adjuster. # of Ext - The number of extensions the adjuster has sent Total Chgs - The total amount of charges on the rental contract A t Rcvd - The amount of the payment received by Enterprise Bill Amount - The amount of the rental bill Summary - The average of all of the columns above.

Return to the Mam Menu (page 1)

08/15/00 Page 5 Λ< 1 Jut I* L--. JS. . SiHSxf iβtjfKfcfflSJΛ¹

fri2| Previous

Return to the Select Report View Options screen (page 2).

08/15/00 Page 6 Enterprise Rent-A-Car

ARMS Web 3.0 Functional Design Specification

Extend Rental

Version 1.1

Last Saved: 9/28/002:55 PM

EXHIBIT E ARMS Redesign Project -Release 3.0 Issue: 1.1 Extend Rental Issue Date: 10/20/00

Revision History

Confidential Enterprise Rent-A-Car © 2000

Y:\APPS#AEl SWeb\AppHc-tion\A MS EBV3\@dkb\Function-l Spccs\ M2Extαι_Renut\Functioιι-l SpecsMA-12-FDS-ARMS eb3.0vl.l.doc ARMS Redesign Project - Release 30 Issue; ] j

Extend Rental Issue Date: 10/20/00

Table of Contents

1. Extend Rental Use Case

1.1 Application Overview

1.2 Brief Description

1.3 Use Case Actors

1.4 Pre-Conditions

1.5 Flow of Events

1.5.1 Activity Diagram 2

1.5.2 Basic Flow 3

1.5.3 Alternative Flows 3

1.6 Post-Conditions 4

1.7 Special Requirements 4 l.S Extension Points 4

1.8.1 MA- 16 Reassign USER/Office (Transfer) 4

1 8.2 MA-08 View Car Class 4

1.8.3 MA-15 Terminate Rental 4

1 8.4 MA-04 Send Message 4

2. Screen Design 5

2.1 Extend Rental Detail 5

2.1.1 Screen Layout -Extend Rental Detail 5

2.1.3 Extend Rental Detail 10

2.1.4 Screen Function Definition 11

Confidential Enterprise Rent-A-Car © 2000

Υ:\APPS\#AR SWebλAppU<^on\AR S EBV3\@ι_ b\Funcaon-I Specs\MA-12E] emlRent-l\Fιmctιonal Sper-s\MA-12-FDS-AHMSWeb3 Ovl 1 doc ARMS Redesign Project - Release 30 Issue: 1.1

Extend Rental Issue Date: 10/20/00

Extend Rental

1. Extend Rental Use Case

1.1 Application Overview

The following is a document used to illustrate the process for how the USER will extend a previously authorized rental using ARMS Web 3.0. The intent for this release of the ARMS/Web application is to reach a much wider audience. This application will target a Multi- Vendor, Multi-Segment, and International customer base.

1.2 Brief Description

This use case will describe how the USER will extend a previously authorized rental. The rental company (via an Authorization Request), the RENTAL ADMINISTRATOR (via a Customer Search), or Reporting (via the Callback feature) can initiate this use case.

1.3 Use Caβe Actors

The following actors will interact with this use case:

• RENTAL ADMINISTRATOR - The RENTAL ADMINISTRATOR will use the system to extend a previously authorized rental. This use case refers to a USER in the role of a rental administrator. There are various types of customers that the USER would represent, which include corporate account holders, car dealerships, insurance companies, and others.

• ARMS - The ARMS system will receive/send transactions to ARMS/Web to confirm the extended rental.

• RENTAL CAR. COMPANY - A wide variety of rental car companies will be able to use this system as well. Each company will have the ability to initiate and manage their rentals through the use of this application.

1.4 Pre-Conditions

• The USER must have logged into the ARMS Web system.

• The USER must have selected a previously authorized, open rental.

1.5 Flow of Events

The Flow of Events will include the necessary steps to make changes and updates to "Extend Rental".

Confidential Enterprise Rent-A-Car © 2000

Y-\APPS\#A!α--Weh\Applιc--on\ARMSWEBV3\(3dkb\ ιm-tιonal Specs\K^-12E)rtend ffital\F-nction-lSp--sV A-12.FDS-AE SW-b3 Ovl 1 do. ARMS Redesign Project - Release 3.0 Issue: 1.1 Extend Rental Issue Date: 10/20/00

1.5.1 Activity Diagram

Extend Rental Activity Diagram

Confidential Enterprise Rent-A-Car © 2000

Y\AEPSWARMSWeb\AppUc-non\ARMSWEBV3\@ kb\Flinction-l Specs\MA-l 2 Extend RentaKFimctional Specs\ A-12-EDS-A MSWeb3.0vl 1 doc ARMS Redesign Project - Release 3.0 Issue: 1.1 Extend Rental Issue Date: 10/20/00

1.5.2 Basic Flow

1. The system will display the details of the Rental.

2. The USER will enter the number of days to extend the rental.

3. The USER will submit the Extend Rental Details.

4. The system will validate the number of days the rental will be extended.

5. The system will update the ARMS/Web database with the Extend Rental Details.

6. The system will read the profile for the confirmation screen setting.

7. For non-Enterprise rentals, the extension is sent to the non-ERAC renal car company's rental system.

8. This ends the use case.

15.3 Alternative Flows

1.5.3.1 View Rental Notebook

At step 1 of the basic flow, the USER may choose to view the history of a rental. The USER will be able to see the diary notes associated with the Reservation / Rental.

1.5.3.2 Display Confirmation

After step 7, the USER may wish to have a confirmation page displayed, indicating that some type of change has taken place. The confirmation page is completely optional; therefore, at anytime the USER wants to set their profile to bypass this screen, he/she may do so.

1.5.3.3 Update USER Profile

During the confirmation process, the USER has the option of changing their profile setting to display or hide the confirmation page. Each time the setting is changed, the USER profile must be updated to reflect the new requirements set by the USER.

1.5.3.4 Validate Changes

If the USER changes or adds information, which does not pass validation, an error message will notify the USER and return them to step 1 of the Basic Flow.

If an eιτor is discovered in the validation of the reservation / rental information submitted by the USER, the system would present the USER with an error message and return them to the Detailed Reservation / Rental Display. If the error is specific to a data field within the form, the field shotild be highlighted and the error described.

15.3.5 Change Customer File

Prior to step 3, the USER has the option to make changes to the customer file. After clicking the change/add link, the screen will refresh with all editable fields opened and available for the USER to make changes.

15.3.6 Update ARMS/Web Database

After successfully validating the recent changes, the system must update the ARMS Web Database. The system goes through the same process as in the Basic Flow, as the database is updated to reflect the latest changes.

Confidential ' Enterprise Rent-A-Car © 2000

Y:\A WARrvEWeb\Arolication\AR SWEBV3\@*b ARMS Redesign Project -Release 3.0 Issue: 1.1

Extend Rental Issue Date: 10/20/00

1.6 Post-Conditions

• If the use case was successful then the rental has been extended and the ARMS/Web system has been notified.

• If the use case was unsuccessful then the system has remained unchanged.

1.7 Special Requirements

• The number of days to extend a rental must be an integer greater than zero.

• If a USER attempts to extend an insured rental beyond their limits for number of days and dollar amount, the system should return an error message.

1.8 Extension Points

1.8.1 MA-16 Reassign USER/Office (Transfer)

After the extend rental detail is displayed, the USER may choose to transfer the current office/USER. First, the USER would select to change the current office/USER. Second, the system would display a list of authorized offices USERs. Third, the USER would select a new office/USER. If additional changes are made to the customer file, the new data will also be passed through the transfer process.

1.8.2 MA-08 View Car Class

The View Car Class use case will be used to allow the USER to view details about and select a car class to apply to a reservation. Details will include the average number of passengers and luggage items that can be served by a vehicle in the specific car class. The car class selected by the USER should be applied to the reservation.

18.3 MA-15 Terminate Rental

After the extend rental detail is displayed, the USER may choose to terminate the rental. If termination is selected, the USER must enter a reason for the termination of the rental. Termination means the insurance company is no longer willing to pay for the rental.

18.4 MA-04 Send Message

The Send Message will be used to allow the USER to capture messages and diary notes associated with extending a rental. The USER can elect to either have the message sent to the rental company responsible for the reservation/authorization, or (Depending on the user segment if this option is available) to store the note in the ARMS/Web system without sending the message to rental company. All MESSAGES and DIARY NOTES captured must be related to a specific reservation/authorization.

Confidential Enterprise Rent-A-Car © 2000

Y:V^PS\#AK SWcb\AreU^on\ARMSWEBV3\@dkb\Fι-αςtioι-_ SpeαΛMA-12 Extend Rcntal\Funrtion-lSpecs\MA-12-FDS-ASMSW.b3.0vl.l.-oe ARMS Redesign Project - Release 30 Issue 1 1 Extend Rental Issue Date: 10/20/00

2. Screen Design

A defimtion of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above More than one screen may be used to implement support for the use case flow.

2.1 Extend Rental Detail

This screen will allow the USER to pick which functions that he/she may want to change

2.1.1 Screen Layout - Extend Rental Detail

wm fff^mvβss*

A*r-ftta**t b1κifβ*~ Nkjna f&K-fl>.».4l!Kfl. {>!«« et* hern

Confidential Enterprise Rent-A-Car © 2000

Y \APPSWARMSWeb\Applιcatιon AIlMSW-_-V3\@dkb mctjonal Sp∞ΛMA-12 Extend Rcntal\F_ncUon-l Spεcs\MA-12-PDS-ARMSWeb3 Ovl I doc ARMS Redesign Project - Release 3 0 Issue. 1.1 Extend Rental . Issue Date: 10/20/00

(Insurance User)

E tem Ren al^* for Bowie, Bavid Claim no.7B584932M0i <suaτθftΛi-B mε 2 of 4 Action Hems

[Chance or Ad-|

Bowie. David Home (773)564-6054 1735 N Paulina St Work (773)395^200 Chicago IL 50622 Email dbowιe@zefer com Requested email confiimation Aiffh-ri.ed Class Standard Rental Location* Days/Rate: 5 days @ $21 99/day Enterprise Edgewater Branch Current Oass. FuH-Size &I∞ N Ashland Additional Charges: Nona Chicago, -.60622 Direct Bill %: Nonβ 773-334-5400 Rental Date: 03/28 2000 Start Date: 0300/2000

Claim Number: 32323232323232323 Repair Facility:

Claim Type: Theft Elco Chevrolet

Insured Name: Lalumandier. Craig Chicago, IL6D621

Owner', vehicle: CMC Suburban 1999 (773)334-9832

Date of Loss: 03/28/2000

Loss Type: Noπ-Dπvable

Policy- Daily rate/

Maximum dollars: 30600

Nrømtoo*-

Message, Belanger, Hugues, 2GQ/00

Note from Enterprise, Sarussi, Marly.2/21/00

Extension Request, 224ΛB

Extension 2/25ΛD

^ top of page

Confidential Enterpπse Rent-A-Car © 2000

Υ \APPSWAM4S e_\AppUcanon\AM^VVEBV3\@dkbWUMhDi-α Specs\MA-12 Extend entalVFunction-l SpecsVMA 12 H3S-AR SWeb3 Ovl 1 d∞ ARMS Redesign Project - Release 3.0 Issue 1 1 Extend Rental Issue Date- 10/20/00

foSnd ental: for Bowie, David Claim no 765849322-001

2 of 4 Action Items

[Change orAd l

Bα ia, David Home (773)564-6054 1735 N Paulina St Work (773)395-6200 Chicago, IL 60622 Email dbo ιe@zefer com Requested email confirmation pEtiTAt. <wrosfc*Art<w* Authorized Class: Standard Rental Location: Days/Rate: 5 days @ 121 99 day Enterprise Edge ater Branch Current Class: Full-Size 5400 N Ashland Additional Charges: Nona Chicago, IL 60622 Rental Date: 0328/2000 773-334-5400 Start Date: O3/2O2OO0

AOCC-KHWAI. £ΛAϊS/t INWKMΛHOM αaim Number 32323232323232323 Repair Facility:

Claim Type: Theft Elco Chevrolet

Insured Name: Lalumandier, Craig Chicago, IL 60621

Owner's vehicle: G C Suburban 1999 (773)334-9832

Date of Loss: 0328/2000

Loss Type: Non-Onvable

Policy: Daily rate

Maximum dollars: 30/600

NOTSUOOK:

Message, Belanger, Hugues, 2000 Note from Enterpπse, Sarussi, Marly, 2/21/00 Extension Request, 2Q4 D0 Extension, 2/25/00

ft too of paqs

Cont-ct Ui I T«rou& Conditions | Loj Off

Confidential Enterprise Rent-A-Car © 2000

Y \APPS\#AR SWeb\Apphcahon\AB_vISWEBV3\@d b\Func onal Specs\MA-12 Extend RentalNFunctional Spe s\MA-12-FDS-ARMS Web3 Ovl 1 doc ARMS Redesign Project - Release 3.0 Issue: 1.1

Extend Rental Issue Date: 10/20/00 a termination date for this rental. This coincides with the use case MA-17-Terminate Rental.

2.1.4.5 Transfer File

When clicked, the USER will be taken to the Transfer File screen. This screen allows the USER to change the office or adjuster currently assigned to the customer file. The required information in the Extend Rental/Customer File will be passed to the Transfer File screen. Upon completion of the transfer, the USER will then be returned to the next action item or the profiled start page, depending on the screen from which the USER began.

2.1.4.6 Change or Add

When clicked, the system will refresh the current screen and make all editable fields in the bottom section (outside the gray box area) input capable. The changes on the top of the screen will not be lost.

2.1.4.7 Top of page

When clicked, the USER will be taken to the top of the current page.

2.1.4.8 View Car Class

When clicked, the USER will be taken to the View Car Class Use Case. No changes will be lost. Once the USER is finished with this use case, the USER will return to the Extend Rental Use Case.

2.1.4.9 Extend Rental

When clicked, the system will validate the input and accept the extension AND the changes made to the customer file. The ARMS/Web database will be updated. The use case will then end and the USER will return to the process from which they came.

Confidential Enterprise Rent-A-Car © 2000 ¹²

YΛAPPSWAR^WebVApplic-ti∞ KM^^ ARMS Redesign Project - Release 3.0 Issue: 1.1 Extend Rental Issue Date: 10/20/00

You fc_-t mOuHinή 3 -«mt -29 B/d8v far Hanla. TM

Ex π R6flt&I- fa Bαwte, l>avM rV-tι»»Ord«Nβ.765θ49322-001 CU8TOMIR FILE 2 af4Adle* NeιnB

[Charge or Add,

RtMTCR INTOΛ ATiON-.

Bowie. D«*d Home: (773)S6«054 1736N. Paulm SL Work: (773)395*200 Chicago, L60E22 EmaitdbowwQzifar.com Requested a al conirmation

Aatfceri.ed D-K Standard Rantal LOC-MMMI DiyriMK 6 day* θ *21 9θ/d»y Enterprise Edgewslei Branch Cwrant Om; F*Sta* 5400 N.AsNMd AddMl.nal Charg-r Wore Chicago, L 60622 Reatal Date: (0080000 773-334*400 Start Out: 030*2000

AtKXntN-AL CLAIM MTOftMATIOM

Parchaaa Order NanlMf: 3232323232323 Repair Facβey.

BI|-tøo: theft Eleo Chevrolet bicared aata Lalumandiar. Craig Chicago, LE0B21

Owmft veMda. GMC Subuiban 1999 (773*334-9632

Data a Loaκ CB/3BIXO0

L aaa Tyaa: Non-MMbta

PeBcy: Dally raaa/

MaKhnun deRers: 3KN

NorcnotM:

Maaaagt, Belanger, Hugυ.s, 20000

Not* torn Enterprise. Saiuaβi. Marty, 201ΛO

Extension Request.20400

Extension, 22&C0

« top of pane cnU-ik|τn.(CιM-W>| i-_fθf

Confidential Enterprise Rent-A-Cβr O 2000

YΛAPPS\*yθOJSWΛ\Ap_Pl at ιo\AR)JSWEBV3\@Λ*\F»κt^ Speα* A-12 Extend Reα !\Funct -ul Specs*JA-12-FDS-ARMSWeb3 Ovl 1 doe ARMS Redesign Project - Release 30 Issue 1 1 Extend Rental Issue Date: 10/20/00

Y»a iugt airthar!?£-i 3 days at S29-39f day for :tenfa. i c-ro

E π< Ren al; for Bowrle_t »a»td Corporate Class No.765B49322-001

2 of 4 Action Items

[Cbanee or Adόl

Bowie David Home (773)564-6054 1735 N Paulina St Work (773)39&6200 Chicago, IL 60622 Email dbowιe@zefer coin Requested email confirmation

Authorized Dass. St-ndard Rental Location: Days/Rate- 5 days @ $21 99/day Enterprise Edge ater Branch Current Class: Full-Size 5400 N Ashland Additional Charges; None Chicago, IL 50822 Rental Date: 03/28/2000 773-334-5400 Start Data 03/20/2000

Corporate Class Number.3232323232323 Loss Type Non-Dnvablβ Policy: Dairy rate/ Maximum dollars: 3O -0O

pjorsrøft*

Message, Belanger, Hugues, 2/2000

Note trom Enterpπse, Sarussi, Marty, 2V21 DO

Exlβnsion Request.2/24 DO

Extension, 2Q5.O0

O top of pane

Confidential Enterprise Rent-A-Car © 2000

Y \APPS\#ARMS cb\Appbca on\ARMSWEBV3\@ kb\Fιmcti!-a-l Sp ra\MA-12ExUaidRa-- \F-ncnonalSpccs\ A-12-rDS-ARMSWeb3 Ovl 1 doc ARMS Redesign Project - Release 3.0 Issue: 1.1 Extend Rental Issue Date: 10/20/00

2.1.3 Extend Rental Detail

Confidential Enterprise Rent-A-Car © 2000 10

Y:\APPSWA3lMSWΛ\AppUcι-ion\ARKβVVEBV3\@<lkb\Function-l Spc_s\MA-12 Extend R-ntaNPunction-l Spera\MA-12-FDS-ARMSWeb3.0vl.l.do- ARMS Redesign Project - Release 3.0 Issue: 1.1 Extend Rental Issue Date: 10/20/00

2.1.4 Screen Function Definition

This section includes the definitions for all functions that can be perfoπned within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.1.4.1 Skip

When clicked, the USER will be taken out of the use case without changing the current status of the request. Any changes made by clicking Change or Add and keying data in the bottom section will be saved.

2.14.2 Process

When clicked, the system will validate the input and accept the changes made to the customer file. The ARMS/Web database will be updated. The use case will then end and the USER will return to the process from which they came.

2.1.4.3 Notebook

When clicked, the USER will be taken to the Note Book section at the bottom of the screen to view all messages for this rental.

2.1.4.4 Set Last Date

When clicked, the system will terminate the rental. The USER will be prompted to enter

Confidential Enteiprise Rent-A-Car © 2000 11

Y:\APPSW AR SWeb\Applic-tion\ARMSWEB^'V3\@ kb\FunotiQr₁al Specs\MA-12 Extend Ra^\Fvmctioral Specs MA-12-FDS-ARMSWeb3.0vl.l.doc ARMS Redesign Project - Release 3.0 Issue: 1.1

Extend Rental Issue Date. 10/20/00

Confidential Enterprise Rent-A-Car © 2000 13

Y-\APPS\#AKMSWeb\Applicafioιι\AlUvISW-α3V3\@dkb\Fuιιotior.-l Spcc-\MA-12 Extend RβntalVF-n tion-l Specs\MA-12-FDS-ARM5Web3.0vl.l.doc Enterprise Rent-A-Car

ARMS Web 3.0

Functional Design Specification

Review List - Action Items

Version 1.1

Last Saved: 9/28/002:37 PM

ARMS Redesign Project - Release 30 Issue. vl 1 Review List - Action Items Issue Date: 10/20/00

Revision Histor

Confidential Enterprise Rent-A-Car © 2000

Y \APPSWARk-SVV-b\Applιc-ti(m\AEMSWEBY3\@d-b\Funcaon-l Specs\MA-l Review List Action ItemsΨuriction-l Specs\ A-l₄-FDS-ARMSWeb3 Ovl 1 doc ARMS Redesign Project - Release 3.0 Issue: vl.1

Review List - Action Items Issue Date: 10/20/00

Table of Contents

1. Review List Action Items Use Case 1.1 Application Overview

1.2 Brief Description

1.3 Use Case Actors

1.4 Pre-Conditions

1.5 Flow of Events

1.5.1 Activity Diagram 2

1.5.2 Basic Flow 3

1.5.3 Alternative Flows 3

1.6 Post-Conditions 3

1.7 Special Requirements 3

1.7.1 Sort Request 3

1.8 Extension Points 4 L8.1 MA-12-Extend Rental 4

1.8.2 MA-10-Authorize Request 4

1.8.3 Invoicing - BI-01-Handle Unapproved Invoices & BI-02-Pay Approved Invoices & BI-03 Reject an Invoice

1.8.4 MA-19-Customer File (Message) 4

2. Screen Design 2 2.1 Action Items 2

2.1.1 Screen Layout - Action Items 2

2.1.2 Action Items - Summary 3

2.1.3 Screen Function Definition 5

Confidential Enterprise Rent-A-Car © 2000

Y:\APPS\#ARMSWeb\ArφHc-dDn\ARMSW-_3V3 @ kb\Funcrion-! Spccs*-A-14 Review List Action Itc-n-\Fmcdon-l Speo-\MA-14-FDS-AR SW.b3.0vl.l.doc ARMS Redesign Project - Release 3.0 Issue: vl.I

Review List - Action Items Issue Date: 10/20/00

Review List - Action Items

1. Review List Action Items Use Case

1.1 Application Overview

The following is a document used to illustrate the process for how the USER would view and/or select any outstanding action items assigned to them using ARMS/ eh 3.0. The intent for this release of the ARMS/Web application is to reach a much wider audience. This application will target a Multi-Vendor, Multi-Segment, and International customer base.

1.2 Brief Description

This use case describes how the USER would view and/or select any outstanding action items assigned to them.

1.3 Use Case Actors

The following actors will interact with this use case.

• RENTAL ADMINISTRATOR - The RENTAL ADMINISTRATOR will use the system to review outstanding action items to be completed. This use case refers to a USER in the role of a USER. There are various types of customers that the USER would represent which include corporate account holders, car dealerships, insurance companies, and others.

• ARMS - The ARMS system will receive/send transactions to ARMS/Web based on actions of the USER, retrieving and acting action items.

• RENTAL CAR COMPANY - A wide variety of rental car companies will be able to use this system as well. Each company will have the ability to initiate and manage their rentals through the use of this application.

1.4 Pre-Conditions

• The USER must be logged into the ARMS/Web system.

• The USER must have selected to Review a List of Action Items.

• The system must retrieve and confirm the USER ID and access authority.

1.5 Flow of Events

The Flow of Events will include the necessary steps for an USER to review and assign outstanding action items.

Confidential Enterprise Rent-A-Car © 2000 1

Y:V^PS\#ARΛlSWeb Appli<^∞\A 2^W-_3V3\@d b\Fuιιction-l SpeαΛ A-M Review List Action Itemsφunctior-il SpecsMA-14-FDS-ARMSWeb3.0vl .l.doc ARMS Redesign Project - Release 3.0 Issue: vl.l Review List - Action Items Issue Date: 10/20/00

1.5.1 Activity Diagram

Review List Action Items

Confidential Enterprise Rent-A-Car © ₂000

Y:\APPS\#ARMSWeb\Application\AEMSWEBV3\@d b\Functιon-l Sp-cs\MA-l Review List Action Items\Functional Specs\MA-l -FDS-ARMSWeb3.0vl .l.doc ARMS Redesign Project - Release 3.0 Issue: vl .1

Review List - Action Items Issue Date: 10/20/00

15.2 Basic Flow

1. The USER selects to review the outstanding action items list.

2. The system retrieves the list of outstanding action items associated with the USER ID.

3. The system sorts and builds the list based on the appropriate USER profile.

4. The system will display a list of all outstanding action items assigned to the USER, which could include:

• Authorize a Request

• Extend a Rental

• Handle Unapproved Invoices/Pay Approved Invoices

• Send a Message

5. The USER will select an item from the action items list.

6. The system displays the detail appropriate to the action item status.

7. Upon completion of the selected action item, the system will determine the next action item and display until the current list has been completed.

8. This ends the use case.

1.5.3 Alternative Flows

1.5.3.1 Handle For A Different USER

Until step 5, the USER may choose to handle requests for another USER. At this time, the USER must select the appropriate USER to handle for. The system will then validate the ID of the alternate USER, and then rebuild the action item list to include all outstanding items associated with the new ID.

1.5.3.2 Re-sort Action Items List

After displaying the action item list using the default from the profile, the USER may decide to sort the list based on some other criteria. At any time, the USER may choose to re-sort the action item list (Depending on the USER segment) based on Item Type, Date Received, Renter's Name, Claim Number or Corporate Class Number or Purchase Order Number, Rental Company, and Administrator.

1.5.3.3 No Items Found

If there are no Action Items available for the USER work on, the system will display a message indicating that there are no available action items to display.

1.6 Post-Conditions

None

1.7 Special Requirements

1.7.1 Sort Request

The default sort order has been specified by the USERs profile, which governs the order in which action items have been presented. If invoices have been added to the USER'S payment list, a link displays for them to proceed to the 'Payment List'. Alternatively, after the last invoice has been approved, the system automatically proceeds to the 'Payment List' before resuming the outstanding action items. If the USER has been designated with the responsibility of handling the 'Unassigned Requests,' a link at the bottom of the action item list displays.

Confidential Enterprise Rent-A-Car © ₂000

Y:\APPSWARMSWeb\Application\AR SWEB V3\@dkb Functional Specs\MA-l Review List Action ItetnsWunction-l Specs\MA-l -FDS-ARMSWeb3-0vl .1.doc ARMS Redesign Project -Release 3.0 Issue- _{v\ \}

Review List - Action Items Issue Date: 10/20/00

1.8 Extension Points

An extension point indicates a link between this use case and another use case. Extension points associated with the use case are indicated below. Clicking on the extension point will open the related use case.

1.8.1 MA-12-Extend Rental

At step 5, the USER must select an action item to perform. At this point, the USER may elect to extend a previously authorized rental. Extensions may be perfoπned due to prolonged body shop delays and other scenarios. Upon completion of the Extend Rental process, the USER should be returned to step 5 of the Basic Flow. The action item that called for the extension should no longer appear in the USER's action item list

1.8.2 MA-10-Authorize Request

At step 5, the USER must select an action item to perform. At this point, the USER may elect to authorize a direct bill request Upon completion of the authorization, the USER should be returned back to step 5 of the Basic Flow. The request needing authorization should no longer appear in the USER'S action item list

1.8.3 Invoicing - BI-01 -Handle Unapproved Invoices & BI-02-Pay Approved Invoices & BI-03 Reject an Invoice

At step 5, the USER must select an action item to perform. At this point the USER may elect to pay approved invoices, handle unapproved invoices, or reject an invoice. Upon completion of this process, the USER should be returned back to step 5 of the Basic Flow. The invoices that were processed should no longer appear in the USER'S action item list.

1.8.4 MA-19 - View Customer File (Message)

At step 5, the USER must select an action item to perform. At this point, the USER may elect to view a message from the rental company. Upon completion of the message, the USER should be returned back to step 5 of the Basic Flow. The message should no longer appear in the USER's action item list.

Confidential Enterprise Rent-A-Car © 2000

Y:V\PPSWAR SWeb\ArφUc-non\AR SWEBV3>@ kb\ ιmclion-l SpecsV A-WReview List Action Items Function-l Specs\MA-14-FDS-ARMSWeb3.0vLl.doc ARMS Redesign Project - Release 3 0 Issue: vl.l Review List - Action Items Issue Date- 10/20/00

2. Screen Design

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Action Items

This screen will allow the USER to pick which functions that he/she may want to change.

2.1.1 Screen Layout - Action Items (ARMS/Web 2.0)

Confidential Enterprise Rent-A-Car © 2000 ²

Y \APPS\#AItMSWeb\Apph(^on\ARMSWEBV3\@dkb\Ft ctιorffll Specs\ A-l₄ Review List Action ItemsVFunctional SpecsV A-l FDS-AR SWebS Ovl 1 doc ARMS Redesign Project - Release 3 0 Issue- vl 1 Review List - Action Items Issue Date: 10/20/00

ACti rϊ Items: Welcome back, Fitzgerald, Nell.

(Fleet User)

Ctϊ r. ItβlTϊS Welcome back, Fitzgerald, Neil.

Confidential Eπterpπse Rent-A-Car © 2000 3

Y \APPS\#AR SWeb\AρρUc^^ Specs\MA-14 Review List Action Ite sΨunctional Specs\MA-14-FDS-ARMSWeb3 Ovl 1 doc ARMS Redesign Project - Release 30 Issue. vl 1 Review List - Action Items Issue Date. 10/20/00

(Dealership User)

ACtlOn ItβmS.: Welcome back. Fitzgerald, Neil.

«J Be-:om p:*M« find trβ aerie's rtnπ-ttrirt ftqtjirrs vour at-aitlor*

To Kottth- Action It-ms. clidcih- column lit)- of your chos-n sorting method («e to sort by data, ollot "DATE RECEIVED"!

•^ Ovor 24 hours old ϊ - N«w InformAtJon has com* In.

Contact Us | Terms-. Conditions | Loo Off

(Corporate User)

OtlOn Items. Welcome back. Fitzgerald. Neil.

OT B.!-m t«-«_ find ϊh* A tion it-ιra th Jrt .-quir* \our .r -ntio

Tosortth- Action Item-, cll tth- oolumn tilt- ofyoυt ohos-n sorting method (ex: to sort by djte. did. 'DATE RECEIVED*)

BEnrPB axrs

S- Extension 05-01-00 BΓJWIB. David 234587S71 HUE Rent-ACar Fitzgerald, NGII

Invoice 05-01-00 Weber. Andrew 754589877 Entβφnsβ Rβnk-vCar Fitzgerald, Neil

Payment List 06-15-00 (5\ Invoices Car Temps Fitzgerald. Neil

-^ Over 24 ho UK old

$51 N***infoπτ>«iJon has co * in

Con aoi Us j Terms & Conditions J Lop Off

Confidential Enterprise Rent-A-Car © 2000

Y \APP5WARMS eb\Apphca on\ARMSWEBV3\@tflcb\Functιonal Specs\ A-14 Review List Action Items\Functιonal Specs\MA-l FDS-ARMSWeb3 Ovl 1 doc ARMS Redesign Project - Release 3.0 Issue: vl.l Review List - Action Items Issue Date: 10/20/00

2.1.2 Action Items - Summary

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.1.3.1 Renter's Name

When clicked on a specific hyperlink under the "Renter's Name" heading, the USER will go into the details of that particular action item and will begin any of the following use cases:

• MA-12-Extend Rental

• MA-10-Authorize Request

• Invoicing - BI-01-Handle Unapproved Invoices & BI-02-Pay Approved Invoices & BI-03 Reject an Invoice

• MA-19-Customer File (Message)

Confidential Enterprise Rent-A-Car © ₂000

Y:\APPSWAR SW A\Appli(ation\ARMSWEBV3\( dkb\F«nctior- Sp-cs\MA-14 Review List Action ItemsVF-nctional Specs\ A-.4-FDS-ARMSWeb3.0vl...<-O- Enterprise Rent-A-Car

ARMS Web 3.0 Functional Design Specification

Assign a Request

Version 1.1

Last Saved: 9/28/004:07 PM

ARMS Redesign Project - Release 1.0 Issue: vl.l Assign a Request Issue Date: 10/20/00

Revision History

Confidential Enterprise Rent-A-Car © ₂000

Y:\APPSWAR -Web\ArφHcaJim\ARMSWra^ SpeαήMA-rø-Assign aRequestNFunctioiial Specs\MA-09-FDS-ARMSWeb3.0vl.l.doc ARMS Redesign Project -Release 1.0 Issue: vl.l

Assign a Request Issue Date: 10/20/00

Confidential Enterprise Rent-A-Car © 2000

Y:\APPS\#ARMSWeb\Appliration\AR SWEBV3 @dkb\Furι-tional Specs\MA-<»-Assign aRequest\Functional Specs MA-09-FDS-AR SWeb3.0vl.t.ιJoc ARMS Redesign Project - Release 1.0 Issue: vl .1

Assign a Request Issue Date: 10/20/00

Table of Contents

1. Assign a Request Use Case

1.1 Application Overview

1.2 Brief Description

1.3 Use Case Actors

1.4 Pre-Conditions

1.5 Flow of Events

1.5.1 Activity Diagram 2

1.5.2 Basic Flow 3

1.5.3 Alternative Flows 3

1.6 Post-Conditions 3

1.7 Special Requirements 3

1.8 Extension Points 3

1.8.1 MA-04 Send Message 3

1.8.2 MA-10 Authorize a Request 3

2. Screen Design 4

2.1 Action Items -Unassigned 4

2.1.1 Screen Layout -Action Items -Unassigned (ARMS Web 2.0) 4

2.1.2 Action Items - Unassigned 7 Screen Function Definition 7

Confidential Enterprise Rent-A-Car © 2000

Y:\APPS\#AR SWeb\Application\AR SWEBV3\@d b\ ιm-tion-l Specs\MA-0-LAssig_ a RequestΨvmction-lSp-cs\MA-09-FDS-ARMSWeb3.0vl.l.doc ARMS Redesign Project - Release 1.0 Issue: vl.l

Assign a Request Issue Date: 10/20/00

Assign a Request

1. Assign a Request Use Case

1.1 Application Overview

The following is a document used to illustrate the process for assigning the unassigned authorization requests to the appropriate user. The assignments will be made using the ARMS Web 3.0 system. The intent for this release of the ARMS Web application is to reach a much wider audience. This application will target a Multi-Vendor, Multi-Segment, and International customer base.

1.2 Brief Description

This use case describes the process of how a USER will review unassigned authorization request and assign them to a USER for further handling.

1.3 Use Case Actors

The following actors will interact with this use case:

• RENTAL ADMINISTRATOR - RENTAL ADMINISTRATOR will use the system to assign the unassigned authorization requests. This use case refers to a USER in the role of a rental administrator. There are various types of customers that the rental administrator would represent, which include corporate account holders, car dealerships, insurance companies, and others.

• ARMS - The ARMS system will receive/send transactions to ARMS Web to manage each phase of the rental process.

• RENTAL CAR COMPANY - A wide variety of rental car companies will be able to use this system as well. Each company will have the ability to initiate and manage their rentals through the use of this application.

1.4 Pre-Conditions

• The USER must be signed-on to the ARMS Web system.

• The USER should be authorized to assign a request.

• If there are unassigned requests present, the USER has selected the link from the Review List Action Items Use Case to enter this use case.

1.5 Flow of Events

The Flow of Events will include the necessary steps to make changes and updates to "Assign an Action Item".

Confidential Enterprise Rent-A-Car © ₂000 1

Y.\APPS\#Aiaι-SWeb\Appli<^on\ARMSWEB\^\@dl- \Functior_J Specs\MA-09^Assign oRequestVFunctional Sp-csV A-09-FDS-ARMSWeb3.0vl.l.doc ARMS Redesign Project - Release 1.0 Issue: vl.l Assign a Request Issue Date: 10/20/00

1.5.1 Activity Diagram

Assign An Action Item Diagram

Confidential Enterprise Rent-A-Car © 2000

Y:\APPS\#ΛRt^Web\AppU --ion\Al?MSW--9V3\@dJ-b\F_nction_l Specs\MA-09-Assign a equest\Function-l Spe«\ A4)9-FDS-ARMSWeb3.0vl.l.doc ARMS Redesign Project -Release 1.0 Issue: vl.l

Assign a Request Issue Date: 10/20/00

15.2 Basic Flow

1. The USER selects the unassigned authorizations link.

2. The system retrieves all unassigned request summaries.

3. The system retrieves all OFFICE IDs within ARMS Web.

4. The system retrieves all USER IDs within the OFFICE.

5. The system displays the unassigned authorization summaries with the offices and users.

6. The USER selects a user to assign to the request.

7. The system will update the ARMS Web database.

8. This ends the use case.

15.3 Alternative Flows

1.5.3.1 Cancel Use Case

The USER should be capable of leaving the use case at any point prior to assigning the of the reservation information.

15.3.2 Modify a Request

Before step 6 of the basic flow, the USER should be able to make changes to the authorization.

1.5.3.3 Select a different office

Before step 6 of the basic flow, the USER should be able to select a different office for this authorization request. If a different office has been selected, the user cannot assign the file to a new user. The new office must now assign the file.

1.6 Post-Conditions

If the use case is successful, the system will change the request type from an unassigned authorization request to direct bill. If the user has authority to authorize this request, the system will change the request to Authorized status and assign the adjuster picked in Step 5 of the basic flow.

If the use case is unsuccessful, the system state will remain unchanged.

1.7 Special Requirements

None

1.8 Extension Points

1.8.1 MA-04 Send Message

The Send Message fimction will be used to allow the user to capture messages and diary notes associated with a rental reservation/authorization. The USER can elect to have the message sent to the rental branch location responsible for the reservation authorization. The USER may also send a message without assigning the file to a user/office. All MESSAGES and DIARY NOTES captured must be related to a specific reservation/authorization.

18.2 MA-10 Authorize a Request

The USER may decide to enter into the full detail screen of the unassigned request, which would invoke the Authorize a Request use case.

Confidential Enterprise Rent-A-Car © 2000

Y:\APPS\#AEN-SWeb\AppUc-tion\AE SWEBV3\@d b\Function-l Specs\MA-09-Assign a RequesΛFunctional SpecsΦtt-09-FDS-AKMSW-b3.0vl.l.do- ARMS Redesign Project - Release 1 0 Issue vl 1 Assign a Request Issue Date 10/20/00

2. Screen Design

A defimtion of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above More than one screen may be used to implement support for the use case flow.

2.1 Action Kerns - Unassigned

This screen will allow the USER to assign action items to an office or USER The USER may also cancel an item or change specified information m the Customer File through this screen.

2.1.1 Screen Layout - Action Items - Unassigned (ARMS Web 2.0)

Yaa just apprβtf ed an Invoice for Crysta Silrv Tatai Amoun t£3S,13

Ac «tNiA 5n5 ittSsslroϊ -sDi:

Weber. Andrew

28445 Mam Avβ Claim Humber}7E458987? ^{' ■}l«"^~"3 Chicago, IL 60622 i !)! Λ.I, T jlJnassigπed 555-555-1212 Vehicle Condition j Select a Loss Type ^ Claim Type j Select a Claim Type jg

Note to Enterprise J_

Srnith. JOB ' jooi ϋ

28445 Main Ave Claim Humbeπ}^89877_ . Chicago IL 60622 A_3„" Ai,ι_^r {Unassigned 555-555-1212 Vehicle Condition j Select a Loss Type ^ Claim Type j Select a Ctoim T/ a _ |

Note to Enterprise |

Confidential Enterpπse Rent-A-Car © 2000

Y \APPSWARNlSWeb\Applic-tion\AR SWEBV3\@ l b\Function-l Spec-\MA-09-Assιgn Request\Fιmchonal Specs\MA-0StFDS-AR SW-b3 Ovl 1 doc ARMS Redesign Project - Release 1.0 Issue: vl.l Assign a Request Issue Date: 10/20/00

(Insurance User)

(Insurance Fleet)

Confidential Enterprise Rent-A-Car © 2000

Y:\APPS\#A MSWek\Ar^Ucation\ARMSWEBV3\@ kb\Furiction-l Specs\MA-(»-Assign a RequestXFunction-l Spec_\MA-09-FDS-ARMSWeb3.0vl.l.d β ARMS Redesign Project - Release 1.0 Issue: vl.l Assign a Request Issue Date: 10/20/00

(Dealership User)

(Corporate User)

Confidential Enterprise Rent-A-Car © 2000

Y:\APPS\#AR SW-b\AppUcati∞\ARl-SW^ ARMS Redesign Project - Release 1.0 Issue: vl.l Assign a Request Issue Date: 10/20/00

2.12 Action Hems - Unassigned

Claims Office: Output Office Id external N/A. organization abbreviated name

Handling For: Output 30 Handling for First Name + Last N/A. Adjuster's Name Name

Output 30 Renter's Name First Name + Last This should be a link. The USER Name should be able to get to the authorize page from this screen field

Output 30 Renter's Address Address Line

Output 10 Renter's City City

Output Renter's State State

Output 10 Renter's Zip Code Zip Code

Output 16 Renter's Home Phone Renters Night If these fields are populated, add a Phone + Renters label to the screen to differentiate Night Phone between Home Phone and Work Phone Extensin

Output 16 Renter's Work Phone Day Phone + If these fields are populated, add a Renters Day label to the screen to differentiate Phone Extension between Home Phone and Work Phone

Claim Number Input 30 Claim Number Insurance Claim N/A. Purchase Order Purchase Order Number, PO#, Number Number CC# Corporate Class Corporate Class Number Number

Vehicle List Box 15 Loss Type loss type Condition description

Claim Type List Box 15 Claim Type Rental type N/A. Bill Type Bill Type description

Date of Loss: Input 10 Date of Loss Date Of Loss N/A.

Note to Input 30 Message Text NOTE N/A. Enterprise

Assign to office: List Box Office Id external organization abbreviated name

Assign adjuster. List Box 30 Adjuster Name First Name + Last Lists only those adjusters the USER Name has authority to assign

Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.1.2.1 «Previous

When clicked, the USER will be taken back to the previous screen.

2.1.2.2 Process

When clicked, the USER will be taken to the next item in the action item list or a detail of the completed action items. This button ends the use case

Confidential Enterprise Rent-A-Car © 2000

Y:\APPSWARMSWsb\Applicaaon\AR^WEBV3^ ARMS Redesign Project - Release 1.0 Issue: vl .1

Assign a Request Issue Date: 10/20/00

2.1.2.3 Cancel

When clicked, the USER will be allowed to cancel the authorization. If this occurs, the rental becomes unauthorized and the rental is no longer responsibility of the company.

Confidential Enterprise Rent-A-Car © 2000 y:\APPS\#ARMSWeb\AH>Uc-tion\AKMSWEBV3\@dkb\Functional Specs\ A-09-As_igπ a Req est\Fιmctional Sp- s\MA-09-FDS-AE SWeb3.0vl.l.d-. Enterprise Rent-A-Car

ARMS Web 3.0 Functional Design Specification

View Car Class

Version 1.3

Last Saved: 9/27/00 9:33 AM

Confidential Enterprise Rent-A-Car © ₂000

Y:\APPS\#AR^-SWeb\AppUcation\ARMSWEBV3\@dkh\Functiorιal Sp«s\MA-08 View Car C]ass\Functior__ Specs\MA )8-FDS-ARMSWeb3.0vl.3.doc ARMS Redesign Project - Release 3.0 Issue: 1.3 View Car Class Issue Date: 10/20/00

Table of Contents

1. View Car Class Use Case 1

1.1 Application Overview 1

1.2 Brief Description 1 1.3 Use Case Actors 1 1.4 Pre-Conditions Error! Bookmark not defined. 1.5 Flow of Events 1

1.5.1 Activity Diagram 2

1.5.2 Basic Flow 3

1.5.3 Alternative Flows 3

1.6 Post-Conditions 3 1.7 Special Requirements 4

1.7.1 Modify Car Class Selection Results 4

1.8 Extension Points 4

Screen Design 5

2.1 Car Class Detail Screen 5

2.1.1 Screen Layout 5

2.1.2 Car Class Details 6

2.1.3 Screen Function Definition 7

3. Questions and Answers

Confidential Enterprise Rent-A-Car © 2000

YΛAPPSWAR S eb\AppIic-lion\AR SWEB 3\@dkb\FuncttonaI Specs\MA-08 View Car ClasΛFunction-. SpecsVMA-0S-EDS-ARMSWeb3.O .3.doc ARMS Redesign Project -Release 3.0 Issue: 1.3

View Car Class Issue Date: 10/20/00

View Car Class

1. View Car Class Use Case

1.1 Application Overview

The following is a document used to illustrate the process for how the USER would view examples of automobiles that are part of each rental company car class using ARMS/Web 3.0. The intent for this release of the ARMS/Web application is to reach a much wider audience. This application will target a Multi-Vendor, Multi-Segment, and International customer base.

1.2 Brief Description

This use case will allow the USER to view examples of automobiles that are part of each rental company car class. The USER will have the ability to select a car class and have the rate for the car class apply to the reservation/authorization.

1.3 Use Case Actors

The following actors will interact with this use case:

• RENTAL ADMINISTRATOR- The RENTAL ADMINISTRATOR will use the system to view and/or select the car class that will apply to a reservation. This use case refers to a USER in the role of a USER. There are various types of customers that the USER would represent, which include corporate account holders, car dealerships, insurance companies, and others.

• ARMS - The ARMS system will receive/send transactions to ARMS Web to retrieving information regarding the automobiles.

• RENTAL CAR COMPANY - A wide variety of rental car companies will be able to use this system as well. Each company will have the ability to initiate and manage their rentals through the use of this application.

1.4 Pre-Conditions

• The USER must be signed-on to the ARMS/Web system.

• The USER must have a reservation or open ticket selected.

1.5 Flow of Events

The Flow of Events will include the necessary steps to view and/or select the car class to apply to a rental reservation.

Confidential Enterprise Rent-A-Car © 2000

Y:\APPSWARMSWeb\Applica-ion\ARMS -_3 V3\@dk-\Functιon_l Specs\MA-0S View Car ClassVFunctional Specs\ A-08-FDS-AE SWeb3.0vl 3.doc ARMS Redesign Project - Release 3.0 Issue: 1.3 View Car Class Issue Date: 10/20/00

1.5.1 Activity Diagram

View Car Class Activity Diagram

Confidential Enterprise Rent-A-Car © 2000

Y:\APPS\#ARMSWeb\AppUcation\AR SWEBV3\@dl b\Functim-l Specs\MA-08 View Car ClassWurκtion-1 Spe<»\MA-08-FDS-ARMSWeb3.0vl.3.doc ARMS Redesign Project - Release 3.0 Issue: 1.3

View Car Class Issue Date: 10/20/00

1.5.2 Basic Flow

The Basic Flow of the View Car Class use case includes all of the required steps to view and/or select a car class for a rental reservation. If a car class is selected, it will be used to populate rate information on a rental authorization.

1. The USER will select View Car Class from the active reservation or open ticket.

2. The system will display a car class detail screen. If the USER had previously selected a car class (for example, on the Create Reservation screen), the car class selected will be displayed. If no car class has been selected, the system will display the Standard car class.

3. The USER will select the car class to apply to the reservation or open ticket.

4. The system will return the USER to the active reservation or open ticket and populate car class information based on the car class selected.

5. This ends this use case.

5.3 Alternative Flows

1.5.3.1 Select Alternate Car Class

From Step 2 of the Basic Flow, the USER will have the ability to view an alternate car class. The car classes that will be available to view include:

Economy

Compact

Intermediate

Standard

Full Size

Premium

If the USER selects an alternate car class, the system will refresh and present the details of the new car class.

1.5.3.2 Populate Car Class Rates

If a rental branch location has already been selected prior to entering this use case, the selection of a car class will populate the rates that apply to the selected car class on the active reservation or open ticket This alternate flow returns the USER to Step 4 of the Basic Flow.

1.6 Post-Conditions

• If successful, the selected Car Class will be returned to the active reservation or open ticket.

• If unsuccessful, the system state is unchanged.

Confidential Enterprise Rent-A-Car © 2000

Y:\APPSWAM^Web\Application\AEMSWEBV3\@ l b\Firrictional Specs\MA-08 View Car ClassVFunctjonal Specs\MA-08-FDS-ARMSWeb3.0vl.3.doc ARMS Redesign Project - Release 3.0 Issue: 1.3

View Car Class Issue Date: 10/20/00

1.7 Special Requirements

The additional requirements of the business use case are included here. These are requirements not covered by the flow as they have been described in the sections above.

1.7.1 Modify Car Class Selection Results

The USER may change the results of this use case as part of the active reservation or open ticket.

1.8 Extension Points

None.

Confidential Enterprise Rent-A-Car © 2000

Y:\APPS\#A SWeb\Apph(^on\ARMSWEBV3\@dkb\Function-l Specs\MA-08 View Cm ClassWunctional Specs\MA-08-FDS-ARMSWeb3 Ovl .3 doc ARMS Redesign Project - Release 3 0 Issue. 1 3 View Car Class Issue Date. 10/20/00

2. Screen Design

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Car Class Detail Screen

This screen will allow the USER to view detailed information about the rental company's car classes. The USER will also have the ability to select a car class to apply to a rental reservation / authorization.

2.1.1 Screen Layout

Confidential Enterprise Rent-A-Car © 2000

Y \APPSWAR SWeb\AppUcaU( \AW SλV-_BV3y8dkl⁾\Functιcιn-l Specs\MA-08 View Car ClassVFimetional Spe-s\MA-08-FDS-ARMSWeb3 Ovl 3 doc ARMS Redesign Project - Release 3 0 Issue: 1.3 View Car Class Issue Date: 10/20/00

2.1.2 Car Class Details

Confidential Enterprise Rent-A-Car © 2000

Y APPSWARMSWeb\^ιplιcatιorΛARMSWEBV3\@dkb\Fιmctιon-I Sρecs\MA-08 View Car ClassVFunctional Specs\ A-08-FDS-ARMSW-b3 Ovl 3 doc ARMS Redesign Project - Release 3.0 Issue: 1.3

View Car Class Issue Date: 10/20/00 tl

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.1.3.1 Select This Car Class

The Continue screen function will allow the USER to select the car class to apply to a reservation.

2.1.3.1.1 The Continue screen function is invoked through either abutton click or through an Enter keystroke.

2.1.3.2 Previous

The Previous screen function allows the USER to return to the previous screen.

2.1.3.2.1 The Previous screen function is invoked through a button click.

Confidential Enterprise Rent-A-Car © 2000

Y:\APPSWAK-_5WA\AppUc-tion\ARMSWEBV3\@dkb\Fuιιcti()n-l SpecsV A-08 View Car ClassVFunction-l Spec-\MA-08-FDS-AEMSWeb3.0vl.3.doc ARMS Redesign Project - Release 3.0 Issue: 1.3

View Car Class Issue Date: 10/20/00

Questions and Answers

None.

Confidential Enterprise Rent-A-Car © 2000

Y:\APPSWAR SWeb\Apptiι---m\AR SWEBV3\@ Enterprise Rent-A-Car

ARMS/Web 3.0

Functional Design Specification

Authorize a Request

Version 1.1

Last Saved: 9/26/00 10:50 AM

ARMS Redesign Project - Release 3.0 Issue: vl.l Authorize a Request Issue Date: 10/20/00

Confidential Enterprise Rent-A-Car © 2000

Y:\APPS\#AK^Web\Application\AE SWEBV3\@ lb\Fi--ction-l Spαs\ A-10-Auihoriz_ aRequest\Fιmction-l Specs\ A-IO-FDS-ARMSWeb3.0v .doc ARMS Redesign Project -Release 3.0 Issue: vl.l

Authorize a Request Issue D_at_e: 10/20/00

Table of Contents

1. Authorize Request Use Case

1.1 Application Overview

1.2 BriefDescription

1.3 Use Case Actors

1.4 Pre-Conditions

1.5 Flow of Events

1.5.1 Activity Diagram 2

1.5.2 Basic Flow 3

1.5.3 Alternative Flows 3

1.6 Post-Conditions 3

1.7 Special Requirements 3

1.7.1 Requirements for Claim Type Authorizations 3

1.7.2 Requirements for editable fields based on reservation /ticket status 4

1.8 Extension Points 5

1.8.1 MA-04 Send A Message 5

1.8.2 MA-07 Additional Charges 5

1.8.3 MA-16 Transfer Work 5

2. Screen Design 6

2.1 Authorize Rental Detail 6

2.1.1 Screen Layout - Authorize Rental Detail 6

2.1.2 Authorize Rental Detail 11

2.1.3 Screen Function Definition 12

Confidential Enterprise Rent-A-Car © 2000

Y:\APPSWARMSWeb\Application\A MSWEB V3\@d b\Fuπctional Spe sVMA-10-Authorize aRequest\Fu∞tion_l Specs\MA-10-FDS-ARMSWeb3.0vU.doc ARMS Redesign Project - Release 3.0 Issue: vl.l

Authorize a Request Issue Date: 10/20/00

Authorize a Request

1. Authorize Request Use Case

1.1 Application Overview

The following is a document used to illustrate the process for how a USER authorizes a direct bill request using ARMS/Web 3.0. The intent for this release of the ARMS/Web application is to reach a much wider audience. This application will target a Multi-Vendor, Multi-Segment, and International customer base.

1.2 Brief Description

This use case describes how a USER authorizes a direct bill request.

1.3 Use Case Actors

The following actors will interact with this use case:

• RENTAL ADMINISTRATOR- The RENTAL ADMINISTRATOR will use the system to authorize a direct bill request. This use case refers to a USER in the role of a rental administrator. There are various types of customers that the USER would represent, which include corporate account holders, car dealerships, insurance companies, and others.

• ARMS - The ARMS system will receive/send transactions to ARMS/Web to confirm the direct bill request.

• RENTAL CAR COMPANY - A wide variety of rental car companies will be able to use this system as well. Each company will have the ability to initiate and manage their rentals through the use of this application.

1.4 Pre-Conditions

• The USER must be logged into the ARMS Web system.

• The USER must have the authority to authorize a request.

• At least one outstanding unauthorized direct bill request must be assigned that the USER may handle.

• The USER must have selected an Unauthorized Direct Bill Request from the Review Action Items Screen or from the Search Results page.

1.5 Flow of Events

The Flow of Events will include the necessary steps to make changes and updates to "Authorize Request"

Confidential Enterprise Rent-A-Car © 2000

Y \APPS\*IA K-SWeb\ArφUc-non\ARMSWEBV3\@dkb\Function-l SpecsVMA-10-Authoπzβ aRequestψunction&l Sp-cs\MA-10-FDS-AR SWeb3 Ovl 1 doo ARMS Redesign Project -Release 3.0 Issue: vl.l Authorize a Request Issue Date: 10/20/00

1.5.1 Activity Diagram

Authorize A Request Activity Diagram

Confidential Enterprise Rent-A-Car © 2000

Y:\Am\#AK^WebV\ppBcation\ARMSWEBV3\@^ ARMS Redesign Project - Release 3.0 Issue- _vl .1 Authorize a Request Issue Date. 10/20/00

1.5.2 Basic Flow

1. The USER selects an outstanding direct bill to authorize.

2. The system displays the Customer file.

3. The USER reviews the renter's information.

4. The USER inputs a number of Authorized Amounts, days and required fields.

5. The USER submits the Authorization.

6. The system validates information in the Customer File.

7. If the USER assigned to the Customer File is 'UNKNOWN' or 'UNASSIGNED', the System will assign the Customer File to the current USER.

8. The system will update the ARMS/Web database with the Authorization.

9. The System reads the USER profile to see if the confirmation page should display.

10. If the profile indicates 'Show Confirmation Page', the System will display the confirmation page

11. For non-Enterprise rentals, the authorization request is sent to the non-ERAC rental car company's rental system.

12. This ends the use case.

1.5.3 Alternative Flows

1.5.3.1 View Notebook

At step 3 of the Basic Flow, the USER can select to view the transaction history (Notebook) by selecting the Go To Notebook link.

1.5.3.2 Add Notes to Customer File

At step 3 of the Basic Flow, the USER can add notes to the Customer File by typing in the appropriate notes field on the Customer File page.

1.5.3.3 Skip Customer File

At step 3 of the Basic Flow, the USER can get out of the Customer File by selecting the skip button on the Customer File page.

1.5.3.4 Change Customer File

At step 3 of the Basic Flow, the USER can make changes to the additional details of the Customer File. This is done by selecting the Add / Change link which will invoke an editable page with all ^♦appropriate information editable.

1.6 Post-Conditions

• If the use case was successful then the changes should go into effect immediately and the screen should revert back to the original screen of entry.

• If the use case was successful, then the ARMS/Web system will be notified of authorization changes.

• If the use case was unsuccessful then the system state will be unchanged.

1.7 Special Requirements

1.7.1 Requirements for Claim Type Authorizations (Insurance Users Only)

The following are a set of requirements surrounding the type of authorized amounts that are allowable based on the Claim Type associated with a rental. These restrictions DO NOT APPLY to reservations that are submitted with a Direct Billing Percentage of zero (0).

1.7.1.1 When the Claim Type selected is 'Insured', 'Theft', or 'Uninsured Motorisf

1.7.1.1.1 For insurance USERs, the reservation/rental must always include an Authorized Rate or both Policy Daily and Maximum Limits as defined by the renter's insurance policy. Zero (0) is an acceptable Policy Daily Limit.

1.7.1.1.2 For insurance USERs, the reservation rental must include an Authorized Rate

Confidential Enterprise Rent-A-Car © 2000 ³

Y\APPS\#AIUklSWeb\Apphcatιon\AIU^WEBV3\@dkbΨm^ Specs\UA-10-FDS-ARMSWeb3 Ovl 1 doc ARMS Redesign Project - Release 3.0 Issue: vl.l Authorize a Request Issue Date: 10/20/00 or Policy Daily Limit if a Policy Maximum Limit is included. Zero (0) is an acceptable Policy Daily Limit.

1.7.1.2 When the Claim Type selected is 'Claimant' (Insurance Users Only)

1.7.1.2.1 The reservation/rental must always include an Authorized Rate.

1.7.1.2.2 The reservation/rental may not include a Policy Daily/Maximum Limits selection.

1.7.1.3 Requirements tor editable fields based on reservation / ticket status

1.7.1.3.1 Depending on the status of the Customer File the USER may change the following fields:

If the Customer File is an Unauthorized Reservation, the USER can Reject the Authorization Request, Send a Message, and/or Transfer (Assign) the file to a USER

Confidential Enterprise Rent-A-Car © 2000

ARMS Redesign Project - Release 3.0 Issue: vl.l Authorize a Request Issue Date: 10/20/00

1.7.1.3.2 If the status of the Customer File is an open ticket the following rules apply:

1.8 Extension Points

An extension point indicates a link between this use case and another use case. Extension points associated with the use case are indicated below. Clicking on the extension point will open the related use case.

1.8.1 MA-04 Send A Message

The Send Message will be used to allow the USER to capture messages and diary notes associated with extending a rental. The USER can elect to either have the message sent to the rental company responsible for the reservation/authorization, or (Depending on the USER segment if this option is available) to store the note in the ARMS/Web system without sending the message to rental company. AU MESSAGES and DIARY NOTES captured must be related to a specific reservation/authorization.

1.8.2 MA-07 Additional Charges

The USER may choose to select the additional charges button that displays a page showing all the additional items at the branch with the branch charges displayed. The USER can select the items and enter in the authorized amounts.

1.8.3 MA-16 Transfer Work

The USER may choose to transfer an authorization to a different USER in his/her office or transfer the authorization to another USER in a different office.

1.8.4 MA-08 View Car Class

The USER may choose to view the car class. This button invokes the View Car Class use case.

1.8.5 MA-17 Cancel Authorization

The USER may choose to deny the authorization. When the USER selects the CANCEL button, it will invoke the Cancel Authorization use case to reject the authorization.

Confidential Enterprise Rent-A-Car © 2000

Y:\APPSWAR SWeb\Applic-tion\AK^Wr-B^ ARMS Redesign Project -Release 30 Issue- vl 1 Authorize a Request Issue Date: 10/20/00

2. Screen Design

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Authorize Rental Detail

This screen will allow the USER to work the currently selected authorization request. The USER (Depending on the USER segment) may set the authorization amounts and policy coverage limits or may assign the request to another USER.

2.1.1 Screen Layout - Authorize Rental Detail (ARMS/Web 2.0)

Confidential Enterpπse Rent-A-Car © 2000

Y \APPSWAR ^Web\App cahon\AIO^WEBV3\@dkb\FractionaI Spe« ARMS Redesign Project - Release 3 0 Issue: vl 1 Authorize a Request Issue Date: 10/20/00

OϊreGt BUI. for Haate, lorn Claim no 765849322-001 C USTOM -R F»S. a 1 of 4 Action Items

[Change or Add]

Hanks, Tom Home- (773)564-6054 1735 N. Paulina St. Work (773)395-6200 Chicago, IL 60622 Email: thanks@zefer. com Requested email confirmation

Bt-NtΛi. mfθmwsi.ri< : Rental Location:

Enterprise Edgewater Branch 5400 N. Ashland Chicago, IL 60622 773-334-5400

Direct Bill request for Hanks, Tom 4/23/00 ^Q top of page

Contact Us | Terms -. Conditions | Log Off

Confidential Enterprise Rent-A-Car © 000

Y \APPS\#ARMSWeb\A^⁾pllC-bon\ARMSWEBV3 @d b\Functlon-l SpecsVMA-.O-Authoπze a RequesftFunctK-ial Specs\MA-10-FDS-ARMSWeb3 Ovl 1 doc ARMS Redesign Project - Release 3.0 Issue: vl 1 Authorize a Request Issue Date 10/20/00

@ Dir8Ct Billϊ for Hanks, I em Claim no 765849322-001

CU STGM SFt FJL2 1 of 4 Action Items

|Change orAdd)

Hanks, Tom Home (773)564-6054 1735 N Paulina St. Work. (773)395-6200 Chicago, IL 60622 Email thanks@zefer com Requested email confirmation

Rental Location:

Enterprise Edgewater Branch 5400 N Ashland Chicago, IL 60622 773-334-5400

Direct Bill request for Hanks, Tom 4 23/00 O top of page

Contact Us | Terms-. Conditions | Log Off

Confidential Enterprise Rent-A-Car © 2000

Y \APPS\#ARMS eb\Apphcatιon\ARMSWEBV3\@dlcb\Functιonal Specs\MA-.0-Authoπze a Rcquestψunctional Sp_c_\MA-l 0-FDS-ARMSWeb3 Ovl 1 doc ARMS Redesign Project - Release 30 Issue vl 1 Authorize a Request Issue Date: 10/20/00

AUtJhOfJtø® OireGt BUI; for Hanks, Tom Purchase Order No.765B49322-001

CUSTOM ER ?. -,-. 1 of 4 Action Items

[Change or Add)

Hanks, Tom Home (773)564-6054

1735 N. Paulina St. Work: (773)395-6200

Chicago, IL60S22 Emaillhanks@zefer. com Requested email confirmation

Rental Location:

Enterprise Edgewater Branch 5400 N. Ashland Chicago, IL 60622 773-334-5400

Direct Bill request for Hanks, Tom 4/23/00 a top of page

Contact Us I Terms & Conditions | og Off

Confidential Enterprise Rent-A-Car © 2000

Y \APPS\*ARl--5Web\Ar^jphc-tton\ARMSWEBV3\@d-;b\Fιιncnon-l Spccs\MA-10-Authonze a RequestVFuncnonal SpecsVMA-10-FDS-ARMSWeb3 Ovl ] doc ARMS Redesign Project - Release 3.0 Issue. vl.l Authorize a Request Issue Date: 10/20/00

OW t Slliϊ for Hanks, Tom Corporate Class No.765849322-001 CUSTOME R psta. 1 of 4 Action Items

[Change or Add)

Hanks, Tom Home (773)564-6054 1735 N. Paulina St Work (773)395-6200 Chicago, IL 60622 Emaιl-thanks@zefer com Requested email confirmation

BKNTAΪ, SNFOBSWAn .; Rental Location:

Enterprise Edgewater Branch 5400 N. Ashland Chicago, IL 60622 773-334-5400

Direct Bill request for Hanks, Tom 4/23/00 O top of page

Contact Us | Terms -. Conditions | Log Off

Confidential Enterprise Rent-A-Car © ₂000 1

Y \AIΨS\#ASMSWeb\Apph --ιon\ARMS EBV3\@d b\Funct-on-l Specs\MA-10-Authonze aRκμestVFιmctιon-1 Specs\MA-10-FDS-ARMSW.b3 Ovl 1 doc ARMS Redesign Project - Release 3.0 Issue: vl.l Authorize a Request Issue Date: 10/20/00

2.1.2 Authorize Rental Detail

Confidential Enterprise Rent-A-Car © 2000 ^l

Y:\APPSWAR SWeb\Application\ARMSWEB V3\@dkb\Fmction-lSpecs\MA-10-Ai-to

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.1.3.1 Skip

When clicked, the USER will be taken out of the use case without changing the current status of the request. Any changes made by clicking Change or Add and keying data in the bottom section will be saved.

2.1.3.2 Process

When clicked, the system will validate the input and accept the changes made to the customer file. The ARMS/Web database will be updated. The use case will then end and the USER will return to the process from which they came.

2.1.3.3 Notebook

When clicked, the USER will be taken to the Note Book section at the bottom of the screen to view all messages for this rental.

2.1.3.4 Set Last Date

When clicked, the system will terminate the rental. The USER will be prompted to enter a termination date for this rental. This coincides with the use case MA-17-Terminate Rental.

Confidential Enterprise Rent-A-Car © 2000 1

YΛAPPS\#ARMSWeb\Application\AR SWEBV3\@d b\Fr^ ARMS Redesign Project -Release 3.0 Issue: vl.l Authorize a Request Issue Date: 10/20/00

2.1.3.5 Transfer File

When clicked, the USER will be taken to the Transfer File screen. This screen allows the USER to change the office or USER currently assigned to the customer file. The required information in the Extend Rental/Customer File will be passed to the Transfer File screen. Upon completion of the transfer, the USER will then be returned to the next action item or the profiled start page, depending on the screen from which the USER began.

2.1.3.6 Change or Add

When clicked, the system will refresh the current screen and make all editable fields in the bottom section (outside the gray box area) input capable. The changes on the top of the screen will not be lost.

2.1.3.7 Top of page

When clicked, the USER will be taken to the top of the current page.

2.1.3.8 View Car Class

When clicked, the USER will be taken to the View Car Class Use Case. No changes will be lost. Once the USER is finished with this use case, the USER will return to the Extend Rental Use Case.

Confidential Enterprise Rent-A-Car © 2000

Y:\AH>SWARMSWeb\Applicari∞V^RhβWEBV3\@dkb\Functio--α Spe∞V A-lO-Authorize aRequest\Funtfion-l Spscs\MA-10-FDS-A MSWeb3.0vU.doc Enterprise Rent-A-Car

ARMS Web 3.0

Functional Design Specification

Create Reservation

Version 1.4

Last Saved: 9/22/00 10:36 PM

ARMS Redesign Project - Release 2.0 Issue: vl.4 Create Reservation Issue Date: 9/22/2000

Revision Histor

Confidential Enterprise Rent-A-Car © 2000

ARMS Redesign Project - Release 2.0 Issue: vl.4

Create Reservation Issue Date: 9/22/2000

Table of Contents

1. Create Reservation Use Case

1.1 Application Overview

1.2 Brief Description

1.3 Use Case Actors

1.4 Pre-Conditions

1.5 Flow of Events

1.5.1 Activity Diagram 2

1.5.2 Basic Flow 3

1.5.3 Alternative Flows 4

1.6 Post-Conditions 6

1.7 Special Requirements 6

1.7.1 Requirements for Reference Number Formatting 6

1.7.2 Requirements for Finding Rental Location 7

1.7.3 Requirements for Routing a Reservation 8

1.7.4 Maintenance of Source Systems 9

1.8 Extension Points 10

1.8.1 MA-10 - Authorize Request 10

1.8.2 MA-19 - View Customer File 10

1.8.3 MA-02- Find Rental Location 10

1.8.4 MA-04-Send Message 10

1.8.5 MA-07-Additional Charges 10

1.8.6 MA-08-View Car Classes 10

2. Screen Design 11

2.1 Initial Reservation Screen 11

2.1.1 Screen Layout 11

2.1.2 Screen Field Definition 14

2.1.3 Screen Function Definition 14

2.2 Authorization Matches Found Screen 15

2.2.1 Screen Layout (ARMS Web 2.0) 15

2.2.2 Screen Field Definition 18

2.2.3 Screen Function Definition 19

2.3 Quick Reservation Screen 20

2.3.1 Screen Layout (ARMS Web 2.0) 20 (Insurance User)(FIeet User) 21 (Fleet User) 22

2.3.2 Screen Field Definition 25

2.3.3 Screen Function Definition 29

2.4 Reservation Confirmation Screen 31

2.4.1 Screen Layout (ARMS Web 3.0) 31

2.4.2 Screen Field Definition 34

2.4.3 Screen Function Definition 34

Confidential Enteφrise Rent-A-Car © ₂000

Y:\APPS\#ARMSWeb\/ψpli<atiorι\ARMSWEBV3\@dkb\F nction-l Specs\MA-01-Creatc ReservationVFurjcrion-l Spe_sVMA-01-FDS-ARMSWeb3.0vl. .doc ARMS Redesign Project - Release 2.0 Issue: vl.4

Create Reservation Issue Date: 9/22/2000

Create Reservation

1. Create Reservation Use Case

1.1 Application Overview

The following is a document used to illustrate the process for creating a reservation using ARMS Web 3.0. The intent for this release of the ARMS Web application is to reach a much wider audience. This application will target a Multi-Vendor, Multi-Segment, and International customer base.

1.2 Brief Description

This use case describes how a USER would create a rental reservation in the ARMS Web system. When creating a reservation, the USER is also creating an authorization for payment. The USER may also submit a reservation without authorizing payment.

1.3 Use Case Actors

The following actors will interact with this use case:

• RENTAL ADMINISTRATOR - The RENTAL ADMINISTRATOR will use the system to create an authorized reservation. This use case refers to a USER in the role of a rental administrator. There are various types of customers that the rental administrator would represent, which include corporate account holders, car dealerships, insurance companies, and others.

• ARMS - The ARMS system will receive/send transactions to ARMS Web to create and confirm the reservation.

• RENTAL CAR COMPANY - A wide variety of rental car companies will be able to use this system as well. Each company will have the ability to initiate and manage their rentals through the use of this application.

1.4 Pre-Conditions

• The USER must be signed in to the ARMS Web system.

• The USER must have the authority to create a reservation.

1.5 Flow of Events

The Flow of Events includes all steps necessary to create a reservation using the ARMS Web system.

Confidential Enterprise Rent-A-Car © ₂000

Y:\APPSW ARMSWeb\Arψlic-tion\ARM5WEBV3\@d b\Fιιn tioιιal Specs\MA-01-Cre_te ReservatioώFunctional Specs\MA-01-FDS-ARMSWeb3.0vl Adoc ARMS Redesign Project - Release 2.0 Issue: vl.4 Create Reservation Issue Date: 9/22/2000

1.5.1 Activity Diagram

Create Reservation Activity Diagram

Confidential Enterprise Rent-A-Car © 2000

Y:\APPS\#ARMSWeb\AppUcalion\ARMSWEBV3\@dlcb\Funcrion-l Specs\MA )l -Create ResemtionVFunctional Specs\MA-01-FDS-A SWeb3.0vlAdoc ARMS Redesign Project - Release 2.0 Issue: vl .4

Create Reservation . Issue Date: 9/22/2000

1.5.2 Basic Flow

The Basic Flow of the Create Reservation use case includes all of the required steps for a new reservation to be created in the ARMS Web system. Shadowed boxes in the Activity Diagram indicate the Basic Flow.

1. The USER selects to create a reservation from the top navigation menu.

2. The system prompts the USER to enter initial information about the renter (Depending on the user segment):

• Corporate Class Number or Claim Number (The use case will refer to this as 'Reference Number')

• Bill Type

• Renter First Name

• Renter Last Name

• Rental Company

• Telephone Number or Postal Code where the renter would like to be picked up

3. The USER enters initial information about the renter.

4. The USER submits the initial reservation information to the system.

5. The system will validate the initial information entered by the USER¹.

6. The system will perform a search for previous authorizations that may correlate directly to the rental reservation that the USER is beginning to establish. The system will search for two key types of records:

• Unauthorized Request Matches

An Unauthorized Request is defined as a rental Authorization Request that is generated when The Rental Company creates a reservation or contract for the customer that has not been approved. This search helps to prevent the USER from creating a new reservation for a customer that has an outstanding Unauthorized Request in the ARMS system. The Unauthorized Request search is completed using the first three characters of t t Renter Last Name and is limited to unauthorized requests (requests in unassigned or direct bill request statuses) for the selected Office. If matches are found, the Unauthorized Request/Authorized Request Search Matches Alternative Flow will be invoked.

• Authorized Matches

Reference numbers that have already been associated with a rental reservation or contract (i.e., Authorized Rentals) should be brought to the attention of the USER to help prevent over-authorization situations. The system will search for an exact corporate class number match on any reservation or ticket (open or closed) related to the company in the last six months. This search will be completed using the exact Reference Number on all authorized requests (requests in any status other than unassigned or direct bill request).

If no matching records are found, the Basic Flow continues.

7. The system will retrieve a rental branch location where the rental is needed based on the Telephone Number or Postal Code entered by the USER If no location is found, a message should be generated notifying the USER that no location was available for the search criteria and that Claims Connection will handle the reservation (include the search criteria in message).

¹ See section 1.5.3.1 Initial Reservation Information Invalid in Alternative Flows on page 4 for validation rules.

Confidential Enterprise Rent-A-Car © 2Q0Q ³

Y:\APPS\#ARl^ eb\Applic-tion\ARMSWE-.V3\@d b\Function-l Specs\ A-01-Cre-te Reserv-tiorfOFunction-l Sp.cs\MA-01-FDS-AR SWcb3.Ovl. .d∞ ARMS Redesign Project - Release 2.0 Issue; _{v j} 4

Create Reservation Issue Date: 9/22/2000

8. The system will retrieve the current applicable rates for that rental branch location. If no rental branch location is available, the system will display an open text box to allow the USER to type in a rate.

9. The system will display the Quick Reservations screen.

10. The USER will enter the reservation information.

11. The USER submits the reservation to the system.

12. The system will validate the reservation information submitted by the USER².

13. The system updates the database.

14. The system sends the reservation to ARMS.

15. The system will display the reservation confirmation to the USER The reservation confirmation will not include a confirmation number, but will incorporate a message that The Rental Company has received the reservation.

16. If the reservation is a non-Enterprise reservation, than the transaction is electronically transmitted to the intended rental car company's rental system.

17. This ends this use case.

1.5.3 Alternative Flows

The Alternative Flows of this use case can occur when certain conditions exist or specific USER feedback is provided.

1.5.3.1 Initial Reservation Information Invalid

If the initial reservation information is invalid (Step 5 of the Basic Flow), the system should present an error message to the USER and force the USER back into Step 2 of the Basic Flow.

1.5.3.1.1 It will be considered invalid if the Reference Number, Renter First Name, Renter Last Name, Rental Company, or Where Needed Value (Postal Code or Telephone Number) have not been included.

1.5.3.1.2 It will be considered invalid if the 'where needed' search criteria is a U.S. or Canadian telephone number and the first three digits (i.e., area code) meet the criteria below:

• 0XX

• 1XX

• The second and third digits equal (e.g., 800, 877, 888, etc.)

Where X equals any digit 0 through 9.

1.5.3.1.3 It will be considered invalid if the 'where needed' search criteria is a U.S. or Canadian telephone number that does not consist of 10 digits.

1.5.3.1.4 It will be considered invalid if the 'where needed' search criteria is a U.S. postal code that does not consist of 5 or 9 digits.

2 . _*

See section 1.5.3.3 Reservation Information Invalid in Alternative Flows on page 5 for validation rules.

Confidential Enterprise Rent-A-Car © 000

Y:\APPSWARl tSWeb\AppUcadon\Al-MSWEB V3\@d b\Function-l Specs\ A-01 -Create Reservarion\Functional Specs\MA-01-FDS-ARMSWeb3.0vl. .doc ARMS Redesign Project - Release 2.0 Issue: vl.4

Create Reservation Issue Date: 9/22/2000

1.5.3.1.5 It will be considered invalid if the 'where needed' search criteria is a Canadian postal code that does not consist of 6 alphanumeric characters in the format AXAXAX where A is an alpha character and X is a digit between 0 and 9.

1.5.3.2 Unauthorized Request/Authorized Request Search Matches

If either the search for Unauthorized Requests or the search for Authorized Request matches returns a positive result (Step 6 of the Basic Flow), the matching records will be presented to the USER The matching records should be provided in summary form, and be distinctly identified as either Authorized Request matches or potential Unauthorized Request matches.

• For Authorized Request matches, the USER will have the ability to select the Authorized Request and move into the MA-19 View Customer File use case to view the details of the previously authorized rental. The USER will have the option of continuing or canceling this use case from the MA-19 View Customer File use case.

• For Unauthorized Request matches, the USER will have the ability to select the Unauthorized Request and move into the MA-10 Authorize Request use case to review and/or perform operations on the Unauthorized Request.

If the customer does not appear as an Unauthorized Request or Corporate Class Number match, the USER can select to continue to Step 7 of the Basic Flow.

1.5.3.3 Reservation Information Invalid

If an error is discovered in the validation of the reservation information submitted by the USER (Step 12 of the Basic Flow), the system will present the USER with an error message and return them to Step 9 of the Basic Flow (NOTE: If the USER submitted information from the Detailed Reservation screen, they should be returned to the Display Detailed Reservation Alternative Flow above). If the error is specific to a data field within the form, the field should be highlighted and the error described.

1.5.3.3.1 It will be considered invalid if the Reference Number, Renter First Name, Renter Last Name, Vehicle Condition, Rental Location, Authorized Number of Days, and at least one Renter Telephone number have not been included.

1.5.3.3.2 It will be considered invalid if the customer has established Reference Number editing and the Reference Number format does not meet the requirements of the customer's Reference Number definition. Reference Number definition is completed as part of the company profile³.

1.5.3.3.3 It will be considered invalid if any field identified as REQUIRED in the company/office profile is not included.

1.5.3.3.4 It will be considered invalid if any data entered violates the data type as specified by the ARMS Web database (i.e., alpha characters in a numeric field).

1.5.3.3.5 A warning will be presented to the USER if any defined limits identified in the company/office/user profile are exceeded (e.g., Maximum Number of Days Authorized). The system will allow the USER to submit the authorization from the warning.

Claim Number format definition will be defined in some cases in both the ARMS Web system and in the ARMS/400 system (e.g„ Nationwide, GEICO). Claim number definition will have to be maintained in BOTH systems in cases where this overlap exists. We are unable to reuse the claim number format definitions due to technical complications.

Confidential Enterprise Rent-A-Car © ₂000 1

Y \APPS\#AR -SWcb\AppUc- ion\AR SWEBV3\@d-;b\Fιmotιon-l Specs\MA-01 -Create ReservatiorήFuncrioπal SpecsVMA-01-FDS-ARMSWeb3.0vl 4 doc ARMS Redesign Project - Release 2.0 Issue: vl 4

Create Reservation Issue Date: 9/22/2000

1.5.3.3.6 It will be considered invalid if the Authorized Number of Days is included and is less than zero (0).

1.5.3.3.7 It will be considered invalid if the Date of Loss is greater than the current date.

1.5.3.3.8 It will be considered invalid if the first three digits (i.e., area code) of any U.S. or Canadian telephone number meet the criteria below:

• 0XX

• 1XX

• The second and third digits equal (e.g., 800, 877, 888, etc.)

Where X equals any digit 0 through 9.

1.5.3.3.9 It will be considered invalid if a U.S. or Canadian telephone number does not consist of 10 digits.

1.5.3.3.10 It will be considered invalid if a U.S. postal code does not consist of 5 or 9 digits.

1.5.3.3.11 It will be considered invalid if a Canadian postal code does not consist of 6 alphanumeric characters in the format AXAXAX where A is an alpha character and X is a digit between 0 and 9.

1.5.3.3.12 It will be considered invalid if an E-mail address is included that does not include an '©'character.

1.5.3.4 Cancel Use Case

The USER should be capable of canceling the use case at any point prior to the submission of the reservation to the ARMS Web database. The USER should be returned to the previous activity/page that the USER was on prior to entering this use case.

1.6 Post-Conditions

• If successful, a reservation authorization is sent to ARMS.

• If unsuccessful, the system state will be unchanged.

1.7 Special Requirements

1.7.1 Requirements for Reference Number Formatting

The following statements are a set of requirements for providing custom reference number formatting for a customer. The ARMS Web system will allow customer companies to define a specific layout or format that they use as their standard reference number format, so that the reference number field used in the system is presented as separate fields and are easily recognizable and 'intuitive' to the USER. These requirements will be implemented to all system functions where the customer reference number is used.

Confidential Enterprise Rent-A-Car © 2000

Y\APPS\#ARMSWeb\Apphcatιon\ARMSWEBV3\@dkb\Functιon-l Specs\MA-Dl -Create Reservation\Fιmctiorιal Spax\ A-01-FDS-AR SW-b3.0vl.₄.doc ARMS Redesign Project - Release 2.0 Issaε: vl .4

Create Reservation Issue Date: 9/22/2000

1.7.1.1 Customers must have the ability to define their reference number format (and in some cases, validations on specific portions of the reference number format) as part of the company profile. More than one reference number format can be stored per company, and each reference number format definition must have a unique identifier/name. The selection of which reference number format to use should be defined as part of the office profile using the reference number format unique identifier/name.

1.7.1.2 Reference numbers will be defined in 'segments'. Each segment will be presented to the USER as a separate field. For example, if the reference number format for the COMPANY were 45- A7456-1207, the reference number format would be defined to the system as a 2-character numeric Held, a 5-character alphanumeric field, and a 4-character numeric Held.

1.7.1.3 Customers must have the ability to define a set of "valid values' for any given segment of the reference number format. Valid Values allow the customer to dictate what the valid entries for a given reference number segment would include. For example, if the second segment in the customer's reference number format must be a state abbreviation, the customer could define valid values for that segment as 'AL', 'AR', 'AK', etc. If the USER does not enter one of the valid values, an error would be generated to notify the USER to enter a "valid' value. If no valid values are included for a reference number segment, all entry in to the field will be considered valid (assuming that the data type is conrect). If valid values are specified, entry into the reference number segment MUST MATCH ONE OF THE VALID VALUES IDENTIFIED.

1.7.1.4 The system will display the reference number field(s) as it is described by the reference number format definition for the office.

1.7.2 Requirements for Finding Rental Location

Below are the requirements for finding a rental location, across multiple rental car companies, in the ARMS Web system. ARMS Web will resolve a rental location and pass the location to ARMS for routing (which is a deviation from current state handling). These requirements were derived from the current state business requirements for the ARMS locator system.

1.7.2.1 ARMS Web will always retum a Rental Company's branch location for a reservation. For all ARMS Web reservations, the following rules for finding a rental location apply:

1.7.2.1.1 For United States locations, the locator will search a 50-mile radius around the renter's phone number or postal code for the closest branch that accepts ARMS reservations.

1.7.2.1.2 For International locations, the locator will search a 50-mile radius around the renter's phone number or postal code for the closest open branch that accepts ARMS reservations. If no open branches are found, the closest branch that accepts ARMS reservations should be returned.

Confidential Enterprise Rent-A-Car © 2000

YΛAPPSWARMSWeb\Appli<^on\A]mSwΕBV3\@dkb\F^ ARMS Redesign Project - Release 20 Issae v] 4

Create Reservation Issue Date: 9/22/2000

1.7.2.2 When the rental branch location is determined, the system will retrieve the name, shipping address, telephone number and rates of the rental branch location and present them to the USER on the Create Reservation screen(s).

1.7.2.3 The system will only display Claims Connection (7680) as the location (with no rates) when no location can be found within the 50-mile radius. If Claims Connection is displayed, a message should be included to indicate that no rental branch location was found within a 50-mile radius of the search criteria, and Claims Connection will ensure that the reservation is handled appropriately.

1.7.3 Requirements for Routing a Reservation

When a reservation is submitted to the ARMS Web system, routing of the reservation is required to ensure that the renter is called within two hours to confirm rental details Routing is done AFTER the reservation has been submitted to the ARMS Web system, and is transparent to the USER. The reservation can be routed to the selected rental branch, to Claims Connection, or to a regional call center based on the following rules:

NOTE: These requirements were deπved from the current state business requirements for the ARMS locator system.

1.7.3.1 The system should automatically route submitted reservations to Claims Connection between Friday 11 00pm and Sunday 11 00pm, regardless of whether the selected rental branch location is open or not.

1.7.3.2 The system should determine if the selected rental branch location on a submitted reservation is open or closed.

1 7 3 2 1 If the selected branch is open, the submitted reservation should be routed directly to the rental branch location (except m cases where a regional call center exists, see 1 73 3 below).

1.7.3.2.2 If the selected rental branch location is closed, the system will determine if the company that submitted the reservation has established after-hours handling of reservations. If the company has not established after-hours handling, the reservation is routed to the selected rental branch location (except in cases where a regional call center exists, see 1.7.3.3 below). If the company has established after-hours handling, the following rules apply:

1. The system will check the hours of availability for Claims Connection Claims Connection Hours are 5.00 a m. - 11 00 p m CST, 7 days a week" a If Claims Connection is open, the reservation will be routed to Claims

Connection (The insurance company customer, National Marketing and the Claims Connection Manager will determine whether or not Claims Connection makes a courtesy call to the renter) b. If Claims Connection is closed, the closest branch hours are checked to see if they will be open within 8 hours If the branch will be open m 8 hours, the reservation will be routed to the rental branch location (except in cases where a regional call center exists, see 1.7.3.3 below). If the branch will not be open in the next 8 hours, the reservation will be routed to Claims Connection

1 7.3.3 The system should detemnine if the selected rental branch location on a submitted reservation

Although we receive reservations 24 hours day, 7 days week, we do not route them between 11 45pm and 430am (CST) The only exception to this is Saturday night to Sunday

Confidential Enterprise Rent-A-Car © 2000 8

Y \APPS\#ARMSWeb\Apphcatιon\AR SWEBV3\@ lkb\Funcnon-l Spe_-\ A-01-CreatβReserv-tιon\Functιon-l Specs\MA-01-FDS-ARMSWeb3 Ovl 4 oc ARMS Redesign Project - Release 2.0 Issue: vl.4

Create Reservation Issue Date: 9/22/2000 has a regional call center.

1.7.3.3.1 If the selected rental branch location has a call center to handle customer callbacks, the reservation should be routed to the call center.

1.7.3.3.2 If the selected rental branch location does not have a call center to handle customer callbacks, the reservation should be routed to the rental branch location.

1.7.3.4 The system should provide specific feedback indicating the reason a reservation was re-routed when the Authorization Confirmation is received. This will allow the USER to be aware of the reason for the change of location if they access the reservation while it is owned by someone other than the rental branch location selected when the reservation was originally submitted.

1.7.3.4.1 If the reservation is re-routed to Claims Connection because the selected rental branch location was closed, the system should provide a message (that will be accessible through the diary notes/notebook) that states the reservation was routed to Claims Connection because the rental branch location was closed when the reservation was submitted.

1.7.3.4.2 If the reservation is re-routed to a regional call center to expedite the callback process, the system should provide a message (that will be accessible through the diary notes/notebook) that states the reservation was routed to a regional call center to expedite the renter callback process.

1.7.3.5 The system should include a message/note with the group/branch number and address of the rental branch location selected by the USER if the reservation is routed to any location (i.e., Claims Connection or otherwise) other than the rental branch location selected by the USER.

1.7.4 Maintenance of Source Systems

This use case requires that information in the existing Locator and Special Instructions (AS/400) databases be kept current and it is assumed that the group responsible for maintaining these databases will continue to do so in the future. Locator is used to retrieve Rental Branch Location information, and Special Instructions is used to retrieve rate information for a selected rental branch location.

Confidential Enterprise Rent-A-Car © 2000

Y:\APPSWARMSWeb\Application\AR SWEB V3\@dkb\Fun-tional Spec-\MA-01 -Create Reservaύon\Fιmctior-ιl Specs A-01-FDS-AR SWeb3.0vl.4.<^oc ARMS Redesign Project - Release 2.0 Issue: vl .4

Create Reservation Issue Date: 9/22/2000

1.8 Extension Points

An extension point indicates a link between this use case and another use case. Extension points associated with the use case are indicated below.

1.8.1 MA-10 - Authorize Request

The Authorize Request use case will be used to allow the USER to view and perform operations on an outstanding Unauthorized Request. The USER will not be returned to this use case on completion of the Authorize Request use case.

1.8.2 MA-19 - View Customer File

The View Customer File use case will be used to allow the USER to view the customer file when a matching authorized request is found and selected. The USER will have the option of ending the use case or be returned to Step 9 of the Basic Flow on completion of the View Customer File use case.

1.8.3 MA-02- Find Rental Location

The Find Rental Location use case will be used to allow the user to find one or more alternate rental branch locations that can provide service to the customer. The USER should be returned to Step 9 of the Basic Flow upon completion of the Find Rental Location use case. If the USER selects a rental branch location, branch information (i.e., address, phone) should be returned and the appropriate fields should be populated on the Reservation screen.

1.8.4 MA-04-Send Message

The Send Message use case will allow the USER to send a message to the Rental Company branch regarding the reservation, or select to store the message text with the reservation as a diary note (which is not sent to the branch). The USER should be returned to Step 9 of the Basic How upon completion of the Send Message use case.

1.8.5 MA-07-Addι^'tional Charges

The Additional Charges use case will be used to add special charges to the reservation being created by the USER . The USER should be returned to Step 9 of the Basic Flow upon completion of the Additional Charges use case. Any Additional Charges captured should be returned and applied to the reservation. The existence of Additional Charges should be reflected on the reservation screen.

1.8.6 MA-08-View Car Classes

The View Car Classes use case will be used to allow the USER to view details about and select a car class to apply to a reservation. Details will include the average number of passengers and luggage items that can be served by a vehicle in the specific car class. The USER should be returned to Step 9 of the Basic Flow upon completion of the View Car Classes use case. The car class selected by the USER should be applied to the reservation.

Confidential Enterprise Rent-A-Car © 2000 10

Y:\APPS\#AR -SWebV^pUc-tion\ARMSWEBV3\@d-;bVFunc-ic«al Specs\MA-01 -Create Rcservation\F nction-l Specs\MA-01-FDS-A MSWeb3.0vl.4.doc ARMS Redesign Project - Release 20 Issue vl 4 Create Reservation Issue Date. 9/22/2000

2. Screen Design

A defimtion of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above More than one screen may be used to implement support for the use case flow.

2.1 Initial Reservation Screen

The Initial Reservation screen provides the user interface and functions to support Steps 2 through 4 of the Basic Flow The information captured on this screen will allow the system to perform several background search activities, and help to better construct the Quick/Detailed Reservation screen. All information captured on the Initial Reservation screen is required to create a new reservation, and is reused later in the reservation creation process.

Confidential Enterprise Rent-A-Car © 2000 11

Y \APPS\#AS SWeb\Applιcanon\AR SWEBV3\@d b\F-rιcaoιι-l SpecsVMA-01 -Create Re-ervationTuncUon-l Specs\ A-01-FDS-AR SWeb3 Ovl doc ARMS Redesign Project - Release 20 Issue vl 4 Create Reservation Issue Date 9/22/2000

(Insurance User)

(Fleet User)

Confidential Enterprise Rent-A-Car© 2000 12

Y\APPSWAR SWeb\Applιcatιon\ARMSWEBV3\@dkb\Functιon-l Spe--\ A-01-CreateRe-ervatιon\Functιon-] Specs\ A-01-FDS-ARMSWeb3 Ovl doc ARMS Redesign Project - Release 2 0 Issue vl 4 Create Reservation Issue Date 9/22/2000

(Dealership User)

(Corporate User)

Confidential Enterprise Rent-A-Car © 2000 13

Y \APPSWAR SWcb\Applιc-t4on\ARMSWEBV3\@dkb\Functιon-l SpecήMA-Ol-Crcatc Reserv-tιon\Functιonal Specs\ A-01 FDS-ARMSWcb3 Ovl ₄ doo ARMS Redesign Project - Release 2.0 Issue: vl.4 Create Reservation Issue Date: 9/22/2000

2.1.2 Screen Field Definition

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.1.3.1 Create Reservation

The Create Reservation screen function will allow the USER to submit the information on the Initial Reservation screen and move on in the create reservation process. The system will use this information to perform background searches for Unauthorized Requests and Corporate Class Number Matches, and to build the Quick/Detailed Reservation screen appropriately.

2.1.3.1.1 The Create Reservation screen function is invoked through either a button click or an Enter keystroke.

2.1.3.1.2 The information captured on the Initial Reservation screen will be used to pre-populate the

Confidential Enterprise Rent-A-Car © 2000 14

YΛAPPSWARlv-SWΛ\Arφlic-tion\AKMSW ARMS Redesign Project - Release 20 Issue- vl.4 Create Reservation Issue Date 9/22/2000 corresponding fields on the Quick/Detailed Reservation screen.

2.1 3.1 3 If the information submitted to the ARMS Web application is invalid or incomplete, this screen function should prompt the USER with an error. The error should be specific as to the cause of the failure. All information previously entered should remain populated in each field, with the problem field highlighted or otherwise identified.

2.2 Authorization Matches Found Screen

The Authorization Matches Found screen provides the functions to support the Unauthorized Request/Authorized Request Search Matches alternative flow.

2.2.1 Screen Layout (ARMS Web 2.0)

Pip?^? wenfy tn? resewtt'OP <ou warn ; ..cats doe . not ^■>χ:'s* If tl &x.s>:ϋ, you _.»» ct ex i'^Λ'j U. '-^Λώsv t ≤ P ^■_ £»«^• p e-ct-ss A

Confidential Enterpπse Rent-A-Car © 2000 15

Y \APPS\#AM SWeb\Apphca on\AR}^WΕBV3\@dkb\F πcUonaI Specs\MA-01-Create ReservationXFuncUonal Specs\ A-01-FDS-ARMSWcb3 Ovl 4 doc ARMS Redesign Project - Release 2.0 Issue vl 4 Create Reservation Issue Date 9/22/2000

(Insurance User)

(Fleet User)

Contact Us | T«rma & Conditions | Loo Off ARMS Redesign Project - Release 20 Issue vl.4 Create Reservation Issue Date. 9/22/2000

(Dealership User)

ARMS Redesign Project - Release 2.0 Issue: vl .4 Create Reservation Issue Date: 9/22/2000

2.2.2 Screen Field Definition

Confidential Enterprise Rent-A-Car © 2000 18

Y:\APPS\*AR -S eb\ pli(---on\AR^-SVEBV3^@d-i)\Fun-tiol_-l Specs\ A-01-Cr-ate Res-rv-bon\Fυπ-tion-l SpecsVMA-01-FDS-AE S eb3.0vl.₄ doc ARMS Redesign Project - Release 2.0 Issue: vl.4 Create Reservation Issue Date: 9/22/2000

2.2.3 Screen Function Definition

This section includes the definitions for all functions that can beperformed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.2.3.1 New Reservation

The New Reservation screen function button will allow the USER to close/continue beyond the Authorization Matches Founds screea

2.2.3.1.1 The New Reservation screen fiinction is invoked through either a button click or through an Enter keystroke.

Confidential Enterprise Rent-A-Car © 2000 19

Y:\APPSWAEMSWcb\Application\ARMSWEB V3\@dkb\F«ncti∞-l Specs\MA-01-Create eservalion\Functiorι-l Specs\ A-01-FDS-AR SWeb3.0vl.₄.d∞ ARMS Redesign Project - Release 20 Issue vl.4 Create Reservation Issue Date: 9/22/2000

2.3 Quick Reservation Screen

The Quick Reservation screen provides support for Step 9 of the Basic Flow.

IMPORTANT NOTE: This is the minimum allowable set of fields on the Quick Reservation screen. The Quick Reservation screen will also include any fields indicated as QUICK RESERVAΗON in the company/office profile! See the Detail Reservation screen for all available fields.

2.3.1 Screen Layout (ARMS Web 2.0)

r ate Re^^r t m;

(SUi K FO R iH for Coppola, Franife Claim no 754589877 GEICO

© top of pag

O lop of page

Confidential Enterprise Rent-A-Car © 2000 20

Y \APPS\#AM^Web\App ralιon\AR SWEBV3\@d b\Fun(Λιon-I SpecsXMA-Ol-Create Reserv-tiorΛFunctional Specs\ A-01-FDS-ARMSW-b3 Ovl doc ARMS Redesign Project - Release 20 Issue vl 4 Create Reservation Issue Date. 9/22/2000

(Insurance User)

Confidential Enterprise Rent-A-Car © 2000 21

Y \APPSWARMSWeb\ApphcaUon\AR S EBV3\@ kb\Funolιon-l SpeaΛMA-Ol-Crcate ReservatioώF ncttonal Specs\MA-01-FDS-ARMSWeb3 Ovl + doc ARMS Redesign Project - Release 20 Issue vl.4 Create Reservation Issue Date 9/22/2000

(Fleet User)

Confidential Enterprise Rent-A-Car © 2000 22

Y \APPSWARMSWcb\Arφhc--ιon\ARMSVVEBV3\@dkb\Fιm-tιor-- Specs\MA-01-Create ReservationΨuncuonal Specs\MA-01-FDS-ARMSWet>3 Ovl 4 doo ARMS Redesign Project - Release 2.0 Issue vl.4 Create Reservation Issue Date: 9/22/2000

(Dealership User)

Conlidenlial Enterprise Rent-A-Car © 2000 23

ARMS Redesign Project - Release 20 Issue vl 4 Create Reservation Issue Date: 9/22/2000

(Corporate User)

Confidential Enterprise Rent-A-Car © 2000 24

Y \APPS\*ARMSWeb\Applιrabon\ARMSWEBV3\@d b\FιmoUon-l SpeeΛMA 01 -Create Reserv-tiorΛFunctional Specs\MA-01-FDS-AEMSWeb3 Ovl 4 doc ARMS Redesign Project - Release 2.0 Issue: vl.4 Create Reservation Issue Date: 9/22/2000

2.3.2 Screen Field Definition

Output 35 User Name First Name Should be presented as 'User First Name + Last + User Last Name Name

Office Combo Box 10 Office Location external The default value should be the primary organization office of the current user. identifier

The values presented in the Office Location list should be limited to the offices that the user has been granted the authority to create a reservation.

If changed, the system should automatically refresh the screen and update the "Handling for" list to the users in the newly selected office with the ability to create a reservation

Handling for Combo Box 35 Handling for First Name The combo list should include the users

-i-Last for the selected office location that have

Name the authority to create a reservation.

The default value should be 'Yourself

The handling for users should be presented as User Last Name + User First Name in alphabetical order

Claim Number Text Box 30 Claim Number Insurance Should be populated by the Reference Purchase Order Purchase Order Claim Number entered on the Initial Reservation Number Number Number, screen. Corporate Class Corporate Class POtf, CC# Number Number Reference number should be presented in separate fields to correspond to the claim number format (segments) that has been defined by the USER profile.

If changed, the system should validate that no matching reference numbers exist (i.e.. reference number matching). The user should be notified if a match exists.

Reference Number is a required field.

Insurance User - Claim Number

Fleet User - Claim Number

Dealership User - Purchase Order

Number

Corporate User - Corporate Class Number

Confidential Enterpπse Rent-A-Car © 2000 25

Y-\APPS\#ARMSWeb\ArφlιcaticΛ\AR SWEBV3\@^ ARMS Redesign Project - Release 2.0 Issue: vl.4 Create Reservation Issue Date: 9/22/2000

Confidential Enterprise Rent-A-Car © 2000 26

Y:\AFPS\#ARMSWeb\Application\AI»lSWEBV3\@^ ARMS Redesign Project - Release 2.0 Issue: vl.4 Create Reservation Issue Date: 9/22/2000

Confidential Enterprise Rent-A-Car © 2000 27

Y:\APPSWARMS W-b\Application\AR S WEBV3\@d b\Function-l SpecsVMA-Ol -Create ResenraUon\Fιm-tional Specs\MA-01-FDS-AR SWeb3.0vl ₄doc ARMS Redesign Project - Release 30 Issue 1 3 Find a Rental Location Issue Date 9/26/00

Confidential Enterprise Rent-A-Car © 2000 15

Y \APPS\#AR]^Web\^lic-tionVARMSWEBV3\@dlcb\Functton-l Specs\ A-02 Find Rental Loc-tιon\Functιonal Specs\MA-02-FDS-ARMSWeb3 Ovl 3 doc ARMS Redesign Project - Release 2.0 Issue: vl.4 Create Reservation Issue Date: 9/22/2000

Confidential Enterprise Rent-A-Car © 2000 28

Y:\APPSWARK-SWeb\App]ic-hon\ARMSWEBV3\@d b\FBnctional Specs\MA-01-Cre_te ReservatioώFunctiσn-1 Sp.cslMA-01-FDS-ARMSWeb3.0vl Adoc ARMS Redesign Project - Release 2.0 Issue: vl.4 Create Reservation Issue Date: 9/22/2000

2.3.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.3.3.1 More Locations

The More Locations screen fimction allows the USER to select a different rental branch location using the Find Rental Location use case. Invoking this screen function will launch the USER into the Find a Rental Location use case.

2.3.3.1.1 The More Locations screen function is invoked through a button click.

2.3.3.2 Additional Charges

The Additional Charges screen function allows the USER to add, view, and modify any additional charges that they might authorize for a rental reservation (e.g., CDW). Invoking this screen function will launch the USER into the Additional Charges use case.

Confidential Enterprise Rent-A-Car © 2000 29

Y:\APPS\#ARMSWeb\Application\ARMSWEBV3\@<ϊ-b\F^^ ARMS Redesign Project - Release 2.0 Issue; _vl .4

Create Reservation Issue Date: 9/22/2000

2.3.3.2.1 The Additional Charges screen function is invoked through a button click.

2.3.3.3 View Car Class

The View Car Class screen function allows the USER to view and select a Rental Car Class to apply to a reservation. Invoking this screen function will launch the USER into the View Car Classes use case.

2.3.3.3.1 The View Car Class screen function is invoked through a button click.

2.3.3.4 Select a Favorite Location

The Select a Favorite Location screen function allows the USER to change the rental branch location to one of the rental branch locations identified as a 'favorites' in their USER profile.

2.3.3.4.1 The Select a Favorite Location is invoked by selecting a value from the Favorite Locations drop-down list. The system should automatically retrieve the favorite location (and rates) when the value of this field is selected.

2.3.3.5 Conϋrm Reservation

The Confirm Reservation screen fimction allows the USER to submit all reservation information to the ARMS Web system, which will create a new reservation.

2.3.3.5.1 The Confirm Reservation screen function is invoked either through a button click or by an Enter keystroke.

2.3.3.5.2 If the information submitted to the ARMS Web application is invalid or incomplete, this screen function should prompt the USER with an error. The error should be specific as to the cause of the failure. All information previously entered should remain populated in each field, with the problem field highlighted or otherwise identified.

2.3.3.6 Cancel

The Cancel Reservation screen function will allow the USER to leave the screen and return to their ARMS Web start page. No information is saved and no reservation is created.

2.3.3.6.1 The Cancel screen function is invoked through a button click.

Confidential Enterprise Rent-A-Car © 2000 ³⁰

Y:\AI^!PS\#ARMSWeb\AppUcanm\ARMSWEBV3\@i-i\Fun-tional Spe<s\MA-Ol-Crea--Re£erv-tio-> \-αotioιιal Spe s\MA-01-FDS-AR SWeb3.0vlAdoc ARMS Redesign Project - Release 2.0 Issue vl 4 Create Reservation Issue Date: 9/22/2000

2.4 Reservation Confirmation Screen

The Reservation Confirmation screen provides the user interface and functions to support Step 16 of the Basic Flow. This provides the USER with confirmation feedback on successful submission of the reservation.

2.4.1 Screen Layout (ARMS Web 3.0)

Ypu just.

C C53 S TsOf iI- rmE Kai F ltonS ϊ~ Dont show me this confirmation page again.

Contact I* I T-r s S. Conditions Loo Off

Confidential Enterpπse Rent-A-Car © ₂000 31

Y \APPS\#ARMSWeb\^phcatιon\AR SWEBV3\@dki.\Fιιnctιon-l Sp-csXMA-Ol-Creat- Reseτvatιon\Functιon-l Specs\MA-01-FDS-AR SW_b3 Ovl 4 doc ARMS Redesign Project - Release 20 Issue- vl 4 Create Reservation Issue Date 9/22/2000

(Insurance User)

Confidential Enterprise Rent-A-Car © 2000 32

4doc ARMS Redesign Project - Release 2.0 Issue: vl.4 Create Reservation Issue Date: 9/22/2000

(Fleet/Dealership/Corporate User)

Confidential Enterprise Rent-A-Car © 2000 ₃3

Y\APPS\#AR SWeh\Apphι^on\Aiα^ -BV3\@dkb\Fmc or-α Sp-cs\MA-01-CreateRes^ ARMS Redesign Project - Release 2.0 Issue: vl.4 Create Reservation Issue Date: 9/22/2000

2.4.2 Screen Field Definition

2.4.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.4.3.1 Retum to Home Page

The Return to Home Page screen function will allow the USER to return to their home page from the reservation confirmation screen.

2.4.3.1.1 The Return to Home Page screen function is invoked through either a button click or an Enter keystroke.

2.4.3.2 Change Reservation

The Change Reservation screen function will allow the USER to go back into the Quick Reservation or Detailed Reservation screen and change any errors.

2.4.3.2.1 The Change Reservation screen function is invoked by clicking on the feedback hyperlink (e.g., You just authorized 3 days at $29.39/day for Tom Hanks).

Confidential Enterprise Rent-A-Car © 2000 34

Y:\APPSWARMSWeb\AppH<Λn\ARMSWEBV3\@^ Enterprise Rent-A-Car

ARMS/Web 3.0

Functional Design Specification

Find a Rental Location

Version 1.3

Last Saved: 9/26/00 1 :53 PM

ARMS Redesign Project - Release 3.0 Issue: 1.3 Find a Rental Location Issue Date: 9/26/00

Revision History

Date Issue Description Author

2000-03-16 0.1 Initial draft published to the design team TomDavies; Sean for QA O'Donnell

2000-03-21 0.2 Revisions recommended by the design Sean O'Donnell team were incorporated into the document.

2000-03-24 0.3 Revisions to the document were made to Sean O'Donnell reflect the changes made subsequent to cross-team QA process results.

2000-05-08 0.5 Revisions from the initial management Sean O'Donnell review session were incorporated into the document.

2000-05-24 0.6 Revisions from the Iteration 2 cross team Sean O'Donnell review process were incorporated into the document.

2000-05-30 0.7 Added data field information from Cindy Bastean DATA FIELDS database

2000-06-05 1.0 Version 1.0 published to the build team. Sean O'Donnell

2000-07-18 1.1 Updated to reflect changes made through Sean O'Donnell discovery in initial builds, screen redesign, and additional business requirement definition.

2000-08-15 1.2 Updated with changes and revisions per Sean O'Donnell the recommendation of the business leads and technical teams.

2000-09-26 1.3 Changes made based on feedback provided Amanda Banta, Aaron by business leads with respect to the future Foster, ke Slater, Tim state of Release 3.0. Weinstock

Confidential Enterprise Rent-A-Car © 2000

Y:\APPSWARMSWBb\Application\A MSVVEBV3\@dkb\Functιonal Specs\MA-02-Find Rental L∞ationΨuncπonal Specs\MA-02-FDS-ARMSWeb30v 3.doc ARMS Redesign Project -Release 3.0 Issue: 1.3

Find a Rental Location Issue Date: 9/26/00

Table of Contents

1. Find a Rental Location Use Case

1.1 Application Overview

1.2 Brief Description

1.3 Use Case Actors

1.4 Pre-Conditions

1.5 Flow of Events

1.5.1 Activity Diagram 2

1.5.2 Basic Flow 3

1.5.3 Alternative Flows 4

1.6 Post-Conditions 5

1.7 Special Requirements 5

1.7.1 Requirements for Finding Rental Location 5

1.7.2 Maintenance of Source Systems 6

1.8 Extension Points 6

2. Screen Design 7

2.1 Location Search Criteria Screen 7

2.1.1 Screen Layout 7

2.1.2 Search for Rental Location 7

2.1.3 Screen Function Definition 8

2.2 Matching Location Screen 9

2.2.1 Screen Layout 9

2.2.2 Screen Field Definition 10

2.2.3 Screen Function Definition 11

2.3 Location Details Screen 13

2.3.1 Screen Layout 13

2.3.2 Screen Field Definition 14

2.3.3 Screen Function Definition 16

3. Questions and Answers 17

Confidential Enterprise Rent-A-Car © 2000

Y:\APPS\#ARMSWeb\Application\AR SWEBV3\@d b\Fιιnctional Specs\MA-02-Fιnd Rental LocationVF-notional SpecsVMA-02-FDS-AB SWeb3 Ovl 3 doc ARMS Redesign Project -Release 3.0 Issue: 1.3

Find a Rental Location Issue Date: 9/26/00

Find a Rental Location

1. Find a Rental Location Use Case

1.1 Application Overview

The following is a document used to illustrate the process of finding and selecting an alternate rental location for a reservation created using ARMS/Web 3.0. The intent for this release of the ARMS/Web application is to reach a much wider audience. This application will target a Multi-Vendor, Multi- Segment, and International customer base.

1.2 Brief Description

This use case describes the process of finding and selecting an alternate rental location for a reservation created in the ARMS/Web system. The USER will have the ability to select the location search criteria they want to use (i.e. phone number or postal code), select the rental company and select to either review a list of nearby rental company locations or have the system automatically determine a rental company location based on the location search criteria¹. This use case provides the mechanism to return rental company location information, including address, rental company, and phone number to create a new reservation or define a favorite location.

1.3 Use Case Actors

The following actors will interact with this use case:

• RENTAL ADMINISTRATOR - The RENTAL ADMINISTRATOR will use the system to find and select a rental location for creating a reservation. This use case refers to a USER in the role of a rental administrator. There are various types of customers that the rental administrator would represent, which include corporate account holders, car dealerships, insurance companies, and others.

• LOCATOR - The LOCATOR system will determine the nearest rental branch location(s) based on the search criteria provided in this use case.

• ARMS - The ARMS system will receive/send transactions to ARMS/Web to retrieve the information regarding the rental company.

• RENTAL CAR COMPANY - A wide variety of rental car companies will be able to use this system as well. Each company will have the ability to initiate and manage their rentals through the use of this application.

1.4 Pre-Conditions

• The USER must be logged on to the ARMS/Web system.

• The USER must be creating a reservation or defining a favorite location.

1.5 Flow of Events

The How of Events includes all steps necessary to select rental location search criteria and retrieve an alternate rental branch location(s).

The USER will also have the ability to select an alternate location by using the 'Favorite Locations' functionality built into the Create Reservation screens.

Confidential Enterprise Rent-A-Car © 2000

Y:\APPS\SAR SWeb\Applicanon\ARMS EBV3\@dld)Φun tiorι-l Specs\MA-02-Find Rental LocahonWunctional Specs\MA-02-FDS-AR SWeb3.0vl 3 doc ARMS Redesign Project - Release 3.0 Issue: 1 3 Find a Rental Location Issue Date: 9/26/00

1.5.1 Activity Diagram

Find Rental Location Use Case Activity Diagram

Confidential Enterprise Rent-A-Car © 2000

Y\AFPS\#ARMSWeb\Applιcatιon\ARMSWEBV3\@d b'-^Junctιon-l Specs\MA-02-Fιnd Rental LocationVFunctional Specs\MA-02-FDS-AR SWeb3 Ovl 3 doc ARMS Redesign Project -Release 3.0 Issue: 1.3

Find a Rental Location Issue Date: 9/26/00

1.5.2 Basic Flow

The Basic Flow of the Find a Rental Location use case includes all of the required steps for the USER to select and input search criteria to find an alternate rental location. The USER will have the ability to view detailed information about a rental branch, and select a rental branch location to apply to a new reservation.

1. The USER selects to find an alternate rental location.

2. The system will prompt the USER for pick up location search criteria (also referred to as 'where needed' search criteria). This allows the USER to input a telephone number, city, or postal code to find a rental branch (or branches) that accepts ARMS/Web reservations in a given area². The USER may also narrow the search by selecting a particular rental company along with the location search criteria. The USER will be given the option to view a list of rental branch locations matching the search criteria, or to have the ARMS/Web system automatically select the rental branch considered the Nearest Match.

3. The USER enters the required search criteria

4. The USER submits the rental branch location search criteria.

5. The system will validate the rental branch location search criteria.

6. The system will retrieve/return a rental branch location³ (based on USER search selection criteria) to be used by the Create Reservation use case⁴. The rental branch location information for the selected branch on the Create Reservation screens will be automatically populated with the list below for the current Create Reservation transaction.

• Branch name⁵

• Address

• Telephone number

• Rates

7. The use case is complete.

2

Rental branch locations have the ability to opt out of accepting ARMS/Web reservations.

The requirements for retrieving a rental branch location can be found on page 5 of this document (Section 1.7.1 Requirements for Finding Rental Location).

This use case is also used to define favorite locations from the 'My Profile' use case. The location will be returned to the 'My Profile' use case when the use case is entered from a 'My Profile' screen The Branch name has been included for future usability purposes (e.g., Network Allocation).

Confidential . Enterprise Rent-A-Car © 2000

Y:\APPS\#ARMSWeb\Application\ARMSWEBV3\@dkb\Functional Sp-cs\MA-02-Find Rental LocationΨunctional Specs\ A-02-FDS-ARMSWeb3.0vl -3.doc ARMS Redesign Project - Release 30 Issue 1 3

Find a Rental Location Issue Date 9/26/00

7.5.3 Alternative Flows

1.53.1 Search Criteria Entered is Invalid

If the USER enters an mvahd Postal Code or Phone Number as location search criteria, an error message should be displayed to the USER and the USER should be forced back into Step 2 of the Basic Flow. If the error is specific to a data field, the field should be highlighted and the error described.

1 5.3.1.1 It will be considered invalid if the 'where needed' search catena is a telephone number and the first three digits (ι.e , area code) meet the criteria below

• OXX

• 1XX

• The second and third digits are equal (e.g., 800, 877, 888, etc )

Where X equals any digit 0 through 9

1.5.3.1 2 It will be considered invalid if the 'where needed' search critena is a U S. or Canadian telephone number that does not consist of 10 digits

1 5 3 1.3 It will be considered invalid if the 'where needed' search criteria is a U S postal code that does not consist of 5 or 9 digits.

1.5 3.1.4 If will be considered invalid if the 'where needed' search cntena is a Canadian postal code that does not consist of 6 alphanumeric characters in the format AXAXAX where A is an alpha character and X is any digit 0 through 9

1 5.3.2 No Rental Branch Locations Found

If the system cannot determine a rental branch location based on the search cnteria entered by the USER, Claims Connection will be returned as the location and the use case will end Please refer to section 1.7 1 Requirements for Finding Rental Location on beginning on page 5 of this functional specification for handling of this situation.

1.5.3.3 View a List of Rental Branch Locations

If the USER opts to view a list of matching rental locations, the list of matching locations will be displayed after Step 5 of the Basic Flow. The USER will have the ability to select one of these locations, view more detail about the locations (I e., maps, hours of operation), or perform another location search by entering new search cntena.

1 5.3 3.1 If the USER requests additional detail on a specific rental branch in the View a List of Rental Branch Locations Alternate Flow, the system should display a screen with the selected branch's additional information (Rental Company, Branch name, Addresses, telephone/fax numbers, Map to the rental branch location, Hours of operation). The USER should either select the location from this screen (and be returned to Step 6 of the Basic Flow), or be returned to the list of matching locations by closing/continuing from this screen

1 5 3.3 2 If the USER wishes to perform another rental branch location search in the View a List of Rental Branch Locations Alternate Flow, the system should return the USER to Step 2 of the Basic Flow

Confidential Enterprise Reπt-A-Car © 2000 4

Y \APPSWARMSWeb\Applιcatιon\ARMSWEB V3\@dkMFunctιonal Specs\MA-02 Find Rental LocationVFtinc onal Specs\MA-02-FDS-ARMSWeb3 Ovl 3 doc ARMS Redesign Project -Release 3.0 Issue: 1.3

Find a Rental Location Issue Date: 9/26/00

1.5.3.4 Use Case Cancellation

The USER should be capable of leaving the use case at any time.

1.6 Post-Conditions

• If successful, a rental branch location will have been determined and returned to the Create Reservation use case.

• If unsuccessful, the system state remains unchanged.

1.7 Special Requirements

The additional requirements of the business use case are included here. These are requirements not covered by the flow as they have been described in the sections above.

1.7.1 Requirements for Finding Rental Location

Below are the requirements for finding a rental location in the ARMS Web system. ARMS/Web will resolve a rental location and pass the location to ARMS for routing (which is a deviation from current state handling). These requirements were derived from the current state business requirements for the ARMS locator system.

1.7.1.1 ARMS/Web will always return a rental branch location for a reservation. For all ARMS Veb reservations, the following rules for finding a rental location apply:

1.7.1.1.1 For United States locations, the locator will search a 50-mile radius around the renter's phone number or postal code for the closest branch (or branches) that accepts ARMS reservations. If the USER selects to review a list of rental branch locations, an array of rental branch locations meeting these criteria should be returned.

1.7.1.1.2 For Canadian locations, the locator will search a 50-mile radius around the renter's phone number or postal code for the closest open branch (or branches) that accepts ARMS reservations. If no open branches are found, the closest branch (or branches) that accepts ARMS reservations should be returned. If the USER selects to review a list of rental branch locations, an array of rental branch locations meeting these criteria should be returned.

1.7.1.2 When the rental branch location is determined, the system will retrieve the group/branch number, name, shipping address, and telephone number of the rental branch location and present them to the USER on the Create Reservation screen(s).

1.7.1.3 The system will only display Claims Connection (7680) as the location (with no rates) when no location can be found within the 50-mile radius. If Claims Connection is displayed, a message should be included to indicate that no rental branch location was found within a 50-mile radius of the search criteria, and Claims Connection will ensure that the reservation is handled appropriately.

Confidential Enterprise Rent-A-Car © 2000

Y:\APPSWAR SWeb\Application\ARMSWEB V3\@dkb\Functional Specs\MA-02-Fιnd Rental LocatioώFunctional Specs\MA-02-FDS-ARly[S eb3.0vl.3.-oc ARMS Redesign Project -Release 3.0 Issue: 1.3

Find a Rental Location Issue Date: 9/26/00 if

7.7.2 Maintenance of Source Systems

This use case requires that several existing AS/400 databases be used to query for information:

• Locator Database

• Office Information Database

The use case requires that the information in these databases be kept current and it is assumed that the group responsible for maintaining these databases will continue to do so in the fiiture.

1.8 Extension Points

None.

Confidential Enterprise Rent-A-Car © 2000

Y:\APPSWARMSWeb\Application\ARMSWEB V3\@dkb\Functional SpecsVMA-02-Find Rental LocatioώFunctional Specs\ A-02-FDS-ARMSWeb3.0vl.3.doc ARMS Redesign Project - Release 3.0 Issue 1 3 Find a Rental Location Issue Date: 9/26/00

Screen Design

A defimtion of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Location Search Criteria Screen

This screen allows the USER to select input the search cnteria they want to use to find a rental location This screen supports Steps 2 and 3 of the Basic Flow.

2.1.1 Screen Layout (ARMS/Web 2.0)

2.1.2 Search for Rental Location

Confidential Enterprise Rent-A-Car © 2000

Y \APPSWARMSWcb\Apphcat-on\ARMSWEBV3\@dkb\Functιotιal Specs\MA-02-Fιnd Rental LocattonVFunctional Specs\MA-02-FDS AR SWeb3 Ovl 3 doc ARMS Redesign Project - Release 3.0 Issue: 1.3 Find a Rental Location Issue Date: 9/26/00

Si/ Su'α-'iil^'icldNmn- SereeiiSpo ficRiilo

2.1.3 Screen Function Definition <

, This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.1.3.1 Next

The Next screen function will allow the USER to submit the information on the Location Search Criteria screen and initiate the search for matching locations

2.1.3.1.1 The Next screen function is launched through either a button click or by using the Enter keystroke.

2.1.3.1.2 If the information submitted to the ARMS/Web system is invalid or incomplete, this screen function should prompt the USER with an error. The error should be specific as to the cause of the failure. All information previously entered should remain populated in each field, with the problem field highlighted or otherwise identified.

Confidential Enterprise Rent-A-Car © 2000

Y:\APPS\#AR SWeb\Application\ARMSVVEBV3\@d b\Function-l Specs\MA-02-Find Rental ocatioriFunctional Specs\ A-02-FDS-ARMSWeb3.0vl.3.doc ARMS Redesign Project -Release 3.0 Issue: 1.3 Find a Rental Location Issue Date: 9/26/00

2.2 Matching Location Screen

This screen allows the USER to review/select a rental location based on the search criteria entered on the Location Search Criteria screen. The screen will present 5 matching records at a time to the USER The USER is given the option of viewing additional detail on a location or entering new search criteria. If there are more locations selected by the search, the USER will view the next locations (up to 5). This screen supports Step 4 of the Basic Flow.

2.2.1 Screen Layout

Confidential Enterprise Rent-A-Car © 2000

Y-\APPS\#ARMSWeb\Applιcation\ARMSWEBV3\@dkbVFunctional Specs\MA-02-Fιnd Rental LocationVFunctional Specs\ A-02-FDS-ARMSW-b3 Ovl 3 doc ARMS Redesign Project- Release 3.0 Issue: 1.3 Find a Rental Location Issue Date: 9/26/00

2.2.2 Screen Field Definition

Confidential Enterprise Rent-A-Car © 2000 10

Y:VAPPSWARMSWebVApplicationVAR SWEBV3\@dkbVFunctional SpecsV A-02-Find Rental LocationVFunctional SpecsVMA-02-FDS-AR SWeb3.0vl.3.doc ARMS Redesign Project - Release 3.0 Issue: 1.3 Find a Rental Location Issue Date: 9/26/00

2.2.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.2.3.1 Select this Location

The Select this Location screen function will submit the selected rental branch location in the Rental Location Information Container to the ARMS/Web system, to be used by the Create Reservation use case.

2.2.3.1.1 The Select this Location screen function is launched through either a button click or by using the Enter keystroke.

2.2.3.2 Next X of Y

The Next X of Y screen function will allow the USER to view the next five rental locations (unless less than five records exist) that match the search criteria. For example, if a total of 8 locations were returned as part of the search, this screen function would be presented as Next 3 of 8

2.2.3.2.1 The Next X of Y screen function is launched through a button click.

2.2.3.2.2 The Next X of Y screen function should not be presented if 5 or fewer records

Confidential Enterprise Rent-A-Car © 2000 11

Y-\APPS\#ARMSWebVApplιcatιon\ARMSWEBV3\@dl-b\Functional SpecsVMA-02-Fιnd Rental LocationVFunctional SpecsVMA-02-FDS-AR SWeb3.0vl 3 doc ARMS Redesign Project -Release 3.0 , Issue: 1.3

Find a Rental Location Issue Date: 9/26/00 are retrieved.

2.2.3.2.3 The Next X of Y screen function should have the X values replaced by the number of records remaining to view (up to five) in this search.

2.2.3.2.4 The Next X of Y screen function should have the Y value replaced by the number of total records returned in the search.

2.2.3.3 Previous 5 of Y

The Previous 5 of Y screen function will allow the USER to view the previous five rental locations that matched the search criteria (and were previously reviewed).

2.2.3.3.1 The Previous 5 of Y screen function is launched through a button click.

2.2.3.3.2 The Previous 5 of Y screen function should not be presented on the initial search results screen. The Previous 5 of Y screen function should only be available if the USER has selected the Next X of Y screen function.

2.2.3.3.3 The Previous 5 of Y screen function should have the Y value replaced by the number of total records returned in the search.

2.2.3.4 Details/Map

The Details/Map screen function allows the USER to review additional information about a rental location presented in the list of matching records. Selecting this screen function will open the Location Details screen for the rental branch selected.

2.2.3.4.1 The Details/Map screen function is launched through a button click.

2.2.3.4.2 Each rental branch location presented in the list of matching locations should have it's own Details/Map button.

2.2.3.5 Search Again

The Search Again screen function will allow the USER to submit the Location Search Criteria Container information on the Matching Location screen and re-initiate the search for matching locations

2.2.3.5.1 The Search Again screen function is launched through a button click.

2.2.3.5.2 If the information submitted to the ARMS/Web system is invalid or incomplete, this screen function should prompt the USER with an error. The error should be specific as to the cause of the failure. All information previously entered should remain populated in each field, with the problem field highlighted or otherwise identified.

Confidential Enterprise Rent-A-Car © 2000 12

Y:VAPPSV#AR ^Web\Applicanon\AR SWEBV3\@dkb\Functional SpecsVMA-02-Find Rental LocationVFunctional SpecsVMA-02-FDS-ARMSWeb3.0vl.3.doc ARMS Redesign Project - Release 3.0 Issue: 1 3 Find a Rental Location Issue Date: 9/26/00

2.3 Location Details Screen

This screen allows the USER to view additional details for a given rental location. This screen supports the View Location Detail alternate flow.

2.3.1 Screen Layout

Confidential Enterpπse Rent-A-Car © 2000 13

Y VAPPSWAR S eb\Application\AR SWEBV3V@dkbVFuncbon_l Sp-c.VMA-02-Fmd Rental LocationVFunctional Specs\MA-02-EDS-ARMSWeb3 Ovl 3 doc ARMS Redesign Project - Release 3.0 Issue. 1.3 Find a Rental Location Issue Date: 9/26/00

2.3.2 Screen Field Definition

Confidential Enterprise Rent-A-Car © 2000 14

Y VAPPS\#ARMSWebV^pplιcatιonVARMSWEBV3V@dkbVFunctιonal SpecsVMA-02-Fιnd Rental LocationVFunctional Specs\MA-02-FDS-ARMSWeb3 Ovl 3 doc ARMS Redesign Project - Release 3.0 Issue: . 1.3 Find a Rental Location Issue Date: 9/26/00

Confidential Enterprise Rent-A-Car © 2000 15

Y:V>-?PSV#ARMSWeb\ApplicationVARMSWEBV3V@dlebVF-nctio-al Specs\MA-02-Find Rental LocationVFunctional SpecsV A-02-FDS-AR SWeb3.0vl .3.doc ARMS Redesign Project - Release 3.0 Issue: 1.3

Find a Rental Location Issue Date: 9/26/00

2.3.3 Screen Function Definition

This section includes the definitions for all functions that can be perfoπned within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.3.3.1 Select this Location

The Select This Location screen function will submit the selected rental branch location to the ARMS/Web system, to be used in other parts of the system.

_*

2.3.3.1.1 Clicking on the Select This Location hyperlink launches the Select this Location screen function.

2.3.3.2 Previous

The Previous screen function will return the USER to the list of locations that was presented based on the search criteria that were entered.

2.3.3.2.1 Clicking on the Prev button launches the Previous screen fimction.

2.3.3.3 Enlarge Map

The Enlarge Map Screen function will retrieve a larger graphic image of the map to the location. The larger image will be placed in the same screen location of the Location Details screen.

2.3.3.3.1 Clicking on the Enlarge Map hyperlink launches the Enlarge Map screen function.

2.3.3.4 Reduce Map

The Reduce Map Screen function will retrieve a smaller graphic image of the map to the location. The smaller image will be placed in the same screen location of the Location Details screen.

2.3.3.4.1 Clicking on the Reduce Map hyperlink launches the Reduce Map screen function.

2.3.3.5 Zoom In

• The Zoom In screen function will retrieve a more specific (more detailed) graphic image of the map to the location. The more specific image will be placed in the same screen location of the Location Details screen.

2.3.3.5.1 Clicking on the Zoom In hyperlink launches the Zoom In screen function.

2.3.3.6 Zoom Out

The Zoom Out screen function will retrieve a more general (less specific) graphic image of the map to the location. The more general image will be placed in the same screen location of the Location Details screen.

2.3.3.6.1 Clicking on the Zoom Out hyperlink launches the Zoom Out screen function.

Confidential Enterprise Rent-A-Car © 2000 ^l6

Y:\APPSV#A MSWebV^plication\AR SWEBV3V@dl-bVFunctional Specs\ A-02-Find Rental LocationVFunctional SpecsVMA-02-FDS-ARMSWeb3.0vl.3.doc ARMS Redesign Project - Release 3.0 Issue: 1.3 Find a Rental Location Issue Date: 9/26/00

Questions and Answers

Issue Number: 307

Question: We have heard from the business that the search by name criteria needs to be better. Today we search by the first three letters of the last name. We need to know what criteria is the preferred method of search to be done. For example: Do we search the entire last name and first name?

Do we search by the first three letters of the last name and the first letter for the first name?

Do we search by first letter of last name and first letter of first name? Need the Business Rule.

Status: 12 User Review

Resolution: 4-17-00, Sean O'Donnell - We have spoken to the Rental Redesign folks to find out how they are doing last/first name matching, and they are not planning to search by name in the new rental system (Telephone Number, Driver's License, and SSN only). They were going to have an 'implied wildcard' search by name, but it was taken out in USER review.

Issue Number: 310

Question: Do we want the ARMS/Web to have search available by phone, zip code/postal code, city and state. Current state only allows for phone number searches. Do we want to search other than phone number

For example: Do we want to search by phone number or zip code?

Do we want to search by phone number or zip code or city? Need Business Rule

Status: Closed - Resolved

Resolution: 3-16-00, Jen Cavanaugh - Talking with Dave Smith.3-22-00,Issue Mtg, Search by phone # & zip code only.

(SHOULD THE ANSWER BE "SEARCH BY PHONE # AND/OR ZIP CODE?) yes it is and/or could be both or one.

Confidential Enterprise Rent-A-Car © 2000 17

Y:\APPSWARMSWebVApplication\AR SWEB 3V@dkbVFunctional SpecsV A-02-Find Rental LocationVFunctional SpecsVMA-02-FDS-AR SWeb3.0vl.3.doc ARMS Redesign Project - Release 3.0 Issue: 1.3 Find a Rental Location Issue Date: 9/26/00

Issue Number: 311

Question: If a daily rental branch is closed, how do we want the system to work? Current state it defaults to Claims Connection. We need clarification on how this should work in the ARMS/Web environment.

3-17-00, Application Team - What do we want to see in the locator, do we want to see just open only or all? If no branch is open do we return to Claims Connection?

Status: Closed - Resolved

Resolution: 3-16-00, Jen Cavanaugh - Stan's team is going to get w/claims Connection to see how this process works after hours. From there we will make some business decisions 3-20-00, Jennifer Cavanaugh - Stan's team needs to research how ARMS & Retail Res Locator works & how they differ. Then we will re-review the question.

3-27-00, Sean - 1 talked with Trent Tinsley and Kim Devallance on this topic, which was EXTREMELY helpful. If the adjuster selects a closed branch, the system will route the ticket based on the type of service established in the insurance company profile:

Insurance companies that do NOT have 24-hour service, the reservation will be routed to the branch that was selected. The branch will do a callback in the morning when they re-open. Insurance companies that have 24-hour service have their reservations re-routed to Claims Connection (who will do a callback prior to 9p in any time zone unless otherwise specified by an adjuster) if the selected office is not open. This determination is made in the background after the adjuster submits the reservation. Claims connection will re-route the reservation to the appropriate branch when the customer is contacted.

Essentially, the way that location selection is handled today can/should be supported in the future version of ARMS Web (location selection is implied through the F2 - Rates fimction of

ARMS/400). Please let me know if you have questions with regard to this issue update/resolution.

4-7-00, Issue Mtg, Sean to check with Carl Jensen to see if the locator pulls back open/closed office. Given Sean's update we can close after that, (Don't show to the adjuster that the reservation was sent to claims connection)

Confidential Enterprise Rent-A-Car © 2000 18

Y \APPSV#AR SWeb\ApplιcatιonVARMSWEBV3V@dkbVFunotιonal SpecsVMA-02-Fmd Rental LocationVFunctional SpecsVMA-02-FDS-ARMSWeb3 Ovl 3 doc ARMS Redesign Project - Release 3.0 Issue: 1.3 Find a Rental Location Issue Date: 9/26/00

Issue Number: 374

Question: In the Create Reservation functional specification, we have stated that the system will pull a location and rates immediately for the USER The issue arises when we have no location to retrieve, in cases that the 'where needed' search criteria is weak or we don't have a branch within 50 miles of the search area. In the current state, we show Claims Connection as if it were a branch in this situation. This can be somewhat confusing (to see the location on Hanley Road in St. Louis if you are in Delaware). In the future state, we think it may be a good idea to notify the USER that no location was found, and that the reservation would be handled by Claims Connection (see example message below). Any thoughts on this question... EXAMPLE MESSAGE:

A rental branch could not be found within 50 miles of 555-512-5000. Claims Connection will ensure your reservation is handled immediately. Please call 800-CLAIMSCONNECTION for additional assistance.

Status: Pending

Resolution: 5-8-00, Response from Sean O'Donnell: Dave liked the idea, and so did Kim. Have not heard from Randy on this one, though. Let me know if you need me to follow up, otherwise this will be written in to the specification for Finding a rental location.

Confidential Enterprise Rent-A-Car © 2000 19

Y:VAPPSWAR SWebVApplicationVAR SWEBV3V@dkbVFιmction-l SpecsVMA-02-Fiπd Rental LocationVFunctional SpecsVMA-02-FDS-AR SWeb3.0vl.3.doc Enterprise Rent-A-Car

Functional Design Specification

Send Message

Version 1.1

Last Saved: 7/18/004:25 PM

NOTE: Revisions have been turned on within this document to assist readers of previous versions to quickly reference the parts of the functional specification have changed. This can make the document difficult to read, and vou may consider accepting all revisions to get an 'easier to read' version of the document. To accept revisions, select Tools X Track Changes -> Accept or Reject

Changes... from the menu bar. Click 'Accept all' and all changes will be accepted, and the document will be easier to understand.

ARMS Redesign Project - Release 2.0 Issue: 1.1 Send Message Issue Date: 10/20/007/4S/QQ

Confidential Enterprise Rent-A-Car © 2000 ' htto://intr_nct'dm /ReadDocθrUnkΛSP^ WehVRelease QnβVMA-Maintain ΛulhVMΛ .

04 Send MβsεageVFunctional Sp.esVMA-⁽M-FDS-vl.0.do. ARMS Redesign Project - Release 2.0 Issue: 1.1

Send Message Issue Date:

10/20/007/48/00

Table of Contents

1. Send Message Use Case

1.1 Brief Description

1.2 Use Case Actors

1.3 Pre-Conditions

1.4 Flow of Events

1.4.1 Activity Diagram 2

1.4.2 Basic Flow 2

1.4.3 Alternative Flows 2

1.5 Post-Conditions 3

1.6 Special Requirements 3

1.6.1 Submit Message Responsibilities 3

1.7 Extension Points 3

2. Screen Design 4

2.1 Message Screen Container 4

2.1.1 Screen Layout 4

2.1.2 Message Screen Container 4

2.1.3 Screen Function Definition 54

3. Questions and Answers 8 i-. — Send Message Use Case

4-Λ Brief Description 3 Use Case Actors 3 Pre-Conditions 4 Flow of Events AΛ Activity Diagram

4 ,2 Basic Flow

4=4 Alternative Flows

45 Post-Conditions- € Special Requirements τ6rl Submit Message Responsibilities

4τ3 Extension Points

2-. — Screen Design

2Λ Message Screen Container

2AΛ Screen Layout

2 _^2 Message Screen Container A3 Screen Function Definition

2-. — Application Operations

3τ4 Create Transaction Transmission key

Sτ Store a Message

-Data Fields

AΛ Data Field Definition

AXΛ message ecars indicator

4.1.2 message text

Confidential Enterprise Rent-A-Car © 2000 " http://intranet/dm₂/ReadIλκ^Liιrf ,ASP?FolderI^ WebVReleasi OneVMΛ Maintain AuthVMA-

64-Send Messag-VFunctional Spec-\MA-M-FDS-vl .O.doc ARMS Redesign Project - Release 2.0 Issue: 1.1

Send Message Issue Date:

1O/20/007 8/OO

-Questions and Answers

Confidential Enterprise Rent-A-Car © 2000 >" htto//mtr-flet'dm /ReadDocθrLink.ASP?Fo1der^ WebVRel-ase OneVMΛ Maintain ΛuthVMΛ

01 Send MessagβVFunctional Spβc-VMΛ-Oi-FDS-vl.O.do. ARMS Redesign Project - Release 2.0 Issue: 1.1 Send Message Issue Date: _^^_ 10/20/007 18 ΘO

Send Message

1. Send Message Use Case

1.1 Brief Description

This use case describes the process of capturing messages and diary notes associated with a rental reservation/authorization. The USER can elect to either have the message sent to the Enterprise rental branch location responsible for the reservation/authorization (MESSAGE in this document), or to store the note in the ARMS Web system without sending the message to Enteφrise (DIARY NOTE in this document). All MESSAGES and DIARY NOTES captured must be related to a specific reservation/authorization.

NOTE: This is a sub-use case that must be accessed from another use case. For example, a USER may send a message while creating a reservation, maintaining an authorization, or completing an extension.

1.2 Use Case Actors

The following actors will interact with this use case. All actors are referred to as USER throughout this use case:

• ADJUSTER - The ADJUSTER will use this use case to enter and send a message about a reservation/authorization to the rental branch location that is responsible for the reservation/authorization. The ADJUSTER may also use this use case to capture diary notes.

• PROCESSOR - The PROCESSOR will use this use case to enter and send a message about a reservation/authorization to either the rental branch location or the ADJUSTER that is responsible for the reservation/authorization.

• ENTERPRISE ADMINISTRATOR - The ENTERPRISE ADMINISTRATOR will use this use case to send a message on a specific transaction to notify the rental branch location or other user of issues/complications in transmission of the transaction.

1.3 Pre-Conditions

• The USER must be signed-on to the ARMS Web system.

• The USER must have selected an authorization that is in a state that allows MESSAGES or DIARY NOTES.

1.4 Flow of Events

The Flow of Events includes all steps necessary to enter MESSAGES and DIARY NOTES.

Confidential Enterprise Rent-A-Car © 2000 1 htto Λntranet/dm_/ReadDocθrUnk.AS.^>?FoldCTl^

0<l Send MasoagtVFunςtional Sp.csVMA OI-FDS vl.O.doc ARMS Redesign Project - Release 2.0 Issue: 1.1 Send Message Issue Date: 10/20/00348/00

1.4.1 Activity Diagram

1.4.2 Basic Flow

The Basic Flow of the Send Message use case includes all of the required steps for the USER to enter a

MESSAGE or DIARY NOTE.

1. The USER will indicate that they want to send a MESSAGE for a reservation/authorization.

2. The system will display a screen that will capture the message/note text.

3. The USER will enter the message/note text.

4. The USER returns to the parent use case, and the system stores the text message to be sent at a later time (see Special Requirements).

5. This ends this use case.

14.3 Alternative Flows

1.4.3.1 Send Diary Note Only

The USER will have the ability to indicate that the MESSAGE text should be stored as a DIARY NOTE only in Step 3 of the Basic Flow. This text should not be sent to the Enteφrise rental branch location handling the reservation/ticket.

Confidential Enterprise Rent-A-Car © 2000 2 http /intranefr'dm2 ReadDocθrUnkΛSP?Foto^

ARMS Redesign Project - Release 2.0 l_ssue: j . j Send Message Issue Date: 10/20/007 18 00

14.3.2 Use Case Cancellation

The USER should be capable of leaving the use case at any time.

1.5 Post-Conditions

• If successful, the message/note text will be updated in the ARMS Web database. MESSAGES requested to be sent to the rental branch location are sent to ARMS.

• If unsuccessful, the system state remains unchanged.

1.6 Special Requirements

1.6.1 Submit Message Responsibilities

The parent use case that accessed this function will have the responsibility of submitting the text message to the ARMS Web database. Based on USER input, the parent use case must complete the following action:

• If the USER chose to have the text sent to the rental branch location as a MESSAGE, the text will be written to the ARMS Web database and the MESSAGE will be sent to ARMS. ARMS will forward the text to ECARS for distribution to the appropriate rental branch.

• If the USER chose to save the text as a DIARY NOTE, the text will be written to the ARMS Web database as a DIARY NOTE only.

1.7 Extension Points

None.

Confidential Enterprise Rent-A-Car © 2000 3 http://intnfflet/dm2/ReadDocθr ink.ASP?Folder^ W hMteleas. Qne\MΛ Maintain Auth\MA-

04-Send M»scag»\Fιm.rional Specs\MΛ 01 FDS-vl.O.do. ARMS Redesign Project - Release 2.0 Issue: 1.1 Send Message Issue Date: 10/20/007/18/00

Screen Design

As noted in the Send Message Use Case, the Send Message function will be available on multiple screens throughout the system (e.g., Create Reservation, Extend Rental, Change Authorization). This section provides functional description of the screen container that is used on the multiple screens to support the Send Message use case.

2.1 Message Screen Container

2.1.1 Screen Layout¹

The area of the screen under consideration is the container beginning with the Notebook heading-aad ending with the Send this message to Enterprise rental branch checkbox. This is an example of how the message container might look on any given screen.

2.1.2 Message Screen Container

Screen Label ^:ielJ aιr.e Datal-'ieM ScreenSpeeificRule

Send this message Check Box Diary Note message ecars If unchecked, the message will be sent to Enterprise Tπrlϊr*fltπr indicator to ARMS to be sent to the rental branch rental branch location. If checked, the message will be stored in the ARMS Web database but will NOT be forwarded to ARMS. sNpte Input Text 200 Message Text message text Text enetered into this field will be sent to Enterprise to the Enterprise rental branch location.

Note to Self Only Input Text 200 Message Text Diary text Text entered into this field will be stored in the ARMS Web database but will not be sent to the Enterprise rental branch location.

¹ This is the screen layout forthe Create Reservtaion screen. The Message screen container is part of this screen, and is shown here for illustrative purposes only.

Confidential Enteφrise Rent-A-Car © ₂000 http : intr-net/dm:^ead&x^Unl \S FoIdg^ WebM>.el«.-. OncAMΛ Mointain AuthVMΛ

ARMS Redesign Project - Release 2.0 Issue: 1.1

Send Message Issue Date:

10/20/003A3/QO

2 2..11..33 S sccrreeeenn F Fuunnccttiioonn D Deeffiinniittiioonn

The Message screen container will use the functions of the parent screen to have the message sent.

Confidential Enteφrise Rent-A-Car © 2000 5 htte/Λntranet/oW/ReadD<x*-frLinkΛ WebVReleasβ OneVMΛ Maintain AuthWlA

O'l Send Mescag»\Fun.tional SpocsVMA (M-FDS vl.O.doc ARMS Redesign Project - Release 2.0 Issue: 1.1 Send Message Issue Date: 10/20/007 lg ΘO

3τ Application Operations

This section will detail all the application operations that are part of this Functional Specification Document.

3.1 Create Transaction Transmission-key

(Office Identifier, Customer Transaction Identifier)

This operation will use the parameters provided to generate and return a Transaction Transmission key.

3.2Store a Message

(Office Identifier, Customer Transaction Identifier, Send Message Indicator, Message Text) This operation will add the information entered by the USER to the ARMS Web database.

Confidential Enteφrise Rent-A-Car © 2000 6 http://intranet/dm /ReadDocθrLink.ASP?Fo1derπ ^

M Sond McssageVFunctional Sp-csVMA 0 FDS-vI.O.do- ARMS Redesign Project - Release 2.0 Issue: 1.1 Send Message Issue Date: 10/20/003/-18/OΘ

4.Data Fields

4.1 Data Field Definition

This section includes a definition of all data fields included in the functional specification.

4.1.1 Customer Transaction ID

4.1.2external organization abbreviated name

Entity EXTERNAL ORGANIZATION

Column Name e o abbr nam-

Label Name external organization abbreviated name:

System Name EOΛBBRNΛM

Data Type CHΛR(IO)

4.1.4mes$age ecars indicator

4.1.5message text

Confidential Enteφrise Rent-A-Car © 2000 1 hto:// tr-net'dm-7R.adIλx* Link.ASP?FoldCT

O'l Send Messag.vFunctional SpgcsVMA-O'l-FDS-vl.O.do. ARMS Redesign Project - Release 2.0 Issue: 1.1 Send Message Issue Date:

5_*3. Questions and Answers

Issue Number: 341

Question: Current state ARMS400 allows user to enter maximum of four lines of fifty characters. Current state ARMS has program limitation often lines of fifty characters. ARMS Web will be limited by current state ARMS. Should that be the planned maximum for ARMS Web or ??? One idea would be to have the number of lines/characters profiled. Then the size of the message box that is displayed to the user would be limited by this profiled amount.

Status: Closed - Resolved

Resolution: 3-30-00, Kim DeVallance - 1 think ten lines of fifty characters to be entered by any user at a time is more than enough. I don't really for see the need to profile this by company

Issue Number: 342

Question: Current state allows message to be sent on unauthorized requests only if they have not been assigned to an adjuster. How should future state work? If we allow messages on assigned unauthorized requests, we must keep in mind that we are defaulting the Direct-Bill To percent at 100% on all auth. screens. When the adjuster submits the message, they MAY be unintentionally authorizing the request.

Status: Closed - Resolved

Resolution: 3-30-00, Kim DeVallance - Kim: we should never send an authorization to the branch if all the adjuster did was key in a message. The message will either appear in ECARS under res notes or callback notes, but should never appear to the branch as an authorization. We not only need to give the adjuster the ability to send a message, but they should be able to change info (such as claim number, claim type, etc) before assigning the request to the adjuster, thereby enabling the adjuster to see the correct info when authorizing or denying a DB. We hear this request a lot from our customers.

Confidential Enterprise Rent-A-Car © 2000 8 http://intranet/dmmeadDocC>rLink.ASP?FolderID=₂^^^ WebVReleas. QneVMA Maintain AuthVMΛ.

O'l Send MβssageVFunctional SpecsVMA-O'l FDS-vl.O.doe Enterprise Rent-A-Car

Functional Design Specification Additional Charges

Version 1.2

Last Saved: 8/15/002:45 PM

ARMS Redesign Project - Release 2.0 Issue: 1.2 Additional Charges Issue Date: 8/15/2000

Revision History

Confidential Enterprise Rent-A-Car © 2000 http^/inti-net d ₂/ReadDocOrLink.ASP?Folderπ =₂70₃&Docπ 96₃8 ARMS Redesign Project - Release 2.0 Issue: 1.2

Additional Charges Issue Date: 8/15/2000

Table of Contents

1. Addi itional Charges Use Case

1.1 Brief Description

1.2 Use Case Actors

1.3 Pre-Conditions

1.4 Flow of Events

1.4.1 Activity Diagram 2

1.4.2 Basic Flow 2

1.4.3 Alternative Flows 3

1.5 Post-Conditions 3

1.6 Special Requirements 3

1.6.1 Submit Additional Charges Responsibilities 3

1.6.2 Additional Charges Descriptions 4

1.7 Extension Points 4

2. Screen Design 5

2.1 Additional Charges 5

2.1.1 Screen Layout 5

2.1.2 Screen Field Definition 5

2.1.3 Screen Function Definition 6

3. Questions and Answers 7

Confidential Enteφrise Rent-A-Car © 2000 httpΛintιanet/(-m₂ Read0ocθrLink-ASP?FoIderID=₂70₃&DcιcII =96₃8 ARMS Redesign Project - Release 2.0 Issue: 1.2

Additional Charges Issue Date: 8/15/2000

Additional Charges

1. Additional Charges Use Case

1.1 Brief Description

The Additional Charges use case will allow the USER to view, add, or modify/remove any additional charges that may be associated with a rental authorization. Additional Charges such as Collision/Damage Waiver (CDW), Mileage Charge, or any other rental related charge could be authorized by a USER through this function.

1.2 Use Case Actors

The following actors will interact with this use case:

• ADJUSTER - The ADJUSTER will use this use case to view, add, or modify any additional charges that are associated with a rental authorization.

1.3 Pre-Conditions

• The USER must be signed-on to the ARMS Web system.

• The USER must have a reservation or open ticket selected (active).

1.4 Flow of Events

The Flow of Events will include the necessary steps to view, add and modify additional charges associated with a rental authorization.

Confidential Enterprise Rent-A-Car © 2000 http^/intranet/dm₂/ReadDocθr inkΛSP?FolderID=₂70₃&DocID=%₃8 ARMS Redesign Project - Release 2.0 Issue: 1.2 Additional Charges Issue Date: 8/15/2000

1.4.1 Activity Diagram

Additional Charges Activity Diagram

1.4.2 Basic Flow

The Basic Flow of the Additional Charges use case includes all of the required steps to view, add, or modify Additional Charges as part of an authorization.

1. The USER will select Additional Charges for the active reservation or open ticket.

2. The system will prompt the USER to add, modify or remove Additional Charges.

3. The USER will view, add, or modify Additional Charges that will be authorized.

4. The USER will submit the Additional Charges to the system.

5. The system will validate the Additional Charges entered by the USER.

Confidential Enteφrise Rent-A-Car © 2000 http^ intranet dm₂/ReadDocθrLink ASP?FoIderII>=₂70₃--DocID=96₃8 ARMS Redesign Project - Release 2.0 Issue: 1.2

Additional Charges Issue Date: 8/15/2000

6. The system will return the USER to the active reservation or open ticket and populate Additional Charges¹.

7. This ends this use case.

14.3 Alternative Flows

1.4.3.1 Additional Charges Invalid

If the Additional Charges entered by the USER are invalid, the system should present an error message to the USER and force the USER back into Step 2 of the Basic Flow. The system will declare additional charges invalid in the following circumstances:

1.4.3.1.1 It will be considered invalid if the additional charge type is 'Dollars per Day' or 'Dollars per Rental' and the additional charge value entered is greater than $999.99.

1.4.3.1.2 It will be considered invalid if the additional charge type is 'Dollars per Day' or 'Dollars per Rental' and the additional charge value entered is less than $0.

1.4.3.1.3 It will be considered invalid if the additional charge type is 'Percentage of Rental' and the additional charge value entered is greater than 100%.

1.4.3.1.4 It will be considered invalid if the additional charge type is 'Percentage of Rental' and the additional charge value entered is less than 0%.

1.5 Post-Conditions

• If successful, the Additional Charges that were added or modified will be returned to the active reservation or open ticket

• If unsuccessful, no Additional Charges will be added to the active reservation or open ticket.

1.6 Special Requirements

The additional requirements of the business use case are included here. These are requirements not covered by the flow as they have been described in the sections above.

1.6.1 Submit Additional Charges Responsibilities

The parent use case that accessed this function will have the responsibility of submitting the additional charges to the ARMS Web database. Any additional charges returned to a parent use case should be reflected on the screen within that use case. For example, if additional charges were being added as part of the Create Reservation process, the Create Reservation screens should have some indication that additional charges have been added.

¹ The Additional Charges should not be submitted to the ARMS Web database until the USER submits the changes on the active reservation or open ticket.

Confidential Enteφrise Rent-A-Car © 2000 3 htφ-i/intι_net dm₂/ReadDocθrLinkASP?FolderID=2703cS-Docπ>=96₃8 ARMS Redesign Project - Release 2.0 Issue: 1.2 Additional Charges Issue Date: 8/15/2000

1.6.2 Additional Charges Descriptions

Below are the current additional charge descriptions used in the ARMS/400 system in the current state:

DAMAGE WAIVER SPECIAL

PAl DROP CHARGE

MILEAGE CHARGE MISC CHARGES

HOURLY SLP

DAILY UNDERAGE DRIVER

WEEKLY BABY CAR SEAT

MONTHLY ^• SKI RACK

1.7 Extension Points

None.

Confidential Enteφrise Rent-A-Car © 2000 http^/intranet dm₂/ReadDocθrLink.ASP?FolderID=₂703&DocID=9638 ARMS Redesign Project - Release 2.0 Issue: 1.2 Additional Charges Issue Date: 8/15/2000

Screen Design

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Additional Charges

This screen will allow the user to view, add, modify or remove additional charges associated with a reservation/authorization.

2.1.1 Screen Layout

2.1.2 Screen Field Definition

Confidential Enteφrise Rent-A-Car © 2000 http^/intranet/dm2/ReadDocθr ink.ASP?FolderID=2703&Docπ =9638 ARMS Redesign Project - Release 2.0 Issue: 1.2 Additional Charges Issue Date: 8/15/2000

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.1.3.1 Create More Surcharges

The Create More Surcharges screen function will allow the USER to select the hyperlink and have an additional Misc. Charge line added to the screen. For example, the Screen Layout above shows only one Misc. Charge box. If a USER were to click on the Create More Surcharges hyperlink, the screen would refresh and provide the user with two Misc. Charges boxes. The USER is not limited to the number of Misc. Charge boxes that can be added.

2.1.3.1.1 The Create More Surcharges screen function is invoked through clicking a hyperlink.

2.1.3.2 Process

The Process screen function allows the USER to save the additional charges that are being authorized and return to the active reservation or open ticket. The active reservation or open ticket will reflect that additional charges have been added.

2.1.3.2.1 The Process screen function is invoked through a button click or through an Enter keystroke.

2.1.3.3 Previous

The Previous screen function will allow the USER to return to the active reservation or open ticket without saving the updates to additional charges.

2.1.3.3.1 The Previous screen function is invoked through a button click.

Confidential Enteφrise Rent-A-Car © 2000 ARMS Redesign Project - Release 2.0 Issue: 1.2

Additional Charges Issue Date: 8/15/2000

3. Questions and Answers

None.

Confidential Enteφrise Rent-A-Car © 2000 httpΛ"ntr-net/dm ReadDocθrLinkASP?FoIderII =2703-_Docπ>=9638 Enterprise Rent-A-Car

Functional Design Specification Additional Charges

Version 1.2

Last Saved: 8/15/002:45 PM

ARMS Redesign Project - Release 2.0 Issue: 1.2 Additional Charges Issue Date: 8/15/2000

Revision History

Date Issue Description Author

2000-04-07 0.1 Initial draft published to cross-team QA Brent Armbruster; Sean process O'Donnell

2000-04-11 0.2 Removed subdocuments. Updated Cindy Bastean formatting in Data Fields Section

2000-05-01 0.3 Added screen fields to "Additional Cindy Bastean Charges" screen field table

2000-05-08 0.4 Additional enhancements and changes Sean O'Donnell made to the functional specification to incorporate comments made in the initial review session.

2000-05-24 0.5 Revisions made as a result of the Iteration 2 Sean O'Donnell cross-team review.

2000-05-30 0.6 Added data field information from Cindy Bastean DATA FIELDS

2000-07-18 1.1 Changes made to the functional Sean O'Donnell specification since the last review session were incorporated into the document.

2000-08-15 1.2 Added the screen design section to the Sean O'Donnell specification based on the updated screens received from Marketing.

Confidential Enteφrise Rent-A-Car © 2000 httprfintranet dm₂/ReadDocθr ink.ASP?FolderID=₂703&DocID=9638 ARMS Redesign Project - Release 2.0 Issue: 1.2

Additional Charges Issue Date: 8/15/2000

Table of Contents

1. Additional Charges Use Case

1.1 Brief Description

1.2 Use Case Actors

1.3 Pre-Conditions

1.4 Flow of Events

1.4.1 Activity Diagram 2

1.4.2 Basic Flow 2

1.4.3 Alternative Flows 3

1.5 Post-Conditions 3

1.6 Special Requirements 3

1.6.1 Submit Additional Charges Responsibilities 3

1.6.2 Additional Charges Descriptions 4

1.7 Extension Points 4

2. Screen Design 5

2.1 Additional Charges 5

2.1.1 Screen Layout 5

2.1.2 Screen Field Definition 5

2.1.3 Screen Function Definition 6

3. Questions and Answers 7

Confidential Enteφrise Rent-A-Car © 2000 http://intranet dm2/ReadDocθrLϊn -ASP?FoIderlD=₂70 &DocII>=96₃8 ARMS Redesign Project - Release 2.0 Issue: 1.2

Additional Charges Issue Date: 8/15/2000

Additional Charges

1. Additional Charges Use Case

1.1 Brief Description

The Additional Charges use case will allow the USER to view, add, or modify/remove any additional charges that may be associated with a rental authorization. Additional Charges such as Collision/Damage Waiver (CDW), Mileage Charge, or any other rental related charge could be authorized by a USER through this function.

1.2 Use Case Actors

The following actors will interact with this use case:

• ADJUSTER - The ADJUSTER will use this use case to view, add, or modify any additional charges that are associated with a rental authorization.

1.3 Pre-Conditions

• The USER must be signed-on to the ARMS Web system.

• The USER must have a reservation or open ticket selected (active).

1.4 Flow of Events

The Flow of Events will include the necessary steps to view, add and modify additional charges associated with a rental authorization.

Confidential Enteφrise Rent-A-Car © 2000 httpΛintιanet/dm₂/ReadDocθrLinl ASP?FolderlD=₂70₃&DoclD=96₃8 ARMS Redesign Project - Release 2.0 Issue: 1.2 Additional Charges Issue Date: 8/15/2000

1.4.1 Activity Diagram

Additional Charges Activity Diagram

1.4.2 Basic Flow

The Basic Flow of the Additional Charges use case includes all of the required steps to view, add, or modify Additional Charges as part of an authorization.

1. The USER will select Additional Charges for the active reservation or open ticket.

2. The system will prompt the USER to add, modify or remove Additional Charges.

3. The USER will view, add, or modify Additional Charges that will be authorized.

4. The USER will submit the Additional Charges to the system.

5. The system will validate the Additional Charges entered by the USER.

Confidential Enteφrise Rent-A-Car © 2000 http_'/intι_jιetdm2/Rea(π3ocθr ink.ASP?FolderII>=₂70₃&Docir =9638 ARMS Redesign Project - Release 2.0 Issue: 1.2

Additional Charges ___ Issue Date: 8/15/2000

6. The system will return the USER to the active reservation or open ticket and populate Additional Charges¹.

7. This ends this use case.

1.4.3 Alternative Flows

1.4.3.1 Additional Charges Invalid

If the Additional Charges entered by the USER are invalid, the system should present an error message to the USER and force the USER back into Step 2 of the Basic Flow. The system will declare additional charges invalid in the following circumstances:

1.4.3.1.1 It will be considered invalid if the additional charge type is 'Dollars per Day' or 'Dollars per Rental' and the additional charge value entered is greater than $999.99.

1.4.3.1.2 It will be considered invalid if the additional charge type is 'Dollars per Day' or 'Dollars per Rental' and the additional charge value entered is less than $0.

1.4.3.1.3 It will be considered invalid if the additional charge type is 'Percentage of Rental' and the additional charge value entered is greater than 100%.

1.4.3.1.4 It will be considered invalid if the additional charge type is 'Percentage of Rental' and the additional charge value entered is less than 0%.

1.5 Post-Conditions

• If successful, the Additional Charges that were added or modified will be returned to the active reservation or open ticket.

• If unsuccessful, no Additional Charges will be added to the active reservation or open ticket.

1.6 Special Requirements

The additional requirements of the business use case are included here. These are requirements not covered by the flow as they have been described in the sections above.

1.6.1 Submit Additional Charges Responsibilities

The parent use case that accessed this function will have the responsibility of submitting the additional charges to the ARMS Web database. Any additional charges returned to a parent use case should be reflected on the screen within that use case. For example, if additional charges were being added as part of the Create Reservation process, the Create Reservation screens should have some indication that additional charges have been added.

¹ The Additional Charges should not be submitted to the ARMS Web database until the USER submits the changes on the active reservation or open ticket.

Confidential Enteφrise Rent-A-Car © 2000 3 htrp:/ ^"ntr_net dm₂yReadDocθrLink.ASP?FolderID=₂703&DocID=9638 ARMS Redesign Project - Release 2.0 Issue: 1.2 Additional Charges Issue Date: 8/15/2000

16.2 Additional Charges Descriptions

Below are the current additional charge descriptions used in the ARMS/400 system in the current state:

DAMAGE WAIVER SPECIAL

PAJ DROP CHARGE

MILEAGE CHARGE MISC CHARGES

HOURLY SLP

DAILY UNDERAGE DRIVER

WEEKLY BABY CAR SEAT

MONTHLY SKI RACK

1.7 Extension Points

None.

Confidential Enteφrise Rent-A-Car © 2000 http^/inttanet/dm₂/ReadDocθrUnk.ASP?FolderID=₂703&DocII>=9638 ARMS Redesign Project - Release 2.0 Issue: 1.2 Additional Charges Issue Date: 8/15/2000

2. Screen Design

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Additional Charges

This screen will allow the user to view, add, modify or remove additional charges associated with a reservation/authorization.

2.1.1 Screen Layout

2.1.2 Screen Field Definition

Confidential Enteφrise Rent-A-Car © 2000 httpΛntranet/dm₂/ReadDocθrLink.ASP?FolderID=₂703&DocID=9638 ARMS Redesign Project - Release 2.0 Issue: 1.2 Additional Charges Issue Date: 8/15/2000

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.13.7 Create More Surcharges

The Create More Surcharges screen function will allow the USER to select the hyperlink and have an additional Misc. Charge line added to the screen. For example, the Screen Layout above shows only one Misc. Charge box. If a USER were to click on the Create More Surcharges hyperlink, the screen would refresh and provide the user with two Misc. Charges boxes. The USER is not limited to the number of Misc. Charge boxes that can be added.

2.1.3.1.1 The Create More Surcharges screen function is invoked through clicking a hyperlink.

2.1.3.2 Process

The Process screen function allows the USER to save the additional charges that are being authorized and return to the active reservation or open ticket. The active reservation or open ticket will reflect that additional charges have been added.

2.1.3.2.1 The Process screen function is invoked through a button click or through an Enter keystroke.

2.1.3.3 Previous

The Previous screen function will allow the USER to return to the active reservation or open ticket without saving the updates to additional charges.

2.1.3.3.1 The Previous screen function is invoked through a button click.

Confidential Enteφrise Rent-A-Car © 2000 httpΛ^"ntranet dπι₂/ReadDocθrLinkΛSP?FolderlI>=270₃&DocID=9638 664

ARMS Redesign Project - Release 2.0 Issue: 1.2 Additional Charges Issue Date: 8/15/2000

3. Questions and Answers

None.

Confidential Enteφrise Rent-A-Car © 2000 httpΛintranet/dm2/ReadDocθr ink-ASP?FolderlD=2703&DoclI 9638 Enterprise Rent-A-Car

Functional Design Specification

View Car Class

Version 1.2

Last Saved: 8/16/003:57 PM

ARMS Redesign Project - Release 2.0 Issue: 1.1 View Car Class Issue Date: 10/20/00

Revision History

Confidential Enteφrise Rent-A-Car © 2000 http://intranet/dm2/ReadDocθr ink.ASP?FolderII>=₂703&DocII>=97₃₃ ARMS Redesign Project - Release 2.0 Issue: 1.1

View Car Class Issue Date: 10/20/00

Table of Contents

1. View Car Class Use Case

1.1 Brief Description

1.2 Use Case Actors

1.3 Pre-Conditions

1.4 Flow of Events

1.4.1 Activity Diagram 2

1.4.2 Basic Flow 3

1.4.3 Alternative Flows 3

1.5 Post-Conditions 3

1.6 Special Requirements 4 1.6.1 Modify Car Class Selection Results 4

1.7 Extension Points 4

2. Screen Design 5

2.1 Car Class Detail Screen 5

2.1.1 Screen Layout 5

2.1.2 Car Class Details 5

2.1.3 Screen Function Definition 6

3. Questions and Answers 7

Confidential Enteφrise Rent-A-Car © 2000 http://intranet/dm2/ReadDocθrLink.ASP?FolderID=2703&DocID=9733 ARMS Redesign Project - Release 2.0 Issue: 1.1

View Car Class Issue Date: 10/20/00

View Car Class

1. View Car Class Use Case

1.1 Brief Description

This use case will allow the USER to view examples of automobiles that are part of each Enterprise Car Class. The USER will have the ability to select a car class and have the rate for the car class apply to the reservation/authorization.

1.2 Use Case Actors

The following actors will interact with this use case:

• ADJUSTER - The ADJUSTER will use this use case to view and/or select the car class that will apply to a reservation.

1.3 Pre-Conditions

• The USER must be signed-on to the ARMS Web system.

• The USER must have a reservation or open ticket selected.

1.4 Flow of Events

The Flow of Events will include the necessary steps to view and/or select the car class to apply to a rental reservation.

Confidential Enteφrise Rent-A-Car © 2000 fattp://intranet dm2/ReadDocθr ink.ASP?FolderiD=₂703&DocID=9733 ARMS Redesign Project - Release 2.0 Issue: 1.1 View Car Class Issue Date: 10/20/00

1.4.1 Activity Diagram

View Car Class Activity Diagram

Confidential Enteφrise Rent-A-Car © 2000 http://intranet dm2/ReadDocθrLink.ASP?FolderlD=2703&DoeID=9733 ARMS Redesign Project - Release 2.0 Issue: 1.1

View Car Class Issue Date: 10/20/00

1.4.2 Basic Flow

The Basic Flow of the View Car Class use case includes all of the required steps to view and/or select a car class for a rental reservation. If a car class is selected, it will be used to populate rate information on a rental authorization.

1. The USER will select View Car Class from the active reservation or open ticket.

2. The system will display a car class detail screen. If the USER had previously selected a car class (for example, on the Create Reservation screen), the car class selected will be displayed. If no car class has been selected, the system will display the Standard car class.

3. The USER will select the car class to apply to the reservation or open ticket.

4. The system will return the USER to the active reservation or open ticket and populate car class information based on the car class selected.

5. This ends this use case.

1.4.3 Alternative Flows

1.4.3.1 Select Alternate Car Class

From Step 2 of the Basic Flow, the USER will have the ability to view an alternate car class. The car classes that will be available to view include:

^■ Economy • Compact

^■ Intermediate

^■ Standard

^■ Full Size

^■ Premium

If the USER selects an alternate car class, the system will refresh and present the details of the new car class.

1.4.3.2 Populate Car Class Rates

If a rental branch location has already been selected prior to entering this use case, the selection of a car class will populate the rates that apply to the selected car class on the active reservation or open ticket This alternate flow returns the USER to Step 4 of the Basic Flow.

1.5 Post-Conditions

• If successful, the selected Car Class will be returned to the active reservation or open ticket.

• If unsuccessful, the system state is unchanged.

Confidential Enteφrise Rent-A-Car © 2000 http://intranetd 2/ReadDocOr ink.ASP?FolderlD=2703&DocID=9733 ARMS Redesign Project - Release 2.0 Issue: 1.1

View Car Class Issue Date: 10/20/00

1.6 Special Requirements

The additional requirements of the business use case are included here. These are requirements not covered by the flow as they have been described in the sections above.

1.6.1 Modify Car Class Selection Results

The USER may change the results of this use case as part of the active reservation or open ticket.

1.7 Extension Points

None.

Confidential Enteφrise Rent-A-Car © ₂000 htt^p://intranet⁽'dn2 ReadDocOr iιι .ASP?FolderIl 2703&DoeII 9733 ARMS Redesign Project - Release 2.0 Issue: 1.1

Issue Date: 10/20/00 View Car Class

2. Screen Design

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Car Class Detail Screen

This screen will allow the USER to view detailed information about Enterprise car classes. The USER will also have the ability to select a car class to apply to a rental reservation / authorization.

2.1.1 Screen Layout

2.1.2 Car Class Details ith SercenFiel-iNimie DauiFi-ld Sor enSpeei tϊeRulf

Confidential Enteφrise Rent-A-Car © 2000 http://intranet^dm2/ReadDocOrLinl-ASP?FoIderID=2703&DoeID=9733 ARMS Redesign Project - Release 2.0 Issue: 1.1 View Car Class Issue Date: 10/20/00

Screen Label SereenFieldNamc DatuField SerocnSpccificRuli-

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.1.3.1 Select This Car Class

The Continue screen function will allow the USER to select the car class to apply to a reservation.

2.1.3.1.1 The Continue screen function is invoked through either a button click or through an Enter keystroke.

2.1.3.2 Previous

The Previous screen function allows the USER to return to the previous screen.

2.1.3.2.1 The Previous screen function is invoked through a button click.

Confidential Enteφrise Rent-A-Car © 2000 http:/⁽'mtranet dm2/ReadDocOr ii!k.ASP?FolderII 2703S;DocID=9733 O 02/067175

674

ARMS Redesign Project - Release 2.0 Issue: 1.1

View Car Class Issue Date: 10/20/00

3. Questions and Answers

None.

Confidential Enterprise Rent-A-Car © 2000 http^mtranet/dm2/ReadDo:OrLink.ASP?FolderID=27^Q3&DoclD=9733 Enterprise Rent-A-Car

Functional Design Specification

Assign a Request

Version 1.1

Last Saved: 10/17/002:24 PM

ARMS Redesign Project - Release 1.01 Issue: vl.l Assign a Request Issue Date: 10/20/00

Confidential Enterprise Rent-A-Car © 2000 http://intranetdm2/ReadDocOt ink.ASP?FolderID=27M&DocID=115₄2 ARMS Redesign Project - Release 1.01 Issue: vl.l

Assign a Request Issue Date: 10/20/00

Table of Contents

1. Assign a Request Use Case

1.1 Brief Description

1.2 Use Case Actors

1.3 Pre-Conditions

1.4 Flow of Events

1.4.1 Activity Diagram 2

1.4.2 Basic Flow ³

1.4.3 Alternative Flows 3

1.5 Post-Conditions 3

1.6 Special Requirements 3

1.7 Extension Points 3

1.7.1 MA-04 Send Message 3

1.7.2 MA- 10 Authorize a Reques 3

1.7.3 MA-17 Cancel Authorization 3

2. Screen Design 4

2.1 Action Items - Unassigned 4

2.1.1 Screen Layout - Action Items - Unassigned 4

2.1.2 Action Items - Unassigned 5

2.1.3 Screen Function Definition 5

3. Application Operations 7

Data Fields

4.1 Data Field Definition

4.1.1 Address Line

4.1.2 City

4.1.3 claim type code

4.1.4 claim type description

4.1.5 company identifier 9

4.1.6 DATE OF LOSS 9

4.1.7 Day Phone 9

4.1.8 external organization abbreviated name 9

4.1.9 external organization identifier 9

4.1.10 First Name 10

4.1.11 First Name 10

4.1.12 handled by adjustor code 10

4.1.13 handled by company identifier 10

4.1.14 handling for adjustor code 10

4.1.15 handling for company identifier 1

4.1.16 Insurance Claim Number 1

4.1.17 Last Name 1

4.1.18 Last Name 1

4.1.19 loss type description 1

4.1.20 NOTE 12

4.1.21 Renters Day Phone Extension 12

4.1.22 Renters Night Phone 12

4.1.23 Renters Night Phone Extensin 12

4.1.24 State 12

Confidential Enterprise Rent-A-Car © 2000 tlp://intranet/dm2/ReadDocOrUnk.ASP?FolderID=270 &DoclD=H5 2 ARMS Redesign Project - Release 1.01 Issue: vl.l

Assign a Request Issue Date: 10/20/00

4.1.25 Zip Code 12

5. Questions and Answers 13

Confⁱdential Enterprise Rent-A-Car © 2000 httpΛmtranet/d 2/ReadDocOrUnk.ASP?FolderrD=27⁽M&DocID=115 2 ARMS Redesign Project - Release 1.01 Issue: vl.l

Assign a Request Issue Date: 10/20/00

Assign a Request

1. Assign a Request Use Case

1.1 Brief Description

This use case describes the process of how a USER will review unassigned authorization request and assign them to an adjuster for further handling.

1.2 Use Case Actors

The following actors will interact with this use case:

• CLAIMS PROCESSOR - The CLAIMS PROCESSOR is a USER who can perform this use case to assign a request for further handling.

• ADJUSTER - The ADJUSTER is a USER who can receive the assigned request for further handling.

1.3 Pre-Conditions

• The USER must be signed-on to the ARMS Web system.

• The USER should be authorized to assign a request.

• If there are unassigned requests present, the USER has selected the link from the Review List Action Items Use Case to enter this use case.

1.4 Flow of Events

The Flow of Events will include the necessary steps to make changes and updates to "Assign an Action Item".

Confidential Enteφrise Rent-A-Car © 2000 http://intι_net dm2/ReadDocOrLi-k. ASP?FolderID=270 &DocID=l 1542 ARMS Redesign Project - Release 1.01 Issue: vl.l Assign a Request Issue Date: 10/20/00

1.4.1 Activity Diagram

Assign An Action Item Diagram

Confⁱdential - Enteφrise Rent-A-Car © 2000 http://inlranet/dm2/ReadDocOrLink. ASP?FolderiD=270 &DocID= 115₄2 ARMS Redesign Project - Release 1.01 Issue: v 1.1

Assign a Request Issue Date: 10/20/00

14.2 Basic Flow

1. The USER selects the unassigned authorizations link.

2. The system retrieves all unassigned request summaries.

3. The system retrieves all OFFICE IDs within ARMS Web.

4. The system retrieves all USER IDs within the OFFICE.

5. The system displays the unassigned authorization summaries with the offices and adjusters.

6. The USER selects an adjuster to assign to the request.

7. The system will update the ARMS Web database.

8. This ends the use case.

.4.3 Alternative Flows

1.4.3.1 Cancel Use Case

The USER should be capable of leaving the use case at any point prior to assigning the reservation information to an ADJUSTER

1.4.3.2 Modify a Request

Before step 6 of the basic flow, the USER should be able to make changes to the authorization.

1.4.3.3 Select a different office

Before step 6 of the basic flow, the USER should be able to select a different office for this authorization request. If a different office has been selected, the user cannot assign the file to a new adjuster. The new office must now assign the file.

1.5 Post-Conditions

If the use case is successful, the system will change the request type from an unassigned authorization request to direct bill. If the user has authority to authorize this request, the system will change the request to Authorized status and assign the adjuster picked in Step 5 of the basic flow.

If the use case is unsuccessful, the system state will remain unchanged.

1.6 Special Requirements

None

1.7 Extension Points

1.7.1 MA-04 Send Message

The Send Message function will be used to allow the user to capture messages and diary notes associated with a rental reservation/authorization. The USER can elect to have the message sent to the Enterprise rental branch location responsible for the reservation/authorization. The USER may also send a message without assigning the file to an adjuster/office. All MESSAGES and DIARY NOTES captured must be related to a specific reservation/authorization.

7.7.2 MA-10 Authorize a Reoues

The ADJUSTER may decide to enter into the full detail screen of the unassigned request, which would invoke the Authorize a Request case.

7.7.3 MA-17 Cancel Authorization

At any point prior to assigning the file to an ADJUSTER, the USER should have the ability to cancel the authorization. If the authorization is cancelled, the ADJUSTER will be prompted to select a cancellation reason code from a drop down list along with having the option to enter additional comments.

Confidential Enterprise Rent-A-Car © 2000 ■ http://intranel/dnι2/ReadDocOrLiιιk.ASP?FoIderlD=270 &DocID=115 2 ARMS Redesign Project - Release 1.01 Issue: vl .l Assign a Request Issue Date: 10/20/00

2. Screen Design

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Action Items - Unassigned

This screen will allow the USER assign action items to a claims office or an adjuster or the USER may cancel an item. The USER may also change specified information in the Customer File through this screen.

2.7.7 Screen Layout - Action Items - Unassigned

Yoti just app roved an invoice for Crystal. Billy - Total Amount $536.13

Ac UtNiAoSnS IItGeNmEsD:

Weber. Andrew DIRECT Btt-L. REQUEST O Assisr. to Office: QQ1

284 5 Main Ave Claim Number:|754589877 Chicago, IL 60622 i Assign Adjuster: Unass| ne(- 555-555-1212 Vehicle Condition:| Select a Loss Type |

Cancel this item

Claim Type:) Select α Claim Type jf Date of Loss:) January 20001

Note to Enterprise:]^"

Smith. Joe DIRECT BH.L REQUEST Assign to Office: I 001

28445 Main Ave Claim Numb9r:|754589877 Chicago, IL 60622 θ Assign Adjuster: | Unassigned 555-555-1212 Vehicle Condition:! Select a Loss Type || -or-

O Caπoajthis item Claim Type:|j3elect a CJeum.Jy.p_e [§

Date of Loss:[ January 1| 2000 g|j|

Note to Enterprise:^

Contact Us j Tarmc-. Conditions | Log Off

Confidential Enterprise Rent-A-Car © 2000 http://intranefc'dm₂^eadDocOrLink.ASP?FolderlD=270 &DocID=11542 ARMS Redesign Project - Release 1.01 Issue: vl.l Assign a Request Issue Date: 10/20/00

2.1.2 Action Items - Unassigned

2.1.3

Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.7.3.7 «Previous

When clicked, the USER will be taken back to the previous screen.

2.7.3.2 Process

When clicked, the USER will be taken to the next item in the action item list or a detail of the completed action items. This button ends the use case

2.7.3.3 Cancel

When clicked, the USER will be allowed to cancel the authorization. If this occurs, the rental becomes unauthorized and the rental is no longer the responsibility of the insurance company.

Confidential Enterprise Rent-A-Car © 2000 httpΛintranet/dra2/ ea-C⁾ocOrLink.ASP?FolderID=₂704&DoclD=π542 ARMS Redesign Project - Release 1.01 Issue: v 1.1

Assign a Request Issue Date: 10/20/00

2.1.3.4 Last Action Message

After each action item in the USER's list has been completed, upon arriving at the next item there will be a confirmation message at the top of the screen. This message will be a hyperlink describing the last completed action. If the USER clicks on this link, the system will open the customer file, which will reflect all of the current information for the rental. The USER is then free to make additional changes or to simply view the file.

Confidential Enterprise Rent-A-Car © 2000 ^http^://intr-ne^t dm2 ReadDocOrLink.ASP?FolderID=2704&DocID=H542 ARMS Redesign Project - Release 1.01 Issue: v 1.1

Assign a Request Issue Date: 10/20/00

3. Application Operations

Confidential Enterprise Rent-A-Car © 2000 ttp://inlraπeti'dm2/ReadDocOrLink.ASP?FoIdetID=2704&DocID=' 11541 ARMS Redesign Project - Release 1.01 Issue: vl.l Assign a Request __ Issue Date: 10/20/00

4. Data Fields

4.1 Data Field Definition

This section includes a definition of all data fields included in the functional specification

4.7.7 Address Line

4.7.2 City

4.7.3 claim type code

4.7.4 claim type description

Confidential Enterprise Rent-A-Car © 2000 http://intr-net/dm2/ReadDocOrLink.ASP?FolderlD=270 &DocID=115 2 ARMS Redesign Project - Release 1.01 Issue: vl.l Assign a Request __ Issue Date: 10/20/00

4.7.5 company identifier

Entity EXTERNAL ORGANIZATION

Column Name cmpy_id

Label Name company identifier:

System Name CMPYID

Data Type DEC(11,0)

Attribute Definition Business Party Identifier is a surrogate key assigned to each unique occurrence of an Individual, External Organization, and Internal Organization (Business Party).

4.7.6 DATE OF LOSS

4.7.7 Day Phone

4.7.8 external organization abbreviated name

4.7.9 external organization identifier

Confidential Enterprise Rent-A-Car © ₂000 http://intranet dm2/ReadDo Orl.ink.ASP?FolderID=270₄&DocID=115 2 ARMS Redesign Project - Release 1.01 Issue: vl .l Assign a Request Issue Date: 10/20/00

4.7.70 First Name

Entity ARM: Adjustor Master

Column Name ALFSNM

Label Name First Name

System Name

Data Type CHAR(15)

Attribute Definition

4.7.77 First Name

4.7.72 handled by adjustor code

4.7.73 handled by company identifier

4.7.74 handling for adjustor code

Confidential Enterprise Rent-A-Car © 2000 10 http.//intranet dm2/Rea(IDocOrUnJ .ASP?FoIderiD=27M<δDoe/E⁾=π5₄2 ARMS Redesign Project - Release 1.01 Issue: vl.l Assign a Request Issue Date: 10/20/00

4.7.75 handling for company identifier

4.7.76 Insurance Claim Number

4.7.77 Last Name

4.7.7S Last Name

4.7.79 loss type description

Confidential Enterprise Rent-A-Car © 2000 http://intranet/d 2/ReadDocOrLink.ASP?FoldsrID=270 &DocID=115 2 690

ARMS Redesign Project - Release 1.01 Issue: vl.l Assign a Request Issue Date: 10/20/00

4.7.27 Renters Day Phone Extension

4.7.22 Renters Night Phone

4.7.23 Renters Night Phone Extensin

4.7.24 State

4.7.25 Zip Code

Confidential Enterprise Rent-A-Car © 2000 12 http://intranet/dm2/ReadDocOr ink.ASP?FolderID-2704&DocID=115₄2 O 02/067175

691

ARMS Redesign Project - Release 1.01 Issue: vl .l Assign a Request Issue Date: 10/20/00

Questions and Answers

Issue Number: 345

Question: Do we force the user to view the Rental Detail in order to change the unassigned adjuster to an adjuster who is authorized to handle?

Status: Closed - Resolved

Resolution: 4-12-00, Randy Haselhorst, we don't want to force them to look at the detail to assign a rental request to another user. They primarily look for claim number, claim type, renter name and possibly date of loss. If you can make the option you've described intuitive, that may work, but it doesn't sound that way to me.

4-12-00, Kim DeVallance, NO - This is a great feature, but I don't know if it is necessary. Some companies use this feature, while others wait for the phone call to authorize.

Issue Number: 346

Question: Should you be allowed to decline, authorize or extend an unassigned rental.

Status: Closed - Resolved

Resolution: 4-12-00, Randy Haselhorst - you can't "extend" until you've authorized. Decline could be an option, but we should probably think about that more to determine if we should. Current state does not have this but I have heard people ask for it. As far as authorizing, that again may be a good idea. I'd like to see Kim and Dave's ideas.

4-12-00, Kim DeVallance - Yes, we have heard this many, many times that will assigning a rental, the user should have the ability to do all these things (as long as the user has the proper authority)

Confidential Enterprise Rent-A-Car © 2000 13 lιtψ:/intt_net ta2^βa--DocOrLtnfc.ASP?FolderID=27(M&DocID=I15 2 692

ARMS Redesign Project - Release 1.01 Issue: vl.l Assign a Request Issue Date: 10/20/00

Issue Number: 361

Question: Can we pass along an unassigned to another office?

Status: Pending

Resolution: Yes, If the request is an unassigned status, the USER can transfer it to another office.

Issue Number: 378

Question: Can we Exit the use case after Sending a Message and leave the request unassigned? Iteration 2 quesiton.

Status: Closed - Resolved

Resolution: 6-23-00 Per Brian Weingart, - yes, after sending a message on an unassigned request, if we didn't assign an adjuster, it is still unassigned.

Issue Number: 413

Question: 6-23-00, Only one person can handle un-assigns - which is set up in the profile? Or can a multiple # of people handle the un-assigns? Does the Handling for drop down box allow for the selection of unassigned? How do we handle record locking? Per Jennifer, Sean is working on this issue.

Status: Pending

Resolution:

Confidential Enterprise Rent-A-Car © 2000 14 http://mt etfclm2/Rea-Do-OrUnk ASP?FoMerlI ='270 --Do-tD= 11 S 2 ARMS Redesign Project - Release 1.01 Issue: vl.l Assign a Request Issue Date: 10/20/00

Issue Number: 414

Question: 6-23-00, If I select Unassigned from the action item list and only one exists do I go straight to the detail? Per Jennifer - Sean is working on this issue

Status: Pending

Resolution:

Issue Number: 415

Question: 6-23-00, If I select Unassigned from the action item list and multiple exists I go straight to the detail. I go to a screen, which looks like action items, but list all of the unassigned. Per Jennifer - Sean is working on this issue.

Status: Pending

Resolution:

Confidential Enteφrise Rent-A-Car © 2000 15 http-7/intraιιet/dιn2/ eadDocθr inl-,ASP?FolderID=₂70₄&DocID=115 2 Enterprise Rent-A-Car

Functional Design Specification Authorize a Request

Version 1.1

Last Saved: 10/16/00 10:26 AM

0

695

Issue: vl.l

Functional Design Specification Issue Date: 10/20/00

Revision Histor

Confidential Enterprise Rent-A-Car © 2000 ttp://ιntranel dm2 eadDocθrLiιιk.ASP7FolderID=27⁽M&DocID=U 85 , „ _B O 02/067175

696

Issue: vl.l

Functional Design Specification Issue Date: 10/20/00

Table of Contents

1. Authorize Request Use Case

1.1 Brief Description

1.2 Use Case Actors

1.3 Pre-Conditions

1.4 Flow of Events

1.4.1 Activity Diagram 2

1.4.2 Basic Flow ³

1.4.3 Alternative Flows 3

1.5 Post-Conditions 3

1.6 Special Requirements 3 1.6.1 Requirements for Claim Type Authorizations 3

1.7 Extension Points 5

1.7.1 MA-04 Send A Message 5

1.7.2 MA-16 Transfer Work 5

1.7.3 MA-08 View Car Class 5

1.7.4 MA- 17 Cancel Authorization 5

2. Screen Design 6

2.1 Authorize Rental Detail 6

2.1.1 Screen Layout - Authorize Rental Detail 6

2.1.2 Authorize Rental Detail 7

2.1.3 Screen Function Definition 8

3. Application Operations 10

Data Fields 11

4.1 Data Field Definition 11

4.1.1 Add Date 11

4.1.2 Address Line 11

4.1.3 Address Line 11

4.1.4 Address Line2 11

4.1.5 Bill To % 11

4.1.6 Branch 12

4.1.7 City 12

4.1.8 City 12

4.1.9 City 12

4.1.10 claim type code 12

4.1.11 claim type description 13

4.1.12 company identifier 13

4.1.13 Date Of Loss 13

4.1.14 Day Phone 13

4.1.15 Dollars Per Day Covered 13

4.1.16 external organization abbreviated name 14

4.1.17 external organization identifier 14

4.1.18 First Name 14

4.1.19 First Name 14

4.1.20 First Name 15

4.1.21 Group 15

4.1.22 Insurance Claim Number 15

4.1.23 Last Name 15

Confidential Enterprise Rent-A-Car © 2000 ii http://intranel m2/ReadDocOrUnk.ASF?FolderID=270 &DocID=n₄85 Issue: vl.l

Functional Design Specification Issue Date: 10/20/00

4.1.24 Last Name 15

4.1.25 Last Name 16

4.1.26 loss type code 16

4.1.27 loss type description 16

4.1.28 Max $ Covered 16

4.1.29 NOTE 16

4.1.30 Number Of Days Authorized 17

4.1.31 Rental Location 17

4.1.32 renter email 17

4.1.33 Renter Make/Model 17

4.1.34 Renter Vehicle Year 17

4.1.35 Renters Day Phone Extension 18

4.1.36 Renters Night Phone 18

4.1.37 Renters Night Phone Extensin 18

4.1.38 Repair Facility Name 18

4.1.39 Start Date 18

4.1.40 State 18

4.1.41 State 19

4.1.42 State 19

4.1.43 Status Description 19

4.1.44 Telephone Number 19

4.1.45 Telephone Number 19

4.1.46 Vehicle Class 20

4.1.47 Vehicle Rate 20

4.1.48 Zip Code 20

4.1.49 Zip Code 21

5. Questions and Answers 22

Confidential Enteφrise Rent-A-Car © 2000 http://intranet/dm2 eadDooOr ink.ASP?FolderII 270 &DocID=U 85 Issue: vl.l

Functional Design Specification Issue Date: 10/20/00

Authorize a Request

1. Authorize Request Use Case

1.1 Brief Description

This use case describes how a USER authorizes a direct bill request.

1.2 Use Case Actors

The following actors will interact with this use case:

• ADJUSTER - The USER will use this system to authorize a direct bill request.

1.3 Pre-Conditions

• The USER must be logged into the ARMS Web system.

• The USER must have the authority to authorize a request.

• At least one outstanding unauthorized direct bill request must be assigned that the USER may handle.

• The USER must have selected an Unauthorized Direct Bill Request from the Review Action Items Screen or from the Search Results page.

1.4 Flow of Events

The Flow of Events will include the necessary steps to make changes and updates to "Authorize Request"

Confidential Enteφrise Rent-A-Car © 2000 httpΛintranet dm2 ReadDocOrLin .ASP?FolderlD=270₄&DoclD=ll₄85 Issue: vl.l

Functional Design Specification Issue Date: 10/20/00

1.4.1 Activity Diagram

Authorize A Request Activity Diagram

Confidential Enterprise Rent-A-Car © 2000 http://iπtπιnet dm2 eadDocθr ink.ASP?FoIderID=270 iS-DocID=ll₄85 Issue: vl.l

Functional Design Specification Issue Date: 10/20/00

1.4.2 Basic Flow

1. The USER selects an outstanding direct bill to authorize.

2. The system displays the Customer file.

3. The USER reviews the renter's information.

4. The USER inputs a number of Authorized Amounts, days and required fields.

5. The USER submits the Authorization.

6. The system validates information in the Customer File.

7. If the adjuster assigned to the Customer File is 'UNKNOWN' or 'UNASSIGNED', the System will assign the Customer File to the current USER.

8. The system will update the ARMS/Web database with the Authorization.

9. The System reads the user profile to see if the confirmation page should display.

10. If the profile indicates 'Show Confirmation Page', the System will display the confirmation page

11. This ends the use case.

14.3 Alternative Flows

1.4.3.1 View Notebook

At step 3 of the Basic Flow, the USER can select to view the transaction history (Notebook) by selecting the Go To Notebook link.

1.4.3.2 Add Notes to Customer File

At step 3 of the Basic Flow, the USER can add notes to the Customer File by typing in the appropriate notes field on the Customer File page.

1.4.3.3 Skip Customer File

At step 3 of the Basic Flow, the USER should have the ability to skip to the next action item by clicking the Skip button. After clicking the Skip button, the USER should be taken to the next action item on their current list without any changes to the file being skipped.

1.4.3.4 Change Customer File

At step 3 of the Basic Flow, the adjuster can make changes to the additional details of the Customer File. This is done by selecting the Add / Change link which will invoke an editable page with all *appropriate information editable.

1.5 Post-Conditions

• If the use case was successful then the changes should go in to effect immediately and the screen should revert back to the original screen of entry.

• If the use case was successful, then the ARMS system will be notified of authorization changes.

• If the use case was unsuccessful then the system state will be unchanged.

1.6 Special Requirements

1.6.1 Requirements for Claim Type Authorizations

The following are a set of requirements surrounding the type of authorized amounts that are allowable based on the Claim Type associated with a rental. These restrictions DO NOT APPLY to reservations that are submitted with a Direct Billing Percentage of zero (0).

1.6.1.1 When the Claim Type selected is 'Insured', Theft', or 'Uninsured Motorisf

1.6.1.1.1 The reservation/rental must always include an Authorized Rate or both Policy Daily and Maximum Limits as defined by the renter's insurance policy. Zero (0) is an acceptable Policy Daily Limit.

1.6.1.1.2 The reservation/rental must include an Authorized Rate or Policy Daily Limit if a Policy Maximum Limit is included. Zero (0) is an acceptable Policy Daily Limit.

Confidential Enteφrise Rent-A-Car © 2000 http://intranet dm2 ReadDo-OrLmlc.ASP?FoIderID=₂704&DαcID=l ] 85 Issue: vl.l

Functional Design Specification Issue Date: 10/20/00

1.6.1.2 When the Claim Type selected is 'Claimant'

1.6.1.2.1 The reservation/rental must always include an Authorized Rate.

1.6.1.2.2 The reservation/rental may not include a Policy Daily/Maximum Limits selection.

1.6.1.3 Requirements for editable fields based on reservation I ticket status

1.6.1.3.1 Depending on the status of the Customer File the adjuster may change the following fields:

If the Customer File is an Unauthorized Reservation, the adjuster can Reject the Authorization Request, Send a Message, and/or Transfer (Assign) the file to an adjuster.

Confidential Enterprise Rent-A-Car © 2000 http:/fintranet/dm2/ReadDo-OrLink. ASP?FolderID=2704&DocID=l 1485 Issue: vl.l

Functional Design Specification Issue Date: 10/20/00

1.6.1.3.2 If the status of the Customer File is an open ticket the following rules apply:

1.7 Extension Points

An extension point indicates a link between this use case and another use case. Extension points associated with the use case are indicated below. Clicking on the extension point will open the related use case.

1.7.1 MA-04 Send A Message

The Send Message will be used to allow the user to capture messages and diary notes associated with a rental reservation/authorization. The USER can elect to either have the message sent to the Enterprise rental branch location responsible for the reservation/authorization, or to store the note in the ARMS Web system without sending the message to Enterprise. All MESSAGES and DIARY NOTES captured must be related to a specific reservation authorization.

1.7.2 MA-16 Transfer Work

(The Change Adjuster button invokes this use case).

The ADJUSTER may choose to transfer an authorization to a different adjuster in his/her office or transfer the authorization to another adjuster in a different office.

1.7.3 MA-08 View Car Class

The ADJUSTER may choose to view the car class. This button invokes the View Car Class use case.

17.4 MA-17 Cancel Authorization

The ADJUSTER may choose to deny the authorization. When the ADJUSTER selects the CANCEL button, it will invoke the Cancel Authorization use case to reject the authorizatio

Confidential Enterprise Rent-A-Car © 2000 http://intranet/d 2/ReadDocOrLink.ASP?FolderID=2704&DocID-11485 Issue: vl.l

Functional Design Specification Issue Date: 10/20/00

2. Screen Design

A definition of the screen layouts), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Authorize Rental Detail

This screen will allow the user to work the currently selected authorization request. The user may set the authorization amounts and policy coverage limits or may assign the request to another adjuster.

2.1.1 Screen Layout -Authorize Rental Detail ilcome to the

Automated Rental Management System

Claims Ctffica: 001 Handling for. yourself

Hanks, Tom Home: <773)ΞS4-G054

1735 N. Paulina St. Work: 7 3)395-Θ20O

Chicago. IL. eOB22 Email: dbo"Λ»ϊβ(g22Θfer. com Requested email confirmation Authorized Class: Standard Enterprise Ront_^A-Car Location; Days/Rate: 5 days @ $21 .95/day Enterprise E gewaiβr Branch Current Class: Compact 54DD N. Ashland Adcϋtlomsil Charges: None Chicago. IL 6DB22 Direct BUI %: None 773-334-S4O0 Rental Dale: 03/2SOTOD Start Dotes 03 20 aOOO

Claim Number 7ΩS&43322-OD1 Repair Facility:

Claim Type: Theft EIco Chevrolet

Insured ame Lalumanc-ier. Craig Chicago. IL ©OS21

Owner's vehicle: ©MC Suburban 1399 <773)334-9θ32

Da e of Lass: Q3/2S 2DOO

Loss Type: Non-Drivable

Policy: Dally rate/

Maximum dollars: 30 6Q0

Message , Belanger, Huguβs, 2 20Λ3O

Note from Enterprise . Sarussi. Marty , 2 21/DO

Exte sion βquβ*t_r 3 24/OQ

Extension . 2 25/DO

** top of page

Confidential Enteφrise Rent-A-Car © 2000 httρ //mtπme /dt⁽ϊ2/Reaaϊ ocOrLiπk.ASP?FolderII>=270 &DocII lH85 Issue: l.l

Functional Design Specification Issue Date: 10/20/00

2.1.2 Authorize Rental Detail

Confidential Enterprise Rent-A-Car © 2000 http://intranet'dm2/ReadD<>cOrLink.ASP?FolderID=270 &DooID=Il 85 Issue: vl .l

Functional Design Specification Issue Date: 10/20/00

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be perfoπned within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.1.3.1 Skip

When clicked, the USER will be taken out of the use case without changing the current status of the request. Any changes made by clicking Change or Add and keying data in the bottom section will be saved.

2.7.3.2 Process

When clicked, the system will validate the input and accept the changes made to the customer file. The arms database will be updated and the data will be sent to the arms system. The use case will then end and the USER will return to the process from which they came.

2.13.3 Notebook

When clicked, the USER will be taken to the Note Book section at the bottom of the screen to view all messages for this rental.

2.1.3.4 Transfer File

When clicked, the USER will be taken to the Transfer File screen. This screen allows the USER to change the office or adjuster currently assigned to the customer file. The required information in the Extend Rental/Customer File will be passed to the Transfer File screen. Upon completion of the transfer, the USER will then be returned to the next action item or the profiled start page, depending on the screen from which the USER began.

Confidential Enteφrise Reπf-A-Car © 2000 http://intranet dm-/ReadDocOrLink.ASP?FolderID=2704&DocID=n g5 Issue: vl.l

Functional Design Specification Issue Date: 10/20/00

2.7.3.5 Change or Add

When clicked, the system will refresh the current screen and make all editable fields in the bottom section (outside the gray box area) input capable. The changes on the top of the screen will not be lost.

2.1.3.6 Top of page

When clicked, the USER will be taken to the top of the current page.

2.7.3.7 View Car Class

When clicked, the USER will be taken to the View Car Class Use Case. No changes will be lost. Once the USER is finished with this use case, the USER will return to the Extend Rental Use Case.

Confidential Enteφrise Rent-A-Car © 2000 http://intranet/dm2 eadDocOrLink.ASP?FolderID=270 &DoclD=π 85 Issue: vl.l

Functional Design Specification Issue Date: 10/20/00

3. Application Operations

Confidential Enterprise Rent-A-Car © 2000 10 http://intranet/dm2/ReadDocOrUnk.ASP?FolderID=270 &DocID=ll 8S Issue: vl.l

Functional Design Specification Issue Date: 10/20/00

4. Data Fields

4.1 Data Field Definition

This section includes a definition of all data fields included in the functional specification

4.7.7 Add Date

4.7.2 Address Line

4.1.3 Address Line

4.7.4 Address Line2

4.7.5 Bill To %

Confidential Enterprise Rent-A-Car © 2000 http://intranet'dnι2 ReadDocOr ink.ASP?Fo)(!erID=270 --DoolD=l 1485 Issue: vl .l

Functional Design Specification Issue Date: 10/20/00

System Name

Data Type DECIMAL(3)

Attribute Definition

4.7.7 City

4.7.8 City

4.7.9 City

4.1.10 claim type code

Confidential Enterprise Rent-A-Car © 2000 12 httpΛinttanet/di-₂/ReadDooθrLink.ASP?FolderII =27⁽M&DooID=ll₄85 Issue: vl.l

Functional Design Specification Issue Date: 10/20/00

Attribute Definition The claim type code defines the different Authorization claim types. For example: Insured, Claimant, Uninsured Motorist, etc.

4.7.72 company identifier

4.7.73 Date Of Loss

Entity ARM: Renter Detail

Column Name RKLSDT

Label Name Date Of Loss

System Name

Data Type NUMERIC(8)

Attribute Definition

4.7.74 Day Phone

| Entity ARM: Renter Detail

Column Name RKDYPH

Label Name Day Phone

System Name

Data Type NUMERIC(IO)

Attribute Definition

4.7. 5 Dollars Per Day Covered

Entity ARM: Authorization(Claim Info)

Column Name AZ$PDY

Confidential Enterprise Rent-A-Car © 2000 13 http://intr-net/dm2 ReadDocOr ink.ASP?FolderID=2704--DocII =ll 85 Issue: vl.l

Functional Design Specification Issue Date: 10/20/00

Label Name Dollars Per Day Covered

System Name

Data Type DECIMAL(5,2)

Attribute Definition

4.7. 6 external organization abbreviated name

4.7.77 external organization identifier

4.7.78 First Name

4.1.19 First Name

Confidential Enterprise Rent-A-Car © 2000 14 http://intranetdm2/ReadDocOr ink.ASP?FolderII =2704&DoctD=lH85 Issue: vl.l

Functional Design Specification Issue Date: 10/20/00

4.7.27 Group

4.7.22 Insurance Claim Number

4.7.23 Last Name

4.7.24 Last Name

Confidential Enteφrise Rent-A-Car © 2000 http://intranetdni2/Rea(-OocOrLinl-ASP?FolderID=270 &DocID=ll₄85 Issue: vl.l

Functional Design Specification Issue Date: 10/20/00

4.7.27 loss type d escription

4.7.28 Max $ Co vered

Entity ARM: Authorization(Claim Info)

Column Name AZ$MAX

Label Name Max $ Covered

System Name

Data Type DECIMAL(9,2)

Attribute Definition

4.7.29 NOTE

Entity ARM: ARMS/400 Diary Notes File

Column Name NENOTE

Label Name NOTE

System Name

Data Type CHAR(50)

Confidential Enteφrise Rent-A-Car © 2000 16 httpJ/intranet/dm2/ eadDocOrLink. ASP?FolderID=270₄&DoclD= 11485 Issue: vl.l

Functional Design Specification Issue Date: 10/20/00

Attribute Definition

4.7.30 Number Of Days Authorized

Entity ARM: Authorization(ClaimInfo)

Column Name AZAUDY

Label Name Number Of Days Authorized

System Name

Data Type DECIMAL(3)

Attribute Definition

4.7.37 Rental Location

4:7.32 renter email

4.7.33 Renter Make/Model

4.1.34 Renter Vehicle Year

Confidential Enteφrise Rent-A-Car © 2000 17 http://intr-netd 2 ReadDocOr ink.ASP?FolderlD=270₄&DocIl ll₄85 Issue: vl.l

Functional Design Specification Issue Date: 10/20/00

4. .35 Renters Day Phone Extension

Entity ARM: Renter Detail

Column Name RKDYEX

Label Name Renters Day Phone Extension

System Name

Data Type NUMERIC(4)

Attribute Definition

4.7.36 Renters Night Phone

Entity ARM: Renter Detail

Column Name RKNTPH

Label Name Renters Night Phone

System Name

Data Type NUMERIC(IO)

Attribute Definition

4.7.37 Renters Night Phone Extensin

4.7.38 Repair Facility Name

4.7.39 Start Date

4.7.40 State

Entity | ARM: Rental Location Master

Confidential Enteφrise Rent-A-Car © 2000 http://intraιιet/dnι2 ReadDocθr ink.ASP?FolderID=270 &DocID=π₄85 Issue: vl.l

Functional Design Specification Issue Date: 10/20/00

4.7.47 State

4.7.42 State

4.7.43 Status Description

4.7.44 Telephone Number

Entity ARM: Rental Location Master

Column Name LOPHNO

Label Name Telephone Number

System Name

Data Type NUMERIC(IO)

Attribute Definition

4.7.45 Telephone Number

Entity ARM: Repair Detail

Column Name RUPHNO

Label Name Telephone Number

Confidential Enteφrise Rent-A-Car © 2000 19 http://intranet/dm2 ReadDocOr tnk.ASF?FoIderID=2704&DocID=11485 Issue: vl.l

Functional Design Specification Issue Date: 10/20/00

System Name

Data Type NUMERIC(IO)

Attribute Definition

4.7.46 Vehicle Class

4.7.47 Vehicle Rate

4.7.48 Zip Code

Confidential Enteφrise Rent-A-Car © 2000 20 http://intranBtdm2/ReadDocOrLink.ASP?Fo!derII>=270₄-.DoeID=ll₄85 Issue vl 1

Functional Design Specification Issue Date 10/20/00

4.7.49 Zip Code

Confidential Enteφnse Rent-A-Car © 2000 21 http //ιntranet dm2 ReadDocOrLιnk.ASP''Folderro=2704&DooID=l HgS Issue: vl.l

Functional Design Specification Issue Date: 10/20/00

Questions and Answers

Issue Number: 419

Question: 6-23-00, When rejecting an authorization do we want a reason code? Per Jennifer - Mike, Brad and Craig is handling this.

Status: Pending

Resolution: 07-03-00 - Brad Reel: In the ARMS Web V2.0 application reason codes will be collected for the following events: reject invoice, terminate authorization. Per a discussion with Randy Haselhorst, it would be worthwhile to collect a reason code for for reject/cancel authorization. However, it is not critical for this release. If possible it should be incorporated. 07-03-00 - Brad Reel: I am reassigning to Mike Slater to work with Neil Fitzgerald and determine whether or not to incoφorate in V2.0, or wait until a later release.

Confidential Enteφrise Rent-A-Car © 2000 22 fattp://infranefdm2/ReadDocOrLink.ASP?FolderID=2704&DocID=11485 Enterprise Rent-A-Car

Functional Design Specification Change Customer File

Version 1.1

Last Saved: 10/17/00 2:23 PM

Issue: vl.l

Change Customer File Issue Date: 10/20/00

Revision History

Date Issue Description Author

April 20, 2000 0.1 Created Use Case and Screen Design Brian Weingart, Debi Ealick and Johnny Sands

April 28, 2000 0.1 Added Use Case and Screen Design as Cindy Bastean subdocuments

May 3, 2000 0.2 Removed subdocuments and formatted Cindy Bastean according to standards. Reconciled Screen Design

May 3, 2000 0.3 Added changes from Team Final Review Cindy Bastean

May 5,2000 0.4 Made screen changes and added to Debi Ealick document.

May 16, 2000 0.5 Made Use Case and Activity Diagram Brian Weingart modifications as per Cross-Team Review session

May 25, 2000 0.6 Added Questions and Answers Cindy Bastean

May 25, 2000 0.6 Updated Screens and Screen Fields Debi Ealick, Cindy Bastean

July 3, 2000 0.7 Updated Screen Field and Data Field Cindy Bastean Information

July 13, 2000 0.7 Updated Use Case and Screen Design Mike Slater, Brian sections Weingart, Johnny Sands, Deb Ealick, Brent Armbruster and Cindy Bastean

August 24, 2000 1.0 Updated Use Case. Changes made based Mike Slater on feedback provided by management reviewers.

October 2, 2000 1.1 Updated FDS. Changes made based on Mike Slater feedback provided by the testing team.

Confidential Enterprise Rent-A-Car © 2000 httpΛintr--iet/dm2/Rea(iDocOr mk.ASP?FolderII 2704&DocID=115 ₄ Issue: vl.l

Change Customer File Issue Date: 10/20/00

Table of Contents

I . Change Customer File Use Case

1.1 Brief Description

1.2 Use Case Actors

1.3 Pre-Conditions

1.4 Flow of Events 1.4.1 Activity Diagram 2

1.4.1 3

1.4.2 Basic Flow 3

1.4.3 Alternative Flows 3

1.5 Post-Conditions 3

1.6 Special Requirements 3

1.7 Extension Points 5

1.7.1 MA-04 Send a Message 5

1.7.2 MA- 16 Reassign USER or Office (The Transfer File button invokes this use case). 5

1.7.3 MA- 15 Terminate a Rental (Set Last Day) 5

1.7.4 MA-17 Cancel Authorization 5

1.7.5 MA-08 View Car Class 5

2. Screen Design 6

2.1 Change Rental Detail 6

2.1.1 Screen Layout - Change Rental Detail (After clicking the Change or Add link) 6

2.1.2 Change Rental Detail 8

2.1.3 Screen Function Definition 9

3. Application Operations 11

4. Data Fields 12

4.1 Data Field Definition 12

4.1.1 Add Date 12

4.1.2 Address Line 12

4.1.3 Address Line 12

4.1.4 Address Line2 12

4.1.5 Branch 12

4.1.6 City 13

4.1.7 City 13

4.1.8 City 13

4.1.9 claim type code 13

4.1.10 claim type description 13

4.1.11 company identifier 14

4.1.12 Date Of Loss 14

4.1.13 Day Phone 14

4.1.14 external organization abbreviated name 14

4.1.15 external organization identifier 14

4.1.16 First Name 15

4.1.17 First Name 15

4.1.18 First Name 15

4.1.19 Group 15

4.1.20 Insurance Claim Number 15

4.1.21 Last Name 16

4.1.22 Last Name 16

Confidential Enterprise Rent-A-Car © 2000 ii http://intranet dm2 ReadDocOrLink.ASP?FolderID-270₄&D∞ID=115₄ Issue: vl.l

Change Customer File Issue Date: 10/20/00

4.1.23 Last Name 16

4.1.24 loss type code 16

4.1.25 loss type description 16

4.1.26 message ecars indicator 17

4.1.27 NOTE 17

4.1.28 Number Of Days Authorized 17

4.1.29 Rate Charged 17

4.1.30 Rental Location 17

4.1.31 renter email 18

4.1.32 Renter Make/Model 18

4.1.33 Renter Vehicle Year 18

4.1.34 Renters Day Phone Extension 18

4.1.35 Renters Night Phone 18

4.1.36 Renters Night Phone Extensin 19

4.1.37 Repair Facility Name 19

4.1.38 standard message description 19

4.1.39 Start Date 19

4.1.40 State 19

4.1.41 State 20

4.1.42 State 20

4.1.43 Status Description 20

4.1.44 Telephone Number 20

4.1.45 Telephone Number 20

4.1.46 Vehicle Class 21

4.1.47 Vehicle Rate 21

4.1.48 Zip Code 21

4.1.49 Zip Code 21

4.1.50 Zip Code 21

Questions and Answers

22

Confidential Enterprise Rent-A-Car © 2000 hHp:Mntranefdra2/ReadDocOrLink.ASP?FolderII =270₄&DQcID=1154 Issue: vl.l

Change Customer File Issue Date: 10/20/00

Change Customer File

1. Change Customer File Use Case

1.1 Brief Description

The Change Authorization use case describes how the USER could change an authorization assigned to a reservation or an open rental.

1.2 Use Case Actors

The following actors will interact with this use case:

• ADJUSTER - The USER will use this case to add or change information related to an existing Customer File on a rental within ARMS Web.

1.3 Pre-Conditions

• The USER must be logged into the ARMS Web system.

• The USER must have selected to change an existing Customer File.

1.4 Flow of Events

The Flow of Events will include the necessary steps to make changes to a Customer File.

Confidential Enterprise Rent-A-Car © 2000 http://intranet dm2/ReadDocOrLink.ASP?FolderID=270 &DocID=115 ₄ Issue: vl.l

Change Customer File Issue Date: 10/20/00

1.4.1 Activity Diagram

Confidential Enteφrise Rent-A-Car © 2000 http://intr-net dm2/ReadDocOr ink.ASP?FolderlD=270₄&DocID=115₄₄ Issue: vl.l

Change Customer File _^_ Issue Date: 10/20/00

14.2 Basic Flow

1. The USER will select a Customer File to change.

2. The SYSTEM will display the associated Customer File detail of the selected item.

3. The USER will add additional or modify existing information associated with the Customer File.

4. The SYSTEM will validate added or modified data.

5. The SYSTEM will update ARMS Web to reflect the changes.

6. The SYSTEM notifies ARMS of the changes associated with the Customer File.

7. The SYSTEM checks the profile for the confirmation screen setting.

8. This ends the use case.

1.4.3 Alternative Flows

1.4.3.1 View Rental Notebook

At step 1, the USER may choose to view the history of a rental. The USER will be able to see the last five diary notes. The USER can also select to view the transaction history or add diary notes from the Extend Rental Detail.

1.4.3.2 Validate Changes

If the USER changes or adds information, which does not pass validation, an error message will notify the USER and return them to step 1 of the Basic Flow.

If an error is discovered in the validation of the reservation / rental information submitted by the USER (Step 3 of the Basic Flow), the system would present the USER with an error message and return them to the Detailed Reservation / Rental Display. If the error is specific to a data field within the form, the field should be highlighted and the error described.

1.4.3.3 Display Confirmation

After step 6, the USER may wish to have a confirmation page displayed, indicating that some type of change has taken place. The confirmation page is completely optional, therefore, at anytime the USER wants to set their profile to bypass this screen, he/she may do so.

1.4.3.4 Update USER Profile

During the confirmation process, the USER has the option of changing their profile setting to display or hide the confirmation page. Each time the setting is changed, the USER profile must be updated to reflect the new requirements set by the USER.

1.5 Post-Conditions

• If the use case was successful then the changes have been saved to the ARMS Web database and if appropriate, ARMS Web has generated notification transactions to ARMS.

• If the use case was unsuccessful then the system has remained unchanged.

1.6 Special Requirements

It will be considered invalid if for a reservation, the Claim Number, Renter First Name, Renter Last Name, Claim Type, Vehicle Condition, Rental Location, Authorized Number of Days, Direct Bill Percent, and at least one Renter Telephone number have not been included.

It will be considered invalid if the customer has established Claim Number editing and the Claim Number format does not meet the requirements of the customer's Claim Number definition.

Confidential Enterprise Rent-A-Car © 2000 http://intanet/dm2 ReadDocOrLink.ASP?FolderlD=270₄&Docπ>=1154 Issue: vl.l

Change Customer File Issue Date: 10/20/00

It will be considered invalid if any field identified as REQUIRED in the company/office profile is not included.

It will be considered invalid if any data entered violates the data type as specified by the ARMS Web database (i.e., alpha characters in a numeric field).

A warning will be presented to the USER if any defined limits identified in the company/office/user profile are exceeded (e.g., Maximum Number of Days Authorized). The system will allow the USER to submit the authorization from the warning.

It will be considered invalid if the selected Claim Type is 'Insured,' 'Uninsured,' or 'Theft' and the reservation does not include an Authorized Rate or does not include both Policy Daily and Policy Maximum Limits (with the exception of reservations with a Direct Bill Percent of zero (0)). A Policy Daily Limit of zero (0) is an acceptable entry.

It will be considered invalid if the selected Claim Type is 'Insured,' 'Uninsured,' or 'Theft' and the reservation includes a Policy Maximum Limit but does not include an Authorized Rate or Policy Daily Limit (with the exception of reservations with a Direct Bill Percent of zero (0)). A Policy Daily Limit of zero (0) is an acceptable entry.

It will be considered invalid if the selected Claim Type is 'Claimant' and Policy Limits (Daily or Maximum) have been included.

It will be considered invalid if the Authorized Number of Days is included and is less than zero (0).

It will be considered invalid if the Direct Bill Percent is greater than zero (0) and the Authorized Number of Days is zero.

It will be considered invalid if the Direct Bill Percent is less than zero (0).

It will be considered invalid if the Direct Bill Percent is greater than one hundred (100).

It will be considered invalid if the Labor Hours are less than zero (0).

It will be considered invalid if the Date of Loss is greater than the current date.

It will be considered invalid if the first three digits (i.e., area code) of any U.S. or Canadian telephone number meet the criteria below:

• 0XX

• 1XX

• The second and third digits equal (e.g., 800, 877, 888, etc.) Where X equals any digit 0 through 9.

It will be considered invalid if a U.S. or Canadian telephone number does not consist of 10 digits.

It will be considered invalid if a U.S. postal code does not consist of 5 or 9 digits.

^> It will be considered invalid if a Canadian postal code does not consist of 6 alphanumeric characters in the format AXAXAX where A is an alpha character and X is a digit between 0 and 9.

Confidential Enterprise Rent-A-Car © 2000 httpJ/intranet dm2 ReadDocOrLink.ASP?FolderID=270 &DocID=115 ₄ Issue: vl.l

Change Customer File Issue Date: 10/20/00

• It will be considered invalid if an E-mail address is included that does not include an '@' character.

• It will be considered invalid if the Send e-mail Confirmation to Renter flag is set to true and the Renter e-mail address is not included.

• If the customer file is in reservation status, the screen will show a cancel button for the USER to cancel the authorization if desired.

• If the customer file is in open ticket status, the screen will show the set last day button for the USER to terminate the rental if desired.

1.7 Extension Points

1.7.1 MA-04 Send a Message

The Send Message will be used to allow the USER to capture messages and diary notes associated with extending a rental. The USER can elect to either have the message sent to the Enterprise rental branch location responsible for the reservation/authorization, or to store the note in the ARMS Web system without sending the message to Enterprise. All MESSAGES and DIARY NOTES captured must be related to a specific reservation/authorization File.

17.2 MA-16 Reassign USER or Office (The Transfer File button invokes this use case).

After the extend rental detail is displayed, the USER may choose to change the current office/USER. First, the USER would select to change the current office/USER, Second, the system would display a list of authorized offices/users. Third, the USER would select a new office/USER.

17.3 MA-15 Terminate a Rental (Set Last Day)

After the extend rental detail is displayed, the USER may choose to terminate the rental. If termination is selected, the USER must enter a reason for the termination of the rental. Termination means the insurance company is no longer willing to pay for the rental. This function (button) is only available for an open ticket. For reservation status, the USER should see the Cancel button.

1.7.4 MA- 17 Cancel Authorization

Before step 5 of the Basic Flow, the USER should have the capability to cancel the authorization. Before the USER has made changes that have been updated in the database and sent to ARMS, the Cancel Authorization function (button) should be available for reservation status. However, the USER cannot perform the Cancel function on an open ticket. For an open ticket, the Termination (Set Last Day) function (button) is available.

1.7.5 MA-08 View Car Class

The View Car Class use case will be used to allow the USER to view details about and select a car class to apply to a reservation. Details will include the average number of passengers and luggage items that can be served by a vehicle in the specific car class. The car class selected by the USER should be applied to the reservation.

Confidential Enteφrise Rent-A-Car © 2000 http://intr-net/dm2«eadDocOrLink ASF'FolderID=270₄&D(K:ID=115 Issue: vl.l

Change Customer File Issue Date: 10/20/00

Screen Design

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Change Rental Detail

This screen will allow the USER to work the currently selected authorization request. The USER may set the authorization amounts and policy coverage limits or may assign the request to another adjuster.

2.1.1 Screen Layout- Change Rental Detail (After clicking the Change or Add link)

IC anqe or Add]

Last: I Hanks First: Tom [Home jg 1(773)5646054 j _Eχt: [

Address: 11735 NL Paulina St__ ~ j| IWor jg 1(773)395-6200 I Exf

City ( Chicago State: fu~ _f Zip: f aEzT Email: j thanks@zefer.com

Enterprise Rcπt-A-Car Location: 17 Requested email confirmation

Enterprise Edgewater Branch 54D0 N Ashland Chicago, IL 60622 773334-5400

Insured Name. Last: j Lalumandjer _r . First: |Craιg Repair Facility: Owner's vehicle JGMC Suburban 1999' jJΞIco Chevrolet J

Data of Loss |jANj_ [ΪTJ| [iooog j|j City: [ Chicago j Vehicle Condition I Non-D livable III State: [ IL Ij'Zip.J EOSΩ

Confidential Enterprise Rent-A-Car © 2000 htφV/mti-iιet/dm2/Reai-DocθrLink.ASP?Fold rID==₂70 &Dc>clD=115 4 Issue vl 1

Change Customer File Issue Date 10/20/00

You just authorized 3 days at S29.39/day for Hanks. Tom Customer File; for Bowie, Davitl Claim no 765849322-001

2 of 4 Action Items

REMTEB INFORMATION- Bowie, David Home (773)56 -6054 1735 N Paulina St Work (773)395 B200 Chicago, I L 60622 Email dbowιe@zefer com Requested email confirmation

RENTAL INFORI-1ΛTION:

Authorized Class: Standard Enterprise Rent-A Car Location: Days/Rate- 5 days @ $21 99/day Enterprise Edgewater Branch Current Class: Full-Size 5400 N Ashland Additional Charges: None Chicago, IL 60622 Direct Bill %: None 773-334-5400 Rental Date: 03/28/2000 Start Date: 03/20/2000

ADDITIONAL Ct-A.ΛΛ

Claim Number: 32323232323232323 Repair Facility:

Claim Type: Theft Elco Chevrolet

Insured Name: Lalumandier, Craig Chicago IL 60621

Owner's vehicle: GMC Suburban 1999 (773)334-9832

Date of Loss. 03 2B/2000

Loss Type' Non-Dnvable

Policy: Daily rate/

Maximum dollars: 30/600

IMOTEBOOK

Message, Belanger Hugues, 2/20/00

Note from Enterprise Sarussi, Marty. 2/21/00

Extension Request 2/24/00

Extension 2/25/00

O top of page

Cont^jo Us I τ,ι sa Conditions \ Log Off

Confidential Enterpπse Rent-A-Car © 2000 http //ratran-tdπ-t Rea Do-OrLiok. ASP'>FoldeιID=2704&DocID=l ISM Issue: vl.l

Change Customer File Issue Date: 10/20/00

2.1.2 Change Rental Detail

Confidential Enterprise Rent-A-Car © 2000 http://intranet/dιn2 ReadDocOrLm .ASP?FolderID=270₄&DocII =π5 Issue: vl.l

Change Customer File Issue Date: 10/20/00

Screen Label ield Name ield Name Screen Speci

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.1.3.1 Skip

When clicked, the USER will be taken out of the use case without changing the current status of the request. Any changes made by clicking Change or Add and keying data in the bottom section will be saved.

2.1.3.2 Process

When clicked, the system will validate the input and accept the changes made to the customer file. The arms web database will be updated and the data will be sent to the arms system. The use case will then end and the USER will return to the process from which they came.

2.1.3.3 Notebook

When clicked, the USER will be taken to the Note Book section at the bottom of the screen to view all messages for this rental.

2.1.3.4 Set Last Day

When clicked, the system will terminate the rental. The USER will be prompted to enter a termination date for this rental. This coincides with the use case MA- 15 -Terminate Rental.

2.1.3.5 Transfer File

When clicked, the USER will be taken to the Transfer File screen. This screen allows the USER to change the office or adjuster currently assigned to the customer file. The required information in the Extend Rental/Customer File will be passed to the Transfer File screen. Upon completion of the transfer, the USER will then be returned to the next action item or the

Confidential Enteφrise Rent-A-Car © 2000 htrp://intι^et dm2/ReadDocOrLink.ASP?FolderID=270 &DocID=115 Issue: vl.l

Change Customer File Issue Date: 10/20/00 profiled start page, depending on the screen from which the USER began.

2.1.3.6 Change or Add

When clicked, the system will refresh the current screen and make all editable fields in the bottom section (outside the gray box area) input capable. The changes on the top of the screen will not be lost.

2. .3.7 Top of page

When clicked, the USER will be taken to the top of the current page.

2.1.3.8 View Car Class

When clicked, the USER will be taken to the View Car Class Use Case. No changes will be lost. Once the USER is finished with this use case, the USER will return to the Extend Rental Use Case.

2.1.3.9 Extend Rental (checkbox)

When checked and the process button is clicked, the system will validate the input and accept the extension AND any other changes made to the customer file. The arms web database will be updated and the data will be sent to the arms system. The use case will then end and the USER will proceed to the next action item. (If unchecked and the process button is clicked, only the changes to the screen will be saved. The extension will NOT be executed.)

2.1.3.10 Last Action Message

After each action item in the USER's list has been completed, upon arriving at the next item there will be a confirmation message at the top of the screen. This message will be a hyperlink describing the last completed action. If the USER clicks on this link, the system will open the customer file, which will reflect all of the current information for the rental. The USER is then free to make additional changes or to simply view the file.

Confidential Enterprise Rent-A-Car © 2000 10 http://intranet dm2/ReadDocOrLink .SP?FolderID=270 &DocID=1154₄ Issue: vl.I

Change Customer File Issue Date: 10/20/00

Application Operations

Confidential Enterprise Rent-A-Car © 2000 11 http://intranet/dm2 ReadDocOrUιιk.ASP?FolderID=270₄&DocID=π5 Issue: vl.l

Change Customer File Issue Date: 10/20/00

4. Data Fields

4.1 Data Field Definition

This section includes a definition of all data fields included in the functional specification

4.17 Add Date

Entity ARM: ARMS/400 Diary Notes File

Column Name NEADDT

Label Name Add Date

System Name

Data Type NUMERIC(8)

Attribute Definition

4.7.2 Address Line

4.1.3 Address Line

4.1.4 Address Line2

4.7.5 Branch

Confidential Enterprise Rent-A-Car © 2000 12 http://inlrane(/dm2 eadDocOr ink.ASP?FolderID=270 &DocID= 115Φ» Issue: vl.l

Change Customer File Issue Date: 10/20/00

4.7.6 City

4.7.7 City

4.7.8 City

Entity ARM: Repair Detail

Column Name RUCYNM

Label Name City

System Name

Data Type CHAR(20)

Attribute Definition

4.1.9 claim type code

4.7.70 claim type description

Confidential Enteφrise Rent-A-Car © 2000 13 http://intranet/dra₂ .eadDocOrLink.ASP?FoIderID=270 &DocID=1154₄ Issue: vl.l

Change Customer File Issue Date: 10/20/00

For example: Insured, Claimant, Uninsured Motorist, etc. j

4.7.77 company identifier

4.7.72 Date Of Loss

4.7.73 Day Phone

4. .74 external organization abbreviated name

4. . 5 external organization identifier

Confidential Enterprise Rent-A-Car © 2000 14 http://intranetdm2/ReadDocOrLink.ASP?FolderID=270 --DcicII 115 Issue: vl.l

Change Customer File Issue Date: 10/20/00

4.7.76 First Name

4.7.77 First Name

4.7.78 First Name

4.7.79 Group

4.7.20 Insurance Claim Number

Confidential Enteφrise Rent-A-Car © 2000 15 http://intranet/dm2/ReadDocθrLink.ASP?FolderID=270₄&DocID=115 ₄ Issue: vl.l

Change Customer File Issue Date: 10/20/00

Label Name Insurance Claim Number

System Name

Data Type CHAR(20)

Attribute Definition

4.7.27 Last Name

4.7.22 Last Name

4.7.23 Last Name

4.7.24 loss type code

4.7.25 loss type description

Confidential Eπteφrise Rent-A-Car © 2000 16 htrpΛintranet dπι2/ReadDc:θrLink.ASP?FolderlD=270 &Docir>'π5 ₄ Issue: vl.l

Change Customer File Issue Date: 10/20/00

4.1.26 message ecars indicator

Confidential Enteφrise Rent-A-Car © 2000 17 http://intranet dn- /ReadDocOrLink.ASP?FolderD>=270₄&DocID=U5 ₄ Issue: vl.l

Change Customer File Issue Date: 10/20/00

4.7.37 renter email

4.1.32 Renter Make/Model

4.7.33 Renter Vehicle Year

4.7.34 Renters Day Phone Extension

4.7.35 Renters Night Phone

Confidential Enteφrise Rent-A-Car © 2000 http://inB-ne-'dnι2/ReadDocOrLink.ASP?FolderID=2704&DocID=115 Issue: vl.l

Change Customer File Issue Date: 10/20/00

System Name

Data Type NUMERIC(IO)

Attribute Definition

4.7.36 Renters Night Phone Extensin

4. .37 Repair Facility Name

4.7.38 standard message description

4.1.39 Start Date

4.1.40 State

Confidential Enteφrise Rent-A-Car © 2000 19 htφ:/Λ^"ntι-Λet dιn2/RβadDocOrLink.ASP?Fo]derID-270 -.DoclD=l l5 ₄ Issue: vl.l

Change Customer File Issue Date: 10/20/00

4.7.47 State

4.7.42 State

4.7.43 Status Description

4. .44 Telephone Number

4.7.45 Telephone Number

Confidential Enteφrise Rent-A-Car © 2000 20 httpΛmtranet/dm2/ReadDocOrLink.ASP?Fold-rID=2704-.DocID=l 1544 Issue: vl.l

Change Customer File Issue Date: 10/20/00

Data Type NUMERIC(IO)

Attribute Definition

4.7.46 Vehicle Class

4.7.47 Vehicle Rate

4.7.48 Zip Code

4.7.49 Zip Code

4.7.50 Zip Code

Confidential Enteφrise Rent-A-Car © 2000 21 http://intranet dm2/ReadDocOrLink.ASP?FolderlD=270 &DoclI 1154₄ Issue: vl.l

Change Customer File Issue Date: 10/20/00

5. Questions and Answers

Issue Number: 368

Question: Can the Adjuster shorten the number of days authorized without terminating the rental.

Status: Closed - Resolved

Resolution: 5-3-00, Brian Weingart, Kim DeVallance - No. After an ticket is open and has been authorized, the only modification allowed to the number of days authorized comes in the form of a termination. For example, if an adjuster sent us ten days and on the fifth day, decided to only give us a total of six (thereby removing the authorization for four days) the adjuster would have to terminate that rental as of the sixth day.

Issue Number: 386

Question: Should the Date of Loss be editable in Change Authorization or does it depend on the state of the reservation/ticket.

Status: Closed - Resolved

Resolution: 6-23-00, Brian Weingart, - Since Date of Loss is considered Insurance company information, the adjuster owns this information. The Adjuster can change this in either an reservation or open ticket status. This is editable until the rental is considered closed.

Confidential Enteφrise Rent-A-Car © 2000 22 http://ratranet dm2/ReadDcι OrLink.ASP?FolderID=27t)4&DocID=llS 4 Enterprise Rent-A-Car

Functional Design Specification

Terminate Rental

Version 1.0

Last Saved: 10/6/00 9:16 AM

ARMS Redesign Project - Release 1.0 Issue: v 1.0 Terminate Rental Issue Date: 10/20/00

Revision History

Confidential Enterprise Rent-A-Car © 2000 httpΛintranet dm2 ReadDocOrLink-ΛSP?FolderID=2704&DoclI>-11219 ARMS Redesign Project - Release 1.0 Issue: vl.O

Terminate Rental Issue Date: 10/20/00

Table of Contents

1. Terminate Rental Use Case

1.1 Brief Description

1.2 Use Case Actors

1.3 Pre-Conditions

1.4 Flow of Events

1.4.1 Activity Diagram 2

1.4.2 Basic Flow 3

1.4.3 Alternative Flows 3

1.5 Post-Conditions 3

1.6 Special Requirements 4

1.6.1 The termination date must be greater than or equal to the current date or the last day authorized. There is a business rule that ensures that an adjuster cannot take away already used rental days. 4

1.6.2 If the USER extends an authorization that has been terminated, the termination information is considered invalid. 4

1.6.3 It is mandatory that a USER select a termination reason from the drop-down list. If the USER selects "Other" from the drop-down list, a comment about the termination must be supplied. 4

1.7 Extension Points 4

2. Screen Design 5

2.1 Terminate Rental 5

2.1.1 Screen Layout- Terminate Rental 5

2.1.2 Terminate Rental 5

2.1.3 Screen Function Definition 6

3. Application Operations 7

4. Data Fields 8

4.1 Data Field Definition 8

4.1.1 Company Id

4.1.2 external organization abbreviated name

4.1.3 external organization identifier 8

4.1.4 First Name 8

4.1.5 First Name 8

4.1.6 Insurance Claim Number 9

4.1.7 Last Name 9

4.1.8 Last Name 9

4.1.9 NOTE 9

4.1.10 renter email 9

4.1.11 Termination Date 9

Questions and Answers 11

Confidential Enterprise Rent-A-Car © 2000 httpΛ^"ntranetdra₂/ReadDocOrLinl-ASP?Foω-rIE⁾=2704«&Doc!D=11219 ARMS Redesign Project - Release 1.0 Issue: vl.O

Terminate Rental Issue Date: 10/20/00

Terminate Rental

1. Terminate Rental Use Case

1.1 Brief Description

The Terminate Rental use case describes how the USER would terminate a rental. This use case will allow the USER to inform Enteφrise of the last day that the ADJUSTER will pay for a rental. In most cases, by providing a date in the future, Enteφrise will receive an extension through the last day.

1.2 Use Case Actors

The following actors will interact with this use case:

• ADJUSTER - The USER will use this case to terminate a rental.

1.3 Pre-Conditions

• The USER must be logged into the ARMS Web system.

• The USER must have the authority to terminate an open rental.

• The USER must have selected an authorized rental.

1.4 Flow of Events

The Flow of Events will include the necessary steps to terminate a rental.

Confidential Enterprise Rent-A-Car © 2000 httpΛiιιtπ-net/dra2/ReadDo-θrUi-tASP?Folderπ>=₂70 &DocID=11219 ARMS Redesign Project - Release 1.0 Issue: vl.O Terminate Rental Issue Date: 10/20/00

1.4.1 Activity Diagram

Terminate Rental Activity Diagram

Confidential Enterprise Rent-A-Car © 2000 http /intiMet dra₂/Re.dDocθrUnl_ASP?FolderID==270 &DocII =11219 ARMS Redesign Project - Release 1.0 Issue: vl.O

Terminate Rental Issue Date: 10/20/00

1.4.2 Basic Flow

1. The USER selects to terminate an authorization.

2. The system prompts the USER for the termination information.

3. The USER enters the termination date and reason/comments.

4. The USER submits the termination information.

5. The system will validate the termination information.

6. The system updates the ARMS Web database.

7. The system reads the USER profile for the confirmation settings.

8. This ends the use case.

1.4.3 Alternative Flows

1.4.3.1 Previous

After step 3, the USER can abandon all changes, which result in the system state remaining unchanged. After clicking the "Previous" button, the USER will be returned to the screen from which they came.

1.4.3.2 Additional Comments

When terminating a rental, the USER must select a reason from the drop-down box to explain why the termination is taking place. As well, if further explanation is desired there is a comment box in which the USER may enter additional comments for more clarification. This section is optional, unless the USER selects "Other" from the reason code drop-down box. In this case, the comment box must be used.

1.4.3.3 Display Confirmation

After step 7, the USER may wish to have a confirmation page displayed, indicating that some type of change has taken place. The confirmation page is completely optional; therefore, at anytime the USER wants to set their profile to bypass this screen, he/she may do so.

1.4.3.4 Update USER Profile

During the confirmation process, the USER has the option of changing their profile setting to display or hide the confirmation page. Each time the setting is changed, the USER profile must be updated to reflect the new requirements set by the USER.

1.5 Post-Conditions

• If the use case was successful then the changes will go into effect immediately and write a transaction record to pass to ARMS indicating that there was a change on the rental. If the renter's email address was entered, a system-generated message will notify the renter.

• If the use case was unsuccessful then the system will remain unchanged.

Confidential Enterprise Rent-A-Car © 2000 httpJ/inti^et/diii2 ReadDo< Link.ASP?FolderlD=2704&DocII>=11219 ARMS Redesign Project - Release 1.0 Issue: v 1.0

Terminate Rental Issue Date: 10/20/00

1.6 Special Requirements

1.6.1 The termination date must be greater than or equal to the current date or the last day authorized. There is a business rule that ensures that an adjuster cannot take away already used rental days.

Current Date Authorization Date Termination Date

6/20 6/25 >=6/20

6/20 6/10 >=6/10

1.6.2 If the USER extends an authorization that has been terminated, the termination information is considered invalid.

1.6.3 It is mandatory that a USER select a termination reason from the drop-down list. If the USER selects "Other" from the drop-down list, a comment about the termination must be supplied.

1.7 Extension Points

None.

Confidential Enteφrise Rent-A-Car © 2000 http^/intr-net/ m2 ReadDocθrLink.ASP?FolderID=₂704&DocID=11219 ARMS Redesign Project - Release 1.0 Issue: vl.O Terminate Rental Issue Date: 10/20/00

Screen Design

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Terminate Rental

This screen will allow the user enter the information about terminating a rental.

2.1.1 Screen Layout - Terminate Rental

2.1.2 Terminate Rental

Confidential Enterprise Rent-A-Car © 2000 http*intπmet m2/ReadDocOrLink. ASP?FolderlD=2704&DocID=l 1219 ARMS Redesign Project - Release 1.0 Issue: v 1.0

Terminate Rental Issue Date: 10/20/00

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.1.3.1 Previous

Will return the user to the detail screen from which they came. The system and the information on the detail screen will remain unchanged

2.1.3.2 Process

When clicked, the system will complete the termination of the rental and notify the required parties.

2.1.3.2.1 The user must have selected a valid termination date that is greater than the current date

Confidential Enterprise Rent-A-Car © 2000 httpΛintι∞et/dιι-2 Rea Dc )ιlii- .ASP?FolderII =2704&DocID=π219 ARMS Redesign Project - Release 1.0 Issue: vl.O

Terminate Rental Issue Date: 10/20/00

Application Operations

Confidential Enterprise Rent-A-Car © 2000 httpJ^/mtranet/dm20leadDocOr ir tASP?FolderlI>=2704i-r)ocI-)=11219 ARMS Redesign Project - Release 1.0 Issue: vl.O Terminate Rental Issue Date: 10/20/00

4. Data Fields

4.1 Data Field Definition

This section includes a definition of all data fields included in the functional specification

4.1.1 Company Id

4.1.2 external organization abbreviated name

4.1.3 external organization identifier

4.1.4 First Name

4.1.5 First Name

Confidential Enterprise Rent-A-Car © 2000 httpΛintraιιet/dιn2/ eadDocθιLink.ASP?Fo]derir .₂70 -iDc<;II 11219 ARMS Redesign Project - Release 1.0 Issue: vl.O Terminate Rental Issue Date: 10/20/00

Data Type CHAR(15)

Attribute Definition

4.1.6 Insurance Claim Number

4.1.7 Last Name

4.1.8 Last Name

4.1.9 NOTE

4.1.10 renter email

4.1.11 Termination Date

Entity ARM: Authorization(Claim Info)

Column Name AZTMDT

Label Name Termination Date

Confidential Enteφrise Rent-A-Car © 2000 ttpΛintranet/dm2yReadDocθr iιιI_ASP?FoldcrlI -2704&DocID-ll219 ARMS Redesign Project - Release 1.0 Issue: vl.O Terminate Rental Issue Date: 10/20/00

Confidential Enteφrise Rent-A-Car © 2000 10 httpΛintranetfdmaReadDocOr ι-tASP?Fo!deriD=270 &DocID=π219 ARMS Redesign Project - Release 1.0 Issue: vl.O Terminate Rental Issue Date: 10/20/00

Questions and Answers

Issue Number: 373

Question: How is the renter currently notified of a termination of the rental? Are they usually notified by the time the rental is terminated? How should this be represented on the screen? Should the checkbox say to notify the renter or that the renter has already been notified?

Status: Pending

Resolution:

Confidential Enteφrise Rent-A-Car © 2000 htφΛmtr_aet/dπι2/ReadDc«θι inl-ASP?FoIderID-27() SJλ)cII 11219 Enterprise Rent-A-Car

Functional Design Specification

Transfer File

Version 0.6

DRAFT

Last Saved: 10/9/00 1:24 PM

ARMS Redesign Project - Release 1.0 Issue: vl.O Transfer File Issue Date: 10/20/00

Confidential Enteφrise Rent-A-Car © 2000 httpΛintι_ιιet dnι2/Rea(lDo θrUnk-ASP?FoIderIE)=270 &Do-II>=11221 ARMS Redesign Project - Release 1.0 Issue: v 1.0

Transfer File Issue Date: 10/20/00

Table of Contents

1. Transfer File Use Case

1.1 Brief Description

1.2 Use Case Actors

1.3 Pre-Conditions

1.4 Flow of Events

1.4.1 Activity Diagram 2

1.4.2 Basic Flow 3

1.4.3 Alternative Flows 3

1.5 Post-Conditions 3

1.6 Special Requirements 3

1.7 Extension Points 4

2. SSccrreeeenn DDeessiiggnn 5

2.1 Transfer File 5

2.1.1 Screen Layout - Transfer File 5

2.1.2 Transfer File 5

2.1.3 Screen Function Definition 6

Application Operations 7

Data Fields 8

4.1 Data Field Definition 8

4.1.1 external organization abbreviated name 8

4.1.2 external organization identifier 8

4.1.3 First Name 8

4.1.4 Last Name 8

Confidential Enteφrise Rent-A-Car © 2000 httpΛintraD^βt dm2/RradD«Λι mk.ASP?FolderlD=27()₄&DocID=11221 ARMS Redesign Project - Release 1.0 Issue: vl .0

Transfer File Issue Date: 10/20/00

Transfer File

1. Transfer File Use Case

1.1 Brief Description

The Transfer File use case describes how the user would assign one of their action items to another user/office.

1.2 Use Case Actors

The following actors will interact with this use case. Each of the actors can be defined generically as USER. The USER will use this use case to reassign action items to other USERS and/or offices.

• ADJUSTER

• PROCESSOR

1.3 Pre-Conditions

• The USER must be logged into the ARMS Web system.

• The USER must have the ability to reassign action items.

• The USER must have access to a customer file to reassign.

• The customer file must be in an open, reservation, or unauthorized state.

1.4 Flow of Events

The Flow of Events will include the necessary steps for a USER to reassign action items.

Confidential Enteφrise Rent-A-Car © 2000 htφ^rmtiMiet dπι2 eadDocθr ink-\SP?FolderlD-270₄&DoclD=l 1221 ARMS Redesign Project - Release 1.0 Issue: vl.O Transfer File Issue Date: 10/20/00

1.4.1 Activity Diagram

Reassign User/Office Activity Diagram

USER

Confidential Enterprise Rent-A-Car © 2000 http- /totιa-ιet d 2yR«dDo-OrLiιιk.ASP?FolderID=270 &DocID=11221 ARMS Redesign Project - Release 1.0 Issue: v 1.0

Transfer File Issue Date: 10/20/00

1.4.2 Basic Flow

1. The USER selects to reassign a customer file.

2. The system retrieves the list of valid offices to display.

3. The system retrieves the list of valid USERs to display based on reservation ticket status.

4. The system displays the list of adjusters for the current office and the list of other valid offices.

5. The USER selects the user that will be the new owner of the selected action item.

6. The system will update he ARMS Web database to reflect the recent ownership change and changes, if any, from the prior screen.

7. The system generates a message indicating that a transfer and any other changes have been completed.

8. The system updates the ARMS Web database and notifies ARMS with an Authorization Change transaction.

9. This ends the use case.

1.4.3 Alternative Flows

1.4.3.1 Change Office

After step 3 of the basic flow, the USER may choose to assign the action item to a new office. If the USER chooses a new office, the flow would return to step 2 of the basic flow. This should reflect possible recipients of the action item from that office.

1.4.3.2 Cancel Use Case

The USER may cancel the use case at any point prior to updating the ARMS Web Database. If the USER elects to cancel the use case, the customer file will not be transferred, however, any other changes that were made to the file will remain.

7.4.3.3 Display Confinnation

After step 7, the USER may wish to have a confirmation page displayed, indicating that some type of change has taken place. The confirmation page is completely optional, therefore, at anytime the USER wants to set their profile to bypass this screen, he/she may do so.

1.4.3.4 Update USER Profile

During the confirmation process, the USER has the option of changing their profile setting to display or hide the confirmation page. Each time the setting is changed, the USER profile must be updated to reflect the new requirements set by the USER.

1.5 Post-Conditions

• If the use case was successful then the changes should go in to effect immediately and the new owner should be able to view the newly assigned action item.

• If the use case was unsuccessful then the system will remain unchanged.

1.6 Special Requirements

• When building the list of valid USERS, the system will determine the status of the reservation / ticket and retrieve all users in the current office with authority to process that status of a reservation / ticket.

• When building the list of valid Offices, the system will retrieve all other offices defined within ARMS Web as valid offices for the specified company.

• When selecting an office for the reassign operation, the system must rebuild the user list so the USER will only see valid users that are able to complete the action item to be transferred.

• After the changes have been submitted, the next Action Item will populate indicating that a transfer has been completed, if the USER started from the Action Item List

Confidential Enteφrise Rent-A-Car © 2000 httpΛmti-met/dnι2 RradDocChrUnk.ASP?Fo!dBrID=270 &DocII 11221 ARMS Redesign Project - Release 1.0 Issue: vl.O

Transfer File Issue Date: 10/20/00

• After the changes have been submitted, the USER will return to the profiled start page with a message indicating that a transfer has been completed, if the USER arrived at the customer file via^" the search option.

1.7 Extension Points

None

Confidential Enteφrise Rent-A-Car © 2000 http://intranet/dπι2/ReadIλ c<⁾r ink-ASP?FolderID=270 --DocI-⁾=π221 ARMS Redesign Project - Release 1.0 Issue: vl.O Transfer File Issue Date: 10/20/00

2. Screen Design

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Transfer File

This screen will allow the user to pick which functions that they may want to change.

2.1.1 Screen Layout - Transfer File

2.1.2 Transfer File

Confidential Enterprise Rent-A-Car © 2000 http*intr_net/dm2 Rea(πλ)cθrLinlcASP?FoWerlD-270 &DocID= 11221 ARMS Redesign Project - Release 1.0 Issue: vl.O

Transfer File Issue Date: 10/20/00

2.1.3 Screen Function Definition

2.1.3.1 Cancel

When clicked, the USER will be returned to the screen/use case where they were prior to selecting Change Office/ Adjuster (Transfer). Any changes made will be lost and the system will remain unchanged.

2.1.3.2 Process

When clicked, the changes made will be validated. If the validation passes, the update will be sent to the ARMS system and the USER will be returned to the screen/use case from which they came. If the validation fails, the USER will be returned to the current screen with error message(s) and the field in error highlighted

Confidential Enterprise Rent-A-Car© 2000 htφ://intranet dm2yReadl>wOr ink.ASP?FolderID-270 --DocID=11221 ARMS Redesign Project - Release 1.0 Issue: vl 0

Transfer File Issue Date: 10/20/00

Application Operations

Confidential Enteφrise Rent-A-Car © 2000 ttpΛintra-Btfm2/Read^]> θrLin-ASP?FoIderII =270&Docπ=11221 ARMS Redesign Project - Release 1.0 Issue: vl.O Transfer File Issue Date: 10/20/00

4. Data Fields

4.1 Data Field Definition

This section includes a definition of all data fields included in the functional specification

4.1.1 external organization abbreviated name

4.1.2 external organization identifier

4.1.3 First Name

4.1.4 Last Name

Confidential Enteφrise Rent-A-Car © 2000 httpJ/intranet dm2 ReadDooOrUnk-ΛSP?Folderπ 2704&DocID-π221 Enterprise Rent-A-Car

Functional Design Specification Cancel Authorization

Version 1.0

Last Saved: 10/9/00 3:34 PM

ARMS Redesign Project - Release 1.0 Issue: vl.O Cancel Authorization Issue Date: 10/20/00

Revision History

Confidential Enteφrise Rent-A-Car © ₂000 httpΛmtranet 2 eadDocθrUn .ASP'Folderπ =₂704&DocID=U-₂2 ARMS Redesign Project - Release 1.0 Issue: vl.O

Cancel Au_thorization Issue Date: 10/20/00

Table of Contents

1. Cancel Authorization Use Case

1.1 Brief Description

1.2 Use Case Actors

1.3 Pre-Conditions

1.4 Flow of Events

1.4.1 Activity Diagram 2

1.4.2 Basic Flow 3

1.4.3 Alternative Flows 3

1.5 Post-Conditions 3

1.6 Special Requirements 3

1.7 Extension Points 3

2. Screen Design 4

2.1 Cancel Direct Bill Authorization 4

2.1.1 Screen Layout - Cancel Direct Bill Authorization 4

2.1.2 Cancel Direct Bill Authorization 4

2.1.3 Screen Function Definition 5

3. Application Operations 6

4. D Daattaa FFiieellddss 7

4.1 Data Field Definition 7

4.1.1 Cancel Date 7

4.1.2 Cancellation Code 7

4.1.3 external organization abbreviated name 7

4.1.4 First Name 7

4.1.5 Insurance Claim Number 7

4.1.6 Last Name 8

4.1.7 NOTE 8

4.1.8 Rental Location 8

Questions and Answers 9

Confidential Enterprise Rent-A-Car © 2000 http://intiOTet/dm2/RβadDocOrLin .ASP?FoW-rII>=2704&Do<:π>=11222 ARMS Redesign Project - Release 1.0 Issue: v 1.0

Cancel Authorization Issue Date: 10/20/00

Cancel Authorization

1. Cancel Authorization Use Case

1.1 Brief Description

This use case will describe how a USER would cancel an authorized reservation.

1.2 Use Case Actors

The following actors will interact with this use case:

• ADJUSTER - The USER will be able to perform the duties of canceling an authorized reservation.

1.3 Pre-Conditions

• The USER must be logged into the ARMS Web system.

• The USER must have the ability to cancel an authorization.

• The USER has selected an authorized reservation and wants to cancel the authorization within ARMS Web.

1.4 Flow of Events

The Flow of Events will include the necessary steps to "Cancel Authorization".

Confidential Enterprise Rent-A-Car © 2000 htφΛintranet dm2/ eadDocθr ink SP?FoIderll =270₄&DocID=11222 ARMS Redesign Project - Release 1.0 Issue: vl.O Cancel Authorization Issue Date: 10/20/00

1.4.1 Activity Diagram

Cancel Authorization Activity Diagram

Confidential Enterprise Rent-A-Car © 2000 httpJ/inhOTet/dm2 R⁽»dD«:Or iιJ-ASP?FolderII 270 &DoclI 11222 ARMS Redesign Project - Release 1.0 Issue: vl .0

Cancel Au_thorization Issue Date: 10/20/00

1.4.2 Basic Flow

1. The USER selects to cancel the authorization.

2. The system will prompt the user for a reason for cancellation.

3. The USER will select a reason.

4. The USER will submit the cancellation.

5. The system will update the ARMS Web database to reflect that the USER cancelled the Authorization.

6. The system will read the USER profile for the confirmation settings.

7. This ends the use case.

1.4.3 Alternative Flows

1.4.3.1 Previous

After step 3, the USER can abandon all changes, which result in the system state remaining unchanged. After clicking the "Previous" button, the USER will be returned to the screen from which they came.

1.4.3.2 Additional Comments

When canceling a rental, the USER must select a reason from the drop-down box to explain why the cancellation is taking place. As well, if further explanation is desired, there is a comment box in which the USER may enter additional comments for more clarification. This section is optional, unless the USER selects "Other" from the reason code drop-down box. In this case, the comment box must be used.

1.4.3.3 Display Confirmation

After step 6, the USER may wish to have a confirmation page displayed, indicating that some type of change has taken place. The confirmation page is completely optional, therefore, at anytime the USER wants to set their profile to bypass this screen, he/she may do so.

14.3.4 Update USER Profile

During the confirmation process, the USER has the option of changing their profile setting to display or hide the confirmation page. Each time the setting is changed, the USER profile must be updated to reflect the new requirements set by the USER.

1.5 Post-Conditions

• If the use case was successful then the changes should go in to effect immediately and generate a transaction record to pass to ARMS indicating that the authorized reservation was cancelled.

• If the use case was unsuccessful then the system will remain unchanged.

1.6 Special Requirements

• When canceling an authorization, the USER must select a reason from the drop-down list. If the USER chooses "Other" from the pre-defined list, a comment about why the authorization was cancelled must be supplied.

1.7 Extension Points

None

Confidential Enterprise Rent-A-Car © 2000 http^/btranetdra2«eadDocOrLinl_ASP?FoIderII>=27()4&DoclI)=π222 ARMS Redesign Project - Release 1.0 Issue: vl.O Cancel Authorization Issue Date: 10/20/00

2. Screen Design

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Cancel Direct Bill Authorization

This screen will allow the user to pick which functions that he/she may want to change.

2.1.1 Screen Layout- Cancel Direct Bill Authorization

2.1.2 Cancel Direct Bill Authorization

Screen Lab Si c Screen Fie Data Field Name

Confidential Enterprise Rent-A-Car © 2000 http^/intran.tfdm₂/ReadI^Or i_tASP?Folder-D=270 &DoclD=n₂22 ARMS Redesign Project - Release 1.0 Issue: vl.O

Cancel Authorization Issue Date: 10/20/00

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.1.3.1 Previous

When clicked, the user will be returned to the screen/use case where they were prior to selecting Cancel Reservation. Any changes made will be lost and the system will remain unchanged.

2.1.3.2 Process

When clicked, system will update the message file with the comment record if entered and mark the current reservation authorization as cancel. The cancellation and the new message, if entered, will be forwarded to the ARMS system. The system returns the USER to the appropriate Action Items List screen.

Confidential Enterprise Rent-A-Car © 2000 httρ*intraιιet/<ira2 ReadI>⁾cθri.iιιk.ASP?Fo^]derlI =270₄&DocII 11222 ARMS Redesign Project - Release 1.0 Issue: vl.O

Cancel Authorization Issue Date: 10/20/00

Application Operations

Confidential Enterprise Rent-A-Car © 2000 hrφΛintraιιet/dDώ«eadI>x Unk.ASP?FolieιlJ -27()4&Dc<:II>=II-22 ARMS Redesign Project - Release 1.0 Issue: vl .0 Cancel Authorization Issue Date: 10/20/00

4. Data Fields

4.1 Data Field Definition

This section includes a definition of all data fields included in the functional specification

4.1.1 Cancel Date

4.12 Cancellation Code

4.1.3 external organization abbreviated name

4.1.4 First Name

4.1.5 Insurance Claim Number

Confidential Enterprise Rent-A-Car © 2000 htψ^/intranet/d 2mCTdDocOrLinl_ASP?FolderlD=2704&DocID=11222 ARMS Redesign Project - Release 1.0 Issue: vl.O Cancel Authorization Issue Date: 10/20/00

4.1.6 Last Name

4.17 NOTE

4.1.8 Rental Location

Confidential Enterprise Rent-A-Car © 2000 httpΛintr_neydm2«eadDocOrLink.ASP?FolderII 270₄&DodD=n222 ARMS Redesign Project - Release 1.0 Cancel Authorization Issue Date: 10/20/00

Questions and Answers

Issue Number: 418

Question: Do we need a reason to cancel - have cancel page.

Status: Closed - Resolved

Resolution: 6-23-00, Per Neil, kill this page, it's not necessary.

Confidential Enterprise Rent-A-Car © 2000 h^ttp: ^/mlranet;dπα/Re- DocOrLirfcΛSP?FoldeτII 27C4&D«:lI ll- 2 Enterprise Rent-A-Car

Functional Design Specification View Customer File

Version 1.0

Last Saved: 10/3/00 2:05 PM

ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

Revision History

Confidential Enteφrise Rent-A-Car © ₂000 hrrp/inimetdra2ReadDocr nk.ASI^FolderII)=270 &DocID=11223 ARMS Redesign Project - Release 1.0 j_ssue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

Table of Contents

1. Search and View Customer File

1.1 Brief Description

1.2 Use Case Actors

1.3 Pre-Conditions

1.4 Flow of Events

1.4.1 Activity Diagram 2

1.4.2 Basic Flow 4

1.4.3 Alternative Flows 4

1.5 Post-Conditions 4

1.6 Special Requirements 4

1.7 Extension Points 5

2. SSccrreeeenn DDeessiiggnn 6

2.1 Find a Customer (tab) 6

2.1.1 Find a Customer (tab) 6

2.1.2 Customer (tab) 7

2.1.3 Screen Function Definition 7

2.2 Customer File - Closed Items 7

2.2.1 Screen Layout - Customer File - Closed Items 7

2.2.2 Customer File - Closed Items 9

2.2.3 Screen Function Definition 11

2.3 Search Results 11

2.3.1 Screen Layout — Search Results 11

2.3.2 Search Results 13

2.3.3 Screen Function Definition 13

3. Application Operations 14

Data Fields 15

4.1 Data Field Definition 15

4.1.1 Add Date 15

4.1.2 Address Line 15

4.1.3 Address Line 15

4.1.4 Address Line2 15

4.1.5 Bill To % 15

4.1.6 Bill to End Date 16

4.1.7 Bill to Start Date 16

4.1.8 Branch 16

4.1.9 City 16

4.1.10 City 16

4.1.11 City 16

4.1.12 claim type code 17

4.1.13 claim type description 17

4.1.14 company identifier 17

4.1.15 Date Of Loss 17

4.1.16 Day Phone 17

4.1.17 Days authorized-detail 18

Confidential Enterprise Rent-A-Car © 2000 http://intranet dm2 ReadDocOr iιιk.ASP?FoIderID==270 &E>ocID=11223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

4.1.18 Dollars Per Day Covered 18

4.1.19 End Date 18

4.1.20 external organization identifier 18

4.1.21 Federal ID Number 18

4.1.22 First Name 19

4.1.23 First Name 19

4.1.24 First Name 19

4.1.25 Group 19

4.1.26 Insurance Claim Number 19

4.1.27 Invoice Number 19

4.1.28 LAST AUT DAY 20

4.1.29 Last Name 20

4.1.30 Last Name 20

4.1.31 Last Name 20

4.1.32 loss type code 20

4.1.33 loss type description 21

4.1.34 Max $ Covered 21

4.1.35 message ecars indicator 21

4.1.36 NOTE 21

4.1.37 Number Of Days Authorized 21

4.1.38 Rate Charged 21

4.1.39 Record Add Date 22

4.1.40 Rental Location 22

4.1.41 renter email 22

4.1.42 Renter Make/Model 22

4.1.43 Renter Vehicle Year 22

4.1.44 Renters Day Phone Extension 23

4.1.45 Renters Night Phone 23

4.1.46 Renters Night Phone Extensin 23

4.1.47 Repair Facility Name 23

4.1.48 standard message description 23

4.1.49 Start Date 23

4.1.50 State 24

4.1.51 State 24

4.1.52 State 24

4.1.53 Status Description 24

4.1.54 Telephone Number 24

4.1.55 Telephone Number 25

4.1.56 Total Amount Due 25

4.1.57 Total Amount Received 25

4.1.58 Total Ticket Charges 25

4.1.59 Transmission Code 25

4.1.60 Vehicle Class 25

4.1.61 Vehicle Rate 26

4.1.62 Zip Code 26

4.1.63 Zip Code 26

4.1.64 Zip Code 26

Confidential Enteφrise Rent-A-Car © ₂000 bttpΛintraιιet d 2/ReadDocOrLtok.ASP?Fo]derID=270 &DocID=11223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

View Customer File

1. Search and View Customer File

1.1 Brief Description

This use case describes the process that a USER would use to find and view information regarding a rental. In order to view the rental detail, one of two general conditions must be satisfied:

1) The rental is open and the USER does not have any authority to make changes

2) The rental is in a state that no longer allows changes to be made.

If these conditions are not met, the USER will be taken to the appropriate use case.

1.2 Use Case Actors

All actors will use the use case to View Rental Detail in the ARMS Web system. All of the following actors can be defined generically as a USER:

• ADJUSTER

• PROCESSOR

• COMPANY MANAGER

• ENTERPRISE ADMINISTRATOR

• COMPANY ADMINISTRATOR

1.3 Pre-Conditions

• The USER must be signed-on to the system (AND)

• The USER does not have the authority to make changes and the ticket is open, (OR)

• The ticket is in a state that doesn't allow changes to be made.

1.4 Flow of Events

The Flow of Events includes all the steps necessary to View Rental Detail in the ARMS Web system.

Confidential Enteφrise Rent-A-Car © 2000 http://intranet/dnι2/Re3dI⁾ocOrLiιιk.ASP?FolderID=2704&DocID=lI2-3 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

1.4.1 Activity Diagram

Confidential Enterprise Rent-A-Car © 2000 httpΛintraaιet/dm2/Rea(aλ)cOrUnkASP?Fo]derID=2704&DocID=11223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

View Customer File Activity Diagram

Confidential Enterprise Rent-A-Car © 2000 http^/mtr-net dm2/RcadDo< >LinkΛSP?Fo!derrD=270 &-)ocir =11223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

1.4.2 Basic Flow

The Basic Flow of the View Rental Detail use case includes all of the required activities for the USER to successfully find and view information regarding an open rental.

1. The USER initiates a search for a Customer File.

2. The system, based on criteria entered by the USER, retrieves the matches for that search.

3. The system displays the search results.

4. The USER selects one of the matches.

5. The system displays the detail of the Customer File.

6. This ends this use case.

1.4.3 Alternative Flows

1.4.3.1 Search Again

After step 3 of the basic flow, the USER may decide that they would like to conduct another search. By entering new search criteria, they would return to step 2 with new criteria and the use case could continue.

1.4.3.2 Only One Match Found

At step 2 of the basic flow, if the system only finds one match, the system will advance to step 5 of the basic flow invoking the appropriate use case for modifications.

14.3.3 View Only

If the Customer File selected was in a state not allowing changes, the system would display the Customer File, however, not allowing the USER to modify any information within ARMS Web.

1.5 Post-Conditions

• If the use case is successful, the system will return to its previous state.

• If the use case is unsuccessful, the use case the system will remain unchanged.

1.6 Special Requirements

To successfully locate a customer file, the following criteria must be satisfied:

1. The following fields will limit the search results: Adjuster Name, Last Authorized Day, Date of Loss, and/or a status of the Customer File. a. If a Renter Last Name has been supplied, an exact match on last name is considered valid b. If a Renter Last Name and Renter First Name has been supplied and there is no exact match on Renter Last Name, there is no match. c. If a Renter Last Name and Renter First Name has been supplied and there is an exact match on Renter Last Name and not an exact match on Renter First Name, the Renter Last Name with the closest Renter First Name is considered a match.

Confidential Enterprise Rent-A-Car © 2000 http /iπtranet/dm2ΛleadDocOrLmk.ASP?Folderπ>=2704&D κ;π>=ll223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00 d. If a Renter Last Name and Claim Number has been supplied and there is an exact match on Renter Last Name and not on Claim Number, the closest match on Renter Last Name and the closest match on Claim Number greater than the Claim Number provided is considered a match.

2. If the USER supplies one or more of the following fields, the above result set will position to closest match of Customer Files based on: Renter Last Name, Renter First Name, and/or Claim Number.

3. This search capability will include all available Open and Closed Rentals for searching.

4. Any empty fields signify the search should not limit the result set by that field.

5. Any Customer File present in the result set will contain a link to the appropriate use case based on the current status of the reservation or rental.

1.7 Extension Points

1.7.1.1 MA-10 Authorized a Request

If the customer file were an unauthorized reservation or ticket, the system would enter the Authorization use case to allow the USER to authorize this Customer File.

1.7.1.2 MA-12 Extend Rental

If the customer file were an authorized ticket or an action item of extension status, the system would enter the Extend Rental use case to allow the USER to extend this Customer File.

1.7.1.3 MA-13 Change Authorization

If the customer file were an authorized reservation or ticket not requiring any immediate action, the system would enter the Change Authorization use case to allow the USER to authorize this Customer File.

1.7.1.4 MA-07 Additional Charges

The Additional Charges use case will be used to add special charges to the reservation being created by the USER (e.g., CDW). Any Additional Charges captured should be returned and applied to the reservation. The existence of Additional Charges should be reflected on the reservation screen.

1.7.1.5 MA-08 View Car Class

The View Car Class use case will be used to allow the USER to view details about and select a car class to apply to a reservation. Details will include the average number of passengers and luggage items that can be served by a vehicle in the specific car class. The car class selected by the USER should be applied to the reservation.

1.7.1.6 Invoicing - BI-01 -Handle Unapproved Invoices & BI-02-Pay Approved Invoices & BI-03 Reject an Invoice

At step 5, the USER may elect to view approved invoices, unapproved invoices, or rejected invoices. Upon completion of this process, the USER should be returned back to step 5 of the Basic Flow.

Confidential Enterprise Rent-A-Car © 2000 http^ intπmet dm2 ReadDocOrLink.ASP?FolderID=2704&E)ocπ =l 1223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

Screen Design

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Find a Customer (tab)

This screen will allow the USER to view the rental.

2.1.1 Find a Customer (tab)

Contact Us | Terms & Conditions I Log Off

Confidential Enterprise Rent-A-Car © ₂000 httpΛ^'nlι^e-'dm2 ReadDocOιLink VSP?FoIderID=2704&D-<:ID=l I223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

2.1.2 Customer (tab)

Data Held Name Screen Specific Rule

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.1.3.1 Search

When clicked, the will search for any records that match the criteria listed.

2.2 Customer File - Closed Items

This screen will allow the USER to view the rental when closed.

2.2.1 Screen Layout - Customer File - Closed Items

Confidential Enterprise Rent-A-Car © ₂000 httpΛintιmιet/dm2/ReadDocOr ink.ASP?FolderID=27(⁾ &DocID=11223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

Welcome to the

Automated Rental Management System

E _≤ggSSΘ! 1W«-MM«M-J

Claims Office: 001 Handlinβ for Yours e-F

Custom f, Bo ie, Da«id Claim No. 323232323232

**e■ I-r F '->i tΛle -3*:c

Go to Invoirn

RENTEf. INFORMATION:

Bowie, David Home: (773) EBA-BOSΔ 1735 N. Paulina St. Work: (773) 395-6200 Chicago, IL60S22 Email: dbowie@zefer. com Renter Type: Claimant Requested email confirmation

RENTAL !MFθr-.ΛAA.-riQr_:

Authorized Rental: Authorized Class: Standard Enterprise Rent-A-Car Location: Days/Rate: 3 days @ $21.99/day Enterprise Edgewater Branch Current Class: Full-Size 5400 N. Ashland Chicago, IL 60622

Rental Date: 03/28/2000 773-334-5400 Start Date: 03 302000

CLAIM INfORMATlON:

Claim Number: 323232323232323 Insured Name: Lalumandier, Craig Repair Facility: Owner's vehicle: GWC Suburban 1999 Elco Chevrolet Date of Loss: 03 28 2000 Chicago, IL60S21 Vehicle Condition: Non-Drivablo (773)334-3832

NOTEBOOK:

Invoice Paid: 536.13 on 6/20/00

Message. Belanger. Hughes, 2/20 D0

Note from Enterprise. Sarussi, Marty. 2/21/00

Extension Request .2/24/00

Extension, 2/25/00

© top of page

Invoicing: I D Print Rental History too [Use the "Print" button from your browser after clicking tha "Printer-Friendly Version" button.]

RENTAL: INVOICE:

Enterprise Rent-A-Car Location: Reference: PPGM D073GΘ2

6850 Ladue Rd. InvoiCB Date: 02/10/00

Saint Louis. M0631240001 Federal ID: 4800791635

(314)512-0294

Authorized CLAIM:

Authorized Period: 02 10Λ» to Q3/01ΛO (20 days) Renter. Weber, Andrew

Days 20 Claim Number 5693754821

Rate 22.99 Claim Type: Claimant

Vehicle Condition: Non-Driveable

Direct Bill Percent 100% Date of Loss: 0205ΛX)

Total authorized: 459.8 Plus Tax S Surcharge Insured Name: Smith, Bob

Actual Rental

Rental Period: 02 10 00 to 03*1 Λ0 (20 days) Billed Period: 02 iO ∞ to 03Λ31/DO (20 days) Actual Days:

20@ $22.99/day = $505.78

Direct Bill Percent 100%

Sates Tax (3%) = $30.35

Total Charges: $535.13

Amount Received: $0.00

Total Due: $538.13

O top of page

Contact Us I TtrπaA Cor>-t-ora I Loo Off

Confidential Enterprise Rent-A-Car © 2000 http:/intπuιet dπι2 ReadE)ocOrLink-ASP?FolderlL =2704&t)ocID=11223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error-

Reference source not found.

View Customer File Issue Date: 10/20/00

2.2.2 Customer File - Closed Items

Confidential Enterprise Rent-A-Car © 2000 http://ιntranet/dm2/ReadDocOrLink ASP?FolderH>=2704&DocID=11223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00 en Label Si/.e Screen Field Name Data Field Nam ^•

Confidential Enterprise Rent-A-Car © 2000 10 htψ://intι™et/dm2 ReadDMθr ink.ASP?FoldMπ)-270 &I)ocII>-l 1223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

2.2.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.2.3.1 Previous

When clicked, the USER will be taken back to the use case from where they came

2.2.3.2 Printer Friendly Version

When clicked, the system will bring up a screen that only shows the particular invoice for which you clicked this button. The USER may print from this screen

2.2.3.3 Top of page

When clicked, the USER will be taken to the top of the current page.

2.3 Search Results

This screen will allow the USER to view the rental when closed.

2.3.1 Screen Layout - Search Results

Confidential Enterprise Rent-A-Car © 2000 11 http://intr_ιι.t dm2/ReadDocOrLink.ASP?FoIderII>-2704&DocID-11223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

Automated Rental Management Systβi.

create a rin

RESERVATION CUSTOMER w

Claims Office- [001 _J Handling for JYourself

There was more than one possible match for the items you searched for. Please choose from the results below or Search Again

Confidential Enterprise Rent-A-Car © 2000 12 http //intranet dm2 eadI κOrLin ΛSP?FoIderir)=270 &tloclD=l 1223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

2.3.2 Search Results

2.3.3 Screen Function Definition

This section includes the definitions for all fimctions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity

2.3.3.1 Search Again

When clicked, the system will re-search the database after the USER has entered new or additional criteria.

2.3.3.2 Top of page

When clicked, the USER will be taken to the top of the current page.

Confidential Enteφrise Rent-A-Car © 2000 13 http- /intra-ietydm2 ReadIλx Unk_ASP?FolderD ₂70 &Dc<;lD=H₂23 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File ^' . Issue Date: 10/20/00

2.3.3.3 View Next 10>»

When clicked, the system will display the next 10 items that match the search criteria

3. Application Operations

Confidential Enteφrise Rent-A-Car © 2000 14 htfp:/Λntrai)er drn2 Rea DocθrLinl-ASP?FolderID=270 &DocII =l I223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

4. Data Fields

4.1 Data Field Definition

This section includes a definition of all data fields included in the functional specification

4.1.1 Add Date

Entity ARM: ARMS/400 Diary Notes File

Column Name NEADDT

Label Name Add Date

System Name

Data Type NUMERIC(8)

Attribute Definition

4.1.2 Address Line

Entity ARM: Rental Location Master

Column Name LOADL1

Label Name

System Name

Data Type CHAR(30)

Attribute Definition

4.1.3 Address Line

Entity ARM: Renter Detail

Column Name RKADL1

Label Name Address Line

System Name

Data Type CHAR(30)

Attribute Definition

4.1.4 Address Line2

Entity ARM: Rental Location Master

Column Name LOADL2

Label Name Address Line

System Name

Data Type CHAR(30)

Attribute Definition

4.15 Bill To %

Entity ARM: Authorization(Claim Info)

Column Name AZBTPC

Label Name Bill To %

System Name

Data Type DECIMALS)

Attribute Definition

Confidential Enteφrise Rent-A-Car © 2000 15 http^/intr-net/dm2 ReadDocθrl.inkΛSP?FoIderID=₂70 &DocID=n₂₂3 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

4.16 Bill to End Date

Entity A4 Invoice Header

Column Name I1BTDT

Label Name Bill to End Date

System Name

Data Type NUMERIC(8)

Attribute Definition

4.17 Bill to Start Date

Entity A4 Invoice Header

Column Name I1SRDT

Label Name Bill to Start Date

System Name

Data Type NUMERIC(8)

Attribute Definition

4.1.8 Branch

Entity ARM: Rental Location Master

Column Name Branch

Label Name Branch:

System Name

Data Type CHAR(2)

Attribute Definition

4.19 City

Entity ARM: Rental Location Master

Column Name LOCYNM

Label Name City

System Name

Data Type CHAR(20)

Attribute Definition

4.1.10 City

Entity ARM: Renter Detail

Column Name RKCYNM

Label Name City

System Name

Data Type CHAR(20)

Attribute Definition

4.1.11 City

Entity ARM: Repair Detail

Column Name RUCYNM

Label Name City

System Name

Data Type CHAR(20)

Confidential Enteφrise Rent-A-Car © 2000 16 http://intranct (ta2 ReadDocθrLink.ASP?FolderID=270 &DocID=l 1223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

Attribute Definition

4.1.12 claim type code

4.173 claim type descript ion

Entity CLAIM TYPE

Column Name clm_typ_dsc

Label Name claim type description:

System Name CLMTYPDSC

Data Type CHAR(40)

Attribute Definition The claim type description is a lexical definition of the claim type code which defines the different Authorization claim types. For example: Insured, Claimant, Uninsured Motorist, etc.

4.174 company identifier

Entity EXTERNAL ORGANIZATION

Column Name cmpy_id

Label Name company identifier:

System Name CMPYID

Data Type DEC(11,0)

Attribute Definition Business Party Identifier is a surrogate key assigned to each unique occurrence of an Individual, External Organization, and Internal Organization (Business Party).

4.175 Date Of Loss

Entity ARM: Renter Detail

Column Name RKLSDT

Label Name Date Of Loss

System Name

Data Type NUMERIC(8)

Attribute Definition

4.176 Day Phone

Entity ARM: Renter Detail

Column Name RKDYPH

Label Name Day Phone

System Name

Data Type NUMERIC(IO)

Attribute Definition

Confidential Enteφrise Rent-A-Car © 2000 17 httpΛintr-net dmΣ ReadDocOr inkΛSPΫFoIderlD-ΣVlM&Doc-D"] 1223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

4.7. 7 Days authorized-detail

4.7.78 Dollars Per Day Covered

4.7.79 End Date

4.1.20 external organization identifier

4.7.27 Federal ID Number

Confidential Enteφrise Rent-A-Car © 2000 IS http:/ intτanet (ta2/ReadDc ;θrLink-ASP?FolderII =27(M&DocID=l]223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

4.7.22 First Name

4.7.23 First Name

4.7.24 First Name

Entity ARM: Renter Detail

Column Name RKFSNM

Label Name First Name

System Name

Data Type CHAR(15)

Attribute Definition

4.7.25 Group

4.7.26 Insurance Claim Number

4.7.27 Invoice Number

Entity A4 Invoice Header

Column Name I1INNO

Label Name Invoice Number

System Name

Data Type CHAR(20)

Confidential Enteφrise Rent-A-Car © 2000 19 http^/intranet drπ2/ReadDocθrLinkΛSP?FoIderII>=₂70 &DocID=11223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

Attribute Definition

4.7.28 LAST AUT DAY

Entity A4 Cross Reference

Column Name X4LADT

Label Name LAST AUT DAY

System Name

Data Type NUMERIC(8)

Attribute Definition

4.7.29 Last Name

4.7.30 Last Name

4.7.37 Last Name

Entity ARM: Renter Detail

Column Name RKLSNM

Label Name Last Name

System Name

Data Type CHAR(20)

Attribute Definition

4.7.32 loss type code

Confidential Enteφrise Rent-A-Car © 2000 20 http^Λntr_ner/dm2 ReadDocθrLink.ASP?FolderID=2704&DocID=l 1223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

4.1.33 loss type description

4.7.34 Max $ Covered

4.7.35 message ecars indicator

4.7.36 NOTE

4.7.37 Number Of Days Authorized

4.7.38 Rate Charged

Entity ARM: Authonzatιon(Claιm Info)

Confidential Enteφrise Rent-A-Car © 2000 21 htrp://intraJier dm2 ReadDocθr ink VSP?FolderID=270 &DocID=11223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

Column Name AZRTCH

Label Name Rate Charged

System Name

Data Type DECIMAL(5,2)

Attribute Definition

4.7.39 Record Add Date

Entity A4 Invoice Header

Column Name I1ADDT

Label Name Record Add Date

System Name

Data Type NUMERIC(8)

Attribute Definition

4.7.40 Rental Location

Entity ARM: Authorization(Claim Info)

Column Name AZRNLC

Label Name Rental Location

System Name

Data Type CHAR(10)

Attribute Definition

4.7.47 renter email

Entity RENTER EXTENSION

Column Name rentr emi

Label Name renter email:

System Name RENTREML

Data Type CHAR(70)

Attribute Definition The email address of the renter.

4.7.42 Renter Make/Model

4.7.43 Renter Vehicle Year

Entity ARM: Renter Detail

Column Name RKVHYR

Label Name Renter Vehicle Year

System Name

Data Type NUMERIC(4)

Attribute Definition

Confidential Enteφrise Rent-A-Car © 2000 22 http://inlranet dm2 ReadDocOr ink.ASP?FolderID=270 &DocI->= 11223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

4. .44 Renters Day Phone Extension

Entity ARM: Renter Detail

Column Name RKDYEX

Label Name Renters Day Phone Extension

System Name

Data Type NUMERIC(4)

Attribute Definition

4.1.45 Renters Night Phone

Entity ARM: Renter Detail

Column Name RKNTPH

Label Name Renters Night Phone

System Name

Data Type NUMERIC(IO)

Attribute Definition

4. . 6 Renters Night Phone Extensin

Entity ARM: Renter Detail

Column Name RKNTEX

Label Name Renters Night Phone Extensin

System Name

Data Type NUMERIC(4)

Attribute Definition

4. . 7 Repair Facility Name

4.7.48 standard message description

4.7.49 Start Date

Entity ARM: Authorization(Claim Info)

Column Name AZSTDT

Confidential Enteφrise Rent-A-Car © 2000 23 http^/intranefdm₂/ReadDocOrLink SP?Fold rID=270₄&Do.ID=n223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

Label Name Start Date

System Name

Data Type NUMERIC(8)

Attribute Definition

4.7.50 State

4.7.57 State

Entity ARM: Renter Detail

Column Name RKSACD

Label Name State

System Name

Data Type CHAR(2)

Attribute Definition

4.7.52 Sfafe

4.7.53 Status Description

4.7.54 Telephone Number

Entity ARM: Rental Location Master

Column Name LOPHNO

Label Name Telephone Number

System Name

Data Type NUMERIC(IO)

Attribute Definition

Confidential Enteφrise Rent-A-Car © 2000 24 http^/intr-net'dm2/ReadDocOrLink.ASP?FolderID-27()4&DocID=l 1223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

4.1.55 Telephone Number

Entity ARM: Repair Detail

Column Name RUPHNO

Label Name Telephone Number

System Name

Data Type NUMERIC(IO)

Attribute Definition

4.7.56 Total Amount Due

Entity A4 Invoice Trailer

Column Name I3BL$$

Label Name Total Amount Due

System Name

Data Type DECIMAL(9,2)

Attribute Definition

4.7.57 Total Amount Received

Entity A4 Invoice Trailer

Column Name I3RC$$

Label Name Total Amount Received

System Name

Data Type DECIMAL(9,2)

Attribute Definition

4.1.58 Total Ticket Charges

Entity A4 Invoice Trailer

Column Name I3TO$$

Label Name Total Ticket Charges

System Name

Data Type DECIMAL(9,2)

Attribute Definition

4.7.59 Transmission Code

Entity ARM: ARMS/400 Diary Notes File

Column Name NETRCD

Label Name Transmission Code

System Name

Data Type CHAR(1)

Attribute Definition

4.7.60 Vehicle Class

Entity ARM: Authorization(Claim Info)

Column Name AZVHCS

Label Name Vehicle Class

System Name

Data Type CHAR(2)

Confidential Enteφrise Rent-A-Car © 2000 25 http^Λntran-t (ta2 eadDocOr inkj\SP?FolderII>-270 &DocID-11223 ARMS Redesign Project - Release 1.0 Issue: 0.6 Error!

Reference source not found.

View Customer File Issue Date: 10/20/00

Attribute Definition

4.7.67 Vehicle Rate

Entity ARM: Authorization(Claim Info)

Column Name AZVHRT

Label Name Vehicle Rate

System Name

Data Type DECIMAL(5,2)

Attribute Definition

Confidential Enteφrise Rent-A-Car © 2000 26 htrpΛintiMet dm2/ReadDocC)rLink-ASP?FoldsrID=270 &Docπ 11223 Enterprise Rent-A-Car

Functional Design Specification Handle Unapproved Invoices

Version 1.1

Last Saved: 8/14/00 1:20 PM

ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

Revision History

Date Issue Description Author

April 19, 2000 0.1 Initial Creation of Section 1.0 Brad Reel

April 24, 2000 0.2 Changes to reflect initial team review Brad Reel

May 9, 2000 0.3 Included all subdocuments Cindy Bastean

May 9, 2000 0.3 Added changes from Final Team Review, Brad Reel, Deb Ealick, Removed subdocuments Anil Kabra, Cindy Bastean

June 9, 2000 1.0 Added data field information Cindy Bastean

June 12, 2000 1.0 Made the following Changes: Brad Reel

• Redefined the process based on iteration one feedback.

Removed invoice printing as part of the Basic Flow and added it to the Alternate Flows

• Detailed the Bulk Payment Reconciliation Process

• Added Alternate Flow to handle when the number of invoices on the Payment List exceeds the number that can be bulk-paid by the user 's system.

June 13, 2000 1.1 Removed reconciliation process from the Brad Reel specification. Reconciliation was deemed too complex to incorporate into the application at this time.

June 29, 2000 1.1 Updated screen field and data field Cindy Bastean information

June 29, 2000 1.1 Updated information throughout sections 1 Brad Reel & 2.

September 15, 2000 1.1 Updated information throughout sections Brian Weingart

Confidential Enteφrise Rent-A-Car © 2000 httprfintr_net dra2/ReadDocOrLiιιkΛSP?Folderπ =2705&E)ocID=10508 ARMS Redesign Project - Release 1.0 l_ssue: i .i

Handle Unapproved Invoices Issue Date: 10/20/00

Table of Contents Handle Unapproved Invoices

1. Handle Unapproved Invoices Use Case

1.1 Brief Description

1.2 Use Case Actors

1.3 Pre-Conditions

1.4 Flow of Events

1.4.1 Activity Diagram 2

1.4.2 Basic Flow 3

1.4.3 Alternative Flows 3

1.5 Post-Conditions 4

1.6 Special Requirements 4

1.6.1 ARMS Web Routes Invoices 5

1.6.2 Includes Tax and Surcharge Data Field 5

1.6.3 Data Fields to Assist with Future Releases or Customer Integration 5

1.7 Extension Points 5

1.7.1 BI-03-Reject an Invoice 5

1.7.2 MA-19-View Rental Detail 5

2. Screen Design 6

2.1 Invoicing — Individual Payment 6

2.1.1 Invoicing — Individual Payment 7

2.1.2 Invoicing — Individual Payment Screen Design 8

2.1.3 Screen Function Definition 10

2.2 Invoicing - Approval 11

2.2.1 Screen Layout - invoicingApproval.shtml 12

2.2.2 Invoicing Approval 13

2.2.3 Screen Function Definition 14

2.3 Individual Payment List 16

2.3.1 Screen Layout -invoicingPymtListshtml 16

2.3.2 Individual Payment List 17

2.3.3 Screen Function Definition 18

2.4 Bulk Payment List 19

2.4.1 Screen Layout - Bulk Payment List 19

2.4.2 Bulk Payment List 19

2.4.3 Screen Function Definition 21

3. Application Operations 22

3.1 Get Unapproved Invoices (Adjuster Id) 22

3.2 Approve Invoice (Invoice Number) 22

3.3 Get Approved Invoices (Adjuster Id) 22

3.4 Get Invoice Detail (Invoice Number) 22

3.5 Pay Invoice (Invoice Number, Check Number) 22

4. Data Fields 23 4.1 Data Field Definition 23

4.1.1 accounting name 23

4.1.2 action item assigned date 23

4.1.3 action item complete date 23

4.1.4 action item effective date 23

Confidential Enterprise Rent-A-Car © 2000 « ttp://inlranrt dm2 ReadDocθrLin ΛSP?Fo!derID-2705&Do ;π⁾-10508 ARMS Redesign Project - Release 1.0 l_ssue: ] . i

Handle Unapproved Invoices Issue Date: 10/20/00

4.1.5 action item status code 23

4.1.6 action item type code 24

4.1.7 action item type description 24

4.1.8 action related adjustor code 24

4.1.9 action related company identifier 24

4.1.10 Address Line 24

4.1.11 Address Line2 25

4.1.12 Adjustor Code 25

4.1.13 ARMS Profile ID 25

4.1.14 ARMS Profile ID 25

4.1.15 assigned to adjustor code 25

4.1.16 assigned to company identifier 26

4.1.17 Bill To % 26

4.1.18 Bill to End Date 26

4.1.19 Bill to Start Date 26

4.1.20 check number 26

4.1.21 City 26

4.1.22 claim type description 27

4.1.23 company identifier . 27

4.1.24 company structure level code 27

4.1.25 Customer Transaction ID 27

4.1.26 Date Of Loss 27 4.1 -27 Dollars Per Day Covered 28 4.1.28 End Date 28 4.129 external organization abbreviated name 28

4.1.30 external organization identifier 28

4.1.31 Federal ID Number 28

4.1.32 First Name 28

4.1.33 First Name 29

4.1.34 First Name 29

4.1.35 handled by adjustor code 29

4.1.36 handled by company identifier 29

4.1.37 handling for adjustor code 29

4.1.38 handling for company identifier 30

4.1.39 Insurance Claim Number 30

4.1.40 Insurance Claim Number 30

4.1.41 Invoice Number 30

4.1.42 Item Amount 30

4.1.43 Item Description 30

4.1.44 Item Quantity 31

4.1.45 Item Rate 31

4.1.46 Last Name 31

4.1.47 Last Name 31

4.1.48 Last Name 31

4.1.49 loss type description 31

4.1.50 Max $ Covered 32

4.1.51 NOTE 32

4.1.52 Number Of Days Authorized 32

4.1.53 Record Add Date 32

4.1.54 related office identifier 32

4.1.55 Remittance Reference # 33

4.1.56 Request Type 33

4.1.57 Start Date 33

Confidential Enteφrise Rent-A-Car © 2000 http:/Λntπ-iet/dιιι2 eadDocOrLink.ASP?FolderID=2705&DocII)=]0508 ARMS Redesign Project - Release 1.0 j_ssue: \ . j

Handle Unapproved Invoices Issue Date: 10/20/00

4.1.58 State 33

4.1.59 Status Code 33

4.1.60 Telephone Number 33

4.1.61 Total Amount Due 34

4.1.62 Total Amount Received 34

4.1.63 Total Billed to Others 34

4.1.64 Total Ticket Charges 34

4.1.65 Vehicle Rate 34

4.1.66 Zip Code 34

5. Questions and Answers 36

Confidential Enteφrise Rent-A-Car © 2000 http^ intrajιet;dm2/ReadDocOrLink_ASP?Folderπ '2705&Do ID=10508 ARMS Redesign Project - Release 1.0 Issue: 1.1

Handle Unapproved Invoices Issue Date: 10/20/00

1. Handle Unapproved Invoices Use Case

1.1 Brief Description

The Handle Unapproved Invoices use case describes how the Adjuster would review invoices and approve them for payment. The use case will then describe the processes the Adjuster will follow in the case where the Adjuster is the one that is actually paying the invoice.

1.2 Use Case Actors

The following actors will interact with this use case:

• ADJUSTER - The ADJUSTER will use this case to approve and either pay unapproved invoices or send them on to a PROCESSOR for payment.

1.3 Pre-Conditions

• The ADJUSTER must be logged into the ARMS Web system.

• The ADJUSTER'S office must be set up for individual approval of invoices.

• The ADJUSTER must be able to handle invoices.

1.4 Flow of Events

The Flow of Events will include the necessary steps for an ADJUSTER to approve and pay invoices.

Confidential Enterprise Rent-A-Car © 2000 http^intrane '⁽ta-/ReadDocOr ink-ASP?Folderro=2705&DocID-10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

1.4.1 Activity Diagram

Handle Unapproved Invoices Activity Diagram

9713/00 Y:\APPSWARMSWeb Application\@dkb\ARMS WeMRelease One\BI-Billlng and lnvotcing\BI-01-Handle Unapproved InvoicesWCT TY DIAGRBI-01-V1 -ACTIVITY DIAGRAM.VSD

Confidential Enterprise Rent-A-Car © 2000 htt ^ intranet/dm2 ReadDocOrLink.ASP?FoIderID=2705ιS.Docπ =10508 ARMS Redesign Project - Release 1.0 Issue: 1.1

Handle Unapproved Invoices Issue Date: 10/20/00

1.4.2 Basic Flow

1. The ADJUSTER will view the detail of the invoice.

2. If the ADJUSTER chooses to pay the invoice immediately, execute subflow 1.4.2.3 - Pay a Single Invoice. Otherwise continue the Basic Flow.

3. The ADJUSTER will approve the invoice.

4. The system will mark the invoice approved.

5. If the ADJUSTER pays their invoices, then the invoice will be added to their payment list. If a PROCESSOR pays their invoices, then the invoice will be added to the PROCESSOR'S payment list.

6. The system will update the ARMS Web database.

7. If this is the last or only invoice in the action items list, then continue to step eight of the Basic Flow. Otherwise, the use case ends.

8. The system will check to see if the ADJUSTER'S office is set up for individual payment or bulk payment.

• If the ADJUSTER'S office is setup for individual payment execute subflow 1.4.2.1, Individual Pay.

• If the ADJUSTER' S office is set up for bulk payment execute subflow 1.4.2.2, Bulk Pay.

1.4.2.1 Individual Payment List

1. The system will display instructions for paying the invoices individually and a summary list of all the invoices just approved by the ADJUSTER.

2. For each invoice on the payment list, the ADJUSTER may enter the associated check number.

3. The ADJUSTER will submit the payment list to the system.

4. The system will mark the invoice paid

5. The system will update the ARMS Web database.

6. This ends the use case.

1.4.2.2 Bulk Payment List

1. The system will display instructions for paying the invoices in bulk and a summary list of all the invoices just approved by the ADJUSTER.

2. The ADJUSTER may enter the check number of the check that is paying all the invoices on the payment list.

3. The ADJUSTER will submit the payment list to the system.

4. The system will mark the invoice paid

5. The system will update the ARMS Web database.

6. This ends the use case.

1.4.2.3 Pay a Single Invoice

1. The ADJUSTER may enter the check number for the invoice being paid.

2. The system will mark the invoice paid

3. The system will update the ARMS Web database.

4. This ends the use case.

1.4.3 Alternative Flows

1.4.3.1 Selected Action Item is Payment List

At step one of the Basic Flow, if the action item being worked is the "Payment List" action item, then the ADJUSTER will be taken immediately to step one of section 1.4.2.1 if they are set up for individual pay, or step one of section 1.4.2.2 if they are set up for bulk pay.

1.4.3.2 Reject an Invoice

At step one in the Basic Flow, the ADJUSTER may choose to reject the invoice. The rejection process is executed using extension point BI-03 - Reject an Invoice.

Confidential Enterprise Rent-A-Car © 2000 httρ^Λntranet/d 2 R(:adDocOrLinkΛSP?FolderID=2705&DocII =10508 ARMS Redesign Project - Release 1.0 Issue: 1.1

Handle Unapproved Invoices Issue Date: 10/20/00

1.4.3.3 View Customer File

At Individual Payment List or Bulk Payment List, the ADJUSTER may choose to view detail information about the rental. The view rental detail process is executed using extension point MA-19 - View Customer File.

1.4.3.4 Print a Single Invoice

At step one in the Basic Flow, the ADJUSTER may choose to print the invoice. If they so choose, they may also print the rental history. The system will display a printer friendly screen and the ADJUSTER will choose to print via their browser window. Upon printing, the ADJUSTER will choose to retum to the step one of the Basic Flow by hitting the "back" button on the web browser.

1.4.3.5 Print an Invoice List

At step one in section 1.4.2.1, Individual Pay, or section 1.4.2.2, Bulk Pay, the ADJUSTER may choose to print the invoice list of all invoices on the Payment List. If they so choose, they may also print the rental history for all invoices. The system will display a printer friendly screen and the ADJUSTER will choose to print via their browser window. Upon printing, the ADJUSTER will choose to return to the step one of section 1.4.2.1 if the ADJUSTER is set up for Individual Pay, or section 1.4.2.2 if the ADJUSTER is set up for Bulk Pay.

14.3.6 Skip Invoice

At step three in the Basic Flow, the ADJUSTER may choose to skip the invoice in question and handle it at a later time. The ADJUSTER will be taken to the next action item on their action item list. The status of the invoice should not be changed by the ARMS Web system.

14.3.7 Payment by PROCESSOR

If the ADJUSTER is only responsible for approving the invoice, then, after step four in the Basic Flow, the system will make the approved invoice an action item for the PROCESSOR(S) responsible for paying the ADJUSTER'S invoices. This ends the use case. Payment by PROCESSOR is handled via Functional Specification BI-02 - Pay Approved Invoices.

14.3.8 Amount Being Approved Exceeds USER'S Authorization Limits

When a USER attempts to approve an invoice for payment, the system will check to see if the amount due on the invoice is greater than the USER'S authorization amount. If the amount due is greater than the USER'S limit, the system will not allow the approval and will request that the USER transfer the invoice to another user with authorization limits that are great enough to approve the invoice.

1.4.3.9 Change Claim Number

At step one in the Basic Flow, if the status is "rejected" and if the profile allows, the ADJUSTER may choose to change the claim number associated with an invoice. Once a claim number has been updated, the ADJUSTER will continue with step four of the basic

1.5 Post-Conditions

• If the use case was successful and the ADJUSTER is responsible for paying invoices, the approved invoices should be marked as paid in the ARMS Web system.

• If the use case was successful and the ADJUSTER is only responsible for approving invoices, then the approved invoices should be marked as adjuster approved in the ARMS Web system.

1.6 Special Requirements

The additional requirements of the business use case are included here. These are requirements not covered by the flow as they have been described in the sections above.

Confidential Enteφrise Rent-A-Car © 2000 4 httprf/intranet/<- 2/ReadDo< LinkASP7FolderlD=2705&Docπ =10508 ARMS Redesign Project - Release 1.0 τ_ssue: j.j

Handle Unapproved Invoices Issue Date: 10/20/00

1.6.1 ARMS Web Routes Invoices

Before an ADJUSTER receives an invoice to be approved, the ARMS Web system will look at the invoicing criteria for the owning office and owning adjuster and make a determination as to whether the invoice is auto approved or adjuster approved. If an invoice is auto approved, the invoice will always be assigned to a processor for payment without it ever being sent to an adjuster for approval. The payment method may be either bulk or individual payment.

1.6.2 Includes Tax and Surcharge Data Field

On the invoice next to the authorized amount, the field "Includes Tax and Surcharge" will be displayed next to the Authorized total if that total should include taxes and surcharges. This will occur in two events. For an insured, if the authorized amount is less than the policy daily amount, the authorized total will include taxes and surcharges up to the policy daily amount. For a claimant, the authorized amount will always include taxes and surcharges, without limit, until the rental is terminated by the ADJUSTER.

1.6.3 Data Fields to Assist with Future Releases or Customer Integration

It must be possible to capture the following information at some point in the future because of either planned future releases or customer integration.

• Amount Being Paid on Each Invoice

1.7 Extension Points

An extension point indicates a link between this use case and another use case. Extension points associated with the use case are indicated below. Clicking on the extension point will open the related use case.

1.7.1 BI-03-Reject an Invoice

The Reject an Invoice Functional Specification is used to reject a specific invoice to Enterprise due to missing required information or an incorrect amount on the bill. Upon completion of the Reject an Invoice Functional Specification, the ADJUSTER should be returned to step six of the Basic Flow in the Handle Unapproved Invoices Functional Specification. Any previously approved invoices should still be approved in the system. The rejected invoice should be marked as rejected by the system. The Handle Unapproved Invoices Functional Specification will only allow for one invoice to be rejected at a time.

17.2 MA-19-View Rental Detail

The View Rental Detail Functional Specification is used to review the rental history in regards to a specific rental. Upon completion of the View Rental Detail Functional Specification, the ADJUSTER should be returned to step four of the Basic Flow in the Handle Unapproved Invoices Functional Specification. Any previously approved invoices should still be approved in the system.

Confidential Enteφrise Rent-A-Car © 2000 http:/intr_net/dm2 ReadDo(K Jnk.ASP?FolderID=2705&DoclD=10508 ARMS Redesign Project - Release 1.0 Issue: 1.1

Handle Unapproved Invoices Issue Date: 10/20/00

2. Screen Design

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Invoicing - Individual Payment

This screen will allow the user to choose to view the invoice selected in the action items list. They will choose to either pay this invoice immediately (pay now), or choose to add it to a payment list for payment later in conjunction with all their other invoices. They may also choose to print the invoice from this page. They may also optionally choose to print the rental history. The user may choose to change the claim number. Finally the user may choose to skip this invoice and leave it until later for review.

Confidential Enteφrise Rent-A-Car © 2000 hrφ^/intraιιet/dra2/ReadDocOr inkΛSP?Folderπ =₂705&DocID=10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

2.1.1 Invoicing - Individual Payment

Confidential Enteφrise Rent-A-Car © ₂000 http:/ intι-ne-^,dm2/RcadDocOrlJn .ASP?Fo^]derID=2705&E>ocID=105()8 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

2.1.2 Invoicing - Individual Payment Screen Design

Confidential Enterprise Rent-A-Car © ₂000 http^ intπmet/dm2/ eadDocOrLink.ASP?Folder-D=2705&DocID=10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

Confidential Enterprise Rent-A-Car © 2000 http://intπmet dm2/ReadDc«OrLinkASP?FoldcrII>-2705&t)ocID=10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.1.3.1 PRINTER FRIENDLY PAGE

When clicked, the user will be taken to the "Printer Friendly View" ofthe current invoice.

2.1.3.2 REJECT

When clicked, the user will be taken to the Reject Invoice process.

2.1.3.3 PAY NOW

When clicked, the system will edit the current information. If the edit passes, the invoice will be marked as paid and the data files updated. If the validation fails, the user will be returned to the current screen with the errors highlighted.

2.1.3.3.1 The system will validate that the user has an authorization limit high enough to approve the invoice. If not, the system will generate an error and ask the USER to transfer the invoice.

2.1.3.4 ADD TO PA YMENT LIST

When clicked, the system will edit the current information for check number and claim number. If the edit passes, the invoice will be marked as approved and will be added to the ADJUSTER'S payment list and the user will be returned to the Review List process.

2.1.3.5 SKIP»

When clicked, the user will be advanced to the next action item to be processed and the current invoice will remain unchanged (un-approved).

Confidential Enterprise Rent-A-Car © 2000 10 hnp*inlranet/dm2 ReadDocOrLinkΛSP?FolderID=2705&DoclD=]0508 ARMS Redesign Project - Release 1.0 Issue: 1.1

Handle Unapproved Invoices Issue Date: 10/20/00

2.1.3.6 Top of Page

When clicked, the user will be taken to the top ofthe current invoice page.

2.13.7 Transfer File

When clicked, the system will present a list of users that have authorization limits greater than the amount due on the invoice. The USER may then choose one user from this list to which they may transfer the file.

2.1.3.8 Policy Information

Policy Information will only be shown under the Authorized Section if the claim type is NOT claimant.

2.2 Invoicing -Approval

This screen will allow the user to choose to view the invoice selected in the action items list. They may choose to approve the invoice payment. This will add the invoice to the PROCESSOR(S) that are responsible for paying the ADJUSTER'S invoices. The user may also choose to skip this invoice and leave it until later for review. They may choose to print the invoice from this page. They may also optionally choose to print the rental history. Finally, the user may choose to change the claim number.

Confidential Enteφrise Rent-A-Car © 2000 I 1 hr^:/intra-ier dm2 ReadDcκ;OrUι-c.ASP?FolderII>=2705&E>ocID=10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

2.2.1 Screen Layout - invoicingApprovaishtml

Confidential Enterprise Rent-A-Car © 20Q0 12 http^intranel dm2/ReadDocθrLink.ASP?FolderID=2705&Docir⁾=10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

2.2.2 Invoicing Approval

Output 152 Line item Charge Item Amount Line Item Charge Q y * Line Item Amount Charge Amount.

This line may repeat multiple times depending on the number of taxes and surcharges that apply.

Output 15 Line Item Charge Item Description This line may repeat multiple times Description depending on the number of taxes and surcharges that apply.

Claim No: Output 15 Claim Number Insurance Claim Number

Claim Number Input 15 Claim Number Insurance Claim Will be pre-filled with claim number Number curently on authorization.

To Output 10 Close Date of billing of Bill to End Date Rental Ticket

Invoice Date: Output 10 Invoice Date (ECARs Record Add Date Ticket Date)

Reference Output 20 Invoice Id Invoice Number Rental Group Id + Rental Branch Id + ECARS Ticket Number

Federal ID: Output 30 Location's Federal Id. Federal ID Number

Billed Period Output 10 Start date of billing of Bill to Start Date Rental Ticket

Amount Output 15,2 Amount of rental Total Amount Received: received. Received

Total Due Output 15,2 Total amount due from Total Amount Due Ins. Company

Total Charges: Output 15,2 Total Rental Ticket Total Ticket Charges Charges

Handling For: Output 30 Handling for Adjuster's First Name + Last Adjuster's First name + Adjuster's last Name Name name. The name ofthe adjuster to which the invoice is currently assigned.

Output 50 Messages NOTE This field will repeat multiple lines for all diary notes (messages ) for a reservation

To Output 10 Authorization End Date Termination Date

Direct Bill Output 15,0 Authorized Bill Bill To % Percent: percentage

Direct Bill Output 15,0 Authorized Bill Bill To % Percent percentage

Authorized Output 10 Authorized Start Date Start Date Period:

To Output 10 Close Date of Rental End Date Ticket

Policy: Daily Output 15,2 Policy Daily Maximum Dollars Per Day

Rate Max Amount + Policy Covered

Dollars Maximum

Confidential Enterprise Rent-A-Car © 2000 13 http^/inlι™et dm2/ReadDocOrLink-ASP?FolderID=2705&DoclI>=10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

2.2.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

Confidential Enterprise Rent-A-Car © 2000 14 httpΛintranet dm2 ReadDocθrUnkΛSP?FolderID=2705&DocID= 10508 ARMS Redesign Project - Release 1.0 Issue: 1.1

Handle Unapproved Invoices Issue Date: 10/20/00

2.2.3.1 PRINTER FRIENDLY PAGE

When clicked, the user will be taken to the "Printer Friendly View" ofthe current invoice.

2.2.3.2 REJECT

When clicked, the user will be taken to the Reject Invoice process.

2.2.3.3 APPROVE FOR PAYMENT

When clicked, the currently displayed invoice status will be marked as approved and the user will be taken to the next Action Item.

• The system will validate that the user has an authorization limit high enough to approve the invoice. If not, the system will generate an eπor and ask the USER to transfer the invoice.

• Another adjuster has not already approved the invoice.

2.2.3.4 SKIP»

When clicked, the user will be advanced to the next selected action item to be processed and the cuπent invoice will remain unchanged (un-approved).

2.2.3.5 Top of Page

When clicked, the user will be taken to the top ofthe cuπent invoice page.

2.2.3.6 Transfer File

When clicked, the system will present a list of users that have authorization limits greater than the amount due on the invoice. The USER may then choose one user from this list to which they may transfer the file.

2.2.3.7 Policy Infonpation

Policy Information will only be shown under the Authorized Section if the claim type is NOT claimant.

Confidential Enterprise Rent-A-Car © 2000 15 httpΛintiOTet dm2 ReadDocθrLink.ASP?FolderII>=2705&Doc-D=10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

2.3 Individual Payment List

This screen provides the user with information on what the system expects them to do, and requests a check number that will be used to pay each invoice. The user may also choose to print the invoices, and optionally print the rental history in addition to the invoices. The user may choose not to process the payment list at this time, in which case the payment list will be added to the user's action items list.

2.3.1 Screen Layout -invoicingPymtListshtml

Confidential Enteφrise Rent-A-Car © 2000 16 http:/ intι™et/dm2 ReadDocOr in⁾ .ASP?FolderID=2705&E)octD=10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

Confidential Enterprise Rent-A-Car © 2000 17 http-7 inb_net dm2 ReadDocOrLink.ASP?Fo!dcrri)=2705&DoclD=l050S ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

2.3.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.3.3.1 PRINTER FRIENDLY PAGE

When clicked, the user will be taken to the "Printer Friendly View" ofthe current invoices.

2.3.3.2 CONFIRM PAYMENT

When clicked, system will mark the reservation as paid and update the database. The update will be passed to the Arms system.

2.3.3.3 PAY LATER

When clicked, the user will be returned to view list and the requests will remain unchanged.

2.3.3.4 Top of Page

When clicked, the user will be taken to the top ofthe current invoice page.

Confidential Enterprise Rent-A-Car © 2000 18 httpι/ tr_-iet/dm2 _MdDocOrUnk-ASP?Folderπ)=2705&Docn 1050S ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

2.4 Bulk Payment List

This screen provides the user with information on what the system expects them to do, and requests a check number that will be used to pay each invoice. The user may also choose to print the invoices, and optionally print the rental history in addition to the invoices. The user may choose not to process the payment list at this time, in which case the payment list will be added to the user's action items list.

2.4.1 Screen Layout - Bulk Payment List

2.4.2 Bulk Payment List

S\/. Screen Ficki Name IHRRIOTΠΠ

Confidential Enterprise Rent-A-Car © 2000 19 htrj)Λ^"ntr_net dm2/ReadDc :OrLink.ASP?FolderID=2705&DocID-1050S ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

Confidential Enterprise Rent-A-Car © 2000 20 httpΛntι-nct dm2 ReadDocOr ink SP?FolderID=2705&DocID=10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

2.4.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.4.3.1 PRINTER FRIENDLY PAGE

When clicked, the user will be taken to the "Printer Friendly View" ofthe current invoices.

2.4.3.2 CONFIRM PAYMENT

When clicked, the system will mark the reservation as paid and update the database. The update will be passed to the Arms system. The user will then be returned to the next action item or the Action Items screen if no more action items exist.

2.4.3.3 PAYLATER

When clicked, the user will be returned to Action Items and the request will remain unchanged.

2.4.3.4 Top of Page

When clicked, the user will be taken to the top ofthe payment list.

Confidential Enterprise Rent-A-Car © 2000 21 http:/Λntr_Met/dm2/ReadDocθrLink.ASP?FolderII =2705&DocID-10508 ARMS Redesign Project - Release 1.0 Issue: l . l

Handle Unapproved Invoices Issue Date: 10/20/00

3. Application Operations

This section will detail all the application operations that are part of this Functional Specification Document.

3.1 Get Unapproved Invoices (Adjuster Id)

The build unapproved invoice list operation finds all the invoices, that need approval, for the specified adjuster.

3.2 Approve Invoice (Invoice Number)

The approve invoice operation marks the specified invoice as approved. This invoice is now ready to be paid.

3.3 Get Approved invoices (Adjuster Id)

The build approved invoice list operation finds all the approved invoices for the specified adjuster.

3.4 Get Invoice Detail (Invoice Number)

The build invoice detail operation gets the relevant invoice information for the specified invoice number.

3.5 Pay Invoice (Invoice Number, Check Number)

The pay invoice operation records the check number specified by the adjuster against the specified invoice and marks the invoice as paid.

Confidential Enterprise Rent-A-Car © 2000 ²² hrtp^intr_net dm2 ReadDocθrLink.ASP?FolderID=2705&DoclD=10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

4. Data Fields

4.1 Data Field Definition

This section includes a definition of all data fields included in the functional specification

4.1 accounting name

Confidential Enterprise Rent-A-Car © 2000 23 http://intr_net/dm2/ReadDocOrLink.ASP?FolderID=270S&DocID=10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

4.1.6 action item type code

4. .7 action item type description

4.1.8 action related adjustor code

4.1.9 action related company identifier

4.7.70 Address Line

Confidential Enterprise Rent-A-Car © 2000 24 httpΛntranet/dra2/ReadI)ocOrLinkASP?FoldCTlD=2705&DocID=10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

4. . 7 Address Line2

4.7.72 Adjustor Code

4.7.73 ARMS Profile ID

4.7.74 ARMS Profile ID

4.1.15 assigned to adjustor code

Confidential Enterprise Rent-A-Car © 2000 25 httpΛintranet/dm2 ReadDocOrLink.ASP?FolderII>=2705&DocID=l050S ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

4.1.16 assigned to company identifier

4.7.77 Bill To %

4.7.78 Bill to End Date

4.7.79 Bill to Start Date

4.7.20 check number

4.7.27 City

Confidential Enteφrise Rent-A-Car © 2000 26 http://intr_αιet/d 2 R-adDocOrUnkASP?FolderID=2705--I>αc-D=10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

4.7.22 claim type description

4.1.23 company identifier

4. .24 company structure level code

Entity ACTION ITEM

Column Name cmpy strct lvl cde

Label Name company structure level code:

System Name CMPYSLVLCD

Data Type DEC(3,0)

Attribute Definition The external organization structure level code identifies the kind or type of internal organizations ofthe external organizations which Enterprise Rent- A-Car does business with. Such as: Corporation, Branch Claims Office, Region, Area, Subregion, etc.

4.7.25 Customer Transaction ID

4.7.26 Date Of Loss

Entity ARM: Renter Detail

Column Name RKLSDT

Label Name Date Of Loss

System Name

Data Type NUMERIC(8)

Attribute Definition

Confidential Enteφrise Rent-A-Car © 2000 27 httpJ inlr-nerdm2«eadDocOrLink.ASP?Folderπ =2705&Docπ>-10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

4. .27 Dollars Per Day Covered

Entity ARM: Authorization(Claim Info)

Column Name AZSPDY

Label Name Dollars Per Day Covered

System Name

Data Type DECIMAL(5,2)

Attribute Definition

4.7.28 End Date

Entity ARM: Authorization(Claim Info)

Column Name AZENDT

Label Name End Date

System Name

Data Type NUMERIC(8)

Attribute Definition

4.7.29 external organization abbreviated name

Entity EXTERNAL ORGANIZATION

Column Name e o abbr nam

Label Name external organization abbreviated name:

System Name EOABBRNAM

Data Type CHAR(10)

Attribute Definition External Organization Abbreviated Name is a shortened text based label associated with an organization outside of Enterprise. This name is sometimes used for accounting purposes.

4. .30 external organization identifier

4.7.37 Federal ID Number

4.7.32 First Name

Entity ARM: Adjustor Master

Confidential Enteφrise Rent-A-Car © 2000 28 http*intr^et/dnι2/ReadDocθrLinkΛSP?FolderID=2705&DocID=10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

4.7.33 First Name

Entity ARM: Insured Detail

Column Name IRFSNM

Label Name First Name

System Name

Data Type CHAR(15)

Attribute Definition

4.7.34 First Name

4.7.35 handled by adjustor code

4.7.36 handled by company identifier

Entity ACTION ITEM

Column Name handl_by_cmρy_id

Label Name ARMS Profile ID

System Name HNDCMPYID

Data Type CHAR(5)

Attribute Definition The handled by company identifier is the company identifier ofthe administrator or adjustor's who is handling the action item.

4.7.37 handling for adjustor code

Confidential Enteφrise Rent-A-Car ©2000 29 http^/intnmet (ta2 ReadD-«C rl-mk.ASP?Fo]dern -2705&DocID-10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

Web application

4.7.38 handling for company identifier

4.1.39 Insurance Claim Number

4.7.40 Insurance Claim Number

4.7.47 Invoice Number

4.7.42 Item Amount

4.1.43 Item Description

Confidential Enteφrise Rent-A-Car © 2000 30 http://intranet/dnι2 ReadDocOrUnkASP?FolderID=2705&DocID=10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

4.7.44 Item Quantity

4.7.45 Item Rate

4.7.46 Last Name

4.7.47 Last Name

4.7.48 Last Name

4.7.49 loss type description

Entity LOSS TYPE

Confidential Enteφrise Rent-A-Car © 2000 31 trp^/intι™et dm2/ReadDocOrLink.ASP?FolderID=2705_.DooII 10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

4.7.50 Max $ Covered

4.7.57 NOTE

4.7.52 Number Of Days Authorized

4.7.53 Record Add Date

4.7.54 related office identifier

Confidential Enteφrise Rent-A-Car © 2000 32 http^/intiOTet dm2/ReadDocOr inkΛSP?FolderID=2705---)ocir>-10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00 action item.

4.1.55 Remittance Reference #

Entity A4 Remit Reference No.

Column Name Q5RMNO

Label Name Remittance Reference #

System Name

Data Type NUMERIC(6)

Attribute Definition

4.7.56 Request Type

Entity ACTION ITEM TYPE

Column Name XURSTP

Label Name Request Type

System Name XURSTP

Data Type CHARO)

Attribute Definition The request type is a code from the ARMS system which identifies whether adjusor action is necessary for an authorization and what type of action.

4.7.57 Start Date

Entity ARM: Authorization(Claim Info)

Column Name AZSTDT

Label Name Start Date

System Name

Data Type NUMERIC(8)

Attribute Definition

4.7.58 State

4.7.59 Status Code

Entity ACTION ITEM TYPE

Column Name XUSTCD

Label Name Status Code

System Name XUSTCD

Data Type CHAR(l)

Attribute Definition The status code is a code from the ARMS system which identifies whether an authorization is a reservation, a ticket, unauthorized, invoiced, paid, etc.

4.7.60 Telephone Number

Entity ARM: Rental Location Master

Column Name LOPHNO

Confidential Enteφrise Rent-A-Car © 2000 33 http^ intr_net dm2/ eadDocOrLirdcΛSP?FolderID==2705&Dcιcπ 10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

Label Name Telephone Number

System Name

Data Type NUMERIC(IO)

Attribute Definition

4.7.67 Total Amount Due

Entity A4 Invoice Trailer

Column Name I3BL$$

Label Name Total Amount Due

System Name

Data Type DECIMAL(9,2)

Attribute Definition

4.7.62 Total Amount Received

Entity A4 Invoice Trailer

Column Name I3RC$$

Label Name Total Amount Received

System Name

Data Type DECIMAL(9,2)

Attribute Definition

4.7.63 Total Billed to Others

Entity A4 Invoice Trailer

Column Name BOT$$

Label Name Total Billed to Others

System Name

Data Type DECIMAL(9,2)

Attribute Definition

4.7.64 Total Ticket Charges

Entity A4 Invoice Trailer

Column Name I3TO$$

Label Name Total Ticket Charges

System Name

Data Type DECIMAL(9,2)

Attribute Definition

4.7.65 Vehicle Rate

Entity ARM: Authorization(Claim Info)

Column Name AZVHRT

Label Name Vehicle Rate

System Name

Data Type DECIMAL(5,2)

Attribute Definition

4.7.66 Zip Code

Entity ARM: Rental Location Master

Confidential Enteφrise Rent-A-Car © 2000 34 http://intr-net dnι2/Rι--dDocθrLink-ASP?FolderII =2705&DocID=10508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

Confidential Enteφrise Rent-A-Car © 2000 35 http:/Λntι∞et/dm2/ReadDocOrLinkΛSP?Fo^]derlI>-2705&DocID=l0508 ARMS Redesign Project - Release 1.0 Issue: 1.1 Handle Unapproved Invoices Issue Date: 10/20/00

5. Questions and Answers

Issue Number: 256

Question: The calculation for authorized limit when displaying the invoice detail does not take bill to percent into account when all the following conditions are true:

Policy Maximum = 0

Policy Daily > 0

Vehicle Rate > 0

Vehicle Rate < Policy Daily or all the following conditions are true:

Policy Maximum > 0

Policy Daily = 0

Vehicle Rate > 0 In all other cases, the amount is multiplied by the bill to percent to get the authorized limit. Is this calculation correct ?

Status: Pending

Resolution: 3-14-00, DSE-Need to follow up with author to get an further understanding of question.

3-23-00, Issue Mtg, Will get addressed in current state and fix.

Issue Number: 257

Question: This is a presentation issue. The adjuster name on the invoice detail screen will not show up in certain cases. This code is in the *INZSR sub routine and needs some investigation of scenarios to determine the exact flaw.

Status: Closed - Resolved

Resolution: 3-14-00, DSE-Need to follow up with author to get an further understanding of question.

Confidential Enteφrise Rent-A-Car ©2000 36 http://intranet dni2/RcadDocOrLi!ik.ASP?FolderID=2705--DocID=10508 Enterprise Rent-A-Car

Functional Design Specification

Pay Approved Invoices

(Processor Pay)

Version 1.0

Last Saved: 6/29/008:56 AM

ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00

Confidential Enteφrise Rent-A-Car © 2000 http://intιanet dm2/ReadDocOrLink.ASP?FolderlI 2705&DocID=l 0509 ARMS Redesign Project - Release 1.0 Issue: 1.0

Pay Approved Invoices Issue Date: 10/20/00

Table of Contents Pay Approved Invoices

1. Pay Approved Invoices Use Case

1.1 Brief Description

1.2 Use Case Actors

1.3 Pre-Conditions

1.4 Flow of Events

1.4.1 Activity Diagram 2

1.4.2 Basic Flow 4

1.4.3 Alternative Flows 4

1.5 Post-Conditions 4

1.6 Special Requirements 5

1.6.1 ARMS Web Routes Invoices 5

1.6.2 Data Fields to Assist with Future Releases or Customer Integration 5

1.6.3 Claim Number is Editable on the Invoice 5

1.7 Extension Points 5 1.7.1 MA-19-View Customer File 5

2. Screen Design 6

2.1 Invoicing - Individual Payment List 6

2.1.1 Individual Payment List 7

2.1.2 Individual Payment List 9

2.1.3 Screen Function Definition 10

2.2 Bulk Payment List 11

2.2.0 Screen Layout - Bulk Payment List 11

2.2.1 11 2.2.2

Confidential Enteφrise Rent-A-Car © 2000 http://intranet/dra2 ReadDocOrLink.ASP?FolderID=2705&DocID=10509 ARMS Redesign Project - Release 1 0 Issue. 1 0 Pay Approved Invoices Issue Date: 10/20/00

2.2.2 Invoicing - Bulk Payment List 12

2 2.3 Screen Function Definition 13

2.3 Return Invoice to Adjuster 14 2 3.1 Screen Layout - returnBilluig.shtml 14 2.3.2 Return Billing 14 2.3 3 Screen Function Definition 14

3. Application Operations 15

3 1 Get Approved Invoices (Office Id) 15

Confidential Enterpπse Rent-A-Car © 2000 http //ιntranet/dm2/ReadDocOrLιnk.ASP'FolderlD=2705&DoclD=10509 ARMS Redesign Project - Release 1.0 Issue: 1.0

Pay Approved Invoices Issue Date: 10/20/00

3.2 Get Invoice Detail (Invoice Number) 15

3.3 Return Invoice to Approving Adjuster (Invoice Number, Reason Code) 15

3.4 Pay Invoice (Invoice Number, Check Number) 15

Data Fields 16

4.1 Data Field Definition 16

4.1.1 accounting name 16

4.1.2 action item complete date 16

4.1.3 action item effective date 16

4.1.4 action item status code 16

4.1.5 action item type code 16

4.1.6 action item type description 17

4.1.7 Address Line 17

4.1.8 Address Line2 17

4.1.9 ARMS Profile LD 17

4.1.10 assigned to adjustor code 17

4.1.11 assigned to company identifier 18

4.1.12 Bill To % 18

4.1.13 Branch 18

4.1.14 check number 18

4.1.15 City 18

4.1.16 claim type description 18

4.1.17 company identifier 19

4.1.18 company structure level code 19

4.1.19 Customer Transaction ED 19

4.1.20 Date Of Loss 19

4.1.21 Dollars Per Day Covered 19

4.1.22 End Date 20

4.1.23 external organization abbreviated name 20

4.1.24 external organization identifier 20

4.1.25 Federal ID Number 20

4.1.26 First Name 20

4.1.27 First Name 21

4.1.28 Group 21

4.1.29 handled by adjustor code 21

4.1.30 handled by company identifier 21

4.1.31 handling for adjustor code 21

4.1.32 handling for company identifier 21

4.1.33 Insurance Claim Number 22

4.1.34 Insurance Claim Number 22

4.1.35 Invoice Number 22

4.1.36 Item Amount 22

4.1.37 Item Description 22

4.1.38 Item Quantity 23

4.1.39 Item Rate 23

4.1.40 Last Name 23

4.1.41 Last Name 23

4.1.42 loss type description 23

4.1.43 Max $ Covered 23

4.1.44 NOTE 24

4.1.45 Record Add Date 24

4.1.46 related office identifier 24

4.1.47 Request Type 24

Confidential Enterprise Rent-A-Car © 2000 http://intranet/dm2/ReadDocOrLinkASP?FolderID=2705&DocID=10509 ARMS Redesign Project - Release 1.0 Issue: 1.0

Pay Approved Invoices Issue Date: 10/20/00

4.1.48 standard message description 24

4.1.49 Start Date 25

4.1.50 State 25

4.1.51 Status Code 25

4.1.52 Telephone Number 25

4.1.53 Ticket Number 25

4.1.54 Total Amount Due 25

4.1.55 Total Amount Received 26

4.1.56 Total Billed to Others 26

4.1.57 Total Ticket Charges 26

4.1.58 Zip Code 26

5. Questions and Answers 27

Confidential Enterprise Rent-A-Car © 2000 http://intranet/dm2/ eadDooOrLin .ASP?FolderID=270S&DoeID=10509 ARMS Redesign Project - Release 1.0 Issue: 1.0

Pay Approved Invoices Issue Date: 10/20/00

1. Pay Approved Invoices Use Case

1.1 Brief Description

The Pay Approved Invoices use case describes how the PROCESSOR would review and pay invoices in the ARMS Web system.

1.2 Use Case Actors

The following actors will interact with this use case:

• PROCESSOR - The PROCESSOR will use this use case to pay approved invoices.

1.3 Pre-Conditions

• The PROCESSOR must be logged into the ARMS Web system.

• The PROCESSOR'S office must be set up to handle processor payment of invoices.

• The PROCESSOR must be authorized to handle invoices.

1.4 Flow of Events

The Flow of Events will include the necessary steps for a PROCESSOR to review and pay invoices.

Confidential Enteφrise Rent-A-Car © 2000 http://intranetdm2/ReadDocOrLink.ASP?FolderID=2705&DooID=10509 ARMS Redesign Project - Release 1.0 Issue: 1.0

Pay Approved Invoices Issue Date: 10/20/00

1.4.1 Activity Diagram

Confidential Enteφrise Rent-A-Car © 2000 http://iπtranet/dm2/ReadDocOrLink.ASP?FolderID=2705&DocID=10509 ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00

Pay Approved Invoices Activity Diagram

\\FSCORP00\coφjDUblic\APPS\#ARMSWeb\Application\@ kb ARMS Web\Release One\BI-Billing and lnvoic!ng\BI-02-Pay Approved lnvoices\ACTIVITY DIAGRAMS\BI-02-ACTIVITY DIAGRAM.VSD

9/15/00

Confidential Enteφrise Rent-A-Car © 2000 http://intranet dm2/ReadDooOrLink.ASP?FolderlD=2705&DoclI 10509 ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00

1.4.2 Basic Flow

1. The PROCESSOR will view their payment list.

2. The system will check to see if the PROCESSOR'S office is set up for individual payment or bulk payment.

• If the PROCESSOR'S office is set up for individual payment execute subflow 1.4.2.1, Individual Pay.

• If the PROCESSOR'S office is set up for bulk payment execute subflow 1.4.2.2, Bulk Pay.

1.4.2.1 Individual Pay

1. The system will display instructions for paying the invoices individually and a summary list of all the invoices on the PROCESSOR'S payment list.

2. For each invoice on the payment list, the PROCESSOR may enter the associated check number.

3. The PROCESSOR will submit the invoices to the system.

4. The system will mark the invoices paid.

5. The system will update the ARMS Web database.

6. This ends the use case.

14.2.2 Bulk Pay

1. The system will display instructions for paying the invoices in bulk and a summary list of all the invoices on the PROCESSOR'S payment list.

2. The ADJUSTER may enter the check number ofthe check that is paying all the invoices on the payment list.

3. The PROCESSOR will submit the invoices to the system.

4. The system will mark the invoices paid.

5. The system will update the ARMS Web database.

6. This ends the use case. 4.3 Alternative Flows

1.4.3.1 View Customer File

At step one of Section 1.4.2.1, Individual Pay, or Section 1.4.2.2, Bulk Pay, the PROCESSOR may choose to view detail information about the rental. The view rental detail process is executed using extension point MA-19 - View Customer File.

1.4.3.2 Return an Invoice

At step one of Section 1.4.2.1, Individual Pay or Section 1.4.2.2, Bulk Pay the PROCESSOR may choose to return any invoice to the ADJUSTER. The PROCESSOR may enter a message to explain why they returned the invoice. The returned invoice should be given a status of returned invoice. The invoice will then become an action item for the owning ADJUSTER to review and correct.

1.4.3.3 Print an Invoice List

At step one in section 1.4.2.1, Individual Pay, or section 1.4.2.2, Bulk Pay, the PROCESSOR may choose to print the invoice list of all invoices on the Payment List. If they so choose, they may also print the rental history for all invoices. The system will display a printer friendly screen and the PROCESSOR will choose to print via their browser window. Upon printing, the PROCESSOR will return to the step one of section 1.4.2.1 if the PROCESSOR is set up for Individual Pay, or section 1.4.2.2 if the PROCESSOR is set up for Bulk Pay.

1.5 Post-Conditions

• If the use case was successful the accepted invoices should be marked as paid in the ARMS Web

Confidential Enterprise Rent-A-Car © 2000 http://intranet dm2 eadDocOrLink.ASP?FolderID=2705&DoclD=10509 ARMS Redesign Project - Release 1.0 Issue: 1.0

Pay Approved Invoices . Issue Date: 10/20/00 system. • If the use case was unsuccessful, the system state is unchanged.

1.6 Special Requirements

The additional requirements ofthe business use case are included here. These are requirements not covered by the flow as they have been described in the sections above.

1.6.1 ARMS Web Routes Invoices

Before an ADJUSTER receives an invoice to be approved, the ARMS Web system will look at the invoicing criteria for the owning office and owning adjuster and make a determination as to whether the invoice is auto approved or adjuster approved. If an invoice is auto approved, the invoice will always be assigned to a processor for payment without it ever being sent to an adjuster for approval.

1.6.2 Data Fields to Assist with Future Releases or Customer Integration

It must be possible to capture the following information at some point in the future because of either planned future releases or customer integration.

• Amount Being Paid on Each Invoice

1.6.3 Claim Number is Editable on the Invoice

If a company is set up for EDI transmission of invoices to the company's claim system, that company must have the ability to change the claim number on the invoice.

1.7 Extension Points

1.7.1 MA-19-View Customer File

The View Customer File Functional Specification is used to review the rental history in regards to a specific rental. Upon completion ofthe View Customer File Functional Specification, the ADJUSTER should be returned to step one of Section 1.4.2.1 , Individual Pay, or Section 1.4.2.2, Bulk Pay in the Handle Unapproved Invoices Functional Specification. Any previously approved invoices should still be approved in the system.

Confidential Enteφrise Rent-A-Car © 2000 httpΛintranet/dm2«t.eadDccOrLink.ASP?FolderID=2705&DocID=10509 ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00

Screen Design

A definition ofthe screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Invoicing - Individual Payment List

This screen will allow the user to enter a check number for each invoice and notify Enterprise that they have processed the payment.

Confidential Enterprise Rent-A-Car © 2000 http://intranet/dm2 ReadDocθr ink.ASP?FolderID=2705&DocID=l0509 ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00

Confidential Enteφrise Rent-A-Car © 2000 http-//intr_net/dm2/ReadDocOrLink.ASP?FolderID=2705&DocID= 10509 ARMS Redesign Project - Release 1.0 Issue: 1.0

Pay Approved Invoices Issue Date: 10/20/00

Confidential Enterprise Rent-A-Car © 2000 http://intranet dm2/ReadDocOrLink.ASP?FolderlD=2705&DocID=10509 ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00

2.1.2 Individual Payment List

Confidential Enteφrise Reπt-A-Car © 2000 httpJ/mtranet/dπι2/ReadDocθrLii- ASP?FolderID=2705&DocID=10509 ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.1.3.1 PRINTER FRIENDLY PAGE

When clicked, the user will be taken to the "Printer Friendly View" ofthe current invoice.

2.1.3.2 CONFIRM PAYMENT

When clicked, system will mark the reservation as paid and update the database. The update will be passed to the Arms system.

2.1.3.3 PAYLATER

When clicked, the user will be returned to their action item list and the payment list will remain unprocessed.

2.1.3.4 RETURN TO ADJUSTER

When clicked, the invoice will be returned to the last adjuster associated with the rental before it closed. The invoice will be removed from the list displayed.

2. .3.5 Top of Page

When clicked, the user will be taken to the top ofthe current invoice page.

Confidential Enteφrise Rent-A-Car © 2000 10 htt^p:^//intrane^t/dm2/ReadDocθrLink.ASP?FolderID=2705&DocID=10509 ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00

2.2 Bulk Payment List

This screen will allow the user to pick which functions that he/she may want to change.

2.2.1 Screen Layout - Bulk Payment List

Confidential Enterprise Rent-A-Car © 2000 1 1 http://intranet/dm2 eadDocθrLink.ASP?FolderIE⁾=2705&DocII>=10509 ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00

Invoicing - Bulk Payment List

Confidential Enterprise Rent-A-Car © 2000 12 http://intranet/dm2/ReadDocOrLink.ASP?FoIderID=2705&DocID=10S09 ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00

2.2.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.2.3.1 PRINTER FRIENDLY PAGE

When clicked, the user will be taken to the "Printer Friendly View" of the current invoice.

2.2.3.2 CONFIRM PAYMENT

When clicked, system will mark the reservation as paid and update the database. The update will be passed to the Arms system.

2.2.3.3 PAY LATER

When clicked, the user will be returned to their action item list and the payment list will remain unprocessed.

2.2.3.4 RETURN TO ADJUSTER

When clicked, the invoice will be returned to the last adjuster associated with the rental before it closed. The invoice will be removed from the list displayed.

2.2.3.5 Top of Page

When clicked, the user will be taken to the top ofthe current invoice page.

Confidential Enterprise Rent-A-Car © 2000 13 htψ://intr_net dm2/ReadDocOrLink.ASP?Folderir 2705&DoclD=l0509 ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00

2.3 Return Invoice to Adjuster

2.3.1 Screen Layout - returnBilling. shtml

Return Billing

Return Billing

You've chosen to return the following Invoice,

Adjuster's Name Renter's Name Claim Number Amount

Warner, Kurt Bamvakais,John 569873451 1271.14

Reason for return: Rental start date before date of loss

2.3.2 Return Billing

2.3.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.3.3.1 CANCEL

When clicked, the user will be returned to the Invoicing Approval or Invoicing Individual Payment screen from which they came. The invoice will still be displayed with the status ofthe invoice unchanged.

2.3.3.2 Return to Adjuster

When clicked, the user will return the invoice to the Adjuster for further instructions and the status will show returned invoice.

Confidential Enteφrise Rent-A-Car © ₂000 14 http://intr_net dm2 ReadDocOrLink.ASP?FolderID=2705&DocID=10509 ARMS Redesign Project - Release 1.0 Issue: 1.0

Pay Approved Invoices Issue Date: 10/20/00

3. Application Operations

This section will detail all the application operations that are part of this Functional Specification Document.

3.1 Get Approved Invoices (Office Id)

The get approved invoices operation finds all the approved invoices for the specified office.

3.2 Get Invoice Detail (Invoice Number)

The get invoice detail operation gets the relevant invoice information for the specified invoice number.

3.3 Return Invoice to Approving Adjuster (Invoice Number, Reason Code)

The return invoice to approving adjuster operation marks the specified invoice so that the approving adjuster can review the invoice and re-approve it.

3.4 Pay Invoice (Invoice Number, Check Number)

The pay invoice operation records the check number specified by the adjuster against the specified invoice and marks the invoice as paid.

Confidential Enterprise Rent-A-Car © 2000 15 hrtp://intⁱ-ⁱιetfdπι₂ ReadI⁾ocθrLink.ASP?Fold-rlD=2705&DocID=10509 ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00

4. Data Fields

4.1 Data Field Definition

This section includes a definition of all data fields included in the ftmctional specification

4.1.1 accounting name

Entity OFFDRB OFFICE DIRECTORY BRANCH MASTER

ColumnName acctg nam

Label Name Accounting Name

System Name

Data Type VARCHAR(8)

Attribute Definition |

4.1.2 action item complete date

Entity ACTION ITEM

Column Name actn_item_cmpl_dte

Label Name action item complete date:

System Name AITMCMPLDT

Data Type DATE

Attribute Definition The action item complete date is the date the action item was completed by an administrator or adjustor.

4.1.3 action item effective date

Entity ACTION ITEM

Column Name actn_item_eff_dte

Label Name action item effective date:

System Name AITMEFFDT

Data Type DATE

Attribute Definition The action item effective date is the date the action item will become effective.

4.1.4 action item status code

4.1.5 action item type code

Entity ACTION ITEM

ColumnName actn_item_typ_cde

Label Name action item type code:

System Name

Data Type DEC(3,0)

Attribute Definition The action item type code defines specific tasks/action items associated with the Rental Authorization Reservation activities accomplished by adjustors

Confidential Enterprise Rent-A-Car © 2000 16 http://intranet/dm2/ReadDocOr uι .ASP?FolderID=270S&DocID=10509 ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00 and administrators when contracting an insured with a replacement vehicle. For example: Closing an Of ___^_

4.1.6 action item type description

4.1.7 Address Line

4.18 Address Line2

4.1.9 ARMS Profile ID

4.1.10 assigned to adjustor code

Confidential Enteφrise Rent-A-Car © 2000 17 http:«ntranet dm2/ReadDocθr ink.ASP?FoIderID=2705&DocID=10509 ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00

4.1.11 assigned to company identifier

4.1.12 Bill To %

4.1.13 Branch

4.1.14 check number

4.1.15 City

4.1.16 claim type description

Confidential Enterprise Rent-A-Car © 2000 18 http://inttanet dm2/ReadDocOr ink.ASP?FolderID=2705&DocID=10509 ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00 which defines the different Authorization claim types. For example: Insured, Claimant, Uninsured Motorist, etc.

4.1.17 company identifier

4.1.18 company structure level code

4.1.19 Customer Transaction ID

4.1.20 Date Of Loss

4.1.21 Dollars Per Day Covered

Confidential Enteφrise Rent-A-Car © 2000 19 http://intranet/dm2/ReadDocOrLink.ASP?FolderID=2705&DocID=l0509 ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00

4.1.22 End Date

Entity ARM: Authorization(Claim Info)

Column Name AZENDT

Label Name End Date

System Name

Data Type NUMERIC(8)

Attribute Definition

Confidential Enteφrise Rent-A-Car © 2000 20 http://intranet dra2/ReadDocθrLink.ASP?FolderID=2705&DocID=l0509 ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00

4.1.27 First Name

Entity ARM: Renter Detail

ColumnName RKFSNM

Label Name First Name

System Name

Data Type CHAR(15)

Attribute Definition

4.1.28 Group

4.1.29 handled by adjustor code

4.130 handled by company identifier

4.1.31 handling for adjustor code

4.132 handling for company identifier

Confidential Enteφrise Rent-A-Car © 2000 21 http://intranetdm2 R-adDo-OrLink.ASP?FolderID=2705&DocID=10509 ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00

System Name HNDCMPYID

Data Type CHAR(5)

Attribute Definition The handling for company identifier is the company identifier used to uniquely identify an adjustor/user who is handling authorization activities for another adjustor/user in the ARMS Web application.

4.133 Insurance Claim Number

4.134 Insurance Claim Number

4.135 Invoice Number

4.136 Item Amount

4.137 Item Description

Confidential Enteφrise Rent-A-Car © 2000 22 ttp://intranet dm2 ReadDo-Or in .ASP?FolderID=2705&DocID=10509 ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00

4.138 Item Quantity

Entity A4 Invoice Detail

ColumnName I2ITQY

Label Name Item Quantity

System Name

Data Type DECIMAL(5)

Attribute Definition Z3

4.139 Item Rate

4.140 Last Name

4.1.41 Last Name

4.142 loss type description

4.143 Max $ Covered

Confidential Enteφrise Rent-A-Car © 2000 23 http:/intranet dm2/ReadDocOr in .ASP?FolderID=2705&DoclD=10509 ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00

Data Type DEdMAL(9,2)

Attribute Definition

4.144 NOTE

4.145 Record Add Date

4.1.46 related office identifier

4.147 Request Type

4.148 standard message description

Confidential Enteφrise Rent-A-Car © 2000 2₄ ttpΛintranet dm2/ReadDocOrLink.ASP?FolderID=₂705&DocID-10509 ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00

4.149 Start Date

Entity ARM: Authorization(Claim Info)

Column Name AZSTDT

Label Name Start Date

System Name

Data Type NUMERIC(8)

Attribute Definition

4.150 Sfafe

4.1.51 Status Code

4.1.52 Telephone Number

4.153 Ticket Number

Entity A4 Cross Reference

Column Name X4TKNO

Label Name Ticket Number

System Name

Data Type CHAR(6)

Attribute Definition

4.154 Total Amount Due

Entity A4 Invoice Trailer

Column Name I3BL$$

Label Nam- Total Amount Due

System Name

Data Type DECIMAL(9,2)

Attribute Definition

Confidential Enteφrise Rent-A-Car © ₂000 25 http://intranet/dm2/ eadDocOrLink. ASP?FolderID=2705&DocID= 10509 ARMS Redesign Project - Release 1.0 Issue: 1.0 Pay Approved Invoices Issue Date: 10/20/00

4.155 Total Amount Received

4.156 Total Billed to Others

4.1.57 Total Ticket Charges

4.158 Zip Code

Confidential Enteφrise Rent-A-Car © 2000 26 http://intranet dm2 eadDocθrLink.ASP?FolderID=2705&DocID=10509 ARMS Redesign Project - Release 1.0 Issue: 1.0

Pay Approved Invoices Issue Date: 10/20/00

5. Questions and Answers

None.

Confidential Enteφrise Rent-A-Car © 2000 27 http-//intranet/dm2/ReadDocOrLink.ASP''FolderID=2705&DocID=10S09 Enterprise Rent-A-Car

Functional Design Specification

Reject an Invoice

Version 1.0

Last Saved: 6/29/00 9:35 AlVI

ARMS Redesign Project - Release 1.0 Issue: 1.0 Reject an Invoice Issue Date: 10/20/00

Revision History

Confidential Enterprise Rent-A-Car © 2000 http.//intranet/dm2 ReadDocOrLin .ASP?FolderID=2705&DocID=10510 ARMS Redesign Project - Release 1.0 Issue: 1.0

Reject an Invoice Issue Date: 10/20/00

Table of Contents Reject an Invoice

1. Reject An Invoice Use Case

1.1 Brief Description

1.2 Use Case Actors

1.3 Pre-Conditions

1.4 Flow of Events

1.4.1 Activity Diagram 2

1.4.2 Basic Flow 3

1.4.3 Alternative Flows 3

1.5 Post-Conditions 3

1.6 Special Requirements 3 1.6.1 Invoices are Initially Auto Approved 3

1.7 Extension Points 3

2. Screen Design 4

2.1 Reject Billing Reason 4

2.1.1 Screen Layout - Reject Billing Reason 4

2.1.2 Reject Billing - Reject Billing Reason 4

2.1.3 Screen Function Definition 4

2.2 Reject Billing Amount 6

2.2.1 Screen Layou - Reject Billing Amount 6

2.2.2 Reject Billing - Reject Billing Amount 6

2.2.3 Screen Function Defmition 7

3. Application Operations 8

3.1 Get Invoice Rejection Reasons (Company Id) 8

3.2 Reject Invoice (Invoice Number) 8

4. D Daattaa FFiieellddss 9

4.1 Data Field Definition 9

4.1.1 accounting name 9

4.1.2 Address Line 9

4.1.3 Address Line2 9

4.1.4 City 9

4.1.5 external organization abbreviated name 9

4.1.6 First Name 10

4.1.7 First Name 10

4.1.8 Insurance Claim Number 10

4.1.9 Last Name 10

4.1.10 Last Name 10

4.1.11 standard message description 10

4.1.12 State 11

4.1.13 Telephone Number 11

4.1.14 Total Amount Due 11

4.1.15 Zip Code 11

Confidential Enterprise Rent-A-Car © 2000 http://intr-net/dm2/ReadDooOrLink.ASP?FoldβrID=2705&DocID= 10510 ARMS Redesign Project - Release 1.0 Issue: 1.0

Reject an Invoice Issue Date: 10/20/00

1. Reject An Invoice Use Case

1.1 Brief Description

The Reject an Invoice use case describes how the ADJUSTER would reject an invoice to Enterprise in the ARMS Web system.

1.2 Use Case Actors

The following actors will interact with this use case:

• ADJUSTER - The ADJUSTER will use this use case to reject an invoice.

1.3 Pre-Conditions

• The ADJUSTER'S office must be set up for individual approval of invoices.

• The ADJUSTER must be set up to approve invoices.

1.4 Flow of Events

The Flow of Events will include the necessary steps for an ADJUSTER to reject invoices.

Confidential Enterprise Rent-A-Car © 2000 http://intranet/d 2 ReadDocOrLmk.ASP?FolderID=2705&DocID-10510 ARMS Redesign Project - Release 1.0 Issue: 1.0 Reject an Invoice Issue Date: 10/20/00

1.4.1 Activity Diagram

Reject an Invoice Activity Diagram

\\FSCORP00\CORP_PUBLIC\APPS\#ARMSWEB\APPLICATION\@DKB\AR S WEB\RELEASE

ONBBI-BILLING AND INVOICING\BI-03-REJECT AN INVOICE\ACTBI-03-ACTIVITY

DIAGRAM.VSD 6/20/00

Confidential Enterprise Rent-A-Car © 2000 http://intranet d 2/ReadDooOrLink.ASP?FolderID-2705&DocII '10510 ARMS Redesign Project - Release 1.0 Issue: 1.0

Reject an Invoice Issue Date: 10/20/00

1.4.2 Basic Flow

1. The ADJUSTER will reject an invoice.

2. The system will prompt for reject confirmation.

3. The ADJUSTER will enter a reject reason for rejecting the invoice.

4. The ADJUSTER may enter comments to be added to the diary notes.

5. The ADJUSTER will submit the rejection to the system.

6. The system will display instructions for achieving resolution on the rejected invoice.

7. The ADJUSTER will acknowledge that they understand the instructions.

8. The system will update the ARMS Web database to reflect that the ADJUSTER rejected the invoice.

9. This ends the use case.

1.4.3 Alternative Flows

1.4.3.1 Cancel Rejection

At steps two through seven ofthe Basic Flow, the ADJUSTER must have the ability to cancel the invoice rejection process. Canceling the rejection should return the ADJUSTER to the Invoicing Approval Screen or the Invoicing Individual Payment screen. The invoice that was to be rejected should be displayed. The status ofthe invoice should be unapproved.

1.4.3.2 No Reject Reason Given

At step three in the Basic Flow; if the ADJUSTER attempts to bypass entering a reject reason, they will be prompted to enter one. The ADJUSTER will not be allowed to complete the rejection process without providing a reject reason.

1.4.3.3 Short Pay

If the reject reason given in step three ofthe Basic Flow is a reason that requires a short pay, at step five ofthe Basic Flow the system will display a field for entry of the short pay amount. The ADJUSTER will not be allowed to complete the rejection process without providing an amount that will be paid.

1.5 Post-Conditions

• If the use case was successful the invoice will be marked rejected in the ARMS Web system.

• If the use case was unsuccessful, the status remains unchanged.

1.6 Special Requirements

The additional requirements ofthe business use case are included here. These are requirements not covered by the flow as they have been described in the sections above.

1.6.1 Invoices are Initially Auto Approved

If an ADJUSTER'S invoices are normally auto approved, functionality needs to exist to route invoices to them when they are returned to ADJUSTER from the PROCESSOR. This functionality will need to override the normal routing processes that exist at the office.

1.7 Extension Points

None.

Confidential Enteφrise Rent-A-Car © 2000 ttp://intranet/dm2/RcadDocOrLink.ASP?FoldcrID-2705&DocID=10510 ARMS Redesign Project - Release 1.0 Issue: 1.0 Reject an Invoice Issue Date: 10/20/00

Screen Design

A definition ofthe screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Reject Billing Reason

This screen will allow the user to begin the rejection process.

2.1.1 Screen Layout - Reject Billing Reason

2.1.2 Reject Billing - Reject Billing Reason

Screen Label Tvpe Si/e Screen Ki Data Held

Amount Output 10 Total Amount Due CALCULATED

Claim Output 15 Claim Number Insurance Claim Number Number

Adjuster's Output 30 Adjuster's Name First Name + Last Name of adjuster's to which the invoice Name Name is assigned

Comments Input 50 Message Text NOTE

Renter's Output 30 Renter's name First Name + Last Renter's Last Name + Renter's First Name Name Name

Reason for List Box 20 Rejection Reasons standard message Rejection description

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

Confidential Enterprise Rent-A-Car © 2000 http://intranet dm2/ReadDocOrLink.ASP''Folderir>=2705&DocID= 10510 ARMS Redesign Project - Release 1.0 Issue: 1.0

Reject an Invoice Issue Date: 10/20/00

2.1.3.1 CONTINUE

The system will validate the input from the screen according to the listed business rules. If the validation passes, the rejection process will continue.

The following business rules that must be passed before the USER may continue to the next step in the rejection process are the following:

■ A valid rejection reason must be selected from the drop down box

■ If the rejection reason selected is "Other" a comment must be entered

2.1.3.2 CANCEL

When clicked, the user will be returned to the Invoicing Approval or Invoicing Individual Payment screen. The invoice will still be displayed with the status ofthe invoice unchanged.

Confidential Enterprise Rent-A-Car © 2000 http-'/intranet/dnι2/ReadDocOrLinI_ASP?FolderID=2705&DocID=10510 ARMS Redesign Project - Release 1.0 Issue: 1.0 Reject an Invoice Issue Date: 10/20/00

2.2 Reject Billing Amount

2.2.1 Screen Layout - Reject Billing Amount

2.2.2 Reject Billing - Reject Billing Amount

Confidential Enteφrise Rent-A-Car © 2000 http://intranet/dm2/ReadDocθr mk.ASP?FoWerID=2705&DocID=10510 ARMS Redesign Project - Release 1.0 Issue: 1.0 Reject an Invoice Issue Date: 10/20/00

2.2.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.2.3.1 REJECT INVOICE

The system will validate the input from the screen. If the validation passes, the invoice will be marked as rejected and the Arms Web database will be updated. If an amount was entered in the "Amount you are paying" field, then the invoice should be marked short paid.

2.2.3.2 CANCEL

When clicked, the user will be returned to the Invoicing Approval or Invoicing Individual Payment screen. The invoice will still be displayed with the status ofthe invoice unchanged.

Confidential Enteφrise Rent-A-Car © 2000 http://intranet ra2/ReadDocOrLink.ASP?Fol erID=2705&DocID=10510 ARMS Redesign Project - Release 1.0 Issue: 1.0

Reject an Invoice Issue Date: 10/20/00

3. Application Operations

This section will detail all the application operations that are part of this Functional Specification Document.

3.1 Get Invoice Rejection Reasons (Company Id)

The get invoice rejection reasons gets the predefined rejection reasons for the company.

3.2 Reject Invoice (Invoice Number)

The reject invoice operation marks the specified invoice as rejected. The rejected invoice becomes an action item for the adjuster to handle.

Confidential Enteφrise Rent-A-Car © 2000 ^ht^tp-/ⁱntrane^t/dm2^/ReadDocOrLink.ASP?FolderID=2705&Docπ>=10510 ARMS Redesign Project - Release 1.0 Issue: 1.0 Reject an Invoice Issue Date: 10/20/00

4. Data Fields

4.1 Data Field Definition

This section includes a defmition of all data fields included in the functional specification

4.1.1 accounting name

Confidential Enteφrise Rent-A-Car © 2000 http://intranet/d 2 ReadDooOrLink.ASP?FolderID=2705&DoclD=10510

4.1.9 Last Name

4.1.10 Last Name

4.1.11 standard message description

ifidential Enterprise Rent-A-Car © 2000 10

//inttanetfdm2/ReadDocOrLink.ASP?FolderID=₂705&DoclD=10510 ARMS Redesign Project - Release 1.0 Issue: 1.0 Reject an Invoice Issue Date: 10/20/00

4.1.6 First Name

Entity ARM: Adjustor Master

Column Name ALFSNM

Label Name First Name

System Name

Data Type CHAR(15)

Attribute Definition

4.1.7 First Name

Entity ARM: Renter Detail

Column Name RKFSNM

Label Name First Name

System Name

Data Type CHAR(15)

Attribute Definition

4.1.8 Insurance Claim Number

4.7.9 Last Name

4.1.10 Last Name

4. standard message description

Confidential Enterprise Rent-A-Car © 2000 10 http://intranet dm_ ReadDocθrLink.ASP?Fo!derID=2705&DocID=l 0510 901

ARMS Redesign Project - Release 1.0 Issue: 1.0 Reject an Invoice Issue Date: 10/20/00 activity type codes. For example: "Authorization confirmed on &Date with Reservation Number &Resnumber"

4.7.72 State

Confidential Enterprise Rent-A-Car © 2000 11 http://intranet/dm₂/ReadDocθrLink.ASP?FolderID=₂705&DocII =10510 Enterprise Rent-A-Car

Functional Design Specification

Callbacks

Version 1.1

Last Saved: 8/17/00 3:12 PM

ARMS Redesign Project - Release 2.0 Issue: 1.1 Callbacks Issue Date: 8/18/2000

Revision Histor

Confidential Enteφrise Rent-A-Car © 2000 httpΛintranet dm2/ eadDo θrLinl_ASP?FolderID=2732&DoclD=976 ARMS Redesign Project - Release 2.0 Issue: 1.1

Callbacks Issue Date: 8/18/2000

Callbacks

1. Callbacks

1.1 Brief Description

This use case describes the process that will perform repair facility callbacks in the ARMS Web system. USERs perform repair facility callbacks on each ofthe rental contracts that are set to expire in the near future (or have already expired), to proactively determine if rentals must be extended due to slippage in repair facility time estimates. The callback process in the ARMS Web system will retrieve each of the rental contracts that will expire in the user-defined period of time, and organize them by repair facility to allow the USER to make one phone call to inquire about the potentially multiple vehicles that the repair facility is responsible for.

1.2 Use Case Actors

AU actors will use the use case to retrieve callback lists in the ARMS Web system. All ofthe following actors can be defined generically as a USER:

• PROCESSOR

• ADJUSTER

• COMPANY MANAGER

For the balance of this use case, all ofthe above actors will be referred to as USER.

1.3 Pre-Conditions

• The USER must be signed-on to the system.

1.4 Flow of Events

The Flow of Events includes all the steps necessary to retrieve and manage callbacks in the ARMS Web system.

Confidential Enterprise Rent-A-Car © 2000 httpy/mtr_net/dm2 ReadDocOτLιnk.ASP?FolderID=2732&DoclD=9764

1.4.1 Activity Diagram

1.4.2 Basic Flow

The Basic Flow ofthe Callbacks use case includes all ofthe required activities for the USER to successfully generate and perform repair facility callbacks in the ARMS Web system.

1. The USER selects to perform callbacks from the reporting menu of top navigation.

2. The system generates a report of all open authorizations for the selected office that will expire the next day (have a last authorized day of tomorrow). This list will include any authorizations that have already expired, or will expire by the end of business on the following day.

Confidential Enterprise Rent-A-Car © 2000 ttp-Λιntranet dm2/ReadDocθr inl ΛSP?FolderII =2732&Docll 97-4 ARMS Redesign Project - Release 2.0 Issue: 1.1

Callbacks Issue Date: 8/18/2000

3. The system displays a summary of repair facilities that have rentals expiring in the specified timeframe. The repair facility callback summary must consist of:

• Repair Facility Name

• Repair Facility Telephone Number

• Number of Rental callbacks due to the Repair Facility

4. The USER selects one or more repair facilities from the repair facility callback summary.

5. The system displays a summary ofthe open authorizations that are set to expire for all selected repair facilities. The open authorization callback summary will consist of:

• Renter Name

• Year/Make/Model of the Renter's Vehicle

• Driveable Flag (y/n)

• Number of Day s Behind

• Authorized Days

• Last Authorized Day

6. The USER will select a customer file from the list.

7. The USER will extend into use case MA-12 Extend Authorization. The USER will have the ability to extend, add notes, terminate or modify an authorization as proscribed in the MA-12 Extend Authorization use case. If callbacks still exist, the USER will be returned to Step 5 ofthe Basic Flow on completion ofthe MA-12 Extend Authorization use case.

If all callbacks have been completed, the Basic Flow continues.

8. The system will display a screen to indicate that all repair facility callbacks for the office have been completed.

9. This ends this use case.

1.4.3 Alternative Flows

The Alternative Flows of this use case can occur when certain conditions exist or when specific USER feedback is provided.

1.4.3.1 Change Last Authorized Date

At Step 3 or Step 5 ofthe Basic Flow, the USER has the ability to change the last authorized day to any day in the future. The system will re-generate the callbacks list and the USER will be returned to Step 2 ofthe Basic Flow on submission ofthe new last authorized day.

1.4.3.2 Last Authorized Date Entered Invalid

In the Change Last Authorized Date Alternative Flow, if the last authorized date entered by the USER is invalid, the system will return to the beginning ofthe Change Last Authorized Date Alternative Flow and provide the USER with an error message.

1.4.3.2.1 It will be considered invalid if the last authorized date entered is less than the current date.

1.5 Post-Conditions

• If successful, a callback list is created for the USER.

Confidential Enterprise Rent-A-Car © 2000 htφΛmtranet/dm2/ReadDocθrLin .ASP?Fol(lerIE)=2732&Do II 9764 ARMS Redesign Project - Release 2.0 Issue: 1.1

Callbacks Issue Date: 8/18/2000

• If unsuccessful, the system state remains unchanged.

1.6 Special Requirements

None.

1.7 Extension Points

1.7.1 MA-12 Extend Authorization

At Step 7 ofthe Basic Flow, the USER will extend from the use case to the MA-12 Extend Authorization use case. This will allow the USER to update the open authorization with the results ofthe repair facility callback (e.g., extend, add notes, or terminate the rental authorization). On completion ofthe MA-12 Extend Authorization use case, the rules specified within the Basic Flow should be followed as to the next step in the process.

Confidential Enterprise Rent-A-Car © 2000 http-J/intr-net dⁱn2/ReadDcⁱcOrLii-cASP?FolderID=2732&Docir⁾=976 ARMS Redesign Project - Release 2.0 Issue: 1.1 Callbacks Issue Date: 8/18/2000

Screen Design

A definition ofthe screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Repair Facility Callback Summary

This screen provides the USER with a repair facility callback summary, and supports Step 3 ofthe Basic Flow.

2.1.1 Screen Layout

Confidential Enterprise Rent-A-Car © 2000 http://intranet dm2/ReadI>xΛrLiιΛΛSP?FoωerlI 273₂&Docir '976₄ Enterprise Rent-A-Car

Functional Design Specification

Reject an Invoice

Version 1.0

Last Saved: 6/29/00 9:35 AM

ARMS Redesign Project - Release 1.0 Issue: LO Reject an Invoice Issue Date: 10/20/00

Revision History

Confidential Enterprise Rent-A-Car © 2000 httprfintmet dm2/ReadDocOr ink.ASP?FolderlD=270S&DocU 10S10

Table of Contents Reject an Invoice

1. Reject An Invoice Use Case

1.1 Brief Description

1.2 Use Case Actors

1.3 Pre-Conditions

1.4 Flow of Events

1.4.1 Activity Diagram 2

1.4.2 Basic Flow 3

1.4.3 Alternative Flows 3

1.5 Post-Conditions 3

1.6 Special Requirements 3

1.6.1 Invoices are Initially Auto Approved 3

1.7 Extension Points 3

2. SSccrreeeenn DDeessiiggnn 4

2.1 Reject Billing Reason 4

2.1.1 Screen Layout - Reject Billing Reason 4

2.1.2 Reject Billing - Reject Billing Reason 4

2.1.3 Screen Function Definition 4

2.2 Reject Billing Amount 6

2.2.1 Screen Layout - Reject Billing Amount 6

2.2.2 Reject Billing - Reject Billing Amount 6

2.2.3 Screen Function Definition 7

3. Application Operations 8

3.1 Get Invoice Rejection Reasons (Company Id) 8

3.2 Reject Invoice (Invoice Number) 8

I. Data Fields 9

4.1 Data Field Definition 9

4.1.1 accounting name 9

4.1.2 Address Line 9

4.1.3 Address Line2 9

4.1.4 City 9

4.1.5 external organization abbreviated name 9

4.1.6 First Name 10

4.1.7 First Name 10

4.1.8 Insurance Claim Number 10

4.1.9 Last Name 10

4.1.10 Last Name 10

4.1.11 standard message description 10

4.1.12 State 11

4.1.13 Telephone Number 11

4.1.14 Total Amount Due 11

4.1.15 Zip Code 11

Confidential Enterprise Rent-A-Car © 2000 httpΛintranet'dm2/ReadDocθιi.inl .ASP?Fo]dBrn>=2705&Doc]D=]0510 ARMS Redesign Project - Release 1.0 Issue: 1.0

Reject an Invoice Issue Date: 10/20/00

1. Reject An Invoice Use Case

1.1 Brief Description

The Reject an Invoice use case describes how the ADJUSTER would reject an invoice to Enterprise in the ARMS Web system.

1.2 Use Case Actors

The following actors will interact with this use case:

• ADJUSTER - The ADJUSTER will use this use case to reject an invoice.

1.3 Pre-Conditions

• The ADJUSTER'S office must be set up for individual approval of invoices.

• The ADJUSTER must be set up to approve invoices.

1.4 Flow of Events

The Flow of Events will include the necessary steps for an ADJUSTER to reject invoices.

Confidential Enteiprise Rent-A-Car © 2000 htφ://intraιιet/dm2/Rea DcιcθrUnl .SP?Fol erlD=2705&DocII 10S10 ARMS Redesign Project - Release 1.0 Issue: 1.0 Reject an Invoice Issue Date: 10/20/00

1.4.1 Activity Diagram

Reject an Invoice Activity Diagram

\\FSCORP00\CORP_PUBLIC*APPSW₁RMSWEB\APPUCATION\@DKB\AR S EB\RELEASE

ONBBI-BILLING AND INWICING\BI-03-REJECT AN INVOICE ACTBI-03-ACTIVITY

DIAGRAM.VSD 6/20/00

Confidential Enteφrise Rent-A-Car © 2000 httpΛiιvtomet dm2/ReadDocOr in!_ASP?FolilertI 2705&I⁾ocl- =10510 , „ _B 02/067175

914

ARMS Redesign Project - Release 1.0 Issue: 1.0

Reject an Invoice Issue Date: 10/20/00

1.4.2 Basic Flow

1. The ADJUSTER will reject an invoice.

2. The system will prompt for reject confirmation.

3. The ADJUSTER will enter a reject reason for rejecting the invoice.

4. The ADJUSTER may enter comments to be added to the diary notes.

5. The ADJUSTER will submit the rejection to the system.

6. The system will display instructions for achieving resolution on the rejected invoice.

7. The ADJUSTER will acknowledge that they understand the instructions.

8. The system will update the ARMS Web database to reflect that the ADJUSTER rejected the invoice.

9. This ends the use case.

7.4.3 Alternative Flows

1.4.3.1 Cancel Rejection

At steps two through seven ofthe Basic Flow, the ADJUSTER must have the ability to cancel the invoice rejection process. Canceling the rejection should return the ADJUSTER to the Invoicing Approval Screen or the Invoicing Individual Payment screen. The invoice that was to be rejected should be displayed. The status of the invoice should be unapproved.

1.4.3.2 No Reject Reason Given

At step three in the Basic Flow; if the ADJUSTER attempts to bypass entering a reject reason, they will be prompted to enter one. The ADJUSTER will not be allowed to complete the rejection process without providing a reject reason.

1.4.3.3 Short Pay

If the reject reason given in step three ofthe Basic Flow is a reason that requires a short pay, at step five ofthe Basic Flow the system will display a field for entry of the short pay amount The ADJUSTER will not be allowed to complete the rejection process without providing an amount that will be paid.

1.5 Post-Conditions

• If the use case was successful the invoice will be marked rejected in the ARMS Web system.

• If the use case was unsuccessful, the status remains unchanged.

1.6 Special Requirements

The additional requirements ofthe business use case are included here. These are requirements not covered by the flow as they have been described in the sections above.

1.6.1 Invoices are Initially Auto Approved

If an ADJUSTER'S invoices are normally auto approved, functionality needs to exist to route invoices to them when they are returned to ADJUSTER from the PROCESSOR. This functionality will need to override the normal routing processes that exist at the office.

1.7 Extension Points

None.

Confidential Enterprise Rent-A-Car © 2000 http^/intranet dnι2 ReadD<κOrLinl_ASP?FolderII)=2705&Docir 10510 ARMS Redesign Project - Release 1.0 Issue: 1.0 Reject an Invoice Issue Date: 10/20/00

Screen Design

A definition ofthe screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Reject Billing Reason

This screen will allow the user to begin the rejection process.

2.1.1 Screen Layout - Reject Billing Reason

2.1.2 Reject Billing - Reject Billing Reason

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be perfoπned within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

Confidential Enterprise Rent-A-Car © ₂000 http^/intranet dm2/Rca DMOr in .ASP?FolderID=2705&DcK:ID=10510 ARMS Redesign Project - Release 1.0 Issue: 1.0

Reject an Invoice Issue Date: 1020/00

2.1.3.1 CONTINUE

The system will validate the input from the screen according to the listed business rules. If the validation passes, the rejection process will continue.

The following business rules that must be passed before the USER may continue to the next step in the rejection process are the following:

■ A valid rejection reason must be selected from the drop down box

■ If the rejection reason selected is "Other" a comment must be entered

2.1.3.2 CANCEL

When clicked, the user will be returned to the Invoicing Approval or Invoicing Individual Payment screen. The invoice will still be displayed with the status ofthe invoice unchanged.

Confidential Enterprise Rent-A-Car © ₂000 htψΛintranet/dm2/ReadDocOrLin .ASP?FolderlD=2705&DocID=10510 ARMS Redesign Project - Release 1.0 Issue: 1.0 Reject an Invoice _____ Issue Date: 10/20/00

2.2 Reject Billing Amount

2.2.1 Screen Layout - Reject Billing Amount

2.2.2 Reject Billing - Reject Billing Amount

Confidential Enterprise Rent-A-Car © 2000 httpΛintranet/dm2 ReadDocθrLinI_ASP?FoldcrI_)=2705&DocID=10510 ARMS Redesign Project - Release 1.0 Issue: 1.0 Reject an Invoice Issue Date: 10/20/00

2.2.3 Screen Function Definition

This section includes the definitions for all functions that can be perfoπned within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.2.3.1 REJECT INVOICE

The system will validate the input from the screen. If the validation passes, the invoice will be marked as rejected and the Arms Web database will be updated. If an amount was entered in the "Amount you are paying" field, then the invoice should be marked short paid.

2.2.3.2 CANCEL

When clicked, the user will be returned to the Invoicing Approval or Invoicing Individual Payment screen. The invoice will still be displayed with the status ofthe invoice unchanged.

Confidential Enterprise Rent-A-Car © 2000 http-'/intr-_ιet/dm2/ReadI κ<⁾rLinl_ASP?FolderII 270-&DoclD-10-10 ARMS Redesign Project - Release 1.0 Issue: 1.0

Reject an Invoice Issue Date: 10/20/00

3. Application Operations

This section will detail all the application operations that are part of this Functional Specification Document.

3.1 Get Invoice Rejection Reasons (Company Id)

The get invoice rejection reasons gets the predefined rejection reasons for the company.

3.2 Reject Invoice (Invoice Number)

The reject invoice operation marks the specified invoice as rejected. The rejected invoice becomes an action item for the adjuster to handle.

Confidential Enteφrise Rent-A-Car © 2000 httpΛintranet/dm2/ReadDocOrUnk.ASP?FolderII--2705&DoclI =10510 02/067175

920

ARMS Redesign Project - Release 1.0 Issue: 1.0 Reject an Invoice Issue Date: 10/20/00

4. Data Fields

4.1 Data Field Definition

This section includes a definition of all data fields included in the functional specification

4.1.1 accounting name

4.1.2 Address Line

4.1.3 Address Line2

4.1.4 City

4.1.5 external organization abbreviated name

Confidential Enterprise Rent-A-Car © 2000 http://intr-net/dιi-_'R---I3-«!θrUnk.ASP?Folderll>=2705&Docπ>-10510 02/067175

921

ARMS Redesign Project - Release 1.0 Issue: 1.0 Reject an Invoice ___^_____ Issue Date: 10/20/00

4.1.6 First Name

Entity ARM: Adjustor Master

Column Name ALFSNM

Label Name First Name

System Name

Data Type CHAR(15)

Attribute Definition

4.1.7 First Name

4.1.8 Insurance Claim Number

4.1.9 Last Name

.4.1.10 Last Name

Entity ARM: Renter Detail

Column Name RKLSNM

Label Name Last Name

System Name

Data Type CHAR(20)

Attribute Definition

4.1.11 standard message description

Entity STANDARD MESSAGE

Column Name std msg dsc

Label Name standard message description:

System Name STDMSGDSC

Data Type CHAR(50)

Attribute Definition The standard message description is a lexical definition for standard message code which defines a predefined message which is applicable to specific

Confidential Enterprise Rent-A-Car © 2000 10 http^/intrane^dni2/ReadDccOrlinI_ASP?FoldcrII =2705-.Do-II>=l 0510 02 0

922

ARMS Redesign Project - Release 1.0 Issue: 1.0 Reject an Invoice Issue Date: 10/20/00 activity type codes. For example: "Authorization confirmed on &Date with Reservation Number &Resnumber"

4.1.12 State

4.1.13 Telephone Number

4.1.14 Total Amount Due

4.1.15 Zip Code

Confidential Enterprise Rent-A-Car © 2000 11 httpΛintraι«st/(im2 ReadD_cOrUnltASP?FoIderlD=270S«a⁾ocID=10S10 Enterprise Rent-A-Car

Functional Design Specification Generate Personal Report

Version 1.11

Last Saved: 8716700 3:01 PM

ARMS Redesign Project - Release 2.0 Issue: 1.11 Generate Personal Report Issue Date: 8/16/2000

Revision History

Confidential Enterprise Rent-A-Car © 2000 httprf tι™e-'(-m_«e-dDo! )rUι*ASP?FolderID-2732-a)ocID» 655 ARMS Redesign Project - Release 2.0 Issue: 1.11

Generate Personal Report Issue Date: 8/16/2000

Table of Contents

1. Generate Personal Report

1.1 Brief Description

1.2 Use Case Actors

1.3 Pre-Conditions

1.4 Flow of Events

1.4.1 Activity Diagram 2

1.4.2 Basic Flow 3

1.4.3 Alternative Flows 3

1.5 Post-Conditions 4

1.6 Special Requirements 5

1.6.1 Open Ticket Detail View 5

1.6.2 Closed Ticket Detail View 6

1.6.3 Custom Report Views 6

1.6.4 Report View Management 6

1.7 Extension Points 7

1.7.1 MA-13 Change Authorization 7

1.7.2 RP-03 Add/Edit Custom View 7

2. Screen Design 8

2.1 Personal Report Template Screen 8

2.1.1 Screen Layout 8

2.1.2 Screen Field Definition 8

2.1.3 Screen Function Definition 1

Confidential Enterprise Rent-A-Car © 2000 httpΛintι_neb'dm2/ReadIXx<⁾rUn .ASP?FolderID=2732&D-clϊ 9655 ARMS Redesign Project - Release 2.0 Issue: 1.11

Generate Personal Report Issue Date: 8/16/2000

Generate Personal Report

1. Generate Personal Report

1.1 Brief Description

This use case describes how a USER would generate a report on their personal rental management activity. Personal reports allow the USER access to reporting on only their own rental management activity, which allows the USER to review their own performance and secures access to the rental management reports of others.

1.2 Use Case Actors

All actors will use the use case to generate personal reports in the ARMS Web system. All ofthe following actors can be defined generically as a USER:

• ADJUSTER

• PROCESSOR

• COMPANY MANAGER

For the balance of this use case, all ofthe above actors will be referred to as USER.

1.3 Pre-Conditions

• The USER must be signed-on to the system.

1.4 Flow of Events

The Flow of Events includes all the steps necessary to generate personal reports in the ARMS Web system.

Confidential Enterprise Rent-A-Car © 2000 httpΛintπm-t/dra2/ReadDocOrLinkΛSP?FoIderlI>=2732&Docπ>=9655 ARMS Redesign Project - Release 2.0 Issue: 1.11 Generate Personal Report Issue Date: 8/16/2000

1.4.1 Activity Diagram

Generate Personal Report Activity Diagram

Confidential Enterprise Rent-A-Car © 2000 httpΛinn-iιet/dm2/ReadDo<ΛrUnk^SP?FD^]derID=2732&Dc !lI = 655 ARMS Redesign Project - Release 2.0 Issue: 1.11

Generate Personal Report Issue Date: 8/16/2000

1.4.2 Basic Flow .

The Basic Flow ofthe Generate Personal Report use case includes all ofthe required activities for the USER to successfully generate and view a standard personal report in ARMS Web.

1. The USER selects to generate a personal report from the top navigation bar.

2. The system generates the report for the specific USER. The report should provide rental management reports for the signed-in USER. The default report view to display to the USER will be the Open Ticket Detail view (see section 1.6.1 of he Special Requirements section on page 5 for further definition).

3. The system displays the report to the USER.

4. This ends this use case.

1.4.3 Alternative Flows

The Alternative Flows of this use case can occur when certain conditions exist or when specific USER feedback is provided. The Alternative Flows are optional and only occur if the conditions specified are met.

14.3.1 Change Report View

At Step 3 ofthe Basic Flow, the USER will have the ability to change the report 'view". Report 'views' change the type of information that is presented to the USER, but maintains the same or similar scope. For example, the USER can select to change to a closed ticket detail view from the open ticket detail view, but the information presented is limited (scoped) to the rental management activity ofthe USER.

If the USER selects to change the report view, the system will return to Step 2 ofthe Basic Flow and re-generate the report to build the requested view.

1.4.3.2 Change Closed Ticket Date Range

At Step 3 ofthe Basic Flow, if the current report view is a closed ticket report, the USER will have the ability to change the date range ofthe report. The available date range for closed ticket reporting will be a rolling 13-month period (to be expanded to 24-months in fiiture releases) with the current month inclusive. The default date range that will be presented to the USER will be the current and previous two (2) months. The USER will have the ability to select Month/Year to begin and end the date range for the closed ticket report. The USER will not have the ability to select specific days within a month as part ofthe date range.

If the USER selects a new date range for the closed ticket report view, the system will return to Step 2 ofthe Basic Flow and re-generate the report to build the USERs closed ticket report for the selected date range.

1.4.3.3 Select Open Ticket from Open Ticket Detail Report

At Step 3 ofthe Basic Flow, if the current report view is an open ticket detail report, the USER will have the ability to select a report line item to view the details ofthe open ticket customer file. When selected, the system will present the USER with the customer file that corresponds to the selected open ticket. The USER will be allowed to modify and submit changes to the customer file (as proscribed in use case MA-13 Change Authorization). Once activity on the customer file is complete, the USER should be returned to the open ticket detail report (Step 3 of he Basic Flow).

¹ Report views are covered in more detail in Section 1.6 Special Requirements.

Confidential Enterprise Rent-A-Car © 2000 http /intranetdm2«eadDm;Or inl .ASP?FolderID=2732&DoclI = 6S5 ARMS Redesign Project - Release 2.0 I_ssue: i.n

Generate Personal Report Issue Date: 8/16/2000

1.4.3.4 Select Closed Ticket from Closed Ticket Detail Report

At Step 3 ofthe Basic Flow, if the current report view is a closed ticket detail report, the USER will have the ability to select a report line item to view the details ofthe closed ticket customer file. When selected, the system will present the USER with the closed customer file that corresponds to the selected closed ticket. The USER will be allowed to view/print the details of the closed ticket, but will not have the ability to modify or change the ticket information. From the closed customer file, the USER will be returned to the closed ticket detail report (Step 3 ofthe Basic Flow).

14.3.5 Sort Report

At Step 3 ofthe Basic Flow, the USER will have the ability to select any report column heading to have the report sorted by the selected column. If the USER selects a column heading, the system must sort the report by the selected column heading in ascending order. The USER will have the ability to toggle between ascending and descending sort order by re-selecting the currently sorted column. For example, if the USER wanted their report view to be sorted by Renter Name, clicking on the column would cause the report view to be sorted ascending by renter last name. If the USER would like to reverse the sort order to descending, selecting the column heading again would allow the report to be resorted descending by renter last name.

The system will return the USER to Step 3 ofthe Basic Flow on completion of this Alternative Flow, with the report view resorted according to the USER request.

1.4.3.6 Add/Edit Custom View

At Step 3 of he Basic Flow, the USER will have the ability to add or edit a custom report view. If the USER selects to add a report view, the system will extend to the RP-03 Add/Edit Custom View use case to define a new custom report layout.

If the USER is viewing a custom report, they will have the ability to edit the custom view by selecting an 'edit' option. When a user requests to edit a custom report layout, the system will extend to the RP-03 Add/Edit Custom View use case and pre-fill all corresponding fields with the currently selected parameters for the custom layout.

On completion ofthe use case extension, the USER will be returned to Step 2 of Basic Flow in this use case and be presented with the custom report layout that was defined/modified.

14.3.7 Select Download Report

At Step 3 ofthe Basic Flow, the USER will have the ability to download the current report view to a comma-delimited file. If the USER selects to download a comma-delimited version ofthe report, the system must publish a comma-delimited file that includes all ofthe data within the columns ofthe current report view. The comma-delimited file should include column headings for each ofthe columns of data provided to the USER. The comma-delimited file must also include report header information that includes:

• Report View (open ticket detail/closed ticket detail)

• Name of the Adjuster

• Date and time the report was generated

The system should retum the USER to the report view (Step 3 ofthe Basic Flow) once a report has been successfully downloaded.

1.5 Post-Conditions

• If successful, a standard report is created for the USER.

If unsuccessful, the system state remains unchanged.

Confidential Enterprise Rent-A-Car © 2000 htn)^ intr_ne-'(toι2 ReadIλιcOrLinI-ASI^Fol erID=2732&DocID=9655 ARMS Redesign Project - Release 2.0 Issue: l.U

Generate Personal Report Issue Date: 8/16/2000

1.6 Special Requirements

The special requirements for this use case define all ofthe personal report 'views' that are available to the USER. This list of personal report views may be expanded at a later date to include additional information from the ARMS/400 reporting detail files, but only these views are anticipated for the initial release.

1.6.1 Open Ticket Detail View

The Open Ticket Detail View provides the USER with columns of data on all currently open tickets under their management. The Open Ticket Detail report will display the following information to the user:

1. Renter Name

2. Claim Number

3. Claim Type 4. Authorized Rate*

5. Authorized Days* 6. Rental Days* 7. Number of Days Behind* 8. Number of Extensions*

9. Surcharges (Y N)

10. Authorized Amount* Specific rules that must apply to the Open Ticket Detail report view are outlined in the sections below;

1.6.1.1 Data Columns in the Open Ticket Detail View should be presented in the order defined above. For example, renter name belongs in column 1 of the Open Ticket Detail report.

1.6.1.2 All numeric fields should have averages provided at the foot of each corresponding column. Numeric fields are indicated with an asterisk (*) in the list above.

1.6.1.3 The default sort for the Open Ticket Detail view must be by the Number of Days Behind field, with open tickets that are the farthest behind presented at the top of the list.

1.6.1.4 Any open tickets that have a value greater than zero (0) in the Number of Days Behind field should be highlighted to the USER.

1.6.1.5 The report must include a count of the total number of contracts in the list.

1.6.1.6 The report view must include report header information (in both screen and downloaded versions) that includes:

• the type/view of report (open ticket detail)

• the name of the USER for whom the report was generated

• the date/time the open ticket report was generated

Confidential Enterprise Rent-A-Car © 2000 ttp://intr-net/c-m2meadDocOrUnk.ASP?FolderII)=2732&Dc<;II =9655 ARMS Redesign Project - Release 20 Issue 1 11

Generate Personal Report Issue Date 8/16/2000

1 62 Closed Ticket Detail View

The Closed Ticket Detail View provides the USER with columns of data on closed ticket activity for the currently selected date range (the default date range is the current plus previous two (2) months). The Closed Ticket Detail report will display the following information to the user:

1. Renter Name

2. Claim Number

3. Claim Type

4. Authorized Rate*

5. Authorized Days*

6. Billed Days*

7. Number of Extensions*

8. Total Charges*

9 Amount Received*

10. . Billed Amount*

Specific rules that must apply to the Closed Ticket Detail report view are outlined in the sections below,

1 62 1 Data Columns in the Closed Ticket Detail View should be presented in the order defined above For example, renter name belongs in column 1 of the Closed Ticket Detail report

1 622 All numenc fields should have averages provided at the foot of each corresponding column. Numenc fields are indicated with an astensk (*) in the list above

1 623 The default sort for the Closed Ticket Detail view must be by the Claim Number field

1 624 The report must include a count of the total number of contracts in the list

1 625 The report view must include report header information (in both screen and downloaded versions) that includes

• the type/view of report view (closed ticket detail)

• the name ofthe USER for whom the report was generated

• the date/time the open ticket report was generated

1 63 Custom Report Views

The USER will have the ability to define their own custom report views through the RP-03 Add/Edit Custom View use case. These custom views are accessible from the Personal Reporting module of ARMS Web

1 64 Report View Management

The system will present all ofthe records in a report result set on a single page, and the USER will scroll through the results to find specific records Report views will not be presented m paging format (e g., forcing the USER to review the Next 25 of 427 records).

Confidential Enterpnse Rent-A-Car © 2000 http7/ιntracιet/d 2/ReadE⁾c :OrLmlcΛSP'FolderID=2732&Docπ>= 655 ARMS Redesign Project - Release 2.0 j_ssue: \ \\

Generate Personal Report Issue Date: 8/16/2000

1.7 Extension Points

This section describes the extension points of this use case.

1.7.1 MA-13 Change Authorization

If the USER selects a line item from the Open Ticket Detail report view, the USER will extend into the MA-13 Change Authorization use case (see the Select Open Ticket from Open Ticket Detail Report Alternative Flow on page 3 for additional detail). The USER will have the ability to make any changes or updates that their security level allows, and have the opportunity to return to this use case without making any changes to the open ticket. On completion of activity in the MA-13 Change Authorization use case, the USER will be returned to Step 3 of the Basic Flow within this use case (be presented with the Open Ticket Detail report).

17.2 RP-03 Add/Edit Custom View

If the USER selects to add or edit a custom view, the USER will extend into the RP-03 Add/Edit Custom View use case (see the Add/Edit Custom View Alternative Flow on page 4 for additional detail). The USER will define or modify their custom report layout and be returned to Step 2 ofthe Basic Flow within this use case.

Confidential Enterprise Rent-A-Car © 2000 htrp:/ intι^e-'dm2 ReadDocOrLin \SP?FolderID=2732&DocID=9655 ARMS Redesign Project - Release 2.0 Issue: 1.11 Generate Personal Report Issue Date: 8/16/2000

Screen Design

A definition ofthe screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Personal Report Template Screen

This screen provides the template to build personal report 'views', and supports Step 3 ofthe Basic Flow.

2.1.1 Screen Layout

aleome to the

Automated Rental Management System

Office; 001 Handling foπ Yoursβtf

PørSOπal Reports: for<ReρortBy> aβof <TI e/Date Stamp> <Report Typβ>

Choose a different report

^β top of ^aflg Download this report View a different report:

Select view: | Open Ticket Summary |

Show Only: [AHCIaimTypes j

β lop of papa

2.1.2 Screen Field Definition

Confidential Enterprise Rent-A-Car © 2000 http://intπme-^, m2/ReadDocOrLin ASP?Fold-rID=2732--Do-ir>-9655 ARMS Redesign Project - Release 2.0 Issue: 1.11 Generate Personal Report Issue Date: 8/16/2000

Confidential Enterprise Rent-A-Car © 2000 http^ intr_n--'dm2/ReadDocOr inkASP?Fold-rπ 2732&D-cID==9655 ARMS Redesign Project - Release 2.0 Issue: 1.11 Generate Personal Report Issue Date: 8/16/2000

Screen Type Length Data Field Screen Specitic Rule

Label

From Combo Closed ticket The 'From' combo box should include all box report from months and years for the last 13 months (rolling date 13 month period, current month inclusive). For example a value in this field might include 'January 2000'.

The default value should be j the current month.

To Combo Closed ticket The 'From' combo box should include all box report to date months and years for the last 13 months (rolling 13 month period, current month inclusive). For example a value in this field might include 'July 2000'.

The default value should be the current month.

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.1.3.1 Choose a different report

The 'Choose a different report' screen fimction provides the USER with a hyperlink to the View a Different Report section ofthe Personal Report Template screen. The 'Choose a different report' screen function must be at or near the header ofthe report.

2.1.3.2 Go to Report Averages

The 'Go to Report Averages' screen function provides the USER with a hyperlink to the bottom ofthe report to review the averages for each ofthe numeric columns in the report view. The 'Go to Report Averages' hyperlink must be at or near the header ofthe report.

2.1.3.3 Column Heading Sort

The 'Column Heading Sort' screen function allows the USER to click on any column heading and have the current report view sorted by the selected column. On initial selection of a column heading, the system will resort the report view by the column selected in ascending order. If the sorted column is selected by the USER, the system will resort the report in descending order.

2. 3.4 Download this report

The 'Download this Report' screen function allows the USER to click on a hyperlink and download a comma-delimited copy ofthe current report view. The downloaded copy must include:

❖ Report Header Information ^• Name ofthe Report View

> Name ofthe Person

> Date and Time that the Report Was generated

❖ Report View Column Headings

Confidential Enterprise Rent-A-Car © 2000 10 http:/Λntπ∞et/ 2 cadDo OrLink.ASP?FolderIO=2732&DocID== 655 ARMS Redesign Project - Release 2.0 Issue: 1.11

Generate Personal Report Issue Date: 8/16/2000

❖ Report View Records

2.13.5 View Report

The 'View Report' screen function allows the USER to submit a request for a different type and/or date range ofthe report view. The system will refresh the screen with updated report view information when this screen function is invoked.

2.13.6 Edit Custom View

The Edit Custom View screen function is available only in cases that the USER has a custom defined view active. If the USER selects the Edit Custom View hyperlink, the system will present the USER with the Add/Edit Custom View screen and pre-populate the screen with the custom view definition. This will allow the USER to edit the custom views that they have previously defined.

Confidential Enteφrise Rent-A-Car © 2000 11 http://intranet/(_ιι_/R_adDocOrI-inkΛSP'Fold_rID=2732&DooII = 655 Enterprise Rent-A-Car Page 1 of 2

Authorize Dir ct BΪJI: for Reed, Keith Claim no.123-9829 C U STO M E R FI LE

Direct Bill Requested for: Claim Number: |!^_?£?9_ Claim Type: insured

Note to Enterprise: days @ l^Economy ^{1 8}-"_

Policy: Daily rate/ι_{p|ease chose a rate>} Maximum do ars«

Direct Bill%: 100

Note to Self Only:

Vehicle Condition:! Please select a condition

Date of Loss:} September 20 ! 2000

Date Rental Needed:| September § |22 f| )2000

Insured Name: Last:| First:

Messages:

Go to Notebook

[Change or Add]

RSNTeft INPORlMATiQN. Keith Reed Home: (314)555-3876 Work: Work: N/A

Email: N/A

RSNTAi- INFQRiyiA-πøM.

Enteφrise Rent-A-Car Location:

ENTERPRISE RENT-A-CAR

3725 BOGEY RD

SAINT CHARLES MO 633033105

6369463010

ABDITIQiMA-. C MΛΛ .MFORMATJ0N:

Insured Name: N/A Repair Facility: Owner's vehicle: N/A N/A Date of Loss: 9/20/00

htφ://labpcad02/aπnsJsp/authDirectBill.jsp?ActionItemID=173&coι_nter=l 10/20/00 Enterprise Rent-A-Car Page 2 of 2

Date of Loss: 9/20/00 Type of Loss:

NOTEBOOKS

& top of page

Contact Us | Terms & Conditions | Log Off

ht1p://labpcad02/armsJsp/authDirectBill.jsp?ActionItemID=173&counter=l 10/20/00 Enteφrise Rent-A-Car Page 1 of 2

Exten R ntal: for Scott Clinton Claim no.615-3456 CUSTOMER FILE 1 of

Extension requested for: Note to Enterprise: additional authorized days @| Compact/20.99

Messages:

Note to Self:

Go to Notebook

Current Rental Status:

Rental Location:

Rental Start Date: 9/22/00 ENTERPRISE RENT-A-CAR

Last authorized ending date: 9/26/00 (314)918-1300

Authorized to date: 4 Repair Facility:

Charges to Date: $83.96^* Owner's vehicle:

Vehicle Condition : Driveable

Direct Bill %: 100

O Extend this rent

"Does not include taxes and surcharges

[Change or Add]

HEJMTEft INFORMATION.

Scott, Clinton Home: (314)555-2345 Work: N/A Email: N/A

RENTAL JI iPOftWfA IOM:

Current Class: Compact Enterprise Rent-A-Car Location: Additional Charges: None ENTERPRISE RENT-A-CAR Direct Bill %: 100 2229 S BRENTWOOD BLVD Rental Date: 9/22/00 SAINT LOUIS MO 631441832 Start Date: 9/21/00 (314)918-1300

ADDITrøSJAi. CLAIM I FORMATION

Claim Number: 615-3456 Repair Facility: Claim Type: Claimant Insured Name: Owner's vehicle: Date of Loss: 9/21/00 Type of Loss: Driveable Policy: Daily rate/ Maximum dollars:

NOTEBOOK:

http:/ labpcad02/armsjsρ/extendRental.jsp?ActioιιItemID=169&counter=l 10/20/00 Enterprise Rent-A-Car Page 2 of 2

^& top of page

Contact Us | Terms & Conditions | Log Off

http://labpcad02/armsJsp/extendRental.jsp?ActionItemID=l 69&counter=l 10/20/00 Enterprise Rent-A-Car Page 1 of 1

Claims Office: 003 Handling for: Yourself

Personal Reports , for <Report By> as of <Time/Date Stamp>

<Report Type>

Choose a different report

[Click on the column heading to sort] © Go to Report Totals

Renter Name Claim Number Claim Type Billed Authorized Number of Authorized Amount Davs Davs Extensions Rate Received

Walker. L 12345678901234567890 Insured 15 13 2 20.00 YES

Oquendo. J 12345678901234567891 Insured 13 12 1 25.00 YES

Grtffey ^j,, ₁₂345678901234567890 Claimant 10 13 16.99 NO

McGwire. M 12345678901234567892 Uninsured 5 12 0 19.99 NO

Laπkford. R 12345678901234567891 Claimant 7 0 0 23.99 YES

Jordan. B 12345678901234567891 Claimant 8 15 0 21.99 NO

Totals 6 Customer Files Averages 7.16 13.33 .33 0.5 ^Q top of page ^*Excludes taxes and governmen Downloa

Choose a different report:

Select a Open Ticket Summary view:

For Closed Tickets, please select a time period:

From: |January 2000 To: March 2000

® top of page

Contact Us | Terms & Conditions | Log off

http://labpcad02/armsJsp/personalReports.jsp 10/20/00 Enterprise Rent-A-Car

Functional Design Specification Generate Management Report

Version 1.11

Last Saved: 8/16/00 3:19 PM

ARMS Redesign Project - Release 2.0 Issue: 1.11 Generate Management Report Issue Date: 8/16/2000

Revision History

Confidential Enterprise Rent-A-Car © 20Q0 http://intranet drn2/ eadDocOr ink.ASP?FolderID=2732&DoolD=9656 ARMS Redesign Project - Release 2.0 Issue: 1.11

Generate Management Report Issue Date: 8/16/2000

Table of Contents

1. Generate Management Report

1.1 Brief Description

1.2 Use Case Actors

1.3 Pre-Conditions

1.4 Flow of Events

1.4.1 Activity Diagram 2

1.4.2 Basic Flow 3

1.4.3 Alternative Flows 3

1.5 Post-Conditions 5

1.6 Special Requirements 5

1.6.1 Standard Management Reporting Views 6

1.6.2 Custom Management Reporting Views 7

1.6.3 Report View Management 7

1.7 Extension Points 7

1.7.1 MA-13 Change Authorization 7

1.7.2 RP-03 AddEdit Custom View 7

2. Screen Design 8

2.1 Management Report View Template 8

• 2.1.1 Screen Layout 8

2.1.2 Screen Field Definition 8

2.1.3 Screen Function Definition 10

Confidential Enteφrise Rent-A-Car © 2000 http://intranet/dra2/ReadDocOrLink.ASP?FolderII 2732&DocID=9656 ARMS Redesign Project - Release 2.0 Issue: 1.11

Generate Management Report Issue Date: 8/16/2000

Generate Management Report

1. Generate Management Report

1.1 Brief Description

This use case describes how a USER would request and generate management reports using the on-line reporting functionality of ARMS Web. On-line management reports provide real-time access to open and closed ticket information, which provides the management team of our customers with a tool to effectively monitor rental management statistics. Using the on-line reporting functionality, USERs can request and receive summarized and detailed rental management reports on their Office, on Adjusters within an office, or on the Repair Facilities that are trading partners of a particular office.

NOTE: The on-line reporting functionality of ARMS Web provides ARMS ticket data only. ARMS and Non-ARMS reporting is available through the monthly L480 report.

1.2 Use Case Actors

All actors will use the use case to generate management reports in the ARMS Web system. All of the following actors can be defined generically as a USER:

• ADJUSTER - Adjusters may be granted the authority to access management reports in their user profile¹.

COMPANY MANAGER- All users that are identified to the system as managers will have access rights to the management reporting functionality.

For the balance of this use case, all of he above actors will be referred to as USER.

1.3 Pre-Conditions

• The USER must be signed-on to the system.

• The USER must have the authority to access management reports.

1.4 Flow of Events

The Flow of Events includes all the steps necessary to generate management reports in the ARMS Web system.

¹ Users may be granted access to management reporting capabilities through their user profile, even if they are not considered 'managers' in the ARMS Web system.

Confidential Enterprise Rent-A-Car © 2000 http://intranet dm2 ReadDocOrLink.ASP?FolderID=2732&DocID=96S6 ARMS Redesign Project - Release 2.0 Issue: 1.11 Generate Management Report Issue Date: 8/16/2000

1.4.1 Activity Diagram

Generate Management Report Activity Diagram

O

Confidential Enterprise Rent-A-Car © 2000 http://intranet/dm2/ReadDooOrLink.ASP?FolderlD=2732&Do.ID=9656 ARMS Redesign Project - Release 2.0 Issue: 1.11

Generate Management Report Issue Date: 8/16/2000

1.4.2 Basic Flow

The Basic Flow ofthe Generate Management Report use case includes all ofthe required activities for the USER to successfully generate and view a management report using the on-line reporting functionality in ARMS Web.

1. The USER selects to generate a management report from top navigation.

2. The system generates a Closed Ticket Summary report by Adjuster for the USER. Management reporting USERs will have the ability to request additional summary or detail reports for: a. The office as a whole (by Office) b. The adjusters within an office (by Adjuster) c. The repair facilities doing business with a claims office (by Repair Facility)

3. The system displays the report to the USER.

4. This ends this use case.

1.4.3 Alternative Flows

The Alternative Flows of this use case can occur when certain conditions exist or when specific USER feedback is provided.

1.4.3.1 Change Report View

At Step 6 ofthe Basic Flow, the USER will have the ability to change the report 'view'². Report 'views' change the type of information that is presented to the USER, but maintains the same or similar scope.

If the USER selects to change the report view, the system will return to Step 5 ofthe Basic Flow and re-generate the report to build the requested view. NOTE: The USER may also change the Report By criteria to request a new report view (e.g., request a report by Adjuster, Office, or Repair Facility).

1.4.3.2 Change Closed Ticket Date Range

At Step 6 ofthe Basic Flow, if the current report view is a closed ticket report, the USER will have the ability to change the date range ofthe report. The available date range for closed ticket reporting will be a rolling 13-month period (to be expanded to 24-months in future releases) with the current month inclusive. The default date range that will be presented to the USER will be the current and previous two (2) months. The USER will have the ability to select Month/Year to begin and end the date range for the closed ticket report. The USER will not have the ability to select specific days within a month as part ofthe date range.

If the USER selects a new date range for the closed ticket report view, the system will return to Step 5 ofthe Basic Flow and re-generate the report to build the USERs closed ticket report for the selected date range.

This applies to both summary and detail views of closed ticket reports.

^! Report views are covered in more detail in Section 1.6 Special Requirements.

Confidential Enterprise Rent-A-Car © 2000 http://intranet/dm2/ eadDocOr ink.ASP?FolderID=2732&DocID=9656 ARMS Redesign Project - Release 2.0 Issue: 1.11

Generate Management Report Issue Date: 8/16/2000

1.4.3.3 Select Summary Line Item from Open Ticket Summary Report At Step 6 of the Basic Flow, if the current report view is an open ticket summary report, the USER will have the ability to select a report line item, which will trigger a request for a more detailed report for the selected item. For example, if the current view were an Open Ticket Summary for Adjusters within an office (Open Summary by Adjuster), the USER would have the ability to select an adjuster from the summarized report and review the Open Ticket Detail report for that adjuster. This 'drill-down' capability must be available for all report types (by Office, by Adjuster, by Repair Facility).

If the USER selects a line item from a summary report view, the system will return to Step 5 of the Basic Flow and generate the Open Ticket Detail report view for the selected item. From the Open Ticket Detail, the USER will have the ability to return to the Open Ticket Summary or to continue reviewing the Open Ticket Detail report views for each adjuster/repair facility within the office.

14.3.4 Select Open Ticket from Open Ticket Detail Report

At Step 6 ofthe Basic Flow, if the current report view is an open ticket detail report, the USER will have the ability to select a report line item to view the details ofthe open ticket customer file. When selected, the system will present the USER with the customer file that corresponds to the selected open ticket. The USER will be allowed to modify and submit changes to the customer file (as proscribed in use case MA-13 Change Authorization). Once activity on the customer file is complete, the USER should be returned to the open ticket detail report (Step 6 ofthe Basic Flow).

1.4.3.5 Select Summary Line Item from Closed Ticket Summary Report

At Step 6 ofthe Basic Flow, if the current report view is a closed ticket summary report, the USER will have the ability to select a report line item, which will trigger a request for a more detailed report for the selected item. For example, if the current view were a Closed Ticket Summary for Repair Facilities within an office (Closed Summary by Repair Facility), the USER would have the ability to select a repair facility name from the summarized report and review the Closed Ticket Detail report for that repair facility. This 'drill-down' capability must be available for all report types (by Office, by Adjuster, by Repair Facility).

If the USER selects a line item from a summary report view, the system will return to Step 5 of the Basic Flow and generate the Closed Ticket Detail report view for the selected item. From the Closed Ticket Detail, the USER will have the ability to return to the Closed Ticket Summary or to continue reviewing the Closed Ticket Detail report views for each adjuster/repair facility within the office.

1.4.3.6 Select Closed Ticket from Closed Ticket Detail Report

At Step 6 ofthe Basic Flow, if the current report view is a closed ticket detail report, the USER will have the ability to select a report line item to view the details of the closed ticket customer file. When selected, the system will present the USER with the closed customer file that corresponds to the selected closed ticket. The USER will be allowed to view/print the details of the closed ticket, but will not have the ability to modify or change the ticket information. From the closed customer file, the USER will be returned to the closed ticket detail report (Step 6 of the Basic Flow).

1.4.3.7 Sort Report

At Step 6 ofthe Basic Flow, the USER will have the ability to select any report column heading to have the report sorted by the selected column. If the USER selects a column heading, the system must sort the report by the selected column heading in ascending order. The USER will have the ability to toggle between ascending and descending sort order by re-selecting the

Confidential Enterprise Rent-A-Car © 2000 4 http://intranet/dm2/ReadDooOrLink.ASP?FolderID=2732&DocID=9656 ARMS Redesign Project - Release 2.0 Issue: 1.11

Generate Management Report . Issue Date: 8/16/2000 currently sorted column. For example, if the USER wanted their report view to be sorted by Renter Name, clicking on the column would cause the report view to be sorted ascending by renter last name. If the USER would like to reverse the sort order to descending, selecting the column heading again would allow the report to be resorted descending by renter last name.

The system will return the USER to Step 6 ofthe Basic Flow on completion of this Alternative Flow, with the report view resorted according to the USER request.

1.4.3.8 Add/Edit Custom View

At Step 6 ofthe Basic Flow, the USER will have the ability to add or edit a custom report view. If the USER selects to add a report view, the system will extend to the RP-03 Add/Edit Custom View use case to define a new custom report layout.

If the USER is viewing a custom report, they will have the ability to edit the custom view by selecting an 'edit' option. When a user requests to edit a custom report layout, the system will extend to the RP-03 Add/Edit Custom View use case and pre-fill all corresponding fields with the currently selected parameters for the custom layout.

On completion ofthe use case extension, the USER will be returned to Step 5 of Basic Flow in this use case and be presented with the custom report layout that was defined/modified.

1.4.3.9 Select Download Report

At Step 6 ofthe Basic Flow, the USER will have the ability to download the current report view to a comma-delimited file. If the USER selects to download a comma-delimited version ofthe report, the system must publish a comma-delimited file that includes all ofthe data within the columns ofthe current report view. The comma-delimited file should include column headings for each of the columns of data provided to the USER. The comma-delimited file must also include report header information that includes:

• Report View (open ticket detail/closed ticket detail)

• Name ofthe Adjuster

• Date and time the report was generated

The system should return the USER to the report view (Step 6 of the Basic Flow) once a report has been successfully downloaded.

1.5 Post-Conditions

• If successful, a standard report is created for the USER.

• If unsuccessful, the system state remains unchanged.

1.6 Special Requirements

The special requirements for this use case define all ofthe management report 'views' that are available to the USER. Management reports will be provided two USERs in two ways:

• ' Standard' reporting views that have been defined by Enterprise at the request of customers

• 'Custom' reporting detail views that allow the USER to define the columns of data that they would like to be present in a report

Confidential Enteφrise Rent-A-Car © 2000 http://intr-net dι_2/ReadDocOrLink.ASP?FolderID-2732&DocID=9656 ARMS Redesign Project - Release 2.0 Issue: 1.11 Generate Management Report Issue Date: 8/16/2000

1.6.1 Standard Management Reporting Views

Standard management reporting views are views that have been defined by Enteφrise based on the requests of customers. These views will be carried forward in to ARMS Web and are defined in this section.

The table below includes the detailed data fields that are available on each ofthe 'standard' management reports. The columns available in each report have been expanded somewhat over the current state, as the web environment offers more flexibility to provide additional information than the current state green screen application. The sequence of columns that must be presented in each report are indicated using the number 1-10, with fields that are on the screen but not in the primary data table indicated with an 'X'. For example, the first column in the 'Adjuster — Open Detail' report is the renter name, the second column is the claim number, etc.

1.6.1.1 All numeric fields should have averages provided at the foot of each corresponding column. Numeric fields are indicated with an asterisk (*) in the list above.

1.6.1.2 The default sort for the Open Ticket Detail views must be by the Number of Days Behind field, with open tickets that are the farthest behind presented at the top of the list.

1.6.1.3 The default sort for the Closed Ticket Detail views must be by Claim Number.

1.6.1.4 The default sort for the Open Ticket Summary views must be by Adjuster Name (if by Adjuster), Repair Facility Name (if by Repair Facility), or Office Name (if by Office)

Confidential Enterprise Rent-A-Car © 2000 http.//in r-nel/drn2 ReadDocOrLinl{.ASP?FolderID=2732&DocID=9655

1.6.1.5 The default sort for the Closed Ticket Summary views must be by Adjuster Name (if by Adjuster), Repair Facility Name (if by Repair Facility), or Month/Year (if by Office)

1.6.1.6 Any items in an Open Ticket Detail view that have a value greaterthan zero (0) in the Number of Days Behind field should be highlighted to the USER.

1.6.1.7 All report views must include a count of the total number of contracts listed.

1.6.1.8 The report view must include report header information (in both screen and downloaded versions) that includes:

• the type/name ofthe report view (e.g., open ticket detail, open ticket summary)

• the name ofthe entity that is being reported on. For summary views, this should always be the office name. For detail views, the entity name must be: o the adjuster name (for reports by Adjuster) o the office name (for reports by Office) o the repair facility name (for reports by Repair Facility)

• the date/time the report was generated

1.6.2 Custom Management Reporting Views

Custom management reporting views allow the USER to define the fields that they would like to use to build their own report. The fields selected by the USER become the columns ofthe report, and the system will not limit the number of columns that a USER can request as part ofthe report. Custom reporting views are discussed at length in use case RP-03 Add/Edit Custom View.

1.6.3 Report View Management

The system will present all ofthe records in a report result set on a single page, and the USER will scroll through the results to find specific records. Report views will not be presented in paging format (e.g., forcing the USER to review the Next 25 of 427 records).

1.7 Extension Points

This section describes the extension points of this use case.

1.7.1 MA-13 Change Authorization

If the USER selects a line item from the Open Ticket Detail report view, the USER will extend into the MA-13 Change Authorization use case (see the Select Open Ticket from Open Ticket Detail Report Alternative Flow on page 4 for additional detail). The USER will have the ability to make any changes or updates that their security level allows, and have the opportunity to return to this use case without making any changes to the open ticket. On completion of activity in the MA-13 Change Authorization use case, the USER will be returned to Step 6 ofthe Basic Flow within this use case.

1.7.2 RP-03 Add/Edit Custom View

If the USER selects to add or edit a custom view, the USER will extend into the RP-03 Add/Edit Custom View use case (see the Add/Edit Custom View Alternative Flow on page 5 for additional detail). The USER will define or modify their custom report layout and be returned to Step 6 ofthe Basic Flow within this use case.

Confidential Enterprise Rent-A-Car © 2000 http-//intr-net dm2/ReadDocOrLiiil-ASP?FolderlD=2732--DoclD=9656 ARMS Redesign Project - Release 2.0 Issue: 1.11 Generate Management Report Issue Date: 8/16/2000

2. Screen Design

A definition ofthe screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Management Report View Template

This screen provides the USER with a management report view template, and supports Step 6 ofthe Basic Flow.

2.1.1 Screen Layout

Welcome to the

Automated Rental Management System create a RESERVATION

Office: 001 Handling foπ Yourself

Management RθpOrtS for<ReportBy>asof σlπιeΛ3ateS_3mp> <ReportType>

Choose a different report

o lop of papa

Download this report

<« Previous <Report Bv> Goto: <Next Report By lt_rn j Next <R-port Bv >»

View a different report: Report by: [Adjuster

Select a view: | Open Ticket Summary jf

Show Only: |ΛII Claim Types jg From: | January 2000 j||

To: | March 2000 © top of page-'

2.1.2 Screen Field Definition

Screen l pc Length Data Field Screen Specific Rule

Label

Confidential Enterprise Rent-A-Car © 2000 http://intranet dm2/ReadDocOrLink.ASP?FoIderID=₂732&DoclD=9656

Screen I ypc Data Field Screen Specific Rule

Label

Output <Reρort By> The <report by> field is a placeholder in the Text header of the report view. For management reports, this placeholder should be populated with the name ofthe entity that is being reported on (i.e., Adjuster Name, Office Name, or Repair Facility Name).

Output <Time/Date The <time/date stamp> field is a placeholder in Text Stamp> the header ofthe report view. For management reports, this placeholder should be populated with the date and time that the report was generated.

Output <Report The <reρort type> field is a placeholder in the Text Type> header of the report view. For management reports, this placeholder should be populated with the name ofthe current report view (e.g., Open Ticket Detail, Custom View 1)

<Column Output <Data The data columns ofthe report should Heading Text Columns 1 correspond to the data columns defined for the 1 through through X> selected report view (either static or custom X> report view). The data columns should be presented in the sequence that they are defined.

Total Output Number of The total field should include the total number Text Customer of contracts/customer files that are represented

Files in the report.

Go to Combo Report sorted The 'Go to' combo box should include all ofthe Box by navigation entities available in the current report. For example, if the report were an Open Ticket Detail view Reported By Adjuster, this list would include all ofthe Adjusters that would PAGE in the list.

The 'Go to' combo box should only be available in detail views.

Report Combo Report sorted The 'Report by' combo box should include all by box by ofthe currently available report by options in the ARMS Web system. The report by options for the initial release of ARMS Web 2.0 should be: 'Office', 'Adjuster', and 'Repair Facility'

Select a Combo Report view The 'select a view' combo box should include view Box selection the names of all report views that are available to the user. This includes all pre-defined (e.g., Open Ticket Detail) and user-defined custom views.

There should be an additional option to 'Add a custom view...'. If selected, the system should redirect the user to the Add Edit Custom View screen in the RP-03 Add/Edit Custom View specification.

Confidential - Enterprise Rent-A-Car © 2000 http://intr-net dm2 eat-DocθrLinI_ASP?FolderID=2732&DocII 9656

Length Data Field Screen Specific Rule

Show Combo Claim Type The 'show only' combo box should include the Only Box Filter following values:

• All Claim Types (default)

• Insured Claim Types

• Claimant Claim Types

• Uninsured Claim Types

• Theft Claim Types

When selected, the report should filter the records to display in the requested report view according to the selection in this combo box. For example, if the selection in the 'show only' field were 'Insured Claim Types', the report view would only include records that have a Claim Type of 'Insured.

From Combo Closed ticket The 'From' combo box should include all box report from months and years for the last 13 months (rolling date 13 month period, current month inclusive). For example a value in this field might include 'January 2000'.

The default value should be 2 mόn hέprtoi. to the current month.

To Combo Closed ticket The 'From' combo box should include all box report to date months and years for the last 13 months (rolling 13 month period, current month inclusive). For example a value in this field might include 'July 2000'.

The default value should be the current month.

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.1.3.1 Choose a different report

The 'Choose a different report' screen function provides the USER with a hyperlink to the View a Different Report section of the Personal Report Template screen. The 'Choose a different report' screen function must be at or near the header of the report.

2.1.3.2 Go to Report Averages

The 'Go to Report Averages' screen function provides the USER with a hyperlink to the bottom ofthe report to review the averages for each ofthe numeric columns in the report view. The 'Go to Report Averages' hyperlink must be at or near the header ofthe report.

2.13.3 Column Heading Sort

The 'Column Heading Sort' screen function allows the USER to click on any column heading and have the current report view sorted by the selected column. On initial selection of a column

Confidential Enterprise Rent-A-Car © 2000 10 http://intranet/dm2/ReadDocθr ink.ASP?FolderID=2732&DooID=9656

heading, the system will resort the report view by the column selected in ascending order. If the sorted column is selected by the USER, the system will resort the report in descending order.

2.1.3.4 Previous <Report By>

The 'Previous <Report By>' screen function allows the USER to navigate to the previous detail record in a particular detail report. For example, if the report view were an Open Ticket Detail report by Repair Facility, the 'Previous <Report By> screen function would allow the USER to move to the previous Repair Facility detail record in a report. This screen function should only be available on open or closed ticket detail views (including custom views), and should only be available if a previous report by item exists (i.e., we wouldn't have a previous item if we were on the first item in the list).

2.1.3.5 Next <ReportBy>

The 'Next <Reρort By>' screen function allows the USER to navigate to the next detail record in a particular detail report. For example, if the report view were an Open Ticket Detail report by Adjuster, the 'Next <Report By> screen function would allow the USER to move forward to the next Adjuster's detail report view within the office. This screen function should only be available on open or closed ticket detail views (including custom views), and should only be available if a next report by item exists (i.e., we wouldn't have a next item if we were on the last item in the list).

2.1.3.6 Download this report

The 'Download this Report' screen function allows the USER to click on a hyperlink and download a comma-delimited copy ofthe cuιτent report view. The downloaded copy must include:

't* Report Header Information

> Name of the Report View

> Name ofthe Person Date and Time that the Report Was generated

❖ Report View Column Headings

❖ Report View Records

2.1.3.7 View Report

The 'View Report' screen function allows the USER to submit a request for a different type and or date range ofthe report view. The system will refresh the screen with updated report view information when this screen function is invoked.

2.1.3.8 Edit Custom View

The Edit Custom View screen function is available only in cases that the USER has a custom defined view active. If the USER selects the Edit Custom View hyperlink, the system will present the USER with the Add/Edit Custom View screen and pre-populate the screen with the custom view definition. This will allow the USER to edit the custom views that they have previously defined.

Confidential Enteφrise Rent-A-Car © 2000 11 ttp://intranet'dm2/ReadDocOr in .ASP?Fold-rID=2732&DocID=9656 Enterprise Rent-A-Car

Functional Design Specification Add/Edit Custom View

Version 1.1

Last Saved: 7/24/00 1:21 PM

Confidential Enterprise Rent-A-Car © 2000 http://intratιet'dm2 ReadDocOrLmk.ASP?FolderlD-2732&DocID=9657 ARMS Redesign Project - Release 2.0 Issue: 1.1

Add/Edit Custom View Issue Date: 8/9/2000

Table of Contents

1. Generate Management Report

1.1 Brief Description

1.2 Use Case Actors

1.3 Pre-Conditions

1.4 Flow of Events

1.4.1 Activity Diagram 2

1.4.2 Basic Flow 3

1.4.3 Alternative Flows 3

1.5 Post-Conditions 3

1.6 Special Requirements 4

1.6.1 Custom Report Definition 4

1.6.2 Custom Report View Data Domain 5

1.7 Extension Points 5

2. Screen Design 6

2.1 Add/Edit Custom View 6

2.1.1 Screen Layout 6

2.1.2 Screen Field Definition 7

2.1.3 Screen Function Definition 8

Confidential Enteφrise Rent-A-Car © 2000 http://intranet dm2 eadDocOrUn .ASP?FolderID=2732&DooID=9657 ARMS Redesign Project - Release 2.0 Issue: 1.1

Add/Edit Custom View Issue Date: 8/9/2000

Add/Edit Custom View

1. Generate Management Report

1.1 Brief Description

The Add/Edit Custom View use case describes the process to add or edit a custom report view in the ARMS Web system. Custom views allow the USER to select the data columns that they would like to view in a report (from a pre-defined list of available fields). USERs will have the ability to access their custom views just as they would any other 'standard' report view.

1.2 Use Case Actors

All actors will use the use case to add or edit a custom report view(s) in the ARMS Web system. All ofthe following actors can be defined generically as a USER:

• ADJUSTER

• COMPANY MANAGER

For the balance of this use case, all ofthe above actors will be referred to as USER.

1.3 Pre-Conditions

• The USER must be signed-on to the system.

• The USER must have the on-line reporting functionality active (i.e., must be on an on-line reporting screen).

1.4 Flow of Events

The Flow of Events includes all the steps necessary to add or edit a custom report view in the ARMS Web system.

Confidential Enteφrise Rent-A-Car © 2000 http://intι_net dm2 ReadDocOrLin .ASP?FolderlD=2732&DocII>=9657 ARMS Redesign Project - Release 2.0 Issue: 1.1 Add/Edit Custom View Issue Date: 8/9/2000

1.4.1 Activity Diagram

Add/Edit Custom View Activity Diagram

Confidential Enterprise Rent-A-Car ©.2000 http://intranet dm2 eadDocOrLink.ASP?FolderID=2732&DocII>9657 ARMS Redesign Project - Release 2.0 Issue: 1.1

Add Edit Custom View Issue Date: 8/9/2000

1.4.2 Basic Flow

The Basic Flow ofthe Add/Edit Custom View use case includes all of the required activities for the USER to successfully add or edit a custom report view for use in the on-line reporting functionality of ARMS

Web.

1. The USER selects to add or edit a custom report view from the on-line reporting screen(s).

2. The system displays a screen that allows the USER to define or build a custom report view.

3. The USER defines the custom report view. The USER will have the ability to indicate a Name for the view, and define the data columns that they would like to have reported. The comprehensive list of data columns that will be available to the USER can be found in Section 1.6 Special Requirements (on page 4).

4. The USER will submit the custom view to the system.

5. The system will update the ARMS Web database.

6. This ends this use case.

1.4.3 Alternative Flows

The Alternative Flows of this use case can occur when certain conditions exist or when specific USER feedback is provided.

1.4.3.1 Edit Custom Report View

At Step 1 ofthe Basic Flow, if the USER selected to edit a current custom report view, the system will present the screen to define/build a custom report and pre-fill all fields with the current report definition. For example, if the USER were editing their 'Massive' custom report view, 'Massive' would appear in the report name field and all ofthe data columns that were previously defined as the massive report would appear in the 'selected columns' portion ofthe screen.

1.5 Post-Conditions

• If successful, a custom report view is created for the USER.

• If unsuccessful, the system state remains unchanged.

Confidential Enterprise Rent-A-Car © 2000 http://intranet dm2/ReadDocθrLinl_ASP?FolderID=2732&DocID=9657 ARMS Redesign Project - Release 2.0 Issue: 1.1

Add Edit Custom View Issue Date: 8/9/2000

1.6 Special Requirements

The special requirements for this use case define all ofthe management report 'views' that are available to the USER. Management reports will be provided two USERs in two ways:

1.6.1 Custom Report Definition

This section provides the system framework for custom report view definition in the ARMS Web system. These are additional requirements around functionality to allow USERs to define/build custom report views, and apply to the use case as a whole.

1.6.1.1 USERs will have the ability to create one or more custom views.

1.6.1.2 USERs will be able to define custom report views for DETAIL views only (USERs will not have the ability to define custom summary views¹).

1.6.1.3 USERs will have the ability to select custom report views by Office, by Adjuster, or by Repair Facility (similar to the standard management reports).

1.6.1.4 Custom report views will be limited to the data columns in the Custom Report View Data Domain (see 1.6.2 Custom Report View Data Domain)

1.6.1.5 Custom report views must define if the report view retrieves Open, Closed, or All Ticket statuses.

1.6.1.6 All custom report views defined as 'closed ticket only' must allow the user to indicate a date range. The default date range for custom views will be the same as the default range for standard closed ticket reports (the current month plus two (2) prior months).

1.6.1.7 When a custom report view has been defined, the name of the custom report view will become a selection from the USERs view list. For example, 'MyCustomView' would be seen in the list with 'Open Ticket Detail', 'Closed Ticket Detail', etc..

¹ Most ofthe numeric fields that can be summarized for USERs are already provided in the standard management report views.

Confidential Enterprise Rent-A-Car © 2000 http://intranet dπι2/ReadDocOrLink.ASP?FolderID=2732&DocID=9657 ARMS Redesign Project - Release 2.0 Issue: 1.1 Add/Edit Custom View Issue Date: 8/9/2000

1.6.2 Custom Report View Data Domain

The following is a list of all available data columns that a USER may select as part of a custom report view. The number of columns that a USER selects to make part of the custom report view is not limited, which allows the USER to select a subset or all of these data fields to be published in their report.

1.7 Extension Points

None.

Confidential Enteφrise Rent-A-Car © 2000 http://intranet dm2 ReadDocOrLink.ASP?FolderID=2732&DocID=9657 ARMS Redesign Project - Release 2.0 Issue: 1.1 Add/Edit Custom View Issue Date: 8/9/2000

2. Screen Design

A definition ofthe screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Add/Edit Custom View

This screen provides the USER with the ability to add or edit a custom view, and supports Step 2 ofthe Basic Flow.

2.1.1 Screen Layout

Nam. Uιi» report 'X~' O Choose a naσiøtαr your new report. θ You may chooso a roport vlaw (optimal).

&8rtfmmβVi-w:jCkMedΥkk.l Detail {optional} θ Gt.oonoticM tt.lu_.

0 Add lha fields you'd Ilka and the older you'd Ilk* to see them. Soloctrlritfs to display on r«ρort Available Fiild* New Report Fields

Renter Mama Aφster Name. Claim Number OBier Charges- CteiπvType Repair Facility Bϋlβd Days Rental ays Auth. Days Renter Stale Auth. Rate Office^'

Number. <A extensions. Rental Open Date Total Changes

Rental Close Date Renter Charges. Tola) EWβd Charges

f Mmssulm i tssaijfflmsma r natøωiωiMft

Confidential Enteφrise Rent-A-Car © 2Q0O http:;/intranet dm2/ReadDo^gOrLin .ASP?FolderID=2732&DocID=9657 ARMS Redesign Project - Release 2.0 Issue: 1.1 Add/Edit Custom View Issue Date: 8/9/2000

2.1.2 Screen Field Definition

Screen Length Data Field Screen Specific Rule Label

Name Custom The name a USER provides to refer to the this Report Name custom report view definition. report

The name ofthe report must be unique to other custom reports defined by the user (e.g., a single user can not have two reports with the same name). This uniqueness must only be enforced at the user level (e.g., two different users CAN use the same name for a report).

The name ofthe report will appear in the USERs 'Select a view' combo box when the report view is saved.

Start Combo Custom view The 'Start from a View' combo list allows a from a box start point USER to select a default or 'standard' view as a

View starting point in report view definition. The values within the combo box should be 'Open Ticket Detail' and 'Closed Ticket Detail'. If selected, the system should use the values ofthe Report by 'Adjuster' standard report to pre- populate the 'New Report Fields' list box..

The default value of this field should be '-Select a Starting View-'

Ticket Combo Custom view The 'Ticket Status' combo box indicates the Status box ticket status scope ofthe report in terms of ticket status. The list should include 'Open Tickets', 'Closed Tickets', and 'All Tickets'. The system will use this as part ofthe overall custom report definition.

Available List Box Custom view The 'Available Fields' list box includes all of Fields available the fields that are available to be included in a fields custom view, but have not yet been selected to be included in the report.

When an available field is selected from the list to be included in the report, the field should be removed from this list box (and populate the 'New Report Fields' list box).

For a list of all available fields see Section 1.6.2 Custom Report View Data Domain above.

Confidential Enterprise Rent-A-Car © 2000 http://intranet dm2/ReadDocOrLink.ASP?FolderID=2732&DocID=9657 ARMS Redesign Project - Release 2.0 Issue: 1.1 Add/Edit Custom View Issue Date: 8/9/2000

Screen I ypc Length Data Field Screen Specific Rule

Label

New List Box Custom view The 'New Report Fields' list box includes all of

Report selected the fields that have been selected by the USER.

Fields fields These fields define the columns ofthe report.

The sequence that the fields appear in the report is defined from top to bottom of this list box (e.g., the first field in the list = the first column in the report). This sequence can be modified using the Sequence Up and Sequence Down screen functions (see 0 Screen Function Definition below).

If the USER selects a starting view (from the Start from a View field), the list box will populate with all ofthe fields that make up the standard view selected (e.g., if the USER selects 'Closed Ticket Detail' from the Start from a View field, all ofthe fields that make up a Closed Ticket Detail report would populate in this field.

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.1.3.1 Remove

The 'Remove' screen function allows a USER to remove selected fields from the 'New Report Fields' list box (and re-add them to the 'Available Fields' list box).

2.13.2 Insert

The 'Insert' screen function allows a USER to add selected fields to the 'New Report Fields' list box (and remove them from the 'Available Fields' list box).

2.1.3.3 Dictionary

The 'Dictionary' screen function allows a USER to open a dictionary that defines all of the fields that can be added to a report view. The dictionary will be included as part ofthe help functionality ofthe system.

2.1.3.4 Sequence Up

The 'Sequence Up' screen function (presented with an 'up' arrow in the screen shot) allows a USER to move a selected field in the 'New Report Fields' list box up in the sequence of the report.

2.1.3.5 Sequence Down

The 'Sequence Down' screen function (presented with a 'down' arrow in the screen shot) allows i USER to move a selected field in the 'New Report Fields' list box down in the sequence ofthe report.

Confidential Enterprise Rent-A-Car © 2000 http://intranet dm2/ReadDocOrLink.ASP?FolderlD=2732&DocID=9657 ARMS Redesign Project - Release 2.0 Issue: 1.1

Add/Edit Custom View Issue Date: 8/9/2000

2.1.3.6 Save Report View

The 'Save Report View' screen function allows the USER to save the custom report definition and return to the reporting use case(s). The system will return the USER to the report use case from which they entered this use case (either RP-01 or RP-02) and be presented with the newly defined report view.

2.1.3.7 Close without Saving

The 'Close without Saving' screen function allows the USER to exist the screen with saving any changes made. The system will return the USER to the report use case from which they entered this use case (either RP-01 or RP-02).

2.13.8 Delete

The 'Delete' screen function allows the USER to delete a custom report view from their profile. When a custom report view is deleted it should no linger be available in the USERs view selection combo box. The system will return the USER to the report use case from which they entered this use case (either RP-01 or RP-02).

Confidential Enterprise Rent-A-Car © 2000 http //intranet/dra2 ReadDocOrLink.ASP?FolderlD-2732&DocID-9657 Enterprise Rent-A-Car

Functional Design Specification

Maintain User

Version 1.3

Last Saved: 8/18/00 1:02 PM

Issue: 1.2

Maintain User Issue Date: 10/20/00

Revision History

Confidential Enterprise Rent-A-Car © 2000 http://intranet dm2 ReadDocOrLink.ASP?FolderID=2706--DocID=10694 Issue: 1.2 Maintain User Issue Date: 10/20/00

Table of Contents

1. Maintain User Use Case 4

1.1 Brief Description 4

1.2 Use Case Actors 4

1.3 Pre-Conditions ⁴

1.4 Flow of Events 4

1.4.1 Activity Diagram 5

1.4.2 Basic Flow 6

1.4.3 Alternative Flows 6

1.5 Post-Conditions 7

1.6 Special Requirements 7

1.6.1 User Inactivation 7

1.6.2 User Default Settings 7

1.7 Extension Points 7

2. Screen Design 8

2.1 Create or Modify User 8

2.1.1 Screen Layout 8

2.1.2 Create or Modify User 8

2.1.3 Screen Function Definition 9

2.2 Create or Modify Team 10

2.2.1 Screen Layout 10

2.2.2 Create or Modify Team 10

2.2.3 Screen Function Definition 11

2.3 User Profile 12

2.3.1 Screen Layout 12

2.3.2 User Profile 13

2.3.3 Screen Function Definition 14

2.4 Team Profile 16

2.4.1 Screen Layout 16

2.4.2 Create or Modify Team 17

2.4.3 Screen Function Definition 17

3. Application Operations 19

3.1 Build list of Users 19

3.2 Find User Information 19

3.3 Update User Information 19

3.4 Build list of User offices 19

3.5 Find User Office Information 19

3.6 Update User Office Information 19

3.7 Add User Office Information 19

3.8 Remove User Office Information 19

3.9 Build a list of users to which the administrator has access 19

3.10 Validate that User ID does not exist 19

4. Data Fields 20

4.1 Data Field Definition 20

4.1.1 User Language Preference 20

4.1.2 Phone Number 20

4.1.3 Profile Attribute Id 20

4.1.4 Last Name 20

Confidential Enterprise Rent-A-Car © 2000 " http://intranefdm2/ReadDocOr ink.ASP?FolderID=2706&DocID=10694 Issue: 1.2 Maintain User Issue Date: 10/20/00

4.1.5 Handler for out of office user 20

4.1.6 Start Page 20

4.1.7 Is user out of office ? 21

4.1.8 Is the user multicompany ? 21

4.1.9 Can user receive work ? 21

4.1.10 Is User Active ? 21

4.1.11 Email Address 21

4.1.12 First Name 21

4.1.13 Password 22

4.1.14 User Id 22

5. Questions and Answers 23

Confidential Enterprise Rent-A-Car © 2000 hnp://intranet/dm2/ReadDocOrLink.ASP?FoldertD=2706&DocID=10694 Issue: 1.2 Maintain User Issue Date: 10/20/00

Maintain User

Maintain User Use Case

1.1 Brief Description

The Maintain User use case describes how a USER would set up or maintain a user in the ARMS Web system.

1.2 Use Case Actors

The following actors will interact with this use case:

• ENTERPRISE ADMINISTRATOR - The ENTERPRISE ADMINISTRATOR is a person who can perform this use case to set up any user in a company.

• COMPANY ADMINISTRATOR - The COMPANY ADMINISTRATOR is aperson who can perform this use case for the company. They may add users and assign them to office(s) that they are the administrator of within the company.

• OFFICE ADMINISTRATOR - The OFFICE ADMINISTRATOR is a person who can perform this use case for the company. The OFFICE ADMINISTRATOR may maintain any user in their company structure to which they have been assigned ownership.

1.3 Pre-Conditions

• The USER must be logged into the system.

• If maintaining a user, the USER should have the ability to maintain that user. In order to maintain a user at a specific office, the ADMINISTRATOR must have access to that specific office.

• If adding a user, the USER should have the ability to add a user.

1.4 Flow of Events

The Flow of Events will include all the steps necessary to add or maintain a company user in the ARMS Web system.

Confidential Enteφrise Rent-A-Car © 2000 http://intranet dm2flleadDocOrLink. ASP?FolderID=2706&DocID= 1069 Issue: 1.2

Maintain User Issue Date: 10/20/00

1.4.1 Activity Diagram

Maintain User Activity Diagram

Y:\APPS\#ARMS eb\Application\@dkb\ARMS Web\Release One\PR-Profiling\PR-05-Maintain

9/14/00 UsertACTIVITY DIAGRAMS\PR-05 MAINTAIN USER.VSD

Confidential Enterprise Rent-A-Car © 2000 http://intranet'drrι2/ReadDocθrLink.ASP?Fo]derlD=2706&DocID=10694 Issue: 1.2 Maintain User Issue Date: 10/20/00

1.4.2 Basic Flow

The Basic Flow will describe how a USER will maintain a user in the ARMS Web system.

1. The USER will choose to maintain user(s).

2. The system will present a list of all users that are in all the offices the USER has access to maintain.

3. The USER will choose a user to maintain.

4. The system will display the user's information for the USER to edit.

5. The USER will update the user's information and submit the information to the system.

6. The system will validate the information entered.

7. The system will update the ARMS Web database.

8. This ends the use case.

1.4.3 Alternative Flows

1.4.3.1 Add User

At step three in the Basic Flow, the USER may choose to add a user, if they have the authority level to do so. The USER will enter a primary office, UseriD, First Name and Last Name for the new user. The system will then validate that the office was entered and the UseriD does not exist. If a UseriD match is found, or the office was not entered, the system will display an error and request the USER enter a new UseriD. Otherwise, the system will display the default settings for a new user; the USER will update the default settings and submit the information to the system. The system will validate the information entered, and update the ARMS Web database. The use case is then complete.

1.4.3.2 Show All Users for the Company

At step three in the Basic Flow, the USER may choose to display all users within the company. This would allow for adding users to offices the USER controls. The USER will choose the user they wish to work with and the system will then display the user's information; the USER will add the user to any offices the USER controls and submit the information to the system. The system will validate the information entered, and update the ARMS Web database. The use case is then complete.

1.4.3.2.1 If a user's primary office is not an office controlled by the USER, the USER may only add the user to offices the USER controls. The USER should not be able to change any ofthe user's settings. A USER that has control of a user's primary office can only change user settings.

14.3.3 User Information Validation Fails In step six ofthe Basic Flow, the system may find that user information entered by the USER does not meet the validation criteria. The system should return the USER to step four ofthe Basic Flow, show the USER the invalid data, and prompt the USER to reenter the data.

This rule also applies for new user creation. Whenever a new user is submitted to the system for creation, the system must validate that the criteria entered is valid. If any information is invalid, the system should present the invalid date to the USER, and prompt the user to correct it.

1.4.3.3.1 The following fields must be populated to complete a user update or new user creation.

• Last Name

• First Name

• UseriD (Must be validated to ensure it is not a duplicate ID)

• Home Office (Must be a valid office and not null)

1.4.3.4 Cancel Add I Maintain User Until step five in the Basic Flow, the USER may choose to cancel the use case. The system

Confidential Enterprise Rent-A-Car © 2000 http://intranet/dnι2/ReadDocOrLink.ASP?FolderID=2706&DocID=1069₄ Issue: 1.2

Maintain User Issue Date: 10/20/00 should not store any changes made by the USER within the use case.

1.5 Post-Conditions

• If the use case was successful and the USER was maintaining a user, the user criteria being changed will have been changed and updated in the ARMS Web system.

• If the use case was successful and the USER was adding a user, the user will have been added in the ARMS Web system.

• If the use case was unsuccessful, the system state will be unchanged.

1.6 Special Requirements

1.6.1 User Inactivation

In order to inactivate a user, the following set of criteria must be validated. If any of the criteria are found to be true, then the system will not allow the USER to inactivate the user.

If A4XREFL1/X4STCD is equal to 'C (closed rental) and any tickets were closed in the past seven days

If A4XREFL1/X4STCD is equal to 'A' (audited invoice)

If A4XREFL1/X4STCD is equal to 'R' (reservation)

If A4XREFL1 X4STCD is equal to 'O' (open contract)

If A4XREFL1/X4STCD is equal to 'U' (unconfirmed) and A4XREFL1 X4RSFG is equal to 'D' (Direct Bill request)

If A4XREFL1/X4STCD is equal to 'Z' (sent) and A4XREFL1/X4RSFG is equal to 'C (extension request & message sent)

If A4XREFL1 X4STCD is equal to 'Z' (sent) and A4XREFL1/X4RSFG is equal to 'M' (authorization message sent)

If A4XREFL1/X4STCD is equal to 'Z' (sent) and A4XREFL1/X4RSFG is equal to 'X' (extension request sent)

If A4XREFL1/X4STCD is equal to 'B' (authorized invoice) and A4XREFL1 X4RSFG is equal to 'B' (invoice sent from ARMS)

If A4XREFL1 X4STCD is equal to 'B' (authorized invoice) and A4XREFL1/X4RSFG is equal to 'R' (invoice returned to adjuster)

If A4XREFL1/X4STCD is equal to 'B' (authorized invoice) and A4XREFL1/X4RSFG is equal to 'E' (rejected system error)

If A4XREFL1/X4STCD is equal to 'B' (authorized invoice) and A4XREFL1/X4RSFG is equal to 'Q' (rejected invoice ARMS researching)

1.6.2 User Default Settings

Whenever a new user is created, the settings for that user should be defaulted based on the user's primary office profile settings. For example, if the office is a reservation only office, the user should default to reservation only. This does not imply that the administrator cannot change the settings. This should also apply to whether can receive work setting should be on or off for the user/team. If all other users/teams in the office have the setting either on or off, then the new user should mimic this setting. Once again, this does not imply that the administrator cannot change this setting.

1.7 Extension Points

None.

Confidential Enterprise Rent-A-Car © 2000 http://intranet dm2/ReadDocOrLink.ASP?FolderID=2706&DocID=1069₄ Issue: 1.2

Maintain User Issue Date: 10/20/00

Screen Design

A definition ofthe screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Create or Modify User

This screen will allow the USER to search for and select a user to modify or select to add a new user.

2.1.2 Create or Modify User _ti_ ____ KEEBSffiiaπEl

Confidential Enteφrise Rent-A-Car © 2000 http //intranβt dm2m.eadDocOrLink Issue: 1.2

Maintain User Issue Date: 10/20/00

Screen L ih Type Siz Screen Field Name Data Field Name Screen Specific Rule

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.1.3.1 A - Z Anchor Links

When any ofthe letters are clicked, the list of users should position itself with that letter presented at the top of the user view area on the page.

2.1.3.2 Teams Link

When the team link is clicked, the list of teams should position itself at the top ofthe view area on the page. The list of teams should be placed last in the list of all users/teams.

2.1.3.3 Process

When the Process button is clicked, the system should check to see that the appropriate information was entered in order to create a new user (Office, Last Name, First Name UseriD). If the information is entered, the system will create a new user with those attributes and the other user attributes defaulted. The system should then display the new user's profile.

Confidential Enteφrise Rent-A-Car © 2000 http://intranefdm2/ eadDocOrLink.ASP''FolderlD=2706&DocID-1069₄ Issue: 1.2

Maintain User Issue Date: 10/20/00

2.2 Create or Modify Team

This screen will allow the USER to input and change information about a user (i e. name, E-mail address, etc.)

2.2.2 Create or Modify Team

Screen Label Screen Field Name Jata Field Name Screen Specific Rule

Confidential Enterprise Rent-A-Car © 2000 10 http //ιntranet dm2/ReadDocOrLιnk ASP'Fold.rID=2706&DoclD=1069₄ Issue: 1.2

Maintain User Issue Date: 10/20/00

2.2.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.2.3.1 A -Z Anchor Links

When any ofthe letters are clicked, the list of users should position itself with that letter presented at the top ofthe user view area on the page.

2.2.3.2 Teams Link

When the team link is clicked, the list of teams should position itself at the top ofthe view area on the page. The list of teams should be placed last in the list of all users/teams.

2.2.3.3 Process

When the Process button is clicked, the system should check to see that the appropriate information was entered in order to create a new team (Office, Team Name). If the information is entered, the system will create a new team with those attributes and the other user attributes defaulted. The system should then display the new team's profile.

Confidential Enterprise Rent-A-Car © 2000 bttD.-//intranefdm2/ReadDooOrLink.ASP?FolderID=2706&Doc!D=1069 Issue: 1.2 Maintain User Issue Date: 10/20/00

2.3 User Profile

This screen will allow the USER to input and change information about a user (i.e. name, E-mail address, etc.)

2.3.1 Screen Layout

Confidential Enterprise Rent-A-Car © 2000 12 http://intranet dm2 ReadDocOrLink.ASP?FolderID=2706&DocID=1069 Issue: 1.2

Maintain User Issue Date. 10/20/00

2.3.2 UserPmfile

Screen Field Name Data Field Name Screen Specific Rule

Reset Password Check Box Reset Password Indicator

Confidential Enteronse Rent-A-Car © 2000 13 httD //ϊntranet dm2/ eadDocOr mk ASP'FolderrD=2706&DoclD=10694 Issue: 1.2

Maintain User Issue Date: 10/20/00

B5H5SSB_ Screen Field Name Data Field Name πjMgJiRl

2.3.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

Confidential Enteφrise Rent-A-Car © 2000 14 http://intanetfdm2/R.adDocOrUnk.ASP?FoId-rID=2706&Docπ 10694 Issue: 1.2 Maintain User Issue Date: 10/20/00

2.3.3. Process

When clicked, the system will ensure that all rules on the page are enforced. Upon completion, the system will return the USER to the Create a New User / Team page.

2.3.3.1.1 The user must have a First Name, Last Name and Home Office entered. The Home Office must be a valid office for that company.

2.3.3.1.2 Work Authority for each user will default to all enabled.

2.3.3.1.3 If the Active switch has been set to inactive, the system will check to see if the user owns any open work. If the user owns work, the system will not allow the user to be set to inactive. The system will notify the USER that the user has open work assigned to them and request that they transfer the work before attempting to inactivate the user.

2.3.3.1.4 If the reset password option is set, the system will reset the user's password. This will reset the user's password to the password used for new users. Need to verify what that password is.

2.3.3.1.5 If the File Ownership flag is turned off, the system will check to see if the user owns any open work. If the user owns work, the system will not allow the file ownership flag to be turned off. The system will notify the USER that the user has open work assigned to them and request that they transfer the work before attempting to turn off file ownership.

Confidential Enterprise Rent-A-Car © 2000 15 http-//intranet/dm2 ReadDocOrLin ASP?FoIderID=2706&DooID=1069₄ Issue: 1.2

Maintain User Issue Date: 10/20/00

2.4 Team Profile

This screen will allow the USER to input and change information about a user (i.e. name, E-mail address, etc.)

2.4.1 Screen Layout

Confidential Enterprise Rent-A-Car © 2000 16 http://intranet d 2 ReadDocOrLink.ASP''FolderlD=2706&DocID=10694 Issue: 1.2

Maintain User Issue Date: 10/20/00

2.4.2 Create or Modify Team iiMWU.l_M.Hl Siz Screen Field Name Data Field Name IjiMgJJg

2.4.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.4.3.1 Process

When clicked, the system will ensure that all rules on the page are enforced. Upon completion, the system will return the USER to the Create a New User / Team page.

2.4.3.1.1 The team must have a Team Name and Home Office entered. The Home Office must be a valid office for that company.

2.4.3.1.2 If the Active switch has been set to inactive, the system will check to see if the team owns any open work. If the team owns work, the system will not allow the team to be set to inactive. The system will notify the USER that the team has open work assigned to them and request that they transfer the work before attempting to inactivate the team.

2.4.3.1.3 If the File Ownership flag is turned off, the system will check to see if the team

Confidential Enterprise Rent-A-Car © 2000 17 http://intraπet dm2/ReadDocOrLink.ASP?FolderID=2706&DocID=1069 Issue: 1.2 Maintain User Issue Date: 10/20/00 owns any open work. If the team owns work, the system will not allow the file ownership flag to be turned off. The system will notify the USER that the team has open work assigned to them and request that they transfer the work before attempting to turn off file ownership. If the user or team does not receive File Ownership, that user or team will not display in the Handle For list.

Confidential Enterprise Rent-A-Car © 2000 18 http://intranet dm2«eadDocOr ink.ASP?FolderID=2706&DoclD= 10694 Issue: 1.2 Maintain User Issue Date: 10/20/00

3. Application Operations

This section will detail all the application operations that are part of this Functional Specification Document.

3.1 Build list of Users

(Office Id, First Name, Last Name, User ID)

Build a list of User first and last names NOT limited to a given office in order to search for a user. Limited by the first or last name passed.

3.2 Find User Information

(User Id)

Retrieve the current values for a user's profile.

3.3 Update User Information

(User Id, Name, e-mail Address, Out of Office, Handler for out of office user, Initial Page, Is user Multi-company, Is User Active, Current Password, New Password, Receive Authorization Assignment)

Update the given data values for the user profile.

3.4 Build list of User offices

(User Id)

Build a list of office names forthe offices the user is assigned to.

3.5 Find User Office Information (User Id, Office Id)

Retrieve the current values assigned for the user at a given office.

3.6 Update User Office Information

(User Id, Office Id, and data values)

Update the given data values for the user profile.

3.7 Add User Office Information (User Id, Office Id)

Assign user access to another office. Default values are set for the users access.

3.8 Remove User Office Information (User Id, Office Id)

Revoke assignment ofthe user to an office. The user cannot be revoked from their primary office

3.9 Build a list of users to which the administrator has access

(Company ID, Administrator ID, User ID)

Build a list of User first and last names limited to a given office in order to maintain a user. Limited by the first or last name passed.

3.10 Validate that User ID does not exist (User ID)

Verify that the administartor must add a new user.

Confidential Enteφrise Rent-A-Car © 2000 19 http://intranet/dm2/ReadDocOrLink.ASP?FolderID=2706&DocID=1069₄ Issue: 1.2 Maintain User Issue Date: 10/20/00

Data Fields

4.1 Data Field Definition

This section includes a defmition of all data fields included in the functional specification.

4.1.1 User Language Preference

This is the user's language preference while working with the ARMS Web System.

Data Field Type: Alpha-Numeric

Data Field Length: 10

Data Source: <Data Source>

4.1.2 Phone Number

This is the user's phone number.

Data Field Type: Alpha-Numeric

Data Field Length: 10

Data Source: <Data Source>

4.13 Profile Attribute Id

LS. assigned identifier for a profile attribute. Must be unique and non-blank. Each profϊlable item will have a profile attribute.

Data Field Type: Alpha-Numeric

Data Field Length: 20

Data Source: <Data Source>

4.1.4 Last Name

This is the last name ofthe user.

Data Field Type: Alpha-Numeric

Data Field Length: 20

Data Source: <Data Source>

4.1.5 Handler for out of office user

This is the user who will handle work for the user who is out of office.

Data Field Type: Alpha-Numeric

Data Field Length: 0

Data Source: <Data Source>

4.16 Start Page

This is the initial page that the user will see when he logs on to the system.

Data Field Type: URL

Data Field Length: 256

Data Source: <Data Source>

Confidential Enteφrise Rent-A-Car © 2000 20 httρ://intr-neydm2/ReadDooOrLink.ASP?FolderID=2706&Do-ID=1069 Issue: 1.2 Maintain User Issue Date: 10/20/00

4.7.7 Is user out of office ?

This flag indicates that the user is out of office and no work should be assigned to them. Instead another user can be set up to handle for the user who is out of office.

Data Field Type: Boolean

Data Field Length: 1

Data Source: <Data Source>

4.1.8 Is the user multicompany ?

This flag indicates that this user can do work for multiple insurance companies. These are typically Enteφrise Rent-A-Car employees working on site at an insurance company office or Rental Management Services employees who are also Enterprise employees who manage rentals for the insurance company but are not on site.

Data Field Type: Boolean

Data Field Length: 1

Data Source: <Data Source>

4.1.9 Can user receive work ?

This flag indicates that user can receive work (e.g. requests for authorization, requests for extension etc.). Typically, a manager would set this flag to "No" so that work would not be assigned to him or her although he or she could be notified in certain situations like authority limit exceeded etc..

Data Field Type: Boolean

Data Field Length: 1

Data Source: <Data Source>

4.170 Is User Active ?

This flag indicates the user is currently active and may log on to the system to do work.

Data Field Type: Boolean

Data Field Length: 1

Data Source: <Data Source>

4.1.11 Email Address

This is the email address ofthe user.

Data Field Type: Alpha-Numeric

Data Field Length: 30

Data Source: <Data Source>

4.7.72 First Name

This is the first name ofthe user.

Data Field Type: Alpha-Numeric

Data Field Length: 15

Data Source: <Data Source>

Confidential Enteφrise Rent-A-Car © 2000 21 http://intranet/dm2/ReadDocθrLink.ASP?FolderID=2706&DocID=1069₄ Issue: 1.2 Maintain User Issue Date: 10/20/00

4.7.73 Password

This is the user specified password that the user will use along with the user id to log on to the ARMS Web System.

Data Field Type: Password

Data Field Length: 10

Data Source: <Data Source>

4.7.74 User Id

This is the user id that the user will use to sign on to the ARMS Web System. This id must be unique across the whole system.

Data Field Type: Alpha-Numeric

Data Field Length: 10

Data Source: <Data Source>

Confidential Enterprise Rent-A-Car © 2000 22 http://intranet/dπι₂ ReadDocOr ink.ASP?FolderID=2706&DocID=1069₄ Issue: 1.2

Maintain User Issue Date: 10/20/00

5. Questions and Answers

Issue Number: 321

Question: When do we "Kill" profiles that have been created but not used? Question 2 - Do we allow for deleting users, and if so, who would handle this function? Question 3 - Do we allow for deleting inactive user, and if so, who would handle this function?

Status: Closed - Resolved

Resolution: 3-21-00, Dave Smith - The other questions would seem to have procedures in place today. Unless there is a compelling reason, I don't think we should reinvent the wheel. Could you check with the ARMS team to find out? 08-07-00 - Brad Reel: UserlDs that were created, but never accessed will be made inactive after six months. UserlDs that have not been accessed for two years will also be made inactive. After being made inactive, they will be purged after three additional months.

Issue Number: 322

Question: Do we allow for deleting users, and if so who would it be that does so?

Status: Closed - Merged

Resolution: 3-21-00, Dave Smith - The other questions would seem to have procedures in place today. Unless there is a compelling reason, I don't think we should reinvent the wheel. Could you check with the ARMS team to find out? 3- 27-00, merged with Issue 321

Issue Number: 323

Confidential Enterprise Rent-A-Car © 2000 23 h«pι'/inlraπel dm2/ReadDocOr iι_-ASP?FoWerII>=2705&DocID=1069₄ Issue: 1.2

Maintain User Issue Date: 10/20/00

Question: When do we delete an inactive user? And who would handle?

Status: Closed - Merged

Resolution: 3-21-00, Dave Smith - The other questions would seem to have procedures in place today. Unless there is a compelling reason, I don't think we should reinvent the wheel. Could you check with the ARMS team to find out?3- 27-00, merged with issue 321

Issue Number: 324

Question: User ID: Do we have current Enterprise Business rules that we need to enforce, and if so, what are they? The assumption we made when discussing this was that the admin could give them whatever ID the user desired. If user wanted the ID Beavis, the admin could create it. The question is, are there some rules we want to enforce (i.e. User ID's start w/ first three characters of insurance company's name, GEI for GEICO) and some defaults for both UseriD & Password? Maybe for GEICO, the first user is GEI0001 and the default password is GEICO. Just something we need to address.

Status: Closed - Resolved

Resolution: 3-22-00, Dave Smith - 1 think we should give them whatever user ID they want.

3-30-00. Kim DeVallance - user ID is a company specific item. For example, GEICO's is their associate ID (similar to our employee number). Progressive uses their PACMAN ID, Nationwide uses their RACF ID...all a similar concept. It is an ID that the adjuster is familiar with and I think we should allow the customer to use an employee number already familiar to the adjuster. 4-7-00, Issue Mtg, the field is 10 characters, First three will be company driven, the next 7 can be alpha/num and the users choice. 4-11-00, Brad Reel - Current State, ID's are first three characters of the company's name, and up to seven numeric characters. Could possibly expand to seven alpha-numeric instead of just numeric. Barring any disagreement, we will suggest the following in the ARMS Web system: first three characters of the company's name are the first three characters of the ID. Then the ID must include at least 4 alpha-numeric characters with at least one number in it. The minimum ID length would be 7 characters, the maximum 10. Suggest we try to force companies to use their employee IDs as the seven digits. ARMS Web system can generate a number if necessary.

Confidential Enterprise Rent-A-Car © 2000 24 httpΛιntr-net dm2/ReadDocθr ink.ASP?FolderID=2706&Do_ID=1069 Issue: 1.2

Maintain User Issue Date: 10/20/00

Need to confirm with our security people that this is acceptable security on an Enterprise-owned application. Also, should consider whether or not we think first three chracters of a company's name will allow us to always uniquely identify companies.

Issue Number: 325

Question: Current State we capture the primary address for the user, (the address the user (adjuster) is located at) do we want to do the same in future state? In the screen prototype should the primary user (adjuster) address be capture in the user profile screens, given that we currently have an office address in the office profile?

Status: Closed - Resolved

Resolution: 3-30-00, Kim DeVallance - Kim-I do not think it is necessary for the ARMS/Web application, but it may be a mandatory field for the ARMS system when it processes info. I would recommend checking with the analysts from ARMS. We pull the address from ECARS when we send a paper bill, and if the bill is electronic, the address does not matter.

4-7-00, Issue Mtg, Default to office address, allow at the user level to be changed, if it is changed it will only update the database not the 400. 4-11-00, Brad Reel - When creating a user, we need to capture a user-specific address. It should default to the primary office they are assigned to when they are first created, but be changeable. This means we have to change the process for adding a user so we identify their primary office before we enter address information.

Issue Number: 326

Question: Can a user be maintained at more than one office? Do we still have a default/primary office when the user is created?

Example: You have been created at the St. Louis Office and you need to travel to California to help with a disaster, does California have the rights to maintain you.

Confidential Enteφrise Rent-A-Car © 2000 25 http://mtr_net/dnι2/ReadDocOrLink.ASP?FolderID=2706&DocID=1069 Issue: 1.2

Maintain User Issue Date: 10/20/00

Status: Closed - Resolved

Resolution: 3-22-00, Dave Smith - For tracking purposes, I think we need to maintain one profile only. If someone moves to another location because of a disaster, we should move the profile to that office. Perhaps to make it easy on the transition, we could transfer their base profile and let the new office modify accordingly.

3-27-00, Ask Brad to follow-up with Dave Smith.

3-30-00, Kim DeVallance - Current state, yes a user can be maintained at more than one office, but a user should have a primary office.

Issue Number: 327

Question: Do we need a primary office at which you see all work below you? This would apply only to people who were in offices that were not claims offices. Example: I am a regional VP (wouldn't that be cool) and I want to use the system. I define "Default One" as my region, so when I look at stuff in the system an I see all the offices under my office as my default.

Status: Closed - Resolved

Resolution: 3-22-00, Dave Smith - Yes, I think this a good enhancement. 3-30-00, Kim DeVallance - This would be great!!!

Issue Number: 328

Question: Do we need a primary office that you can create work at? This would apply to everyone and defines the primary office I can create work in. For an Adjuster, this would be their primary office. For someone at a higher level, it would be the office they assign work to if they create it. Following the example above, if that VP creates a res (unlikely, but work with me), this default would be the claims office it would be sent to for completion.

Confidential Enterprise Rent-A-Car © 2000 26 http://intranet/dm2 ReadDocOrLink.ASP'>FolderID=2706&DoclD=1069 Issue: 1.2

Maintain User Issue Date: 10/20/00

Status: Closed - Resolved

Resolution: 3-22-00, Dave Smith - Yes, I think this a good enhancement as well. 3-30-00, Kim DeVallance - Yes, but keep in mind during the life of a rental we can transfer the rental to different offices within the same company profile.

Issue Number: 329

Question: Where does the manager get assigned to a user? At the Office Level, the User Level or the Team level? Can a user have more than one manager?

Status: Closed - Resolved

Resolution: 08-08-00 - Brad Reel: Upon further discussion with the business, the process for selecting a person to handle an authorization limit is as follows: When a user hits an authorization limit, the system will request that the user select another user to approve the request and handle the rental. The system will only present users that have limits higher than the requested amount/number of days. Once the user has been selected, the rental will then be permanently transferred to the chosen user.

Issue Number: 331

Question: Under Report Layout section, is this for the office to give the user what fields that they want them to see? Then the user can set how he views these fields in MY PROFILE?

Status: Closed - Resolved

Resolution: 3-21-00, Anita Klopfenstein - It allows the user to create a default report layout as well as establish groupings. For example: I may want a team group which allows me to select adjusters to view. However, this would be a function which had to be approved in the profile of the user. Otherwise they can

Confidential Enterprise Rent-A-Car © 2000 27 http://intranet/dm2/ReadDocOrLink.ASP?FolderID=2706&DocID=1059₄ Issue: 1.2

Maintain User Issue Date: 10/20/00 only see their work.

Issue Number: 332

Question: Are the authorization limits for the life of the rental or the transaction, (as applied to use by an adjuster)

Status: Closed - Resolved

Resolution: 3-21-00, Anita Klopfenstein - Both - There is a daily limit and a rental max.

For the life of the rental.

Issue Number: 350

Question: Do we want to force a search before and admin can add a user?

Status: Closed - Resolved

Resolution: 08-07-00 - Brad Reel: When adding a user, the system will search for the UseriD and ensure it does not exist. No other searches will be performed.

Issue Number: 352

Question: Where does the ability to change the language the user can view the screens in reside? With the Admin or the user?

Confidential Enterprise Rent-A-Car © 2000 28 http://intranet/dm2/ReadDocOrLink.ASP?FolderID=2706&DocID=1069₄ Issue: 1.2

Maintain User Issue Date: 10/20/00

Status: Deferred

Resolution:

Issue Number: 356

Question: When setting up a user, should the office profile restrict the user's profile? Or are the office and user profiles independent of each other?

Status: Closed - Resolved

Resolution: 08-07-00 - Brad Reel: Office profile overrides user profile. A user can have more rights than the office, but will still be restricted to only activities that can be performed in that office based on the office profile while they are working in that office.

Issue Number: 360

Question: Brad Decoder, Password/ do we send e-mail to the admin to let them know how many times login failed?

Status: 12 User Review

Resolution:

Issue Number: 365

Confidential Enteφrise Rent-A-Car © 2000 29 http://intranet/dm2 ReadDocOrLink.ASP?FolderID=2706--DooID-1069 Issue: 1.2 Maintain User Issue Date: 10/20/00

Question: Do we need a batch process for adding users?

Status: Closed - Resolved

Resolution: 07-03-00 - Brad Reel: This question has also been asked in the more general setting of "Should a process exist for walking a user through setting up an entire company (much like a wizard tool)." For this release of ARMS Web (V2.0) a batch process for creating users will not be created. There will also not be a wizard for creating a company. However, for future releases, this wizard will be a very worthwhile tool to create and should be incorporated into future releases.

Confidential Enteφrise Rent-A-Car © 2000 30 httpΛmtranet/dm2/ReadDocOrLink.ASP?FolderID=2706&0ocII 1069 Enterprise Rent-A-Car

Functional Design Specification

Maintain User

Version 1.3

Last Saved: 8/18/00 1:02 PM

Issue: 1.2

Maintain User Issue Date: 10/20/00

Revision History

Confidential Enterprise Rent-A-Car © 2000 httpΛintranet dm2/ReadDocθr inl_ASP?FoIdnlD=₂706&DocID=1069 Issue: 1.2 Maintain User Issue Date: 10/20/00

Table of Contents

1. Maintain User Use Case 4

1.1 Brief Description 4

1.2 Use Case Actors 4

1.3 Pre-Conditions ⁴

1.4 Flow of Events 4

1.4.1 Activity Diagram ⁵

1.4.2 Basic Flow ⁶

1.4.3 Alternative Flows 6

1.5 Post-Conditions 7

1.6 Special Requirements

1.6.1 User Inactivation 7

1.6.2 User Default Settings 7

1.7 Extension Points 7

2. Screen Design 8

2.1 Create or Modify User 8

2.1.1 Screen Layout 8

2.1.2 Create or Modify User 8

2.1.3 Screen Function Definition 9

2.2 Create or Modify Team 10

2.2.1 Screen Layout 10

2.2.2 Create or Modify Team 10

2.2.3 Screen Function Definition 11

2.3 User Profile 12

2.3.1 Screen Layout 12

2.3.2 User Profile 13

2.3.3 Screen Function Definition 14

2.4 Team Profile 16

2.4.1 Screen Layout 16

2.4.2 Create or Modify Team 17

2.4.3 Screen Function Definition 17

3. Application Operations 19

3.1 Build list of Users 19

3.2 Find User Information 19

3.3 Update User Information 19

3.4 Build list of User offices 19

3.5 Find User Office Information 19

3.6 Update User Office Information 19

3.7 Add User Office Information 19

3.8 Remove User Office Information 19

3.9 Build a list of users to which the administrator has access 19

3.10 Validate that User ID does not exist 19

4. Data Fields 20 4.1 Data Field Definition 20

4.1.1 User Language Preference 20

4.1.2 Phone Number 20

4.1.3 Profile Attribute Id 20

4.1.4 Last Name 20

Confidential Enterprise Rent-A-Car © 2000 " http^/intι_net/d 2/ReadIX>cθrLinl_ASE Folderπ 2706--Docir =10-9 Issue: 1.2

Maintain User Issue Date: 10/20/00

4.1.5 Handler for out of office user 20

4.1.6 Start Page 20

4.1.7 Is user out of office ? 21

4.1.8 Is the user multicompany ? 21

4.1.9 Can user receive work ? 21

4.1.10 Is User Active ? 21

4.1.11 Email Address 21

4.1.12 First Name 21

4.1.13 Password 22

4.1.14 User Id 22

5. Questions and Answers 23

Confidential Enterprise Rent-A-Car © 2000 ht Λintr__ιet d 2/ReadI>3cOrLink.ASP?FolderID=₂706&DocIE)=10694 Issue: 1.2 Maintain User Issue Date: 10/20/00

Maintain User

Maintain User Use Case

1.1 Brief Description

The Maintain User use case describes how a USER would set up or maintain a user in the ARMS Web system.

1.2 Use Case Actors

The following actors will interact with this use case:

• ENTERPRISE ADMINISTRATOR - The ENTERPRISE ADMINISTRATOR is a person who can perform this use case to set up any user in a company.

• COMPANY ADMINISTRATOR - The COMPANY ADMINISTRATOR is aperson who can perform this use case for the company. They may add users and assign them to office(s) that they are the administrator of within the company.

• OFFICE ADMINISTRATOR - The OFFICE ADMINISTRATOR is a person who can perform this use case for the company. The OFFICE ADMINISTRATOR may maintain any user in their company structure to which they have been assigned ownership.

1.3 Pre-Conditions

• The USER must be logged into the system.

• . If maintaining a user, the USER should have the ability to maintain that user. In order to maintain a user at a specific office, the ADMINISTRATOR must have access to that specific office.

• If adding a user, the USER should have the ability to add a user.

1.4 Flow of Events

The Flow of Events will include all the steps necessary to add or maintain a company user in the ARMS Web system.

Confidential Enterprise Rent-A-Car © 2000 httpΛinti-net dra2/ReadDocOrUnI_ASP?FoIderlI 2706&Do-lI⁾=1069 Issue: 1.2

Maintain User Issue Date: 10/20/00

1.4.1 Acϋvity Diagram

Maintain User Activity Diagram

Y:\APPS\#ARMS eb\Application\@dkb\ARMSWeb\ReleaseOne\PR-Profiling\PR-05-Maintain

9/1 /00 UsertACTIVITY DIAGRA S\PR-05 MAINTAIN USER.VSD

Confidential Enterprise Rent-A-Car © 2000 httpΛ tιa-e-'dm_/R«adDocθrUn .ASπFoIderII ₂706&DocID=10694 Issue: 1.2 Maintain User Issue Date: 10/20/00

1.4.2 Basic Flow

The Basic Flow will describe how a USER will maintain a user in the ARMS Web system.

1. The USER will choose to maintain user(s).

2. The system will present a list of all users that are in all the offices the USER has access to maintain.

3. The USER will choose a user to maintain.

4. The system will display the user's information for the USER to edit.

5. The USER will update the user's information and submit the information to the system.

6. The system will validate the information entered.

7. The system will update the ARMS Web database.

8. This ends the use case.

1.4.3 Alternative Flows

1.4.3.1 Add User

At step three in the Basic Flow, the USER may choose to add a user, if they have the authority level to do so. The USER will enter a primary office, UseriD, First Name and Last Name for the new user. The system will then validate that the office was entered and the UseriD does not exist. If a UseriD match is found, or the office was not entered, the system will display an error and request the USER enter a new UseriD. Otherwise, the system will display the default settings for a new user, the USER will update the default settings and submit the information to the system. The system will validate the information entered, and update the ARMS Web database. The use case is then complete.

1.4.3.2 Show All Users for the Company

At step three in the Basic Flow, the USER may choose to display all users within the company. This would allow for adding users to offices the USER controls. The USER will choose the user they wish to work with and the system will then display the user's information; the USER will add the user to any offices the USER controls and submit the information to the system. The system will validate the information entered, and update the ARMS Web database. The use case is then complete.

1.4.3.2.1 If a user's primary office is not an office controlled by the USER, the USER may only add the user to offices the USER controls. The USER should not be able to change any ofthe user's settings. A USER that has control of a user's primary office can only change user settings.

1.4.3.3 User Information Validation Fails

In step six ofthe Basic Flow, the system may find that user information entered by the USER does not meet the validation criteria. The system should return the USER to step four ofthe Basic Flow, show the USER the invalid data, and prompt the USER to reenter the data.

This rule also applies for new user creation. Whenever a new user is submitted to the system for creation, the system must validate that the criteria entered is valid. If any information is invalid, the system should present the invalid date to the USER, and prompt the user to correct it.

1.4.3.3.1 The following fields must be populated to complete a user update or new user creation.

• Last Name

• First Name

• UseriD (Must be validated to ensure it is not a duplicate ID)

• Home Office (Must be a valid office and not null)

1.4.3.4 Cancel Add / Maintain User

Until step five in the Basic Flow, the USER may choose to cancel the use case. The system

Confidential Enterprise Rent-A-Car © 2000 6 htrp://intr_net/dm2 RradDocOrLin .ASP?FolderIE>=2706&D-clD=10694 Issue: 1.2 Maintain User Issue Date: 10/20/00 should not store any changes made by the USER within the use case.

1.5 Post-Conditions

• If the use case was successful and the USER was maintaining a user, the user criteria being changed will have been changed and updated in the ARMS Web system.

• If the use case was successful and the USER was adding a user, the user will have been added in the ARMS Web system.

• If the use case was unsuccessful, the system state will be unchanged.

1.6 Special Requirements

1.6.1 User Inactivation

In order to inactivate a user, the following set of criteria must be validated. If any ofthe criteria are found to be true, then the system will not allow the USER to inactivate the user.

• If A4XREFL1/X4STCD is equal to ^SC (closed rental) and any tickets were closed in the past seven days

• If A4XREFL1 X4STCD is equal to 'A' (audited invoice)

• If A4XREFL1/X4STCD is equal to 'R' (reservation)

• If A4XREFL1/X4STCD is equal to 'O' (open contract)

• If A4XREFL1/X4STCD is equal to 'U' (unconfirmed) and A4XREFL1 X4RSFG is equal to 'D' (Direct Bill request)

• If A4XREFL1/X4STCD is equal to 'Z' (sent) and A4XREFL1/X4RSFG is equal to 'C (extension request & message sent)

• If A4XREFL1/X4STCD is equal to 'Z' (sent) and A4XREFL1/X4RSFG is equal to 'M' (authorization message sent)

• If A4XREFL1/X4STCD is equal to 'Z' (sent) and A4XREFL1 X4RSFG is equal to 'X' (extension request sent)

• If A4XREFL1/X4STCD is equal to 'B' (authorized invoice) and A4XREFL1/X4RSFG is equal to 'B' (invoice sent from ARMS)

• If A4XREFL1/X4STCD is equal to 'B' (authorized invoice) and A4XREFL1 X4RSFG is equal to 'R' (invoice returned to adjuster)

• If A4XREFL1/X4STCD is equal to 'B' (authorized invoice) and A4XREFL1/X4RSFG is equal to 'E' (rejected system error)

• If A4XREFL1 X4STCD is equal to 'B' (authorized invoice) and A4XREFL1/X4RSFG is equal to 'Q' (rejected invoice ARMS researching)

1.6.2 User Default Settings

Whenever a new user is created, the settings for that user should be defaulted based on the user's primary office profile settings. For example, if the office is a reservation only office, the user should default to reservation only. This does not imply that the administrator cannot change the settings. This should also apply to whether can receive work setting should be on or off for the user/team. If all other users/teams in the office have the setting either on or off, then the new user should mimic this setting. Once again, this does not imply that the administrator cannot change this setting.

1.7 Extension Points

None.

Confidential Enterprise Rent-A-Car © 2000 http^/intran-t/dra2 ReadDocOrLin .ASP?FoIderID=2706--DoclD=1069 Issue: 1.2

Maintain User Issue Date: 10/20/00

Screen Design

A definition ofthe screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 Create or Modify User

This screen will allow the USER to search for and select a user to modify or select to add a new user.

2.1.2 Create or Modify User screen Field Name Data Field Name Screen Specific Rule

Confidential Enterprise Rent-A-Car © 2000 httpΛintranet dra2/ReadDocOrLink.ASP?FolderID=2706-.DocID=10694 Issue: 1.2

Maintain User Issue Date: 10/20/00

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.13. A - Z Anchor Links

When any ofthe letters are clicked, the list of users should position itself with that letter presented at the top ofthe user view area on the page.

2.1.3.2 Teams Link

When the team link is clicked, the list of teams should position itself at the top ofthe view area on the page. The list of teams should be placed last in the list of all users/teams.

2.13.3 Process

When the Process button is clicked, the system should check to see that the appropriate information was entered in order to create a new user (Office, Last Name, First Name UseriD). If the information is entered, the system will create a new user with those attributes and the other user attributes defaulted. The system should then display the new user's profile.

Confidential Enterprise Rent-A-Car © 2000 http^/intranctf mΣ/ReadDocOrLink. ASP?FolderII =2706&DocID= 10694 Issue: 1.2

Maintain User Issue Date: 10/20/00

2.2 Create or Modify Team

This screen will allow the USER to input and change information about a user (i.e. name, E-mail address, etc.)

-Lall.lU.l-fllflBl Screen Field Name Data Field Name Screen Specific Rule

Confidential Enterprise Rent-A-Car © ₂000 10 httprfintr_n-fdm2 Rc_dDo-Or ink. ASP?FoMcrID=2706&DocI_>= 106M Issue: 1.2

Maintain User Issue Date: 10/20/00

2.2.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.2.3.1 A - Z Anchor Links

When any ofthe letters are clicked, the list of users should position itself with that letter presented at the top ofthe user view area on the page.

2.2.3.2 Teams Link

When the team link is clicked, the list of teams should position itself at the top ofthe view area on the page. The list of teams should be placed last in the list of all users/teams.

2.2.3.3 Process

When the Process button is clicked, the system should check to see that the appropriate information was entered in order to create a new team (Office, Team Name). If the information is entered, the system will create a new team with those attributes and the other user attributes defaulted. The system should then display the new team's profile.

Confidential Enterprise Rent-A-Car © 2000 http://intranet/dm2ΛeadDocOrLiιιk.ASP?FolderI! '2706&DocID=I0694 Issue: 1.2 Maintain User Issue Date: 10/20/00

2.3 User Profile

This screen will allow the USER to input and change information about a user (i.e. name, E-mail address, etc.)

2.3.1 Screen Layout

Confidential Enterprise Rent-A-Car © 2000 12 httpΛntιanet ⁽hn₂ ReadIXcOrLiι_ ASP?FolderID=2706&DocID=1069₄ Issue: 1.2

Maintain User Issue Date: 10/20/00

2.3.2 UserProWe

Confidential Enterprise Rent-A-Car © 2000 13 hrtp://inti-net dnι2 ReadDocθrLinl-ASP?FolderII =2706--DocII 10694 Issue: 1.2

Maintain User Issue Date: 10/20/00

Siz Screen Field Name reiaigr.isETTϊi. ■aaEECTarergffliisfflE.

2.3.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

Confidential Enterprise Rent-A-Car © 2000 14 htlpΛintranet dm2 ReadDocθr in .ASP?FoldcrII 2706&Do.lD=I0694 Issue: 1.2 Maintain User Issue Date: 10/20/00

2.3.3.1 Process

When clicked, the system will ensure that all rules on the page are enforced. Upon completion, the system will return the USER to the Create a New User / Team page.

2.3.3.1.1 The user must have a First Name, Last Name and Home Office entered. The Home Office must be a valid office for that company.

2.3.3.1.2 Work Authority for each user will default to all enabled.

2.3.3.1.3 If the Active switch has been set to inactive, the system will check to see if the user owns any open work. If the user owns work, the system will not allow the user to be set to inactive. The system will notify the USER that the user has open work assigned to them and request that they transfer the work before attempting to inactivate the user.

2.3.3.1.4 If the reset password option is set, the system will reset the user's password. This will reset the user's password to the password used for new users. Need to verify what that password is.

2.3.3.1.5 If the File Ownership flag is turned off, the system will check to see if the user owns any open work. If the user owns work, the system will not allow the file ownership flag to be turned off. The system will notify the USER that the user has open work assigned to them and request that they transfer the work before attempting to turn off file ownership.

Confidential Enterprise Rent-A-Car© 2000 15 http://inha-ιe-^,dm2/ReadDocOrLin .ASP?Fo^]dcrtD=2706--D_-ID=1069₄ Issue: 1.2

Maintain User Issue Date: 10/20/00

2.4 Team Profile

This screen will allow the USER to input and change information about a user (i.e. name, E-mail address, etc.)

2.4.1 Screen Layout

Confidential Enterprise Rent-A-Car © 2000 16 http://intπιnct/dm2/ReadDocOι ink.ASP?FolderII =2706-lDocII⁾=1069 Issue: 1.2

Maintain User Issue Date: 10/20/00

2.4.2 Create or Modify Team

.,BBH.H«IW Siz Screen Field Name Data Field Name Screen Specific Rule

2.4.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.4.3.1 Process

When clicked, the system will ensure that all rules on the page are enforced. Upon completion, the system will return the USER to the Create a New User / Team page.

2.4.3.1.1 The team must have a Team Name and Home Office entered. The Home Office must be a valid office for that company.

2.4.3.1.2 If the Active switch has been set to inactive, the system will check to see if the team owns any open work. If the team owns work, the system will not allow the team to be set to inactive. The system will notify the USER that the team has open work assigned to them and request that they transfer the work before attempting to inactivate the team.

2.4.3.1.3 If the File Ownership flag is turned off, the system will check to see if the team

Confidential Enterprise Rent-A-Car © 2000 17 http://intranet/d 2/ReadDocOrLink.ASP?FoldcrID=2706&DocID-1059 Issue: 1.2 Maintain User Issue Date: 10/20/00 owns any open work. If the team owns work, the system will not allow the file ownership flag to be turned off. The system will notify the USER that the team has open work assigned to them and request that they transfer the work before attempting to turn off file ownership. If the user or team does not receive File Ownership, that user or team will not display in the Handle For list.

Confidential Enterprise Rent-A-Car © 2000 http:Mntranet/dm /ReadDocOrLink.ASP?FolderID=2706&DocID-1069 Issue: 1.2 Maintain User Issue Date: 10/20/00

Application Operations

This section will detail all the application operations that are part of this Functional Specification Document.

3.1 Build list of Users

(Office Id, First Name, Last Name, User ID)

Build a list of User first and last names NOT limited to a given office in order to search for a user. Limited by the first or last name passed.

3.2 Find User Information

(User Id)

Retrieve the current values for a user's profile.

3.3 Update User Information

(User Id, Name, e-mail Address, Out of Office, Handler for out of office user, Initial Page, Is user Multi-company, Is User Active, Current Password, New Password, Receive Authorization Assignment)

Update the given data values for the user profile.

3.4 Build list of User offices (User Id)

Build a list of office names for the offices the user is assigned to.

3.5 Find User Office Information (User Id, Office Id)

Retrieve the current values assigned for the user at a given office.

3.6 Update User Office Information (User Id, Office Id, and data values)

Update the given data values for the user profile.

3.7 Add User Office Information (User Id, Office Id)

Assign user access to another office. Default values are set for the users access.

3.8 Remove User Office Information (User Id, Office Id)

Revoke assignment ofthe user to an office. The user cannot be revoked from their primary office

3.9 Build a list of users to which the administrator has access (Company ID, Administrator ID, User ID)

Build a list of User first and last names limited to a given office in order to maintain a user. Limited by the first or last name passed.

3.10 Validate that User ID does not exist (User iD)

Verify that the administartor must add a new user.

Confidential Enterprise Rent-A-Car © 2000 1° htt ^/inlⁱanetdπώyRea DocOr inl-ASPTFolderlD-aTOfi&Docir-^lOβM Issue: 1.2 Maintain User Issue Date: 10/20/00

4. Data Fields

4.1 Data Field Definition

This section includes a definition of all data fields included in the functional specification.

4.1.1 User Language Preference

This is the user's language preference while working with the ARMS Web System.

Data Field Type: Alpha-Numeric

Data Field Length: 10

Data Source: <Data Source>

4. .2 Phone Number

This is the user's phone number.

Data Field Type: Alpha-Numeric

Data Field Length: 10

Data Source: <Data Source>

4.1.3 Profile Attribute Id

LS. assigned identifier for a profile attribute. Must be unique and non-blank. Each profilable item will have a profile attribute.

Data Field Type: Alpha-Numeric

Data Field Length: 20

Data Source: <Data Source>

4.1.4 Last Name

This is the last name ofthe user.

Data Field Type: Alpha-Numeric

Data Field Length: 20

Data Source: <Data Source>

4.1.5 Handler for out of office user

This is the user who will handle work for the user who is out of office.

Data Field Type: Alpha-Numeric

Data Field Length: 0

Data Source: <Data Source>

4.16 Start Page

This is the initial page that the user will see when he logs on to the system.

Data Field Type: URL

Data Field Length: 256

Data Source: <Data Source>

Confidential Enteφrise Rent-A-Car © 2000 20 httpΛintranet d 2/ReadDocOr ink.ASP?FoltlerII =₂706&DocID=1069 Issue: 1.2 Maintain User Issue Date: 10/20/00

4.1.7 Is user out of office ?

This flag indicates that the user is out of office and no work should be assigned to them. Instead another user can be set up to handle for the user who is out of office.

Data Field Type: Boolean

Data Field Length: 1

Data Source: <Data Source>

4.1.8 Is the user multicompany ?

This flag indicates that this user can do work for multiple insurance companies. These are typically Enterprise Rent-A-Car employees working on site at an insurance company office or Rental Management Services employees who are also Enterprise employees who manage rentals for the insurance company but are not on site.

Data Field Type: Boolean

Data Field Length: 1

Data Source: <Data Source>

4.1.9 Can user receive work ?

This flag indicates that user can receive work (e.g. requests for authorization, requests for extension etc.). Typically, a manager would set this flag to "No" so that work would not be assigned to him or her although he or she could be notified in certain situations like authority limit exceeded etc..

Data Field Type: Boolean

Data Field Length: 1

Data Source: <Data Source>

4.1.10 Is User Active ?

This flag indicates the user is currently active and may log on to the system to do work.

Data Field Type: Boolean

Data Field Length: 1

Data Source: <Data Source>

4.1.11 Email Address

This is the email address ofthe user.

Data Field Type: Alpha-Numeric

Data Field Length: 30

Data Source: <Data Source>

4.1.12 First Name

This is the first name ofthe user.

Data Field Type: Alpha-Numeric

Data Field Length: 15

Data Source: <Data Source>

Confidential Enterprise Rent-A-Car © 2000 21 httpΛirιtr_net dm₂/Rea Iλ⁾cOrLin j\SP?FolderID=270<&DcιclD=10-9 Issue: 1.2 Maintain User Issue Date: 10/20/00

4.1.13 Password

This is the user specified password that the user will use along with the user id to log on to the ARMS Web System.

Data Field Type: Password

Data Field Length: 10

Data Source: <Data Source>

4.1.14 User Id

This is the user id that the user will use to sign on to the ARMS Web System. This id must be unique across the whole system.

Data Field Type: Alpha-Numeric

Data Field Length: 10

Data Source: <Data Source>

Confidential Enterprise Rent-A-Car © 2000 22 http-J/intranet/dm2yReadDocOr inlcASP?FolderID=2706&D-clD= 10694 Issue: 1.2

Maintain User Issue Date: 10/20/00

5. Questions and Answers

Issue Number: 321

Question: When do we "Kill" profiles that have been created but not used? Question 2 - Do we allow for deleting users, and if so, who would handle this function? Question 3 - Do we allow for deleting inactive user, and if so, who would handle this function?

Status: Closed - Resolved

Resolution: 3-21-00, Dave Smith - The other questions would seem to have procedures in place today. Unless there is a compelling reason, I don't think we should reinvent the wheel. Could you check with the ARMS team to find out? 08-07-00 - Brad Reel: UserlDs that were created, but never accessed will be made inactive after six months. UserlDs that have not been accessed for two years will also be made inactive. After being made inactive, they will be purged after three additional months.

Issue Number: 322

Question: Do we allow for deleting users, and if so who would it be that does so?

Status: Closed - Merged

Resolution: 3-21-00, Dave Smith - The other questions would seem to have procedures in place today. Unless there is a compelling reason, I don't think we should reinvent the wheel. Could you check with the ARMS team to find out? 3- 27-00, merged with Issue 321

Issue Number: 323

Confidential Enterprise Rent-A-Car © 2000 23 http^/ tranet/dm2 ReadDo-Ort.inl-ASP?Fold-rID=2706&DocII -10694 Issue: 1.2

Maintain User Issue Date: 10/20/00

Question: When do we delete an inactive user? And who would handle?

Status: Closed - Merged

Resolution: 3-21-00, Dave Smith - The other questions would seem to have procedures in place today. Unless there is a compelling reason, I don't think we should reinvent the wheel. Could you check with the ARMS team to find out?3- 27-00, merged with issue 321

Issue Number: 324

Question: User ID: Do we have current Enterprise Business rules that we need to enforce, and if so, what are they? The assumption we made when discussing this was that the admin could give them whatever ID the user desired. If user wanted the ID Beavis, the admin could create it. The question is, are there some rules we want to enforce (i.e. User ID's start w/ first three characters of insurance company's name, GEI for GEICO) and some defaults for both UseriD & Password? Maybe for GEICO, the first user is GEI0001 and the default password is GEICO. Just something we need to address.

Status: Closed - Resolved

Resolution: 3-22-00, Dave Smith - 1 think we should give them whatever user ID they want.

3-30-00. Kim DeVallance - user ID is a company specific item. For example, GEICO's is their associate ID (similar to our employee number). Progressive uses their PACMAN ID, Nationwide uses their RACF ID...all a similar concept. It is an ID that the adjuster is familiar with and I think we should allow the customer to use an employee number already familiar to the adjuster. 4-7-00, Issue Mtg, the field is 10 characters, First three will be company driven, the next 7 can be alpha/num and the users choice. 4-11-00, Brad Reel - Current State, ID's are first three characters of the company's name, and up to seven numeric characters. Could possibly expand to seven alpha-numeric instead of just numeric. Barring any disagreement, we will suggest the following in the ARMS Web system: first three characters of the company's name are the first three characters of the ID. Then the ID must include at least 4 alpha-numeric characters with at least one number in it. The minimum ID length would be 7 characters, the maximum 10. Suggest we try to force companies to use their employee IDs as the seven digits. ARMS Web system can generate a number if necessary.

Confidential Enterprise Rent-A-Car © 2000 24 http:Λiιιtra-et/dm2meadDocOrLiπl_ASP?Fold-rII =2706-.DoclD=10694 Issue: 1.2

Maintain User Issue Date: 10/20/00

Need to confirm with our security people that this is acceptable security on an Enterprise-owned application. Also, should consider whether or not we think first three chracters of a company's name will allow us to always uniquely identify companies.

Issue Number: 325

Question: Current State we capture the primary address for the user, (the address the user (adjuster) is located at) do we want to do the same in future state? In the screen prototype should the primary user (adjuster) address be capture in the user profile screens, given that we currently have an office address in the office profile?

Status: Closed - Resolved

Resolution: 3-30-00, Kim DeVallance - Kim-I do not think it is necessary for the ARMS/Web application, but it may be a mandatory field for the ARMS system when it processes info. I would recommend checking with the analysts from ARMS. We pull the address from ECARS when we send a paper bill, and if the bill is electronic, the address does not matter.

4-7-00, Issue Mtg, Default to office address, allow at the user level to be changed, if it is changed it will only update the database not the 400. 4-11-00, Brad Reel - When creating a user, we need to capture a user-specific address. It should default to the primary office they are assigned to when they are first created, but be changeable. This means we have to change the process for adding a user so we identify their primary office before we enter address information.

Issue Number: 326

Question: Can a user be maintained at more than one office? Do we still have a default/primary office when the user is created?

Example: You have been created at the St. Louis Office and you need to travel to California to help with a disaster, does California have the rights to maintain you.

Confidential Enterprise Rent-A-Car © 2000 25 httpΛintranel/dm2 ReadDo_OrLiιιl_ASP?FoIdcrlD=2706--Do_lI>= 10694 Issue: 1.2

Maintain User Issue Date: 10/20/00

Status: Closed - Resolved

Resolution: 3-22-00, Dave Smith - For tracking purposes, I think we need to maintain one profile only. If someone moves to another location because of a disaster, we should move the profile to that office. Perhaps to make it easy on the transition, we could transfer their base profile and let the new office modify accordingly.

3-27-00, Ask Brad to follow-up with Dave Smith.

3-30-00, Kim DeVallance - Current state, yes a user can be maintained at more than one office, but a user should have a primary office.

Issue Number: 327

Question: Do we need a primary office at which you see all work below you? This would apply only to people who were in offices that were not claims offices. Example: I am a regional VP (wouldn't that be cool) and I want to use the system. I define "Default One" as my region, so when I look at stuff in the system an I see all the offices under my office as my default.

Status: Closed - Resolved

Resolution: 3-22-00, Dave Smith - Yes, I think this a good enhancement. 3-30-00, Kim DeVallance - This would be great!!!

Confidential Enterprise Rent-A-Car © 2000 26 httprf⁾ntr_i^jet/dιιι2 ieadDocOjlii-_ASP?Fo^]dcrlD=270-ΛDocID=10694 Issue: 1.2

Maintain User Issue Date: 10/20/00

Status: Closed - Resolved

Resolution: 3-22-00, Dave Smith - Yes, I think this a good enhancement as well. 3-30-00, Kim DeVallance - Yes, but keep in mind during the life of a rental we can transfer the rental to different offices within the same company profile.

Issue Number: 329

Question: Where does the manager get assigned to a user? At the Office Level, the User Level or the Team level? Can a user have more than one manager?

Status: Closed - Resolved

Resolution: 08-08-00 - Brad Reel: Upon further discussion with the business, the process for selecting a person to handle an authorization limit is as follows: When a user hits an authorization limit, the system will request that the user select another user to approve the request and handle the rental. The system will only present users that have limits higher than the requested amount/number of days. Once the user has been selected, the rental will then be permanently transferred to the chosen user.

Issue Number: 331

Question: Under Report Layout section, is this for the office to give the user what fields that they want them to see? Then the user can set how he views these fields in MY PROFILE?

Status: Closed - Resolved

Resolution: 3-21-00, Anita Klopfenstein - It allows the user to create a default report layout as well as establish groupings. For example: I may want a team group which allows me to select adjusters to view. However, this would be a function which had to be approved in the profile of the user. Otherwise they can

Confidential Enterprise Rent-A-Car © 2000 27 httpΛintr--ιet ⁽ n2/RcadI>κOιLinfcASP?Fo^]derπ)=2706&I⁾-c^]l 10694 Issue: 1.2

Maintain User Issue Date: 10/20/00 only see their work.

Issue Number: 332

Question: Are the authorization limits for the life of the rental or the transaction, (as applied to use by an adjuster)

Status: Closed - Resolved

Resolution: 3-21-00, Anita Klopfenstein - Both - There is a daily limit and a rental max.

For the life of the rental.

Issue Number: 350

Question: Do we want to force a search before and admin can add a user?

Status: Closed - Resolved

Resolution: 08-07-00 - Brad Reel: When adding a user, the system will search for the UseriD and ensure it does not exist. No other searches will be performed.

Issue Number: 352

Question: Where does the ability to change the language the user can view the screens in reside? With the Admin or the user?

Confidential Enterprise Rent-A-Car © 2000 28 htφVΛ^"nti-ne-'dm2 ReadDocOrLink.ASP?FolderID=270_--DocID=10694 Issue: 1.2

Maintain User Issue Date: 10/20/00

Status: Deferred

Resolution:

Issue Number: 356

Question: When setting up a user, should the office profile restrict the user's profile? Or are the office and user profiles independant of each other?

Status: Closed - Resolved

Resolution: 08-07-00 - Brad Reel: Office profile overrides user profile. A user can have more rights than the office, but will still be restricted to only activities that can be performed in that office based on the office profile while they are working in that office.

Issue Number: 360

Question: Brad Decoder, Password/ do we send e-mail to the admin to let them know how many times login failed?

Status: 12 User Review

Resolution:

Issue Number: 365

Confidential Enteφrise Rent-A-Car © 2000 29 httpΛintτanet/dι>-2 eadDo<^Link.ASP?FolderID=2706έa3ocπ)==l()69 Issue: 1.2

Maintain User Issue Date: 10/20/00

Question: Do we need a batch process for adding users?

Status: Closed - Resolved

Resolution: 07-03-00 - Brad Reel: This question has also been asked in the more general setting of "Should a process exist for walking a user through setting up an entire company (much like a wizard tool)." For this release of ARMS Web (V2.0) a batch process for creating users will not be created. There will also not be a wizard for creating a company. However, for future releases, this wizard will be a very worthwhile tool to create and should be incorporated into future releases.

Confidentⁱal Enterprise Rent-A-Car © 2000 30 htlp //iιrtra^jιet/dm2/ReadDocOrLιnk. ASP^*'FolderID=2706&DocID= 10694 Enterprise Rent-A-Car

Functional Design Specification

User Profile

Version 1.0

Last Saved: 8/18/009:53 AM

ARMS Redesign Project - Release 1.0 Issue: 1.0 User Profile Issue Date: 10/20/00

Revision History

Date Issue Description Author

3/29/00 1.0 Combined subdocuments with master Brad Reel, Anil Kabra, document. Gathered data directly from Russ Dittmar, Johnny databases. Sands, Gary Thomae, Deborah Ealick, Cindy Bastean

4/5/00 0.2 Revised per cross-team and intra-team final Cindy Bastean, Deborah evaluations Ealick, Brad Reel

July 6, 2000 1.0 Revised to reflect iteration one review and Brad Reel other items discovered during development.

August 18, 2000 1.0 Updated all issues. Brad Reel

Confidential Enteφrise Rent-A-Car © ₂000 http://intranet/dm2/ReadDocOrLin .ASP?FolderID-2706&DoclD=9765 ARMS Redesign Project - Release 1.0 Issue: 1.0

User Profile Issue Date: 10/20/00

Table of Contents User Profile

1. User Profile Use Case 3

1.1 Brief Description 3

1.2 Use Case Actors 3

1.3 Pre-Conditions 3

1.4 Flow of Events 4

1.4.1 Activity Diagram 4

1.4.2 Basic Flow 5

1.4.3 Alternative Flows 6

1.5 Post-Conditions 7

1.6 Special Requirements 7

1.7 Extension Points 7

2. Screen Design 8 2.1 My Profile 8

2.1.1 Screen Layout - My Profile 8

2.1.2 My Profile 9

2.1.3 Screen Function Definition 9

3. Application Operations 10

3.1 Retrieve User Profile 10

3.2 Update User Profile 10

3.3 Change Password 10

4. Data Fields

4.1 Data Field Definition

4.1.1 Handler for out of office user

4.1.2 Start Page

4.1.3 Is user out of office ?

4.1.4 Password

5. Questions and Answers 12

Confidential Enterprise Rent-A-Car © 2000 http: /intanet/dm2/ReadDocOr ink.ASP?FolderID=2706-.DocID=9765 ARMS Redesign Project - Release 1.0 Issue: 1.0

User Profile Issue Date: 10/20/00

1. User Profile Use Case

1.1 Brief Description

The User Profile use case describes how the USER would customize their working environment. User Profile will allow the USER to change their password, set his or her out of office, and modify their Favorite Locations list.

1.2 Use Case Actors

Actors will use this use case to update their user profile. The following actors will interact with this use case:

ENTERPRISE ADMINISTRATOR

COMPANY ADMINISTRATOR

OFFICE ADMINISTRATOR

CLAIMS MANAGER

ADJUSTER

FIRST NOTICE OF LOSS ADJUSTER

PROCESSOR

1.3 Pre-Conditions

• The company must be enrolled in ARMS Web.

• The USER must be enrolled and have an active User ID and password.

• The USER must be logged into the ARMS Web system.

Confidential Enteφrise Rent-A-Car © 2000 http://intranet dm2/ReadDocOr ink.ASP?FolderlD-2706&DocID=9765 ARMS Redesign Project - Release 1.0 Issue: 1.0 User Profile Issue Date: 10/20/00

1.4 Flow of Events

The Flow of Events will include the necessary steps to make changes and updates to "My Profile"

1.4.1 Activity Diagram

User Profile Activity Diagram

8M/00

Confidential Enterprise Rent-A-Car © 2000 http://intranet dn-> ReadDocOr ink.ASP?FolderID=2706&DocII 9765 ARMS Redesign Project - Release 1.0 Issue: 1.0

User Profile Issue Date: 10/20/00

1.4.2 Basic Flow

1. The USER will choose to edit their User Profile.

2. The system will display the USER'S User Profile

3. The USER will specify the action they would like to perform (user settings, set out of office, add a Favorite Location, remove a Favorite Location, edit a Favorite Location).

4. The USER will select one ofthe options.

5. Based on the USER'S response, one or more ofthe following subflows is executed:

• if the USER chooses to edit a Favorite Location, the Edit Favorite Location Subflow is executed.

• If the USER chooses to add a Favorite Location, the Add Favorite Location Subflow is executed.

• If the USER chooses to remove a Favorite Location, the Remove Favorite Location Subflow is executed.

• If the USER chooses to set the Out of Office Function, the Out of Office Subflow is executed.

• If the USER chooses to Change Password, the Change Password Subflow is executed.

• If the USER chooses Confirmation Page, the Confirmation Page Subflow is executed.

1.4.2.1 Edit Favorite Location Subflow

This subflow allows the USER to edit a location on their Favorite Locations List

1. The USER selects the location they wish to edit from their Favorite Locations List.

2. The USER changes the name they wish to use to identify the location. This is the name that will be displayed to them in their Favorite Locations List.

3. The USER submits the information to the system.

4. The system updates ARMSWeb to reflect the new Favorite Location.

5. The use case ends.

1.4.2.2 Add Favorite Location Subflow

This subflow allows the USER to add a location to the Favorite Locations List.

1. The USER will execute Functional Specification MA-02: Find a Rental Location to search for the location they would like to add to their Favorite Locations List.

2. The USER selects the location they wish to add to their Favorite Locations List.

3. The USER enters the name they wish to use to identify the location. This is the name that will be displayed to them in their Favorite Locations List.

4. The USER submits the information to the system.

5. The system updates ARMSWeb to reflect the new Favorite Location.

6. The use case ends.

1.4.2.3 Remove Favorite Location Subflow

This subflow allows the USER to remove a location from their Favorite Locations List.

1. The USER selects the location they wish to remove from their Favorite Locations List.

2. The USER submits the information to the system.

3. The system updates ARMSWeb to reflect the removal ofthe Favorite Location.

4. The use case ends.

1.4.2.4 Out Of Office Subflow

This subflow allows the USER to select when they are out of office and assigns their workload to another USER.

1. The USER will set choose to be Out of Office

2. The USER will enter the beginning date of when they will be Out of Office.

Confidential Enterprise Rent-A-Car © 2000 5 http://inU_net dro2ReadDocOr ink.ASP?FolderID-2706&;DoclD=9765 ARMS Redesign Project - Release 1.0 Issue: 1.0

Issue Date: 10/20/00 User Profile

3. The USER will choose an alternate USER to handle their work for each office the USER is assigned to.

4. The USER submits the information to the system.

5. The system validates the changes.

6. The system updates ARMSWeb database to reflect the out of office status. At this time, the system will assign any work that exists for the USER to the chosen user(s). Any new work that is assigned to the USER will automatically be reassigned by the system to the chosen user(s).

7. The use case ends.

1.4.2.5 Change Password Subflow

This subflow allows the USER to change their current password.

1. The USER enters the old password.

2. The USER enters the new password of their choice.

3. The USER re-enters new password for verification.

4. The USER submits the passwords to the system.

5. The system validates the password changes.

6. The system updates ARMSWeb to reflect the new password changes.

7. The use case ends.

1.4.2.6 Confirmation Page

This subflow allows the USER to turn on or off confirmation pages in the ARMS Web system.

8. If Confirmation pages have been turned off, the user will turn them on.

9. If Confirmation pages have been turned on, the user will turn them off.

10. The USER submits the change to the system.

11. The system updates ARMSWeb to reflect the change.

12. The use case ends.

1.4.3 Alternative Flows

1.4.3.1 Invalid Password

At step five in the Change Password Subflow, if the current password is incorrect or if the confirmed password does not match the new password, the system will prompt the USER to re- enter the old, the new and the confirmation password. i;43.i.ϊ ^Itw lfjέ^cδSid ^filvali if Λe,neψ asswoident?ιred ξ»otte of the last

4.3U.2 , It will J3e considered invalid if the new password is not at between six and 10 characters and r umeric in type. -Validate 1AΛΛΛ & 1-43.1.2 in Sign-on.

1.4.3.2 Alternate Users not Chosen in Each Office USER is Assigned

At step five in the Out of Office Subflow, the system will validate that a user was selected to handle the USER'S work in each office the USER is assigned to. If a user was not chosen for each office, the system will notify the USER that they must select a user to handle their work in each office they are assigned to. The system will then return the USER to step two of the Out of Office Subflow.

14.3.3 Out of Office Start Date is in the Past

At step five in the Out of Office Subflow, the system will validate that a user selected an out of office date that is present (today) or in the future. If the date is in the past, the system will generate an error and ask the USER to enter a date that is either today or in the future. The system will then return the USER to step two ofthe Out of Office Subflow.

Confidential Enterprise Rent-A-Car © 2000 http://intranet dm2/ReadDooOrUnk.ASP?FolderID=2706&DoclD=9765 ARMS Redesign Project - Release 1.0 Issue: 1.0

User Profile Issue Date: 10/20/00

1.4.3.4 Favorite Location Name Entered is the same as an Existing Location When the USER submits the name for a new location, or changes the name of an existing location, the system will validate that the name entered is not an exact duplicate of any other name in that USER' S list of Favorite Locations. If the name is a duplicate, the system will prompt the USER to enter a different name for the location in question. The system will then return the USER to step one ofthe Edit Favorite Location Subflow. .4.3.5 Cancel User Profile

At any point during the use case up until a change has been submitted to the system, the USER may decide to not update their profile.

1.5 Post-Conditions

• If the use case was successful then either a new password has been assigned, the out of office function will be turned on, or the USER'S Favorite Locations will be edited.

• If the use case was unsuccessful then the system will remain unchanged.

1.6 Special Requirements

None.

1.7 Extension Points

None.

Confidential Enterprise Rent-A-Car © 2000 h^ttp:^//in^tranet dra2 ReadDocO. ink.ASP?FolderID=2706--DoclD-9765 ARMS Redesign Project - Release 1.0 Issue: 1.0 User Profile Issue Date: 10/20/00

2. Screen Design

A definition ofthe screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.

2.1 My Profile

This screen will allow the USER to pick which functions that they wish to change.

2.1.1 Screen Layout - My Profile iCo e to the Automated Rental Wanaαement System

RESERVATION CUSTOMER

Office; tot .Handling for. Yourself

Admlnis Vtrs Priofile

Out of Offices

Confidential Enterprise Rent-A-Car © 2000 hltpV/mlranel/dni2/ReadDocOrLin .ASP?FoIderID=270S--DocII>= 765 ARMS Redesign Project - Release 1.0 Issue: 1.0 User Profile Issue Date: 10/20/00

2.1.2 My Profile

2.1.3 Screen Function Definition

This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.

2.1.3.1 Process

When clicked, the system will validate the information on the screen is correct and complete. If an error is found the screen will be redisplayed with a message indicating the error condition and highlighting the field in error. If no errors are found, the database will be updated with the new information.

2.13.2 Add A Different Office

When clicked, the system will take the USER to MA-02-Find Rental Location Use Case. Here, the USER will select a new location to add to the preferred location list, and then return to the PR-07-User Profile Use Case. The new information will be validated and the database will be updated.

Confidential Enterprise Rent-A-Car © 2000 http://intran-t/d 2 ReadDocOr inl_ASP?FoId_rID-2706&D<)cID-9765 ARMS Redesign Project - Release 1.0 Issue: 1.0

User Profile Issue Date: 10/20/00

3. Application Operations

This section will detail all the application operations that are part of this Functional Specification Document.

3.1 Retrieve User Profile

(User Id)

Retrieve user's current profile settings.

3.2 Update User Profile

(User Id, Out of Office, Assigned Adjuster, Start Page)

Update user's Out of Office status, Adjuster to handle work during out of office period, and the user's initial page.

3.3 Change Password

(Current Password, New Password, New Password Confirmation)

Change the user's password from the current password to the new password. Validate that the current password is correct.

Confidential Enterprise Rent-A-Car © 2000 10 http://intranet dm2/ReadDocOrLin .ASP?FolderID-2706&D∞lI 9765 ARMS Redesign Project - Release 1.0 Issue: 1.0 User Profile Issue Date: 10/20/00

4. Data Fields

4.1 Data Field Definition

This section includes a definition of all data fields included in the functional specification.

4.1.1 Handler for out of office user

This is the user who will handle work for the user who is out of office.

Data Field Type: Alpha-Numeric Data Field Length: 0 Data Source: <Data Source>

4.1.2 Start Page

This is the initial page that the user will see when he logs on to the system.

Data Field Type: URL

Data Field Length: 256

Data Source: <Data Source>

4.1.3 Is user out of office ?

This flag indicates that the user is out of office and no work should be assigned to them. Instead another user can be set up to handle for the user who is out of office.

Data Field Type: Boolean Data Field Length: 1 Data Source: <Data Source>

4.1.4 Password

This is the user specified password that the user will use along with the user id to log on to the ARMS Web System.

Data Field Type: Password

Data Field Length: 10

Data Source: <Data Source>

Confidential Enteφrise Rent-A-Car © 2000 http://intranet/di-2 ReadDocOrLink.ASP?FoIderID=2706&DoclD-9765 0

1042

ARMS Redesign Project - Release 1.0 Issue: 1.0

Issue Date: 10/20/00 User Profile

5. Questions and Answers

Issue Number: 334

Question: Is out of office assigned at the user level or at the office level? (Could you set this for each office you work out of?) Example: You have been created at the St. Louis Office and you need to travel to California to help with a disaster, does California have the rights to maintain you.

Status: Closed - Resolved

Resolution: 4-7-00, Issue Mtg, Defer to user review 12

08-07-00 - Brad Reel: A user will be required to set their out of office function for all offices they are assigned to in order to activate the function. The function is set up using the assumption that a user would only be out of office if they were unreachable at all offices (vacation, training, etc.). Since the system can be accessed from any web connection, it is possible for a user to do work for any and all offices they are assigned to from anywhere. Therefore, it seems logical that a user would only set their out of office function if they were not available in any capacity.

Issue Number: 335

Question: Does a user have the field level control ofthe fields he can see?

Status: Closed - Resolved

Resolution: 4-7-00, Issue Mtg, Should be set at the Office level, the user should not be able to set the field that they want to see.

4-11-00, Brad Reel - User does not need to have control over the fields they see. Control at the office (or team level, where applicable) is sufficient

Issue Number: 336

Question: Are we still using the "Requests to be Processed" page, (the Command Center) as an option for a start up page?

Confidential Enteφrise Rent-A-Car © 2000 12 htlp://infranet dm2/Re-dDocOrLink.ASP?FolderID=2706&DocID=9765 1043

ARMS Redesign Project - Release Issue: 1.0 User Profile Issue Date: 10/20/00

Status: Future

Resolution: 4-7-00, Issue Mtg, Defer to future release, We are not sure that it will not be an option, right now it is not.

4-11-00, Brad Reel - As of right now, the "Command Center" page (Requests to be Processed) should not be an option for the start page, and is not even planned for the ARMS Web system.

Issue Number: 434

Question: 07-06-00 - Brad Reel: The ARMS Web redesign has a requirement that the system would allow the user to choose the page in the system they could use as their start-up page. Their options were: the Command Center Page, the Action Items Page, or the Create Reservation Page. Based on the way the system has been designed to process since that time, it does not seem to make sense to be able to choose anything other than the Action Items page as a user's start page. The profile build team suggests removing the option to allow a user to choose their start page from the user profile.

07-07-00 - Brad Reel: Feedback from the technical team and the business suggests that it may make more sense to have Create Reservation as an option, and have it process in a different manner than the normal create reservation process. The main advantage of this would be First Notice of Loss Adjsuters. There was also consensus that if the ability to sleet your start page is removed in this release, it should be possible to easily add it back in the fiiture. 07-07-00 - Brad Reel: Upon speaking to the database and build teams, it should not be difficult to add the functionality back to the system in a future release. A user's start page was set up as an attribute of a user, and since there will still be other attributes for a user, the start page will just be a new attribute when it is added back. Therefore adding the ability to choose a start page in a future release should not be difficult.

07-07-00 - Brad Reel: This issue is being assigned to Sean O'Donnell for review ofthe feasibility and impacts to the create reservation process if a user is allowed to enter the create res page without having entered the intial required fields (i.e. Claim #, Claim Type, Renter Last Name, etc.). This issue should be discussed for resolution at the 07-17 issues meeting and is being assigned to Craig Lalumandier as resolution contact until it is resolved. Upon resolution, this issue may need to be assigned back to Brad Reel so that the decision can be implemented into the user profile.

Status: Closed - Resolved

Resolution: 07/17/00 [Craig L.] - For the initial release, the start page will not be profiled. This feature would not be difficult to add in the future.

Sean O'Donnell 07-11-2000 - 1 would NOT recommend allowing users to have the create reservation page selected as their 'Start Page' for the following reasons;

- the reason(s) we split the reservation process into two pages to begin with still exist 1) to have the information to perform authorized and unauthorized matches to ensure that the reservation that

Confidential Enteφrise Rent-A-Car © 2000 13 rφ:/rιntraιιetΛlm2 ReadDooOrUnl ASP?Fo!derπ>=2706&Dθ(:ID=9765 ARMS Redesign Project - Release 1.0 Issue: 1.0 User Profile Issue Date: 10/20/00 is being created does not already exist, 2) to get the 'where needed' information to retreive a location & rates, 3) to get the claim type information up front so that we can build the authorization section ofthe create reservation page appropriately.

- if we change the process to support 'FNOL' adjusters differently than the 'normal' way of creating a reservation, use ofthe application will be inconsistent.

Please contact me if there are concerns with these statements.

Confidential Enteφrise Rent-A-Car © 2000 14 htlp:;/intranet dπ-2 ReadDTOθrLmk.ASP?FolderiD=2706&l-oolD=9765 Automated Extensions

Insurance company wishes Auto Extension to automate part or all of their extension process through

ARMS.

There will be three options available for this automation

Option 1 Option 2 Option 3

Automated Extension based on labor hours or down time

Automated System Extensions

Insurance company electronically

Automated Extension based on sends ARMS the total number of

System automatically extends ARMS Automotive Status days the repairs should take, or the rental each time a request for labor hours for the repairs (which extension is received from Insurance company agrees to allow

Enteφrise will convert to days). If

Enteφrise. System will only be status updates made by preferred the authorized number of days that authorized to extend a rental for the Bodyshops in ARMS Automotive to exists on the open file is less than number of days equal to 25% of the automatically generate rental the number of labor hours/down total days initially authorized by the extensions in ARMS Claims. time days ARMS automatically adjustor. extends the rental to equal the number of labor hours/down time days.

Example

Example Example

Joe's Bodyshop, a preferred shop

Initial Authorization was for 12 Initial Authorization was for 6 days. for ABC Insurance, enters in a shop days. An extension request is sent The adjustor views the renter's status and estimated completion for 5 additional days. System auto vehicle and estimates 8 days down date in ARMS Automotive. The extends the rental for 3 days (25% time. When the 8 days down time entry of the Estimated completion of original auth) and an extension is entered into the Claims systems date automtacially triggers an request is created in the adjustor's and automatically sent to ARMS, extension within ARMS Claims to action items for the remaining 2 day the rental will be automatically extend the rental up through the extension. extended for 2 additional days.

Estimated completion date. Training System

Create A AcύDntet»5 t; Cotiwlεlertήεttoas I Keperfs | - ϋftrPrafH- Reservation

CJateϋillcs- 01 ST LOUIS - NOFfTH^l Assignωt-t | Yourself

Extend Rental: ΓUI^<ABR&MS,KELILY & mm.ummmt

CUSTOMER Fϊi,£

?cff 14 ftcf Soil Items

Coverage Extension requested far.

J3 Js tf ftsio«aϊ anHiorfesd a @ jOlher lg_sι^<_a_ι

Massaps:

8fflg®1 fa^PM R-BBJT .l CaSrøflSEQΪ3ESreBI^:OBO03E*¥S 081_RFrøER-!N?^<*CftR (PP0U

TLTAJTORS»AI

Ownβfte Vehicle; U89S CMC

Vfeiføte ©ersiWKm. urft*ewn

C«rrerrt RentalStatasE

Rental start D$I*, en am LastΛϋlhβrt-^βtl Dale; Sf1M)1 Oa s jWiortzeαto fiatø:

Coverage Anhorized to Date: S ayg Aul orfzied Total: f leasts* DirectBϊll %:

*Does not Enclαde teses and surcharges

ction Items: *»m#Bact wj Off-line Sync

§**jSs*» am the «β» les* M m≠$ ψ ≠tt&tm.

IfJEj

ARMS Claims Remote Processing

Button Description:

Sync Up

ARMS Claims lets you keep copies of your action items and store them locally on your computer as offline transactions. ARMS Claims can automatically update the contents of transactions on the local machine and the main system. Or you can manually synchronize the transactions and then continue to work offline. When ARMS Claims synchronizes your transactions, it copies the changes made on each system and then disconnects. Any items that's deleted from either the offline transaction set or the main application is deleted from both. After you work offline and re-establish your connection to ARMS Claims, the Sync up option is utilized to update the main system.

Preferences

The preferences button provides the adjuster the ability to establish defaults for automatic syncing of the data. Other preferences would include options on how syncing issues when offline and main system transactions are updated.

History

The history button will display all of the sync events over a specified period of time. It will display any error messages and resolution to sync conflicts (i.e. the main system was updated after the local record was updated which record takes precedence.)

Step 1 ' Adjust is attached to the ARMS Claims system through an Internet ARMS Claims Offline Access connections

Step 3: Tha adjust then disconects from the internet site and can now access the ARMS claims

Step 2. The adjuster selects the programs on hie laptop to work offline. These program s use the data downloaded during the sychronize file options to download all of sync process to allow the adjust or to create resrevations, authorize direct bills, extend rentals, his ARMS Claims data to a database on approve invoices and set last day on rentals. his system.

Step 6: The data is re-synced with the mam system All records and data fields are updated real time.

Power Templates

Claims Officer EΪ^^ iϊ ^B Sssigπsrfto [Yourself

E3rten Rental:

QUICK EXTENSIOlf

Clams Gtfe ) 01 ST. LQUiS- NORTH fl Asssenedta [ADAMS, KVLΪ

Action I βmS. Welcome B∞K^LJ SUMMER.

Below please fins tte a tso itemsftat require your stteπton ϊβ *βrt the Aefion Items, selicfc the ecfawa itfβ of yβir chosen sorting enaihα ex to sort by date, diet {"PATE RECaVEfr*.

SJTVPE ftATJE RECeWEfe WEUTEffS -Sil£ CLAIM tJUWBER ftfi. STSR

I Extensions 8t17/01 (4) Extensions ADAMS, KYLE

I Unassi εl items βf17rtM Msal§ms UNrøSIGNED

Over 24 hours old.

£ New ιritofRi«ιαrt has come In.

Coniaet Us \ Rflvaev Pollev > Loa Ort

■aatesøft* fll- ST. LOUIS'* NβfiTM

Administration:

afe U-ϊ&ssϊis*ai!-S3 Power Templates

The purpose of the power templates is to allow the adjuster to quickly update all action items without having to go into the details. The adjuster is presented with the required information to extend, authorize, approve invoice, or set last day on the rental. If the adjuster wishes to view the details, a hyperlink is simply selected.

Adjuster Service Concepts

mm ff*« MST. LOUIS- NORTH jϊ M nm Yeuwealf

Mmύ Rental: «f «*iS, HSULV (Mm nβ. l4S258iS4-

€USTøPiR lLi

€»w Of ««; ) m ST. UOU1S - NQCTH jj) AsΛinec, le; jYsursait

Inten Rental: tm MPtWiBlSs KELLY ϋtaiim ne.1452869841

CUSTOMER FILE

ι#st§ m ®

A*s&rwN- !« fvMse

ϊXtβtld R.βH;tel- to

Calm no.148288984 CUSTQMER ll_E

Υt m®§ System

Claims

Create A | Fund ft roHBHiwi Reseevaitwa I Custø et

Adjuster

OWICK 01 ST. LOUIS -NORETHI AssSgnettta: j Yourself

ExtθO€Ϊ K ntøl- farβfWfMSjI&LY Ctøffl) rø.1 $5236984- cu$τonEf t,ε

ARMS Claims - Multiple Adjusters

The Adjuster profile tab provides the owning adjuster the ability to establish task (extend, authorize, invoice) authority on a claim

Creating a Reservation

Extending a Reservation

The same process occurs for the invoice process

Transfering claim

Third Party

Assist Company Example Management

The insurance company decides which actions a third party user can make with respect to claims or which the insurance company will ultimately be responsible for payment.

Example: Insurance Company Authorized Company Actions Authorized Assist Company A Create, Authorize

Insurance Company X Assist Company B Create, Authorize

& User Maintenance

Assist Company C Create, Extend Rentals

Assist Company A Create, Extend Rentals

Insurance Company Y

Assist Company C Create Rentals

This means that.... 1063

When Mr. A of Assist Company A logs onto ARMS, Mr. A will see a list of action items:

Insurance Company X Action 1 Action 2 Mr. A of Assist Company A can Create and Authorize rentals for Action 3 Insurance Company X, but do nothing more for Company X. Action 4

Insurance Company Y

Action 1 Mr. A of Assist Company A can Create and Extend rentals for Action 2 Insurance Company Y, but do nothing more for Company Y. Action 3

Mr. A cannot see or work on anything that has been assigned to Assist Company B or Assist Company C as he is from Assist Company A and all his access is limited to Assist Company A.

When Mr. B of Assist Company B logs onto ARMS, Mr. B will see a list of action items:

Insurance Company X

Action 1 Action 2 Mr. B of Assist Company B can Create and Authorize rentals for Insurance Action 3 Company X and do nothing more for Company X. Mr. B can do nothing for Action 4 Company Y as they have no authorization from Company Y.

Mr. B will assign and maintain the user access for others at Assist Company B pertaining to Company X as he has been give that access by Company X.

Mr. B cannot see or work on anything that has been assigned to Assist Company A or Assist Company C as he is from Assist Company B and all his access is limited to Assist Company B.

When Mr. C of Assist Company C logs onto ARMS, Mr. C will see a list of action items:

Insurance Company X

Action 1 Action 2 Mr. C of Assist Company C can Create and Extend rentals for Insurance Action 3 Company X, but do nothing more for Company X. Action 4

Insurance Company Y

Mr. C of Assist Company C can Create rentals for Insurance Company

Action 1 Y, but do nothing more for Company Y. Action 2

Mr. C cannot see or work on anything that has been assigned to Assist Company A or Assist Company BC as he is from Assist Company A and all his access is limited to Assist Company B. Mpproved Third party claims management Body Shop

Create Reservations

The Insurance company uses the

Administration tab to set up a Body

Shop provider. The Body shop name Reservation

Body shop togs into and customer number is established. information is sent

Authorizing limits (rates/Days) are Customer takes car ARMS Claims and to customer, establiched. Extenstlon and Invoice to Body shop Enterprise branch reservation for authority (days, amounts, etc) are and Insurance customer also established. Company.

Extensions

If the extension is in

Body shop logs into the authority range ARMS Claims and If authority level is

Body shop profile is the extend the

Body shop needs selects the not approved than checked to ensure rental and send to extend the customer's vehicle request the body authority has been information to rental. and enters in established. shop contact the number days to Insurance company. insurance company. branch and extend. customer

Invoice if the invoice is in the authority range

Body shop logs into If authority level is

Bodyshop needs ARMS Claims and Body shop profile is the body shop not approved then to approve the approves and sends selects the checked to ensure request the body authority has been information to rental. customer to shop contact the established. Insurance company. approve invoice. Insurance company. branch and customer

Credit Hire Example

The insurance company decides which actions a third party user can make with respect to claims or which the insurance company will ultimately be responsible for payment.

Example:

Insurance Company Authorized Company Actions Authorized

Credit Hire A Create, Authorize

Insurance Company X Credit Hire B Create, Authorize

& User Maintenance

Credit Hire C Create, Extend Rentals

Insurance Company Y

This means that....

When Mr. A of Credit Hire A logs onto ARMS, Mr. A will see a list of action items:

Insurance Company X

Action 1 Action 2 Mr. A of Credit Hire A can Create and Authorize rentals for Insurance Action 3 Company X, but do nothing more for Company X. Action 4

Insurance Company Y

Action 1 Mr. A of Credit Hire A can Create and Extend rentals for Insurance Action 2 Company Y, but do nothing more for Company Y. Action 3

Mr. A cannot see or work on anything that has been assigned to Credit Hire B or Credit Hire C as he is from Credit Hire A and all his access is limited to Credit Hire A.

When Mr. B of Credit Hire B logs onto ARMS, Mr. B will see a Ust of action items:

Insurance Company X

Action 1 Action 2 Mr. B of Credit Hire B can Create and Authorize rentals for Insurance Company X Action 3 and do nothing more for Company X. Mr. B can do nothing for Company Y as they Action 4 have no authorization from Company Y.

Mr. B will assign and maintain the user access for others at Credit Hire B pertaining to Company X as he has been give that access by Company X.

Mr. B cannot see or work on anything that has been assigned to Credit Hire A or Credit Hire C as he is from Credit Hire B and all his access is limited to Credit Hire B.

When Mr. C of Credit Hire C logs onto ARMS, Mr. C will see a list of action items:

Insurance Company X

Action 1 Action 2 Mr. C of Credit Hire C can Create and Extend rentals for Insurance Action 3 Company X, but do nothing more for Company X. Action 4

Insurance Company Y

Mr. C of Credit Hire C can Create rentals for Insurance Company Y, but

Action 1 do nothing more for Company Y. Action 2

Mr. C cannot see or work on anything that has been assigned to Credit Hire A or Credit Hire BC as he is from Credit Hire A and all his access is limited to Credit Hire B. An independent party constitutes a third-party management organization that an insurance company may give permission to manage some or all of the rental transaction. An independent party my consist of, but not limited to the following:

• Credit hire

• Fleet management company

• Assist company

• Lawyer

Functions for each "role" vary by the insurance company authorizing permissions.

An independent party constitutes a third-party management organization that an insurance company may give permission to manage some or all of the rental transaction on behalf of an insurance company. An independent party may consist of, but not limited to the following:

• Credit Hire

This is a lawyer in England that represents clients before a claim is filed. The lawyer (credit hire) helps their client get access to rentals, deals with the body shop and medical providers. The credit hire is hired by the renter, or by the person who was involved in the accident.

• Lawyer

See Credit Hire example. This person manages the claim for their client. In England, this role is called "Credit Hire," in Germany, it is called "Lawyer."

• Fleet management company

Typically, a fleet management company takes care of a fleet for a company, manages the car hire paperwork and authorizations for replacement rentals that are needed when a fleet car is in the shop.

• Assist company

This company will take on the task of managing the rental process on behalf ofthe insurance company in managing the rental portion of the claim due to the accident.

Functions for each "role" vary by the insurance company authorizing permissions. The chart and description below attempt to explain each permission as it pertains to each entity outlined above.

* Own files: this authorization, if granted, will allow the user to have a file (or claim) assigned to him or her. ** User Maintenance: A person that is authorized with this capability has the ability to maintain the authorizations for other users within his organization. For example, person "B" at ABC company has access to "user maintenance." Person B ean assign the access for persons C and A at ABC company, but not for Mr. D at DEF corporation. Primary Billing Coverage Adjuster Repair Facility Independent Party Extension Adjuster

Shop Example

The insurance company decides which actions a third party user can make with respect to claims for which the insurance company will ultimately be responsible for payment.

Example: Insurance Company Authorized Company Actions Authorized

Shop A Create, Authorize

Insurance Company X Shop B Create, Authorize

& User Maintenance

Shop C Create, Extend Rentals

Shop A Create, Extend Rentals

Insurance Company Y

Shop C Create Rentals

This means that....

When Mr. A of Shop A logs onto ARMS, Mr. A will see a list of action items:

Insurance Company X Action 1 Action 2 Mr. A of Shop A can Create and Authorize rentals for Insurance Action 3 Company X, but do nothing more for Company X. Action 4

Insurance Company Y

Action 1 Mr. A of Shop A can Create and Extend rentals for Insurance Company Action 2 Y, but do nothing more for Company Y. Action 3

Mr. A cannot see or work on anything that has been assigned to Shop B or Shop C as he is from Shop A and all his access is limited to Shop A.

When Mr. B of Shop B logs onto ARMS, Mr. B will see a list of action items:

Insurance Company X

Action 1 Action 2 Mr. B of Shop B can Create and Authorize rentals for Insurance Company X and do Action 3 nothing more for Company X. Mr. B can do nothing for Company Y as they have Action 4 no authorization from Company Y.

Mr. B will assign and maintain the user access for others at Shop B pertaining to Company X as he has been give that access by Company X.

Mr. B cannot see or work on anything that has been assigned to Shop A or Shop C as he is from Shop B and all his access is limited to Shop B.

When Mr. C of Shop C logs onto ARMS, Mr. C will see a Ust of action items:

Insurance Company X

Action 1 Action 2 Mr. C of Shop C can Create and Extend rentals for Insurance Company Action 3 X, but do nothing more for Company X. Action 4

Insurance Company Y

Mr. C of Shop C can Create rentals for Insurance Company Y, but do

Action 1 nothing more for Company Y. Action 2

Mr. C cannot see or work on anything that has been assigned to Shop A or Shop BC as he is from Shop A and aU his access is limited to Shop B. Find A Action items I Cottrnmea tums a Reports Customer

Claims Office: 016 - ENGLEWOOD, CO

Administration:

MODIFYUSER

Office

-8 Top of Page create A Find ft ActioniteHis; XΛmweteafti-tions i Report

Reservation Customer

Administration:

MODiFYUSER

Create a New User/Team

Automated Rental Management System

Claims Patent Pendln

Create A Find A Action Items I Completed Aώϊons ;^' fettorts

Reservation Customer

Claims Office: 016 - ENOLEWOOD, CO

Administration:

M ODI FY U S ER

Office

Authorizations

ϊlfftlfllϊllβ

mtm ®m® 81 ST. LOUIS -HDICTHlM ®»tø- jYαutsβl

Car Sales

€w«*ι |oι ST. LOUIS -NOFTΓHH * $ W ma^'

Create Reservation: tw m §U«iSt_n€ttftil Clstartoo, _3 #4S Car Sales

QUICK PORII

^•βπβϊesrøsfώredδsd

Car Sties Inventory: welcome Back CAU SUM ER

Cars available for sale in the Renter's area are listed below.

Results are based off of a search for Hase_hor_-t, Connie

Area Code 83105 FCAR Find ACV

mi latest agrø $,3 »

SUVRflHirCIXX_g

1-888- Car- Sales (227-7253.1

ItaJtL& ^

Total Loss/Car Sales Process - ARMS

Claims

What is claimed is:

1. An Internet enabled automatic rental vehicle transaction system, said system having an Internet web site through which an authorized purchaser of rental vehicle services may access a rental vehicle software program resident on a computer system, said rental vehicle software program being configured to automatically respond to a series of commands from said authorized purchaser and communicate a rental vehicle reservation to one of a plurality of providers of said rental vehicle services, at least one of said rental vehicle service providers offering a plurality of specific geographically remote rental vehicle locations at which vehicles for rent are situated, said rental vehicle reservation having sufficient information for authorizing, processing and billing said rental vehicle transaction so that a rental vehicle transaction may be automatically processed thereby for any one of said plurality of said rental vehicle service providers.

2. The rental vehicle transaction system of claim 1 ^• wherein said authorized purchaser comprises a business organization, said business organization having a plurality of authorized purchasers, said plurality of authorized purchasers being enabled to access said Internet web site from any location offering Internet web access, and wherein said at least one of said rental vehicle service providers further comprising a second business organization, said second business organization having the computer system and rental vehicle software program resident therein, and wherein said second business organization includes a plurality of geographically diverse rental vehicle locations.

3. The rental vehicle transaction system of claim 2 wherein said rental vehicle software program is configured to permit a rental vehicle reservation to be initiated remote from said authorized purchaser and communicated to said authorized purchaser for authorization.

4. The rental vehicle transaction system of claim 2 wherein said software program is configured to permit said authorized purchasers to modify said rental vehicle reservation through said Internet web site.

5. The rental vehicle transaction system of claim 4 wherein said software program is configured to permit said authorized purchasers to modify said rental vehicle reservation including extending a time period for which said reservation authorizes use of a rental vehicle.

6. The rental vehicle transaction system of claim 4 wherein said software program is configured to permit said authorized purchaser to generate reports relating to rental vehicle reservation activity conducted through said software program.

7. The rental vehicle transaction system of claim 6 wherein said software program further comprises a data base, said data base storing rental vehicle reservation activity for access by said authorized purchasers.

8. The rental vehicle transaction system of claim 7 wherein said software program is configured to automatically communicate billing information to said authorized purchaser, for further processing.

9. The rental vehicle transaction system of claim 8 wherein said software program is configured to communicate messages between said authorized purchaser and any others having access to said software program.

10. The rental vehicle transaction system of claim 9 wherein said software program is configured for allowing access through its Internet web site to a plurality of service providers, and for limiting the functionality available to said plurality of service providers.

11. The rental vehicle transaction system of claim 10 wherein said plurality of service providers include vehicle repair facilities.

12. The rental vehicle transaction system of claim 1 further comprising a second computer system, said second computer system having a second computer software program resident thereon, said second computer software program being configured to process rental vehicle transactions at a plurality of geographically diverse branch facilities each of which has a plurality of vehicles for rental, said second computer system being linked to said first computer system.

13. The rental vehicle transaction system of claim 12 wherein each of said first and second computer systems comprises a networ having a main frame computer, said main frame computers being linked to each other, and wherein said _, second computer system further comprises a WAN.

14. The rental vehicle transaction system of claim 13 wherein said authorized purchaser comprises a business organization, said business organization having a plurality of authorized purchasers, said plurality of authorized purchasers being enabled to access said Internet web site from any location offering Internet web access, and further comprising a second business organization, said second business organization having the second computer system resident therein, and wherein said second business organization includes the plurality of geographically diverse rental vehicle locations.

15. The rental vehicle transaction system of claim 14 wherein said first software program is configured to permit a rental vehicle reservation to be initiated remote from said authorized purchaser and communicated to said authorized purchaser for authorization.

16. The rental vehicle transaction system of claim 15 wherein said first software program is configured to permit said authorized purchasers to modify said rental vehicle reservation through said Internet web site.

17. The rental vehicle transaction system of claim 16 wherein said first software program is configured to permit said authorized purchasers to modify said rental vehicle reservation including extending a time period for which said reservation authorizes use of a rental vehicle.

18. The rental vehicle transaction system of claim 16 wherein said first software program is configured to permit said authorized purchaser to generate reports relating to rental vehicle reservation activity conducted through said first software program.

19. The rental vehicle transaction system of claim 18 wherein said first software program further comprises a data base, said data base storing rental vehicle reservation activity for access by said authorized purchasers.

20. The rental vehicle transaction system of claim 19 wherein said first software program is configured to automatically communicate billing information to said authorized purchaser for further processing.

21. The rental vehicle transaction system of claim 20 wherein said first software program is configured to communicate messages between said authorized purchaser and any others having access to said software program.

22. The rental vehicle transaction system of claim 21 wherein said first software program is configured for allowing access through its Internet web site to a plurality of service providers, and for limiting the functionality available to said plurality of service providers. ^β

23. The rental vehicle transaction system of claim 22 wherein said plurality of service providers include vehicle repair facilities .

24. An automatic rental vehicle transaction system, said system having a graphical user interface (GUI) through which an authorized purchaser of rental vehicle services may access a rental vehicle software program resident on a computer system, said rental vehicle software program being configured to automatically respond to a series of commands from said authorized purchaser and communicate a rental vehicle reservation to any one of a plurality of vehicle rental service providers including one having a plurality of specific geographically remote rental vehicle locations at which vehicles for rent are situated, said rental vehicle reservation having sufficient information for authorizing, processing and billing said rental vehicle transaction so that a rental vehicle transaction may be automatically processed thereby.

25. The rental vehicle transaction system of claim 24 wherein said authorized purchaser comprises a business organization, said business organization having a plurality of authorized purchasers, said plurality of authorized purchasers being enabled to access said rental vehicle software program from any location offering access to said computer system, and further comprising a second business organization, said second business organization having the computer system and rental vehicle software program resident therein, and wherein said second business organization includes a plurality of geographically diverse rental vehicle locations.

26. The rental vehicle transaction system of claim 25 further comprising a second computer system resident in said second business organization, said second computer system having a second computer software program resident thereon, said second computer software program being configured to process rental vehicle transactions at the plurality of geographically diverse branch facilities each of which has a plurality of vehicles for rental, said second computer system being linked to said first computer system.

27. The rental vehicle transaction system of claim 26 wherein each of said first and second computer systems comprises a network having a main frame computer, said main frame computers being linked to each other, and wherein said second computer system further comprises a WAN.

28,^'' The rental vehicle transaction system of claim 27 wherein said rental vehicle software program is configured to permit a rental vehicle reservation to be initiated remote from said authorized purchaser and communicated to said authorized purchaser for authorization.

29. The rental vehicle transaction system of claim 28 wherein said first software program is configured to permit said authorized purchasers to modify said rental vehicle reservation through said Internet web site.

30. The rental vehicle transaction system of claim 29 wherein said first software program is configured to permit said authorized purchaser to generate reports relating to rental vehicle reservation activity conducted through said first software program.

31. The rental vehicle transaction system of claim 30 wherein said first software program is configured to automatically communicate billing information to said authorized purchaser for further processing.

32. The rental vehicle transaction system of claim 31 wherein said first software program is configured to communicate messages between said authorized purchaser and any others having access to said software program.

33. The rental vehicle transaction system of claim 32 wherein said first software program is configured for allowing access thereto to a plurality of service providers, and for limiting the functionality available to said plurality of service providers.

34. The rental vehicle transaction system of claim 33 wherein said plurality of service providers include vehicle repair facilities.

35. A computer software program to provide an Internet site access by a multi-level business organization to a plurality of service providers including one such service provider having an integrated business, said access being sufficient for placing and monitoring orders for delivery of services by said integrated business, said integrated business including a computer system having a business software program configured to automatically accept reservations for, and provide administrative control and accounting for, services offered and physically available at a plurality of geographically diverse locations.

36. The computer program of claim 35 wherein said Internet site software program is configured to provide said access to said business software program for a range of functional interactions therewith.

37. The computer program of claim 36 wherein said Internet site computer software program is configured to provide access to an authorized purchaser of a plurality of said service providers' services, said authorized purchaser comprising a multi-level business organization requiring interaction at a plurality of levels of said business software program.

38. The computer program of claim 37 wherein said at least one service provider having an integrated business is itself a multi-level business organization, said business software program providing communication of business information needed to effectively execute reservations placed for delivery of its services, and wherein said Internet site software program is configured to provide interaction between different levels of both of said business organizations.

39. The computer program of claim 38 wherein said Internet site software program is further configured to provide controlled access to said business software program by third party service providers.

4-0. The computer program of claim 38 wherein said Internet site software is resident on a first computer system and said business software program is resident on a second computer system, and wherein each of said first and second computer systems comprises a network having a main frame computer, said main frame computers being linked to each other, and wherein said second computer system further comprises a WAN.

41. A method for providing an Internet site through which an authorized purchaser comprising a multi-level business organization of rental vehicle services may access a rental vehicle software program and make reservations for any one of a plurality of rental vehicle service providers, at least one of said providers being an integrated business organization with a functional integrated computer system providing access to a plurality of diverse geographic locations at which vehicles for rental are kept, said method comprising the steps of: providing an Internet site computer system having a software program configured to create Internet access thereto; and establishing a link between said purchaser's computer system and at least one of said providers computer system; said Internet site software program being further configured to facilitate functional interaction between the software program resident on said rental vehicle provider's business computer system and an authorized purchaser logged onto said Internet site software program.

42. The method of claim 41 wherein said provider's computer system further comprises a main frame computer, and wherein the step of establishing a link includes the step of establishing a link between said authorized purchaser's computer and said main frame computer.

43. A method for providing a GUI interface through which an authorized purchaser of rental vehicle services comprising a multi-level business organization may access a rental vehicle software program resident on a rental vehicle provider's business computer system to thereby conduct rental vehicle business with a plurality of providers including conducting vehicle rental business on at least one of said provider's business computer system, said method comprising the steps of: providing a computer system having a software program configured to create a GUI interface; and establishing a link between said two computer systems; said GUI interface software program being further configured to communicate with a plurality of providers including facilitating functional interaction between the software program resident on said at least one rental vehicle provider's business computer system and an authorized purchaser logged onto said GUI interface software program.

44. The method of claim 43 wherein each of said computer systems further comprises a main frame computer, and wherein the step of establishing a link includes the step of establishing a link between said two main frame computers.

45. An Internet enabled automatic rental vehicle transaction system, said system having an Internet web site through which an authorized purchaser of rental vehicle services may access a plurality of rental vehicle providers including at least one provider having a rental vehicle software program resident on a computer system, said rental vehicle software program being configured to- automatically respond to a series of commands from said authorized purchaser and communicate a rental vehicle reservation to a centralized destination, said rental vehicle reservation having sufficient information for authorizing, processing and billing said rental vehicle transaction so that a rental vehicle transaction may be automatically processed thereby virtually without human intervention.

46. The rental vehicle transaction system of claim 45 wherein said software program is configured to permit said authorized purchasers to generate a report comprised of that users work load sorted by completion date.

47. A rental vehicle transaction system, said system comprising an Internet site through a computer, said computer being networked with a plurality of vehicle rental providers, at least one of said providers having an integrated computer system connected thereto, and said computer being configured to allow users to place reservations for rental vehicle services with any one of said providers.

48. The transaction system of claim 47 wherein said Internet site computer is further configured to allow data requirements for said reservation to be customized.

49. The transaction system of claim 47 wherein said Internet site is networked through the Internet with said other providers .

50. The transaction system of claim 49 wherein said Internet site is configured to allow customization of menus presented to said users.

51. An Internet enabled automatic rental vehicle transaction system, said system having an Internet web site through which an authorized purchaser of rental vehicle services may access a rental vehicle software program resident on a computer system, said rental vehicle software program being configured to automatically respond to a series of commands from said authorized purchaser and communicate a rental vehicle reservation to one of a plurality of providers of said rental vehicle services, a plurality of said rental vehicle service providers each offering a plurality of specific geographically remote rental vehicle locations at which vehicles for rent are situated, said rental vehicle software program having access to a data base, said data base including at least data corresponding to characteristics of presently available vehicles for rental situated at least at one of said specific geographic locations, said data base being accessible to said authorized purchaser and from which said purchaser may choose a vehicle for rent, said rental vehicle reservation having sufficient information for authorizing, processing and billing said rental vehicle transaction so that a rental vehicle transaction may be automatically processed thereby for any one of said plurality of said rental vehicle service providers.

52. The rental vehicle transaction system of claim 51^' wherein said software program is configured to automatically update said data base as reservations are processed in order to maintain said data base for use by subsequent authorized purchasers.

53. The rental vehicle transaction system of claim 52 wherein said computer system comprises a computer network.

54. The rental vehicle transaction system of claim 53 wherein said computer network comprises a first computer for hosting said web site, a second computer for hosting said rental vehicle software program for controlling and processing said authorized reservations, and at least one third computer configured for fulfilling said authorized reservations.

55. The rental vehicle transaction system of claim 54 wherein each of said rental vehicle service providers has its own third computer configured for fulfilling said authorized reservations .

56. The rental vehicle transaction system of claim 55 wherein said authorized purchaser comprises a business organization, said business organization having a plurality of authorized purchasers, said plurality of authorized purchasers being enabled to access said Internet web site from any location offering Internet web access, and wherein each of said plurality of rental vehicle service providers comprises a separate business organization, said separate business organizations each providing their own plurality of geographically diverse rental vehicle locations.

57. The rental vehicle transaction system of claim 56 wherein said software program is configured to permit said authorized purchasers to modify said rental vehicle reservation including extending a time period for which said reservation authorizes use of a rental vehicle.

58. The rental vehicle transaction system of claim 57 wherein said software program is configured to permit said authorized purchaser to generate reports relating to rental activity conducted through said software program.

59. An Internet enabled automatic rental vehicle transaction system, said system having an Internet web site through which an authorized purchaser of rental vehicle services may access a rental vehicle software program resident on a computer system, said rental vehicle software program being configured to automatically respond to a series of commands from said authorized purchaser and communicate a rental vehicle reservation to one of a plurality of providers of said rental vehicle services, a plurality of said rental vehicle service providers each offering a plurality of specific geographically remote rental vehicle locations at which vehicles for rent are situated, said rental vehicle software program having access to a data base, said data base including at least data corresponding to characteristics of presently available vehicles for rental situated at each of said specific geographic locations, said data base being accessible to said authorized purchaser and from which said purchaser may choose a vehicle for rent, said rental vehicle reservation having sufficient information for authorizing, processing and billing said rental vehicle transaction, and said rental vehicle software program being configured to process said authorized reservation for any one of said plurality of said rental vehicle service providers.

60. The rental vehicle transaction system of claim 59 wherein said software program is configured to automatically update said data base as reservations are processed in order to maintain said data base for use by subsequent authorized purchasers.

61. The rental vehicle transaction system of claim 60 wherein said computer system comprises a computer network.

62. The rental vehicle transaction system of claim 61 wherein said computer network comprises a first computer for hosting said web site, a second computer for hosting said rental vehicle software program for controlling and processing said authorized reservations, and at least one third computer for fulfilling said authorized reservations.

63. The rental vehicle transaction system of claim 62 wherein each of said rental vehicle service providers has its own third computer configured for fulfilling said authorized reservations .

64. The rental vehicle transaction system of claim 63 wherein said authorized purchaser comprises a business organization, said business organization having a plurality of authorized purchasers, said plurality of authorized purchasers being enabled to access said Internet web site from any location offering Internet web access, and wherein each of said plurality of rental vehicle service providers comprises a separate business organization, said separate business organizations each providing their own plurality of geographically diverse rental vehicle locations .

65. , he rental vehicle transaction system of claim 64 wherein said software program is configured to permit said authorized purchasers to modify said rental vehicle reservation including extending a time period for which said reservation authorizes use of a rental vehicle.

66. The rental vehicle transaction system of claim 65 wherein said software program is configured to permit said authorized purchaser to generate reports relating to rental activity conducted through said software program.

67. A method for providing an Internet site through which an authorized purchaser, said authorized purchaser comprising_, a multi-level business organization, of rental vehicle services may access a rental vehicle software program and make reservations for any one of a plurality of rental vehicle service providers, each of said providers being an integrated business organization with a functional integrated computer system providing access to a plurality of diverse geographic locations at which vehicles for rental are kept, said method comprising the steps of: providing an Internet site computer system having a software program configured to create Internet access thereto; and establishing a link between said purchaser' s computer system and each of said providers' computer systems; said Internet site software program being further configured to facilitate functional interaction between the software program resident on said rental vehicle providers' business computer systems and an authorized purchaser logged onto said Internet site software program; and maintaining a data base of reservation activity handled by said Internet site.

68. The method of claim 67 further comprising the step of providing a communication capability over said link to allow for communication between said authorized purchaser and said providers.

69. The method of claim 68 further comprising the step of permitting access to said reservation data base by said authorized purchaser for generating reports therefrom.

70. The method of claim 69 further comprising the step of allowing for limiting the functionality of certain authorized purchasers in using the software program.

71. An Internet enabled automatic rental vehicle transaction system, said system having an Internet web site through which an authorized purchaser of rental vehicle services may access a rental vehicle software program resident on a computer system, said rental vehicle software program being configured to automatically respond to a series of commands from said authorized purchaser and communicate a rental vehicle reservation to one of a plurality of providers of said rental vehicle services, at least one of said rental vehicle service providers offering a plurality of specific geographically remote rental vehicle locations at which vehicles for rent are situated, said rental vehicle reservation having sufficient information for authorizing, processing and billing said rental vehicle transaction so that a rental vehicle transaction may be automatically processed thereby for any one of said plurality of said rental vehicle service providers, wherein said software program is configured to permit said authorized purchasers to modify said rental vehicle reservation through said Internet web site, wherein said authorized purchaser comprises a business organization, said business organization having a plurality of authorized purchasers, said plurality of authorized purchasers being enabled to access said Internet web site from any location offering Internet web access, and wherein said at least one of said rental vehicle service providers further comprises a second business organization, said second business organization having the computer system and rental vehicle software program resident therein, and wherein said second business organization includes a plurality of geographically diverse rental vehicle locations.

72. The rental vehicle transaction system of claim 71 wherein said software program is configured to permit multiple parties to modify said rental vehicle reservation, and wherein said software program is further configured to restrict actions which each of said multiple parties can effect to thereby control the extent to which said vehicle reservation may be modified by each of said multiple parties.

73. The rental vehicle transaction system of claim 72 wherein said multiple parties are each insurance adjusters and said software program is restricted through an entry instruction generated by said insurance company.

74. The rental vehicle transaction system of claim 72 wherein said multiple parties include at least one agent who is not a member of the same organization employing at least one other of said multiple parties.

75. The rental vehicle transaction system of claim 71 wherein said software program is configured to provide a synching function so that another computer may be selectively connected thereto and, under operator command, a data base in said other computer containing reservation data may be uploaded to a data base in said software program containing a master data base of reservation data, said computer system comparing the data from said two data bases and choosing to store data from each according to a synch protocol at least partially specified by the user.

76. The rental vehicle transaction system of claim 75 wherein said other computer is a mobile computer, and said selective connection is provided over an internet connection;

77. The rental vehicle transaction system of claim 71 wherein said software program is configured to permit the entry of user satisfaction data and transmit said user satisfaction data to an authority for response thereto.

78. The rental vehicle transaction system of claim 71 wherein said software program is configured to provide a menu of action items for selective entry and processing by a user thereof, and further comprising a command through which a user may execute a plurality of entered action items all together without further operator action.

79. The rental vehicle transaction system of claim 71 wherein said software program has access to a data base in which data corresponding to an inventory of vehicles are kept, and wherein said software program is configured to permit a user to access said data base to thereby view replacement vehicles available for transfer to a customer.

80. The rental vehicle transaction system of claim 79 wherein said software program is configured to permit searching of said data base from parameters entered by said user.

81. The rental vehicle transaction system of claim 80 wherein said parameters include at least vehicle valuation.

82. The rental vehicle transaction system of claim 81 wherein said software program is configured to accept authorization for said transfer by an insurance company.

83. An Internet enabled automatic rental vehicle transaction system, said system having an Internet web site through which an authorized purchaser of rental vehicle services may access a rental vehicle software program resident on a computer system, said rental vehicle software program being configured to automatically respond to a series of commands from said authorized purchaser and communicate a rental vehicle reservation. to one of a plurality of providers of said rental vehicle services, at least one of said rental vehicle service providers offering a plurality of specific geographically remote rental vehicle locations at which vehicles for rent are situated, said rental vehicle reservation having sufficient information for authorizing, processing and billing said rental vehicle transaction so that a rental vehicle transaction may be automatically processed thereby for any one of said plurality of said rental vehicle service providers, and wherein said software program is configured to permit said authorized purchasers to modify said rental vehicle reservation including extending a time period for which said reservation authorizes use of a rental vehicle.

84. The rental vehicle transaction system of claim 83 wherein said software program is configured to permit multiple parties to modify said rental vehicle reservation, and wherein said software program is further configured to restrict actions which each of said multiple parties can effect to thereby control the extent to which said vehicle reservation may be modified by each of said multiple parties.

85. The rental vehicle transaction system of claim 84 wherein said multiple parties are each insurance adjusters and said software program is restricted through an entry instruction generated by said insurance company.

86. The rental vehicle transaction system of claim 84 wherein said multiple parties include at least one agent who is not a member of the same organization employing at least one other of said multiple parties.

87. The rental vehicle transaction system of claim 83 wherein said software program is configured to provide a synching function so that another computer may be selectively connected thereto and, under operator command, a data base in said other computer containing reservation data may be uploaded to a data base in said software program containing a master data base of reservation data, said computer system comparing the data from said two data bases and choosing to store data from each according to a synch protocol at least partially specified by the user.

88. The rental vehicle transaction system of claim 87 wherein said other computer is a mobile computer, and said selective connection is provided over an internet connection.

89. The rental vehicle transaction system of claim 83 wherein said software program is configured to permit the entry of user satisfaction data and transmit said user satisfaction data to an authority for response thereto.

90. The rental vehicle transaction system of claim 83 wherein said software program is configured to provide a menu of action items for selective entry and processing by a user thereof, and further comprising a command through which a user may execute a plurality of entered action items all together without further operator action.

91. The rental vehicle transaction system of claim 83 wherein said software program has access to a data base in which data corresponding to an inventory of vehicles are kept, and wherein said software program is configured to permit a user to access said data base to thereby view replacement vehicles available for transfer to a customer.

92. The rental vehicle transaction system of claim 91 wherein said software program is configured to permit searching of said data base from parameters entered by said user.

93. The rental vehicle transaction system of claim 92 wherein said parameters include at least vehicle valuation.

94. The rental vehicle transaction system of claim 93 wherein said software program is configured to accept authorization for said transfer by an insurance company.

95. The rental vehicle transaction system of claim 71 wherein said rental vehicle software program is configured to communicate over the Internet through a stateless connection.

96. The rental vehicle transaction system of claim 83 wherein said rental vehicle software program is configured to communicate over the Internet through a stateless connection.

97. An Internet enabled automatic rental vehicle transaction system, said system having an Internet web site through which an authorized purchaser of rental vehicle services may access a rental vehicle software program resident on a computer system, said rental vehicle software program being configured to automatically respond to a series of commands from said authorized purchaser and communicate a rental vehicle reservation to at least one provider of said rental vehicle services, said at least one rental vehicle service providers offering a plurality of specific geographically remote rental vehicle locations at which vehicles for rent are situated, said rental vehicle reservation having sufficient information for authorizing, processing and billing said rental vehicle transaction so that a rental vehicle transaction may be automatically processed thereby for said at least one of said rental vehicle service provider, wherein said software program is configured to permit said authorized purchasers to modify said rental vehicle reservation through said Internet web site, wherein said authorized purchaser comprises a business organization, said business organization having a plurality of authorized purchasers, said plurality of authorized purchasers being enabled to access said Internet web site from any location offering Internet web access, and wherein said at least one rental vehicle service provider further comprises a second business organization, said second business organization having the computer system and rental vehicle software program resident therein, and wherein said rental vehicle software program is configured to communicate over the Internet through a stateless connection.