Payee %1 is being processed in Group List %2 run by User %3. There could be other overlaps.

The below error usually occurs when we run the payroll for a payee using group list who is already being processed by another user through another Group List.

Payee %1 is being processed in Group List %2 run by User %3. There could be other overlaps.

To resolve it, the user needs to be deleted from the other group list used by the other user. Just run below SQL and re-run the payroll for payee in error.

DELETE FROM PS_GP_GRP_LIST_RUN WHERE oprid = '';

ORA-00001: unique constraint (SYSADM.PS_GP_PI_GEN_SOVR) violated in Global Payroll

This error usually occurs when the COBOL process GPPDPRUN errors out and we run it again on top of that. It basically tries to insert the same set of rows on the payroll processing tables with the earlier set of rows already present. And when it does that it throws the UNIQUE CONSTRAINT error.

The first thing that we need to do is check the process log where we will get the clue as to where exactly process failed. Important thing to notice here is, if you process the payroll through streams then it's better to check which particular stream caused the COBOL to fail. Once the stream is located then just cancel that particular stream and re-run it, the error will be gone.

However, if the payroll is processed without streams then the whole payroll needs to be cancelled and re-run which will resolve the issue.

Segmentation not created for a payee in PeopleSoft Global Payroll

Recently we had an issue when payroll wasn't creating segments for a new country for which we were implementing GP. We spend nearly two days trying to figure out what exactly was causing this.

These are possible reasons:

Unprocessed Iterative Triggers

If one or more iterative triggers of previous period are in unprocessed state then segmentation for those employees will not be processed. If so then delete those triggers using below SQL
DELETE FROM PS_GP_RTO_TRGR WHERE COUNTRY = <payee's country> AND EMPLID = <emplid> AND TRGR_STATUS = 'U' AND CAL_RUN_ID <> <Current Calendar Group>;

There might also be unprocessed iterative triggers created for the country other than payee's country which will cause this hence delete those triggers too.

Unprocessed Retro Triggers

If one or more retro triggers for other countries are in unprocessed state then segmentation for those employees will not be processed. If so then delete those triggers using below SQL
DELETE FROM PS_GP_ITER_TRGR WHERE COUNTRY <> <payee's country> AND EMPLID = <emplid> AND ITER_TRGR_STATUS = 'U';

Segmentation Triggers

If one or more segmentation triggers for other countries exist and are active for those employees then segmentation will not be processed.
DELETE FROM PS_GP_SEG_TRGR WHERE COUNTRY <> <payee's country> AND EMPLID = <emplid> AND SEG_TRGR_STATUS = 'A';

In our case, all above where the reasons so we basically deleted all those unwanted triggers (Iterative, Retro and Segment) using SQL script and it resolved the issue. The segmentation was processed.

Retro trigger not picked up when created through INSERT SQL in PeopleSoft Global Payroll

Global Payroll system is a den of mysteries and one of them is the retro trigger created using INSERT SQL. The issue with this is it doesn't get picked up by the payroll process unless we also create an iterative trigger for the current open period.

In case you haven't noticed, whenever you create a retro trigger manually through PIA, it also creates an iterative trigger as it's shown below:

Retro trigger created through PIA

Iterative trigger is automatically created with source record as GP_RTO_TRGR_VW

So, it means whenever you create retro triggers using INSERT SQL then create an iterative trigger also. Only if you do this the payroll will pick up the retro trigger and process it.
You can use these SQLs to create retro trigger and iterative trigger respectively.

SQL to create retro trigger

Insert into PS_GP_RTO_TRGR (EMPLID,COUNTRY,TRGR_EVENT_ID,TRGR_EFFDT,TRGR_CREATE_TS,RTO_TRGR_SRC,TRGR_STATUS,TRGR_DESCR,RECNAME,FIELDNAME,TRGR_FLD_VAL_CHAR,TRGR_FLD_VAL_DT,TRGR_FLD_VAL_NUM,CAL_RUN_ID) values (,'GBR','JOB',to_date(,'DD-MM-RR'),SYSDATE,'M','U',' ',' ',' ',' ',null,0,' ');

SQL to create iterative Trigger

Insert into PS_GP_ITER_TRGR (EMPLID,CAL_RUN_ID,ITER_TRGR_STATUS,TRGR_CREATE_TS,ITER_TRGR_SRC,COUNTRY,RECNAME,FIELDNAME,TRGR_FLD_VAL_CHAR,TRGR_FLD_VAL_DT,TRGR_FLD_VAL_NUM) values (,,'U',SYSDATE,'O','GBR','GP_RTO_TRGR_VW',' ',' ',null,0);

