common remitter guide for users and support - usg.edu · common remitter user guide © 2019 board...

Common Remitter User Guide

© 2019 Board of Regents of the University System of Georgia. All Rights Reserved. ‐ 1 ‐

CommonRemitterProcessingGuide

ForInstitutionalUsersandSupportPersonnel

Version 4 Last Updated: 7‐1‐2019



TABLEOFCONTENTSCOMMONREMITTERPROCESSING…………………………………………………………….…………………5

COMMON REMITTER FLOWCHART………………..………………………..………………………………………….....6 MENU VIEWS AND USER ROLES………………………..…………………………………..……………………………..7

COMMONREMITTERSETUP…………………………………………………………………………………………8

RETIREMENT SETUP…………………………………………………………………………………………………………8TSA PROVIDER SETUP………………………………………………………………………………………………………8 CUSTOM TRANSLATE VALUES……………………………………………………………………………………………..8 RET & TSA PROVIDER…………...…………………………………………………………………………..…………..11 WORK TABLE SETUP….…………………………………………………………...………………………………………11 ERROR CODES………………………………………………………………….……...…………………………………….11

RETIREMENT…………………………………………………………………..…………………………………………..12

RETIREMENT PROCESSES: RET PROVIDER WORK TBL LOAD…………………………………………………………………………………...13 RET ADD CONTRIBUTION ROW……………………………………………………………………………………...19

RET ADJUSTMENTS…………………………………………………………………………………………………….24 RET PROVIDER VALIDATION.............................................................................................................................33 ERS FORFEITED LEAVE BALANCES………………………………………………………………………………….39 RET PROVIDER FINAL EXTRACT……………………………………………………………………………………..43 CREATE RET ACCOUNTING ENTRIES……………………………………………………………………………….49 JOURNAL GENERATION………………………………………………………………………………………………....61 RET STAGING DELETE………………………………………………………………………………………………....63

RETIREMENTINQUIRY/REPORTS……………………………...……………………………………………69

RET WORK TABLE ERRORS RET WORK TABLE LOAD DETAILS RET PROVIDER SUMMARY WRK TBL RET PROVIDER VARIANCES RET PROVIDER VARIANCES DETAIL ERS SUMMARY REPORT TRS SUMMARY REPORT RET PROVIDER SUMMARY HIST TBL RET HISTORY TABLE LOAD DETAILS RETIREMENT CERTIFICATE REPORT RET PROVIDER SUMMARY HIST RET BENEFIT PLAN SUMMARY HIST RET TERMINATION REASON HIST



COLLEGEOFAGRICULTUREANDENVIRONMENTALSCIENCES(CAES)REPORTS..……70 CAES NO ABBR FOR EMP JOB DATA CAES NO ANNUAL_RT ON CWR JOB CAES WORK TABLE DETAILS CAES WORK TABLE ERRORS CAES WORK TABLE PERCENTAGES CAES HISTORY TABLE DETAILS CAES TRS SUMMARY REPORT

RETIREMENTORPPROCESSES……………………………………...…………………………………………74

ORP WORK TABLE LOAD……………………………………………………………………………………………..75 ORP Add Contribution…………………………………………………………………………………………….82 ORP ADJUSTMENT……………………………………………………………………………………………………...87 ORP VALIDATION/CHECK…………………………………………………………………………………………….96 CENSUS/CENSUS REMITTANCE…………………………………………………………………...……………..…102 ORP CREATE ACCOUNTING ENTRIES……………………………………………………………………………..108 JOURNAL GENERATION…………………………………………………………………………………….………....119

RETIREMENTORPINQUIRY/REPORTS…………………………………………………………………121

ORP WORK TABLE ERRORS ORP WORK TABLE EXTRACT DETAILS ORP PROVIDER SUMMARY WRK TBL ORP PROVIDER VARIANCES ORP VARIANCES DETAIL ORP SUMMARY HIST TBL ORP HISTORY TABLE DETAIL ORP MONTHLY PROVIDER SUMMARY

TSA(TAXSHELTEREDANNUITY)

TSAPROCESSES……………………………………………………………………………………………………...124

TSA WORK TBL LOAD……………………………………………………………………………………………….125 TSA ADJUSTMENTS…………………………………………………………………………………………………...132 TSA Add Contribution Row……………………………………………………………………………………140CREATE TSA ACCOUNTING ENTRIES…………………………………………………………………………...…146 JOURNAL GENERATION……………………………………………………………………………………………….156



TSAINQUIRY/REPORTS…………………………………………………………………………………………158

TSA DETAILS FOR ALL PLANS TSA WORK TABLE ERRORS TSA WORK NET POSITIVE DATA TSA WORK NET NEGATIVE DATA TSA WORK NET ZERO DATA TSA WORK NEGATIVE >= 10K DATA TSA VARIANCES WORK TABLE TSA VARIANCES DETAIL TSA HISTORY DETAILS TSA HISTORY NET POSITIVE DATA TSA HISTORY NET NEGATIVE DATA TSA HISTORY NET ZERO DATA TSA REMITTANCE

APPENDIXPREREQUISITES………………………………………………………………………………………………………...162 PROCESS TASK LIST………………………………………………………………………………………….……….162 RECONCILIATION………………………………………………………………………………………………………162 FIELD LISTING FOR ADD/CHANGE/DELETE PAGES……………………………………………………………163 ERROR, MESSAGE AND WARNING LISTING………………………………………………………………………165 COMMUNICATION……………………………………………………………………………………………………...167 ANNUAL UPDATES…………………………………………………………………………………………………….167 GENERAL LEDGER ACCOUNT AND FUND CODE LISTING………………………………………………………167



CommonRemitterProcessingCommon Remitter Process in HCM (Human Capital Management) is comprised of the ability to extract payroll deduction data for active employees with retirement and tax-sheltered savings plans, including the ability to add/adjust/delete those payroll deductions to correctly reflect provider contributions on a monthly or Payrun ID basis as deemed necessary depending upon the type of contribution. The Common Remitter module includes the ability to create the accounting entries required for recording and journal generation of valid contribution data via integration broker into the PeopleSoft Financials module.The Common Remitter final extract processes will be used to create outbound data files for demographic and contribution data which will be remitted to the approved Retirement and Savings Plan providers as approved by the Board of Regents of the University System of Georgia.



CommonRemitterFlowchart

One USG Payroll Confirmation

Work Table Load

Pre‐Reconcilement

Add Adjustment

Delete Completed

Final Extract

Post Reconcilement

Create Accounting Entries

Message Data to

PS Financials

Journal Generation

In PS Financials

Message Data to OneUSG

Final Reconcilement

OneUSG Connect Common Remitter Listserv

First Update Work Table Load/ Add/Adjust/Delete

OneUSg Connect Common Remitter Listserv

Second Update Final Extract/ Create Acctg Entries



MenuviewswithinCommonRemitter

The menu views show all available menu links. Note: Not all menu links are available for All Common Remitter user roles.

CommonRemitterUserRoles

Institutional User Role SSC Common Remitter Support Role ITS Common Remitter Support Role

Navigation:BORCustomizations,BORPayroll,CommonRemitter



CommonRemitterSetup

Overview: The CR Setup is used for maintenance of data fields used in Common Remitter processing. The CR Setup menus are available for the ITSSupport role only.

RetirementSetup – RET Liability – Acct/Fund Xref contains the Provider, Transaction Type, Benefit Plan, Account and Fund Code. These values are used to correctly identify the account/fund code used in journal generation by Provider. The current Provider list includes the following:

ERS – Employees Retirement System of Georgia TRS – Teachers Retirement System of Georgia FID – Fidelity Investments, ORP RET – TIAA Provider Processing ORP TIAA – Teachers Insurance and Annuity Association, ORP VALI – Variable Annuity Life Insurance Company, ORP

TSAProviderSetup – TSA Paygroup Xref contains the TSA Benefit Plan and BOR Valic Paygroup identifier for each institution, the TSA Liability – Acct/Fund Xref contains the Provider indicator assignment 1,2,3 etc. these are assigned for each Service Provider, Benefit Plan, Account and Fund Code. These values are used to correctly identify the account/fund code used in journal generation by Provider. The below are sample Service Provider list with numeric assignment, refer to BOR Policy for current providers:

1. VALIC – Variable Annuity Life Insurance Company 2. FIDINVT – Fidelity Investments 3. TIAA – Teachers Insurance and Annuity Association

CustomTranslateValues – pages where definitions for the following data fields are maintained

BOR_EMPL_STATUS A – ACTIVE R - RETIRED T – TERMINATED D - DECEASED

BOR_PAY_REASON - TRS 00 – REG PAY (00) 01 – CERT UPG (01) 02 – PROMTION (02) 03 – POS DWNGRD (03) 04 – ZEROSALCTR (04) 05 – UNPAIDSICK (05) 06 – 40+YRSRVCS (06) 07 – RET RETURN (07)



BOR_PAY_REASON - ERS 00 – REG PAY (00) 01 – LEAVE W/OUT PAY (01) 02 – MILITARY LEAVE W/OUT PAY (02) 03 – PAY DECREASE (03) 04 – PAY INCREASE (04) 05 – ONE TIME BONUS (05) 06 – 34 YEAR DISCONTINUE (06)

BOR_TERM_REASON – ERS 00 – CONTRIB GRP OR PENSION PLAN CHG 01 - RETIREMENT 02 - DEATH 03 - OTHER 04 – TRANSFER

BOR_TERM_REASON – TRS 01 – LEFT EMPLOYMENT 02 - RETIREMENT 03 - DEATH 04 - OTHER

CAES_BUSINESS_UNIT – unique coding for UGA CALENDAR_YEAR – maintained for each Provider EMPLOYER_CODE – unique institution code for ERS, TRS and TIAA Providers EMPL_CLASS – unique coding for UGA ERNCD INVESTMENT_OPT_BOR – internal coding for ORP processing

1. VALI 2. FID 3. TIAA 4. AXAEQUI 5. LINC

IRS_LIMIT – annual IRS limit IRS_LIMIT_CY_OR_FY – Provider Plan Year, calendar or fiscal JOB_CLASS – used to meet TRS reporting requirement

0 = 00 1 = 03 2 = 00 200X = 02 3 = 03 4 = 05 5 = 04



6 = 02 7 = 06 8 = 06 9 = 01

MAR_STATUS used to meet TIAA reporting requirement C = 0 D = 0 E = 0 H = 1 L = 0 M = 2 N = 0 S = 1 U = 0 W = 1

PAYRUN_ID – used to map ADP Payrun ID to HCM Payrun ID PAY_FREQUENCY – used to meet TIAA reporting requirement

A =1 B =6 D =8 M = 4 M10 = 4 Q = 3 S = 5 W = 7

PAY_FREQUENCY – used to meet ORP reporting requirement BIWEEKLY = B M10 = M MONTHLY = M WEEKLY = W

PAY_FREQUENCY – used to meet ERS reporting requirement A = 00 B = 02 H = 02 M = 00 S = 01 W = 03

PAY_FREQUENCY – used to meet TSA reporting requirement B = BW M = MO



PLAN – used to meet ERS reporting requirement GTDC = GDC NAR = ERS OAR = ERS

PLAN_CODE – maps Plan Types to Deduction Codes ORP = 01ORP GTDC = 01GDCP NAR = 01ERS OAR = 01ERSE OAR = 01ERSO

RUN_ID_BOR – used to map HCM Payrun ID to ADP Payrun ID SEX – used to meet TIAA reporting requirement

F = 2 M = 1 N U

SPCL_ACCUM – used for HCM reporting requirements RET&TSAProviderDefinition- used to maintain the Benefit Plan, Deduction Code and Plan Types for the work table load processes WorkTableSetup – used to maintain editable data fields in the work table ErrorCodes – used to maintain the Common Remitter error codes

001 = SSN is blank 002 = SSN is all 9s 003 = SSN has more than one EMPLID associated with it 004 = EE Contribution is zero 005 = ER contribution is zero 006 = ERSCON contribution is zero 007 = ER Deduction calculation is wrong 008 = EE Deduction calculation is wrong 009 = ERSCON calculation is wrong 010 = EE does not exist in personal or demo data 020 = IRS Limit Exceeded 030 = ER & EE Contributions <>0, but MTD = 0 031 = ER & EE Contribution = 0, but MTS <>0 032 = ER, EE, & MtD Contributions = 0 051 = Employee is not in an Active Status, and has no Status Change Date 061 = Negative Earnings reported, please verify and override if correct



Retirement

Overview: Once all payrolls for a given month have been confirmed in the HCM payroll module, data is processed in the Common Remitter Retirement menus for ERS and TRS. Within the Retirement menu are the processes where the work tables are populated by Shared Services Center (SSC) Common Remitter Team Members. Users work in concert with SSC Common Remitter Team Members as needed to complete additions of contribution data rows along with adjustments and deletes as necessary. Contribution correctness with regards to rate x reportable monthly gross is verified during the RET Provider Validation process. To fulfill the ERS requirement in reporting forfeited leave balances, users will enter the forfeited hours into the ERS Forfeited Leave page where the final extract picks up the hours for remittance to ERS. At the announced time, SSC Common Remitter Team Members will run the RET Provider Final Extract processes which will compile demographic and contribution data into file(s) as specified by each provider for remittance. Finally, when notified via email from OneUSG Connect Common Remitter listserv, users will complete the Create RET Accounting Entries process which will stage the data into the HR Accounting Line (HRAL) and Personal Services Board of Regents (PSB) tables where they will then be pushed via integration broker into PeopleSoft Financials for journal generation. After successful journal generation the Journal ID and Accounting dates are messaged back to HCM HRAL and PSB tables. The RET Staging Delete process is used to clear data from the HRAL and PSB tables in the event a user runs the Create RET Accounting Entries process with incorrect parameters, this self-service DBI is only available to ITS user roles.

Within the Retirement menus, are the Retirement Inquiry/Reports for work table and history data in summary and detail forms. These reports are used for pre and post reconcilement purposes after the work table load and after the final extracts have been completed respectively.

TheRetirementmenusareavailableasnoted: Processes: RET Provider Work Tbl Load – SSC and ITS Support user roles only RET Add Contribution Row – All Common Remitter user roles RET Adjustments – All Common Remitter user roles RET Provider Validation – All Common Remitter user roles ERS Forfeited Leave Balances – All Common Remitter user roles RET Provider Final Extract – SSC and ITS Support user roles only Create RET Accounting Entries – All Common Remitter user roles RET Staging Delete – ITS user roles only Inquiry/Reports – All Common Remitter user roles.



