Service Request PPI730 Transactions by Retirement Code. Technical Specification. Created on: October 09, Last Modified on: 11/18/2017

Transcription

1 Service Request PPI730 Transactions by Retirement Code Created on: October 09, 2017 Last Modified on: 11/18/2017 Prepared by Baskar Chitravel Information Technology Services Office of the President University of California

2 Version History Version # Date Revised By Reason for Change /31/2017 Baskar Chitravel Initial version /18/2017 Baskar Chitravel Added changes to PPI750 Page 1

3 Table of Contents Version History Introduction Service Request Overview of System Modifications Design Considerations Assumptions and Dependencies Testing Considerations Mainframe Design UCRS Interface Changes COBOL Program PPI730 Transactions by Retirement Code Unit Testing Requirements Attachment A EDB Selection Attachment B PAR Employees Selection Attachment C Standard Mode PPI730 Run Attachment D PERS File Check Attachment E Verify Treasure File Run Page 2

4 1 Introduction Implementation of Retirement Choice has led to a high volume of corrections and adjustments on the UCRS interface. Most of the volume consists of adjustments that move contributions and service credit from one retirement code to another. Service Request outlines the requirements for the PPI730 UCRS Transaction File changes to ensure corrections and adjustments made in PPS are presented on the MEM730 file in a manner that can be processed by UCRS Service Request SR requests the following modifications in PPS: 1. Currently, program PPI730 applies the most recent retirement code of an employee to all the UCRS transactions produced for that employee. Change the PPI730 program logic to apply the employee retirement code retrieved from the current PAR to the associated UCRS transactions produced from that PAR. 2. Each time after a new PAR is read, as of now, PPI730 has differing ways of collecting year-to-date 403(b) and 457(b) amounts (inputting PAR employee ID: XPAR-ID-NO), as below: 403(b) YTD amounts are collected by calling routine PPPBLS. 457(b) YTD amounts are collected by calling routine PPDSAUTL. In order to ensure the correct 403(b) YTD amounts are included in each transaction record, pick up the 403(b) YTD amounts from XDSA array (rather than from PPPBLS) in the same way as the 457(b) amounts are handled. Page 3

5 2 Overview of System Modifications Following are the brief description of the PPI730 program changes to avoid adjustments that move contributions and service credit from one retirement code to another: In the PAR processing logic, accumulate UCRS T segment record, if the incoming new PAR satisfies the following criteria: 1) The incoming PAR is the first PAR of the first employee OR 2) The incoming PAR Employee ID is the same as the previous PAR Employee ID AND The incoming PAR Primary Control is not the same as the previous PAR Primary Control. Change the logic to pick up 403(b) amounts the same way as the 457(b) amounts are handled. Page 4

6 3 Design Considerations 3.1 Assumptions and Dependencies Following are the assumptions made, while designing the PPS changes for the PPI730 Transactions by Retirement Code: A. The solution suggested by Caroline Rider as proof of concept in June 2017 will be used to address the issue of high volume of corrections and adjustments on the UCRS interface after the implementation of Retirement Choice. B. If the employee has multiple input PAR Records in a month, each PAR has unique PAR Primary Gross Control Number. C. No change is needed to the layout of any of the output files produced by PPI730, including the MEM730 file, which will be processing individual PAR records produced for the employee in a month and passing these multiple Employee Retirement Records to the UCRS system. D. Changes impact only UCRS Records and Reporting. E. No CICS changes needed. F. No change needed in UCRS system to process the multiple corrections and adjustments, which are produced in PPS for an employee on the MEM730 file. Page 5

7 4 Testing Considerations o It is recommended to start the testing with the following database data: EDB Complete all the current Monthly and Bi-Weekly computes for the testing month. Also, complete the Monthly Maintenance to begin next month. PAR Load all the Monthly and Bi-Weekly PAR data produced during the current month. CTL Current Control Table data o Merged PAR Sequential File with all the Monthly and Bi-Weekly PAR data produced during the current month must be used to input into the PPI730 program run. o Only UCRS Retirement Interface file produced during the Standard Run should produce data changes. o In the UCRS file produced after the changes, make sure the following: Adjustments that move contributions and service credit from one retirement code to another are applied properly to all transactions. YTD 403(B) Contribution Amount is now retrieved from the XDSA array of the employee, rather than from the PPPBLS program call, make sure that the 403B Contribution Amount (PPPDBL: Y-Balance of GTN 008) is populated in all the fixed data of the UCRS records produced for the employee. o PPI730 changes should not affect the STIP file produced during the Treasurer Run mode of PPI730 program. o Extensive Unit Testing with the base environment is required. o Comprehensive QA and UAT testing setup and support are required. Page 6

