Wednesday, March 27, 2019

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);

Wednesday, March 20, 2019

Object not copied, parent definition does not exist in target database (62,33)

We once were doing migration for a project but got stuck when app designer wouldn't copy one of the objects in the project to target instance and kept throwing below error:

Object not copied, parent definition does not exist in target database (62,33)

The error was associated with one AE SQL step and we spend quite some time scratching our head over this. Finally we discovered that we forgot to include the parent section of the SQL Step of the App Engine in the project. In other words, we were trying to migrate a child object without it's parent object.  
Well, it doesn't sound convincing right ? because we very often migrate child objects without their parent objects. But in our case it didn't work because the child object (SQL or PeopleCode) was added newly.
Let's try to understand it in a different way. Consider we have an app engine which contains Sections and Steps and this is how they are related.

App Engine - Section(s) - Step(s)

Consider that we have added a new step under a section so if we have to migrate one of the Steps (PeopleCode or SQL) then we must also take along the corresponding parent Section. If you have included the child object but not it's parent then app designer will throw an error (Shown in the first para).  To resolve this, include the respective parent section.

Saturday, March 2, 2019

Prompt isn't fetching the elements in the Rule Package Definition in PeopleSoft Global Payroll

Have you ever encountered this issue where in the rule package definition, when you try to add desired elements you don't see them in the prompt as shown below:


as you can see the element that you have defined isn't displayed in the prompt and this is related to your Global Payroll access. For instance, in this case I defined a country specific element for GBR but in my Global Payroll profile I have access to All Countries as shown below:


To resolve the issue, just change the flag to Specific Country and also select that particular country you defined the element for i.e. GBR in this case:


Now go back to the Rule Package definition, open the page again and try adding the element. If it doesn't work then log-out/log-in and then try again.

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