Setting Up Triggers

This chapter provides an overview of triggers and discusses how to:

• Set up trigger definitions.

• Implement triggers.

• View and manage triggers.

• Review PeopleSoft delivered triggers.

Understanding Triggers

This section discusses:

• Description of triggers.

• Trigger table data.

• Iterative triggers.

• Retroactive triggers.

• Segmentation triggers.

• Trigger generation.

Description of Triggers

In Global Payroll, the mechanism used to detect online changes to data that result in a system action is called a trigger. Common data changes that might use triggers are payee hiring, pay rate changes, and job location changes.

There are three types of triggers: iterative, retroactive, and segmentation. You can generate triggers in two ways:

• Manually: Doesn't require you to set up trigger definitions. You create triggers manually for a given payee.

  Note. The manual generation of triggers is available for retroactive and segmentation triggers only. Iterative triggers can only be generated automatically.

• Automatically: Does require you to set up trigger definitions. These trigger definitions tell the system how and when to generate “automatic” triggers when a database change occurs.

Once triggers are generated (manually or automatically), the batch process uses the trigger to perform the proper action.

Trigger Table Data

When a trigger is generated by a change to a record or record and field combination, it writes out the necessary data to process the trigger. Each type of trigger has its own tables in which the trigger data is stored.

Besides storing information about which employees to process, process definitions, and effective dates, trigger tables store information about the status of payee-level triggers, the trigger type, the date and time when the trigger is generated, and so on.

Iterative Trigger Table

The information generated by an iterative trigger is stored in the iterative trigger table (GP_ITER_TRGR). The following table illustrates the structure of data in the iterative trigger table:

Retroactive Trigger Table

The information generated by a retroactive trigger is stored in the retroactive trigger table (GP_RTO_TRGR). The following table illustrates the structure of data in the retroactive trigger table:

When a retroactive trigger is generated by a data change, it writes out the employee ID, the effective date of the change (also called the trigger effective date), the country, and the associated event ID along with information to facilitate retroactive processing by the batch code. Among other things, this data tells the system:

• Which payees to process.

• Which periods to process retroactively, based on the trigger effective date.

• Which process definition (associated with an event definition) to use when managing retroactive situations.

The system determines how many previous periods to recalculate in relation to the change’s effective date.

Note. You can generate multiple rows of trigger data for one event by making multiple record and field combinations sensitive to retroactive data changes. For example, a retroactive hire situation might be picked up by a field on the Job page and fields on other pages that would ordinarily be affected by changes to an employee’s hire date. Although multiple rows of trigger data don’t prevent retroactive processing, the earliest trigger effective date is used to drive limit calculations, which, in turn, direct retroactive calculations.

Segmentation Trigger Table

The information generated by a segmentation trigger is stored in the segmentation trigger table (GP_SEG_TRGR). The following table illustrates the structure of data in the segmentation trigger table:

See Also

Understanding Retroactive Processing

Defining Backward and Forward Retroactive Processing Limits

Iterative Triggers

Iterative triggers tell the system that a payee needs to be processed (or reprocessed) for the current open calendar. They are generated for open calendar group IDs. Without an iterative trigger, the payee cannot be reprocessed. Because processing is its sole function for the current open calendar, it doesn’t need to have an event ID attached.

Iterative triggers are generated by the system, through online data changes or an automatic reprocess feature in batch processing. When specified data has changed for a payee, the system (through online code) generates iterative triggers that enable the batch process to recalculate the payee, add the payee to the calendar run, or remove the payee from the calendar run.

See Also

Processing Concepts

Retroactive Triggers

When the online system registers payee data changes to an online record or record and field combination, PeopleCode creates a trigger including the country code, which is an integral part of its definition. A trigger is inserted for every country where a trigger definition for that record or record and field combination has been defined regardless of whether a payee has ever been in the country. The system cleans up extraneous retroactive triggers during the identification phase by searching the Job table for the country that's associated with the payee's current job and Payee Process Stat (payee process status) records for countries where the payee was formerly employed. If the payee has never been in the country that is being processed, the retroactive triggers for that country are deleted. To avoid more than one calendar group from deleting the same set of triggers, only triggers for the country identified by the calendar group being processed are deleted.

