Service Request TX Retroactive Payments-Phase One DETAIL DESIGN. Document Number DETAIL. April 24, Phillip Thompson

Transcription

1 Service Request TX Retroactive Payments-Phase One DETAIL DESIGN Document Number DETAIL April 24, 1996 Phillip Thompson Information Systems & Computing Office of the President University of California

2 Page 1 Overview A decision by an Administrative Law Judge requires the University to pay retroactive range, merit and incentive awards to exclusively represented members of the Technical bargaining unit represented by UPTE (University Professional and Technical Employees). The University must also pay interest on these moneys based on when the employees should have received the original payment. This design document only deals with changes to the retroactive processing. It does not provide details for the interst calculation process which will be issued in a subsequent release. Campuses will use existing processes to update the employee data base with the range adjusted and/or merit adjusted rates. The existing retroactive range process will be used. It has a component which will determine the adjustment amounts and create appropriate RA transactions. For employees not included in an overlapping range adjustment, the existing retroactive merit process will be used. It has a component which will determine the adjustment amounts and create appropriate RA transactions. For employees included in an overlapping range adjustment, a modification to the existing process will be developed which will correctly identify records on the PAR file requiring adjustment, but which will determine the adjustment amount based on the actual merit component only (i.e. not including the range adjustment amount). This process will also create appropriate RA transactions. For specific employees, incentive award data will also need to be coded and keyed in some form of transaction. In addition to the specific needs of this project, an issue has been raised that applies to any retroactive process. The issue involves the hourly rates as defined on the range and merit pay scale files and calculated hourly rates on PAR earnings distributions. The pay scale hourly rates are only carried out to two decimal positions. In the Compute, however, when an hourly rate is calculated from a non-hourly pay rate, such as for overtime, the hourly rate is calculated to four decimal positions. The result is that the pay scale rates and such PAR earnings distributions rates never match., which causes the record to be defined as an exception. The correction of exceptions can require a significant work load for the campuses during any retroactive

3 Page 2 adjustment processing. It is requested that some mitigation of this work load be developed as part of this project. After the appropriate transaction files have been created in the existing and modified processes, an new intermediate process is needed prior to the Compute. First, simple interest must be calculated for each RA amount from the time it was originally paid to the associated campus population to some defined end date. Second, the Compute has a limit of 99 RA transactions per Employee ID. The multiple RA transactions will be collapsed on the basis of Employee ID, Full Accounting Unit (FAU), DOS Code and Title Code. Separate RA transactions will be created for interest payments, using a special one-time DOS Code LTX. Interest transactions based on Federal Contract & Grants funds will be coded with a default FAU (provided by each campus).

4 Page 3 Processing Overview There are five main retroactive process cycles which must occur. The input and output of the various cycles must be kept separate and in synch. 10/1/94 Retroactive Range for Title Codes contained in a UCOP provided Pay Scale table. 10/1/94 Retroactive Merit for APS Employee ID s contained in a campus generated Merit Pay Scale file (ID s not included in Retro Range). 1/1/95 Retroactive Merit for Employee ID s contained in a campus generated Merit Pay Scale file (ID s overlap with Retro Range). 7/1/95 Retroactive Merit for Employee ID s contained in a campus generated Merit Pay Scale file (ID s overlap with Retro Range). Individually dated Retroactive Incentive Awards for Employee ID s identified by the campus. 1. The existing processes will be used for the 10/1/94 Retro Range Adjustment. This requires a separate update to the Prior Period Table, including pay period begin and end dates. The Final RA transaction file should be retained, but not processed through any Compute. 2. The existing processes will be used for the 10/1/94 Retro Merit Adjustment. This requires a separate update to the Prior Period Table, including pay period begin and end dates. The Final RA transaction file should be retained, but not processed through any Compute. 3. A modified process will be used for the 1/1/95 Retro Merit Adjustment. This requires a separate update to the Prior Period Table, including pay period begin and end dates. The selection phase logic of PPP930 will be changed to allow for special processing of a Merit that overlaps with a Range Adjustment. First the Retro Range Pay Scale file will be accessed via PPIRANGE using the PAR pay rate. Then the Retro Range Pay Scale New Rate, if one is found, will be used to access the Merit Match file via PPIMERIT. This double call assumes the Merit Pay Scale old rates are based on the Retro Range Pay Scale new rates. The Final RA transaction file should be retained, but not processed through any Compute. 4. A modified process (i.e. the above PPP930 changes) will be used for the 7/1/95 Retro Merit Adjustment. This requires a separate update to the Prior Period Table, including pay period begin and end dates. The Final RA transaction file should be retained, but not processed through any Compute.

5 Page 4 5. Transactions will be keyed for Retroactive Incentive Awards. A Pay End date should be coded which defines the date the specific employee should have been paid the award. This transaction file should be retained, but not processed through any Compute. 6. New one-time programs will then process the five transaction files and create a new RA file for processing in an appropriate Compute. The program will collapse RA transactions based on Employee ID, FAU, DOS Code and Title Code. It will calculate interest based on original Pay Period End Dates, dates when each retroactive payment was made to the associated campus population and a provided interest end date entered via the run specification record. These changes will be issued in a later release. 7. The RA transaction file out of the new program will be processed through the appropriate Compute.

