Overview - Multiple Invoiced Rentals

I. INTRODUCTION

Often rental agreements cover a period of time greater than 30 calendar days. This can cause some problems if:

1. Local laws stipulate that car rentals cannot exceed 30 days.

2. You must wait until the contract closes before generating an invoice for the customer for the rental charges.

3. Users using EDC: The rental exceeds the maximum rental length allowed by the Credit Card Processors. (Example: Worldpay, Windcave, Stripe etc.) The usual maximum allowed rental days is 99.

The CARS+ Multiple Invoiced rental logic is designed to eliminate the above two problems.

The Multiple Invoiced logic consists of the following:

1. Special fields on the RA Open screen are used to set up each contract for the Multiple Invoiced logic using one of the following three methods:

a. Billing Cycle:In this method a certain number of days can be specified, such as 28 or 30 days.For example, if 30 days is selected, starting with the opening date of the contract, the RA will be closed down every 30 days and a new one created.If the RA starts on May 13, it will be closed June 12 (30 days); then July 12, August 10, Sept. 9, etc. with each contract being 30 days long.

b. End of the Month Billing:(A form of “Calendar Month” billing.)In this method, the RA closes on the last day of the month.The first month’s charges are pro-rated.For example, if the RA starts on May 13, it will be closed May 31; then June 30, July 31, August 31, etc.

c. Day of the Month Billing: (A form of “Calendar Month” billing.)In this method, the RA closes on a specific day of the month other than the last day, such as the 15th.The first month’s charges , therefore, may be pro-rated depending on the day of the month selected.

i. For example, if the RA starts on May 13, and the 15th is selected as the billing date, it will be closed on May 15 (after only two days). Subsequent closings will be on June 15, July 15, August 15, Sept. 15, etc.

ii. Using the same example, if the 12th is selected as the billing date, it will be closed on June 12, July 12, Aug. 12, Sept. 12 etc. without the need for a prorated billing in the first month.

Note: After a RA has been opened, a change to the billing method can be made only by select users. See the section below on editing the billing cycle.

2. The Multiple Invoiced Rentals program batch closes appropriate Multiple Invoiced rentals and automatically batch opens cloned copies of the closed RAs.

3. Special logic within the RA Close program for making the final close of the contract.

User tip: The Multiple Invoiced Rentals logic was designed with the assumption that the RA would be a direct bill. CARS+ EDC clients using a Payments Service processor (currently Worldpay, Windcave and Stripe) can configure CARS+ to request authorizations or take deposits upon each cloning. Please refer to the Multiple Invoiced Rentals chapter for details. CARS+ EDC clients using other card processors will, after the RAs have been processed via the Multiple Invoiced Rentals program, need to access the closed RA in Edit Closed RA and enter the payment details. Additionally, the newly cloned RA must be brought up in RA Open and a new authorization obtained.

This chapter covers the Multiple Invoiced Rental logic features. It is assumed that the reader is familiar with the standard RA Open and RA Close programs.

II. DEFINITIONS

MULTIPLE INVOICED RENTALS - Multiple Invoiced Rentals are rentals which:

1. extend for a period of time which is longer than the normal RA.

2. either the renter or a bill-to customer is to be invoiced for the rental charges.

3. due to the length of the rental, the customer is to be invoiced one or more times (on an agreed to invoicing cycle) before the actual return of the vehicle.

LONG-TERM RENTALS - These rentals are very similar to Multi-Invoiced Rentals with the exceptions listed below. As a result, they are managed by a different set of programs and reports than Multi-Invoiced Rentals. For more information on longterm rentals, please refer to the chapter Overview - Longterm Rentals.

DIFFERENCES BETWEEN THE TWO TYPES OF RENTALS:

MULTI-MONTH RENTALS	LONGTERM RENTALS
The Invoicing frequency (Billing Cycle) can be set to any period desired: once a week, every 14 days, every 30 days, on the same day of each month (such as on the 15th of the month) etc.	The Invoicing frequency is set automatically to 30 days and cannot be changed.
A deposit can be placed on a Multi-month rental and it will be applied to each billing cycle until it is all consumed.	Deposits CANNOT be added to Longterm rentals. For Hertz users, they cannot have a SVV, FVV or OTTO.
Retail rentals do NOT automatically become Multi-Month rentals if they are opened for a period greater than X days.	Retail rentals automatically become Longterm rentals if they are opened for a period greater than X days.