To enter a retroactive trigger manually, you use the Review Triggers-Retro page; required fields are Country, Trigger Effective Date, and Trigger Event ID.

See Also

Defining Trigger Event IDs

Viewing, Adding, or Canceling Retroactive Triggers

Segmentation Triggers

Segmentation triggers tell the system that payroll and absence data for a payee must be segmented. A segmentation event ID must be created before defining a segmentation trigger.

Example

A payee changes jobs on March 15, during a pay period that goes from March 1 through March 31. The system segments each period or element (given element segmentation), using the following segmentation logic:

For period segmentation: The first segment includes March 1 – March 14; the second segment includes March 15 – March 31. Each segment comprises a separate gross-to-net calculation.

For element segmentation: Only one segment exists, with two slices. The first slice includes March 1 – March 14; the second slice includes March 15 – March 31. There is only one gross-to-net calculation.

See Also

Defining Segmentation Events and Types

Understanding Segmentation Setup

Trigger Generation

All triggers are generated, taking trigger level into account. Retroactive and segmentation triggers check Trigger Effdt Type (trigger effective-dated type) to determine whether a trigger should be generated.

Rules for Generating Iterative Triggers

Iterative triggers are generated only when an open calendar group exists; the calendar group must be “Identified.”

When the trigger level is Record, an iterative trigger is generated if a row is added, changed, or deleted.

When the trigger level is Field, Non-Value-based:

• If a row and the field are changed, an iterative trigger is generated.

• If a row is added or deleted, an iterative trigger is generated.

When the trigger level is Field, Value-based, besides observing the rules for non-value-based triggers, an iterative trigger is generated only if the value on the added, changed, or deleted row matches a specified value or you have specified generation of a trigger even if no values match.

Rules for Generating Retroactive Triggers

When Trigger Effdt Type is Effective Date:

• If a row is added, use that effective date as the trigger date.

• If a row is deleted, use the initial effective date as the trigger date.

• If a row is changed, the earlier of the initial effective date and the changed effective date is used.

The initial effective date is the effective date with which the row was loaded. The changed effective date is the effective date on the row at save time. If you haven’t changed the effective date, it’s the same as the initial effective date. If you’ve changed the effective date, it’s different from the initial effective date.

When Trigger Effdt Type is Begin/End Date:

• If a row is added, use the begin date as the trigger date.

• If a row is deleted, use the initial begin date as the trigger date.

• If a row is changed and the end date is the only changed field, use the earlier of the initial end date and changed end date as the trigger date; otherwise, use the earlier of the initial begin date and the changed begin date as the trigger date.

The initial begin date is the begin date with which the row was loaded. The changed begin date is the begin date on the row at save time. If you haven’t changed the begin date, it’s the same as the initial begin date. If you’ve changed the begin date, it’s different from the initial begin date.

The initial end date is the end date with which the row was loaded. The changed end date is the end date on the row at save time. If you haven’t changed the end date, it’s the same as the initial end date. If you’ve changed the end date, it’s different from the initial end date.

Note. With absences, use the begin date even if you change the end date. If the existing row is voided, and a new row is created. Because the existing row is void, begin date is used.

When Trigger Effdt Type is Fixed Date, the trigger date is the date that you specify as a parameter in the PeopleCode function Generate_Triggers.

When Trigger Level is Record:

• If a row is added, changed, or deleted, a retroactive trigger is generated.

• If you change multiple rows, the earliest trigger date from all the changed rows is used as the trigger date.

When Trigger Level is Field, Non-Value-based:

• If a row is added or deleted, find the maximum effective-dated row that’s earlier than the trigger date for the row.

  If the field value differs between the prior row and the added or deleted row, a retroactive trigger is generated.

• If a row and the field value are changed, a retroactive trigger is generated, whether or not the effective date for that row is changed.