8 5 Mainframe Design 5.1 UCRS Interface Changes COBOL Program PPI730 Using the earnings and deductions from the PAR file and the EDB extract, in the standard run mode, program PPI730 creates the UCRS, PERS, SCERS, FCSRS, and OCERS Retirement Interface files. In addition, in the treasurer run mode, PPI730 creates STIP Treasures File on a per compute basis. The details of the files produced by PPI730 in each mode of run is listed below: STANDARD RUN (Monthly PAR): Retirement Interface files produced in the Standard Run are the following: PERSFILE FCSRS OCERS SCERS UCRS TREASURER RUN (Per Cycle PAR): STIP Page 7

9 The changes to PPI730 to satisfy the SR requirements are the following: MISCELLANEOUS WORKING STORAGE Declare a temporary variable Previous Primary Control UCRS-PREV-PRI-GRS-CTL to store the PAR Primary Control XPAR-PRI-GRS-CTL of the processing PAR, which will be used for breaking logic. 10 UCRS-PREV-PRI-GRS-CTL PIC S9(3) VALUE READ-AND-PROCESS-NEW-REC SECTION Currently, in the PAR processing logic in READ-AND-PROCESS-NEW-REC section, accumulation of the UCRS T segment record by calling paragraph DEDUCTIONS-FOR-T-PLANS happens, only if the incoming new PAR satisties the following: The incoming PAR is the first PAR of the first employee OR The incoming PAR Employee ID is the same as the previous PAR Employee ID. Page 8

10 The 2nd condition above will be changed to the condition below: The incoming PAR Employee ID is the same as the previous PAR Employee ID AND The incoming PAR Primary Control is the same as the previous PAR Primary Control PERFORM PROCESS-DEDUCTIONS XPAR-NO-DED-REF TIMES * ***** For consecutive PARs of same employee, process PAR T Plans ***** deductions, only if their XPAR-PRI-GRS-CTL also match. * IF (XPAR-ID-NO = UCRS-PREV-EMP-NO AND XPAR-PRI-GRS-CTL = UCRS-PREV-PRI-GRS-CTL) OR UCRS-PREV-EMP-NO = ZERO MOVE ZERO TO T-DED-I PERFORM DEDUCTIONS-FOR-T-PLANS XPAR-NO-DED-REF TIMES END-IF Page 9

11 33160-UCRS-SET-UP-FIXED-PORT SECTION Currently, the accumulated UCRS record is written (33170-WRITE-UCRS-REC), clear out the accumulated records (33050-CLEAR-T-PLAN-ARRAY), and start the fresh accumulation of the UCRS T segment record by calling paragraph DEDUCTIONS-FOR-T-PLANS happens, only if the incoming new PAR satisties the following: The incoming PAR is not the first PAR of the first employee AND The incoming PAR Employee ID is not the same as the previous PAR Employee ID. The 2nd condition above will be changed to the condition below: The incoming PAR Employee ID is not the same as the previous PAR Employee ID. OR The incoming PAR Primary Control is not the same as the previous PAR Primary Control UCRS-SET-UP-FIXED-PORT SECTION ENTRY. * ***** For consecutive PARs of same employee, skip processing of T ***** plans deductions, only if their XPAR-PRI-GRS-CTL also match * IF XPAR-ID-NO = UCRS-PREV-EMP-NO AND XPAR-PRI-GRS-CTL = UCRS-PREV-PRI-GRS-CTL IF UCRS-RETIREMENT-CODE = 'L' OR = 'V' GO TO ESTAB-RETR-CODE ELSE GO TO EXIT END-IF ELSE Page 10