III. SET UP STEPS

A. EDIT OPTIONAL ITEMS

Page 1

TYP FLG

(Type Flag)
User tip for type M = Miscellaneous Charges.

Items in this category only will be displayed when the Option Pop-Up window is called from the Miscellaneous Charge fields on the RA Open and RA Close screens. Options of this type DO NOT get carried forward to the next RA when cloned by the Multi-month RA logic..

Field on page 4 defines how certain options are charged on multiple invoiced rentals.

ECHO CLS

(Echo Close)

This field is available to define if certain options (other than type "M") should be added at open and removed at close. Enter:

P = Apply this option automatically to all RAs. Remove the option at Close. (On multi-month RAs, the option is applied to the first RA in the series, but is not carried forward to subsequent RAs.)

User tip: This is a way to apply an authorization pad by Pricing Code. A standard auth. pad can be set up in the Edit Misc. Control Fields file and it applies to all RAs. If the standard auth. pad is being used, there is no need to use the Option feature. However, if the auth. pad needs to vary by vehicle class or certain corporate accounts need to be exempt from it, an Option can be set up for it using Pricing Codes. Entering the letter "P" in this field for the auth. pad option to have it automatically applied to all RAs and removed at Close. Like all automatically applied options, a Privilege Code can be set up to exempt certain corporate accounts from it.

M = Similar to "P" (above), except that on multi-month RAs the option is applied to all RAs in the series and removed when each RA is closed.
User tip: These options must be configured as 'automatically applied' in Edit Option Rates.

B. EDIT OPTION RATES

Field on page 4 defines how certain options are charged on multiple invoiced rentals.

MLT RA

(Multiple RA logic)

Some options are defined with a maximum number of days for which they can be charged on a RA. For multiple invoiced rental, RAs are closed after a set period of time. The data is cloned and a new RA is opened. This field is used to define:

A. How options with a maximum number of days should be charged

B. How flat fee options should be charged.

A. Options with maximum days

The following example illustrates this concept. Assume that a rental is scheduled to run for 90 days. The first RA is set up with the multi-month logic so that it will close the first RA after 30 days, clone the information, and open another RA. Subsequently the second RA will close after another 30 days and a third RA will open.

Example 1: Assume there is a surcharge defined with a maximum charge of 20 days. This field determines whether the 20-day surcharge should apply to the first RA only, or whether it should apply to all RAs in the sequence. Enter:

Y = Yes. On multi-month RAs when an option has a maximum days limit, clone the option to each RA in the series so that it is charged to the maximum day limit on each contract.

N (or blank) =No. On multi-month RAs when an option has a maximum days limit, it applies only once up to the maximum number of days and thereafter is not cloned to a new RA.

Example 2: Now, assume that the surcharge is defined with a maximum charge of 40 days.

Entering “Y” would cause the option to be charged for all 30 days on each RA. (The maximum number of days was never met.)

Entering “N” would cause the option to be charged for 30 days on the first RA. Then it would be cloned to the second RA and be charged for 10 days (total of 40 days). Since the maximum number had been reached, it would not be cloned to the next RA.

EXAMPLE: Type N (RET)

B. Flat fee options

This field defines whether a flat fee option is charged on every RA in the series or if it is charged only on the first RA. Enter:

Y = Yes. On multi-month RAs when an option is a flat fee, clone the option to each RA in the series.

N (or blank) =No. On multi-month RAs when an option is flat fee, it applies only to the first RA and is not cloned to a new RA.

C. INCREMENTAL MILES/KM WHEN MULTI-MONTH RAs ARE PROCESSED

Part of the multi-month logic provides the odometer reading to increment a certain amount each time the multiple invoiced rentals are processed. The increment can be manually entered on the RA, left blank, or come from the following sources:

EDIT LOCATIONS

Page 4, Field 20: Multi-RA KMs

Use this field to set a default amount of miles/kms to increment the odometer when RAs are cloned.

EDIT MISC CONTROL FIELDS

Page 7, Field 39: Multi Month Mls type

This field affects the default incremental mileage/kms for multiple invoiced rentals. Enter:

blank = The default estimated miles per period will come from the "Multi-ra Kms" field in Edit Locations. If that field is blank, no default will be loaded.

1 = If the rate has unlimited miles/kms, the default estimated miles per period will come from the "Multi-RA Kms" field in Edit Locations. If that field is blank, the default estimated miles per period will come from the "Multi Mls Per Period" field in Edit Misc. (see the next field)
If the rate has limited miles/kms, the days in the billing cycle will be used to calculate the number of free miles/kms per cycle, and that amount will be entered as the default.

Page 7, Field 40: Multi Mls Per Period

This field is related to the field above. When that field = 1, this field is used to set a default amount of miles/kms used to increment the odometer reading when multiple invoiced rentals are processed.

User tip: If the estimated miles/km field on the RA is left blank, the odometer increments by 1 mile/km when closing and cloning a new RA. This causes virtually all of the miles/kms to be charged on the final RA. In order to prevent that, set up a default increment in one of these places or on the individual RA.

D. EDIT RENTAL RULES/RATES When setting up a rate for multi-month RAs, note that the Multiple Invoiced Rentals program, (the program that processes these RAs) does not check the rules of the rate on the RA (including the rules for minimum and maximum days). Unlike a regular RA, on multiple invoiced rentals the negotiated rate applies to the entire rental, even the last one of the chain that may be for only a few days. An exception is made when a rate has an alternate rate linked to it. When the rate has an alternate rate, the rules on the rate ARE checked by the Multiple Invoiced Rentals program and by RA Close for the final RA in the series. Additionally, all of the "change-to" rules on the rate will be checked (including the minimum or maximum days). E. EDIT USER ACCESS FILE When multiple posting companies are set up, the fire wall logic within CARS+ is in effect when processing Multiple Invoiced Rentals. The logic compares the Posting Company Code on the user's default sign-on location to the Posting Company Code of the location entered on the screen. If the Posting Companies are different, the location's RAs cannot be processed. Use the "Firewalls" field in Edit User Access to bypass the firewall logic. F. MULTI-MONTH RENTALS AND PAYMENT SERVICES For those clients who make use of the CARS+ Payment Services logic (WorldPay or Windcave), it is possible to automatically seek a new credit card authorization on the new RA created by the close and clone process. Authorizations can be gained for a new deposit created at open or for a pre-authorization that will be used when the current contract closes. Contact Thermeon Customer Support if you wish to have this logic activated by way of a GVT(MULTAORD) record it is not turned on by default. Note for installation using GVT record MULTAORD: (See Warning note below) You must advise Thermeon Customer Support if the GVT should be set up in "Auth/Payment" mode or "Deposit" mode. If running in Deposit mode, the first RA must have card details in both the Main Window and the C Subwindow. The card number in the Main Window will be used to take the deposit on each cloning of the RA. If running in Auth/Payment mode, it is only necessary to enter card details in the Main Window. This card number will be used to take a payment upon closing the cloned RA using the opened RA's Pre-Auth, and then making a new Pre-Auth on the new cloned RA. If no card details are entered, no action is taken by the feature. The RA will be assumed to be a direct bill -- either to the customer entered in the B Subwindow or the renting customer if no details are provided in the B Subwindow. NOTE: WARNING!!! Once this GVT record has been set to Auth/payment or Deposits, it is not recommended to make changes. Example: changing the record from A (Auth/Payment only) mode to D (Deposit) mode while multimonth rental agreements are still open and in use. If this change needs to be made, note that ALL Mutlimonth RA Deposits and Auth/payments will need to be done manually during this transition period. Contact Thermeon Customer Support with any questions or concerns before requesting this change. IV. OPENING A MULTIPLE INVOICED RENTAL The following fields are handled uniquely when opening a Multiple Invoiced rental: MAIN WINDOW
7. FOP EXP	If the rental is to be secured by the renter's credit card in this field, the following rules apply: The expiration date on the credit card does not need to be greater than the return date entered into Field 11. But it must be greater than the open date of the RA plus the number of days in the billing cycle. If the expiration date on the card is less than the date in Field 11, the RA will NOT close and clone in the month in which the card expires. It is assumed that by then the renter will have received a replacement card with a future expiration date. Update the RA with the new expiration date and run the Multi-month rentals program again. EXAMPLE: 1. When first opening the rental, the credit card cannot expire within the first billing period. (Example billing set at 30 days, the FOP must be valid for the initial 30 day period.) 2. Cars+ will allow the final return date to be after the expire date (Example: this is a 6 month rental and the credit card is to expire within the 4th month. The assumption is that the renter will receive a new card before the present card expires.) 3. The close and clone logic checks to see if the card will still be good for the next billing period. (In this example, it will close and clone 3 times. As the card will expire in the 4th month, the program will NOT close and clone the RA for the 4th month. Cars+ will report an error and the credit card on file must be updated. 4. Based on the above, there is nothing that prevents a user from extending the RA beyond the expire date. Cars+ will prevent the next RA Clone and close in the expiring month.
11. RET DATE/TIME	Using your selected date and time format, enter the date and time of when the customer expects to return the vehicle. This may be months or even years into the future.
14c. PPD (prepaid fuel)	The fuel purchase option (also known as prepaid fuel) cannot be sold on a multiple invoiced RA.
G SUBWINDOW (DATES AND MISCELLANEOUS) or AM SUBWINDOW (MULTI-MONTHS, LONGTERMS, AND LEASES) Access to these fields can be controlled by a field in the user's User Access record. The following fields appear in both subwindows.
DAYS IN BILLING CYCLE	Enter up to 3 numeric characters to indicate one of the following: A. Billing Cycle: The number of days in this contract’s invoicing cycle. For example, entering 28 in this field will set up the rental to be invoiced every 28 days from the original open date. EXAMPLE: Type 28 (RET) For the next two methods, the first character of this 3-character field must be a “9”. The second and third characters can be 01 to 31, representing the day of the month on which the RA is to be closed and invoiced. B. End of the Month Billing: Use “31” for the last two characters to designate RAs that should close on the last day of the month. If the value of the last two numbers is greater than the last day of a particular month, the last day of that month will be used. So in January the contracts will be closed and clone on the 31st but in February they will clone on the 28th (or 29th in leap years) and in April they will be processed on the 30th. EXAMPLE: Type 931 (RET) C. Day of the Month Billing: Enter a “9” followed by 2 characters representing the day of the month on which this RA should be closed. For example, to code a contract to close on the 15tth of the month follow the example below: EXAMPLE: Type 915 (RET) Note: The values 930 and 929 mean that in the month of February, contracts will be processed on the last day of that month, while in all other months, they will be processed on the date indicated. User Tip: When Day of the Month billing is used (also referred to as calendar month billing) the rate must include a monthly rate. If it does not, the following message will display: MONTHLY RATE REQUIRED ON CALENDAR MONTH RENTAL AGREEMENTS An exception to this rule is allowed if the GVT record "RAMULTRT" is set up. If your system should be so configured, ask Thermeon's Customer Support Dept. to set up this GVT record for you. Note: The method for the billing cycle cannot be changed once a RA is open unless the user has "ALL" access or in their User Access Record the field "Block Multi-Month" is set to "E". For other users, the current RA must be closed. Then another RA should be opened with the new method. Note: Recursive Billing (where the contract has skipped one or more billing cycles and must create multiple billings to “catch up”, will also use the appropriate billing cycle, last-day-of the month, or certain day of the month value for each month as the closing date on each RA. Note: When rates are set up with a minimum number of days, the rule applies only to the first RA of the series. Once it is cloned, it does not apply to subsequent RAs or the last RA in the series. As an example, assume that a multi-month rental is set up with a Rate Code that has a minimum of 25 days. If the customer returns the car before the 25 days are up, the "change to" rate will be used. But after several months, if the last RA in the series closes with only 15 days expired, the change-to logic is not used. NOTES: Leaving this field blank turns off the Multiple Invoiced Rental logic. If the return date on the RA is for less days than the billing days entered, when the RA is saved, the billing days field will be cleared. For example, if the user entered 931 for the billing days, but the RA is for only 1 week, it cannot be a multiple invoiced rental and, therefore, the field will be cleared.

