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

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 system 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.

REFERENCE TO A COMPUTER PROGRAM LISTING APPENDIX SUBMITTED ON COMPACT DISC

This application includes a computer program listing appendix submitted on a compact disc, the compact disc containing the files “Exhibit A.txt” (file created Aug. 13, 2012; file size of 316 kilobytes), “Exhibit C.txt” (file created Aug. 13, 2012; file size of 534 kilobytes), and “Exhibit D.txt” (file created Aug. 13, 2012; file size of 262 kilobytes), these files being incorporated herein by reference.

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 with 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 users 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 another 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 users 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 (owners) 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.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The overall system architecture for the first parent's invention20is best shown inFIG. 1. As shown therein, an insurance company computer system22, which itself may be virtually any computer configuration or even a stand alone PC accesses the Internet24through any convenient access point26such as even including an ISP (Internet service provider), as known in the art. Also connected to the Internet24is a web portal28which is preferably provided by a server appropriately programmed as explained herein below. This web portal28may 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 Internet24is preferable, except for scheduled downtimes for maintenance, etc. The service provider30which for purposes of explaining the first parent's preferred embodiment is preferably a vehicle rental organization, has itself an Internet portal mainframe32connected by a bi-directional communication link34to a second computer network36which may itself preferably have a mainframe server38. This second computer system36is preferably a network having a database40for communication with what may be thousands of branch offices each of which has its own computer interface44which communicates to this second mainframe server38to 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 computers32,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 link46extending between the server42and each of the branch offices44may 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 link46could 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 system36. 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 link46serves as the electronic umbilical cord through which branch offices44communicate with the business computer system36of the invention.

Attached hereto as exhibits are functional descriptions of the software programs resident on the computers comprising the two computer systems32,38which 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 computer38. Attached hereto as Exhibits B and C are related flow diagrams (seeFIGS. 4-91of Exhibit B) and explanatory text, respectively, for the software resident on the mainframe AS/400 computer32. Attached hereto as Exhibit D is a functional description of the software resident on computer32but which also appears on the server28which creates the web portal for access to the mainframe32and its resident program. Server28may 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 computer32. However, the software of Exhibit D could also be run on server28, 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 toFIG. 2. As shown therein, a right hand column is identified as “ECARS” which represents the integrated business software implemented as part of the mainframe operation38in computer network36. The center column headed “ARMS” is resident on mainframe computer32and coordinates the communication of data. The left column headed “ARMS/WEB” represents the software resident on computer but which is presented on server28and accessible by users through the Internet. Along the left side ofFIG. 2are 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 ofFIG. 2to the bottom. However, some functional features are permitted throughout the entirety of one of the three periods designated at the left side ofFIG. 2. One such example is the “message” function which allows messages to be sent between users at one business organization22and branch offices44and others connected to the other business organization30. 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 inFIG. 3and includes three levels of architecture. As shown in the first level of the architecture50, a user52such as an insurance company or other user has access through the Internet54to the computer system comprising and incorporating the invention. An Internet provider provides a link56through 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 firewall58as 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 servers60are interconnected in a network62and may preferably include an ancillary server64for running load balancing software or the like to balance the load and provide redundancy amongst what may be a plurality of web servers60. These web servers60may 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 servers60,62process the random and disorderly communications flowing to and from this system and the Internet before passing them through a firewall66as 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 architecture68is noted in the figure as the “Enterprise private network” and is comprised of a plurality of servers70network connected with a network connection72. 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 servers70and 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 architecture74, described below, but also to route the reservation information back through the first architectural level50and into the Internet54for transmission to a competitive service provider76. Although the interconnection is depicted inFIG. 3as being made through the Internet54, the network of servers70configured in accordance with the ARMS/WEB application software may utilize virtually any electronic means for transmitting the reservation information to a competitive services provider76. These include email, automated telephone, facsimile, and other forms of electronic communication. Of course, the competitive services provider76may itself comprise an integrated business such that the level of interconnectivity provided to the user52may 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 level74of the architectural topography shown inFIG. 3which parallels portions of that shown inFIG. 1in that a pair of network mainframe computers, such as AS/400's78,80may process reservations to and from various branch offices82which are geographically diverse.

With the invention, the Internet portal provided by the ARMS/WEB network configured servers70provide 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 providers76. Thus, the user52enjoys 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 servers70is 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 (seeFIG. 160), or some combination thereof. A first modality as exemplified byFIG. 160(option 1) 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 as exemplified byFIG. 160(option 2) 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 as exemplified byFIG. 160(option 3) 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” (seeFIG. 161).

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 (seeFIG. 164). 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 on-going rentals, among other tasks. The user would then re-connect 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” (seeFIG. 163) is provided that illustrates a sign in log for a user who wants to initiate a “synch”, and a second “screen shot” (seeFIG. 162) 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 synching of the data. Other preferences would include options on how synching issues when offline and main system transactions are updated. Also, a history feature will allow the user to display all of the synching activity from his connection or portal (e.g., a display of all of the snych events over a specified period of time) including error messages and conflicts noted (e.g., resolution to synch conflicts (i.e., the main system was updated after the local record was updated which record takes precedence)).

Yet another feature allows for a user to enter, or execute, a full menu of transactions without individually opening them from a summary menu (seeFIG. 165). This has been referred to as a “power template” feature. 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 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 users action list.FIG. 167shows an administrative feature whereby a user's defined preferences can include options to list management tasks for each of extensions, direct bill requests, and invoice billing as a list or individually.FIG. 166shows an action items list where 4 extension management tasks are displayed as a group for selection to access the power template ofFIG. 165.

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 (seeFIGS. 168-171). 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 (seeFIGS. 168 and 169) 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 (seeFIG. 169), 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 (seeFIG. 171) 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 (seeFIG. 174), 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” (seeFIG. 183) 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.

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. As extended for independent party management, this capability further adapts the invention for use with agencies such as “credit hire” (seeFIGS. 178-179), “lawyer” (seeFIG. 183), “fleet management companies”, or “repair facility” (see FIGS.177and181-182), or “assist companies” (seeFIGS. 175-176), all of which are found in other than domestic markets. A credit hire is a lawyer in England that represents clients before a claim is filed. The lawyer (credit hire) helps his/her 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. The “lawyer” is similar to the credit hire—this person manages the claim for his/her client. In England, this role is called “Credit Hire”, in Germany it is called “Lawyer”. 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. An assist company will take on the task of managing the rental process on behalf of the insurance company in managing the rental portion of the claim due to an 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.

Create/ReceiveAutho-Main-Re-Un-rizetain/PayUserportingassignedOwnReser-ExtendIn-Mainte-(Manage-Actionfiles*vationsRentalsvoicenance**ment)ItemsCreditXXXXXXHire(Lawyer)FleetXXXXXXXManage-mentCompanyAssistXXXXXXCompany*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 authorization for other users within his organization. For example, person “B” at ABC company has access to “user maintenance.” Person B can assign the access for persons C and A at ABC company, but not for Mr. D at DEF corporation.
Included herewith isFIG. 180which further explains the different types of independent parties routinely found at present, and examples of “screen shots” (seeFIGS. 172,173,183, and184) 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 (seeFIG. 185(the “Total Loss” selection in the “Vehicle Condition” field of the Create Reservation screen), 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 (seeFIG. 186), 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 customers claim has been satisfied. A flow chart describing this process is attached for further explanation (seeFIG. 187).

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.

Exhibit A

See the file “Exhibit A.txt” submitted on the incorporated compact disc.

Exhibit B

Exhibit C

See the file “Exhibit C.txt” submitted on the incorporated compact disc.

Exhibit D

See the file “Exhibit D.txt” submitted on the incorporated compact disc.

Exhibit E

ARMS Web 3.0

Functional Design Specification

Extend Rental

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 DescriptionThis 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 Case ActorsThe 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-ConditionsThe USER must have logged into the ARMS/Web system.The USER must have selected a previously authorized, open rental.
1.5 Flow of EventsThe Flow of Events will include the necessary steps to make changes and updates to “Extend Rental”.1.5.1 Activity Diagram—seeFIG. 92.1.5.2 Basic Flow1. 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 Extended 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 rental car company's rental system.8. This ends the use case.1.5.3 Alternative Flows1.5.3.1 View Rental NotebookAt 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 ConfirmationAfter 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 ProfileDuring 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 the1.5.3.4 Validate ChangesIf 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, 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.5.3.5 Change Customer FilePrior 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.1.5.3.6 Update ARMS/Web DatabaseAfter 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.
1.6 Post-ConditionsIf 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 RequirementsThe 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 Points1.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 ClassThe 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.8.3 MA-15 Terminate RentalAfter 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.1.8.4 MA-04 Send MessageThe 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.
2. Screen DesignA 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 Extend Rental DetailThis screen (seeFIGS. 93(a)-(e)) will allow the USER to pick which functions that he/she may want to change.2.1.1 Screen Layout—Extend Rental Detail—seeFIGS. 93(a)-(e)2.1.3 Extend Rental Detail

Screen LabelTypeSizeScreen Field NameData Field NameScreen Specific RuleAdditionalOutput15Additional ChargesChargesHandling For:Output30Handling forFirst Name + LastLast Name + FirstAdjuster's NameNameNameNote to SelfInput50MessageNOTEOnlyMessages:Output8Message CreationAdd DateN/A.DateNote toInput50Message TextNOTEN/A.Enterprise:Output50Message TextNOTEN/A.Claim Number:Output11Claim NumberInsurance ClaimPurchasePurchase OrderNumber, PO#, CC#Order NumberNumberCorporateCorporate ClassClass NumberNumberDaysOutput2Number of DaysNumber of DaysN/A.Authorized toAuthorizedAuthorizedDate:___additionalOutput2Number of Days toNumber of Days toauthorizedExtendExtenddaysPolicy LimitsList Box5Policy MaximumMax $ Covered +and Dollars per dayDollars Per DayCoveredOutput30Rental LocationRental LocationBranch Namedays @:List Box6Rental Location RateVehicle RateN/A.Date of RentalOutput10Rental Start DateStart DateN/A.Insured Name:Output30Insured's NameFirst Name + LastNameOutput30Rental LocationAddress Line +N/A.AddressAddress Line2Output25Rental LocationCityN/A.City NameOutput10Rental LocationZip CodeN/A.Postal/Zip CodeOutput3Rental LocationStateN/A.State/Province CodeOutput13Rental LocationTelephone NumberN/A.Telephone NumberDate of Loss:Output10Date of LossDate of LossOutput20Renter City NameCityOutput10Rental Postal/ZipZip CodeCodeOutput3Renter State/StateProvince CodeOutput30Renter StreetAddress LineAddressHome:Output16Renter's HomeRenters Night Phone +Not editable if ticketPhoneRenters Nightis Open.Phone ExtensionOutput30Renter's NameFirst Name + LastWill not be editable ifNameticket is open. FirstName + Last NameRenterOutput30Renter's NameFirst Name + LastN/A.Information:NameWork Phone:Output16Renter's WorkDay Phone +Will not be able toPhoneRenters Day Phoneedit if ticket is Open.ExtensionOwner'sOutput4Vehicle Year, MakeRenter Make/Model +vehicle:and ModelRenter Vehicle YearRepair Facility:Output20Body Shop NameRepair Facility NameInput16Body Shop PhoneTelephone NumberNumberOutput15Repair Facility CityCityOutput3Repair Facility StateStateOutput7Repair Facility zipZip CodecodeLast DayOutput10Date rental isCALCULATEDCalculated field.authorizedauthorized throughPopulated with anOpen Ticket only.Charges toOutput10Total ChargesCALCULATEDDate:Renter TypeOutput10Claim typeclaim typedescriptionClaims Office:Output3Office Idexternal organizationN/A.abbreviated nameVehicleOutput15Type of Lossloss type descriptionConditionRenter Email:Output20Renter's Emailrenter emailWill not be able toedit if ticket is Open.2.1.4 Screen Function DefinitionThis 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.4.1 SkipWhen 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.4.2 ProcessWhen 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 NotebookWhen 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 DateWhen 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.2.1.4.5 Transfer FileWhen 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 AddWhen 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 pageWhen clicked, the USER will be taken to the top of the current page.2.1.4.8 View Car ClassWhen 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 RentalWhen 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.
ARMS Web 3.0
Functional Design Specification
Review List—Action Items
Version 1.1

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/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 DescriptionThis use case describes how the USER would view and/or select any outstanding action items assigned to them.
1.3 Use Case ActorsThe 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-ConditionsThe 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 EventsThe Flow of Events will include the necessary steps for a USER to review and assign outstanding action items.1.5.1 Activity Diagram—seeFIG. 94.1.5.2 Basic Flow1. 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 RequestExtend a RentalHandle Unapproved Invoices/Pay Approved InvoicesSend a Message5. 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 Flows1.5.3.1 Handle For A Different USERUntil 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 list to include all outstanding items associated with the new ID.1.5.3.2 Re-sort Action Items ListAfter 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 FoundIf 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-ConditionsNone
1.7 Special Requirements1.7.1 Sort RequestThe 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.
1.8 Extension PointsAn 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 RentalAt 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 performed 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 RequestAt 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 InvoiceAt 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.
2. Screen DesignA 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 ItemsThis screen (seeFIGS. 95(a)-(e)) will allow the USER to pick which functions that he/she may want to change.2.1.1 Screen Layout—Action Items—seeFIGS. 95(a)-(e)2.1.2 Action Items—Summary

ScreenScreenScreenLabelTypeSizeField NameData FieldSpecific RuleDateOutput0Date Receivedaction itemN/A.Receivedassigned dateTypeOutput15Action Itemaction itemN/A.TypetypedescriptionUSEROutput0USER's NameFirst Name +N/A.Last NameHandlingList Box30Handling forFirst Name +N/A.For:USER's NameLast NameWelcomeOutput30User's NameFirst Name +N/A.BackLast NameClaimOutput0Claim NumberInsuranceN/A.NumberPurchase OrderClaimPurchaseNumberNumber,OrderCorporate ClassPO#, CC#NumberNumberCorporateClassNumberRenter'sOutput30Renter's NameFirst Name +N/A.NameLast NameClaimsList3OfficeexternalOffice:Boxorganizationabbreviatedname2.1.3 Screen Function DefinitionThis 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 NameWhen 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 RentalMA-10-Authorize RequestInvoicing—BI-01-Handle Unapproved Invoices & BI-02-Pay Approved Invoices & BI-03 Reject an InvoiceMA-19-Customer File (Message)
ARMS Web 3.0
Functional Design Specification
Assign a Request
Version 1.1

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 DescriptionThis 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 ActorsThe 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-ConditionsThe 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 EventsThe Flow of Events will include the necessary steps to make changes and updates to “Assign an Action Item”.1.5.1 Activity Diagram—seeFIG. 96.1.5.2 Basic Flow1. 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.1.5.3 Alternative Flows1.5.3.1 Cancel Use CaseThe USER should be capable of leaving the use case at any point prior to assigning the of the reservation information.1.5.3.2 Modify a RequestBefore step 6 of the basic flow, the USER should be able to make changes to the authorization.1.5.3.3 Select a different officeBefore step 6 of the basic flow, the USER should be able to select a selected, the user cannot assign the file to a new user. The new office must now assign the file.
1.6 Post-ConditionsIf 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 RequirementsNone
1.8 Extension Points1.8.1 MA-04 Send MessageThe 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 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.1.8.2 MA-10 Authorize a RequestThe USER may decide to enter into the full detail screen of the unassigned request, which would invoke the Authorize a Request use case.
2. Screen DesignA 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—UnassignedThis screen (seeFIGS. 97(a)-(e)) will allow the USER to assign action items to an office or USER. The USER may also cancel an item or change specified information in the Customer File through this screen.2.1.1 Screen Layout—Action Items—Unassigned (ARMS Web 2.0)—seeFIGS. 97(a)-(e)2.1.2 Action Items—Unassigned

Screen LabelTypeSizeScreen Field NameData Field NameScreen Specific RuleClaims Office:Output3Office IdexternalN/A.organizationabbreviatednameHandling For:Output30Handling forFirst Name +N/A.Adjuster's NameLast NameOutput30Renter's NameFirst Name +This should be a link.Last NameThe USER should beable to get to theauthorize page fromthis screen fieldOutput30Renter's AddressAddress LineOutput10Renter's CityCityOutput3Renter's StateStateOutput10Renter's Zip CodeZip CodeOutput16Renter's HomeRenters NightIf these fields arePhonePhone + Renterspopulated, add aNight Phonelabel to the screen toExtensiondifferentiate betweenHome Phone andWork PhoneOutput16Renter's WorkDay Phone +If these fields arePhoneRenters Daypopulated, add aPhone Extensionlabel to the screen todifferentiate betweenHome Phone andWork PhoneClaim NumberInput30Claim NumberInsuranceN/A.PurchasePurchase OrderClaim Number,Order NumberNumberPO#, CC#CorporateCorporate ClassClass NumberNumberVehicleList Box15Loss Typeloss type descriptionConditionClaim TypeList Box15Claim TypeRental typeN/A.Bill TypeBill TypedescriptionDate of Loss:Input10Date of LossDate of LossN/A.Note toInput30Message TextNOTEN/A.EnterpriseAssign toList Box5Office Idexternaloffice:organizationabbreviated nameAssignList Box30Adjuster NameFirst Name + LastLists only thoseadjuster:Nameadjusters the USERhas authority toassignScreen Function DefinitionThis 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<<PreviousWhen clicked, the USER will be taken back to the previous screen.2.1.2.2 ProcessWhen 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.1.2.3 CancelWhen 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.
ARMS/Web 3.0
Functional Design Specification
View Car Class
Version 1.3

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 DescriptionThis 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 ActorsThe 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-ConditionsThe USER must be signed-on to the ARMS/Web system.The USER must have a reservation or open ticket selected.
1.5 Flow of EventsThe Flow of Events will include the necessary steps to view and/or select the car class to apply to a rental reservation.1.5.1 Activity Diagram—seeFIG. 98.1.5.2 Basic FlowThe 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.5.3 Alternative Flows1.5.3.1 Select Alternate Car ClassFrom 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:EconomyCompactIntermediateStandardFull SizePremiumIf 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 RatesIf 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-ConditionsIf successful, the selected Car Class will be returned to the active reservation or open ticket.If unsuccessful, the system state is unchanged.
1.7 Special RequirementsThe 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 ResultsThe USER may change the results of this use case as part of the active reservation or open ticket.
1.8 Extension PointsNone.
2. Screen DesignA 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 ScreenThis screen (seeFIGS. 99(a)-(b)) 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—seeFIGS. 99(a)-(b)2.1.2 Car Class Details

ScreenScreenDataLabelTypeLengthField NameFieldScreen Specific RuleOutput20Car ClassThis should be theNamename of the currentlyselected car class.Output40RentalCompanyName(PersonOutput2Car ClassThis should provideImage)Personthe average personCapacitycapacity of the se-lected car class.(LuggageOutput2Car ClassThis should provideImage)Luggagethe average luggageCapacitycapacity of theselected car class.Hidden255Car ClassThis should provideImagea picture of anSourceexample car withinthe selected car class.Output120Car ClassThis should provideDetaila description of theDescriptionselected car class.EconomyOutputEconomyThis should be aCar Classhyperlink to theEconomy car classdetail.CompactOutputCompactThis should be aCar Classhyperlink to theCompact car classdetail.Inter-OutputInter-This should be amediatemediatehyperlink to theCar ClassIntermediate carclass detail.StandardOutputStandardThis should be aCar Classhyperlink to theStandard car classdetail.Full SizeOutputFull SizeThis should be aCar Classhyperlink to the FullSize car class detail.PremiumOutputPremiumThis should be aCar Classhyperlink to thePremium car classdetail.2.1.3 Screen Function DefinitionThis 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 ClassThe 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 PreviousThe 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.
3. Questions and AnswersNone.
ARMS/Web 3.0
Functional Design Specification
Authorize a Request
Version 1.1

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 DescriptionThis use case describes how a USER authorizes a direct bill request.
1.3 Use Case ActorsThe 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-ConditionsThe 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 EventsThe Flow of Events will include the necessary steps to make changes and updates to “Authorize Request”.1.5.1 Activity Diagram—seeFIG. 100.1.5.2 Basic Flow1. 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 Flows1.5.3.1 View NotebookAt 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 FileAt 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 FileAt 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 FileAt 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-ConditionsIf 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 Requirements1.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 Motorist’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 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 for editable fields based on reservation/ticket status1.7.1.3.1 Depending on the status of the Customer File the USER may change the following fields:

Unassigned/Assigned butField NameUnauthorizedUnauthorized(Depending onReservation/ReservationAuthorizedUSER Segment)Ticketor TicketTicketCLAIM NUMBERXXX(Insurance & Fleet)PURCHASE ORDERNUMBER (Dealership)CORPORATE CLASSNUMBER (Corporate)CLAIM TYPEXXX(Insurance)BILL TYPE(Dealership)VEHICLE CONDITIONXXXDATE OF LOSSXXX(Removed for corporate)INSUREDXXXINFORMATIONRENTERXINFORMATIONDATE RENTALXIS NEEDEDNUMBER OFXXAUTHORIZED DAYSDIRECT BILLXXXPERCENT(Insurance Only)POLICY LIMITSXXX(Insurance andCorporate Only)AUTHORIZED RATEXXXIf 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.1.7.1.3.2 If the status of the Customer File is an open ticket the following rules apply:

UnauthorizedAuthorizedReservation/AuthorizedActionsReservationTicketOpen TicketSend MessageXXXExtensionXTerminate RentalXCancel AuthorizationXXTransfer/Assign AdjusterXXXView Car ClassXXX
1.8 Extension PointsAn 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 MessageThe 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.1.8.2 MA-07 Additional ChargesThe 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 WorkThe 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 ClassThe USER may choose to view the car class. This button invokes the View Car Class use case.1.8.5 MA-17 Cancel AuthorizationThe 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.
2. Screen DesignA 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 DetailThis screen (seeFIGS. 101(a)-(e)) 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—seeFIGS. 101(a)-(e)2.1.2 Authorize Rental Detail

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 DescriptionThis use case will describe 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 ActorsThe 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 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-ConditionsThe USER must be signed in to the ARMS Web system.The USER must the authority to create a reservation.
1.5 Flow of EventsThe Flow of Events includes all steps necessary to create a reservation using the ARMS Web system.1.5.1 Activity Diagram—seeFIG. 102.1.5.2 Basic FlowThe 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 typeRenter First NameRenter Last NameRental CompanyTelephone Number or Postal Code where the renter would like to be picked up3. 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. (See section 1.5.3.1 Initial Reservation Information Invalid in Alternative Flows on page 4 for validation rules.)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 MatchesAn 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 the 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 MatchesReference 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 allocation 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).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. (See section 1.5.3.3 Reservation Information Invalid in Alternative Flows on page 5 for validation rules.)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, then the transaction is electronically transmitted to the intended rental car company's rental system.17. This ends the use case.1.5.3 Alternative FlowsThe Alternative Flows of this use case can occur when conditions exist or specific USER feedback is provided.1.5.3.1 Initial Reservation Information InvalidIf 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:0XX1XXthe 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.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 MatchesIf 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 InvalidIf 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. (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.)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.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:0XX1XXThe 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 id 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 CaseThe 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-ConditionsIf successful, a reservation authorization is sent to ARMS.If unsuccessful, the system state will be unchanged.
1.7 Special Requirements1.7.1 Requirements for Reference Number FormattingThe 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.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 field, a 5-character alphanumeric field, and a 4-character numeric field.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 correct). 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 LocationBelow 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 return 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.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 ReservationWhen 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 derived 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:00 pm and Sunday 11:00 pm, 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 in cases where a regional call center exists, see 1.7.3.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 Connections Hours are 5:00 a.m.-11:00 p.m. CST, 7 days a week. (Although we receive reservations 24 hours/day, 7 days/week, we do not route them between 11:45 pm and 4:30 am (CST). The only exception to this is Saturday night to Sunday.)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 in 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 determine if the selected rental branch location on a submitted reservation 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 call1.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 SystemsThis 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.
1.8 Extension PointsAn 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 RequestThe 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 FileThe 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 LocationThe 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 MessageThe 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 Flow upon completion of the Send Message use case.1.8.5 MA-07—Additional ChargesThe 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 ClassesThe 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.
2. Screen DesignA 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 Initial Reservation ScreenThe 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.2.1.1 Screen Layout—seeFIGS. 103(a)-(e)2.1.2 Screen Field Definition