• If a row and the effective date for that row are changed (assume the effective date before the change is “old date” and the effective date after the change is “new date”):

  • If the field is changed, a retroactive trigger is generated.

  • Find the row whose maximum effective date is less than the new date.

    If the field value differs between the prior row and the changed row, a retroactive trigger is generated.

  • Find the row whose maximum effective date is less than the old date.

    If the field value differs between the prior row and the changed row, a retroactive trigger is generated.

• If a prior row isn’t found, the added, changed, or deleted row is the first row in the buffer.

  A retroactive trigger is generated with the primary event ID specified in the trigger definition.

When Trigger Level is Field, Value-based, besides observing the rules for non-value-based triggers, a retroactive trigger is generated only if the value on the added, changed, or deleted row matches a specified value or you've specified generation of a trigger even if no values match.

Rules for Generating Segmentation Triggers

Segmentation triggers are generated only from records whose Trigger Effdt Type is Effective Date.

Segmentation triggers aren’t generated for deleted rows.

When Trigger Effdt Type is Effective Date:

• If a row is added, use that effective date as the trigger date.

• If a row is changed, the changed effective date (not the initial effective date) is used.

Note. The initial effective date is the effective date with which the row was loaded. The changed effective date is the effective date on the row at save time.

When Trigger Level is Record, a segmentation trigger is generated if a row is added or changed.

When Trigger Level is Field, Non-Value-based:

• If a row is added or changed, find the row whose maximum effective date is less than the added or changed row.

  If the field value differs between the prior and current row, a segmentation trigger is generated.

• If a prior row cannot be found:

  • If the field value is changed, a segmentation trigger is generated.

  • If it is a new row, a segmentation trigger is generated for all specified fields.

When Trigger Level is Field, Value-based, besides observing the rules for non-value-based triggers, a segmentation trigger is generated only if the value on the added or changed row matches a specified value or you've specified generation of a trigger even if no values match.

Setting Up Trigger Definitions

This section provides an overview of trigger definition setup and discusses how to:

• Define triggers.

• Indicate which field values initiate actions.

See Also

Using Calendars

Defining Retroactive Processing

Defining Segmentation

Defining Segmentation Events and Types

Understanding Trigger Definition Setup

To set up and use triggers, you should understand exactly how trigger definition is structured.

A trigger serves as a mechanism to detect online changes, as they happen, to certain data in the system and to write a row of data to a trigger table for further processing by the batch code. The row of data in the trigger table is the trigger that tells the system that some action must occur during batch processing.

Three types of actions can occur, reflecting the three types of triggers: iterative, retroactive, and segmentation.

An iterative trigger tells the system to process (or reprocess) a payee for the current open calendar, possibly because data has changed for the payee or the payee was placed in suspended mode during batch processing and needs reprocessing. Only one iterative trigger is generated, regardless of the number of calendars in the calendar group.

A retro trigger tells the system to perform retroactive processing. Perhaps a payee’s rate of pay has changed and that rate of pay is retroactive for the previous two months. The payroll data must be reprocessed, to ensure that the payee is receiving the correct pay rate.

A segmentation trigger tells the system to perform period segmentation or element segmentation.

Note. It’s highly recommended that when you define a retroactive or segmentation trigger, you also define an iterative trigger. If a calendar group has been calculated once and data changes are subsequently made, unless an iterative trigger is defined, retroactive or segmentation triggers generated from the data changes are not processed until the next Identify process.

Payee level triggers in Global Payroll are generated when there are changes to payee records that have Employee ID as part of their primary key structure. Payee-level triggers identify which specific payee needs processing. Mass triggers function differently.

See Setting Up Mass Triggers.

Segmentation triggers can only be defined with effective-dated records. Retroactive triggers can be defined only with records using Effective Date, Begin-End Date, or Fixed Date. Iterative triggers can be defined with non-effective-dated records. If you ignore these requirements, the system will generate an error message stating that the trigger will not be generated from the record.

To set up a trigger:

1. Select the country.

   All triggers are defined at the country level because retroactive methods, process definitions, and trigger event IDs are uniquely defined by country. The same trigger may be processed differently in different countries.