EST MILES PER PERIOD	Enter up to 5 numeric characters for an estimate of the number of miles that will be used for each billing period. Note: For End of Month and Day of Month billing, the first month’s time charges may be prorated. The mileage allotment entered in this field will ALSO be prorated. For example, if the RA begins on April 16 and is set up with End of Month billing, the first RA will close April 30 and 50% of the estimated miles entered here will be applied to that first partial month. If a default amount has been entered in the Location record, it will automatically be loaded in this field. If a default amount has been entered in Edit Misc. Control fields (and not in the Location record) it will be loaded after doing an F8 estimate. If the rental rate is limited miles/kms, the free allotment of miles/kms will be loaded after doing an F8 estimate. Leaving this field blank results in the odometer incrementing by "1" when the RA is closed and cloned. This will cause the miles/kms driven to be charged when the vehicle is return and the final RA closes. This may result in a significant balloon charge on the RA.
START DATE/ODOM/FUEL	These display only fields will carry the original RA Open Date, Odometer and Fuel tank level from this RA when it is cloned into new RAs by the Multiple Invoiced Rentals program.
PREVIOUS LINKING RA#	This display only field will carry the previous RA# which this was cloned from.
ORIG RA NUMBER	This field appears only in the AM subwindow. For reference purposes, it shows the original RA number in the series.
Note: There is an option to adjust the rate for inflation that can only be found in the AM subwindow. Additionally any installments will be displayed. When saving a RA which has calendar month billing specified, a daily and monthly rate must be present in the rate structure. If there is no rate in the “Day” and the “Month” fields, the following message will display: MONTHLY [DAILY] RATE REQUIRED ON CALENDAR MONTH RENTAL AGREEMENTS.