Screen LabelTypeSizeScreen Field NameData FieldScreen Specific RuleOutput35User NameFirst Name +Should be presented as UserLast NameFirst Name + User Last NameOfficeCombo10Office LocationexternalThe default value should beBoxorganizationthe primary office of theidentifiercurrent user.The values presented in theOffice Location list should belimited to the offices that theuser has been granted theauthority to create areservation.If changed, the system shouldautomatically refresh thescreen and update the“Handling for” list to the usersin the newly selected officewith the ability to create areservation.Handling forCombo35Handling forFirst Name +The combo list should includeBoxLast Namethe users for the selectedoffice location that have theauthority to create areservation.The default value should be‘Yourself’.The handling for users shouldbe presented as User LastName + User First Name inalphabetical order.Claim NumberText Box30Claim NumberInsuranceShould be populated by thePurchase OrderPurchase OrderClaimReference Number enteredNumberNumberNumber, PO#,on the Initial ReservationCorporate ClassCorporate ClassCC#screen.NumberNumberReference number should bepresented in separate fields tocorrespond to the claimnumber format (segments)that has been defined by theUSER profile.If changed, the system shouldvalidate that no matchingreference numbers exist (i.e.,reference number matching).The user should be notified ifa match exists.Reference Number is a requiredfield.Insurance User - ClaimNumberFleet User - Claim NumberDealership User - PurchaseOrder NumberCorporate User - CorporateClass NumberClaim TypeCombo20Rental TypeRental typeShould be populated by theBill TypeBoxDescriptiondescriptionRental Type selected on theInitial Reservation screen.The values of the Rental Typefield for the Insurance userclass are: ‘Insured’,‘Claimant’, ‘Theft’, and‘Uninsured’. Claim Type is arequired field.VehicleCombo20Vehicle ConditionDriveable Flag +The values of the VehicleConditionBoxRepairableCondition field should include:Flag‘Driveable’, ‘Non-Driveable’,and ‘Total Loss’.the default value should be‘-Select Vehicle Condition-’.Renter FirstText15Renter First NameFirst NameShould be populated by theNameRenter First Name entered onthe Initial Reservation screen.If the Renter First Namechanges, and an exact/Unauthorized request matchexists on the Renter FirstName + Renter Last Namecombination, the user will benotified of this match.Renter First Name is arequired field.Renter LastText20Renter Last NameLast NameShould be populated by theNameRenter Last Name entered onthe Initial Reservation screen.If the Renter Last Namechanges, and an exact/Unauthorized request matchexists on the Renter FirstName + Renter Last Namecombination, the user will benotified of this match.Renter Last Name is arequired field.Combo10Renter PhoneThe combo list should includeBoxType 1the values: ‘Home’, ‘Work’,‘Mobile’, and ‘Pager’.The default value should be‘Select Type’Text15Renter PhoneDay PhoneIf the Where Needed criteriaNumber 1entered on the InitialReservation or Find a RentalLocation screen was‘Telephone’, the WhereNeeded Value from thescreen should be populated inthis field.At least one renter phonenumber is required.Text5Renter PhoneRenters DayN/AExtension 1PhoneExtensionPost CodeText10Renter PostalZip CodeIf the Where Needed criterionCodeentered on the InitialReservation or Find a RentalLocation screen was ‘PostalCode’, the Where NeededValue from the screen shouldbe populated in this field.Email addressText Box50email AddressN/ASend emailCheck1email ConfirmationThis field will default toconfirmationBoxIndicatorunchecked.to the renterAuthorizedText3Authorized NumberNumber OfThe Number of Days is aDaysof DaysDaysrequired field.AuthorizedPolicy LimitsCombo10Policy Daily LimitDollars PerThe combo list should includeBoxand PolicyDay Covered +the policy daily and maximumMaximumMax $ Coveredlimits as defined in thecompany/office profile.The policy limits should bepresented as ‘Policy DailyLimit + “/” + Policy MaximumLimit’.This field should default to‘Select Policy Limits’ if theClaim Type is ‘Insured’,‘Uninsured Motorist’, or ‘Theft’If the Claim Type is‘Claimant’, this field shouldNOT be displayed.‘Other’ should be a selectionin the list of options. Ifselected, the system willautomatically replace thecombo box with an open textbox to allow the USER to typein a Daily Policy Limit, and asecond open text box to allowthe USER to type in aMaximum Policy Limit.Combo20Authorized RateVehicle RateThis field should be a comboBoxbox that lists all of the ratesand car classes for the rentalbranch location in the format‘Rate + “ ” + Car Class’‘Other’ should be a selectionin the list of options. Ifselected, the system willautomatically replace thecombo box with an open textbox to allow the USER to typein a rate. A combo boxshould also be included thatallows the USER to select acar class with selections toinclude ‘Economy’, ‘Compact’,‘Intermediate’, ‘Standard’, and‘Full Size’.If the reservation is for an‘Insured’, ‘Uninsured’, or‘Theft’ Claim Type, the defaultselection for the field shouldbe ‘-Policy Limits-’If the reservation is for a‘Claimant’ Claim Type, thedefault selection for the fieldshould be‘-Select a rate-’.AdditionalOutputAdditional ChargesShould include the AdditionalChargeCharge Description, theAdditional Charge Value, andthe Additional Charge Type.More than one additionalcharge can exist.Direct Billing %Text3Authorized DirectBill To %The Direct Bill % shouldBill Percentdefault to 100%.The Direct Bill % is a requiredfield.AuthorizedOutput9Authorized TotalCALCULATEDThe authorized total amountTotal AmountAmountfield should show the totalamount (w/o taxes and gov'tsurcharges) authorized basedon the Number of DaysAuthorized, Rate, PolicyLimits, and Direct Bill percententered by the user.This field will calculate thetotal amount to be authorized(based on entry) when theUSER clicks the Calculatescreen function.RentalOutput30Rental LocationBranch NameN/ALocationBranch NameOutput30Rental LocationAddress LineN/AAddressOutput30Rental LocationAddress Line2N/AAddressOutput25Rental LocationCityN/ACity NameOutput10Rental LocationZip CodeN/APostal/Zip CodeOutput3Rental LocationStateN/AState/ProvinceCodeOutput20Rental LocationTelephoneN/ATelephone NumberNumberAdd the currentCheck1Add to FavoritesNOTShould default to falselocation to myboxIndicatorSTORED(unchecked).list of favoritesIf checked, the system shouldadd the current rental branchlocation to the favorites list inthe user profile on the basis ofthe reservation. The branchlocation address will appear inthe combo box on subsequentattempts until a description.FavoriteCombo30Favorite Locationlocation nameThe combo list should includeLocationsBoxthe descriptions of eachfavorite location as identifiedin the user profile.This field should default to‘-Select a Favorite Location-’.If a favorite location isselected, the application willinstantly retrieve the favoritelocation and refresh thereservation screen.Note toText400Authorizationmessage textN/AEnterpriseMessageNote to SelfText400Diary Notediary note textThe system will store the textOnlyentered into this field in theARMS Web database with theauthorization, but themessage will not be sent tothe branch.2.3.3 Screen Function DefinitionThis 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 LocationsThe More Locations screen function 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 ChargesThe 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.2.3.3.2.1 The Additional Charges screen function is invoked through a button click.2.3.3.3 View Car ClassThe 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 LocationThe 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 Confirm ReservationThe Confirm Reservation screen function 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 CancelThe 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.
2.4 Reservation Confirmation ScreenThe 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—seeFIGS. 106(a)-(c)2.4.2 Screen Field Definition

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 DescriptionThis 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. (The USER will also have the ability to select an alternate location by using the ‘Favorite Locations’ functionality built into the Create Reservation screens.) 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 ActorsThe 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-ConditionsThe 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 EventsThe Flow of Events includes all steps necessary to select rental location search criteria and retrieve an alternate rental branch location (s).1.5.1 Activity Diagram—seeFIG. 107.1.5.2 Basic FlowThe 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. (Rental branch locations have the ability to opt out of accepting ARMS/Web reservations.) 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 (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).) (based on USER search/selection criteria) to be used by the Create Reservation use case. (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 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 (The Branch name has been included for future usability purposes (e.g., Network Allocation).)AddressTelephone numberRates7. The use case is complete.1.5.3 Alternative Flows1.5.3.1 Search Criteria Entered is InvalidIf the USER enters an invalid 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 criteria is a telephone number and the first three digits (i.e., area code) meet the criteria below:0XX1XXthe second and third digits 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 criteria 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 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 No Rental Branch Locations FoundIf the system cannot determine a rental branch location based on the search criteria 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 LocationsIf 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 criteria.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.1.5.3.4 Use Case CancellationThe USER should be capable of leaving the use case at any time.
1.6 Post-ConditionsIf successful, a rental branch location will have been determined and returned to the Create Reservation use case.If unsuccessful, the system state remained unchanged.
1.7 Special RequirementsThe 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 LocationBelow 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/Web 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.1.7.2 Maintenance of Source SystemsThis use case requires that several existing AS/400 databases be used to query for information:Locator DatabaseOffice Information DatabaseThe 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 future.
1.8 Extension PointsNone.
2. Screen DesignA 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 Location Search Criteria ScreenThis screen allows the USER to select/input the search criteria 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—seeFIGS. 108(a) and (b)2.1.2 Search for Rental Location

ScreenScreenFieldDataScreenLabelTypeLengthNameFieldSpecific RuleRadio1SelectorA radio buttonButtonRadioshould be presentedButtonfor every rentalbranch locationrecord in the list.Only one radiobutton may beselected.The rental branchlocation that is theshortest distancefrom the searchcriteria enteredshould be thedefault.LocationOutput30RentalAddressA location shouldLocationLinebe presented forAddressevery rental branchlocation record inthe list.RentalOutput30RentalThe name of theCompanyCompanyrental company thatnameis available from thesearch criteria.MilesOutput4MilesMiles from searchfromcriteria should beSearchpresented for everyCriteriarental branchlocation record inthe list.CityOutput18RentalCityA city should beLocationpresented for everyCityrental branchNamelocation record inthe list.State/Output2RentalStateA state/provinceProvinceLocationshould be presentedState/for every rentalProvincebranch locationCoderecord in the list.CountryDrop14CountryNOTThis list shouldDownSTOREDconsist of UnitedStates and Canada.This will expand infuture releases.The selection willdefault to the homecountry of theUSER as definedin the USER profile.Input12WhereWhereTextNeededNeededValueValueRentalCombo20RentalThis is a list ofCompanyboxCompanyall the rentalcompanies thatare participating.Postal/Radio1Postal/NOTZip CodeButtonZip CodeSTOREDButtonTele-Radio1Tele-NOTThis should be thephoneButtonphoneSTOREDdefault radioButtonbutton selection.CityRadio1CityNOTButtonRadioSTOREDButtonAuto-Check-1NearestNOTThis should defaultmaticallyboxMatchSTOREDto checked.select theSelectionnearestoffice2.2.3 Screen Function DefinitionThis 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 LocationThe 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 YThe 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 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 YThe 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/MapThe 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 its own Details/Map button.2.2.3.5 Search AgainThe 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.
2.3 Location Details ScreenThis 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—seeFIGS. 110(a) and (b)2.3.2 Screen Field Definition

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 Enterprise (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 ActorsThe 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-ConditionsThe 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 EventsThe Flow of Events includes all steps necessary to enter MESSAGES and DIARY NOTES.1.4.1 Activity Diagram—seeFIG. 111.1.4.2 Basic FlowThe 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.1.4.3 Alternative Flows1.4.3.1 Send Diary Note OnlyThe 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 Enterprise rental branch location handling the reservation/ticket.1.4.3.2 Use Case CancellationThe USER should be capable of leaving the use case at any time.
1.5 Post-ConditionsIf 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 Requirements1.6.1 Submit Message ResponsibilitiesThe 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 PointsNone.
2. Screen DesignAs 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 Container2.1.1 Screen Layout—seeFIG. 112. (This is the screen layout for the Create Reservation screen. The Message screen container is part of this screen, and is shown here for illustrative purposes only.)The area of the screen under consideration is the container beginning with the Notebook heading. This is an example of how the message container might look on any given screen.2.1.2 Message Screen Container

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 ActorsThe 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-ConditionsThe 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 EventsThe Flow of Events will include the necessary steps to view, add and modify additional charges associated with a rental authorization.1.4.1 Activity Diagram—seeFIG. 113.1.4.2 Basic FlowThe 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.6. The system will return the USER to the active reservation or open ticket and populate Additional Charges. (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.)7. This ends this use case.1.4.3 Alternative Flows1.4.3.1 Additional Charges InvalidIf 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-ConditionsIf successful, the Additional Charges that were added or modified will be returned to the active reservation or open ticket.If unsuccessful, no Additional Charge will be added to the active reservation or open ticket.
1.6 Special RequirementsThe 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 ResponsibilitiesThe 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.1.6.2 Additional Charges DescriptionsBelow are the current additional charge descriptions used in the ARMS/400 system in the current state:

DAMAGE WAIVERSPECIALPAIDROP CHARGEMILEAGE CHARGEMISC CHARGESHOURLYSLPDAILYUNDERAGE DRIVERWEEKLYBABY CAR SEATMONTHLYSKI RACK
1.7 Extension PointsNone.
2. Screen DesignA 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 ChargesThis screen will allow the user to view, add, modify or remove additional charges associated with a reservation/authorization.2.1.1 Screen Layout—seeFIG. 114.2.1.2 Screen Field Definition

ScreenScreenFieldDataScreenLabelTypeLengthNameFieldSpecific RuleCDWCheck1CDW(CollisionBox(CollisionDamageDamageWaiver)Waiver)PAICheck1PAI(PersonalBox(PersonalAccidentAccidentInsurance)Insurance)UnderageCheck1UnderageDriverBoxDriverDrop ChargeCheck1DropBoxChargeMileageCheck1MileageChargeBoxChargeMisc. ChargeCheck1Misc.BoxChargeCheck BoxCreateText15AdditionalA description ofCharge TypeBoxChargethe additionalDescriptionsurcharge to beauthorized.AmountText6AdditionalAn Amount textBoxChargebox should beValueincluded for everycheck box onthe screen.TypeCombo20AdditionalA Type comboBoxChargebox should beTypeincluded for everycheck box on thescreen.Values include:Dollars per Day(DEFAULT);Dollars per Rental;Percentage ofRental2.1.3 Screen Function DefinitionThis 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 SurchargesThe 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 ProcessThe 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 PreviousThe 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.
3. Questions and AnswersNone.
Functional Design Specification
View Car Class
Version 1.2

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 ActorsThe following actors will interact with this use case:ADJUSTER—The ADJUSTER will use the case to view and/or select the car class that will apply to a reservation.
1.3 Pre-ConditionsThe USER must be signed-on to the ARMS Web system.The USER must have a reservation or open ticket selected.
1.4 Flow of EventsThe Flow of Events will include the necessary steps to view and/or select the car class to apply to a rental reservation.1.4.1 Activity Diagram—seeFIG. 98.1.4.2 Basic FlowThe Basic Flow of the View Car Class use case includes all of the required steps to view and/or select a car 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 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 Flows1.4.3.1 Select Alternate Car ClassFrom 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:EconomyCompactIntermediateStandardFull SizePremiumIf 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 RatesIf 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-ConditionsIf successful, the selected Car Class will be returned to the active reservation or open ticket.If unsuccessful, the system state is unchanged.
1.6 Special RequirementsThe 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 ResultsThe USER may change the results of this use case as part of the active reservation or open ticket.
1.7 Extension PointsNone.
2. Screen DesignA 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 ScreenThis screen (seeFIG. 99(a)) 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—seeFIG. 99(a)2.1.2 Car Class Details

ScreenScreenDataScreenLabelTypeLengthField NameFieldSpecific RuleOutput20Car ClassThis should beNamethe name of thecurrently selectedcar class.(PersonOutput2Car ClassThis should provideImage)Personthe average personCapacitycapacity of theselected car class.(LuggageOutput2Car ClassThis should provideImage)CapacityLuggagethe average luggagecapacity of theselected car class.Hidden255Car ClassThis should provideImagea picture of an exam-Sourceple car within theselected car class.Output120Car ClassThis should provideDetaila description of theDescriptionselected car class.EconomyOutputEconomyThis should be aCar Classhyperlink to theEconomy car classdetail.CompactOutputCompactThis should be aCar Classhyperlink to theCompact car classdetail.Inter-OutputInter-This should be amediatemediatehyperlink to theCar ClassIntermediate carclass detail.StandardOutputStandardThis should be aCar Classhyperlink to theStandard car classdetail.Full SizeOutputFull SizeThis should be aCar Classhyperlink to theFull Size car classdetail.PremiumOutputPremiumThis should be aCar Classhyperlink to thePremium car classdetail.2.1.3 Screen Function DefinitionThis 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 ClassThe 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 PreviousThe 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.
3. Questions and AnswersNone.
Functional Design Specification
Assign a Request
Version 1.1

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 ActorsThe 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-ConditionsThe 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 EventsThe Flow of Events will include the necessary steps to make changes and updates to “Assign an Action Item”.1.4.1 Activity Diagram—seeFIG. 115.1.4.2 Basic Flow1. 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.1.4.3 Alternative Flows1.4.3.1 Cancel Use CaseThe 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 RequestBefore step 6 of the basic flow, the USER should be able to make1.4.3.3 Select a different officeBefore 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-ConditionsIf 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 RequirementsNone.
1.7 Extension Points1.7.1 MA-04 Send MessageThe 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.1.7.2 MA-10 Authorize a RequestThe ADJUSTER may decide to enter into the full detail screen of the unassigned request, which would invoke the Authorize a Request case.1.7.3 MA-17 Cancel AuthorizationAt any point prior to assigning the file to an ADJUSTER, the USER should have the ability to cancel the authorization. If the authorization is canceled, 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.
2. Screen DesignA 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—UnassignedThis screen will allow the USER to 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.1.1 Screen Layout—Action Items—Unassigned—seeFIG. 116.2.1.2 Action Items—Unassigned

ScreenScreenDataScreenLabelTypeSizeField NameField NameSpecific RuleClaimsOutput3Office IdexternalN/A.OfficeorganizationabbreviatednameHandlingOutput30HandlingFirst Name +N/A.For:forLast NameAdjuster'sNameOutput30Renter'sFirst Name +This should beNameLast Namea link.The USERshould be ableto get to theauthorize pagefrom thisscreen field.Output30Renter'sAddressAddressLineOutput10Renter'sCityCityOutput3Renter'sStateStateOutput10Renter'sZip CodeZip CodeOutput16Renter'sRenters NightIf these fieldsHomePhone +are populated,PhoneRenters Nightadd a label toPhonethe screen toExtensiondifferentiatebetween HomePhone andWork Phone.Output16Renter'sDay Phone +If these fieldsWork PhoneRenters Dayare populated,Phoneadd a label toExtensionthe screen todifferentiatebetween HomePhone andWork Phone.ClaimInput30ClaimInsuranceN/A.NumberNumberClaimNumberVehicleList15Loss Typeloss typeConditionBoxdescriptionClaimList15Claim Typeclaim typeN/A.TypeBoxdescriptionDate ofInput10Date of LossDate of LossN/A.Loss:Note toInput30MessageNOTEN/A.EnterpriseTextAssign toList5Office Idexternaloffice:BoxorganizationabbreviatednameAssignList30AdjusterFirst Name +Lists onlyadjuster:BoxNameLast Namethoseadjusters theUSER hasauthorityto assign.2.1.3 Screen Function DefinitionThis 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<<PreviousWhen clicked, the USER will be taken back to the previous screen.2.1.3.2 ProcessWhen 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.1.3.3 CancelWhen 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.2.1.3.4 Last Action MessageAfter 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.
3. Application Operations
4. Data Fields
4.1 Data Field DefinitionThis section includes a definition of all data fields included in the functional specification.

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 ActorsThe following actors will interact with this use case:ADJUSTER—The USER will use this system to authorize a direct bill request.
1.3 Pre-ConditionsThe 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 EventsThe Flow of Events will include the necessary steps to make changes and updates to “Authorize Request”.1.4.1 Activity Diagram—seeFIG. 117.1.4.2 Basic Flow1. 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.
1.4.3 Alternative Flows1.4.3.1 View NotebookAt 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 FileAt 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 FileAt 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 FileAt 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-ConditionsIf 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 system will be notified of authorization changes.If the use case was unsuccessful then the system state will be unchanged.
1.6 Special Requirements1.6.1 Requirements for Claim Type AuthorizationsThe 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 Motorist’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.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/ticket status1.6.1.3.1 Depending on the status of the Customer File the adjuster may

Unassigned/Assigned butUnauthorizedUnauthorizedReservation/Reservation orAuthorizedField NameTicketTicketTicketCLAIM NUMBERXXXCLAIM TYPEXXXLOSS TYPEXXXDATE OF LOSSXXXINSURED INFORMATIONXXXRENTER INFORMATIONXDATE RENTAL IS NEEDEDXADDITIONAL CHARGESXXXNUMBER OF AUTHORIZEDXXDAYSBILL-TO PERCENTXXXPOLICY LIMITSXXXAUTHORIZED RATEXXXIf 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.1.6.1.3.2 If the status of the Customer File is an open ticket the following rules apply:

UnauthorizedAuthorizedReservation/AuthorizedActionsReservationTicketOpen TicketSend MessageXXXExtensionXTerminate RentalXCancel AuthorizationXXTransfer/Assign AdjusterXXXView Car ClassXXX
1.7 Extension PointsAn 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 MessageThe 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 ClassThe ADJUSTER may choose to view the car class. This button invokes the View Car Class use case.1.7.4 MA-17 Cancel AuthorizationThe 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 authorization.
2. Screen DesignA 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 DetailThis 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—seeFIG. 118.2.1.2 Authorize Rental Detail

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 nor an open rental.
1.2 Use Case ActorsThe 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-ConditionsThe USER must be logged into the ARMS Web system.The USER must have selected to change an existing Customer File.
1.4 Flow of EventsThe Flow of Events will include the necessary steps to make changes to a Customer File.1.4.1 Activity Diagram—seeFIG. 119.1.4.2 Basic Flow1. 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 Flows1.4.3.1 View Rental NotebookAt 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 ChangesIf 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 ConfirmationAfter 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 ProfileDuring 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-ConditionsIf 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 RequirementsIt 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.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,’ 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,’ 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:0XX1XXthe 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 that does not consist of 5 or 9 digits.It will be considered invalid if the 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.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 Points1.7.1 MA-04 Send a MessageThe 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.1.7.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.1.7.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 AuthorizationBefore 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 ClassThe 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.
2. Screen DesignA 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 DetailThis screen (seeFIGS. 120(a) and (b)) 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—seeFIGS. 120(a) and (b)2.1.2 Change Rental Detail

Screen SpecificScreen LabelTypeSizeScreen Field NameData Field NameRuleAdditionalOutput15Additional ChargesChargesHandling For:Output30Handling forFirst Name + LastLast Name + FirstAdjuster's NameNameNameNote to SelfInput50MessageNOTEOnlyMessages:Output8Message CreationAdd DateN/A.DateNote toInput50Message TextNOTEN/A.Enterprise:Output50Message TextNOTEN/A.Claim Number:Output11Claim NumberInsurance ClaimNumberDaysOutput2Number of DaysNumber Of DaysN/A.Authorized toAuthorizedAuthorizedDate:____ additionalOutput2Number of Days toNumber of Days toauthorizedExtendExtenddaysPolicy LimitsList Box5Policy Maximum andMax $ Covered +Dollars per dayDollars Per DayCoveredOutput30Rental LocationRental LocationBranch Namedays @:List Box6Rental Location RateVehicle RateN/A.Date of RentalOutput10Rental Start DateStart DateN/A.Insured Name:Output30Insured's NameFirst Name + LastNameOutput30Rental LocationAddress Line +N/A.AddressAddress Line2Output25Rental Location CityCityN/A.NameOutput10Rental LocationZip CodeN/A.Postal/Zip CodeOutput3Rental Location State/StateN/A.Province CodeOutput13Rental LocationTelephone NumberN/A.Telephone NumberDate of Loss:Output10Date of LossDate of LossOutput20Renter City NameCityOutput10Rental Postal/ZipZip CodeCodeOutput3Renter State/StateProvince CodeOutput30Renter StreetAddress LineAddressHome:Output16Renter's HomeRenters Night Phone +Not editable if ticketPhoneRenters Nightis Open.Phone ExtensionOutput30Renter's NameFirst Name + LastWill not be editable ifNameticket is open. FirstName + Last NameRenterOutput30Renter's NameFirst Name + LastN/A.Information:NameWork Phone:Output16Renter's Work PhoneDay Phone +Will not be able toRenters Day Phoneedit if ticket is Open.ExtensionOwner'sOutput4Vehicle Year, MakeRenter Make/Model +vehicle:and ModelRenter VehicleYearRepair Facility:Output20Body Shop NameRepair Facility NameInput16Body Shop PhoneTelephone NumberNumberOutput15Repair Facility CityCityOutput3Repair Facility StateStateOutput7Repair Facility zipZip CodecodeLast DayOutput10Date rental isCALCULATEDCalculated field.authorizedauthorized throughPopulated with anOpen Ticket only.Charges toOutput10Total ChargesCALCULATEDDate:Renter TypeOutput10Claim typeclaim typedescriptionClaims Office:Output3Office Idexternal organizationN/A.abbreviated nameVehicleOutput15Type of Lossloss type descriptionConditionRenter Email:Output20Renter's Emailrenter emailWill not be able toedit if ticket is Open.2.1.3 Screen Function DefinitionThis 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 SkipWhen 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 ProcessWhen 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 NotebookWhen 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 DayWhen 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 FileWhen 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.3.6 Change or AddWhen 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 pageWhen clicked, the USER will be taken to the top of the current page.2.1.3.8 View Car ClassWhen 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 clicked 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 MessageAfter 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.
3. Application Operations
4. Data Fields
4.1 Data Field DefinitionThis section includes a definition of all data fields included in the functional specification.

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 Enterprise of the last day that the ADJUSTER will pay for a rental. In most cases, by providing a date in the future, Enterprise will receive an extension through the last day.
1.2 Use Case ActorsThe following actors will interact with this use case:ADJUSTER—The USER will use this case to terminate a rental.
1.3 Pre-ConditionsThe 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 EventsThe Flow of Events will include the necessary steps to terminate a rental.14.1 Activity Diagram—seeFIG. 121.14.2 Basic Flow1. 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 Flows1.4.3.1 PreviousAfter 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 CommentsWhen 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 ConfirmationAfter 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 ProfileDuring 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-ConditionsIf 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.
1.6 Special Requirements1.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.

AuthorizationCurrent DateDateTermination Date6/206/25>=6/206/206/10>=6/101.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 PointsNone.
2. Screen DesignA 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 RentalThis screen (seeFIG. 122) will allow the user enter the information about terminating a rental.2.1.1 Screen Layout—Terminate Rental—seeFIG. 1222.1.2 Terminate Rental

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 ActorsThe 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.ADJUSTERPROCESSOR
1.3 Pre-ConditionsThe 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 EventsThe Flow of Events will include the necessary steps for a USER to reassign action items.1.4.1 Activity Diagram—seeFIG. 123.1.4.2 Basic Flow1. 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 the 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 Flows1.4.3.1 Change OfficeAfter 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 CaseThe 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.1.4.3.3 Display ConfirmationAfter 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 ProfileDuring 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-ConditionsIf 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 RequirementsWhen 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.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 PointsNone.
2. Screen DesignA 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 FileThis screen (seeFIG. 124) will allow the USER to pick which functions that they may want to change.2.1.1 Screen Layout—Transfer File—seeFIG. 1242.1.2 Transfer File

Screen LabelTypeSizeScreen Field NameData Field NameScreen Specific RuleAdjuster'sListBox30Change to Adjuster'sFirst Name + LastList of adjuster's withinNameNameNamethe currently selectedAssign to Claim Officethat are authorized tohandle the currentrequest type. Theadjuster that the requestis currently assigned towill be selected uponentry into the screen.Adjuster'sOutput30Current Adjuster'sFirst Name + LastN/A.Name:NameNameClaims OfficeListBox3Change to Office IdexternalList of office within theorganizationcurrent CompanyidentifierStructure that areauthorized to handle thecurrent request type.The office that therequest is currentlyassigned to will beselected in the dropdown box upon entryinto the screen.Claims Office:Output3Current Office IdexternalN/Aorganizationabbreviated name2.1.3 Screen Function Definition2.1.3.1 CancelWhen 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 ProcessWhen clicked, the system 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.
3. Application Operations
4. Data Fields
4.1 Data Field DefinitionThis section includes a definition of all data fields included in the functional specification.4.1.1 external organization abbreviated name

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 ActorsThe 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-ConditionsThe 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 EventsThe Flow of Events will include the necessary steps to “Cancel Authorization”.1.4.1 Activity Diagram—seeFIG. 125.1.4.2 Basic Flow1. 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 Flows1.4.3.1 PreviousAfter 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 CommentsWhen 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 ConfirmationAfter 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 ProfileDuring 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-ConditionsIf 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 RequirementsWhen 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 PointsNone.
2. Screen DesignA 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 AuthorizationThis screen (seeFIG. 126) will allow the USER to pick which functions that he/she may want to change.2.1.1 Screen Layout—Cancel Direct Bill Authorization—seeFIG. 1262.1.2 Cancel Direct Bill Authorization

Screen SpecificScreen LabelTypeSizeScreen Field NameData Field NameRuleReasonList Box50Cancellation ReasonNOTEN/AComment:Input50Message TextNOTERequired ifcancellation reasonis “Other”Claim #Output30Claim NumberInsurance ClaimNumberRenter's NameOutput30Renter's NameFirst Name + LastN/AName21.3 Screen Function DefinitionThis 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 PreviousWhen 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 ProcessWhen clicked, the 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.
3. Application Operations
4. Data Fields
4.1 Data Field DefinitionThis section includes a definition of all data fields included in the functional specification.

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 ActorsAll 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:ADJUSTERPROCESSORCOMPANY MANAGERENTERPRISE ADMINISTRATORCOMPANY ADMINISTRATOR
1.3 Pre-ConditionsThe 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 EventsThe Flow of Events includes all the steps necessary to View Rental Detail in the ARMS Web system.1.4.1 Activity Diagram—seeFIG. 127.1.4.2 Basic FlowThe 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 Flows1.4.3.1 Search AgainAfter 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 FoundAt 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.1.4.3.3 View OnlyIf 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-ConditionsIf 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 RequirementsTo 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.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 Points1.7.1.1 MA-10 Authorized a RequestIf 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 RentalIf 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 AuthorizationIf 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 ChargesThe 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 ClassThe 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—81-01—Handle Unapproved Invoices & BI-02 Pay Approved Invoices & BI-03 Reject an InvoiceAt 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.
2. Screen DesignA 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)—seeFIG. 1282.1.2 Customer (tab)

4.1.1 Add DateEntityARM: ARMS/400 Diary Notes FileColumn NameNEADDTLabel NameAdd DateSystem NameData TypeNUMERIC(8)Attribute Definition4.1.2 Address LineEntityARM: Renter Location MasterColumn NameLOADL1Label NameSystem NameData TypeCHAR(30)Attribute Definition4.1.3 Address LineEntityARM: Renter DetailColumn NameRKADL1Label NameAddress LineSystem NameData TypeCHAR(30)Attribute Definition4.1.4 Address Line2EntityARM: Renter Location MasterColumn NameLOADL2Label NameAddress LineSystem NameData TypeCHAR(30)Attribute Definition4.1.5 Bill To %EntityARM: Authorization(Claim Info)Column NameAZBTPCLabel NameBill To %System NameData TypeDECIMAL(3)Attribute Definition4.1.6 Bill To End DateEntityA4 Invoice HeaderColumn NameIIBTDTLabel NameBill To End DateSystem NameData TypeNUMERIC(8)Attribute Definition4.1.7 Bill to Start DateEntityA4 Invoice HeaderColumn NameIISRDTLabel NameBill to Start DateSystem NameData TypeNUMERIC(8)Attribute Definition4.1.8 BranchEntityARM: Rental Location MasterColumn NameBranchLabel NameBranch:System NameData TypeCHAR(2)Attribute Definition4.1.9 CityEntityARM: Rental Location MasterColumn NameLOCYNMLabel NameCitySystem NameData TypeCHAR(20)Attribute Definition4.1.10 CityEntityARM: Renter DetailColumn NameRKCYNMLabel NameCitySystem NameData TypeCHAR(20)Attribute Definition4.1.11 CityEntityARM: Repair DetailColumn NameRUCYNMLabel NameCitySystem NameData TypeCHAR(20)Attribute Definition4.1.12 claim type codeEntityAUTHORIZATION EXTENSIONColumn Nameclm_typ_cdeLabel Nameclaim type code:System NameCLMTYPCDEData TypeDEC(3,0)Attribute DefinitionThe claim type code defines the differentAuthorization claim types. For example: Insured,Claimant, Uninsured Motorist, etc.4.1.13 claim type descriptionEntityCLAIM TYPEColumn Nameclm_typ_dscLabel Nameclaim type description:System NameCLMTYPDSCData TypeCHAR(40)Attribute DefinitionThe claim type description is a lexicaldefinition of the claim type code which defines thedifferent Authorization claim types. For example:Insured, Claimant, Uninsured Motorist, etc.4.1.14 company identifierEntityEXTERNAL ORGANIZATIONColumn Namecmpy_idLabel Namecompany identifier:System NameCMPYIDData TypeDEC(11,0)Attribute DefinitionBusiness Party Identifier is a surrogate keyassigned to each unique occurrence of anIndividual, External Organization, and InternalOrganization (Business Party).4.1.15 Date of LossEntityARM: Renter DetailColumn NameRKLSDTLabel NameDate Of LossSystem NameData TypeNUMERIC(8)Attribute Definition4.1.16 Day PhoneEntityARM: Renter DetailColumn NameRKDYPHLabel NameDay PhoneSystem NameData TypeNUMERIC(10)Attribute Definition4.1.17 Days authorized-detailEntityARM: ARMS/400 Diary Notes FileColumn NameNEAUDYLabel NameDays authorized-detailSystem NameData TypeDECIMAL(3)Attribute Definition4.1.18 Dollars Per Day CoveredEntityARM: Authorization(Claim Info)Column NameAZ$PDYLabel NameDollars Per Day CoveredSystem NameData TypeDECIMAL(5,2)Attribute Definition4.1.19 End DateEntityARM: Authorization(Claim Info)Column NameAZENDTLabel NameEnd DateSystem NameData TypeNUMERIC(8)Attribute Definition4.1.20 external organization identifierEntityEXTERNAL ORGANIZATIONColumn Namee_o_idLabel Nameexternal organization identifier:System NameEOIDData TypeDEC(11,0)Attribute DefinitionThe external organization identifieris a surrogate key assigned to each uniqueoccurrence of an External Organization.Examples: body shops, vehicle manufacturers,insurance companies, leasing accounts,credit unions, dealerships, or government agencies.4.1.21 Federal ID NumberEntityA4 Invoice HeaderColumn NameIIFETXLabel NameFederal ID NumberSystem NameData TypeCHAR(15)Attribute Definition4.1.22 First NameEntityARM: Adjustor MasterColumn NameALFSNMLabel NameFirst NameSystem NameData TypeCHAR(15)Attribute Definition4.1.23 First NameEntityARM: Insured DetailColumn NameIRFSNMLabel NameFirst NameSystem NameData TypeCHAR(15)Attribute Definition4.1.24 First NameEntityARM: Renter DetailColumn NameRKFSNMLabel NameFirst NameSystem NameData TypeCHAR(15)Attribute Definition4.1.25 GroupEntityARM: Rental Location MasterColumn NameGroupLabel NameGroup NumberSystem NameData TypeCHAR(2)Attribute Definition4.1.26 Insurance Claim NumberEntityARM: Authorization(Claim Info)Column NameAZCLNOLabel NameInsurance Claim NumberSystem NameData TypeCHAR(20)Attribute Definition4.1.27 Invoice NumberEntityA4 Invoice HeaderColumn NameI1INN0Label NameInvoice NumberSystem NameData TypeCHAR(20)Attribute Definition4.1.28 LAST AUT DAYEntityA4 Cross ReferenceColumn NameX4LADTLabel NameLAST AUT DAYSystem NameData TypeNUMERIC(8)Attribute Definition4.1.29 Last NameEntityARM: Adjustor MasterColumn NameALLSNMLabel NameLast NameSystem NameData TypeCHAR(20)Attribute Definition4.1.30 Last NameEntityARM: Insured DetailColumn NameIRLSNMLabel NameLast NameSystem NameData TypeCHAR(20)Attribute Definition4.1.31 Last NameEntityARM: Renter DetailColumn NameRKLSNMLabel NameLast NameSystem NameData TypeCHAR(20)Attribute Definition4.1.32 loss type codeEntityAUTHORIZATION EXTENSIONColumn Nameloss_typ_cdeLabel Nameloss type code:System NameLOSSTYPCDEData TypeDEC(3,0)Attribute DefinitionThe loss type code defines the differentloss categories when an Insurance Companyauthorizes a Rental. For example: Theft, Drivable,Repairable, Non-drivable, Non-repairable, Totaled.4.1.33 loss type descriptionEntityLOSS TYPEColumn Nameloss_typ_dscLabel Nameloss type description:System NameLOSSTYPDSCData TypeCHAR(40)Attribute DefinitionThe loss type description is a lexicaldefinition of the loss type code which defines thedifferent loss categories when an Insurance Companyauthorizes a Rental. For example: Theft, Drivable,Repairable, Non-drivable, Non-repairable, Totaled.4.1.34 Max $ CoveredEntityARM: Authorization (Claim Info)Column NameAZ$MAXLabel NameMAX $ CoveredSystem NameData TypeDECIMAL(9,2)Attribute Definition4.1.35 message ecars indicatorEntityAUTHORIZATION MESSAGEColumn Namemsg_ecars_indLabel Namemessage ecars indicator:System NameMSGECARINDData TypeCHAR(1)Attribute DefinitionThe message ecars indicator indicates whetherthe message is sent/received from the ecars system.4.1.36 NOTEEntityARM: ARMS/400 Diary Notes FileColumn NameNENOTELabel NameNOTESystem NameData TypeCHAR(50)Attribute Definition4.1.37 Number Of Days AuthorizedEntityARM: Authorization(Claim Info)Column NameAZAUDYLabel NameNumber Of Days AuthorizedSystem NameData TypeDECIMAL(3)Attribute Definition4.1.38 Rate ChargedEntityARM: Authorization(Claim Info)Column NameAZRTCHLabel NameRate ChargedSystem NameData TypeDECIMAL(5,2)Attribute Definition4.1.39 Record Add DateEntityA4 Invoice HeaderColumn NameI1ADDTLabel NameRecord Add DateSystem NameData TypeNUMBER(8)Attribute Definition4.1.40 Rental LocationEntityARM: Authorization(Claim Info)Column NameAZRNLCLabel NameRental LocationSystem NameData TypeCHAR(10)Attribute Definition4.1.41 renter emailEntityRENTER EXTENSIONColumn Namerentr_emlLabel Namerenter email:System NameRENTREMLData TypeCHAR(70)Attribute DefinitionThe email address of the renter.4.1.42 Renter Make/ModelEntityARM: Renter DetailColumn NameRKVHMMLabel NameRenter Make/ModelSystem NameData TypeCHAR(15)Attribute Definition4.1.43 Renter Vehicle YearEntityARM: Renter DetailColumn NameRKVHYRLabel NameRenter Vehicle YearSystem NameData TypeNUMERIC(4)Attribute Definition4.1.44 Renters Day Phone ExtensionEntityARM: Renter DetailColumn NameRKDYEXLabel NameRenters Day Phone ExtensionSystem NameData TypeNUMERIC(4)Attribute Definition4.1.45 Renters Night PhoneEntityARM: Renter DetailColumn NameRKNTPHLabel NameRenters Night PhoneSystem NameData TypeNUMERIC(10)Attribute Definition4.1.46 Renters Night Phone ExtensionEntityARM: Renter DetailColumn NameRKNTEXLabel NameRenters night Phone ExtensionSystem NameData TypeNUMERIC(4)Attribute Definition4.1.47 Repair Facility NameEntityARM: Repair DetailColumn NameRURFNMLabel NameRepair Facility NameSystem NameData TypeCHAR(35)Attribute Definition4.1.48 standard message descriptionEntitySTANDARD MESSAGEColumn Namestd_msg_dscLabel Namestandard message description:System NameSTDMSGDSCData TypeCHAR(50)Attribute DefinitionThe standard message description ifa lexical definition for standard message code whichdefines a predefined message which is applicable tospecific activity type code. For example:“Authorization confirmed on & Date with ReservationNumber & Resnumber”4.1.49 Start DateEntityARM: Authorization(Claim Info)Column NameAZSTDTLabel NameStart DateSystem NameData TypeNUMERIC(8)Attribute Definition4.1.50 StateEntityARM: Rental Location MasterColumn NameLOSACDLabel NameStateSystem NameData TypeCHAR(2)Attribute Definition4.1.51 StateEntityARM: Renter DetailColumn NameRKSACDLabel NameStateSystem NameData TypeCHAR(2)Attribute Definition4.1.52 StateEntityARM: Repair DetailColumn NameRUSACDLabel NameStateSystem NameData TypeCHAR(2)Attribute Definition4.1.53 Status DescriptionEntityARM: ARMS/400 Cross Reference Status Table FileColumn NameXUSTDSLabel NameStatus DescriptionSystem NameData TypeCHAR(6)Attribute Definition4.1.54 Telephone NumberEntityARM: Rental Location MasterColumn NameLOPHNOLabel NameTelephone NumberSystem NameData TypeNUMERIC(10)Attribute Definition4.1.55 Telephone NumberEntityARM: Repair DetailColumn NameRUPHNOLabel NameTelephone NumberSystem NameData TypeNUMERIC(10)Attribute Definition4.1.56 Total Amount DueEntityA4 Invoice TrailerColumn Name13BL$$Label NameTotal Amount DueSystem NameData TypeDECIMAL(9,2)Attribute Definition4.1.57 Total Amount ReceivedEntityA4 Invoice TrailerColumn Name13RC$$Label NameTotal Amount ReceivedSystem NameData TypeDECIMAL(9,2)Attribute Definition4.1.58 Total Ticket ChargesEntityA4 Invoice TrailerColumn Name13TO$$Label NameTotal Ticket ChargesSystem NameData TypeDECIMAL(9,2)Attribute Definition4.1.59 Transmission CodeEntityARM: ARMS/400 Diary Notes FileColumn NameNETRCDLabel NameTransmission CodeSystem NameData TypeChar(1)Attribute Definition4.1.60 Vehicle ClassEntityARM: Authofization(Claim Info)Column NameAZVHCSLabel NameVehicle ClassSystem NameData TypeCHAR(2)Attribute Definition4.1.61 Vehicle RateEntityARM: Authorization(Claim Info)Column NameAZVHRTLabel NameVehicle RateSystem NameData TypeDECIMAL(5,2)Attribute Definition4.1.62 Zip CodeEntityARM: Rental Location MasterColumn NameLOZPCDLabel NameZip CodeSystem NameData TypeCHAR(9)Attribute Definition4.1.63 Zip CodeEntityARM: Rental DetailColumn NameRKZPCDLabel NameZip CodeSystem NameData TypeCHAR(9)Attribute Definition4.1.64 Zip CodeEntityARM: Repair DetailColumn NameRUZPCDLabel NameZip CodeSystem NameData TypeCHAR(9)Attribute Definition
Functional Design Specification
Handle Unapproved Invoices
Version 1.1
1. Handle Unapproved Invoices Use Case
1.1 Brief DescriptionThe 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 ActorsThe 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-ConditionsThe 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 EventsThe Flow of Events will include the necessary steps for an ADJUSTER to approve and pay invoices.1.4.1 Activity Diagram—seeFIG. 131.1.4.2 Basic Flow1. 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 set up 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 List1. 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 List1. 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 Invoice1. 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 Flows1.4.3.1 Selected Action Item is Payment ListAt 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 InvoiceAt 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.1.4.3.3 View Customer FileAt 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 InvoiceAt 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 will choose to return to the step one of the Basic Flow by hitting the “back” button on the web browser.1.4.3.5 Print an Invoice ListAt 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.1.4.3.6 Skip InvoiceAt 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.1.4.3.7 Payment by PROCESSORIf 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.1.4.3.8 Amount Being Approved Exceeds USER'S Authorization LimitsWhen 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 NumberAt 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-ConditionsIf 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 RequirementsThe 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 ARMS Web Routes InvoicesBefore 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 FieldOn 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 IntegrationIt 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 PointsAn 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 InvoiceThe 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.1.7.2 MA-19-View Rental DetailThe 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.
2. Screen DesignA 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 PaymentThis 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.2.11 Invoicing—Individual Payment—seeFIG. 132

Screen LabelTypeSizeScreen Field NameData FieldScreen Specific RuleOutput30Rental Location'sAddress Line +Mailing StreetAddress Line2AddressOutput15Line Item ChargeItem DescriptionThis line may repeatDescriptionmultiple timesdepending on thenumber of taxes andsurcharges thatapply.Output15,2Line Item ChargeItem AmountLine Item Charge Qty *DescriptionLine Item ChargeAmount. This linemay repeat multipletimes depending onthe number of taxesand surcharges thatapply.Claim No:Input15Claim NumberInsurance ClaimNumberInvoice Date:Output10Invoice Date (Ecar'sRecord Add DateTicket Date)Reference:Output20Invoice IDInvoice NumberRental Group ID +Rental Branch ID +ECARS TicketNumberPlease includeOutput20Invoice IdInvoice NumberRental Group Id +this referenceRental Branch Id +number onECARS Ticketyour checkNumberFederal ID:Output30Location's Federal Id.Federal ID NumberFederal ID:Output30Location's Federal IDFederal ID NumberAmountOutput15,2Amount of rentalTotal AmountReceivedCharges receivedReceivedTotal Due:Input15,2Total Amount DueTotal Amount Duefrom Ins. CompanyTotal Charges:Output15,2Total Rental TicketTotal Ticket ChargesChargesHandling For:Output30Handling forFirst Name + LastAdjuster's First name +Adjuster's NameNameAdjuster's lastname. The name ofthe adjuster to whichthe invoice iscurrently assigned.Output150MessagesNOTEThis field will repeatmultiple lines for alldiary notes(messages) for thisreservation.toOutput10AuthorizationEnd DateTermination DatetoOutput10AuthorizationEnd DateTermination DateDirect BillOutput15,0Authorized BillBill to %PercentpercentageDirect BillOutput15,0Authorized BillBill to %PercentpercentageAuthorizedOutput10Authorized Start DateStart DatePeriod:Billed Period:Output10Authorized Start DateStart DateClaim NumberInput15Claim NumberInsurance ClaimWill be pre-filled withNumberthe claim numbercurrently on theauthorization.toOutput10Close date of RentalEnd DateTicketPolicy: DailyOutput15,2Policy DailyDollars Per DayRate-MaxMaximum Amount +CoveredDollars:Policy MaximumPolicy: DailyOutput15,2Policy DailyMax $ CoveredRate/MaxMaximum Amount +Dollars:Policy MaximumRental Period:Output10Start date of RentalStart DateTicketInsured NameOutput30Insured's NameFirst Name + LastNameForOutput30Insured's nameFirst Name + LastNameOutput30Rental Location'sCity + State + ZipMailing City, StateCodeand Zip CodeOutput30Rental Location'sAddress Line +Mailing Street StressAddress Line2Output15Rental Location'sTelephone NumberPhone NumberOutput30Rental Location'sCitymailing City, State,and ZipOutput30Rental Location'sStateMailing City, State,and ZipOutput30Rental Location'sZip Codemailing City, State,and ZipOutput30Rental Location'sAddress Line +Mailing StreetAddress Line2AddressOutput15Rental Location'sTelephone NumberThis field is repeatedPhone Numberfor each invoice inthe payment list.RenterOutput30Renter's NameFirst Name + LastName(Output5Number ofCALCULATEDAuthorized Days(Output5Number ofCALCULATEDauthorized days(Output5Number of RentalCALCULATEDDaysTotal DueOutput15,2Total Amount DueCALCULATEDTotal Charges −from Ins. CompanyAmount ReceivedNumber ofOutput15,2Total AuthorizedCALCULATEDNumber ofAuthorizedAmount before taxAuthorized Days *Dates + “@” +and surchargeAuthorized DailyauthorizedRateDaily Rate +“/day=”TotalOutput15,2Total authorizedCALCULATED(Number ofauthorizedamount with Tax andauthorized Days *includes Tax &surchargeAuthorized DailySurchargeRate) + CalculatedTax and surchargeNumber ofOutput15,2Total Ticket RentalCALCULATEDNumber of RentalRental Days +Amount before taxDays * ECARS“@” + ECAR'sand surchargeTicket Daily Rate.Ticket DailyRate + “/day=”Claim Type:Output10Claim Typeclaim typedescriptionClaims Office:Output3Office Idexternal organizationThe claims office idabbreviated namewhich the user iscurrently processwork for.VehicleOutput20Loss Typeloss type descriptionConditionRentalOutput30Rental Location'saccounting nameAccounting NameSend PaymentOutput30Rental Location'saccounting nameTo:Accounting NameCheck NumberInput20Check Numbercheck numberfor yourpayment2.1.3 Screen Function DefinitionThis 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 PAGEWhen clicked, the user will be taken to the “Printer Friendly View” of the current invoice.2.1.3.2 REJECTWhen clicked, the user will be taken to the Reject Invoice process.2.1.3.3 PAY NOWWhen 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 PAYMENT LISTWhen 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).2.1.3.6 Top of PageWhen clicked, the user will be taken to the top of the current invoice page.2.1.3.7 Transfer FileWhen 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 InformationPolicy Information will only be shown under the Authorized Section if the claim type is NOT claimant.
2.2 Invoicing—ApprovalThis 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.2.2.1 Screen Layout—invoicing Approval.shtml—seeFIG. 1332.2.2 Invoice Approval

Screen LabelTypeSizeScreen Field NameData FieldScreen Specific RuleOutput152Line item ChargeItem AmountLine Item Charge Qty *AmountLine Item ChargeAmount.This line may repeatmultiple timesdepending on thenumber of taxes andsurcharges thatapply.Output15Line Item ChargeItem DescriptionThis line may repeatDescriptionmultiple timesdepending on thenumber of taxes andsurcharges thatapply.Claim No:Output15Claim NumberInsurance ClaimNumberClaim Number15Claim NumberInsurance ClaimWill be pre-filled withNumber claim numbercurrently onauthorization.ToOutput10Close Date of billingBill to End Dateof Rental TicketInvoice Date:Output10Invoice Date (ECARsRecord Add DateTicket Date)ReferenceOutput20Invoice IdInvoice NumberRental Group Id +Rental Branch Id +ECARS TicketNumberFederal ID:Output30Location's Federal Id.Federal ID NumberBilled PeriodOutput10Start date of billing ofBill to Start DateRental TicketAmountOutput15,2Amount of RentalTotal AmountReceived:received.ReceivedTotal DueOutput15,2Total amount dueTotal Amount Duefrom Ins. CompanyTotal Charges:Output15,2Total Rental TicketTotal Ticket ChargesChargesHandling For:Output30Handling forFirst Name + LastAdjuster's First name +Adjuster's NameNameAdjuster's lastname. The name ofthe adjuster to whichthe invoice iscurrently assigned.Output50MessagesNOTEThis field will repeatmultiple lines for alldiary notes(messages) for areservationToOutput10AuthorizationEnd DateTermination DateDirect BillOutput15,0Authorized BillBill To %Percent:percentageDirect BillOutput15,0Authorized BillBill To %PercentpercentageAuthorizedOutput10Authorized Start DateStart DatePeriod:ToOutput10Close Date of RentalEnd DateTicketPolicy: DailyOutput15,2Policy DailyDollars Per DayRate/MaxMaximum Amount +CoveredDollarsPolicy MaximumPolicy: DailyOutput15,2Policy DailyMax $ CoveredRate/MaxMaximum Amount +DollarsPolicy MaximumRental Period:Output10Start date of RentalStart DateTicketInsured Name:Output30Insured's nameFirst Name + LastNameFor:Output30Insured's NameFirst Name + LastRenter's Last Name +NameRenter's FirstNameOutput30Rental Location'sCity + State + ZipMailing City + MailingMailing City, StateCodeState + Mailing Zipand Zip CodeOutput30Rental Location'sAddress Line +Mailing StreetAddress Line2AddressOutput15Rental Location'sTelephone NumberPhone NumberDate of loss:Output20Date of lossDate Of LossRenterOutput30Renter's nameFirst Name + LastRenter's Last Name +NameRenter's FirstName(Output5Number ofCALCULATEDTotal number ofAuthorized Daysauthorized rentaldays(Output5Number of BilledCALCULATEDDays(Output5Number of RentalCALCULATEDTotal number ofDaysauthorized RentalDaysTotal Due:Output15,2Total Amount DueCALCULATEDTotal Charges −from Ins. CompanyAmount ReceivedNumber ofOutput15,2Total authorizedCALCULATEDNumber ofAuthorizedamount before taxAuthorized Days *Days + “@” +and surchargeAuthorized DailyAuthorizedRateDaily Rate +“/day=”TotalOutput15,2Total AuthorizedCALCULATED(Number ofauthorizedAmount with tax andauthorized Days *includes Tax &surchargeAuthorized DailySurchargeRate) + (CalculatedTax and surcharge)Number ofOutput15,2Total Ticket RentalCALCULATEDNumber of RentalRental Days +Amount before taxDays * ECARS“@” + ECAR'sand surchargeTicket Daily RateTicket DailyRate + “/day=”Claim Type:Output10Claim Typeclaim typeClaimant, Insured,descriptionetc.Claims Office:Output3Office Idexternal organizationThe claims office idabbreviated namewhich the user iscurrently processwork for.RentalOutput30Rental Location'saccounting nameAccounting Name2.2.3 Screen Function DefinitionThis 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 PAGEWhen clicked, the user will be taken to the “Printer Friendly View” of the current invoice.2.2.3.2 REJECTWhen clicked, the user will be taken to the Reject Invoice process.2.2.3.3 APPROVE FOR PAYMENTWhen clicked, the currently displayed invoice status will be marked as approved and the user will be taken to the next Action Items.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.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 current invoice will remain unchanged (un-approved).2.2.3.5 Top of PageWhen clicked, the user will be taken to the top of the current invoice page.2.2.3.6 Transfer FileWhen 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 InformationPolicy Information will only be shown under the Authorized Section if the claim type is NOT claimant.
2.3 Individual Payment ListThis 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—invoicingPymtList.shtml—seeFIG. 1342.3.2 Individual Payment List

This section includes a definition of all data fields included in the functional specification.

4.1.1 accounting nameEntityOFFDRB OFFICE DIRECTORYBRANCH MASTERColumn Nameacctg_namLabel NameAccounting NameSystem NameData TypeVARCHAR(8)Attribute Definition4.1.2 action item assigned dateEntityACTION ITEMColumn Nameactn_item_assn_dteLabel Nameaction item assigned date:System NameAITMASGNDTData TypeDATEAttribute DefinitionThe action item assigned date is the datethe action item was established and assignedto an administrator or adjustor.4.1.3 action item complete dateEntityACTION ITEMColumn Nameactn_item_cmpl_dteLabel Nameaction item complete date:System NameAITMCMPLDTData TypeDATEAttribute DefinitionThe action item complete date is the datethe action item was completed by anadministrator or adjustor.4.1.4 action item effective dateEntityACTION ITEMColumn Nameactn_item_eff_dteLabel Nameaction item effective date:System NameAITMEFFDTData TypeDATEAttribute DefinitionThe action item effective date is the datethe action item will become effective.4.1.5 action item status codeEntityACTION ITEMColumn Nameactn_item_stat_cdeLabel Nameaction item status code:System NameData TypeCHAR(6)Attribute DefinitionThe action item status code defines thestatus of this action item. For example:4.1.6 action item type codeEntityACTION ITEMColumn Nameactn_item_typ_cdeLabel Nameaction item type code:System NameData TypeDEC(3,0)Attribute DefinitionThe action item type code defines specifictasks/action items associated with theRental Authorization/Reservation activitiesaccomplished by adjustors and administratorswhen contracting an insured with a replace-ment vehicle. For example: Closing an Of4.1.7 action item type descriptionEntityACTION ITEM TYPEColumn Nameactn_item_typ_dscLabel Nameaction item type description:System NameData TypeCHAR(40)Attribute DefinitionThe action item type description is a lexicaldefinition of an action item type code whichdefines specific tasks/action items associatedwith the Rental Authorization/Reservationactivities accomplished by adjustors andadministrators when contracting an4.1.8 action related adjustor codeEntityACTION ITEMColumn Nameactn_rel_adjr_cdeLabel NameAdjustor CodeSystem NameARADJRCDEData TypeCHAR(10)Attribute DefinitionThe action related adjustor code is theadjustor code of the adjustor/user whichrequires completion of some action itemwork activity such as an office closingand adjustors/users who need to be movedto another office.4.1.9 action related company identifierEntityACTION ITEMColumn Nameactn_rel_cmpy_idLabel NameARMS Profile IDSystem NameARCMPYIDData TypeCHAR(5)Attribute DefinitionThe action related company identifier isthe company identifier of the adjustor/userwhich requires completion of some actionitem work activity such as an office closingand adjustors/users who need to be movedto another office.4.1.10 Address LineEntityARM: Rental Location MasterColumn NameLOADL1Label NameSystem NameData TypeCHAR(30)Attribute Definition4.1.11 Address Line2EntityARM: Rental Location MasterColumn NameLOADL2Label NameAddress LineSystem NameData TypeCHAR(30)Attribute Definition4.1.12 Adjustor CodeEntityARM: Adjustor MasterColumn NameALAACDLabel NameAdjustor CodeSystem NameData TypeCHAR(10)Attribute Definition4.1.13 ARMS Profile IDEntityACTION ITEMColumn NameALCUIDLabel NameARMS Profile IDSystem NameData TypeCHAR(5)Attribute DefinitionThe ARMS Profile ID is the companyidentifier used to uniquely define anauthorization.4.1.14 ARMS Profile IDEntityARM: Adjustor MasterColumn NameALCUIDLabel NameARMS Profile IDSystem NameData TypeCHAR(5)Attribute Definition4.1.15 assigned to adjustor codeEntityACTION ITEMColumn Nameassgn_to_adjr_cdeLabel NameAdjustor CodeSystem NameAADJRCDEData TypeCHAR(10)Attribute DefinitionThe assigned to adjustor code is theadjustor code of the administrator oradjustor's who is assigned the action item.4.1.16 assigned to company identifierEntityACTION ITEMColumn Nameassgn_to_cmpy_idLabel NameARMS Profile IDSystem NameACMPYIDData TypeCHAR(5)Attribute DefinitionThe assigned to company identifier is thecompany identifier of the administratoror adjustor's who is assigned the action item.4.1.17 Bill To %EntityARM: Authorization(Claim Info)Column NameAZBTPCLabel NameBill To %System NameData TypeDECIMAL(3)Attribute Definition4.1.18 Bill to End DateEntityA4 Invoice HeaderColumn NameIIBTDTLabel NameBill to End DateSystem NameData TypeNUMERIC(8)Attribute Definition4.1.19 Bill to Start DateEntityA4 Invoice HeaderColumn NameIISRDTLabel NameBill to Start DateSystem NameData TypeNUMERIC(8)Attribute Definition4.1.20 check numberEntityRENTAL INVOICE PAYMENTColumn Namechk_nbrLabel Namecheck number:System NameCHKNBRData TypeDEC(11,0)Attribute Definition4.1.21 CityEntityARM: Rental Location MasterColumn NameLOCYNMLabel NameCitySystem NameData TypeCHAR(20)Attribute Definition4.1.22 claim type descriptionEntityCLAIM TYPEColumn Nameclm_typ_dscLabel Nameclaim type description:System NameCLMTYPDSCData TypeCHAR(40)Attribute DefinitionThe claim type description is a lexicaldefinition of the claim type code whichdefines the different Authorization claimtypes. For example: Insured, Claimant,Uninsured Motorist, etc.4.1.23 company identifierEntityEXTERNAL ORGANIZATIONColumn Namecmpy_idLabel Namecompany identifier:System NameCMPYIDData TypeDEC(11,0)Attribute DefinitionBusiness Party Identifier is a surrogatekey assigned to each unique occurrenceof an Individual, External Organization,and Internal Organization (Business Party).4.1.24 company structure level codeEntityACTION ITEMColumn Namecmpy_strct_lvl_cdeLabel Namecompany structure level code:System NameCMPYSLVLCDData TypeDEC(3,0)Attribute DefinitionThe external organization structure levelcode identifies the kind or type of internalorganizations of the external organizationswhich Enterprise Rent-A-Car does businesswith. Such as: Corporation, Branch ClaimsOffice, Region, Area, Subregion, etc.4.1.25 Customer Transaction IDEntityACTION ITEMColumn NameAZCUTILabel NameCustomer Transaction IDSystem NameData TypeCHAR(20)Attribute DefinitionThe Customer Transaction ID is theauthorization transaction identifierwhich along with a company identifieruniquely define an authorization.4.1.26 Date Of LossEntityARM: Renter DetailColumn NameRKLSDTLabel NameDate of LossSystem NameData TypeNUMERIC(8)Attribute Definition4.1.27 Dollars Per Day CoveredEntityARM: Authorization(Claim Info)Column NameAZ$PDYLabel NameDollars Per Day CoveredSystem NameData TypeDECIMAL(5,2)Attribute Definition4.1.28 End DateEntityARM: Authorization(Claim Info)Column NameAZENDTLabel NameEnd DateSystem NameData TypeNUMERIC(8)Attribute Definition4.1.29 external organization abbreviated nameEntityEXTERNAL ORGANIZATIONColumn Namee_o_abbr_namLabel Nameexternal organization abbreviated name:System NameEOABBRNAMData TypeCHAR(10)Attribute DefinitionExternal Organization AbbreviatedName is a shortened text based labelassociated with an organization outsideof Enterprise. This name is sometimesused for accounting purposes.4.1.30 external organization identifierEntityALTERNATE ORGANIZATIONColumn Namee_o_idLabel Nameexternal organization identifier:System NameEOIDData TypeDEC(11,0)Attribute DefinitionBusiness Party Identifier is a surrogatekey assigned to each unique occurrenceof an Individual, External Organization,and Internal Organization (Business Party).4.1.31 Federal ID NumberEntityA4 Invoice HeaderColumn NameIIFETXLabel NameFederal ID NumberSystem NameData TypeCHAR(15)Attribute Definition4.1.32 First NameEntityARM: Adjustor MasterColumn NameALFSNMLabel NameFirst NameSystem NameData TypeCHAR(15)Attribute Definition4.1.33 First NameEntityARM: Insured DetailColumn NameIRFSNMLabel NameFirst NameSystem NameData TypeCHAR(15)Attribute Definition4.1.34 First NameEntityARM: Renter DetailColumn NameRKFSNMLabel NameFirst NameSystem NameData TypeCHAR(15)Attribute Definition4.1.35 handled by adjustor codeEntityACTION ITEMColumn Namehandl_by_adjr_cdeLabel NameAdjustor CodeSystem NameHNDADJRCDEData TypeCHAR(10)Attribute DefinitionThe handled by adjustor code is the adjustorcode of the administrator or adjustor's whois handling the action item.4.1.36 handled by company identifierEntityACTION ITEMColumn Namehandl_by_cmpy_idLabel NameARMS Profile IDSystem NameHNDCMPYIDData TypeCHAR(5)Attribute DefinitionThe handled by company identifier is thecompany identifier of the administrator oradjustor's who is handling the action item.4.1.37 handling for adjustor codeEntityAUTHORIZATION ACTIVITY LOGColumn Namehandl_for_adtr_cdeLabel Namehandling for adjustor code:System NameHNDADJRCDEData TypeCHAR(10)Attribute DefinitionThe handling for adjustor coder is theadjustor code of an adjustor/user whois handling authorization activities foranother adjustor/user in the ARMS Webapplication.4.1.38 handling for company identifierEntityAUTHORIZATION ACTIVITY LOGColumn Namehandl_for_cmpy_idLabel Namehandling for company identifier:System NameHNDCMPYIDData TypeCHAR(5)Attribute DefinitionThe handling for company identifier isthe company identifier used to uniquelyidentify an adjustor/user who is handlingauthorization activities for anotheradjustor/user in the ARMS Webapplication.4.1.39 Insurance Claim NumberEntityA4 Invoice HeaderColumn NameIICLNOLabel NameInsurance Claim NumberSystem NameData TypeCHAR(20)Attribute Definition4.1.40 Insurance Claim NumberEntityARM: Authorization(Claim Info)Column NameAZCLNOLabel NameInsurance Claim NumberSystem NameData TypeCHAR(20)Attribute Definition4.1.41 Invoice NumberEntityA4 Invoice HeaderColumn NameIIINNOLabel NameInvoice NumberSystem NameData TypeCHAR(20)Attribute Definition4.1.42 Item AmountEntityA4 Invoice DetailColumn NameI2IT$$Label NameItem AmountSystem NameData TypeDECIMAL(7,2)Attribute Definition4.1.43 Item DescriptionEntityA4 Invoice DetailColumn NameI2ITDSLabel NameItem DescriptionSystem NameData TypeCHAR(30)Attribute Definition4.1.44 Item QuantityEntityA4 Invoice DetailColumn NameI2ITQYLabel NameItem QuantitySystem NameData TypeDECIMAL(5)Attribute Definition4.1.45 Item RateEntityA4 Invoice DetailColumn NameI2ITRTLabel NameItem RateSystem NameData TypeDECIMAL(7,2)Attribute Definition4.1.46 Last NameEntityARM: Adjustor MasterColumn NameALLSNMLabel NameLast NameSystem NameData TypeCHAR(20)Attribute Definition4.1.47 Last NameEntityARM: Insured DetailColumn NameIRLSNMLabel NameLast NameSystem NameData TypeCHAR(20)Attribute Definition4.1.48 Last NameEntityARM: Renter DetailColumn NameRKLSNMLabel NameLast NameSystem NameData TypeCHAR(20)Attribute Definition4.1.49 loss type descriptionEntityLOSS TYPEColumn Nameloss_typ_dscLabel Nameloss type description:System NameLOSSTYPDSCData TypeCHAR(40)Attribute DefinitionThe loss type description is a lexicaldefinition of the loss type code whichdefines the different loss categorieswhen an Insurance Company authorizesa Rental. For example: Theft, Drivable,Repairable, Non-drivable, Non-repairable,Totaled.4.1.50 Max $ CoveredEntityARM: Authorization(Claim Info)Column NameAZ$MAXLabel NameMax $ CoveredSystem NameData TypeDECIMAL(9,2)Attribute Definition4.1.51 NOTEEntityARM: ARMS/400 Diary Notes FileColumn NameNENOTELabel NameNOTESystem NameData TypeCHAR(50)Attribute Definition4.1.52 Number Of Days AuthorizedEntityARM: Authorization(Claim Info)Column NameAZAUDYLabel NameNumber Of Days AuthorizedSystem NameData TypeDECIMAL(3)Attribute Definition4.1.53 Record Add DateEntityA4 Invoice HeaderColumn NameIIADDTLabel NameRecord Add DateSystem NameData TypeNUMERIC(8)Attribute Definition4.1.54 related office identifierEntityACTION ITEMColumn Namerel ofc idLabel Namerelated office identifier:System NameRELOFCIDData TypeDEC(11,0)Attribute DefinitionThe related office identifier is the identifierof the office responsible for the action item.4.1.55 Remittance Reference #EntityA4 Remit Reference No.Column NameQ5RMNOLabel NameRemittance Reference #System NameData TypeNUMERIC(6)Attribute Definition4.1.56 Request TypeEntityACTION ITEM TYPEColumn NameXURSTPLabel NameRequest TypeSystem NameXURSTPData TypeCHAR(1)Attribute DefinitionThe request type is a code from the ARMSsystem which identifies whether adjustor actionis necessary for an authorization and what typeof action.4.1.57 Start DateEntityARM: Authorization(Claim Info)Column NameAZSTDTLabel NameStart DateSystem NameData TypeNUMERIC(8)Attribute Definition4.1.58 StateEntityARM: Rental Location MasterColumn NameLOSACDLabel NameStateSystem NameData TypeCHAR(2)Attribute Definition4.1.59 Status CodeEntityACTION ITEM TYPEColumn NameXUSTCDLabel NameStatus CodeSystem NameXUSTCDData TypeCHAR(1)Attribute DefinitionThe status code is a code from the ARMSsystem which identifies whether anauthorization is a reservation, a ticket,unauthorized, invoiced, paid, etc.4.1.60 Telephone NumberEntityARM: Rental Location MasterColumn NameLOPHNOLabel NameTelephone NumberSystem NameData TypeNUMERIC(10)Attribute Definition4.1.61 Total Amount DueEntityA4 Invoice TrailerColumn Name13BL$$Label NameTotal Amount DueSystem NameData TypeDECIMAL(9,2)Attribute Definition4.1.62 Total Amount ReceivedEntityA4 Invoice TrailerColumn Name13RC$$Label NameTotal Amount ReceivedSystem NameData TypeDECIMAL(9,2)Attribute Definition4.1.63 Total Billed to OthersEntityA4 Invoice TrailerColumn Name130T$$Label NameTotal Billed to OthersSystem NameData TypeDECIMAL(9,2)Attribute Definition4.1.64 Total Ticket ChargesEntityA4 Invoice TrailerColumn Name13TO$$Label NameTotal Ticket ChargesSystem NameData TypeDECIMAL(9,2)Attribute Definition4.1.65 Vehicle RateEntityARM: Authorization(Claim Info)Column NameAZVHRTLabel NameVehicle RateSystem NameData TypeDECIMAL(5,2)Attribute Definition4.1.66 Zip CodeEntityARM: Rental Location MasterColumn NameLOZPCDLabel NameZip CodeSystem NameData TypeCHAR(9)Attribute Definition
5. Questions and AnswersIssue Number: 256Question: 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=0Policy Daily>0Vehicle Rate>0Vehicle Rate<Policy Dailyor all the following conditions are true:Policy Maximum>0Policy Daily=0Vehicle Rate>0In all other cases, the amount is multiplied by the bill to percent to get the authorized limit. Is this calculation correct?Status: PendingResolution: 3-14-00, DSE—Need to follow up with author to get a further understanding of question.3-23-00, Issue Mtg., Will get addressed in current state and fix.Issue Number: 257Question: 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—ResolvedResolution: 3-14-00, DSE—Need to follow up with author to get a further understanding of question.
Functional Design Specification
Pay Approved Invoices
(Processor Pay)
Version 1.0
1. Pay Approved Invoices Use Case
1.1 Brief DescriptionThe Pay Approved Invoices use case describes how the PROCESSOR would review and pay invoices in the ARMS Web system.
1.2 Use Case ActorsThe following actors will interact with this use case:PROCESSOR—The PROCESSOR will use this use case to pay approved invoices.
1.3 Pre-ConditionsThe 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 EventsThe Flow of Events will include the necessary steps for a PROCESSOR to review and pay invoices.1.4.1 Activity Diagram—seeFIG. 1361.4.2 Basic Flow1. 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 Pay1. 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.1.4.2.2 Bulk Pay1. 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 of the 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.1.4.3 Alternative Flows1.4.3.1 View Customer FileAt 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 InvoiceAt 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 ListAt 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-ConditionsIf the use case was successful the accepted invoices should be marked as paid in the ARMS Web system.If the use case was unsuccessful, the system state is unchanged.
1.6 Special RequirementsThe 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 ARMS Web Routes InvoicesBefore 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 IntegrationIt 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 Invoice1.6.3 Claim Number is Editable on the InvoiceIf 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 Points1.7.1 MA-19-View Customer FileThe View Customer File Functional Specification is used to review the rental history in regards to a specific rental. Upon completion of the 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.
2. Screen DesignA 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 ListThis screen will allow the user to enter a check number for each invoice and notify Enterprise that they have processed the payment.2.1.1 Individual Payment List—seeFIG. 137

Screen LabelTypeSizeScreen Field NameData FieldScreen Specific RuleClaim NumberInput15Claim NumberInsuranceWill be pre-filled withClaim Numberclaim number currentlyon authorization. Thisfield is repeated foreach invoice in thepayment list.This field is repeatedfor each invoice in thepayment list.Invoice DateOutput10Invoice DateRecord Add DateThis field is repeated(ECARS Ticketfor each invoice in theDate)payment list.Please includeOutput20Invoice IDInvoice NumberRental Group ID +this referenceRental Branch ID +number onECARS Ticket number.your check:This field is repeatedfor each invoice in thepayment list.Invoice:Output20Invoice IdInvoice NumberRental Group Id +Rental Branch Id +ECARS TicketNumberThis field is repeatedfor each invoice in thepayment list.Federal IDOutput30Location'sFederal ID NumberThis field is repeatedFederal IDfor each invoice in thepayment list.TotalOutput15,2Total amountTotal Amount DueTotal Charges −Amount:due from Ins.Amount ReceivedCompanyThis field is repeatedfor each invoice in thepayment list.Handling For:Output30Handling forFirst Name +Adjuster's FirstAdjuster's NameLast Namename + Adjuster'slast name.The name of the adjusterto which the invoice iscurrently assigned.Output30Insured's NameFirst Name +This field is repeatedLast Namefor each invoice in thepayment list.Output30Rental Location'sAddress Line +This field is repeatedMailing StreetAddress Line2for each invoice in theAddresspayment list.Output12Rental LocationTelephone NumberThis field is repeatedTelephone Numberfor each invoice inthe payment list.Output30Rental Location'sCity + State +This field is repeatedMailing City,Zip Codefor each invoice inState and Zipthe payment list.CodeOutput30Rental Location'sCity + State +This field is repeatedMailing CityZip Codefor each invoice inState and Zipthe payment list.Output30Rental Location'sAddress Line +This field is repeatedMailing StreetAddress Line2for each invoice inAddressthe payment list.Date of lossOutput10Date of lossDate Of LossThis field is repeatedfor each invoice inthe payment list.InvoiceOutput5Invoice ListCALCULATEDThis field is repeatedNumberfor each invoice inthe payment list.CountClaim typeOutput10Claim Typeclaim typeThis field is repeateddescriptionfor each invoice inthe payment list.Claims Office:Output3Office IdexternalThis claims office idorganizationwhich the user isabbreviated namecurrently processwork for.VehicleOutput10Loss Typeloss type descriptionThis field is repeatedConditionfor each invoice inthe payment list.Remit to:Output30Rental Location'saccounting nameThis field is repeatedAccounting Namefor each invoice inthe payment list.SendOutput30Rental Location'saccounting nameThis field is repeatedPayment to:Accounting Namefor each invoice inthe payment list.Rental:Output30Rental Location'saccounting nameThis field is repeatedAccounting Namefor each invoice inthe payment list.Enter the checkInput20Check Numbercheck numberThis field is repeatednumber offor each invoice inyour paymentthe payment list.here:2.1.3 Screen Function DefinitionThis 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 PAGEWhen clicked, the user will be taken to the “Printer Friendly View” of the current invoice.2.1.3.2 CONFIRM PAYMENTWhen 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 PAY LATERWhen clicked, the user will be returned to their action item list and the payment list will remain unprocessed.2.1.3.4 RETURN TO ADJUSTERWhen 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.1.3.5 Top of PageWhen clicked, the user will be taken to the top of the current invoice page.
2.2 Bulk Payment ListThis screen will allow the user to pick which functions that he/she may want to change.2.2.1 Screen Layout—Bulk Payment List—seeFIG. 1382.2.2 Invoicing—Bulk Payment List

Entity 4.1.1 accounting nameEntityOFFDRB OFFICE DIRECTORY BRANCHMASTERColumn Nameacctg_namLabel NameAccounting NameSystem NameData TypeVARCHAR(8)Attribute Definition4.1.2 action item complete dateEntityACTION ITEMColumn Nameactn_item_cmpl_dteLabel Nameaction item complete date:System NameAITMCMPLDTData TypeDATEAttribute DefinitionThe action item complete date is the datethe action item was completed by anadministrator or adjustor.4.1.3 action item effective dateEntityACTION ITEMColumn Nameactn_item_eff_dteLabel Nameaction item effective date:System NameAITMEFFDTData TypeDATEAttribute DefinitionThe action item effective date is the datethe action item will become effective.4.1.4 action item status codeEntityACTION ITEMColumn Nameactn_item_stat_cdeLabel Nameaction item status code:System NameData TypeCHAR(6)Attribute DefinitionThe action item status code defines thestatus of this action item. For example:4.1.5 action item type codeEntityACTION ITEMColumn Nameactn_item_typ_cdeLabel Nameaction item type code:System NameData TypeDEC(3,0)Attribute DefinitionThe action item type code defines specifictasks/action items associated with the RentalAuthorization/Reservation activitiesaccomplished by adjustors and administratorswhen contracting an insured with a replacementvehicle. For example: Closing an Of4.1.6 action item type descriptionEntityACTION ITEM TYPEColumn Nameactn_item_typ_dscLabel Nameaction item type description:System NameData TypeCHAR(40)Attribute DefinitionThe action item type description is a lexicaldefinition of an action item type code whichdefines specific tasks/action items associatedwith the Rental Authorization/Reservationactivities accomplished by adjustorsand administrators when contracting an4.1.7 Address LineEntityARM: Rental Location MasterColumn NameLOADL1Label NameSystem NameData TypeCHAR(30)Attribute Definition4.1.8 Address Line2EntityARM: Rental Location MasterColumn NameLOADL2Label NameAddress LineSystem NameData TypeCHAR(30)Attribute Definition4.1.9 ARMS Profile IDEntityACTION ITEMColumn NameALCUIDLabel NameARMS Profile IDSystem NameData TypeCHAR(5)Attribute DefinitionThe ARMS Profile ID is the companyidentifier used to uniquely define anauthorization.4.1.10 assigned to adjustor codeEntityACTION ITEMColumn Nameassgn_to_adjr_cdeLabel NameAdjustor CodeSystem NameAADJRCDEData TypeCHAR(10)Attribute DefinitionThe assigned to adjustor code is theadjustor code of the administratoror adjustor's who is assigned the action item.4.1.11 assigned to company identifierEntityACTION ITEMColumn Nameassgn_to_cmpy_idLabel NameARMS Profile IDSystem NameACMPYIDData TypeCHAR(5)Attribute DefinitionThe assigned to company identifier is thecompany identifier of the administrator oradjustor's who is assigned the action item.4.1.12 Bill To %EntityARM: Authorization(Claim Info)Column NameAZBTPCLabel NameBill To %System NameData TypeDECIMAL(3)Attribute Definition4.1.13 BranchEntityA4 Cross ReferenceColumn Namebr_idLabel NameBranch:System NameData TypeCHAR(2)Attribute Definition4.1.14 check numberEntityRENTAL INVOICE PAYMENTColumn Namechk_nbrLabel Namecheck number:System NameCHKNBRData TypeDEC(11,0)Attribute Definition4.1.15 CityEntityARM: Rental Location MasterColumn NameLOCYNMLabel NameCitySystem NameData TypeCHAR(20)Attribute Definition4.1.16 claim type descriptionEntityCLAIM TYPEColumn Nameclm_typ_dscLabel Nameclaim type description:System NameCLMTYPDSCData TypeCHAR(40)Attribute DefinitionThe claim type description is a lexicaldefinition of the claim type code whichdefines the different Authorization claimtypes. For example: Insured, Claimant,Uninsured Motorist, etc.4.1.17 company identifierEntityEXTERNAL ORGANIZATIONColumn Namecmpy_idLabel Namecompany identifier:System NameCMPYIDData TypeDEC(11,0)Attribute DefinitionBusiness Party Identifier is a surrogatekey assigned to each unique occurrenceof an Individual, External Organization,and Internal Organization (Business Party).4.1.18 company structure level codeEntityACTION ITEMColumn Namecm py_strct_lvl_cdeLabel Namecompany structure level code:System NameCMPYSLVLCDData TypeDEC(3,0)Attribute DefinitionThe external organization structure levelcode identifies the kind or type of internalorganizations of the external organizationswhich Enterprise Rent-A-Car does businesswith. Such as: Corporation, Branch ClaimsOffice, Region, Area, Subregion, etc.4.1.19 Customer Transaction IDEntityACTION ITEMColumn NameAZCUTILabel NameCustomer Transaction IDSystem NameData TypeCHAR(20)Attribute DefinitionThe Customer Transaction ID is theauthorization transaction identifierwhich along with a company identifieruniquely define an authorization.4.1.20 Date Of LossEntityARM: Renter DetailColumn NameRKLSDTLabel NameDate of LossSystem NameData TypeNUMERIC(8)Attribute Definition4.1.21 Dollars Per Day CoveredEntityARM: Authorization(Claim Info)Column NameAZ$PDYLabel NameDollars Per Day CoveredSystem NameData TypeDECIMAL(5,2)Attribute Definition4.1.22 End DateEntityARM: Authorization(Claim Info)Column NameAZENDTLabel NameEnd DateSystem NameData TypeNUMERIC(8)Attribute Definition4.1.23 external organization abbreviated nameEntityEXTERNAL ORGANIZATIONColumn Namee_o_abbr_namLabel Nameexternal organization abbreviated name:System NameEOABBRNAMData TypeCHAR(10)Attribute DefinitionExternal Organization AbbreviatedName is a shortened text based labelassociated with an organization outsideof Enterprise. This name is sometimesused for accounting purposes.4.1.24 external organization identifierEntityEXTERNAL ORGANIZATIONColumn Namee_o_idLabel Nameexternal organization identifier:System NameEOIDData TypeDEC(11,0)Attribute DefinitionThe external organization identifier is asurrogate key assigned to each uniqueoccurrence of an External Organization.Examples: body shops, vehiclemanufacturers, insurance companies,leasing accounts, credit unions, dealerships,or governing agencies.4.1.25 Federal ID NumberEntityA4 Invoice HeaderColumn NameI1FETXLabel NameFederal ID NumberSystem NameData TypeCHAR(15)Attribute Definition4.1.26 First NameEntityARM: Adjustor MasterColumn NameALFSNMLabel NameFirst NameSystem NameData TypeCHAR(15)Attribute Definition4.1.27 First NameEntityARM: Renter DetailColumn NameRKFSNMLabel NameFirst NameSystem NameData TypeCHAR(15)Attribute Definition4.1.28 GroupEntityA4 Cross ReferenceColumn Namegrp_idLabel NameGroup NumberSystem NameData TypeCHAR(2)Attribute Definition4.1.29 handled by adjustor codeEntityACTION ITEMColumn Namehandl_by_adjr_cdeLabel NameAdjustor CodeSystem NameHNDADJRCDEData TypeCHAR(10)Attribute DefinitionThe handled by adjustor code is theadjustor code of the administrator oradjustor's who is handling the action item.4.1.30 handled by company identifierEntityACTION ITEMColumn Namehandl_by_cmpy_idLabel NameARMS Profile IDSystem NameHNDCMPYIDData TypeCHAR(5)Attribute DefinitionThe handled by company identifier is thecompany identifier of the administrator oradjustor's who is handling the action item.4.1.31 handling for adjustor codeEntityAUTHORIZATION ACTIVITY LOGColumn Namehandl_for_adtr_cdeLabel Namehandling for adjustor code:System NameHNDADJRCDEData TypeCHAR(10)Attribute DefinitionThe handling for adjustor coder is theadjustor code of an adjustor/user who ishandling authorization activities for anotheradjustor/user in the ARMS Web application.4.1.32 handling for company identifierEntityAUTHORIZATION ACTIVITY LOGColumn Namehandl_for_cmpy_idLabel Namehandling for company identifier:System NameHNDCMPYIDData TypeCHAR(5)Attribute DefinitionThe handling for company identifier is thecompany identifier used to uniquely identifyan adjustor/user who is handling authorizationactivities for another adjustor/user in theARMS Web application.4.1.33 Insurance Claim NumberEntityA4 Invoice HeaderColumn NameI1CLNOLabel NameInsurance Claim NumberSystem NameData TypeCHAR(20)Attribute Definition4.1.34 Insurance Claim NumberEntityARM: Authorization(Claim Info)Column NameAZCLNOLabel NameInsurance Claim NumberSystem NameData TypeCHAR(20)Attribute Definition4.1.35 Invoice NumberEntityA4 Invoice HeaderColumn NameI1INNOLabel NameInvoice NumberSystem NameData TypeCHAR(20)Attribute Definition4.1.36 Item AmountEntityA4 Invoice DetailColumn NameI2IT$$Label NameItem AmountSystem NameData TypeDECIMAL(7,2)Attribute Definition4.1.37 Item DescriptionEntityA4 Invoice DetailColumn NameI2ITDSLabel NameItem DescriptionSystem NameData TypeCHAR(30)Attribute Definition4.1.38 Item QuantityEntityA4 Invoice DetailColumn NameI2ITQYLabel NameItem QuantitySystem NameData TypeDECIMAL(5)Attribute Definition4.1.39 Item RateEntityA4 Invoice DetailColumn NameI2ITRTLabel NameItem RateSystem NameData TypeDECIMAL(7,2)Attribute Definition4.1.40 Last NameEntityARM: Adjustor MasterColumn NameALLSNMLabel NameLast NameSystem NameData TypeCHAR(20)Attribute Definition4.1.41 Last NameEntityARM: Renter DetailColumn NameRKLSNMLabel NameLast NameSystem NameData TypeCHAR(20)Attribute Definition4.1.42 loss type descriptionEntityLOSS TYPEColumn Nameloss_typ_dscLabel Nameloss type description:System NameLOSSTYPDSCData TypeCHAR(40)Attribute DefinitionThe loss type description is a lexicaldefinition of the loss type code whichdefines the different loss categories whenan Insurance Company authorizes a Rental.For example: Theft, Drivable, Repairable,Non-drivable, Non-repairable, Totaled.4.1.43 Max $ CoveredEntityARM: Authorization(Claim Info)Column NameAZ$MAXLabel NameMax $ CoveredSystem NameData TypeDECIMAL(9,2)Attribute Definition4.1.44 NOTEEntityARM: ARMS/400 Diary Notes FileColumn NameNENOTELabel NameNOTESystem NameData TypeCHAR(50)Attribute Definition4.1.45 Record Add DateEntityA4 Invoice HeaderColumn NameI1ADDTLabel NameRecord Add DateSystem NameData TypeNUMERIC(8)Attribute Definition4.1.46 related office identifierEntityACTION ITEMColumn Namerel_ofc_idLabel Namerelated office identifier:System NameRELOFCIDData TypeDEC(11,0)Attribute DefinitionThe related office identifier is the identifierof the office responsible for the action item.4.1.47 Request TypeEntityACTION ITEM TYPEColumn NameX4RSFGLabel NameRequest TypeSystem NameData TypeCHAR(1)Attribute Definition4.1.48 standard message descriptionEntitySTANDARD MESSAGEColumn Namestd_msg_dscLabel Namestandard message description:System NameSTDMSGDSCData TypeCHAR(50)Attribute DefinitionThe standard message description is a lexicaldefinition for standard message code whichdefines a predefined message which is applicableto specific activity type codes. For example:“Authorization confirmed on &Date withReservation Number &Resnumber”4.1.49 Start DateEntityARM: Authorization(Claim Info)Column NameAZSTDTLabel NameStart DateSystem NameData TypeNUMERIC(8)Attribute Definition4.1.50 StateEntityARM: Rental Location MasterColumn NameLOSACDLabel NameStateSystem NameData TypeCHAR(2)Attribute Definition4.1.51 Status CodeEntityACTION ITEM TYPEColumn NameXUSTCDLabel NameStatus CodeSystem NameXUSTCDData TypeCHAR(1)Attribute DefinitionThe status code is a code from theARMS system which identifies whetheran authorization is a reservation, a ticket,unauthorized, invoiced, paid, etc.4.1.52 Telephone NumberEntityARM: Rental Location MasterColumn NameLOPHNOLabel NameTelephone NumberSystem NameData TypeNUMERIC(10)Attribute Definition4.1.53 Ticket NumberEntityA4 Cross ReferenceColumn NameX4TKNOLabel NameTicket NumberSystem NameData TypeCHAR(6)Attribute Definition4.1.54 Total Amount DueEntityA4 Invoice TrailerColumn NameI3BL$$Label NameTotal Amount DueSystem NameData TypeDECIMAL(9,2)Attribute Definition4.1.55 Total Amount ReceivedEntityA4 Invoice TrailerColumn NameI3RC$$Label NameTotal Amount ReceivedSystem NameData TypeDECIMAL(9,2)Attribute Definition4.1.56 Total Billed to OthersEntityA4 Invoice TrailerColumn NameI3OT$$Label NameTotal Billed to OthersSystem NameData TypeDECIMAL(9,2)Attribute Definition4.1.57 Total Ticket ChargesEntityA4 Invoice TrailerColumn NameI3TO$$Label NameTotal Ticket ChargesSystem NameData TypeDECIMAL(9,2)Attribute Definition4.1.58 Zip CodeEntityARM: Rental Location MasterColumn NameLOZPCDLabel NameZip CodeSystem NameData TypeCHAR(9)Attribute Definition
5. Questions and AnswersNone.
Functional Design Specification
Reject an Invoice
Version 1.0
1. Reject An Invoice Use Case
1.1 Brief DescriptionThe Reject an Invoice use case describes how the ADJUSTER would reject an invoice to Enterprise in the ARMS Web system.
1.2 Use Case ActorsThe following actors will interact with this use case:ADJUSTER—The ADJUSTER will use this use case to reject an invoice.
1.3 Pre-ConditionsThe 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 EventsThe Flow of Events will include the necessary steps for an ADJUSTER to reject invoices.1.4.1 Activity Diagram—seeFIG. 1401.4.2 Basic Flow1. 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 Flows1.4.3.1 Cancel RejectionAt steps two through seven of the 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 GivenAt 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 PayIf the reject reason given in step three of the Basic Flow is a reason that requires a short pay, at step five of the Basic Flow the system will display allowed to complete the rejection process without providing an amount that will be paid.
1.5 Post-ConditionsIf 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 RequirementsThe 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 Invoices are Initially Auto ApprovedIf 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 PointsNone.
2. Screen DesignA 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 Reject Billing ReasonThis screen will allow the user to begin the rejection process.2.1.1 Screen Layout—Reject Billing Reason—seeFIG. 141

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 of the 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 ActorsAll actors will use the use case to retrieve callback lists in the ARMS Web system. All of the following actors can be defined generically as a USER:PROCESSORADJUSTERCOMPANY MANAGERFor the balance of this use case, all of the above actors will be referred to as USER.
1.3 Pre-ConditionsThe USER must be signed-on to the system.
1.4 Flow of EventsThe Flow of Events includes all the steps necessary to retrieve and manage callbacks in the ARMS Web system.1.4.1 Activity Diagram—seeFIG. 1431.4.2 Basic FlowThe Basic Flow of the Callbacks use case includes all of the 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.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 NameRepair Facility Telephone NumberNumber of Rental callbacks due to the Repair Facility4. The USER selects one or more repair facilities from the repair facility callback summary.5. The system displays a summary of the open authorizations that are set to expire for all selected repair facilities. The open authorization callback summary will consist of:Renter NameYear/Make/Model of the Renter's VehicleDriveable Flag (y/n)Number of Days BehindAuthorized DaysLast Authorized Day6. 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 of the Basic Flow on completion of the 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 FlowsThe 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 DateAt Step 3 or Step 5 of the 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 of the Basic Flow on submission of the new last authorized day.1.4.3.2 Last Authorized Date Entered InvalidIn 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 of the 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-ConditionsIf successful, a callback list is created for the USER.If unsuccessful, the system state remains unchanged.
1.6 Special RequirementsNone.
1.7 Extension Points1.7.1 MA-12 Extend AuthorizationAt Step 7 of the 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 of the repair facility callback (e.g., extend, add notes, or terminate the rental authorization). On completion of the MA-12 Extend Authorization use case, the rules specified within the Basic Flow should be followed as to the next step in the process.
2. Screen DesignA 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 Repair Facility Callback SummaryThis screen provides the USER with a repair facility callback summary, and supports Step 3 of the Basic Flow.2.1.1 Screen Layout—seeFIG. 144
Functional Design Specification
Generate Personal Report
Version 1.11

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 ActorsAll actors will use the use case to generate personal reports in the ARMS Web system. All of the following actors can be defined generically as a USER:ADJUSTERPROCESSORCOMPANY MANAGERFor the balance of this use case, all of the above actors will be referred to as USER.
1.3 Pre-ConditionsThe USER must be signed-on to the system.
1.4 Flow of EventsThe Flow of Events includes all the steps necessary to generate personal reports in the ARMS Web system.1.4.1 Activity Diagram—seeFIG. 1451.4.2 Basic FlowThe Basic Flow of the Generate Personal Report use case includes all of the 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 the 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 FlowsThe 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.1.4.3.1 Change Report ViewAt Step 3 of the Basic Flow, the USER will have the ability to change the report ‘view’. (Report views are covered in more detail in Section 1.6 Special Requirements.) 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 of the USER.If the USER selects to change the report view, the system will return to Step 2 of the Basic Flow and re-generate the report to build the requested view.1.4.3.2 Change Closed Ticket Date RangeAt Step 3 of the Basic Flow, if the current report view is a closed ticket report, the USER will have the ability to change the date range of the 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 of the date range.If the USER selects a new date range for the closed ticket report view, the system will return to Step 2 of the 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 ReportAt Step 3 of the 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 of the 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 the Basic Flow).1.4.3.4 Select Closed Ticket from Closed Ticket Detail ReportAt Step 3 of the 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 3 of the Basic Flow).1.4.3.5 Sort ReportAt Step 3 of the 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 of the 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 ViewAt Step 3 of the 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 of the use case extension, the USER will be returned to Step 2 of Basic Flow in this use case and be presented with the custom1.4.3.7 Select Download ReportAt Step 3 of the 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 of the report, the system must publish a comma-delimited file that includes all of the data within the columns of the 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 of the AdjusterDate and time the report was generatedThe system should return the USER to the report view (Step 3 of the Basic Flow) once a report has been successfully downloaded.
1.5 Post-ConditionsIf successful, a standard report is created for the USER.If unsuccessful, the system state remains unchanged.
1.6 Special RequirementsThe special requirements for this use case define all of the 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 ViewThe 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 Name2. Claim Number3. Claim Type4. 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 generatedthe date/time the open ticket report was generated1.6.2 Closed Ticket Detail ViewThe 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 Name2. Claim Number3. Claim Type4. 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.6.2.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.6.2.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.2.3 The default sort for the Closed Ticket Detail view must be by the Claim Number field.1.6.2.4 The report must include a count of the total number of contracts in the list.1.6.2.5 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 of the USER for whom the report was generatedthe date/time the open ticket report was generated1.6.3 Custom Report ViewsThe 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.6.4 Report View ManagementThe system will present all of the 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 PointsThis section describes the extension points of this use case.1.7.1 MA-13 Change AuthorizationIf 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).1.7.2 RP-03 Add/Edit Custom ViewIf 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 of the Basic Flow within this use case.
2. Screen DesignA 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 Personal Report Template ScreenThis screen provides the template to build personal report ‘views’, and supports Step 3 of the Basic Flow.2.1.1 Screen Layout—seeFIG. 1462.1.2 Screen Field Definition

ScreenLabelTypeLengthData FieldScreen Specific RuleOfficeComboBranch claimsThis combo list should include all ofBoxofficethe offices for the currently activecompany that the USER is assignedto.If the value of this field is changed,the system should automaticallyrefresh the screen with the currentreport view for the newly selectedoffice.Handling forOutputHandling forFor personal reports, this valueTextshould always be ‘Yourself’.Output<Report By>The <report by> field is a placeTextholder in the header of the reportview. For personal reports, thisplaceholder should be populated withthe name of the user that is beingreported on (i.e., the name of theuser that requested the report).Output<Time/DateThe <time/date stamp> field is aTextStamp>placeholder in the header of thereport view. For personal reports,this placeholder should be populatedwith the date and time that the reportwas generated.Output<ReportThe <report type> field is aTextType>placeholder in the header of thereport view. For personal reports,this placeholder should be populatedwith the name of the current reportview (e.g., Open Ticket Detail,Custom View 1)<ColumnOutput<DataThe data columns of the reportHeading ITextColumns Ishould correspond to the datathrough X>through X>columns defined for the selectedreport view (either static or customreport view). The data columnsshould be presented in the sequencethat they are defined.TotalOutputNumber ofThe total field should include the totalTextCustomernumber of contracts/ customer filesFilesthat are represented in the report.Select aComboReport viewThe ‘select a view’ combo boxviewBoxselectionshould include the names of allreport views that are available to theuser. This includes all pre-defined(e.g., Open Ticket Detail) and user-defined custom views.There should be an additional optionto ‘Add a custom view . . . ’. Ifselected, the system should redirectthe user to the Add/Edit CustomView screen in the RP-03 Add/EditCustom View specification.Show OnlyComboClaim TypeThe ‘show only’ combo box shouldBoxFilterinclude the following values:II Claim Types (default)nsured Claim Typeslaimant Claim Typesninsured Claim Typesheft Claim TypesWhen selected, the report shouldfilter the records to display in therequested report view according tothe selection in this combo box. Forexample, if the selection in the ‘showonly’ field were ‘Insured ClaimTypes’, the report view would onlyinclude records that have a ClaimType of ‘Insured.FromComboClosed ticketThe ‘From’ combo box shouldboxreport frominclude all months and years for thedatelast 13 months (rolling 13 monthperiod, current month inclusive). Forexample a value in this field mightinclude ‘January 2000’.The default value should be 2months prior to the current month.ToComboClosed ticketThe ‘From’ combo box shouldboxreport to dateinclude all months and years for thelast 13 months (rolling 13 monthperiod, current month inclusive). Forexample a value in this field mightinclude ‘July 2000’.The default value should be thecurrent month.2.1.3 Screen Function DefinitionThis 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 reportThe ‘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 AveragesThe ‘Go to Report Averages’ screen function provides the USER with a hyperlink to the bottom of the report to review the averages for each of the numeric columns in the report view. The ‘Go to Report Averages’ hyperlink must be at or near the header of the report.2.1.3.3 Column Heading SortThe ‘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.1.3.4 Download this reportThe ‘Download this Report’ screen function allows the USER to click on a hyperlink and download a comma-delimited copy of the current report view. The downloaded copy must include:Report Header InformationName of the Report ViewName of the PersonDate and Time that the Report Was generatedReport View Column HeadingsReport View Records2.1.3.5 View ReportThe ‘View Report’ screen function allows the USER to submit a request for a different type and/or date range of the report view. The system will refresh the screen with updated report view information when this screen function is invoked.2.1.3.6 Edit Custom ViewThe 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.SeeFIGS. 147(a)-(c).
Functional Design Specification
Generate Management Report
Version 1.11

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 ActorsAll 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. (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.)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 the above actors will be referred to as USER.
1.3 Pre-ConditionsThe USER must be signed-on to the system.The USER must have the authority to access management reports.
1.4 Flow of EventsThe Flow of Events includes all the steps necessary to generate management reports in the ARMS Web system.1.4.1 Activity Diagram—seeFIG. 1481.4.2 Basic FlowThe Basic Flow of the Generate Management Report use case includes all of the 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 FlowsThe 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 ViewAt Step 6 of the Basic Flow, the USER will have the ability to change the report ‘view’. (Report views are covered in more detail in Section 1.6 Special Requirements.) 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 of the 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 RangeAt Step 6 of the Basic Flow, if the current report view is a closed ticket report, the USER will have the ability to change the date range of the 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 of the date range.If the USER selects a new date range for the closed ticket report view, the system will return to Step 5 of the 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.1.4.3.3 Select Summary Line Item from Open Ticket Summary ReportAt 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.1.4.3.4 Select Open Ticket from Open Ticket Detail ReportAt Step 6 of the 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 of the 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 of the Basic Flow).1.4.3.5 Select Summary Line Item from Closed Ticket Summary ReportAt Step 6 of the 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 ReportAt Step 6 of the 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 ReportAt Step 6 of the 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 6 of the 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 ViewAt Step 6 of the 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 of the 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 ReportAt Step 6 of the 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 of the report, the system must publish a comma-delimited file that includes all of the data within the columns of the 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 of the AdjusterDate and time the report was generatedThe 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-ConditionsIf successful, a standard report is created for the USER.If unsuccessful, the system state remains unchanged.
1.6 Special RequirementsThe special requirements for this use case define all of the 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 report1.6.1 Standard Management Reporting ViewsStandard management reporting views are views that have been defined by Enterprise 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 (seeFIG. 149) includes the detailed data fields that are available on each of the ‘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)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 greater than 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 of the report view (e.g., open ticket detail, open ticket summary)the name of the entity that is being reported on. For summary views, this should always be the office name. For detail views, the entity name must be:the adjuster name (for reports by Adjuster)the office name (for reports by Office)the repair facility name (for reports by Repair Facility)the date/time the report was generated1.6.2 Custom Management Reporting ViewsCustom 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 of the report, and the system will not limit the number of columns that a USER can request as part of the report. Custom reporting views are discussed at length in use case RP-03 Add/Edit Custom View.1.6.3 Report View ManagementThe system will present all of the 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 PointsThis section describes the extension points of this use case.1.7.1 MA-13 Change AuthorizationIf 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 of the Basic Flow within this use case.1.7.2 RP-03 Add/Edit Custom ViewIf 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 of the Basic Flow within this use case.
2. Screen DesignA 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 Management Report View TemplateThis screen provides the USER with a management report view template, and supports Step 6 of the Basic Flow.2.1.1 Screen Layout—seeFIG. 1502.1.2 Screen Field Definition

ScreenLabelTypeLengthData FieldScreen Specific RuleOfficeComboBranch claimsThis combo list should include all ofBoxofficethe offices for the currently activecompany that the USER is assignedto.If the value of this field is changed,the system should automaticallyrefresh the screen with the currentreport view for the newly selectedoffice.Handling forOutputHandling forFor management reports, this valueTextshould always be ‘Yourself’Output<Report By>The <report by> field is a placeholderTextin the header of the report view. Formanagement reports, thisplaceholder should be populated withthe name of the entity that is beingreported on (i.e., Adjuster Name,Office Name, or Repair FacilityName).Output<Time/DateThe <time/date stamp> field is aTextStamp>placeholder in the header of thereport view. For managementreports, this placeholder should bepopulated with the date and time thatthe report was generated.Output<ReportThe <report type> field is aTextType>placeholder in the header of thereport view. For managementreports, this placeholder should bepopulated with the name of thecurrent report view (e.g., Open TicketDetail, Custom View 1)<ColumnOutput<DataThe data columns of the reportHeading ITextColumns Ishould correspond to the datathrough X>through X>columns defined for the selectedreport view (either static or customreport view). The data columnsshould be presented in the sequencethat they are defined.TotalOutputNumber ofThe total field should include the totalTextCustomernumber of contracts/customer filesFilesthat are represented in the report.Go toComboReport sortedThe ‘Go to’ combo box shouldboxby navigationinclude all of the entities available inthe current report. For example, ifthe report were an Open TicketDetail view Reported By Adjuster,this list would include all of theAdjusters that would PAGE in thelist.The ‘Go to’ combo box should onlybe available in detail views.Repot byComboReport sortedThe ‘Report by’ combo box shouldboxbyinclude all of the currently availablereport by options in the ARMS Websystem. The report by options forthe initial release of ARMS Web 2.0should be: ‘Office’, ‘Adjuster’, and‘Repair Facility’Select aComboReport viewThe ‘select a view’ combo boxviewboxselectionshould include the names of allreport views that are available to theuser. This includes all pre-defined(e.g., Open Ticket Detail) and user-defined custom views.There should be an additional optionto ‘Add a custom view . . . ’. Ifselected, the system should redirectthe user to the Add/Edit CustomView screen in the RP-03 Add/EditCustom View specification.Show OnlyComboClaim TypeThe ‘show only’ combo box shouldboxFilterinclude the following values:II Claim Types (default)nsured Claim Typeslaimant Clain Typesninsured Claim Typesheft Claim TypesWhen selected, the report shouldfilter the records to display in therequested report view according tothe selection in this combo box. Forexample, if the selection in the ‘showonly’ field were ‘Insured ClaimTypes’, the report view would onlyinclude records that have a ClaimType of ‘Insured.FromComboClosed ticketThe ‘From’ combo box shouldboxreport froninclude all months and years for thedatelast 13 months (rolling 13 monthperiod, current month inclusive). Forexample a value in this field mightinclude ‘January 2000’.The default value should be 2months prior to the current month.ToComboClosed ticketThe ‘From’ combo box shouldboxreport to dateinclude all months and years for thelast 13 months (rolling 13 monthperiod, current month inclusive). Forexample a value in this field mightinclude ‘July 2000’.The default value should be thecurrent month.2.1.3 Screen Function DefinitionThis 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 reportThe ‘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 AveragesThe ‘Go to Report Averages’ screen function provides the USER with a hyperlink to the bottom of the report to review the averages for each of the numeric columns in the report view. The ‘Go to Report Averages’ hyperlink must be at or near the header of the report.2.1.3.3 Column Heading SortThe ‘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.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 <Report By>The ‘Next <Report 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 reportThe ‘Download this Report’ screen function allows the USER to click on a hyperlink and download a comma-delimited copy of the current report view. The downloaded copy must include:Report Header InformationName of the Report ViewName of the PersonDate and Time that the Report Was generatedReport View Column HeadingsReport View Records2.1.3.7 View ReportThe ‘View Report’ screen function allows the USER to submit a request for a different type and/or range of the 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 ViewThe 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.
Functional Design Specification
Add/Edit Custom View
Version 1.1

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 ActorsAll actors will use the use case to add or edit a custom report view(s) in the ARMS Web system. All of the following actors can be defined generically as a USER:ADJUSTERCOMPANY MANAGERFor the balance of this use case, all of the above actors will be referred to as USER.
1.3 Pre-ConditionsThe 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 EventsThe Flow of Events includes all the steps necessary to add or edit a custom report view in the ARMS Web system.1.4.1 Activity Diagram—seeFIG. 1511.4.2 Basic FlowThe Basic Flow of the 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 FlowsThe 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 ViewAt Step 1 of the 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 of the data columns that were previously defined as the massive report would appear in the ‘selected columns’ portion of the screen.
1.5 Post-ConditionsIf successful, a custom report view is created for the USER.If unsuccessful, the system state remains unchanged.
1.6 Special RequirementsThe special requirements for this use case define all of the management report ‘views’ that are available to the USER. Management reports will be provided two USERs in two ways:1.6.1 Custom Report DefinitionThis 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). (Most of the numeric fields that can be summarized for USERs are already provided in the standard management report 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.1.6.2 Custom Report View Data DomainThe 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.

AdjusterClaim NumberClaim TypeOffice NameRenter NameState of RentalLocationAuthorized DaysAuthorized RatePolicy Daily RateDays BehindNumber of ExtensionsPolicy MaximumRateRental DaysBilled DaysBilled to %Repair Facility NameInsured NameRental StatusTotal ChargesBilled AmountAmount ReceivedOther ChargesVehicle Condition (DriveableAuthorized TotalFlag/ Repairable Flag)AmountSurcharges FlagRental Start DateRental Close DateTermination DateInvoice DateInvoice Approve DateRemittance DateRepair Facility Phone Number
1.7 Extension PointsNone.
2. Screen DesignA 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 Add/Edit Custom ViewThis screen provides the USER with the ability to add or edit a custom view, and supports Step 2 of the Basic Flow.2.1.1 Screen Layout—seeFIG. 1522.1.2 Screen Field Definition

ScreenLabelTypeLengthData FieldScreen Specific RuleName thisTextCustom ReportThe name a USER provides to refer toreportNamethe custom report view definition.The name of the report must be uniqueto other custom reports defined by theuser (e.g., a single user can not havetwo reports with the same name). Thisuniqueness must only be enforced atthe user level (e.g., two different usersCAN use the same name for a report).The name of the report will appear inthe USERs ‘Select a view’ combo boxwhen the report view is saved.Start from aComboCustom viewThe ‘Start from a View’ combo listViewboxstart pointallows a USER to select a default or‘standard’ view as a starting point inreport view definition. The values withinthe combo box should be ‘Open TicketDetail’ and ‘Closed Ticket Detail’. Ifselected, the system should use thevalues of the 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-’TicketComboCustom viewThe ‘Ticket Status’ combo box indicatesStatusboxticket statusthe scope of the report in terms of ticketstatus. The list should include ‘OpenTickets’, ‘Closed Tickets’, and ‘AllTickets’. The system will use this aspart of the overall custom reportdefinition.AvailableList BoxCustom viewThe ‘Available Fields’ list box includesFieldsavailable fieldsall of the fields that are available to beincluded in a custom view, but have notyet been selected to be included in thereport.When an available field is selected fromthe list to be included in the report, thefield should be removed from this listbox (and populate the ‘New ReportFields’ list box).For a list of all available fields seeSection 1.6.2 Custom Report View DataDomain above.New ReportList BoxCustom viewThe ‘New Report Fields’ list boxFieldsselected fieldsincludes all of the fields that have beenselected by the USER. These fieldsdefine the columns of the report.The sequence that the fields appear inthe report is defined from top to bottomof this list box (e.g., the first field in thelist = the first column in the report).This sequence can be modified usingthe Sequence Up and Sequence Downscreen functions (see 0 ScreenFunction Definition below).If the USER selects a starting view(from the Start from a View field), thelist box will populate with all of the fieldsthat make up the standard viewselected (e.g., if the USER selects‘Closed Ticket Detail’ from the Startfrom a View field, all of the fields thatmake up a Closed Ticket Detail reportwould populate in this field.2.1.3 Screen Function DefinitionThis 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 RemoveThe ‘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.1.3.2 InsertThe ‘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 DictionaryThe ‘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 of the help functionality of the system.2.1.3.4 Sequence UpThe ‘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 DownThe ‘Sequence Down’ screen function (presented with a ‘down’ arrow in the screen shot) allows a USER to move a selected field in the ‘New Report Fields’ list box down in the sequence of the report.2.1.3.6 Save Report ViewThe ‘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 SavingThe ‘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.1.3.8 DeleteThe ‘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 longer 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).
Functional Design Specification
Maintain User
Version 1.3

Maintain User

1. 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 ActorsThe 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 a person 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-ConditionsThe 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 EventsThe Flow of Events will include all the steps necessary to add or maintain a company user in the ARMS Web system.1.4.1 Activity Diagram—seeFIG. 1531.4.2 Basic FlowThe 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 Flows1.4.3.1 Add UserAt 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 CompanyAt 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 of the 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 FailsIn step six of the 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 of the 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 NameFirst NameUserID (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 UserUntil step five in the Basic Flow, the USER may choose to cancel the use case. The system should not store any changes made by the USER within the use case.
1.5 Post-ConditionsIf 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 Requirements1.6.1 User InactivationIn 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 daysIf 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) andA4XREFL1/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 ‘0’ (rejected invoice ARMS researching)1.6.2 User Default SettingsWhenever 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 PointsNone.
2. Screen DesignA 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 Create or Modify UserThis screen will allow the USER to search for and select a user to modify or select to add a new user.2.1.1 Screen Layout—seeFIG. 1542.1.2 Create or Modify User

Screen SpecificScreen LabelTypeSizeScreen Field NameData Field NameRuleNew TeamRadio1Create a New TeamButtonNew UserRadio1Create a New UserButtonIndicatorUser ID:Input10User IdARMS Profile IDFirst Name:Input15First Name of NewFirst NameUserHandling ForOutput30Handling ForFirst Name + LastNameLast Name:Text Box20Last Name of NewLast NameUserUser IDOutput10List of User Ids withinAdjustor Codethe companyNameOutput30List of Users within aFirst Name + LastCompanyNameUser ID:Input10User IdAdjustor CodePrimary officeList Box25Primary officeexternal organizationnamePrimary officeOutput10List of Primary officesexternal organizationabbreviated nameOfficeOutput20List of Officeexternal organizationDescriptionDescriptions withinnameCompanyOffice:Output4Office Idexternal organizationabbreviated name2.1.3 Screen Function DefinitionThis 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 LinksWhen any of the 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.3.3.2 Teams LinkWhen the team link is clicked, the list of teams should position itself at the top of the view area on the page. The list of teams should be placed last in the list of all users/teams.2.1.3.3 ProcessWhen 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.
2.2 Create or Modify TeamThis screen will allow the USER to input and change information about a user (i.e. name, E-mail address, etc.)2.2.1 Screen Layout—seeFIG. 1552.2.2 Create or Modify Team

Screen SpecificScreen LabelTypeSizeScreen Field NameData Field NameRuleNew TeamRadio1Create a New TeamButtonNew UserRadio1Create a New UserButtonIndicatorNameOutput20Adjusters AssociatedFirst Name + Lastwith the CompanyNameHandling ForOutput20Handling ForFirst Name + LastNameUser IDOutput7List of User IdsAdjustor CodeAssociated with aCompanyPrimary officeList Box20Primary officeexternal organizationassociated withabbreviated nameTeamPrimary officeOutput10List of Primary officesexternal organizationAssociated with aabbreviated nameCompanyOfficeOutput20List of Officeexternal organizationDescriptionDescriptionsnameassociated with acompOffice:Output10Officeexternal organizationabbreviated nameTeam NameInput15Team Nameexternal organizationname2.2.3 Screen Function DefinitionThis 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 LinksWhen any of the 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.2.3.2 Teams LinkWhen the team link is clicked, the list of teams should position itself at the top of the view area on the page. The list of teams should be placed last in the list of all users/teams.2.2.3.3 ProcessWhen 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.
2.3 User ProfileThis 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—seeFIG. 1562.3.2 User Profile

Screen SpecificScreen LabelTypeSizeScreen Field NameData FieldRuleRemove ThisCheck Box1Delete branch fromBranchpreferred locationsindicatorFirst Day Out:List Box10Out of office startThree drop downs:datemonth, day, yearOffRadio1Select feature settingButtonOnRadio1Select feature settingButtonOffRadio1Show confirmationButtonpageOnRadio1Show confirmationButtonpage?ConfirmText Box0Passwordchange passwordN/A.Password:NewText Box0Passwordchange passwordN/A.Password:Adjuster:List Box30Handler for out ofFirst Name + Lastoffice userNameHandling ForOutput15Handling ForFirst Name + LastAdjusterNameOld Password:Text Box0PasswordUser PaswdN/A.AddressOutput30Preferred LocationAddress Line +AddressAddress Line2OfficeOutput10Claims Officeexternal organizationabbreviated nameOffice:Output10Handler for out ofexternal organizationoffice adjuster'sabbreviated nameofficeNameInput30Preferred Locationlocation nameDefaults to addressNamename2.1.3 Screen Function DefinitionThis 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 ProcessWhen 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.1.3.2 Add A Different OfficeWhen 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.
3. Application OperationsThis 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.
4. Data Fields
4.1 Data Field DefinitionThis section includes a definition of all data fields included in the functional specification.4.1.1 Handler for out of office userThis is the user who will handle work for the user who is out of office.Data Field Type: Alpha-NumericData Field Length: 0Data Source: <Data Source>4.1.2 Start PageThis is the initial page that the user will see when he logs on to the system.Data Field Type: URLData Field Length: 256Data 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: BooleanData Field Length: 1Data Source: <Data Source>4.1.4 PasswordThis 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: PasswordData Field Length: 10Data Source: <Data Source>
5. Questions and AnswersIssue Number: 334Question: 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—ResolvedResolution: 4-7-00, Issue Mtd., Defer to user review 1208-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: 335Question: Does a user have the field level control of the fields he can see?Status: Closed—ResolvedResolution: 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: 336Question: Are we still using the “Requests to be Processed” page (the Command Center) as an option for a start up page?Status: FutureResolution: 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: 434Question: 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 Adjusters. There was also consensus that if the ability to select your start page is removed in this release, it should be possible to easily add it back in the future.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 of the feasibility and impacts to the create reservation process if a user is allowed to enter the create res page without having entered the initial 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—ResolvedResolution: Jul. 17, 2000 [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—I 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 exist1) to have the information to perform authorized and unauthorized matches to ensure that the reservation that is being created does not already exist, 2) to get the ‘where needed’ information to retrieve a location & rates, 3) to get the claim type information up front so that we can build the authorization section of the create reservation page appropriately.if we change the process to support ‘FNOL’ adjusters differently than the ‘normal’ way of creating a reservation, use of the application will be inconsistent.Please contact me if there are concerns with these statements.