6 Page 5 Program Changes PPP930: Program PPP930 processes Retroactive Range and Merit adjustments. It runs in one of four phases: Record Selection, Corrections, Pro-ration Edit, and Final. Only the Record Selection phase will be affected. The Record Selection phases reads the Prior Period Table (PRP) monthly and semimonthly/biweekly pay period start and end dates to determine which PAR records should be selected for processing. The Pay Rates on the selected PAR Earnings Distributions are then matched against a pay rate table. In the case of the retroactive range adjustment, the Pay Scale table contains old and new rates by title code, coverage code, RDUC code and rate code. If a match occurs between the PAR rate and an old rate, a transaction is written coded as accepted, and with the new rate and calculated adjusted gross amount. If a match does not occur, the transaction is still written but it is coded as an exception. Similar logic applies to retroactive merit processing. Another pay scale file, known as the Merit Match File, is used which is organized by specific Employee ID. Again, the PAR pay rate is matched against the old rates, and transactions are separated into accepted records and exceptions. Only the Record Selection phase reads the PAR file and attempts the rate matching. All subsequent phases work off the transaction file created in the Record Selection phase. During the Corrections phases the exceptions can be corrected for acceptance. After all corrections are made, the Final phase is run which creates the Final RA transaction file, created from the accepted transactions. The amount on the RA transaction is based on the difference between the old rate and new rate and the time or percentage time on the original earnings distribution. Changes: Currently, the run specification record is used to select the Process Option: Retro Range, Retro Merit or Special. A new Process Option will be added as a valid option: Merit After Range. The value on the Run Specification Record will be MRT AFTR RNG. In almost all cases where current logic performs code for the Retro Merit process, it will also perform that code for the Merit After Range process. The few exceptions involve Heading text,

7 Page 6 which will be changed to identify the Merit After Range process. The report file is also marked for similar heading logic in PPP940 (which processes the PPP930 report file). The report file will also be marked uniquely for the Merit After Range process. The main change to PPP930 will be in the logic which attempts to match old rates from the PAR earnings distribution to the two Pay Scale tables. Currently, if the Retro Range process is being performed, the PAR earnings distribution pay rate is passed to called routine PPIRANGE. PPIRANGE accesses the Retro Range Pay Scale file and returns a new rate, if one is found, and a return code indicating the success of the search. A zero return code means there was an exact match, and the transaction is considered accepted. Records are selected for some non- zero return codes, e.g. the title code is on the pay scale table but not the rate, and these become exceptions. Currently, if the Retro Merit process is being performed, the PAR earnings distribution pay rate is passed to called routine PPIMERIT. PPIMERIT accesses the Retro Merit Match file and returns a new rate, if one is found, and a return code indicating the success of the search. A zero return code means there was an exact match, and the transaction is considered accepted. Records are selected for some non- zero return codes, e.g. the title code is on the pay scale table but not the rate, and these become exceptions. The new Merit After Range process will call both routines. First the PAR Earnings Distribution pay rate will be passed to routine PPIRANGE. If there is an exact match, i.e. the return code is zero, the returned Retro Range new rate will then be passed to PPIMERIT. If this also returns an exact match, i.e. the return code is zero, then the Retro Range new rate will be used as the old rate in subsequent reporting, calculations and file creation, and the PPIMERIT returned new rate will be used as the new rate. This will cause the calculated difference to solely reflect the merit component. If the first call to PPIRANGE does not find an exact match, the original PAR Earnings Distribution rate will be used in the call to PPIMERIT. Thus, processing will be as for any normal Retro Merit processing. If the first call to PPIRANGE does find an exact match, but the subsequent call to PPIMERIT does not find a match, then the processing will continue as for any normal Retro Merit processing, i.e. the exception record will reflect the original PAR pay rate. In addition to the above change, a change will be added to both the existing and the new processing options. This will hopefully mitigate the impact of the Compute calculated hourly rates containing four decimal places. When the PAR Earnings Distribution pay rate is hourly, a working copy of the amount will be rounded up by adding.0050 (one half cent) to the rate, and

8 Page 7 the third and fourth decimal positions will be zeroed out. This adjusted rate will then be passed to PPIRANGE and PPIMERIT for matching purposes. The original PAR pay rate, not the rounded rate, will be used in further calculations and reporting. Note, however, that any new rate returned from the Pay Scale files will only contain two decimal positions. PPP940: Program PPP940 reads the report file produced by PPP930 and prints the reports. Some heading text depends on a code passed from PPP930. Changes: Code will be added detect the new Merit After Range processing option and change headings accordingly.

9 Page 8 Forms Changes PPP930 Program Run Specification (UPAY678): A new Process Option value will be added for requesting a Retroactive Merit that is running in conjunction with, i.e. after, a Retroactive Range adjustment. See Attachment A for a form sample.

10 Page 9 Attachments Attachment A Sample PPP930 Program Run Specification UPAY678 form.