V. EDITING THE BILLING CYCLE ON AN EXISTING RA

WARNING:

Editing the billing cycle, especially the 'day of the month' billing or changing the cycle from one method to another, on an existing RA has significant ramifications and thus is restricted. The field "Block Multi-Month" in the user's record in Edit User Access File controls who can perform this task.

How the change is handled depends on the timing of the change including whether the billing date is moved to later day or earlier day in the month.

It is recommended that the next time the RA cycles, the closed RA be brought up in Edit Closed RA and examined. Edits to the time calculation may be needed. Pressing F8 to re-calculate the charges may help.

The cycle can be changed on individual RAs by bringing up the RA in RA Open or Edit Opening Fields, accessing the G subwindow, and changing the value in the field "Days in the Billing Cycle." To change multiple RAs at one time, use Update RA Billing Days Field.

VI. VEHICLE EXCHANGES

When an exchange is performed on a multi-month rental, it is possible that the ending odometer reading for the vehicle being returned is less than the opening odometer reading was at the start of the contract. As long as the contract is designated as a multi-month rental, this is allowed.

VII. MULTIPLE INVOICED RENTAL PROGRAM

This is the program which batch closes and clones contracts so as to allow interim invoicing on long term rentals.

A. RAs are selected for processing when all of the following conditions are met:

1. The RA is set-up for multiple invoicing (the field "Days in Billing Cycle" is not blank).

2. The RA meets any other selection criteria entered on the Multiple Invoiced Rentals screen (such as Open Location, RA Type , etc.).

3. The required number of days have elapsed under one of the following methods:

a. Billing cycle: The RA's Open Date plus the number of days in its field "Days in Billing Cycle" is less than or equal to the Cut-Off date entered on the Multiple Invoiced Rentals screen.

b. End of the month: The Cut-Off date entered on the Multiple Invoiced Rentals screen is equal to or greater than the last day of the month.

c. Day of the month: The Cut-Off date entered on the Multiple Invoiced Rentals screen is equal to or greater than the specified billing date.

4. The RA's Return Date is after the entered Cutoff Date. (Cutoff date cannot be later than yesterday.)

RAs which have a Return Date earlier than the Cut-Off Date must either have their Return Date extended, if the customer still has the car, or be manually batch closed if the vehicle was returned.

NOTE: Cars+ checks the credit card expiration date at the time of rental and at the time of cloning only. Credit card expiration dates are not checked for rental extensions.

5. The Prevent Close Flag is not set to "Y".

The Multiple Invoiced Rentals program skips those RAs that have the Prevent Close flag set to "Y".

6. If there is a credit card in the FOP field in the Main Window, the card's expiration date is later than the upcoming billing cycle.