RetirementProviderWorkTblLoad Overview: The Retirement Provider Work Tbl Load process is used to load HCM Payroll ERS and TRS contribution data into a work table for validation, reconcilement and correction as deemed necessary. The Retirement Provider Work Tbl Load process name is BOR_PRWK. The retirement work table load for ERS and TRS is run once monthly. The Work Table is populated with the deductions taken for retirement during payroll processing. The Retirement Provider Work Tbl Load process is the initial step for the reporting of the monthly retirement benefit plans and is available only to SSC and ITS Support users.

Procedure The steps required to run the Retirement Work Table Load process are:

Step Action

1. Navigate to BOR Customizations > BOR Payroll > Common Remitter > Retirement > Retirement Processes > RET Provider Work Tbl Load

2. Click the AddaNewValue tab to create a new Run Control ID.

3. Enter "XXX_WRK_TBL_LOAD" in the RunControlID field. Where XXX represents either ERS or TRS.

The RET Provider Work Table Load process must be run for each retirement group – ERS and TRS individually. It is recommended that a separate Run Control ID be used for each Retirement Provider due to the difference in reporting data fields. Enter one of the following in the Run Control ID group box, then continue to add the others as the additional processes are run.



Step Action

4. Click the Add button.

The RET Provider – HCM Work Table Load run parameters page will open.

5. In the Processing Parameters group box Enter or Search for the Provider:

Reminder: The Provider is unique for each process.

Note: The accounting date will become the journal date in the ACTUALS ledger at the time this process is run. All benefit reconciliation processes should be completed, and journals posted before the accounting period is closed for efficient benefit reconciliation of GL accounts.



Step Action

6. Enter the Calendar Year:

7. Enter or Search for the Month:

Note: This is the reporting month, accounting entries will be created as of the last day of the month.

8. Enter or Search for the BusinessUnit:

9. To add or delete Business Units as needed -

Click the add or delete button.

10. Click the Save button.

Note: This will save the Run Control ID and parameters currently being used. When

the parameters change each month, you MUST the page again. Failure to do so will result in the prior saved parameters being used in processing.

11. Click the Run button.

Note: Only click the Run button once and wait until process runs to Success before running BOR_PRWK process again



Step Action

12. The ProcessSchedulerRequest page will open for review.

Note: The Select box must be checked for Work Table Load/Validation process to run successfully.

13. Click the OK button to continue processing or click the Cancelbutton to return to the previous menu.

14. Clicking the OK button to continue will return you to the RETWorkTableLoad run parameters page. Click on the Process Monitor link.

15. The Process Monitor page displays processing data and Status’ for each process.

Verify that the Run Status = Success and the Distribution Status = Posted Note: Status’ ≠ Success will require further analysis to determine issue(s).



Step Action

16. Click on the Process Name to retrieve the institutional summary that will be compared to the BOR_PY_RET_SUMMARY query for balancing.

17. Click on the xxxxx – BOR_PR_SHELL- Success hyper link in the Process Detail page.

This will open the Process Detail.

18. Click the link under Actions. There will be two files in the Files List:

Note: In the event the process runs to No Success, click the .stdout file for indicator of reason. Click the .txt file to review the contribution summary for the work table load. This is a consolidated report and will reflect contribution totals for the selected Provider and Business Units.



Step Action

19. Once notification has been received via the OneUSG Common Remitter listserv users should being review for correctness. Users should use reports/online queries found in the Retirement Inquiry menu for completing the pre-reconcilement process which should be done prior to the RET Final Extract process being run. Instructions for running the following are found in the Retirement Inquiry section of this guide: RET Work Table Errors RET Work Table Load Details RET Provider Summary Wrk Tbl RET Provider Variances RET Provider Variances Detail

20. Congratulations. RunningtheRETProviderHCMWorkTableLoad is complete. This topic demonstrates how to run the RET Provider HCM Work Table Load process. Below are the key concepts of this topic: - Only confirmed payrolls for the reporting month will be populated in the RET Provider HCM Work Table Load process. All Payrolls for the reporting month must be confirmed prior to running the process. - The RET Provider HCM Work Table Load process populates the BOR_CR_WRK_TBL table. - The process may be run individually or collectively for any number of Business Units. Typically, the process will be run for all participating business units at the same time.

21. UGAspecialprocess – CAES Work Table Load – must be run immediately following the RET Provider HCM Work Table Load process for TRS. This process will be run by the SSC Common Remitter Support team.



RETAddContributionRowOverview: The RET Add Contribution Row page will add a new contribution data row when a row was not created by the RET Work Table Load process. The added contribution data row will have a BOR_CR_ACTION_TYPE = A(Add) and BOR_CR_ROW_SOURCE = U (User). Coding of the action type and source are necessary for audit purposes. The RET Add Contribution Row cannot be used if an EMPLID with the target Provider already exists in the BOR_CR_WRK_TBL. The RET Add Contribution Row process is available to all Common Remitter users.

AdditionalInformation This process should only be used in the event that a paycheck was not included in the ORP Distribution process, when an intended check was not processed timely, or if enrollment was made in an incorrect Provider. Then Add Contribution Row functionality must be used to create a row for the targeted Provider. Contributions shown with the incorrect Provider must be Deleted using the RET Adjustment Page functionality to prevent submission to the Provider. Existing EMPLIDs in the BOR_CR_WRK_TBL requiring adjustment may not be updated using the Add Contribution Row functionality. Note:Addingacontributionrowmayclearapriormonthreconcilingitemormaycreateareconcilingitemforthereportingmonth. Users should exercise caution when determining the validity of using the Add Contribution Row functionality. Required Contribution Data is unique by Provider and not all fields that are available for edit are required for each provider. When the SAVE function is performed, if a required data field has been left blank, a warning message will be displayed stating that the blank field is required.

Note: Some fields may be displayed for reference only with no edit.



Procedure

The steps required to use the RET Add a Contribution Row are:

Step Action

1. Navigate to BOR Customizations > BOR Payroll > Common Remitter > Retirement > Retirement Processes > RET Add Contribution Row

2. The RET AddContributionRowparameterspage opens:

3. Enter or select the BusinessUnit from the drop-down search

4. Enter or select the Providerfrom the drop-down search

5. Enter or select the EMPLIDfrom the drop-down search

6. Click the ADD button to Add RET Contribution Row.



Step Action

7. The AddRETContributionRow page is displayed.

8. Populate row data as required dependent upon Provider requirements.

Note: The Adj Year and Adj Month fields should only be populated if adding a contribution row for a period prior to the reporting month. The Reporting Calendar Year and Month will be auto populated after Add.



Step Action

9. If the Save is attempted prior to completing ALL required fields, an error or warning message will be produced prompting for correction. Data resulting in a Message or Warning may be successfully saved but may affect outbound file or reporting data by leaving blank or mismatched values. Data resulting in an Error may not be saved until corrective action is taken. Note: Refer to the Error, Message and Warning listing if additional information is needed concerning the Message Severity and take corrective steps as required.

10. CAUTION: Checking the User Override button will prevent the validation routines

from being performed on the data row. If the User Override button is used in the event of a negative contribution entry, care should be taken to review the data for correctness.



Step Action

11. In the event additional data rows for prior periods are required for the newly added contribution row, scroll to the end of the data row.

Click the insert button

12. Populate row data as required dependent upon Provider requirements. Note: The Adj Year and Adj Month fields must be populated if adding additional contribution row(s) for a period prior to the reporting month.

13. In the event an additional row is added in error, the Delete button field will be opened after the insert, when more than one row is present.

Click the delete button as needed and proceed with the Savefunction that follows.

14. Click the Save button to Save the newly added RET HCM Contribution Row for further processing.

15. Congratulations. The AddRETContributionRowprocess is complete. This topic

demonstrates how to enter data using the Add RET Contribution Row process. Below are the key concepts of this topic: - The Add RET Contribution Row process will add a new contribution row when a row was not created by the Work Table Load Process. - Note about entering required data fields. - Error, Message and Warning list identification and descriptions. - Using the User Override functionality. - Deleting a data row added in error.



Step Action

16. UGAspecialprocess – CAES Add Contribution – contributions may be added after receiving notification that the CAES Work Table Load process for TRS has been completed. This process will be completed by the UGA institutional user.

RETAdjustments Overview: The RET Adjustments process is used to correct contribution data containing Validation Errors in the RET Provider Work Tbl Load Process or if prior month contribution data must be submitted to a provider. The RET Adjustments page may be used to completely delete a contribution row that should not be remitted to a provider. The RET Adjustments process is available to all Common Remitter users.

AdditionalInformation The RET Adjustments process should only be used in the event Validation Errors are present in the Work Table Load Process. Typical errors are a result of mismatches between the Monthly Gross Earnings, the Provider rate and the Employee/Employer contributions. These may occur as a result of a pay-line adjustment. The RET Adjustments functionality may be used to delete a contribution row for the targeted Provider. For example, if a participant is enrolled in the incorrect Benefit Plan and the Contributions shown with a particular Provider should not be remitted. The RET Provider Adjustments page may be used to enter or separate prior month adjustments. Notes: The reporting month Calendar Year and Month CD may not be used in the Adj. Year and Adj. Month fields. Required Contribution Data is unique by Provider and not all fields that are available for edit are required for each provider. When the SAVE function is performed, if a required data field has been left blank, a warning message will be displayed stating that the blank field is required.



Note: Some fields may be displayed for reference only with no edit option. The original Work Table Load data row for all contribution rows containing adjustments will be marked with a Deleted Action Type = D and maintained in the Work History table for Audit and reporting purposes. Adjustment rows will be marked with a Pending (P) Row Status until the RET Provider Validation process has been run. If the adjustment entered passes the validation process, the Row Status will be valid.

Procedure

The steps required to enter RET Adjustments are:

Step Action

1. Navigate to BOR Customizations > BOR Payroll > Common Remitter > Retirement > Retirement Processes > RET Adjustments

2. The RETAdjustmentssearch parameterspage opens:



Step Action

3. Enter or Search for the EMPLID or enter %WildCard to return all.

A partial EMPLID may be entered i.e. 003, click and all EMPLIDs

beginning with 003 will be returned. Enter the Business Unit and click and all EMPLIDs will be returned. Note: There are several ways to perform a search. Use the one most convenient for you.

4. Enter or Search for the Provider:


6. Enter or Search for the CalendarYear:


8. Enter or Search for the RowStatus or leave blank to return all results regardless

of status.

9. Search Criteria requires only one field = Business Unit, this will restrict EMPLIDs

being returned to be business unit specific.



Step Action

10. Once an EMPLID data row is selected the RETHCMAdjustments page is displayed.

11. Populate row data as required dependent upon Provider requirements. Note: The Adj Year and Adj Month fields may only be populated if adding a contribution row for a period prior to the reporting month.



Step Action

12. If the Save is attempted prior to completing ALL required fields a message, error or warning will be produced prompting for correction. Data resulting in a Message or Warning may be successfully saved but may affect outbound file or reporting data by leaving blank or mismatched values. Data resulting in an Error may not be saved until corrective action is taken. Note: refer to the Error, Message and Warning listing if additional information is needed concerning the Message Severity and take corrective steps as required.

13. CAUTION: Checking the User Override button will prevent the validation routines

from being performed on the data row. If the User Override button is used in the event of a negative contribution entry, care should be taken to review the data for correctness.



Step Action

14. In the event additional data rows for prior periods are required for the contribution row, scroll to the end of the data row.


15. Populate row data as required dependent upon Provider requirements. Note: the Adj Year and Adj Month fields must be populated if adding additional contribution row(s) for a period prior to the reporting month.


Click the delete button as needed, and proceed with the function that follows.



Step Action

17. In the event the entire contribution data row needs to be deleted from further

processing, click the button at the top right of the RET Provider Adjustment page.

18. A warning message will appear requesting confirmation of the Delete:



Step Action

19. Click the Yes button to return for further processing.

***Notice the Delete button is now grayed out and the adjustments group box cleared of data.

20. Click the Save button to Save the Deleted or Adjusted Contribution Row data for further processing.

21. If you have Deleted a contribution row in error, simply click the button, complete a search for the Deleted EMPLID and the delete row content will be repopulated for further processing.



Step Action

22. The adjusted contribution rows will show a ‘Pending Row Status’ after a Save until the RET Validation process has been run:

Notice that the Source is changed from System (Work Table Load) to User. This is to allow an Audit trail creation. Also note that the original data row has an Action Type = Delete, this is an Audit trail creation as well.

23. Congratulations. The RETAdjustmentsprocess is complete. This topic demonstrates how to enter RET Adjustments for data rows populated in the Work Table Load process. Below are the key concepts of this topic: - The RET Adjustments process is used to correct contribution data containing Validation Errors in the Work Table Load Process or if prior month contribution data must be submitted. - Required field check list. - Error, Message and Warning list identification and descriptions shown in the RET Add Contribution Row process. - Using the User Override functionality. - Deleting an adjusted data row added in error. - Deleting a contribution data row completely.

24. UGAspecialprocess – CAES Adjustment Contribution – contributions may be adjusted after receiving notification that the CAES Work Table Load process for TRS has been completed. This process will be completed by the UGA institutional user.



RETProviderValidation Overview: The RET Provider Validation process performs calculation routine validation for the reporting month for all RET Add Contribution Rows and RET Adjustments rows from the BOR_CR_WRK_TBL table. This process will ensure that the Monthly Gross Amount * the applicable Provider rate is equal to the Employee and Employer deductions and mark each row with a Valid Status. The RET Provider Validation process name is BOR_PR_CHECK. The RET Provider Validation process is available to all Common Remitter users.

AdditionalInformation Note: Data rows with the User Override check box checked will not be included in the RET Provider Validation process. The RET Provider Validation process may be run as many times as deemed necessary during the Add Contribution Row and RET Provider Adjustments processes to verify that rows are valid, and no further adjustments are required. The RET Provider Validation process must be run individually for each Retirement Provider Plan. The current Retirement Provider Plans are as follows:

ERS TRS

The Retirement Provider Plans are validated individually because different rates and rules vary dependent upon the plan selection.

Current Error Code Listing may be found in the RET Add Contribution Row process. Error codes may be present after the initial Work Table Load process has been run, or if an adjustment made on the RET Provider Adjustments page creates an error after the RET Provider Validation process is run. For error codes, refer to page 11 in this document.



Procedure In this topic, you will run the RET Provider Validation process for one or all Business Units dependent upon the User running the process. Institutional users may only run the process for themselves. SSC and ITS Support users may run for one or all Business Units.