12 Add code to save the PAR Primary Control XPAR-PRI-GRS-CTL of the processing PAR into the temporary variable Previous Primary Control UCRS-PREV-PRI-GRS-CTL, which will be used for comparison logic after reading the next PAR record. MOVE XPAR-ID-NO TO UCRS-PREV-EMP-NO WS-EMPLOYEE-ID. * ***** Save XPAR-PRI-GRS-CTL of the current PAR for matching with ***** consecutive PARs of same employee (for T plans dedns logic). * MOVE XPAR-PRI-GRS-CTL TO UCRS-PREV-PRI-GRS-CTL. * PERFORM 9800-SELECT-PCM. Change the logic to pick up 403(b) amounts the same way the 457(b) amounts are handled (from XDSA, rather than from PPPBLS), which is necessary to ensure that the correct amounts are included in each record. MOVE XDSA-BALAMT (YTD-457B, XDSA-YTD-P) TO UCRS-457B-YTD. * ***** If PPPBLS 403B Contribution Amount does not match with XDSA ***** 403B YTD Contribution Amount, move XDSA YTD Amt to UCRS. * IF XBLS-403B-YTD-CNTRB = XDSA-BALAMT (YTD-403B, XDSA-YTD-P) CONTINUE ELSE MOVE XDSA-BALAMT (YTD-403B, XDSA-YTD-P) TO UCRS-403B-YTD-CNTRB END-IF. * MOVE ZERO TO NUMBER-OF-APPTS-SELECTED. Page 11

13 PPI750 Using the UCRS file produced in PPI730 and Specification Card file input, program PPI750 creates the report PPI7502 UCRS Contribution List. In addition, it produces an Error Report, if there are any issues while processing the UCRS file. The details of the modes that PPI750 can run is listed below: SERIAL RUN: In this mode of program run, all the UCRS Records are read and processed sequentially. RANDOM RUN: In this mode, only random employees that are inputted in the input specification card is read and processed sequentially. RANGES RUN: Range of Employee ID is the input for this mode and the program run processes all the UCRS Records for these employees in the input range. Following modifications are done for Program PPI750: In order to avoid SOC7 ABEND due to data overflow in the Save Plan Array of Contribution and Tax Segment, the Save Plan Array size is increased from 99 to 200. In addition to the existing Employee ID, Retirement Code is also added to the logic that breaks the PPI7502 report display. Fixed a wrong Pay Year move statement, while sorting the Contribution and Tax Segment Save Plan Array, before displaying them in the PPI7502 report. Page 12

14 6 PPI730 Transactions by Retirement Code Unit Testing Requirements For testing the UCRS File changes, select a test region and perform the following steps: Load the needed data: Load the EDB after Monthly Maintenance. Load the recent CTL Database. Load the base PAR Files into the PAR tables. Using the RUN465 JCL, load the July Merged PAR file, which will be used for our test purposes, into the PAR tables. Query the database for test employees: Employees should be found with YTD Balances in PPPDBL table for GTN 008. Attachment A has the SQL to get the employees with non-zero GTN_AMT for GTN_IND GTN_NUMBER = '008. = 'Y' and Page 13

15 In order to verify the 403(b) amount in UCRS Detail record, which is taken from XDSA rather than from PPPBLS, choose few employees from the query, as below: EMPLOYEE_ID GTN_AMT Attachment B explains how to get employees with more than one PAR with a different Retirement Code produced during the current month. Using this SQL as a guide, find employees with more than one PAR with unique Retirement Code produced with a Pay Period End Date in the month of July Choose few test employees from the output produced using this PAR query result: EMPLOYEE_ID RECORD_TYPE PRI_GROSS_CTL RET_PLAN_CODE U U U U W Page 14

16 Also, choose few employees with the same Retirement Code: EMPLOYEE_ID RECORD_TYPE PRI_GROSS_CTL RET_PLAN_CODE U U U U U U U For each Employee ID, SQL Query in the JCL RUNQGTNO has queries to the PAR Deduction / Reduction / Contribution table (PPPDRC) to accumulate the contribution amounts for each plan (except plan 21, which is calculated using retirement routines). Submit the query and the results can be used against checking the Contribution Segment of the UCRS Record produced before the PPI730 change. For each PAR (identified by unique Primary Gross Control) of the Employee ID, SQL Query in the JCL RUNQGTNN has queries to the PAR Deduction / Reduction / Contribution table (PPPDRC) to accumulate the contribution amounts for each plan (except plan 21, which is calculated using retirement routines). Submit the query and the results can be used against checking the Contribution Segment of the UCRS Record produced after the PPI730 change. Page 15

