DRB Processing is used to prepare and send reservation, rental and accounting (receivables) data to one of Hertz's Data Centers. CARS+ supports two different Hertz designs: one where all data is sent to one place and the receiving system passes that data to other Hertz "down stream" systems (such as travel agency commissions - TACO, GMD, etc.) or a design where accounting data is sent to one system and all other rental data is sent to a Hertz Data Center. The following chart summarizes these two designs and the programs used by sending region:
| Transmission Zone |
CARS+ Program used to send Accounting Data |
CARS+ Program used to send Marketing Data |
Hertz Record Layout Used |
| North America both corp and licensees |
HTZDRB and HIRDRB - these programs send closed rental and reservation data to OKC. For corporate locations, these programs are run in "near-real-time" for licensees these are daily batch files. For licensees, any RA that does not have a Hertz Credit card or a Hertz voucher (Tour, SVV or FVV) is sent as a "Blues Marketing" record and thus bypasses Hertz Global Accounts Receivable system. |
The DRB system in OKC will take data sent in HTZDRB and HIRDRB and feed it to all "down stream" systems including Global Marketing Database. |
GXASF031 |
|
Brazil |
Additional posting program 6 is used to export accounting data to JetData in Brazil. Any RA that does not have a Hertz Credit card or a Hertz voucher (Tour, SVV or FVV) is sent as a "Blues Marketing" record and thus bypasses Hertz Global Accounts Receivable system. |
HTZDRB - this program sends closed rental and reservation data to to all "down stream" systems including Global Marketing Database in OKC. This is run as a daily batch file. FTEDRB is used to produce an ascii file of frequent flier data. |
GXASF031 |
|
Europe |
HZEGAR - this program sends closed rental and reservation data to the data center in Dublin Ireland. This is run as a daily batch file. For licensees, any RA that does not have a Hertz Credit card or a Hertz voucher (Tour, SVV or FVV) is sent as a "Blues Marketing" record and thus bypasses Hertz Global Accounts Receivable system. |
The data center in Dublin will take the data sent in HZEGAR and feed it to all "down stream" systems including Global Marketing Database. | GXASF033 |
| Australia both corp and licensees |
HTZGAR and HIRGAR - these programs send closed rental and reservation data to OKC. For both corporate and licensee locations, this is run in "near-real-time" mode. For licensees, any RA that does not have a Hertz Credit card or a Hertz voucher (Tour, SVV or FVV) is sent as a "Blues Marketing" record and thus bypasses Hertz Global Accounts Receivable system. |
The data center in OKC will take the data sent in HTZGAR and HIRGAR and feed it to all "down stream" systems including Global Marketing Database. | GXASF033 |
| New Zealand both corp and licensees |
Additional posting program 7 is used to export accounting data to Oracle Financials in Melbourne Australia. | HTZNWZ - this program sends closed rental and reservation data to to all "down stream" systems including Global Marketing Database in OKC using the "RENTTAPE" record layout. This is run as a daily batch file. |
RENTTAPE |
| All other international licensees |
No accounting feed to a Hertz Data Canter is currently available. RAs with a Hertz collectable FOP (HCC, SVV, FVV, Tour) must be manually sent to OKC for processing. |
RADIUS - this program sends closed rental and reservation data to to all "down
stream" systems including Global Marketing Database in OKC using the "Radius" record layout. This is run as a daily batch file. User Note: Of the transmission programs listed in this column, this is the only one that does NOT do the audit checks described below. See the chapter on Hertz Frequent Flier Download for operating instructions. |
RADIUS |
As the screen layout, reports and general procedures are the same for all but the two accounting export programs and FTEDRB, this documentation applies to all of the other programs and file formats. The term "EDRB" below is used to refer to both EDRB and GAR formats. Instructions for the two additional posting programs used in Brazil and New Zealand will be described at the end of this chapter.
RATE TYPES THAT ARE NOT SUPPORTED BY EDRB/GAR
Although, all of the Rate Types described in Edit Rental Rules and Rates are supported by the CARS+ Reservation, RA Open and RA Close programs, they are NOT all supported by Hertz' EDRB/GAR programs. The following chart indicates the rate types that are supported by these applications:
|
RATE TYPE |
Hertz EDRB |
Hertz GAR |
| STANDARD |
Y |
Y |
| WEEKEND |
Y |
Y |
| TIERED |
Y |
Y |
| FIXED TIERED |
Y |
Y |
| STEP-TIERED |
Y* |
N |
| HOURLY |
N |
N |
| CHAUFFEUR HOURLY |
N |
N |
| PERIOD |
Y* |
N |
| CALENDAR DAY |
Y |
Y |
| HOTEL CALCULATED |
Y |
Y |
| INCLUSIVE |
Y |
Y |
| SEASONAL |
Y* |
N |
| RETURN SPECIFIC |
Y |
Y |
| PACKAGE |
Y* |
N |
| DAILY AVERAGED |
Y |
Y |
* The data structure within the systems in OKC expect rates to fit the structure of day/week/month/xday. These rates do not fit that structure. In order to pass the OKC audits, HTZDRB on rentals involving these types of rates takes the total Time change and divides it by the number of chargeable days to arrive at an averaged daily rate. It is this averaged daily rate that is sent to OKC. Therefore, the rates sent to OKC will NOT match what you see in CARS+, although the revenue will be correct.
SET UP
Thermeon's Customer Support Department will do the necessary set up and configuration for EDRB that is right for your transmission zone and they will coordinate with OKC for test transmissions.
OVERVIEW OF THE PROCEDURE
The following is an outline of this procedure:
1. When a RA is closed, the closing program (both on-line and batch) queues the RA for inclusion in the next DRB transmission. Voided RAs are also included in the transmission.
Note: In some instances, certain RAs are excluded from the queue. RAs meeting one of the following criteria are NOT queued for transmission:
a. The location where the RA opened has been designated as a non-valid rental location for the purposes of DRB processing. (See the Edit Locations File.)
b. The class of vehicle has been designated as one whose RAs are not to be transmitted via DRB processing. (See the Edit Class Codes File.)
2. The DRB Processing program is then executed by the system timer (automatic transmission file creation) or by manually starting the program using the screen described below.
3. All RAs queued for transmission are automatically audited for errors which would result in Data Center rejection. RAs with errors appear on the DRB Error Log and remain queued up for corrections and inclusion in a future transmission (note: the Radius feed does NOT do an audit check).
When a RA has an error on EDRB and the contract is corrected on a later date, the DBR date on the RA (and the RA Charge records) is changed to the cutoff date of the EDRB run when it actually gets transmitted. For example, assume that a RA that closed Feb. 1 had an error on the EDRB which was corrected February 5. This RA would be transmitted with the work of Feb. 5. If the cutoff date on the transmission was February 5, the DBR date of the corrected RA would be changed to February 5. If the cutoff date on the transmission was February 6, its DBR date would be changed to February 6. It is likely that the work of the original closed date, Feb. 1, is already posted. Therefore, there is no need to go back and re-post an earlier day's work (no need to do "sweep posting).
Although the revenue will post February 5, the payments that were taken on the RA will post on the DBR of February 1. They are also on the Drawer Balance Report of Feb. 1. For cash flow purposes, credit cards can be settled as soon as the payments are posted. In effect, posting the payments on one date and the revenue on another date (once the EDRB errors have been corrected) will all balance out by flushing through the A/R Account.
To avoid this situation, run a Test Run of the EDRB and correct all errors PRIOR to doing an actual transmission.
4. RAs without errors are written to a transmission batch file. The file is named using the following format:
First three letters of the month.
Date DRB Processing was executed
The letters "DRB."
Company Number of the data processed.For example, the file created on April 20 from data in Company 00 would be:
APR20DRB.00
This program enforces the Data Center's rule that only one transmission file can be created on any given day. Therefore, once this program is run to create a transmission file, any attempt to create a second file on the same day will fail.
5. The DRB Processing program prints two other reports; the Vouchers/Special Documents Report and the DRB Audit Report.
6. Finally, the file is transmitted electronically to the Data Center.
7. Inclusive Rates: CARS+ extracts all inclusive items out of a rental rate and allocates some of the Time revenue to each inclusive item. In the feed to OKC some of that extracted revenue is added back into the Time revenue before the RA is sent. The logic works as follows;
For North and South America
- Everything is unbundled from the inclusive rate and sent as option revenue outside of TIME
For Asia/Pacific using HTZGAR
- Any inclusive "L" type option is added back in to TIME
- Option Code CVG2 is added back in to TIME
- As are Options "MAX" and "PAI"
- All other inclusive options are NOT reported as part of Time and thus reported separately
For Europe using HZEGAR:
- Any inclusive "L" type option is added back into TIME
- Option Code CVG3 if defined as an Option type "C" is added back into TIME
- All other inclusive options are NOT reported as part of Time and thus reported separately
- For rentals that have a tour voucher and some out of voucher chargeable days which are charged using an inclusive rate, the out of voucher rate does NOT have any of the revenue for its included items extracted. The GAR system in OKC is not able to handle extracted revenue in this case.
Note: When operations set up their own "private" CDPID numbers (ones that OKC is not aware of), those private CDPID numbers must be alphanumeric. The EDRB program ignores alpha-numeric CDPID numbers. (CDPID numbers assigned by OKC are numeric only.)
EDRB/GAR FEEDS AND TOUR VOUCHERS
Net tour vouchers can be set up to either be sent to OKC for receivable processing or be posted to the CARS+ for handling as a local collectable. If the voucher is to be a local receivable, the value of the voucher is sent to OKC as a cash deposit. The following chart defines how tour IT records must be set up for each of these two categories for each of the three transmission logics:
| Transmission Zone |
Vouchers to be sent to OKC |
Local Receivable |
| The Americas |
Only vouchers entered into the S subwindow which reference an IT record defined as Tour Family "N" are sent to OKC. |
Vouchers entered through the V subwindow and those entered into the S subwindow with IT records defined as Four Family "T" are posted as local receivables. |
|
Asia Pacific |
Only vouchers entered into the S subwindow which reference an IT record defined as Tour Family "N" are sent to OKC. | Vouchers entered through the V subwindow and those entered into the S subwindow with IT records defined as Four Family "T" are posted as local receivables. |
|
Europe |
Vouchers entered into the S subwindow which reference an IT record defined as Tour Family "N" and those with Tour Family "T" which also have a Hertz Charge Card in the Billing Account Field and an Alternate IT # are sent to OKC. | Vouchers entered through the V subwindow and those entered into the S subwindow with IT records defined as Four Family "T" but without a Hertz Charge Card in the Billing Account Field and an Alternate IT # are posted as local receivables. |
EDITS TO POSTED RAs
HTZDRB/HIRDRB (EDRB) Users:
Edits to posted RAs are not automatically transmitted to Hertz. For users of the HTZDRB (EDRB) program, an edited RA can be manually re-transmitted as long as the edit changes payment on the RA from being a locally collected (i.e., Market Analysis) to being collected by Hertz (e.g., a voucher or HCC is added) or vice versa. Once the edit has been made, please contact Thermeon Customer Support to have the RA re-queued for transmission in the next batch file.
Changes which do not involve the addition or removal of a Hertz-collected payment must be reported manually. With the exception explained above, OKC allows an RA to be transmitted via EDRB only once. If there is an important update to an already transmitted RA, it needs to be manually transmitted to OKC.
GAR Feed Users:
In general, edits to posted RAs are not automatically sent. The one exception to this rule is the GAR feed for corporate locations that is run in "near-real-time" mode (at this time only Hertz Australia). These closed RAs are sent to OKC within minutes after they are initially closed. If they are edited before midnight on the same day that they originally closed, the edited RA will be sent to OKC. Edits done after midnight are not sent.
| OPTION: __ DRB PROCESSING 1 Send date 04-20-08 2 Test run (Y/N) Y (also R=rerun reports, U=re-update RAs) File name APR20DRB RA count Run date Start time End time Done by Times run Sequence# 1 Errors 3 Lag days 9 4 NoShows/Voids? Y 5 Print Errors? Y Printer /dev/tty 1BEGIN 2PREVIOUS 3ERASE 4 5BACKUP 6 7HELP 8 |
Enter data as follows:
| 1. SEND DATE |
For a test run or a real run, both of which create a new transmission file, this field MUST default to today's date. This field:
To examine a previously created transmission file, enter the date that the file was created, or press F2 to scroll backwards through the list of previous transmission dates. EXAMPLE: Press (RET). |
| 2. TEST RUN |
Enter:
EXAMPLE: Type Y (RET). User tip: The first time that a real run is done (meaning this field = N), the RAs included in that run are marked with the appropriate transmit date. Any subsequent real run will only re-report the same set of RA's. Therefore, changing the number of lag days on a subsequent real run done on the same day has no effect. The following fields are not accessible but display important information. |
|
FILE NAME |
This field contains the name of the transmission file that will be or was created on the date in Field 1. The following fields display data only when accessing a previously created transmission file. |
|
RA COUNT |
Number of RAs included in this transmission file. |
|
RUN DATE |
Date the DRB reports were last printed from a transmission file. |
|
START TIME |
System time when the program began processing queued RAs. |
|
END TIME |
System time when the program completed processing all queued RAs. |
|
DONE BY |
Employee Code of the user who created this transmission file. |
|
TIMES RUN |
Number of times this program has been run for the date in Field 1 (excluding test runs). |
|
SEQUENCE# |
This counter begins at "1" and is incremented by 1 each time a new transmission file is created. For example, the number "20" indicates the twentieth transmission file created in this data base. |
| ERRORS |
Number of errors found during the auditing process. Because a single RA can have multiple errors, this count may not correspond to the RA count. |
| 3. LAG DAYS |
Enter a single numeric character to indicate the number of days the system should wait after a RA is closed before it is transmitted. Lags days allow for auditing time before RAs are transmitted. The default number in this field comes from a field in the Edit Miscellaneous Control Fields file, but can be overridden here. EXAMPLE: Type 3 (RET) |
| 4. NOSHOWS/ VOIDS? |
This field controls whether or not No-Show reservations and Void RAs are transmitted in the Electronic DRB file. Y = Send No-Show and Void RAs.Licensees should always answer "Y". N = Don't send. Corporate locations should always answer "N" because the No-Shows and Voids are sent in the Car Rent White Feed. EXAMPLE: Type Y (RET) |
|
5. PRINT ERRORS? |
This field refers to corporate locations that are running in "near real time mode", which, among other things, means that this program is run automatically every 15 minutes. When run in this manner, the reports are printed from a separate program. Therefore, these corporate locations should answer "N". Licensees should leave at the default of "Y" because they will get the prompt at the bottom of the screen asking whether or not to print the reports. EXAMPLE: Type Y(RET) |
Upon pressing F1, the following prompt will display:
DO YOU WISH TO TRANSMIT THIS FILE?(Y/N)
Answering "N" causes the program to move on to the prompts for printing the various reports.
Answering "Y", causes a second prompt to display:
SEND FILE TO P)RODUCTION OR T)EST SYSTEM?
Enter "P" or "T" as appropriate.
The normal response to this question is "P" - to send the file to the Production system at Hertz OKC. However, when an operation first goes up on EDRB, it is necessary to send files to the Test system until OKC approves them for production transmissions. In addition, occasionally when a new feature is being implemented, it may be necessary to send the Test system.
When EDRB is run automatically, the file is transmitted to the production system and all reports are printed.
DRB REPORTS
Whether a DRB is initiated manually (through this program) or set to occur automatically (through the system timer), the following reports print when appropriate.
DRB ERROR LOG
The following is a list of all the possible error messages that may appear on the DRB Error Log. In some messages, the erroneous data from the RA is included. In the list below, italics and underlining is used to indicate inserted data.
1. INVALID DRB AREA: area number. The Area Number of the opening location does not match the Area Number of your system's Main location, as defined on the Main Control File screen.
2. UNKNOWN PC CODE: document name document code and voucher#. The system does not recognize the PC# of a special document entered into the S Subwindow on the RA Open screen.
3. TIME CHARGES MISSING. The Data Center will not accept an RA with missing time and mileage charges.
4. CHECK-OUT-LOC NOT A VALID DRB LOC: open location code. On the Edit Locations screen, Field 38 defines which locations are valid locations for DRB reporting. This message indicates that the RA was opened at a invalid location.
5. CHECK-IN-LOC NOT A VALID DRB LOC: close location code. The RA was closed at a invalid location.
6. ORIG RETURN LOC NOT A VALID DRB LOC: return location code. The Return Location entered on the RA Open screen was not a valid location.
7. INVALID VEHICLE OWNING CITY: owning location code. The Owning Location Code of a foreign vehicle begins with the illegal characters "00". To correct this, create a new foreign location code in the Customer File and then change the owning location code on the affected foreign vehicle.
8. CORP LOC CAN'T END WITH '00'. A corporate Location Code ends with the illegal characters '00'.
9. ODOM-IN NOT > ODOM-OUT. The check-in odometer reading is not greater than the check-out reading.
10. BILLED DAYS < RENTAL DAYS: number of days chargedelapsed days. Renter was charged for less days than the number of elapsed days. If free days are given to the customer use the Customer Service Adjustment field. This situation is ignored if a packaged weekend charge is involved.
11. CARD# SEEMS WRONG FOR FOP: fop codefop card number. After doing a second validation of the FOP Code and Credit card #, the data does not match. This is usually caused by changes made in the CARS+ Card Definitions since the RA was closed or a failure to have an FOP Code defined for OTTOs.
12. CC# credit card number INVALID CARD#. Changes have been made to the Credit Card Definitions file so that a card which passed the check digit routine at the time of entry is now found to be invalid.
13. FOREIGN PAY CODE BUT NOT FOREIGN COUNTRY. The Hertz credit card used has been identified by its card number to have been issued outside the US or Canada, yet the home address of the renter is not that of a foreign country.
14. FT frequent traveler number CHECK DIGIT ERROR. Changes have been made to the Frequent Traveler Code records so that a frequent traveler number that passed the check digit routine at the time of entry is now found to be invalid.
15. NET DUE NOT = FOP AMT: net due amountpayment amount. For corporate locations, this will occur if more than one credit card was used in payment or if a forced charge is left "unpaid" by FOP "FCHG". For licensee locations, this will occur if more than one type "BC" FOP is used in payment.
16. NEGATIVE NET DUE - ACCT 2043 MISSING OR INCORRECT. RA was saved with a refund due the renter.
17. TOUR PAY CODE BUT NET DUE NOT ZERO. This error occurs when a tour voucher is used with either a credit card to be cleared through the Data Center or an unprocessed forced charge.
18. BAD VEH-RATE-CLASS CODE. With the exception of certain 2 character class codes, all Hertz Class codes must be a single alpha character.
19. CUST-SERV-ADJ AMT > 1ST SUB-TOT-AMT. The Customer Service Adjustment cannot be greater than the total Time and Mileage.
20. DRIVER ADDRESS-STATE: ON INVALID COUNTRY CODE or BILL-TO-STATE: ON INVALID COUNTRY CODE. These messages indicate that a foreign country code, valid at the time the RA was opened, has been removed from the Country Code File.
21. BAD OR MISSING FIRST NAME. Although CARS+ allows RAs to be opened to parties with only a last name (for example, companies as renters), the DRB system in OKC cannot accept transactions of that sort. Renters must have both a first and last name to be transmitted. To correct this, edit the RA via Edit Opening Fields and add data to the first name field.
22. GST MISSING BUT NOT TAX EXEMPT. This error only occurs at Canadian sites. It indicates that the GST Tax has been removed from the RA but no Tax Exempt Number was recorded.
23. CANADIAN POSTAL CODE REQUIRED. This error occurs on Canadian addresses (those with Canadian Province Codes in the State field) which do not have Canadian formatted Postal Codes. This error can occur on any of the following fields:
Renter's address - Correct this in the renter's Customer file record, not on the RA Open screen.
Renter's Employer's address - Correct this also in the renter's Customer file record.
Bill-To address - Correct this in the bill-to customer's Customer File record.
24. TIME CHARGES MISSING. This error occurs when the daily rate on the RA is zero. To transmit a RA without a time charge, enter a Customer Service Adjustment to back out the Time charge.
25. TIME CHARGE ERROR (QTY X RATE NOT = AMT). This error occurs when the length of the rental is greater than 99 days. The chargeable days field in the EDRB/GAR record is only two characters in size thus an RA of 100 days or greater has the chargeable days truncated when placed in the transmission record. An RA with this error must be split into more than one rental or manually submitted. Setting the max days field in Edit Misc to 99 days or less will prevent this from happening in the future.
26. VOUCHER DAYS TOO LARGE. This error occurs when the voucher days are greater than 99. The field for voucher days is only 2 characters. RAs with vouchers of more than 99 days must be submitted manually to OKC and cannot be transmitted via EDRB.
27. INVALID VEH CLASS / INVALID RATE CLASS. Hertz class codes are a maximum of two characters. Typically this error is displayed when a class code is greater than two characters. Contact Thermeon Customer Support for help with creating the correct conversion record. Once the conversion record has been created the RAs will transmit on the next run.
CLEARING UNCORRECTABLE ERRORS OFF THE DRB ERROR LOG
The following steps can be used to clear uncorrectable errors off the DBR Error Log. It is important to note that the method used to clear these errored RAs results in the false assumption that the contracts have been successfully transmitted even though they are not. Therefore, it should be standard practice to manually DRB these rental agreements before using the following clearing procedure.
1. Perform a Test Run for a date for which there has never been a Real Run (the field labeled "Times Run" is blank). Normally, use the default of today’s date.
2. Fix all contracts that can be fixed so that on a subsequent Test Run, the only RAs that appear on the Error Log are those you wish to clear.
3. Run this program a second time with an "X" in the Test Run field for the selected date. This will execute the program in a "purge" mode. In the purge mode,
As a result, the RAs that cannot be corrected drop off the queue of RAs to be transmitted.
4. Run this program a third time with an “N” in the Test Run field for the selected date. This will create a transmission batch file with all valid RAs for that date.
User tip: On occasion, a RA may need to be transmitted even though it fails the
audit process. The program Set EDRB Error Flag can be used to force the transmission of a RA
which has failed the audit logic so that it can be submitted anyway. WARNING: Forcing too many errors through in any one batch may result in the entire batch being rejected at OKC.
LICENSEES AND BALANCE DUE RENTALS
One of the audit rules imposed by OKC is that no rental can have a balance due, neither positive nor negative. That is, the total of all deposits/payments/vouchers on an RA must exactly equal the total charges. That would mean that CARS+ would not be allowed to do any local direct bill rentals or local insurance replacement rentals. Early on, that rule was deemed unacceptable by our licensee body. As a result, for licensee operations only, the EDRB program reports a RA with a balance due as having been "paid in full by cash" at the time of close. The RAs will report on the CARS+ DBR as having a balance due that will post to the accounting files, but the same RA will report to OKC as having no balance that OKC needs to be concerned about.
Note: Cars+ sends reimbursements in the DRB as deposits. There is a GVT record (GARREIMB) that Thermeon Support can load to your server that will change reimbursements to be sent as Miscellaneous array.
RETRANSMITTING MQ FILES
If for some reason the MQ batch files need to be sent again (or if they were not sent in the first place) they can be resent using the SHELL/MQGAR script. See Retransmitting MQ batch files for more information.
ADDITIONAL POSTING PROGRAMS USED IN BRAZIL AND NEW ZEALAND
As stated in the table at the start of this chapter, both Brazil and New Zealand export rental receivable and general ledger distribution data to external accounting systems that are NOT part of the two standard Hertz Data Centers (OKC and Dublin, Ireland). This exporting is NOT done through an EDRB like program but rather through the standard CARS+ DBR posting logic. See the chapter on the Accounting DBR and Posting for instructions on how to post RAs.
I. SYSTEM SETUP
A. FOR HERTZ BRAZIL
1. In Edit Main Control record, the value "6" must be inserted into the field Extra Post Pgm on page 1 of the record. This is done in the operating company that is shared by both the corporate and licensee locations. This will cause accounting data to be exported to JetData.
B. FOR HERTZ NEW ZEALAND
1. The same field in Edit Main Control Record must be set up as follows:
In the operating company that is shared by both corporate and licensee locations, enter the value "7". This will cause the corporate locations to export data to Oracle Financials
In the accounting companies for each individual licensee, enter the value "X" in Extra Posting Prog and the value "3" in the field XML Interface on page 2. This will cause the licensee locations to have their accounting data exported to MYOB..
2. In addition, the GVT record "NZPSTRA7" must be set up in the operating company that is shared by both corporate and licensee locations. This will cause any licensee RA that has a Hertz voucher (TOUR, SVV, FVV, ETC.) or Hertz FOP (HCC OR OTTO) on it to "double post" to both their own MYOB files and the corporate Oracle Financials files.