Step Action

1. Navigate to BOR Customizations > BOR Payroll > Common Remitter > Retirement > Retirement Processes > RET Adjustments

2. The RETProviderValidationRun Controlpage opens:

3. Click the AddaNewValue tab.

4. Enter the appropriate RunControlID in the Run Control ID group box. Note:ThereshouldbeaRunControlIDforeachRetirementProviderPlanasfollows:

5. Click the ADD button to add the new Run Control ID.



Step Action

6. The RET Provider Validation run parameters page will open.


Reminder:thisprocessisrunindividuallybyRetirementProviderPlan

8. In the Processing Parameters group box Enter the CalendarYear:

9. In the Processing Parameters group box Enter or Search for the Month:


11. SSC will click the to insert additional rows for each Business Unit.

Note:THISDOESNOTAPPLYTOANINDIVIDUALBUSINESSUNIT.

12. Click the Save button to permanently save the Run Control ID.

13. Click the Run button to run the BOR_CR_CHECK process.



Step Action


15. Click the OK button to continue processing or click the Cancelbutton to return to the

previous menu.

16. Clicking the OK button to continue will return you to the RETProviderValidation run parameters page. Click on the Process Monitor link at the top of the RET Provider HCM Validation processing parameters page.



Step Action

17. The Process Monitor page displays processing data and Status for each process.

Verify that the Run Status = Success and the Distribution Status = Posted Note: The process will be in a Queued or Processing Status until the process is completed. Click the Refresh button to refresh the data until expected status is achieved. Status’ ≠ Success will require further analysis to determine cause of issue(s).

18. Navigate to the Retirement Inquiry menus and run the RET Work Table Errors report to verify that no errors remain. Instructions for running this report may be found in the Retirement Inquiry section of this guide.

19. After verification that no errors remain, users should use reports/online queries found in the Retirement Inquiry menu for completing another round of the pre-reconcilement process which should be done prior to the RET Final Extract process being run. Instructions for running the following are found in the Retirement Inquiry section of this guide: RET Work Table Errors RET Work Table Load Details RET Provider Summary Wrk Tbl RET Provider Variances RET Provider Variances Detail



Step Action

20. Congratulations. RunningtheRETProviderValidation is complete. This topic demonstrates how to run the RET Provider Validation process. Below are the key concepts of this topic: - The RET Provider Validation process performs calculation routine validation for the reporting month for all Added Contribution and RET Provider Adjustments rows from the BOR_CR_WRK_TBL table. - The process may be run individually or collectively for any number of Business Units. - The RET Provider Validation process must be run individually for each Retirement Provider Plan. - The RET Provider Validation process may be run as many times as deemed necessary during the Add Contribution Row and RET Provider Adjustments processes to verify that rows are valid, and no further adjustments are required.

21. UGAspecialprocess – CAES Validation – may be run at any time or as many times as needed during the CAES Add Contribution and CAES Adjustment Contribution processes and prior to the processing of the CAES Final File. This process will be completed by the UGA institutional user.



ERSForfeitedLeaveBalancesOverview: In the event a BOR institution hires a new employee that had previously been a participant in the Employees Retirement System of Georgia, ERS requires that all Sick, Annual and Forfeited Leave balances be remitted with the monthly contribution data files. Employees hired and were previous ERS participants should disclose to the institutional HCM division that they had been an ERS participant. The HCM department should receive a notice of any forfeited leave from the previous employer as these newly BOR institutional employees would continue to participate in ERS until retirement. Since the time and record keeping for these employees is not in the BOR HCM payroll system, the only way for BOR institutions to track the ERS participant forfeited leave is by manual user data input.

AdditionalInformation After hire, the monthly sick and annual leave balances that will be entered are contained in BOR_CR_ERS_VAC_AND_SICK_BAL query, ERS with VAC and Sick Bal. Note: Employees hired that were previous ERS participants should disclose to the institutional HCM division that they had been an ERS participant and the previous employer name and contact information. The HCM department should obtain a notice of any forfeited leave from the previous employer as these newly BOR institutional employees would continue to participate in ERS until retirement. The ERS Leave Maintenance page stores the amount of forfeited leave and is updated annually in January prior to the final extract processing. Current monthly balances for Sick and Annual Leave are not historically stored. Once the final extract has been run for the current processing month, the Sick Leave and Annual Leave fields are blanked with only the Forfeited Leave field remaining. The month code is advanced to the following month to ready the table for the next month processing. This is because the Forfeited Leave hours remain constant during the year or processed during retirement. Sick and Annual Leave balances are recorded in the BOR_CR_LVE_WRK table only until the ERS Final Extract has been run. Forfeited Leave balances remain until zeroed out by the institution during retirement or transfer to another institution or employer.



Procedure In this topic, institutional users will learn to enter Sick Leave, Annual Leave and Forfeited Leave for monthly ERS Reporting.

Step Action

1. Navigate to BOR Customizations > BOR Payroll > Common Remitter > Retirement > Retirement Processes > Forfeited Leave for ERS

2. The BOR_CR_ERS_LEAVEBusiness Unit searchpage opens:

3. Enter the institutional Business Unit to Find an Existing Value in the Search Criteria

group box.

If the institution has not been maintained previously, use the Add A New Value

to enter the business unit for the first time and click the button.

4.

Click the button.



Step Action

5. The ERS Leave Maintenance page will open.

This is the page where the Sick, Annual and Forfeited Leave are maintained. Once the final extract has been run, the values for Sick and Annual Leave will be blanked out so they can be entered with the new values each month. The Forfeited Leave is initially entered as a new hire to BOR but previous ERS participant is entered into the system. The Forfeited Leave is updated annually in January prior to the final extract being processed. The Forfeited Leave is only zeroed out when the employee transfers to another institution, is terminated or retired.

6. As previously noted, the Forfeited Leave is obtained by the HCM office during the hire process. Users maintaining the ERS Leave Maintenance page should receive a copy of the documentation to support the entry. Sick Leave and Annual Leave are obtained by running the BOR_CR_ERS_VAC_AND_SICK_BAL query, ERS with VAC and Sick Bal query. Navigation: Reporting Tools > Query > Query Manager > BOR_CR_ERS_VAC_AND_SICK_BAL, this query should be run after the accruals have been completed for the month and before the Common Remitter ERS Final Extract.

7. Enter values as shown in the below example and the page.



Step Action

8. Congratulations. MaintenanceoftheForfeitedLeaveforERS is complete. This topic demonstrates how to enter Sick Leave, Annual Leave and Forfeited Leave for ERS monthly reporting. Below are the key concepts of this topic: - The Forfeited Leave for ERS is a maintenance page where monthly and forfeited leave are entered. - The leave maintenance is entered by each business unit monthly after the Sick and Annual leave accruals are completed and prior to the ERS Final Extract completion. - The Forfeited Leave for any new hire/previous ERS participant may be entered at any time during the month but prior to the ERS Final Extract for the reporting period. - The Sick Leave and Annual Leave are blanked out after each ERS Final Extract process. -The amount of Forfeited Leave is updated annually in January prior to the final extract process.



RETProviderFinalExtractOverview: The RET Provider Final Extract process moves payroll data for the reporting month and participating providers from the BOR_CR_WRK_TBL table and populates the BOR_CR_WRK_HST table. The RET Provider Final Extract creates an output file used in remitting payroll and demographic data to the Providers. The RET Provider Final Extract process name is BOR_CR_EXT. Note: Types of output files created for remittance YYYYMMXXXX.trs YYYYMMAAA-AAAA.ERSGA Where: XXXX = TRS Employer ID AAA-AAAA = ERS Employer Code YYYY = Year MM = Month DD = Day The RET Provider Final Extract process is available to only SSC and ITS Support users.

AdditionalInformation Payroll deductions are summed and remitted on one line if the following conditions are the same:

Provider name Check Date

In the event of a negative amount with an alternate check date, multiple lines will be submitted for the same provider. The RET Provider Final Extract is run individually for each Provider. Outbound data files for submission will be created for each provider ERS and TRS.



ProcedureIn this topic, SSC Support users will run the RET Provider Final Extract process for one or all Business Units as needed.

Step Action

1.

Navigate to BOR Customizations > BOR Payroll > Common Remitter > Retirement > Retirement Processes > RET Provider Final Extract

2. The RETProviderFinalExtractRun Controlpage opens:


4. Enter the appropriate RunControlID in the Run Control ID group box. Note:ThereshouldbeaRunControlIDforeachRetirementProviderasfollows:




Step Action

6. The RET Provider Final Extract run parameters page will open.


Reminder:thisprocessisrunindividuallybyProvider

8. In the Processing Parameters group box Enter the CalendarYear:


10.

Click the to insert additional rows for each Business Unit.


12. Click the Run button to run the BOR_CR_EXT process.



Step Action



previous menu.

15. Clicking the OK button to continue will return you to the RETProviderFinalExtract

run parameters page, click on the Process Monitor link located at the top of the RET Provider – Final File Extract Processing Parameters page.



Step Action


Verify that the Run Status = Success and the Distribution Status = Posted Note: The process will be in a Queued or Processing Status until the process is completed. Click the Refresh button to refresh the data until expected status is achieved. Status’ ≠ Success will require further analysis to determine issue(s).

17. Once notification has been received via the OneUSG Common Remitter listserv, users should being review for correctness. Users should use reports/online queries found in the Retirement Inquiry menu for completing the final reconcilement process which should be done after the RET Final Extract process is completed. Instructions for running the following are found in the Retirement Inquiry section of this guide: RET Provider Summary Hist Tbl RET History Table Load Details Ret Provider Summary Hist RET Benefit Plan Summary Hist Note: Each of these reports are pulled from the BOR_CR_WRK_HST table and should contain the same totals. They are just created with different key criteria to meet various needs.



Step Action

18. Congratulations. RunningtheRETProviderFinalExtract is complete. This topic demonstrates how to run the RET Provider Final Extract process. Below are the key concepts of this topic: - The RET Provider Final Extract process populates the BOR_CR_WRK_HST table. - The process may be run individually or collectively for any number of Business Units. Typically, the process will be run for all participating business units at the same time. - The RET Provider Final Extract creates an output file used in remitting payroll and demographic data to each Retirement Provider.

19. UGAspecialprocess – CAES Final File – will be run after the CAES Add Contribution and CAES Adjustment Contribution have been completed. This process will be completed by the SSC Common Remitter team member.



CreateRETAccountingEntriesOverview: The Create RET Accounting Entries process extracts data from the BOR_CR_RET_HST table and places it in the HR_ACCTG_LINE (HRAL) and PERS_SERV_BOR (PSB) tables. The HR_ACCTG_LINE table is a temporary table used for the staging of data prior to general ledger journal generation for various processes. The PERS_SERV_BOR table is populated with the data rows to be used for queries and future enhancements as needed. Note: Only valid data, non-deleted rows are extracted for general ledger journal entry creation. Data rows containing an Error status or Deleted action will not be extracted to the HR_ACCTG_LINE or PERS_SERV_BOR tables. Data row status = ‘E’ error, are reconciling differences and may be from a prior reporting month or the current reporting month activity. Data row action types = ‘D’ delete, are original rows loaded by the work table load process and have been updated by the user. All data and row statuses may be identified in the RET history Details query located under History Table Reports. ProcessName: BOR_CC_R The HCM Common Remitter data staged in the HRAL table will be messaged via integration broker into the mirror table HRAL in PeopleSoft Financials for Journal Generation, the same way that HCM Payroll data is messaged. The Journal Generation process for the retirement contribution data will occur in PeopleSoft Financials. Once journal generation has been completed, the Journal ID and Journal Date will be updated and messaged back to the HCM HRAL and PSB tables, the same way that the Payroll Journal ID’s are messaged. Institutional users having the Common Remitter user role will be responsible for running the Create RET Accounting Entries process.

AdditionalInformation The RET Final Extract process must be completed successfully prior to running the Create RET Accounting Entries process. A *Cash/Clearing Account must be used in run parameter. The user may opt to post directly to the Cash (bank account) or an alternate Clearing Account, dependent upon their individual business practice. General Ledger entries will be summed by chart string. This results in one-line entry per provider for remittance amounts to the respective liability account.



CurrentlistingofparticipatingRETProviders: ERS – Employee’s Retirement System of Georgia TRS – Teacher’s Retirement System

Note:The *Calendar Year and *Month will auto populate the *Accounting Date with the last day of the processing *Month. The Business Unit may opt to post as of an alternate date in the following month, dependent upon their individual business practice.

The *Accounting Date determines the actual posting date, provided the accounting period is open. Using the auto populated date (month end) will relieve the liabilities as of the reporting month. For example: the reporting month = ‘05’ May, then the liability account(s) general ledger entries will be 05/31/XXXX.

***Reminder, the *Cash/Clearing Account entry will be posted with the same date. If a Cash - bank account code, i.e. 118100 is used, the result will be a reconciling item on the bank reconciliation. This occurs because of the month end posting date verses the actual cash movement date. To avoid creating a reconciling item on the bank account, a Clearing Account i.e. 229900 may be used. If a Clearing Account is used, a manual journal entry to move funds from Cash to the Clearing account must be made at a later date to clear the entries.

Procedure In this topic, you will run the Create RET Accounting Entries process for your Business Unit.

Step Action

1. Navigate to BOR Customizations > BOR Payroll > Common Remitter > Retirement > Retirement Processes > Create RET Accounting Entries



Step Action

2. The CreateRETAccountingEntriesRun Controlpage opens:


4. Enter CREATE_RET_ACCTG_ENTRIES in the Run Control ID group box.


6. The Create RET Accounting Entries run parameters page will open.

Note: Processing Parameters vary dependent upon the Provider selected for Processing. Refer to the individual Step for Provider specifics. Users may add a different run Control ID for ERS and TRS, if the same Run Control ID is used remember the SAVE function must be used each time the page is updated, else the last saved parameters will be used instead.



7. Processing Parameters for Providers = ERS

In the Processing Parameters group box, enter or select from the drop down menus the following values:

*Business Unit *Provider *Calendar Year *Month *Accounting Date *Cash/Clearing Account

Note: The *Calendar Year and *Month will auto populate the *Accounting Date with the last day of the processing *Month. The Accounting Date determines the posting date of the Journal. VerifyAccountingDate! Fiscal Year and Period will be automatically populated based on the Accounting Date. The inclusion of journal entries for ERS adjustments is completed by populating the adjustment amounts as needed for the following fields: EE Adj Amount = adjustment amount for total employee contributions ER Adj Amount = adjustment amount for total employer contributions GTDC EE Adj Amount = adjustment amount for total employee GTDC contributions