7. When multiple posting companies are used, the location(s) entered have the same posting company as the user's sign-on location, or the user is exempt from firewall logic in the their user record in the Edit User Access file.

B. The automatic closing logic will do the following:

1. Before closing and cloning a RA, the bill-to company's customer type is checked to make sure it is still a valid bill-to type. If it is not, the following message is displayed and the RA is skipped:

BILL-TO ON RA xxx IS NO LONGER A VALILD BILLING ACCOUNT

(where xxx is the RA number.)

2. The Closing date of each contract will be set to one of the following:

a. Cycle Billing:The result of Open Date plus the number of days in "Days in Billing Cycle".

b. End of Month:The last day of the month

c. Day of Month:The day specified.

3. The closing DBR date is set to either the Closing Date and Time or the current system date and time depending on how the user answers the DBR Date question on the Multiple Invoiced Rentals screen.

4. The closing odometer is set to the opening odometer plus the value in the "Estimated Miles Per Period" field in the RA. (Prorating is not done in the first month of a Month End or Day of Month billing RA.)

5. Closing fuel level is set to the opening fuel level.

6. Options that are a flat fee charge or have been set up with a limit for the maximum number of days for which the option can be charged are handled according to the setting in Edit Option Rates (Field: Mlt RA).

7. If the RA being closed has a deposit that is greater than the closing charges, the un-used deposit is carried forward.

For the amount of the difference between the deposit and the closing charges, a negative deposit is applied to the closing contract, and a positive deposit is applied to the new RA.

8. All charges will then be calculated as normal with the following exception:
a. Calendar month rentals are calculated as follows:
First month (if prorating is necessary): Number of calendar days multiplied by the RA’s Daily rate. All other rate fields (Hours, Weeks, Months) are ignored. CAUTION: Best price logic is not in effect.

All subsequent full months: The RA’s Monthly rate multiplied by one regardless of the number of days in the month.

For example, let’s assume the following rate structure:
Day         $   50

Week        $  300

Month       $1,200
Assume the vehicle went on rent May 3 and will be billed using End of Month logic. The first contract will close May 31 with a charge for 29 days (calendar days) at $50 per day equaling $1,450 for a partial month. This illustrates the point that when using End of Month billing or Day of Month billing, the daily rates must be coordinated with the monthly rate in order to charge an appropriate amount. (Calendar day calculation logic will apply regardless of the setting of the Calendar Day Calc flag of the attached Rate Product.)

b. If the rate rules are set up to reference an alternate rate(s), the best rate is applied to the RA being closed. AND, that rate is carried forward to the new RA.
As a rule, the Multiple Invoiced Rentals program does not check the rules of the rate on the RA. Unlike a regular RA, on multiple invoiced rentals the negotiated rate applies to the entire rental, even the last one of the chain that may be for only a few days.
An exception is made when a rate has an alternate rate linked to it. When the rate has an alternate rate, the rules on the rate ARE checked by the Multiple Invoiced Rentals program and by RA Close (for the final RA in the series.) Additionally, all of the "change-to" rules on the rate will be checked (including the minimum or maximum days).
9. If there is a credit card in the FOP field of the main window, the credit card number and expiration date are cloned to the next RA.
10. If payment is to be made by credit card (rather than direct bill), the closed RA must be brought up in Edit Closed RA and the payment processed.

11. Delivery and Collection: If delivery and collection charges are applied to the reservation or the first RA in the series, both charges will be included in the initial estimate. However, delivery will be charged only on the first RA, and it is not cloned to subsequent RAs. When The Multiple Invoice Rental program is run, Collection will be changed to a zero rate on the RA being cloned from and the charge carries forward to subsequent RAs. The Collection charge will actually be applied only to the last RA in the series.

C. The automatic cloning logic will create a new contract for each contract which was batch closed. All data in the closed contract will copy across to the new contract except the following:

1. The RA number will be new. It is the next number available from the opening location's range of RA numbers. The closed RA's number is written into the field "Previous linking RA#" which is displayed in the G subwindow of the RA Open screen.

2. The Open Date/Time is set to the Closing Date/Time of the contract that was closed.

3. The Opening Odometer is set to the Closing Odometer of the contract that was closed.

4. Any deposits or vouchers which were part of the closed contract DO NOT get cloned on the new contract.