17 Run unmodified PPI730: Submit the JCL RUNI730, which runs PPI730 in the Standard Mode. Verify the following: 1. All the files, except the Treasurers file, are produced. In base, only PERS and UCRS files have records populated. 2. In the UCRS file, using the UCRS Detail Record Layout in PAYBCC.TEST.COPYLIB(UCRSDSCT), verify that the 403(b) amounts for the test employees above match the expected amount. The snapshots for the 403(b) amount for the test employees are in the Attachment C. 3. In the UCRS file, no separate UCRS Records produced for the test employees selected by the PAR lookup above. So, for the verification of UCRS Record per Retirement Code logic, for the employees chosen from the Attachment B query, verify that only one UCRS Record produced eventhough multiple PAR records are found. The snapshots for the UCRS Detail Recors for the test employees are in the Attachment C. Submit the JCL RUNI730T, which runs PPI730 in the Treasurer Mode. Verify that only the Treasurers file is produced in this run. Page 16

18 Run modified PPI730: Install the changed PPI730 batch program into the test region using the installation instructions provided with the release. Change the RUNI730 and RUNI730T JCLs so that it can point to the modified version of the PPI730 program. Also, rename all the files produced so that they can be compared against the unmodified run files. Submit the JCL RUNI730, which runs PPI730 in the Standard Mode. Verify the following: 1. All the files, except the Treasurers file, are produced. In base, only PERS and UCRS files have records populated. 2. In the PERS File, only label header record has the changes from before and after run. Use Attachment D for PERS File Check details. 3. In the UCRS file, using the UCRS Detail Record Layout in PAYBCC.TEST.COPYLIB(UCRSDSCT), verify that the 403(b) amounts for the test employees above match the expected amount. The snapshots for the 403(b) amount for the test employees are in the Attachment C. Page 17

19 3. In the UCRS file, no separate UCRS Records produced for the test employees selected by the PAR lookup above. So, for the verification of UCRS Record per Retirement Code logic, for the employees chosen from the Attachment B query, verify that only one UCRS Record produced eventhough multiple PAR records are found. The snapshots for the UCRS Detail Recors for the test employees are in the Attachment C. 4. Verify that the file UCRS CONTROL RECORD REPORT (DD GRPA1) produced in both the production and changed version should match, except Covered Gross has a difference of 3, due to the Retirement Code change for employee Submit the JCL RUNI730T, which runs PPI730 in the Treasurer Mode. Verify that only the Treasurers file is produced in this run. Verify that the file UCRS CONTROL FOR TREASURERS STIP (DD GRPA1) produced in both the production and changed version should match, except Covered Gross has a difference of 3, due to the Retirement Code change for employee Also, the STIP file (DD TFILE) produced during the Treasurer Run mode from both the runs of PPI730 program should match as well (Attachment E Verify Treasure File Run). Page 18

20 Attachment A EDB Selection Select Test Employees with 403(B) YTD Amounts From the EDB, select few employees with non-zero 403(b) Year-to-date amount. The SQL to find employees with 403(b) YTD amount is below: Query (RUNQDBL): SELECT EMPLOYEE_ID, GTN_AMT FROM PBQDA.PPPDBL WHERE GTN_IND = 'Y' AND GTN_NUMBER = '008' AND GTN_AMT > 0; Result: EMPLOYEE_ID GTN_AMT Page 19

21 Page 20

22 Attachment B PAR Employees Selection Select PAR Test Employees Select few employees with more than one PAR with a different Retirement Code produced during the current month. The SQL to find employees with more than one PAR with unique Retirement Code produced with a Pay Period End Date in the month of July 2017 is below: Query (RUNQEUD): SELECT EMPLOYEE_ID, RECORD_TYPE, PRI_GROSS_CTL, RET_PLAN_CODE FROM PBQDA.PPPEUD A WHERE PAY_CYCLE_END_DATE >= '07/01/2017' AND PAY_CYCLE_END_DATE <= '07/31/2017' AND A.EMPLOYEE_ID IN (SELECT B.EMPLOYEE_ID FROM PBQDA.PPPEUD B WHERE PAY_CYCLE_END_DATE >= '07/01/2017' AND PAY_CYCLE_END_DATE <= '07/31/2017' AND A.EMPLOYEE_ID = B.EMPLOYEE_ID AND A.RET_PLAN_CODE <> B.RET_PLAN_CODE) ORDER BY EMPLOYEE_ID; Result: EMPLOYEE_ID RECORD_TYPE PRI_GROSS_CTL RET_PLAN_CODE U U U U U U U U U N H H H N U U U U U Page 21