Step Action

Note: Adjustments typically reduce the Provider invoice amount. Entering the adjustment amounts in the Processing Parameters when running the Create RET Accounting Entries will reduce the total sum amounts posted by account to general ledger. This will keep the Invoiced amount and the amount posted to G/L in sync by Provider. ***For Audit purposes users must retain a copy of the ERS provided adjustment document.



8. Processing Parameters for Provider = TRS

In the Processing Parameters group box enter or select from the drop down menus the following values:

*Business Unit *Provider *Calendar Year *Month *Accounting Date *Cash/Clearing Account

Note: The *Calendar Year and *Month will auto populate the *Accounting Date with the last day of the processing *Month. The Accounting Date determines the posting date of the Journal. VerifyAccountingDate! Fiscal Year and Period will be automatically populated based on the Accounting Date. The inclusion of journal entries for TRS adjustments is completed by populating the adjustment amounts as needed for the following fields: EE Adj Amount = adjustment amount for total employee contributions ER Adj Amount = adjustment amount for total employer contributions Note: Adjustments typically reduce the Provider invoice amount. Entering the adjustment amounts in the Processing Parameters when running the Create RET



Step Action

Accounting Entries will reduce the total sum amounts posted by account to general ledger. This will keep the Invoiced amount and the amount posted to G/L in sync by Provider. ***For Audit purposes users must retain a copy of the TRS provided adjustment document.

9. Click the Save button to permanently save the Run Control ID and associated processing parameters.

10. Click the Run button to run the BOR_CR_RETAC process.



previous menu.

13. Clicking the OK button to continue will return you to the CreateRETAccounting

Entries run parameters page, click on the Process Monitor link.



Step Action

14. The Process Monitor page displays processing data and status for each process.

Verify that the Run Status = Success and the Distribution Status = Posted Note: Status’ ≠ Success will require further analysis to determine issue(s). The Run Status = Success indicates that data has been successfully placed in the HR_ACCTG_LINE table and is awaiting journal generation using the Generate RET Journal Entries process. The Run Status = No Success may indicate that the Accounting entries have already been created for pay run id: The Calendar Year and Month. The Create RET Accounting Entries may only be run once in a 24-hour period. It is possible to run the again after 24 hours but will require that a ticket be submitted to ITS to have the Staging Tables cleared of the duplicate data.

15. To view message status’, click the link in the process monitor for the process instance that ran to No Success.

16. This will open the Process Detail page.



Step Action

17. Click the link under the Process name to view the Process Detail information.

18. Click the message link showing No Success on the Process Detail page:



Step Action

19. An additional Process Detail page will open.



Step Action

20. Click on the Message Log link. The reason for No Success will be shown.

21. If a different message other than ‘RET Accounting entries process can only be run once

daily per provider’ is received, submit a ticket to ITS for assistance.

22. Click to return to the process detail page, click to return to

the first Process Detail page, click again to return to the Process List page. If preferred, you may use the X at the top right corner to return.

23. If the Run and DistributionStatus = Success, proceed with the Generate Journal Entries process in PeopleSoft Financials.



Step Action

24. Congratulations. RunningtheCreateRETAccountingEntries is complete. This topic demonstrates how to run the Create RET Accounting Entries process. Below are the key concepts of this topic: - The Create RET Accounting Entries process populates the HRAL table with data rows ready for final processing by running the Generate Journal Entries in PeopleSoft Financials. - The Create RET Accounting Entries process populates the PERS_SERV_BOR table with the data rows to be used for queries and future enhancements as needed. - Only rows with an Action Type ≠ D and Row Status = V will be included in the Create RET Accounting Entries process. All Action Types and Row Status’ are retained in the Work History table for Audit purposes. - Processing Parameters vary dependent upon Provider processing requirements.



JournalGenerationOverview: The journal generation process will be run in the PeopleSoft Financials General Ledger module. Navigation: General Ledger > Journals > Subsystem Journals > Generate Journals The below snapshot shows normal processing parameters for Common Remitter entries journal generation.

Select the correct Accounting Definition Name and Template for journal generating the target provider data. AccountingDefinitionName/Description JournalTemplate PYRLRETDEF Retirement Accounting Entries PAYROLL_RT (Use when journal generating ERS, TRS and ORP) PYRLTSADEF TSA Accounting Entries PAYROLL_TS (Use when journal generating TSA) Use the From Date Option = Specify Date and To Date Option = Specify Date when journal generating. The specify date is the accounting date or check date; these represent the same date. Institutional users designated for Generating Journals will be responsible for running Journal Generate process in PeopleSoft Financials.



AdditionalInformation The Create RET/TSA Accounting Entries process must be completed in HCM Common Remitter and the HRAL data must be messaged from HCM to PS Financials prior to Generating Journals. Note: Entries having the same Accounting Definition Name, Template and Specify Date will be combined in a single journal, unless the journal generation process is run after each Create RET Accounting Entries process. Review the process log for the FS_JGEN_BOR (Generate Journals) to reveal the Journal ID. Once journal generation has been completed the Journal ID and Journal Date will be updated and messaged back to the HCM HRAL and PSB tables, the same way that the Payroll Journal ID’s are messaged.



RETStagingDeleteOverview: The RET Staging Delete process is a self-service DBI that only ITS Support users may run. The RET Staging Delete process will clear the HRAL and PSB table data to allow the Create RET/TSA Accounting Entries process to be rerun. Occasionally there are problems with the data staged in the HRAL and PSB tables caused by running the Create RET/TSA Accounting Entries processes multiple times or with the incorrect run parameters. Normally when the incorrect run parameters are used, it is caused by the institutional user not having Saved the updated parameters prior to running the process. AdditionalInformationInstitutional users are required to submit a ticket to ITS requesting that the staging tables HRAL and PSB be cleared of data staged incorrectly. ITS Support users must run the RET Staging Delete process in both HCM and PS Financials. This is required to clear both systems of the data staged incorrectly.

To obtain the data to be entered in the Process Parameters, the ITS Support User must use the TOAD query tool. Sample selects: select * from ps_hr_acctg_line where run_dt = '14-SEP-2018' and business_unit_gl = '98000' --and appl_jrnl_id = 'PAYROLL_TS' and appl_jrnl_id = 'PAYROLL_RT' select * from ps_pers_serv_bor where business_unit = '98000' and run_dt = '14-SEP-2018' --and journal_id like 'TS%' --and trans_type_bor in ('TEC','TEC') and journal_id like 'RT%' and trans_type_bor in ('CEE','CER','LEE','LER')



Procedure In this topic, ITS Support users will run the RET Staging Delete process for Business Units who have submitted a ticket making the request.

Step Action

1. Navigate to BOR Customizations > BOR Payroll > Common Remitter > Retirement > Retirement Processes > RET Staging Delete

2. The RETStagingTableDeleteRun Controlpage opens:



Step Action


4. Enter a RunControlID in the Run Control ID group box.


6. The RET Staging Delete run parameters page will open.



Step Action

7. In the Processing Parameters group box Enter or Search for the BusinessUnit:

8. In the Processing Parameters group box Enter the TransactionID:

Transaction ID’s are found by running the select using TOAD for the PSB table. Make a note of each transaction ID that was staged in error.

9. In the Processing Parameters group box Enter or Search for the RunDate:

The run date is found by running the select using TOAD for both the HRAL and PSB table.

10. In the Processing Parameters group box Enter or Search for the JournalTemplate:

The journal template is either: PAYROLL_RT or PAYROLL_TS, dependent upon the target date to be deleted from the HRAL and PSB tables.

11. In the Processing Parameters group box Enter or Search for the JournalID:

The Journal ID is found by running the select using TOAD for both the HRAL and PSB table. If journal generation has not been completed leave blank.


13. Click the Run button to run the BOR_CR_DBI process.



Step Action



previous menu.

16. Clicking the OK button to continue will return you to the Removestagingdatafrom

HR_ACCTG_LINEandPERS_SERV_BORrun parameters page, click on the Process Monitor link located at the top of the RET Provider – Final File Extract Processing Parameters page.



Step Action


Verify that the Run Status = Success and the Distribution Status = Posted Note: The process will be in a Queued or Processing Status until the process is completed. Click the Refresh button to refresh the data until expected status is achieved. Status’ ≠ Success will require further analysis to determine issue(s).

18. Verify that the data has been successfully cleared by rerunning the select statements using the TOAD query tool.

19. Congratulations. RunningtheRETStagingDeleteprocess is complete. This topic demonstrates how to run the RET Staging Delete process. Below are the key concepts of this topic: - The RET Staging Delete process clears data from the HRAL and PSB tables for the targeted data as requested by an institution via ticket. - The process may only be run for a single business unit and transaction at the time. - The RET Staging Delete process must be run in both HCM and PS Financials.



RetirementInquiry/Reports

The Retirement Inquiry menu contains three separate kinds of reports. The reports are divided by the BOR_CR_WRK_TBL (work table), BOR_CR_WRK_HST (history table) and CAES tables (for UGA use only).

Retirement (ERS/TRS) online queries and reports are found at the following navigation: BOR Customizations > BOR Payroll > Common Remitter > Retirement > Retirement Inquiry

After the ERS/TRS work table load process has been run, the following online queries are available for use in validating the Common Remitter data with the Payroll deduction data. The work table reports are used in validation and pre-reconcilement.

RETWorkTableErrors – this report will return data if there are any errors present in the work table. Error examples: missing demographic data, SSN is blank, EE Contribution is zero, etc. – refer to the Error Code listing for a complete list (page 11 of this document).

RETWorkTableLoadDetails – this report will return all data loaded into the work table by the work table load process. The total data should match the total payroll deductions for the reporting period.

RETProviderSummaryWrkTbl – this report will provide work table data in summary for by Provider and Benefit Plan

RETProviderVariances – this report will identify instances where there are variances between the work table load data and the payroll deduction data by payroll deduction code.

RETProviderVariancesDetail – this report will provide the variance detail which includes amounts, deduction codes and transaction types.

After the ERS/TRS final extract processes have been run the data is moved from the work table into the history table where the following reports become available. Note: the history table reports may be rerun for any month. The history table reports are used in validation and post-reconcilement.

ERSSummaryReport – this .pdf report provides data in summary form which is in turn loaded into the ERS website for monthly reporting. The report includes contribution



summary and employee counts for each provider, ERS Old, ERS New, Georgia Defined Contribution plans.

TRSSummaryReport – this .pdf report provides data in summary form which is in turn loaded into the TRS website for monthly reporting. The report includes contribution summary and employee counts.

RETProviderSummaryHistTbl–this report provides history data in summary form by provider and benefit plan and includes the data row source for reference.

RETHistoryTableLoadDetails– this report provides detailed history data by EMPLID by provider and benefit plan. Results returned may be filtered by using various run criteria, else all data in the history table will be returned.

RetirementCertificateReport– this .pdf report provides contribution data by EMPLID and month. The report is run for a single EMPLID at the time and is used for certification reporting.

RETProviderSummaryHist– this report will provide history table data in summary for by Provider and Benefit Plan. The report includes only valid non-deleted data rows.

RETBenefitPlanSummaryHist– this report will provide history table data in summary form Benefit Plan. The report includes only valid non-deleted data rows.

RETTerminationReasonHist– this report will provide a listing of EMPLIDs and termination reasons for the reporting period which are being provided to the provider.

The College of Agriculture and Environmental Sciences (CAES) reports are specifically for University of Georgia (UGA) use.

CAES–NoABBRforEMPJobData – this report identifies EMPLIDs that do not have an annual base benefits rate (ABBR).

CAES–NoAnnual_RtonCWRJob – this report identifies EMPLIDs that do not have an annual rate on the Contingent Worker Record.

CAES–WorkTableDetails - this report will return all data loaded into the work table by the work table load process. The total data should match the total payroll deductions for the reporting period.

CAES–WorkTableErrors – this report will return data if there are any errors present in the work table. Error examples: missing demographic data, SSN is blank, EE Contribution is zero, etc. – refer to the Error Code listing for a complete list (page 11 in this document). CAES–WorkTablePercentages – this report returns data which includes the percentages, ABBR and annual rates for the CAES employees



CAESHistoryTableDetails – this report provides detailed history data by EMPLID by provider and benefit plan. Results returned may be filtered by using various run criteria, else all data in the history table will be returned. CAESTRSSummary Report – this .pdf report provides data for the CAES employees in summary form which is in turn loaded into the TRS website for monthly reporting. The report includes contribution summary and employee counts.



Procedure The steps required to run any of the online queries/report are the same. The run parameters are the only variant.

Step Action

1. Navigate to BOR Customizations > BOR Payroll > Common Remitter > Retirement > Retirement Inquiry > Select the target report name

2. The onlinequery/reportpage opens for the selected online query/report:

3. Enter prompted values or the wild card (%) may be used to return desired results. If

the magnifying glass is present, click for a drop-down search selection. Prompt Fields: Business Unit – institutional five-digit business unit EMPLID – unique identifier for each employee Calendar Year – four-digit year i.e. 2018 Month – enter the two-digit month code or use down arrow for search Provider – system assigned abbreviation used for each provider Source – identifies the source of the data row, drop down search to see complete name Action Type – identifies the action for any given row Row Status – identifies the row status for any given row Payroll Deduction Code – the deduction code used during payroll processing

4. Some reports are in .pdf form due to the complex algorithms of the data being requested. The Processing Parameters work the same as the prompts for the online queries/reports. Simply enter the parameters for the requested .pdf report, click the Save, Run, OK, Process Monitor, Details, View Log/Trace and lastly click the .PDF file in the File List to open the processed report.

5. All of the online queries and reports may be downloaded for permanent file or further analysis.



Step Action

6. Congratulations. Runningonlinequeries/reports is complete. This topic describes how to run the online queries/reports. Below are the key concepts of this topic: - The work table reports return data contained only in the work table prior to final extraction. The work table reports are used for pre-reconcilement and verification. - The history table reports return data contained only in the history table after the final extraction. The history table reports are used for post-reconcilement and verification. - Brief descriptions of each online query/report. - Descriptions of prompt values used in the online queries/reports. - Online queries/reports may be downloaded or saved for future use and analysis.



RetirementORPProcesses