5. If a credit card number and expiration date were entered into the main window of the RA, they will be carried forward to the next RA. The RA must be brought up on the Open screen and new authorization entered. (The new auth. must be obtained by requesting it via EDC, or manually entered if obtained outside of CARS+.)

6. The monthly commission percentage is carried forward.

7. For users other than Hertz operations, FVV's (full value vouchers) are carried over to the next RA.

8. A field in the Multiple Invoiced Rentals program controls how automatically applied options are handled during the cloning process. Entering:

Y = The program should review the automatically applied options and add or remove them as necessary. For example, if a new tax or fee has gone into effect since the current RA opened (the one being closed), add that fee to the cloned RA.

N = The program should not review the automatically applied options. Instead, clone exactly what is on the current RA.
9. The rate in effect on the closed RA will be used on the new RA. Note that the rate product and effective date of the rate product are cloned to the new RA (as shown in the R subwindow). If a newer version of the rate has been created and is in effect, it is not used.

10. A vehicle with a Hold Code is cloned to the new RA. (A Hold Code does not stop the process of the multiple invoiced rental being closed and cloned.) The fact that the vehicle has a Hold Code is noted on the Audit Report.

D. Multiple Invoiced Rentals Audit Report

If requested, this report prints after the Multiple Invoiced Rentals program runs listing RAs that need attention. RA's included are:

The RA has a fuel card on it (Prepaid Fuel field = C).
The customer's driver's license expires before the returned date of the newly opened RA.
There is a credit card in the FOP field (Field 7 of the Main window).
The vehicle has a open Hold Code assigned to it.

The following data is shown on the report:

Closed RA #
New RA #
Renter's first and last name
Renter's phone number
Prepaid fuel flag
Odometer reading on the new RA
A place to write in the actual current odometer reading (to be filled in manually after calling the renter)
Driver's license expiration date
Form of Payment name, and expiration date
Vehicle number
All open Hold Codes on the vehicle

E. Hertz Operations

For Hertz operations, in addition to the above, CARS+ also does the following:

The Hertz billing documents HCC, FVV, or OTTO by definition cover the entire rental period. Therefore, when RAs with these documents are closed and cloned, these documents are also cloned to the new RA.

Exception: When the validation logic is turned on for Hertz Credit Cards (HCC), prior to cloning the RAs the HCC credit card record is checked to make sure the card is still in active status. If not in active status, the RA will not be cloned.

When a SVV exists on the RA being closed, the following happens:

If the SVV value is greater than the RA charges, the SVV amount is set to the total charges of the closed RA and the difference is cloned to the new RA as the SVV amount.

If the SVV value is equal to or less than the total charges on the RA being closed, the SVV is applied to it. Although a SVV record will be applied to the newly cloned RA, the value is set to zero.

VIII. MULTIPLE INVOICED RENTALS REPORT

To obtain a list of the open Multi-Month RAs showing the date they are due to be cloned, use the Multiple Invoiced Rentals Report found on the Rental Accounting Menu. (shortcut MULTRPT). This can be run for a particular bill-to company, all bill-to companies, or for those RAs without a bill-to company.

IX. MULTIPLE INVOICED RENTALS PRE-CLONE REPORT

This report is used to examine open multiple-month RAs for problems needing manual intervention before the next clone takes place.

In order to be included in this report, the RA must have been opened through the Multiple Invoice Rentals cloning process within the data range and location requested. An examination of each of those RAs is done.If at least one of the following potential problems is found, the RA is included in the report:

Driver’s license will expire before the end of the current billing cycle (the next cloning)
Form of Payment (credit card) will expire before the current billing cycle (the next cloning)
RA has a Fuel Card (requires manual intervention after the close of the RA.)
Vehicle has open Hold Codes applied to it
RA has a cash deposit

The intention is that this report will be run before the next cloning procedure is done so that these issues can be resolved prior to the cloning process.

X. PERFORMING THE FINAL CLOSE OF A MULTIPLE INVOICED RENTAL

The final close of a Multiple Invoiced rental MUST be done via either the On-line or Batch Close program. The final open RA that needs to be closed can be requested in one of the following two ways:

1. Enter the RA# of the currently open RA directly into the RA Close screen.