23 U U U U U N U U U U U U U U U H H U U N U N U U U U U U U U U U N U U N U U W W U U H Page 22

24 Attachment C Standard Mode PPI730 Run Verification of 403(b) Amount From the Attachment A query for the 403(b) amounts, choose few employees with their expected 403(b) amounts, as below: EMPLOYEE_ID GTN_AMT Verify that the 403(b) amounts from the production run (populated using PPPBLS) match with the changed PPI730 run (fetched from the XDSA Array), as below: Employee ID: GTN Amount: Before: Page 23

25 After: Employee ID: GTN Amount: Before: After: Page 24

26 Employee ID: GTN Amount: Before: After: Employee ID: GTN Amount: Before: After: Page 25

27 Employee ID: GTN Amount: Before: After: Page 26

28 Verification of UCRS Record per Retirement Code From the Attachment B query, which contains employees with more than one PAR with a different Retirement Code produced during the current month, choose a test employee, as below: EMPLOYEE_ID RECORD_TYPE PRI_GROSS_CTL RET_PLAN_CODE U U W In the UCRS record, for the above employee, verify that only one UCRS Record produced eventhough multiple PAR records are found in the production run, as below: Before: After: After the PPI730 change, each PAR produces an UCRS Record and so verify that total of 3 UCRS Records are produced for the test employee, as below: Page 27

29 Employee ID: Total Number of Detail Records: 11 For the test employee , Total of 11 Detail Records produced, out of which 3 are Service Credit Segment, 3 are Contribution Segment, and 5 are Tax Segment, as per the statistics below: Before: #Service Records: 3 Page 28

30 After: After the PPI730 change, 3 UCRS Recors are produced. verify that each UCRS Record has 1 Service Record and the details match the base version, as below: Page 29

31 Page 30

32 Before: #Contribution Records: 3 For the production run, SQL query RUNQGTNO is developed to fetch the Total Contribution Amounts for all the Plan Codes except Plan 21, using the PPPDRC PAR Deduction/Reduction/Contribution table. Verify the below contribution amount for each plan, other than 21, with the SQL Query Result of the RUNQGTNO Query. After: For the changed run, SQL query RUNQGTNN is developed to fetch the Total Contribution Amounts for all the Plan Codes except Plan 21, using the PPPDRC PAR Deduction/Reduction/Contribution table. Verify the below contribution amount for each plan, other than 21, with the SQL Query Result of the RUNQGTNN Query. For Plan 21, make sure that Total Plan 21 amount below is equal to the production run amount above of Employee: UCRS Record# 1 #Contribution Records: 1 Page 31

33 Employee: UCRS Record# 2 #Contribution Records: 2 Employee: UCRS Record# 3 #Contribution Records: 1 Page 32

34 Before: #Tax Records: 5 For the production run, SQL query RUNQTSPO is developed to fetch the Tax Segment Monthly Amounts for the Plan Codes 02 (Parking), 03 (Transit/Vanpool), and 04 (Health/Dental/Vision), using the PPPDRC (PAR Deduction / Reduction / Contribution) table. Verify the below Tax Segment amount for the 02, 03, and 04 plans, with the SQL Query Result of the RUNQTSPO Query. Also, SQL query RUNQTS01 is developed to fetch the Tax Segment YTD Amounts, from the EDB tables PPPPAY and PPPPCM, for the following Plan Codes: Plan Code Description (Current Year) YTD Total Gross (Prior Year) YTD Total Gross (Current Year) YTD FWT Gross (Prior Year) YTD FWT Gross Verify the below Tax Segment amount for the 00 and 01 plans, from the SQL Query Result of the RUNQTS01 Query. After: For the changed run, SQL query RUNQTSPN is developed to fetch the Tax Segment Monthly Amounts for the Plan Codes 02 (Parking), 03 (Transit/Vanpool), and 04 (Health/Dental/Vision), using the PPPDRC (PAR Deduction / Reduction / Contribution) table. Verify the below Tax Segment amount for the 02, 03, and 04 plans, with the SQL Query Result of the RUNQTSPN Query. Verify the below Tax Segment amount for the 00 and 01 plans, which is repeated in all the 3 UCRS Records for the employee , from the SQL Query Result of the RUNQTS01 Query. Page 33

