Showing posts with label Global Payroll. Show all posts
Showing posts with label Global Payroll. Show all posts

Wednesday, November 5, 2014

Understanding PeopleSoft Global Payroll Identification

The first stage in PeopleSoft Global Payroll processing is the identification of the employees to be calculated. Several criteria are used to determine which employees should be selected. Understanding why an employee is selected is not always evident to users. In this post I'm sharing how I normally determine the identification reason.

Once you run the identification stage, the employees to be processed are stored in the GP_PYE_PRC_STAT table. This table not only shows which employees are going to be calculated, but also indicates which calendars will be considered. This is particularly important when running retroactive calculations, as it allows you understanding the impact of this type of calculations.

In any case, going back to the identification, in this table you will find the SEL_RSN field, which contains a code that translates into the reason behind the employee identification. The valid values that this field may take are:

  • 01: The employee is active during the calendar period and included in the Payee List associated to the calendar.
  • 02: The employee is inactive (but was active before the start of the calendar period) and included in the Payee List associated to the calendar.
  • 03: The employee is active during the calendar period and has a positive input associated to him/her.
  • 04: The employee is active during the calendar period and has a retro trigger associated to him/her.
  • 05: The employee is active during the calendar period and associated to the calendar pay group.
  • 06: The employee is inactive during the calendar period and associated to a positive input in the current calendar.
  • 07: The employee is inactive (but still associated to the calendar pay group) and has a retro trigger associated to him/her.
  • 08: The employee is inactive but has a retroactive calculation delta from a previous calendar which has not been picked yet.
  • 09: The employee is inactive but has a retroactive calculation correction from a previous calendar which has not been picked yet.
  • 0A: The employee is active and linked to the calendar using an override.
  • 0B: The employee is inactive and linked to the calendar using an override.

From a technical standpoint, you can check the SQL used to select each reason by check the stored statement under the name GPPIDNT2_I_PRCnn, when nn is the SEL_RSN value.

Do you use other way to understand why was an employee identified? If so, please feel free to share your method in the comments, as I'm afraid my approach is a little bit too technical. ;)

Tuesday, May 25, 2010

Cloning elements in Global Payroll

I've been lately involved in a couple of PeopleSoft Global Payroll implementations. One of the pain areas in dealing with Global Payroll rules definition is that there does not seem to be an easy way to clone or save an element with another name. Re-entering the element again is not always an option, specially if you are dealing with a formula, array or bracket with several lines.

Just a couple of weeks ago we found out a way in which we could clone elements. Here it is:

  • Create a Rule Package with the elements you want to clone in it.
  • Export the Rule Package.
  • Rename (both pin name and code) the elements.
  • Import and apply the Rule Package you previously exported.

We still think we could make it easier with a bit of customization, by automating export and import of the package rule, as it is on the same database.

Anyway, I hope this is useful. Have you found any other way to do this?