Unable to stop retro processing for a payee in PeopleSoft Global Payroll

Recently we had an issue where for an employee a retro trigger got created accidentally and caused some of the finalized calendars to re-open. It completely screwed up the payroll results for the current period because we had many Positive Inputs for adjustment and the retro which caused the issue was completely undesired.

We desperately wanted to get rid of the retro pressing so we first tried with cancelling the retro trigger and ran the payroll for that employee but it didn't help as the retro was still opening. We then set the retro limit through the  page hoping that the Assign Retro Limit page hoping that it won't go back beyond current calendar but that didn't help either. The retro was still processing.

We then did following to get the results we wanted to get.

1. Open the Payee Status page and set the process indicator flag to Cancel
2. Process the payroll for the payee
3. Open the Review Triggers page and cancel all the retro triggers for the payee
4. Open the Payee Status page and set the process indicator flag to Uncancel
5. Process the payroll for the payee again

How to unfinalize a calendar in PeopleSoft Global Payroll

One thing you all must agree that everyone of us who work in PeopleSoft Global Payroll, at some point of time have to undo the finalize of a calendar just to process it again. But the issue is, there is no delivered way of doing this so we have to use our own way which is through SQL script.

A calendar group can be un-finalized by executing following three steps:

1. Reset the calculation status to Successful in the table GP_PYE_SEG_STAT
2. Reset all the flags and the finalized time stamp in the table GP_CAL_RUN
3. Reset the finalized time stamp in the table GP_CAL_RUN_DTL

All the above three steps can be executed through SQL given below:

UPDATE PS_GP_PYE_SEG_STAT
SET PYE_CALC_STAT = '50'
WHERE CAL_RUN_ID = 'Calendar Group';

UPDATE PS_GP_CAL_RUN
SET RUN_FINALIZED_IND = 'N',
RUN_FINALIZED_TS = NULL,
RUN_OPEN_IND = 'Y',
PMT_SENT_IND = 'N',
GL_SENT_IND = 'Y'
WHERE CAL_RUN_ID = 'Calendar Group';

UPDATE PS_GP_CAL_RUN_DTL
SET CAL_FINAL_TS = NULL
WHERE CAL_RUN_ID = 'Calendar Group';

Most frequently queried tables in PeopleSoft Global Payroll

A PeopleSoft Global Payroll specialist who maintains and support the system have to frequently query a set of tables very frequently. Lets see what are those.

The below tables contain the calculation results and are source of data that is displayed in the page Result by Calendar Group
PS_GP_PYE_PRC_STAT  (Contains all the resolved calendars)
PS_GP_PYE_SEG_STAT (Contains all the resolved segments calendar-wise)
PS_GP_RSLT_ERN_DED (Contains payroll earnings and deduction results under each segments calendar-wise)
PS_GP_RSLT_DELTA (Contains retro delta results calendar-wise)
PS_GP_RSLT_ACUM (Contains accumulator results calendar-wise)
PS_GP_RSLT_PIN (Contains supporting element results (bracket, formula, variables etc..) calendar-wise)
PS_GP_RSLT_PI_DATA (Contains positive input results calendar-wise)

The below tables contain triggers created from various sources and can be seen in the page Review Triggers
PS_GP_RTO_TRGR (Contains retro triggers)
PS_GP_SEG_TRGR (Contains segmentation triggers)
PS_GP_ITER_TRGR (Contains iterative triggers)

This one contains the error/warning messages associated with payees calendar-wise after the pay calculation process is run and can be seen through the page Payee Messages
PS_GP_MESSAGES

When we run the payroll with debug and trace option enabled, the audit trail is stored in the below table and can be seen through the page Element Resolution Chain
PS_GP_AUDIT_TBL

The payee level data is stored and maintained in below tables
PS_GP_PI_MNL_DATA (The earnings and deductions assigned to a payee, Page - One Time (Positive Input))
PS_GP_PAYEE_DATA(The retro limit at payee level, page Assign Retro Limit)
PS_GP_PYE_OVRD (Elements assigned to a payee for a specific period, page -Element Assignment by Payee)

Calendar Group Definitions are stored in this table:
PS_GP_CAL_RUN

Payments processing details and results are stored in below tables:
PS_GP_PMT_PREPARE (Payment processing details for a calendar group, page -Run Payment Prep Process)
PS_GP_PAYMENT (Payment processing results for a calendar group)

GP-GL processing detail and result are stored in below tables:
PS_GP_GL_PREPARE (GP-GL processing details for a calendar group)
PS_GP_GL_DATA (GP-GL processing results)