2. Specify which record or field combination needs to be sensitive to data changes.

   You can indicate that the entire record is to be sensitive to data changes (a record-trigger level), meaning that data changes to any field in the record trigger an action, or indicate that specific field combinations in the record are to be sensitive to data changes (a field-trigger level).

   For retroactive, segmentation, and iterative triggers, you can define value-qualified triggers, representing trigger conditions where the field must be changed to a value on a specified list for the trigger to be generated.

3. For retroactive and segmentation triggers, create a trigger event definition.

   The trigger event definition tells the system what to do when the trigger is activated. Iterative triggers don’t have trigger event definitions, because their only function is to process a payee for the current open calendar; therefore, the defined event is always the same.

4. Create the trigger setup.

   On the Trigger Definitions - Trigger Definitions page, you define the type of trigger (iterative, retroactive, or segmentation), whether an entire record or one or more record and field combinations are to be sensitive to data changes, and which trigger event definition is associated with the trigger (for retroactive and segmentation triggers). If you choose to make one or more record and field combinations that are sensitive to data changes, you need to define the fields and, if applicable, their associated values.

Note. Trigger data is generated by the online system, based on conditions that you specify during setup. Additionally, you can manually enter trigger rows.

Pages Used to Set Up Trigger Definitions

Defining Triggers

Access the Trigger Definitions page.

Country	Displays a definition that applies to one country.
Record (Table) Name	Displays the record (table) name that you selected to access this page. Can stand alone or be part of the record and field combination that generates a trigger in response to an online data change.
Trigger Status	To activate the trigger definition, select Active. To have no triggers generated, select Inactive.
Trigger Type	Displays the trigger type, which is based on the type of trigger that you selected to access this page. Options are: Iterative, Retro, and Segmentation.
Trigger Level	Select Record to have the trigger activated if any data change takes place to any field in the record. Select Field to indicate that the trigger is to be activated if any data change affects the record and field combination. You indicate the field of the record and field combination in Field Name in the Trigger List group box. If you select Field, Field Name contains the specific field that generates a trigger if it’s changed.
Trigger Event ID and Primary Event ID	Trigger Event ID is a required field, defined at the record level for retroactive and segmentation. Enter an event ID that you defined on the Retro Event Definition page or Segmentation Event Definition page. This field isn’t used for iterative triggers, because they aren’t dependent on event IDs. This field isn’t available when the trigger type is Segmentation and trigger level is Field. Primary Event ID appears only when the trigger type is Retro and the trigger level is Field. Enter an event ID that you defined on the Retro Event Definition page. This event ID handles the case when the trigger level is Field and a prior row cannot be found—meaning that the changed, added, or deleted row is the first row in the buffer. In such a case, a retroactive trigger is generated using the primary retroactive event ID specified.
Trigger Effdt Type	Displays one of these values, based on your selection in Record (Table) Name: Effective Date Begin-End Date Fixed Date: This value can be used only with retroactive triggers. You must pass a date as a parameter to the generic PeopleCode function. This date is used as the effective date for the trigger. Regardless of the number of data changes, only one trigger is generated. Note. For the Segmentation trigger type, the record can only be effective-dated. Other Trigger Effdt Type values aren’t allowed.

If you selected Field in the Trigger Level field, the Trigger List group box becomes available.

See Also

Defining Backward and Forward Retroactive Processing Limits

Indicating Which Field Values Initiate Actions

Access the Trigger Definitions - Field Values page.

Field Values

No Match on Field Value Option

Using the options in this group box, you can specify a default trigger event ID to use when a change to a field affects values besides those you listed on the Field Values page. You need these options only if changes to other values in the field are to trigger processing.

Example

You’re modifying the Pay Rate Change value in the HR Action field to trigger retroactive processing but aren’t changing the effective date of other values, such as Family Status Change and Hire, in the same field to trigger retroactivity. To use the Trigger Definitions - Trigger Definitions page to specify one value for retroactive processing:

1. Enter the record (for this example, Job table) on the Add search page, and select Retro as the trigger type.