Overview: The Retirement ORP Processes and Retirement ORP Inquiry menus are located within the Retirement menu. The Retirement ORP Processes are run after each payroll has been confirmed and the ORP Distribution process has been completed in the HCM Payroll module. Following payroll confirmation in the HCM payroll module, data is processed in the Common Remitter Retirement menus for Fidelity (FID), TIAA-Cref (TIAA) and VALIC (VALI) ORP providers and remitted in a single remitter processor - TIAA. The process to populate the ORP Work Tables are run by the Shared Services Center (SSC) Common Remitter Team Members. Once notification has been received via the OneUSG Connect Common Remitter listserv, Institutional Users will work in concert with the SSC Common Remitter Team Members to begin the process of performing a pre-reconcilement and complete additions of contribution data rows, adjustments and deletes as necessary. Contribution correctness with regards to rate x reportable monthly gross is verified during the ORP Validation/Check process. At the announced time SSC Common Remitter Team Members will run the ORP Provider Final Extract processes which will compile demographic and contribution data into file(s) as specified by each provider for remittance to each provider. Finally, when notified via email from OneUSG Connect Common Remitter listserv, users will complete the ORP Create Accounting Entries process which will stage the data into the HRAL and PSB tables where they will then be pushed via integration broker into PeopleSoft Financials for journal generation. After successful journal generation, the Journal ID and Accounting dates are messaged back to HCM HRAL and PSB tables. In the event a user runs the ORP Create Accounting Entries process with incorrect parameters or multiple times, The RET Staging Delete process is used to clear data from the HRAL and PSB tables, this self-service DBI is only available to ITS user roles.

The Retirement menu also contains the Retirement ORP Inquiry/Reports for work table and history data in both summary and detail forms. These reports are used for reconcilement purposes after the work table load and after the final extracts have been completed.

The Retirement ORP Processes menus are available as noted: Processes: Census/Census Remittance – SSC and ITS Support user roles only ORP Work Tbl Load – SSC and ITS Support user roles only ORP Add Contribution Row – All Common Remitter user roles ORP Adjustments – All Common Remitter user roles ORP Validation/Check – All Common Remitter user roles ORP Provider Final Extract – SSC and ITS Support user roles only ORP Create RET Accounting Entries – All Common Remitter user roles Inquiry/Reports – All Common Remitter user roles.



ORPWorkTableLoad Overview: The ORP Work Table Load process is used to load HCM Payroll ORP contribution data into a work table for validation, reconcilement and correction as deemed necessary. The ORP Work Table Load process name is BOR_PROR. The ORP Work Table Load process is run by Payrun ID. The ORP Work Table Load process is the initial step for the reporting of the ORP retirement benefit plans and is available only to SSC and ITS Support users. The following diagram highlights the business process flow for the ORP Work Table Load process:

Procedure The steps required to run the ORP Work Table Load process are:

Step Action

1. Navigate to BOR Customizations > BOR Payroll > Common Remitter > Retirement > Retirement ORP Processes > ORP Work Table Load


3. Enter "ORP_WT_LOAD" in the RunControlID field.

The ORP Work Table Load process is run by Payrun ID.




Step Action

Step Action

5. The HCM-ORP Provider – Work Table Load (by Payrun_ID) parameters page will open.


Note: The Provider for the work table load process will use ORP only, for all other processes and inquiries the specific Provider will be used.



Step Action

7. In the Processing Parameters group box Enter or Search for the PayrunID:

Note: The Pay Calendar for each Payrun ID contain the dates that are used in the ORP Create Accounting Entries process for journal generation.





Note: This will save the Run Control ID and parameters currently being used. When

the parameters change each Payrun ID you MUST the page again. Failuretodosowillresultinthepriorsavedparametersbeingusedinprocessing.


Note: OnlyclicktheRunbuttononceandwaituntilprocessrunstoSuccessbeforerunningBOR_PRWKprocessagain.



Step Action




14. Clicking the OK button to continue will return you to the HCM‐ORPProvider‐WorkTableLoad(byPayrun_ID) run parameters page. Click on the Process Monitor link.

15. The Process Monitor page displays processing data and Status’s for each process.




Step Action

16. Click on the Process Name to retrieve the institutional summary that will be compared to the BOR_CR_ORP_PROV_SUM_WRK_TBL – ORP Provider Summary Wrk Tbl query for balancing.

17. Click on the xxxxx – BOR_PR_OSHEL- Success hyper link in the Process Detail page.

This will open the Process Detail.



Step Action

18. Click the link under Actions. There will be two files in the Files List:

Note: In the event the process runs to No Success, click the .stdout file for indicator of reason. Click the .txt file to review the contribution summary for the work table load. This is a consolidated report and will reflect contribution totals for the selected Provider and Business Units. Grand Totals are located at the end of the institutional summaries.



Step Action

19. Once notification has been received via the OneUSG Common Remitter listserv, users may begin review for correctness. Users should use reports/online queries found in the Retirement ORP Inquiry menu for completing the pre-reconcilement process which should be done prior to the ORP Provider Final Extract process being run. Instructions for running the following are found in the Retirement ORP Inquiry section of this guide: ORP Work Table Errors ORP Work Table Extract Details ORP Provider Summary Wrk Tbl ORP Provider Variances ORP Provider Variances

20. Congratulations. RunningtheORPWorkTableLoad is complete. This topic demonstrates how to run the ORP Work Table Load process. Below are the key concepts of this topic: - Only confirmed payrolls for the Payrun ID will be populated in the ORP Work Table Load process. The target Payrun ID must be confirmed prior to running the ORP Work Table Load process. - The ORP Work Table Load process populates the BOR_CR_WRK_TBL table. - The process may be run individually or collectively for any number of Business Units. Typically, the process will be run for all participating business units at the same time.



ORPAddContributionRow Overview: The ORP Add Contribution Row page will add a new contribution data row when a row was not created by the ORP Work Table Load process. The added contribution data row will have a BOR_CR_ACTION_TYPE = A (Add) and BOR_CR_ROW_SOURCE = U (User). Coding of the action type and source are necessary for audit purposes. The RET Add Contribution Row cannot be used if an EMPLID with the target Provider already exists in the BOR_CR_WRK_TBL. The RET Add Contribution Row process is available to all Common Remitter users.

AdditionalInformation This process should only be used in the event that a paycheck was not included in the ORP Distribution process, when an intended check was not processed timely, or if enrollment was made in an incorrect Provider. Then ORP Add Contribution functionality must be used to create a row for the targeted Provider. Contributions shown with the incorrect Provider must be Deleted using the ORP Adjustment Page functionality to prevent submission to the Provider. Existing EMPLIDs in the BOR_CR_WRK_TBL requiring adjustment may not be updated using the Add Contribution Row functionality. Note: Adding a contribution may clear a prior month reconciling item or may create a reconciling item for the reporting month. Users should exercise caution when determining the validity of using the ORP Add Contribution functionality. Required Contribution Data is unique by Provider and not all fields that are available for edit are required for each provider. When the SAVE function is performed if a required data field has been left blank, a warning message will be displayed stating that the blank field is required.




Procedure The steps required to use the RET Add a Contribution Row are:

Step Action

1. Navigate to BOR Customizations > BOR Payroll > Common Remitter > Retirement > Retirement ORP Processes > ORP Add Contribution

2. The ORPAddContributionRowparameterspage opens:


4. Enter or select the PayrunIDfrom the drop-down search


6. Enter or select the EmplIDfrom the drop-down search



Step Action

7. Click the ADD button to open the ORP Add Contribution page.

8. The AddRETContributionRow page is displayed.

9. Populate row data as required dependent upon Provider requirements.

Note: The Adj Year and Adj Month fields should only be populated if adding a contribution row for a period prior to the reporting month. The Reporting Calendar Year and Month will be auto populated after Add.

10. If the Save is attempted prior to completing ALL required fields a message, error or warning will be produced prompting for correction. Data resulting in a Message or Warning may be successfully saved but may affect outbound file or reporting data by leaving blank or mismatched values. Data resulting in an Error may not be saved until corrective action is taken. Note: Refer to the Error, Message and Warning listing if additional information is needed concerning the Message Severity and take corrective steps as required.



Step Action

11. CAUTION: Checking the User Override button will prevent the validation routines from being performed on the data row. If the User Override button is used in the event of a negative contribution entry, care should be taken to review the data for correctness.

12. In the event additional data rows for prior periods are required for the newly added

contribution row, scroll to the end of the data row.




Click the delete button as needed and proceed with the Savefunction that follows.

15. Click the Save button to Save the newly Added ORP Contribution Row for further processing.



Step Action

16. Congratulations. The ORPAddContributionprocess is complete. This topic demonstrates how to enter data using the ORP Add Contribution process. Below are the key concepts of this topic: - The ORP Add Contribution process will add a new contribution row when a row was not created by the ORP Work Table Load Process. - Note about entering required data fields. - Error, Message and Warning list identification and descriptions. - Using the User Override functionality. - Deleting a data row added in error.



ORPAdjustmentOverview: The ORP Adjustment process is used to correct contribution data containing Validation Errors in the ORP Work Table Load Process or if prior month contribution data must be submitted to a provider. The ORP Adjustment page may be used to completed delete a contribution that should not be remitted to a provider. The ORP Adjustment process is available to all Common Remitter users.

AdditionalInformation The ORP Adjustment process should only be used in the event Validation Errors are present in the ORP Work Table Load Process. Typical errors are a result of mismatches between the Monthly Gross Earnings x the Provider rate and the Employee/Employer contributions. These may occur as a result of a payline adjustment. The ORP Adjustment functionality may be used to delete a contribution row for the targeted Provider. For example, if a participant is enrolled in the incorrect Benefit Plan and the Contributions shown with a particular Provider should not be remitted. The ORP Provider Adjustment page may be used to enter or separate prior month adjustments. Notes: The reporting month Calendar Year and Month CD may not be used in the Adj. Year and Adj. Month fields. Required Contribution Data is unique by Provider and not all fields that are available for edit are required for each provider. When the SAVE function is performed if a required data field has been left blank a warning message will be displayed stating that the blank field is required.

Some fields may be displayed for reference only with no edit. The original Work Table Load data row for all contribution rows containing adjustments will be marked with a Deleted Action Type = D and maintained in the Work History table for Audit and reporting purposes. Adjustment rows will be marked with a Pending (P) Row Status until the RET Provider Validation process has been run. If the adjustment entered passes the validation process, the Row Status will be valid.



Procedure

The steps required to enter RET Adjustments are:

Step Action

1. Navigate to BOR Customizations > BOR Payroll > Common Remitter > Retirement > Retirement ORP Processes > ORP Adjustment

2. The ORPAdjustmentsearch parameterspage opens:





Step Action

5. Enter or Search for the PayrunID:




7. Enter or Search for the CalendarYear:


9. Enter or Search for the RowStatus or leave blank to return all results regardless of status.

10. Search Criteria requires only one field = Business Unit. This will restrict EMPLIDs being returned to be business unit specific.



Step Action

11. Once an EMPLID, data row is selected, the ORPProviderAdjustments page is displayed.

12. Populate row data as required dependent upon Provider requirements. Note: The Adj Year and Adj Month fields may only be populated if adding a contribution row for a period prior to the reporting month.



Step Action

13. If the Save is attempted prior to completing ALL required fields, a message, error or warning will be produced prompting for correction. Data resulting in a Message or Warning may be successfully saved but may affect outbound file or reporting data by leaving blank or mismatched values. Data resulting in an Error may not be saved until corrective action is taken. Note: Refer to the Error, Message and Warning listing if additional information is needed concerning the Message Severity and take corrective steps as required.

14. CAUTION checking the User Override button will prevent the validation routines from

being performed on the data row. If the User Override button is used in the event of a negative contribution entry, care should be taken to review the data for correctness.



Step Action




17. In the event an additional row is added in error, the Delete button field will be opened after the insert when more than one row is present.

Click the delete button as needed and proceed with the function that follows.



Step Action


processing, click the button at the top right of the ORP Provider Adjustments page.




Step Action




22.

If you have Deleted a contribution row in error, simply click the button, complete search for the Deleted EMPLID and the delete row content will be repopulated for further processing.



Step Action

23. The adjusted contribution rows will show a Pending Row Status after Save until the ORP Validation/Check process has been run:

Notice that the Source is changed from System (Work Table Load) to User. This is to allow an Audit trail creation. Also, note that the original data row has an Action Type = Delete; this is an Audit trail creation as well.

24. Congratulations. ORPAdjustmentprocess is complete. This topic demonstrates how to enter ORP Adjustment for data rows populated in the Work Table Load process. Below are the key concepts of this topic: - The ORP Adjustment process is used to correct contribution data containing Validation Errors in the Work Table Load Process or if prior month contribution data must be submitted or perform Deletes for contributions that should not be submitted. - Required field check list. - Error, Message and Warning list identification and descriptions shown in the ORP Add Contribution Row process. - Using the User Override functionality. - Deleting an adjusted data row added in error. - Deleting a contribution data row completely.



ORPValidation/Check Overview: The ORP Validation/Check process performs calculation routine validation for the Payrun ID in process for all ORP Add Contribution and ORP Adjustment rows from the BOR_CR_OWRK_TBL table. This process will ensure that the Gross Amount * the applicable Provider rate is equal to the Employee and Employer deductions and mark each row with a Valid Status. The ORP Validation/Check process name is BOR_PR_OCHCK. The ORP Validation/Check process is available to all Common Remitter users.

AdditionalInformation Note: Data rows with the User Override check box checked will not be included in the ORP Validation/Check process. The ORP Validation/Check process may be run as many times as deemed necessary during the ORP Add Contribution and ORP Adjustment processes to verify that rows are valid, and no further adjustments are required. The ORP Validation/Check process is run for a specific Payrun ID and includes all Providers. The current ORP Provider Plans are as follows:

FID TIAA VALI

Current Error Code Listing may be found in the ORP Add Contribution process. Error codes may be present after the initial ORP Work Table Load process has been run, or if an adjustment made on the ORP Adjustments page creates an error after the ORP Validation/Check process has been run. Refer to page 11 in this document for error code listings.



Procedure In this section, you will run the ORP Validation/Check process for one or all Business Units dependent upon the User running the process. Institutional users may only run the process for themselves, SSC and ITS Support users may run for one or all Business Units.

Step Action

1. Navigate to BOR Customizations > BOR Payroll > Common Remitter > Retirement > Retirement ORP Processes ORP Validation/Check

2. The ORPValidation/Check Run Controlpage opens:


4. Enter the appropriate RunControlID in the Run Control ID group box.



Step Action


6. The ORPValidation/Check run parameters page will open.


Note:Provider=ORPwillruntheprocessforallproviders.