2. Enter the RA# of any of the previously closed segments of the multi-invoiced rental. When this is done the following question is displayed:

CLOSED MULTIMONTH RA - LOCATE LAST (OPEN) RA INSTEAD?

Answer:

Y = Yes, please find the currently open RA that is part of the multi-invoiced chain that the RA just requested is a part of. If "Yes" is answered, the program will "follow" the chain of closed and linked RAs until it finds the RA that is currently open for this multi-month RA.
N = No, please display the closed RA that was requested.

The close will take place just like any other contract closing with the following exceptions:

A. If the "Estimated Miles Per Period" feature was used, it is possible that the customer drove less than cumulative estimate. In fact, it is possible that the actual closing odometer may be less than the estimated opening odometer on the final segment of the rental. Normally, the RA Close program prevents you from setting the closing odometer to be less than the opening odometer. This restriction is not present on Multiple Invoiced rentals. Therefore, the user is free to set the closing odometer to the actual reading even if it is less than the current opening odometer reading.

But it should be understood that if an odometer reading is entered which is less than the estimated opening odometer, the system logic assumes that the final odometer reading is correct. Because the closing odometer reading MUST be greater than the opening reading, the opening reading on the final RA is automatically rewritten to be one mile (or km.) less than the closing figure.

If the miles/kms were chargeable on the previous RAs in the sequence, be aware that a credit will NOT be calculated by the system for the previous mileage charges. Therefore, if the customer was over charged for mileage on earlier segments and you wish to issue a credit, you must calculate the credit manually (off system) and use either the Customer Service Adjustment field or the Reimbursement field to place the credit on the final RA in the sequence.

B. When closing the last RA in a series of Multi-Month RAs, normally there will be no fuel charge calculated. Multi-month rentals in general are exempt from the fuel charge logic. However, your system can be configured so that the last RA in a series of Multi-Month RAs IS subject to the normal fuel charge calculation. If you wish to activate this feature, please contact Thermeon's Customer Support Dept. and request that GVT code MULTIGAS be set up.

C. When closing the last RA in a series of Multi-Month RAs where tiered rates are used, the rate from the highest tier is used even if the final leg of the contract has fewer days that the highest tier.

D. When closing the last one in a series of multi-month RAs, the A subwindow (Rates) must be viewed prior to saving the close of the contract. Therefore, after a calculation or recalculation is made, the "A" subwindow will flash and the following message will appear on the screen:

LAST RA IN MULTI-MONTH CHAIN - CHECK RATES

If the A subwindow has not been viewed prior to saving, the user will be prompted to view the subwindow and will be unable to close the RA until doing so.

E. If the elapsed days on the final close exceed the number of days in the billing cycle, the following message will display:

RENTAL LENGTH LONGER THAN BILLING CYCLE, CONTINUE TO CLOSE?Y/N

Enter:

Y = to have the Close continue

N = to stop the Close and exit back to the menu

F. When the rate has a minimum number of days defined, the last RA in the chain may not meet that minimum number. For example, a monthly rate may have a minimum of 28 days. The last RA in the multi-month chain is NOT subject to the minimum rule (the rental has been on-going for previous months). Therefore, the RA will calculate using the weekly and daily rates.

XI. LINKED RA'S

One of the files that can be searched from the RA Open screen with the F6 Search feature is the one for Linked RAs. By entering any one of the RA numbers in the chain of a multiple invoiced rental, all RA numbers in the chain will be displayed. See the example below which shows that the first 2 RAs have already been closed and the third one remains open.

OPTION: __ LINKED RA SEARCH
F1=RA #
RA # Open Date/Time Close Date/Time Revenue Exch/Link
****
1 S370815 08-16-03 1830 09-15-03 1830 1596.68 L
2 S371906 09-15-03 1830 10-15-03 1830 1596.68 L
3 S372317 10-15-03 1830 12-28-03 1800 0.00
** End of linking records **

XII. COMMISSIONS

The multi-month program, when cloning information from on RA to another, copies the reservation number from the original RA to subsequently cloned RAs. This causes the cloned RAs to appear on the Incentive Transaction Report. However, the system does not provide for a travel agent commission to be due on the cloned RAs. Only the first RA in the series is seen as commissionable if originating from a travel agent or other commissionable vendor.