2. Select a trigger level of Field and the appropriate retroactive event ID.

3. In the Field group box, enter the field (Action) for which to generate a retroactive trigger, and select the Dependent on Field Value check box.

4. On the Trigger Definitions - Field Values page, define the exact value (Pay Rate Change) that you want to make sensitive to retroactive changes and the process to use when calculating retroactivity, by linking the value to a retroactive event ID.

See Also

Defining Retroactive Processing

Implementing Triggers

You need to implement triggers for every trigger record in Trigger Definition Setup.

Enter the following PeopleCode on SavePostChange for a field on this record. Because this PeopleCode has been defined at this level, it’s run in any component that uses the record (provided that record fields aren’t used as related-display fields).

The PeopleSoft system has delivered this PeopleCode on some records in the database. To prevent these records from generating triggers, remove the following PeopleCode from these records:

1. Declare the function that generates triggers:

   Declare Function Generate_Triggers PeopleCode 
   FUNCLIB_GP.TRGR_FUNCTIONS FieldFormula;

2. Declare a local date variable as:

   Local date &L_DT;

3. Invoke the function as:

   Generate_Triggers(EMPLID, &L_DT);

Details

The function Generate_Triggers is defined in FUNCLIB_GP.TRGR_FUNCTIONS.FieldFormula and needs two parameters when it’s invoked. The parameters are:

1. &P_EMPLID

   Indicates the EMPLID for which the triggers are to be generated. Use field EMPLID for &P_EMPLID.

2. &P_FIXED_DT

   The value to be used for trigger effective date for records where Trigger Effdt Type is Fixed Date. It’s ignored for records where Trigger Effdt Type is Effdt or Begin-End Date. Use &L_DT for &P_FIXED_DT.

The variable &L_DT needs to be assigned a value only in case of the Fixed Date type of triggers. Examples are the positive input records, the Manual Positive Input table (GP_PI_MNL_DATA) and the Manual Positive Input Supporting Element Override table (GP_PI_MNL_SOVR).

Note. You can enter PeopleCode that can invoke the function only if certain conditions are met, as discussed in example 2 below.

The following examples are from PeopleCode that’s delivered with the database. The examples show changes necessary for any additional records that are to generate triggers.

Example 1: Trigger Record = GP_PYE_SOVR

Sample PeopleCode:

PeopleCode on GP_PYE_SOVR.EMPLID.SavePostChange
Declare Function Generate_Triggers PeopleCode 
FUNCLIB_GP.TRGR_FUNCTIONS FieldFormula;
Local date &L_DT;
/*-----Function to generate Triggers for Global Payroll---*/
Generate_Triggers(EMPLID, &L_DT);

Explanation

&L_DT isn’t assigned a value, because Trigger Effdt Type for the Payee Supporting Element Override table (GP_PYE_SOVR) is not Fixed Date.

Example 2: Trigger Record = GP_PI_MNL_DATA (Manual Positive Input)

This record has Trigger Effdt Type is Fixed Date.

Sample PeopleCode:

PeopleCode on GP_PI_MNL_DATA.LASTUPDDTTM.SavePostChange
Declare Function Generate_Triggers PeopleCode 
FUNCLIB_GP.TRGR_FUNCTIONS FieldFormula;
  Local date &L_DT;
  Local Rowset &L_RS0;
  Component datetime &C_CAL_IDNT_TS;
  /*-----Function to generate Triggers for Global Payroll---*/
  &L_RS0 = GetLevel0();
  &L_DT = &L_RS0(1).GP_PI_MNL_D.PRD_END_DT.Value;
  If All(&C_CAL_IDNT_TS) Then
   Generate_Triggers(EMPLID, &L_DT);
  End-If;

Explanation

&L_DT must be set to a value to be used as the trigger effective date for triggers generated from positive input.

With positive input, triggers must be generated with the period end date (for the calendar that has the positive input). So, &L_DT is set in this way:

&L_RS0 = GetLevel0();
&L_DT = &L_RS0(1).GP_PI_MNL_D.PRD_END_DT.Value;