8. In the Processing Parameters group box Enter the PayrunID:





Step Action

11. SSC will click the to insert additional rows for each Business Unit. Note:THISDOESNOTAPPLYTOANINDIVIDUALBUSINESSUNIT


13. Click the Run button to run the BOR_CR_CHECK process.



previous menu.

16. Clicking the OK button to continue will return you to the HCMORPProvider–

Validation/Check run parameters page. Click on the Process Monitor link at the top of the HCM ORP Provider – Validation/Check processing parameters page.



Step Action


Verify that the Run Status = Success and the Distribution Status = Posted Note: The process will be in a Queued or Processing Status until the process is completed. Click the Refresh button to refresh the data until expected status is achieved. Status’ ≠ Success will require further analysis to determine cause of issue(s).

18. Navigate to the Retirement ORP Inquiry menus and run the ORP Work Table Errors report to verify that no errors remain. Instructions for running this report may be found in the Retirement ORP Inquiry section of this guide.

19. After verification that no errors remain, users should use reports/online queries found in the Retirement ORP Inquiry menu for completing another round of the pre-reconcilement process which should be done prior to the ORP Provider Final Extract process being run. Instructions for running the following are found in the Retirement ORP Inquiry section of this guide: ORP Work Table Errors ORP Work Table Extract Details ORP Provider Summary Wrk Tbl ORP Provider Variances ORP Variances Detail



Step Action

20. Congratulations. Running theORPValidation/Check is complete. This topic demonstrates how to run the ORP Validation/Check process. Below are the key concepts of this topic: - The ORP Validation/Check process performs calculation routine validation for the specified Payrun ID for all Added Contribution and ORP Adjustment rows from the BOR_CR_OWRK_TBL table. - The process may be run individually or collectively for any number of Business Units. - The ORP Validation/Check process may only be run for the specified Payrun ID. - The ORP Validation/Check process may be run as many times as deemed necessary during the ORP Add Contribution and ORP Adjustment processes to verify that rows are valid, and no further adjustments are required.



Census/CensusRemittanceOverview:The Census/Census Remittance processes are used to provide indicative and contribution data. The Census/Census Remittance processes consolidate both ORP and TSA into a single remittance process. The TIAA Census Daily Outbound process is a batch process and remits indicative data to TIAA. The TIAA Census Remittance process moves payroll data for the target Pay Run ID from the BOR_CR_OWRK_TBL and BOR_CR_WRK_TSA tables and populates the BOR_ORP_WRK_HST and BOR_CR_TSA_HST tables respectively. The TIAA Census Remittance process creates an output file used in remitting payroll and demographic data to the Providers. The TIAA Census Remittance process name is BOR_CENSUS_R.

TIAA Census Daily Outbound – daily file run to submit indicative data to Provider. The TIAA Census Daily Outbound process will be automatically run by batch job.

TIAA Census Remittance – final extract file that combines TSA and ORP contributions into a single data file for remittance to Provider. The TIAA Census Remittance process will be run by SSC Common Remitter Team.

Note: Types of output files created for remittance

AE_BOR_CENSUS_R_NNNNNN.stdout CR_001222_100075_100075_MONTH_YYMMDD_NNNNNN.txt CR_ERROR_MONTH_YYMMDD_NNNNNN.csv CR_LOG_PPPP_YYMMDD_NNNNNN.txt

Where: NNNNNN = process ID MM = Month DD = Day PPPP = Payrun ID The Census/Census Remittance processes are available to only SSC and ITS Support users.

AdditionalInformation Payroll deductions are summed and remitted on one line if the following conditions are the same:

Provider name Check Date

In the event of a negative amount with an alternate check date, multiple lines will be submitted for the same provider. The TIAA Census Remittance is run for a specified Payrun ID and Provider. Outbound data files for submission will be created for a single provider processor TIAA.



Procedure The steps required to run the TIAA Census Remittance process are:

Step Action

1. Navigate to BOR Customizations > BOR Payroll > Common Remitter > Retirement > Retirement ORP Processes > Census/Census Remittance > TIAA Census Remittance


3. Enter "TIAA_CENSUS_REMITTANCE" in the Run Control ID field.




Step Action

5. The TIAA Census Remittance – oad (by Payrun_ID) parameters page will open.

6. In the Processing Parameters group box Enter or Search for the Payrun ID:

Note: The Pay Calendar for each Payrun ID contain the dates that are used in the ORP Create Accounting Entries process for journal generation.


Note: This will save the Run Control ID and parameters currently being used. Each time the Payrun

ID is changed you MUST the page again. Failure to do so may result in the prior saved parameters being used in processing.


Note: Only click the Run button once and wait until process runs to Success.



Step Action

9. The Process Scheduler Request page will open for review.

Note: The Select box must be checked for the BOR_CENSUS_R process to run successfully.

10. Click the OK button to continue processing or click the Cancel button to return to the TIAA Census Remittance page.

11. Clicking the OK button to continue will return you to the TIAA Census Remittance run parameters page. Click on the Process Monitor link.

12. The Process Monitor page displays processing data and Status’s for each process.




Step Action

13. Click on the Details hyperlink to review the Process Details



14. Click the link under Actions. There will be four files in the Files List:

Notes:

In the event the process runs to No Success, click the .stdout file for indicator of reason. The CR_001222_100075_100075_MONTH_190618_084554.txt, is the Provider remittance

file. You should not open the file unless instructed to do so as the file may become corrupted.

The CR_ERROR_MONTH_190618_084554.csv file contains data rows having errors. Click the CR_LOG_97M1_190618_084607 .txt file to review the contribution summary for

the work table load. This is a consolidated report and will reflect contribution totals for each Business Unit by Benefit Plan. Grand Totals are located at the end of the institutional summaries.



Step Action

15. The CR_001222_100075_100075_MONTH_190618_084554.txt file will be pushed to the SSFTP server for remittance processing to the Provider.

16. Congratulations. Running TIAA Census Remittance process is complete. This topic demonstrates how to run the TIAA Census Remittance process. Below are the key concepts of this topic: - Only confirmed payrolls for the Payrun ID will be included in the remittance file. The target Payrun ID must be confirmed prior to running the ORP Work Table Load process. - Errors exceptions in the remittance file are reflected in the CR_ERROR_MONTH_190618_084554.csv file - The CR_LOG_XXXX_YYMMDD_nnnnnn.txt file contains contribution summaries by business unit and benefit plan.



ORPCreateAccountingEntriesOverview: The ORP Create Accounting Entries process extracts data from the BOR_ORP_WRK_HST table and places it in the HR_ACCTG_LINE (HRAL) and PERS_SERV_BOR (PSB) tables. The HR_ACCTG_LINE table is a temporary table used for the staging of data prior to general ledger journal generation for various processes. The PERS_SERV_BOR table is populated with the data rows to be used for queries and future enhancements as needed. Note: Only valid data, non-deleted rows are extracted for general ledger journal entry creation. Data rows containing an Error status or Deleted action will not be extracted to the HR_ACCTG_LINE or PERS_SERV_BOR tables. Data row status = ‘E’ error, are reconciling differences and may be from a prior reporting month or the current reporting month activity. Data row action types = ‘D’ delete, are original rows loaded by the work table load process and have been updated by the user. All data and row statuses may be identified in the ORP History Table Detail query located under Retirement ORP Inquiry Reports. ProcessName: BOR_CC_O The HCM Common Remitter data staged in the HRAL table will be messaged via integration broker into the mirror table HRAL in PeopleSoft Financials for Journal Generation, the same way that HCM Payroll data is messaged. The Journal Generation process for the retirement contribution data will occur in PeopleSoft Financials. Once journal generation has been completed, the Journal ID and Journal Date will be updated and messaged back to the HCM HRAL and PSB tables, the same way that the Payroll Journal ID’s are messaged. Institutional users having the Common Remitter user role will be responsible for running the ORP Create Accounting Entries process.

AdditionalInformation The ORP Final Extract process must be completed successfully prior to running the ORP Create Accounting Entries process. A *Cash/Clearing Account must be used in run parameter. The user may opt to post directly to the Cash (bank account) or an alternate Clearing Account, dependent upon their individual business practice. General Ledger entries will be summed by chart string. This results in one-line entry per chartstring for remittance amounts to the respective liability account.



CurrentlistingofparticipatingORPProvidersprocessedbyTIAA‐Cref: FID – Fidelity Investments, ORP TIAA – Teachers Insurance and Annuity Association, ORP VALI – Variable Annuity Life Insurance Company, ORP

Note:The *Calendar Year, *Month, Accounting Date, Fiscal Year and Period will be auto populated based on the Payrun ID data. Remember that the check date is the date the liability is incurred and will be the accounting date as well. The Business Unit may opt to post as of an alternate date in the following month, dependent upon their individual business practice.



Procedure In this topic, you will run the Create ORP Accounting Entries process for your Business Unit.

Step Action

1. Navigate to BOR Customizations > BOR Payroll > Common Remitter > Retirement > Retirement ORP Processes > ORP Create Accounting Entries

2. The CreateRETAccountingEntriesRun Controlpage opens:


4. Enter CREATE_RET_ACCTG_ENTRIES in the Run Control ID group box.




Step Action

6. The ORP Create Accounting Entries run parameters page will open. The ORP Create Accounting Entries process is run once per Payrun ID cycle. Note:theSAVEfunctionmustbeusedeachtimethepageisupdated,orelsethelastsavedparameterswillbeusedinstead.

7. Processing Parameters:

In the Processing Parameters group box enter or select from the drop-down menus the following values:

*Business Unit *Provider = RET *Payrun ID *Cash/Clearing Account

Note: The Calendar Year, Month, Accounting Date, Fiscal Year and Period will auto populate based on the Pay Calendar of the target Payrun ID.



Step Action


9. Click the Run button to run the Create ORP Acct Entries – OBR_CC_O process.



previous menu.

12. Clicking the OK button to continue will return you to the CreateORPbyPayrun_ID

AccountingEntries run parameters page, click on the Process Monitor link.



Step Action


Verify that the Run Status = Success and the Distribution Status = Posted Note: Status’ ≠ Success will require further analysis to determine issue(s). The Run Status = Success indicates that data has been successfully placed in the HR_ACCTG_LINE table and is awaiting journal generation using the Generate RET Journal Entries process. The Run Status = No Success may indicate that the Accounting entries have already been created for pay run id: the Calendar Year and Month.

The ORP Create Accounting Entries may only be run once in a 24-hour period. It is possible to run them again after 24 hours but will require that a ticket be submitted to mailto:[email protected] to have the Staging Tables cleared of the duplicate data.

14. To view message status, click the link in the process monitor for the process instance that ran to No Success.



Step Action

15. This will open the Process Detail page.

16. Click the message link showing No Success on the Process Detail page:



Step Action




Step Action

18. Click on the Message Log link the reason for No Success will be shown.

19. If a different message other than RET Accounting entries process can only be run once

daily per provider is received submit a ticket to [email protected] for assistance.

20. Click to return to the process detail page. Click to return to

the first Process Detail page. Click again to return to the Process List page. If preferred, you may use the X at the top right corner to return.




Step Action

22. Congratulations. RunningtheORPCreateAccountingEntries is complete. This topic demonstrates how to run the ORP Create Accounting Entries process. Below are the key concepts of this topic: - The ORP Create Accounting Entries process populates the HRAL table with data rows ready for final processing by running the Generate Journal Entries in PeopleSoft Financials. - The ORP Create Accounting Entries process populates the PERS_SERV_BOR table with the data rows to be used for queries and future enhancements as needed. - Only rows with an Action Type ≠ D and Row Status = V will be included in the Create RET Accounting Entries process. All Action Types and Row Status’ are retained in the Work History table for Audit purposes. - The ORP Create Accounting Entries process is run once for Provider = RET per Payrun ID cycle.




Select the correct Accounting Definition Name and Template for journal generating the target provider data. AccountingDefinitionName/Description JournalTemplate PYRLRETDEF Retirement Accounting Entries PAYROLL_RT (Use when journal generating ERS, TRS and ORP) PYRLTSADEF TSA Accounting Entries PAYROLL_TS (Use when journal generating TSA) Use the From Date Option = Specify Date and To Date Option = Specify Date when journal generating. The specify date is the accounting date or check date, these represent the same date. Institutional users designated for Generating Journals will be responsible for running Journal Generate process in PeopleSoft Financials.



AdditionalInformation The ORP Create Accounting Entries process must be completed in HCM Common Remitter and the HRAL data must be messaged from HCM to PS Financials prior to Generating Journals. Note: Entries having the same Accounting Definition Name, Template and Specify Date will be combined in a single journal, unless the journal generation process is run after each Create RET Accounting Entries process. Review the process log for the FS_JGEN_BOR (Generate Journals) to reveal the Journal ID. Once journal generation has been completed the Journal ID and Journal Date will be updated and messaged back to the HCM HRAL and PSB tables, the same way that the Payroll Journal IDs are messaged.



RetirementORPInquiryThe Retirement ORP Inquiry menu contains two kinds of reports. The reports are divided by the BOR_CR_OWRK_TBL (work table), BOR_CR_ORP_WRK_HST (history table).

Retirement ORP (FID/TIAA/VALI) online queries/reports are found at the following navigation: BOR Customizations > BOR Payroll > Common Remitter > Retirement > Retirement ORP Inquiry

After the ORP work table load process has been run the following online queries are available for use in validating the Common Remitter data with the Payroll deduction data. The work table reports are used in validation and pre-reconcilement.

ORPWorkTableErrors – this report will return data if there are any errors present in the work table. Error examples: missing demographic data, SSN is blank, EE Contribution is zero, etc. – refer to the Error Code listing for a complete list (page 11 of this document).

ORPWorkTableExtractDetails – this report will return all data loaded into the work table by the work table load process. The total data should match the total payroll deductions for the reporting period.

ORPProviderSummaryWrkTbl – this report will provide work table data in summary form by Provider = RET and Benefit Plan

ORPProviderVariances – this report will identify instances where there are variances between the work table load data and the payroll deduction data by payroll deduction code.

ORPVariancesDetail – this report will provide the variance detail which includes amounts, deduction codes and transaction types.

After the ORP Provider final extract processes have been run the data is moved from the work table into the history table where the following reports become available. Note: The history table reports may be rerun for any month. The history table reports are used in validation and post-reconcilement.

ORPSummaryHistTbl–this report provides history data in summary form by benefit plan and includes the data row source for reference.

ORPHistoryTableDetail– this report provides detailed history data by EMPLID and benefit plan. Results returned may be filtered by using various run criteria, else all data in the history table will be returned.