35 Employee: UCRS Record# 1 #Tax Segment Records: 4 Employee: UCRS Record# 2 #Tax Segment Records: 5 Employee: UCRS Record# 3 #Tax Segment Records: 4 Page 34

36 The UCRS Detail Record details for more Test Employees, using before run, are below: These UCRS records have been matched against the changed program run as above for employee Employee ID: Total Number of Detail Records: 7 Before: #Service Records: 2 After: After the PPI730 change, 2 UCRS Records are produced and verify that each UCRS Record has 1 Service Record and the details match the base version (above). Page 35

37 Before: #Contribution Record: 1 After: Verify that the total contribution amount is for plan 95 matches, as above, and the split of amounts is from the SQL Query Result of the RUNQGTNN Query. EMPLOYEE_ID PRI_GROSS_CTL PLAN 95 3_ _ Before: #Tax Records: 4 After: Verify the below Tax Segment amount for the 00 and 01 plans, which is repeated in all the 2 UCRS Records for the employee , from the SQL Query Result of the RUNQTS01 Query EMPLOYEE_ID PLAN 00 (2017 YTD GRS) PLAN 00 (2016 YTD GRS) PLAN 01 (2017 FWT GRS) PLAN 01 (2016 FWT GRS) _ Page 36

38 Employee ID: Total Number of Detail Records: 15 Before: #Service Records: 3 After: After the PPI730 change, 3 UCRS Records are produced and verify that each UCRS Record has 1 Service Record and the details match the base version (above). Before: #Contribution Records: 7 Page 37

39 After: Verify the contribution amounts for each plan, with the SQL Query Result of the RUNQGTNN Query (plan 21 is split into 3 times ; which is total). EMPLOYEE_ID PRI_GROSS_CTL PLAN _ _ _ EMPLOYEE_ID PRI_GROSS_CTL PLAN 18 3_ EMPLOYEE_ID PRI_GROSS_CTL PLAN 29 3_ _ EMPLOYEE_ID PRI_GROSS_CTL PLAN 30 3_ EMPLOYEE_ID PRI_GROSS_CTL PLAN 93 46_ _ EMPLOYEE_ID PRI_GROSS_CTL PLAN 99 25_ _ Page 38

40 Before: #Tax Records: 5 After: Verify the below Tax Segment amount for the 00 and 01 plans, which is repeated in all the 3 UCRS Records for the employee , from the SQL Query Result of the RUNQTS01 Query EMPLOYEE_ID PLAN 00 (2017 YTD GRS) PLAN 00 (2016 YTD GRS) PLAN 01 (2017 FWT GRS) PLAN 01 (2016 FWT GRS) _ Verify that the split of the Tax Segment amount for the 04 plan, with the SQL Query Result of the RUNQTSPN Query. EMPLOYEE_ID PRI_GROSS_CTL T_PLAN 04 52_ Page 39

41 Attachment D PERS File Check Testing of PERS File Compare the PERS File produced in the Before Change run and After Change run. For the layout, use the PERS LABEL Record copybook in PAYBCC.TEST.COPYLIB(PERSLABL). In the PERS File, all the employee records should match for both the PERS Files produced during before and after run. However, it has the difference only in label creation date, as below: OLD PERS File: NEW PERS File: Page 40

42 Attachment E Verify Treasure File Run Testing of PPI730 in the Treasure File Run Compare the Treasury (TFILE) File produced in the Before Change run and After Change run. In the Treasury File, all the records should match for both the TFILE Files produced during before and after run. Before: After: Page 41

43 The file UCRS CONTROL FOR TREASURERS STIP (DD GRPA1) produced in both the production and changed version should match, except the Covered Gross Amount has a difference of 3, due to the Retirement Code change for employee , as below: Before: After: Page 42