Note. GP_PI_MNL_D.PRD_END_DT has been assigned the value of PRD_END_DT for the calendar through earlier PeopleCode on GP_PI_MNL_DATA.ENTRY_TYPE_ID.RowInit.

The function can now be invoked. In case of positive input, the trigger-generation mechanism needs to be invoked only if the calendar that has positive input has been identified:

If All(&C_CAL_IDNT_TS) Then
  Generate_Triggers(EMPLID, &L_DT);
End-If;

Note. You must define all the required trigger types. If a record is defined to have a trigger type of Retro, only a retroactive trigger is generated. An iterative trigger isn’t automatically generated. In such a case, define a record to have retroactive and iterative trigger types. It’s highly recommended that when you define a retroactive or segmentation trigger, you define an iterative trigger. If a calendar group has been calculated and data changes are subsequently made, unless an iterative trigger is defined, any retroactive or segmentation triggers generated from the data changes aren’t processed until the next Identify phase.

See Also

Reviewing PeopleSoft Delivered Triggers

Viewing and Managing Triggers

This section discusses how to:

• View, add, or cancel segmentation triggers.

• View, add, or cancel retroactive triggers.

• View or change the trigger status for iterative triggers.

• View iterative triggers by calendar group ID.

Pages Used to View and Manage Triggers

Viewing, Adding, or Canceling Segmentation Triggers

Access the Review Triggers - Segmentation page.

Country	Displays the country to which the trigger applies.
Effective Date	Displays the trigger effective date in relation to which the period or elements are segmented.
Event ID	Displays the event ID, which tells the system which segmentation type to use to process segmentation events and which elements to segment if you use element segmentation. The event IDs displayed here are those that you defined on the Segmentation Event Definition page.
Description	Displays a description of the trigger event ID that you defined on the Segmentation Event Definition page.
Trigger Level	Options are: Payee: Select to have all of a payee’s jobs processed for segmentation. Job: Select to have segmentation occur for one employee record number (job) and not for other jobs.
Empl Rcd# (employee record number)	Select the employee record number for which you want to create a trigger. If you select Payee as the trigger level, the value that appears in this field is 0. If you select Job, that particular job (Empl Rcd#) appears.
Trigger Status	Options are: Active: Select if the trigger is active. Canceled: Enables you to cancel an active segmentation trigger. After you save the page, the trigger no longer appears if you reenter the page.
Trigger Source	Select a trigger source. A trigger can have two different sources. Trigger rows are generated by the online system, based on conditions that you specify during ; you can manually insert trigger rows that weren’t created based on predefined rules. Options are: Automatic: Indicates triggers that were created based on predefined conditions that you specify during setup. Manual: Indicates triggers that were manually entered on this page. For a manually inserted row of trigger data, the trigger source is Manual and the trigger status is Active.
Timestamp	The day and time the trigger was created.

Adding Manual Segmentation Triggers

For a manually inserted row of trigger data:

• You define the country and effective date on the Payee Triggers - Segmentation page.

  A trigger is created for a payee, and segmentation occurs. The system uses the effective date that you specify as the segmentation date, as with automatic segmentation.

• You must connect any trigger that you add on the Payee Triggers - Segmentation page to an event ID.

  The system uses the event ID that you specify on the Payee Triggers - Segmentation page to determine which type of segmentation to use and which elements to segment in the case of element segmentation.

The trigger source is Manual, and the trigger status is Active.

Note. Unlike automatically generated triggers, manual triggers are independent of any database change that’s defined by a record or record and field combination on the Triggers Definition page. It’s important to understand the potential consequences of creating manual triggers. Because they aren’t linked to a specific data change, you might segment periods and elements where nothing has changed.

Updating and Canceling Segmentation Triggers

For automatically and manually generated rows of trigger data:

• The event ID is changeable.

• You can change the trigger status from Active to Canceled.

• You cannot reinstate a canceled trigger; you must add a new manual trigger.

For the effective date on generated rows of trigger data:

• The effective date on the Payee Triggers - Segmentation page is the date in relation to which segmentation occurs.

• The effective date can be changed on a manually generated trigger.

• You cannot alter the effective date of a trigger that was generated by the system based on predefined setup rules.

See Also

Segmentation and Retro

Viewing, Adding, or Canceling Retroactive Triggers

Access the Review Triggers - Retro page.

Country	Displays the country to which the trigger applies.
Trigger Effective Date	Displays the trigger effective date that the system uses to determine how many previous periods to recalculate.
Trigger Event ID	Displays the trigger event ID, which tells the system which retroactive process definition to use when an event triggers retroactivity.
Description	Displays the description of the trigger event ID that you defined on the Retro Event Definition page.
Trigger Status	Select a trigger status. Options are: Canceled: Indicates that the trigger will not be processed. A canceled trigger no longer appears on the page. Unprocessed: Indicates that the trigger hasn’t been processed.
Retro Trigger Source	Select a retroactive trigger source. A trigger can have two different sources. Trigger data is generated automatically by the online system based on conditions that you specify during setup, or you can manually insert trigger rows that weren’t created automatically based on predefined rules. Options are: Automatic: Indicates triggers that were created based on predefined conditions that you specify during setup. Manual: Indicates triggers that were manually entered on the Payee Triggers - Retro - Unexpanded page. For a manually inserted row of trigger data, the trigger source is Manual and the trigger status is Unprocessed.
Trigger Tag	If a trigger is utility-generated, this field describes the source of the trigger.
Timestamp	The day and time the trigger was created.

Adding Manual Retroactive Triggers

For a manually inserted row of trigger data:

• You define the country and effective date on the Payee Triggers - Retro page.

  A retroactive trigger is created for that payee, and retroactive processing occurs regardless of whether changes are made to the database. The system uses the effective date to determine which periods to recalculate, as with standard retroactivity.

• Any trigger that you add to the Payee Triggers - Retro page must be connected to an event ID.

  The system uses the event ID that you specify to determine how retroactivity should be processed so that when that trigger gets expanded and is used in a batch, the batch process knows which retroactive process to use.

• The trigger source is Manual, and the trigger status is Unprocessed.

Note. Unlike automatically generated triggers, manual triggers are independent of any database change that’s defined by a record or record and field combination on the Triggers Definition page. It’s important to understand the potential consequences of creating manual triggers. Because they aren’t linked to a specific data change, you might process retroactivity in previous periods, where nothing has changed.

Warning! If a retroactive trigger is added or canceled, this isn’t the only required action. The corresponding data in the database must be adjusted accordingly.

Updating and Canceling Retroactive Triggers

For automatically and manually generated rows of trigger data:

• The event ID may be changed.

• You can change the trigger status from Unprocessed to Canceled.

  After a trigger is processed, you cannot alter the trigger status, because it’s no longer unprocessed and therefore doesn’t appear on the page anymore.

• You cannot reinstate a canceled trigger.

  You must add a new manual trigger.

For the trigger effective date on generated rows of trigger data:

• The trigger effective date on the Payee Triggers - Retro page is the date in relation to which retroactive processing occurs.

• The trigger effective date can be changed on a manually generated trigger (the trigger source is Manual).

• You cannot alter the trigger effective date of a trigger that has been generated by the system based on predefined setup rules.

Warning! Canceling a trigger does not undo the database change that created the trigger. If there’s retroactivity for another reason, this change can be picked up when prior periods are recalculated.

Viewing or Changing the Trigger Status for Iterative Triggers

Access the Review Triggers - Iterative page.

Country	Displays the country to which the trigger applies.
Calendar Group ID	Identifies the calendar group that’s targeted to process the iterative trigger.
Trigger Source	Select a trigger source. An iterative trigger can have two different sources. Trigger data is generated by the online code based on conditions that you specify during setup or by the system during batch processing. Options are: Batch: Indicates triggers that were generated by batch processing. Online: Indicates triggers that were created by the online code.
Trigger Status	Select a trigger status. Options are: Canceled: Indicates that the trigger isn’t to be processed. Unprocessed: Indicates that the trigger hasn’t been processed.
Timestamp	The day and time the trigger was created.