RetirementCertificateReport– this .pdf report provides contribution data by EMPLID and month. The report is run for a single EMPLID at the time and is used for certification reporting.

ORPMonthlyProviderSummary– this report will provide history table data in summary for Provider = RET for the selected month. The report sums all Payrun IDs with a check date in the target month. The report includes only valid non-deleted data rows.




Step Action

1. Navigate to BOR Customizations > BOR Payroll > Common Remitter > Retirement > Retirement ORP Inquiry > Select the target report name



the magnifying glass is present, click for a drop-down search selection. Prompt Fields: Business Unit – institutional five-digit business unit EMPLID – unique identifier for each employee Payrun ID – unique four-digit Payroll Payrun ID Year – four-digit year i.e. 2018 Month – enter the two-digit month code or use down arrow for search Provider – RET Source – identifies the source of the data row, drop down search to see complete name Action Type – identifies the action for any given row Row Status – identifies the row status for any given row Payroll Deduction Code – the deduction code used during payroll processing




Step Action

5. Congratulations. RunningRetirementORPInquiryonlinequeries/reports are complete. This topic describes how to run the online queries/reports. Below are the key concepts of this topic: - The work table reports return data contained only in the work table prior to final extraction. The work table reports are used for pre-reconcilement and verification. - The history table reports return data contained only in the history table after the final extraction. The history table reports are used for post-reconcilement and verification. - Brief descriptions of each online query/report. - Descriptions of prompt values used in the online queries/reports. - Online queries/reports may be downloaded or saved for future use and analysis.



TaxShelteredAnnuity(TSA)Processes

Overview: TSA contribution data is remitted each time a payroll is confirmed by Payrun ID. The TSA Work Table Load process pulls payroll deductions for a confirmed payroll’s specified Payrun ID and participating providers and populates the BOR_CR_WRK_TSA table. Once a payroll for a specified Payrun ID has been confirmed in the HCM payroll module data, the payroll deduction data is loaded during the TSA Work Table Load process processed in the Common Remitter Retirement menus for FID, TIAA and VALI. Within the TSA menu are the processes where the work tables are populated by Shared Services Center (SSC) Common Remitter Team Members. Users work in concert with SSC Common Remitter Team Members as needed to complete additions of contribution data rows along with adjustments and deletes as necessary. TSA contribution amounts are not validated since the contribution is for specified amounts and are not subject to calculation routine for correctness. At the announced time SSC Common Remitter Team Members will run the TSA Final Extract processes which will compile demographic and contribution data into file(s) as specified by each provider for remittance. Finally, when notified via email from OneUSG Connect Common Remitter listserv, users will complete the Create TSA Accounting Entries process which will stage the data into the HR Accounting Line (HRAL) and Personal Services Board of Regents (PSB) tables where they will then be pushed via integration broker into PeopleSoft Financials for journal generation. After successful journal generation the Journal ID and Accounting dates are messaged back to HCM HRAL and PSB tables.

The TSA menu also contain the TSA Inquiry Reports for work table and history data in both summary and detail forms. These reports are used for reconcilement purposes after the work table load and after the final extracts have been completed respectively.

The TSA menus are available as noted: Processes: TSAWorkTableLoad – SSC and ITS Support user roles only TSAAdjustments – All Common Remitter user roles TSAAddContributionRow – All Common Remitter user roles TSAFinalExtract – SSC and ITS Support user roles only CreateTSAAccountingEntries – All Common Remitter user roles



TSAWorkTableLoad

Overview:This topic demonstrates how to run the TSA Work Table Load process. The TSA Work Table Load process pulls payroll data for a confirmed payroll’s specified Payrun ID and participating providers and populates the BOR_CR_WRK_TSA table.

AdditionalInformation Demographic and enrollment data must be present to all inclusion of payroll contributions in the Common Remitter processes.

In this topic, you will run the TSA Work Table Load process for any one or all Business Units.

1. Navigate to BOR Customizations > BOR Payroll > Common Remitter > TSA > TSA Processes > TSA Work Table Load

2. Find an existing value or click the AddaNewValue tab to create a new Run Control ID.



3. . Enter "TSA_WRK_TBL_LOAD" in the RunControlID field.


5. The TSA HCM Work Table Load parameters page will open.

6. In the Processing Parameters group box Enter or Search for the PayrunID:

Note: The Pay Calendar for each Payrun ID contain the dates that are used in the TSA Create Accounting Entries process for journal generation.







Note: this will save the Run Control ID and parameters currently being used. When the

parameters change each Payrun ID you MUST the page again. Failure to do so will result in the prior saved parameters being used in processing.


Note: you must only click the Run button once and wait until process runs to Success before running BOR_PRWK_TSA process again.






13. Clicking OK button to continue will return you to the TSAHCMWorkTableLoadrun

parameters page. Click on the Process Monitor link.





15. Click on the Details link to review the Process Detail page.

16. Click the link under Actions. There will be two files in the Files List: On the View Log/Trace link to retrieve the CR_PR_USG_WRK_YYYYMMDD_PPPP.txt file which contains the TSA Summary by institution. This summary will be used by SSC Common Remitter Team to verify contribution amounts to the HCM payroll data.

YYYY = Calendar Year MM = Month lD = Day PPPP = Payrun ID Note: In the event the process runs to No Success click the .stdout file for indicator of reason. This is a consolidated report and will reflect contribution totals for the selected Provider and Business Units. Grand Totals are located at the end of the institutional summaries.



17. Once notification has been received via the OneUSG Common Remitter listserv users may begin review contributions for correctness. Users should use reports/online queries found in the TSA Inquiry menu for completing the pre-reconcilement process which should be done prior to the TSA Final Extract process being run. Instructions for running the following are found in the TSA Inquiry section of this guide: TSA Details for all plans TSA Work Table Errors TSA Work Net Positive Data TSA Work Net Negative Data TSA Work Net Zero Data TSA Work Negative >= 10K Data TSA Variances Work Table TSA Variances Detail

18. Congratulations. RunningtheTSAWorkTableLoad is complete. This topic demonstrates how to run the TSA Work Table Load process. Below are the key concepts of this topic: - Only confirmed payrolls for the Payrun ID will be populated in the TSA Work Table Load process. The target Payrun ID must be confirmed prior to running the TSA Work Table Load process. - The TSA Work Table Load process populates the BOR_CR_WRK_TSA table. - The process may be run individually or collectively for any number of Business Units. Typically, the process will be run for all participating business units at the same time.



TSAAdjustmentsOverview: The TSA Adjustments process is used to correct contribution data containing Validation Errors in the TSA Work Table Load Process or if prior month contribution data must be submitted to a provider. The TSA Adjustments page may be used to delete a contribution that should not be remitted to a provider. The TSA Adjustment process is available to all Common Remitter users.

AdditionalInformation The TSA Adjustments process should be used in the event Validation Errors are present in the TSA Work Table Load Process. Typical errors are a result of missing demographic data (personal or enrollment) or an incorrect benefit begin date. The TSA Adjustments functionality may be used to delete a contribution row for an EMPLID and targeted Provider. For example, if a participant is enrolled in the incorrect Benefit Plan and the Contributions are shown with an incorrect Provider and should not be remitted. The TSA Provider Adjustments page may be used to enter or separate prior month adjustments. Using prior month periods for entry is for institutional use only, the provider receives summed values for a reporting period. For example, during August an EMPLID has a contribution of 100.00 and the institutional user enters a prior month contribution of 100.00, the provider will receive a single contribution amount equal to 200.00 for the month of August. Notes: The reporting month Calendar Year and Month CD may not be used in the Adj. Year and Adj. Month fields. Required Contribution Data is unique by Provider and not all fields that are available for edit are required for each provider. When the SAVE function is performed if a required data field has been left blank a warning message will be displayed stating that the blank field is required.

Some fields may be displayed for reference only with no edit. The original Work Table Load data row for all contribution rows containing adjustments will be marked with a Deleted Action Type = D and maintained in the Work History table for Audit and reporting purposes. TSA Adjustment rows do not have a validation process. This is because no calculations are required to be a valid contribution row.



Procedure The steps required to enter TSA Adjustments are:

Step Action

1. Navigate to BOR Customizations > BOR Payroll > Common Remitter > TSA > TSA Processes > TSA Adjustment

2. The TSAAdjustmentssearch parameterspage opens:

Note: Search Criteria only requires the Business Unit to perform a search but entering an EMPLID will narrow the search results to the targeted EMPLID and help avoid making an adjustment on an incorrect EMPLID.


4. Enter or Search for the PayrunID:



Step Action





7. Enter or Search for the RowStatus:

8. Once an EMPLID data row is selected, the TSAHCMAdjustments page is displayed.



Step Action

9. Populate row data as required. Note: The Adj Year and Adj Month fields should only be populated if adding a contribution row for a period prior to the reporting month. Note: If additional contributions are due from a prior period, you may opt to add to the current contribution row. Either process is acceptable. Vendors only look for the total amount of contribution when received, not internal processing notes.


11. CAUTION: When checking the User Override button care should be taken to review the data for correctness. Any changes made will be remitted to the provider. The only time User Override should be used in the TSA Adjustments page would be to remit negative amounts.



Step Action



13. Populate row data as required dependent upon Provider requirements. Note: The Adj Year and Adj Month fields should be populated if adding additional contribution row(s) for a period prior to the reporting month.



Step Action

14. In the event an additional row is added in error, the Delete button field will be opened after the insert when more than one row is present.

Click the delete button as needed and proceed with the function that follows.


processing, click the button at the top right of the TSA HCM Adjustments page.



Step Action


Click Yes to proceed with the Delete function, click No to return to the TSA HCM Adjustments page and exit the function.






Step Action

19. If you have Deleted a contribution row in error, simply click the button, complete search for the Deleted EMPLID and the delete row content will be repopulated for further processing.



Step Action

20. The adjusted contribution rows will show a Valid Status immediately. This is because TSA does not require validation.

Notice that the source is changed from System (Work Table Load) to User. This is to allow an Audit trail creation. Also, note that the original data row has an Action Type = Delete which is an Audit trail creation as well.

21. Congratulations. TSAAdjustmentsprocess is complete. This topic demonstrates how to enter TSA Adjustments for data rows populated in the Work Table Load process. Below are the key concepts of this topic: - The TSA Adjustments process is used to correct contribution data containing Validation Errors in the Work Table Load Process or if prior month contribution data must be submitted or perform Deletes for contributions that should not be submitted. - Required field check list. - Error, Message and Warning list identification and descriptions shown in the TSA Add Contribution Row process. - Using the User Override functionality. - Deleting an adjusted data row added in error. - Deleting a contribution data row completely.



TSAAddContributionRow Overview: The TSA Add Contribution Row page will add a new contribution data row when a row was not created by the TSA Work Table Load process. The added contribution data row will have a BOR_CR_ACTION_TYPE = A (Add) and BOR_CR_ROW_SOURCE = U (User). Coding of the action type and source are necessary for audit purposes. The TSA Add Contribution Row cannot be used if an EMPLID with the target Provider already exists in the BOR_CR_WRK_TBL. The TSA Add Contribution Row process is available to all Common Remitter users.

AdditionalInformation This process should only be used in the event when a paycheck contribution deduction was not included in the TSA Work Table Load process. When an intended check was not processed timely, or if enrollment was made in an incorrect Provider or with the incorrect deduction begin date, then TSA Add Contribution functionality must be used to create a row for the targeted Provider and contribution. Contributions shown with the incorrect Provider must be Deleted using the TSA Adjustment Page functionality to prevent submission to the Provider. Existing EMPLIDs in the BOR_CR_WRK_TBL requiring adjustment may not be updated using the Add Contribution Row functionality. Note: Adding a contribution may clear a prior month reconciling item or may create a reconciling item for the reporting month. Users should exercise caution when determining the validity of using the TSA Add Contribution functionality. Required Contribution Data is unique by Provider and not all fields that are available for edit are required for each provider. When the SAVE function is performed if a required data field has been left blank a warning message will be displayed stating that the blank field is required.




Procedure The steps required to use the TSA Add a Contribution Row are:

Step Action

1. Navigate to BOR Customizations > BOR Payroll > Common Remitter > Retirement > Retirement ORP Processes > TSA Add Contribution Row

2. The TSAAddContributionRowparameterspage opens:

Leaving required data fields blank will result in error messages:



Step Action


4. Enter or select the EmplIDfrom the drop-down search

5. The Employee Record Number = 0 is defaulted, update if required when adding a contribution row:

6. Enter or select the BenefitPlanfrom the drop-down search


8. Enter or select the PayrunIDfrom the drop-down search

The Provider = 4 Service Provider = RET

9. Click the ADD button to open the ORP Add Contribution page.



Step Action

10. The BORPrTSAAddPG page is displayed.

11. Populate contribution fields for the added data as required. Identifying information i.e. EMPLID, Name, Benefit Plan, Employee Status, Pay Period End Date are defaulted from the Pay Calendar and Add Search page.

Note: If a negative amount is required, prefix with the (-) symbol.



Step Action

12. If the Save is attempted prior to completing ALL required fields a message, error or warning will be produced prompting for correction. Data resulting in a Message or Warning may be successfully saved but may affect outbound file or reporting data by leaving blank or mismatched values. Data resulting in an Error may not be saved until corrective action is taken. Note: Refer to the Error, Message and Warning listing if additional information is needed concerning the Message Severity and take corrective steps as required.



Step Action

13. Click the Save button to Save the newly Added TSA Contribution Row for further processing.

Note: If additional data rows are needed for the same EMPLID, Benefit Plan and Provider, navigate to the TSA Adjustments page for entry.

14. Congratulations. The TSAAddContributionprocess is complete. This topic demonstrates how to enter data using the ORP Add Contribution process. Below are the key concepts of this topic: - The TSA Add Contribution process will add a new contribution row when a row was not created by the TSA Work Table Load Process. - Note about entering required data fields. - Error, Message and Warning list identification and descriptions. - Adding additional data rows for the same EMPLID, Benefit Plan and Provider.