Adding Manual Iterative Triggers

On this page, you cannot manually insert a row of trigger data.

Updating and Canceling Iterative Triggers

For automatically generated rows of trigger data, you can change the trigger status from Unprocessed to Canceled. After a trigger is processed, you cannot alter the trigger status, because it’s no longer unprocessed and therefore doesn’t appear on the page anymore.

Viewing Iterative Triggers by Calendar Group ID

Access the Iterative Triggers - CalGrpID page.

EmplID	Lists all payees in the selected calendar group who have unprocessed iterative triggers.
Trigger Source	Displays the trigger source. An iterative trigger can have two different sources. Trigger data is generated automatically by the online code based on conditions that you specify during setup or by the system during batch processing. Options are: Batch: Indicates triggers that were generated by batch processing. Online: Indicates triggers that were created by the online code.
Trigger Status	Select a trigger status. Options are: Canceled: Indicates that the trigger isn’t to be processed. You can cancel automatically generated triggers by setting the trigger status to Canceled. Unprocessed: Indicates that the trigger has not been processed.

Reviewing PeopleSoft Delivered Triggers

The Global Payroll core application delivers the following list of record.fields that have trigger PeopleCode attached to facilitate trigger definition. Corresponding trigger definitions require trigger event IDs; therefore, it is your responsibility to set them up. All trigger definitions and trigger event IDs should be set up and defined based on statutory or customer-specific business logic.

The following list is delivered as a starting point. You can add PeopleCode to other fields to meet customer-specific business needs, and delete the PeopleCode from any of these fields:

• JOB.REPORTS_TO

• COMPENSATION.EMPLID

• GP_PI_MNL_SOVR.SETID

• GP_PYE_OVRD.ARR_PYBK_AMT

• GP_PYE_OVR_SOVR.SOVR_VAL_DT

• GP_PYE_SOVR.EMPLID

• PERS_DATA_EFFDT.EMPLID

• CONTRACT_DATA.EMPLID

• WKF_CNT_TYPE.EMPLID

• SCH_ASSIGN.EMPLID

• GP_ABS_EVENT.EMPL_RCD

• GP_SEG_TRGR.CAL_RUN_ID

• GP_SEG_TRGR_VW.CAL_RUN_ID

• GP_RTO_TRGR.CAL_RUN_ID

• GP_RTO_TRGR_VW.CAL_RUN_ID

• GP_RTO_TRG_CTRY.CAL_RUN_ID

• GP_ABS_OVRD.PIN_GCTL_NUM

• GP_PYE_SECT_DTL.RECALC_IND

• JOB_JR.EMPLID

• ADDRESSES.EMPLID

• BEN_PROG_PARTIC.EMPLID

• GP_PI_MNL_DATA.PIN_NUM

• GP_PI_MNL_D_VW.PIN_NUM

• GP_PI_MNL_E_VW.PIN_NUM

• HEALTH_BENEFIT.EMPLID

• LIFE_ADD_BEN.EMPLID

• PERSON.EMPLID

• PER_ORG_ASGN.EMPLID

• PRIMARY_JOBS.EMPLID

Because Compensation is a child of Job, it’s highly suggested that only retroactive and iterative triggers be defined for this record. Defining a segmentation trigger at the record level for Compensation can have adverse effects. For each subsequent Compensation row dated after the changed row, a trigger is generated besides the changed row. As a result, too many triggers are generated and each additional trigger causes unwanted segmentation. It is recommended that you define the segmentation trigger using JOB.COMP_RATE at the record and field level.

The positive input records, the Manual Positive Input table (GP_PI_MNL_DATA) and the Manual Positive Input Supporting Element Override table (GP_PI_MNL_SOVR), require that a calendar group be identified for triggers to be generated from these records. Once identified, triggers are generated even if finalized.

Note. It’s recommended that you set up period segmentation triggers for changes in the Pay System Flag and Pay Group fields on the Job record.