CreateTSAAccountingEntriesOverview: The Create TSA Accounting Entries process extracts data from the BOR_CR_TSA_HST table and places it in the HR_ACCTG_LINE (HRAL) and PERS_SERV_BOR (PSB) tables. The HR_ACCTG_LINE table is a temporary table used for the staging of data prior to general ledger journal generation for various processes. The PERS_SERV_BOR table is populated with the data rows to be used for queries and future enhancements as needed. Note: Only valid data, non-deleted rows are extracted for general ledger journal entry creation. Data rows containing an Error status or Deleted action will not be extracted to the HR_ACCTG_LINE or PERS_SERV_BOR tables. Data row status = ‘E’ error, are reconciling differences and may be from a prior reporting month or the current reporting month activity. Data row action types = ‘D’ delete, are original rows loaded by the work table load process and have been updated by the user. All data and row statuses may be identified in the TSA History Details query located under TSA Inquiry menu. ProcessName: BOR_CC_T The HCM Common Remitter data staged in the HRAL table will be messaged via integration broker into the mirror table HRAL in PeopleSoft Financials for Journal Generation, the same way that HCM Payroll data is messaged. The Journal Generation process for the tax-sheltered annuity contribution data will occur in PeopleSoft Financials. Once journal generation has been completed the Journal ID and Journal Date will be updated and messaged back to the HCM HRAL and PSB tables, the same way that the Payroll Journal ID’s are messaged. Institutional users having the Common Remitter user role will be responsible for running the Create TSA Accounting Entries process.

AdditionalInformationThe TSA Final Extract process must be completed successfully, and notification received prior to running the Create TSA Accounting Entries process. Notifications are sent via email from the OneUSG Connect Common Remitter listserv. A *Cash/Clearing Account must be used in run parameter. The user may opt to post directly to the Cash (bank account) or an alternate Clearing Account, dependent upon their individual business practice. General Ledger entries will be summed by chart string. Note: The Accounting Date, Fiscal Year and Period will be auto populated based on the Payrun ID data. Remember that the check date is the date the liability is incurred and will be the accounting



date as well. The Business Unit may opt to post as of an alternate date in the following month, dependent upon their individual business practice.

Warning: The Create TSA Accounting Entries process may only be run once per Payrun ID cycle. If the process is run prior to receiving notice “The final extract is complete, you may now begin the create accounting entries and journal generation process” – a DBI will be required to reset the BOR_CR_AUDIT table to allow reprocessing.



Procedure In this topic, you will run the Create TSA Accounting Entries process for your Business Unit.

Step Action

1. Navigate to BOR Customizations > BOR Payroll > Common Remitter > TSA > TSA Processes > Create TSA Accounting Entries

2. The CreateTSAAccountingEntriesRun Controlpage opens:


4. Enter CREATE_TSA_ACCTG_ENTRIES in the Run Control ID group box.




Step Action

6. The Create TSA Accounting Entries run parameters page will open.

7. In the Processing Parameters group box enter or select from the drop-down menus

the following values: Business Unit Payrun ID Cash/Clearing Account Receivables Account

Note: The Accounting Date, Fiscal Year and Period will auto populate based on the Pay Calendar of the target Payrun ID.


Reminder: The SAVE function must be used each time the page is updated, or else the last saved parameters will be used instead.

9. Click the Run button to run the Create TSA Acct Entries - BOR_CC_T process.



Step Action



previous menu.

12. Clicking the OK button to continue will return you to the CreateTSAAccountingEntries run parameters page, click on the Process Monitor link.



Step Action


Verify that the Run Status = Success and the Distribution Status = Posted Note: Status’ ≠ Success will require further analysis to determine issue(s). The Run Status = Success indicates that data has been successfully placed in the HR_ACCTG_LINE table and is waiting journal generation using the Journal Generation process in PS Financials. The Run Status = No Success may indicate that the Accounting entries have already been created for pay run id.

The Create Accounting Entries may only be run once for a Payrun ID. In the event and there is an error with the journal users must submit a ticket to [email protected] for assistance and to have the Staging Tables cleared of the incorrect data. This would be a rare occurrence for TSA entries.



Step Action

14. In the event a process instance ran to No Success. To view message status’, click the

Process Name link in the process monitor.

15. The Process Detail page will open. Click the message link showing No Success on the Process Detail page:



Step Action




Step Action

17. Click on the Message Log link, the reason for No Success will be shown.

18. If a message other than Accounting entries have already been created for pay run id:

XXXX - submit a ticket to ITS for assistance.

19. Click to return to the process detail page. Click to return to

the first Process Detail page. Click again to return to the Process List page. If preferred, you may use the X at the top right corner to return.




Step Action

21. Congratulations. Running the CreateTSAAccountingEntries is complete. This topic demonstrates how to run the Create TSA Accounting Entries process. Below are the key concepts of this topic: - The Create TSA Accounting Entries process populates the HRAL table with data rows ready for final processing by running the Generate Journal Entries in PeopleSoft Financials. - The Create TSA Accounting Entries process populates the PERS_SERV_BOR table with the data rows to be used for queries and future enhancements as needed. - Only rows with an Action Type ≠ D and Row Status = V will be included in the Create TSA Accounting Entries process. All Action Types and Row Status’ are retained in the Work History table for Audit purposes. - The Create TSA Accounting Entries process is run only for the specified Payrun ID. - The Create TSA Accounting Entries process may only be run once for each Payrun ID.




Select the correct Accounting Definition Name and Template for journal generating the target provider data. AccountingDefinitionName/Description JournalTemplate PYRLRETDEF Retirement Accounting Entries PAYROLL_RT (Use when journal generating ERS, TRS and ORP) PYRLTSADEF TSA Accounting Entries PAYROLL_TS (Use when journal generating TSA) Use the From Date Option = Specify Date and To Date Option = Specify Date when journal generating. The specify date is the accounting date or check date- these represent the same date. Institutional users designated for Generating Journals will be responsible for running Journal Generate process in PeopleSoft Financials.



AdditionalInformation The Create TSA Accounting Entries process must be completed in HCM Common Remitter and the HRAL data must be messaged from HCM to PS Financials prior to Generating Journals Note: Entries having the same Accounting Definition Name, Template and Specify Date will be combined in a single journal line. The Create TSA Accounting Entries process is run for a single Payrun ID. Review the process log for the FS_JGEN_BOR (Generate Journals) to reveal the Journal ID. Once journal generation has been completed the Journal ID and Journal Date will be updated and messaged back to the HCM HRAL and PSB tables, the same way that the Payroll Journal ID’s are messaged.



TSAInquiry/Reports

The TSA Inquiry menu contains two kinds of reports. The reports are divided by the BOR_CR_WRK_TSA (work table), BOR_CR_TSA_HST (history table).

TSA online queries/reports are found at the following navigation: BOR Customizations > BOR Payroll > Common Remitter > TSA > TSA Inquiry

After the TSA work table load process has been run the following online queries are available for use in validating the Common Remitter data with the Payroll deduction data. The work table reports are used in validation and pre-reconcilement.

TSADetailsforallplans – this report will return all data loaded into the work table by the work table load process. The total data should match the total payroll deductions for the reporting period.

TSAWorkTableErrors – this report will return data if there are any errors present in the work table. Error examples: missing demographic data, SSN is blank, EE Contribution is zero, etc. – refer to the Error Code listing for a complete list (page 11 of this document).

TSAWorkNetPositiveData – this report will provide work table detail data where the net contribution for each EMPLID is a positive amount.

TSAWorkNetNegativeData – this report will provide work table detail data where the net contribution for each EMPLID is a negative amount.

TSAWorkNetZeroData – this report will provide work table detail data where the net contribution for each EMPLID is a zero amount.

TSAWorkNegative>=10KData– this report will provide work table detail data where the net contribution is equal to a net negative contribution or sums to be greater than ten thousand dollars.

TSAVariancesWorkTable – this report will identify instances where there are variances between the work table load data and the payroll deduction data by payroll deduction code.

TSAVariancesDetail – this report will provide the variance detail which includes amounts, deduction codes and transaction types.

After the TSA Final Extract processes has been run the data is moved from the work table into the history table where the following reports become available. Note: The history table reports may be rerun for any month. The history table reports are used in validation and post-reconcilement.

TSAHistoryDetails– this report provides detailed history data by EMPLID by provider and benefit plan. Results returned may be filtered by using various run criteria, else all data in the history table will be returned by using the wild card (%).



TSAHistoryNetPositiveData – this report will provide history table detail data where the net contribution for each EMPLID is a positive amount.

TSAHistoryNetNegativeData – this report will provide work table detail data where the net contribution for each EMPLID is a negative amount.

TSAHistoryNetZeroData – this report will provide work table detail data where the net contribution for each EMPLID is a zero amount.

TSARemittanceReport– this report will provide contribution data in summary or detail form for all data rows with a valid status that will be remitted to the provider. This report is a .pdf report.




Step Action

1. Navigate to BOR Customizations > BOR Payroll > Common Remitter > TSA > TSA Inquiry > select the target report name



the magnifying glass is present, click for a drop-down search selection. Prompt Fields: Business Unit – institutional five-digit business unit EMPLID – unique identifier for each employee Payrun ID – unique four-digit Payroll Payrun ID Provider – system assigned abbreviation used 4-RET Action – identifies the action for any given row Row Status – identifies the row status for any given row




Step Action

5. Congratulations. RunningTSAInquiryonlinequeries/reports is complete. This topic describes how to run the online queries/reports. Below are the key concepts of this topic: - The work table reports return data contained only in the work table prior to final extraction. The work table reports are used for pre-reconcilement and verification. - The history table reports return data contained only in the history table after the final extraction. The history table reports are used for post-reconcilement and verification. - Brief descriptions of each online query/report. - The TSA online queries/reports are run by the unique Payrun ID. - Descriptions of prompt values used in the online queries/reports. - Online queries/reports may be downloaded or saved for future use and analysis.



Appendix

Prerequisites:

Before Common Remitter processing begins for a reporting cycle the following conditions must be met:

Active Employee Status o Benefit Eligible

Benefit Enrollment o Begin Deduction Date

Payroll Confirmed

ProcessTaskList:

Payroll Confirmed Work Table Load ListServ First Update Pre-Reconcilement Add/Adjust/Delete period Final Extract ListServ Second Update Create Accounting Entries Message HRAL data to PS Financials Journal Generation Message Journal ID and Journal Date to One USG Connect Payroll Post-Reconcilement

Reconciliation:

This is a summary of the normal process that should be used.

Payroll Deductions total for the reporting period should equal the Common Remitter work table load.

Use a payroll query or deduction report to obtain the amounts and total. Reconcile the Payroll Deductions to the Work Table details and summary reports. If differences are present identify them by comparing the two reports in detail form. Make

corrections if needed on the Adjustment or Add pages for the respective provider ERS/TRS/ORP/TSA.

Reconcile summaries again to verify that adds/adjustments/deletes were entered correctly prior to the final extract completion.



After the final extract and journal generation has been completed perform a final or post reconcilement for permanent record.

The Invoiced amount from Shared Services Common Remitter Team should match any of the History Table summaries and the Journal generated in PS Financials.

Note: When using any of the detail’s online reports in the Common Remitter module, remember that only valid non-deleted data rows are included in the final extract that will be submitted to the Provider. For this reason, when summing for totals using the details reports you should pivot those rows with an action type of deleted or a row status other than valid.



FieldListingforAdd/Change/Deletepages:

Error,MessageandWarningListing:



Message NBR’s 1 – 199 relate to the Validation and Application Engine processes Message NBR’s 200 – 412 relate to the RET/ORP/TSA Add Contribution Row and RET/ORP/TSA Provider Adjustments pages. Note: the above sample message number is (28521,202) refer to the message in the below listing for Message NBR 202, states that Deduction Code is a required field on row 1.



Communication:

UGS Service Now – ticket submission

OneUSG Connect Common Remitter Listserv

AnnualUpdates:

Common Remitter – Custom Translate Values o Calendar Year – additional years added as needed for each Provider o IRS Limit – added when the IRS Annual Maximum Limitations change o IRS Limit CY or FY – added for each year and Provider to indicate Plan Type if

calendar or fiscal year rule

GeneralLedgerAccountandFundCodeListing:

Retirement/ORP as of 7/1/2019 o Table Name – BOR_CR_RET_LIAB

EP_PROVIDER_BOR BOR_CRT_TRANS_TYPE BENEFIT_PLAN ACCOUNT FUND_CODE

RET LEE ORP 224500 62000

RET LER ORP 234500 62000

RET LEE ORPLMT 224500 62000

RET LER ORPLMT 234500 62000

Retirement/ORP pre - 7/1/2019

EP_PROVIDER_BOR BOR_CRT_TRANS_TYPE BENEFIT_PLAN ACCOUNT FUND_CODE

ERS LEE ERS 224741 62000

ERS LEE ERSNEW 224741 62000

ERS LEE GDCP 224751 62000

ERS LEE GTDC 224751 62000

ERS LEE NAR 224741 62000

ERS LEE OAR 224741 62000

ERS LER ERS 234241 62000

ERS LER ERSNEW 234241 62000

ERS LER NAR 234241 62000

ERS LER OAR 234241 62000

FID LEE ORP 224051 62000



FID LEE ORPLMT 224051 62000

FID LER ORP 234355 62000

FID LER ORPLMT 234355 62000

TIAA LEE ORP 224031 62000

TIAA LEE ORPLMT 224031 62000

TIAA LER ORP 234335 62000

TIAA LER ORPLMT 234335 62000

TRS LEE 00TRS 224711 62000

TRS LEE 00TRSL 224711 62000

TRS LEE TRS 224711 62000

TRS LEE TRSLMT 224711 62000

TRS LER 00TRS 234111 62000

TRS LER 00TRSL 234111 62000

TRS LER TRS 234111 62000

TRS LER TRSLMT 234111 62000

VALI LEE ORP 224071 62000

VALI LEE ORPLMT 224071 62000

VALI LER ORP 234365 62000

VALI LER ORPLMT 234365 62000

ERS LEE GSEPS 224741 62000

ERS LER GSEPS 234241 62000

TSA

o Table Name – BOR_CR_TSA_LIAB

EP_PROVIDER_BOR BENEFIT_PLAN ACCOUNT FUND_CODE

1 ‐ Valic 403B 225601 62000

1 ‐ Valic 457B 225701 62000

2 ‐ Fidelity 403B 225602 62000

2 ‐ Fidelity 457B 225702 62000

3 – TIAA‐Cref 403B 225603 62000

3 – TIAA‐Cref 457B 225703 62000

4 – RET 403B 224500 62000

4 – RET 457B 224500 62000

6 – Northern Life 403B 225606 62000

6 ‐ Northern Life 457B 225706 62000

8 ‐ Lincoln 403B 225608 62000

8 ‐ Lincoln 457B 225708 62000

common remitter guide for users and support - usg.edu · common remitter user guide © 2019 board...

Documents