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:

• Trigger uses.

• Trigger table data.

• Trigger generation.

• Managing used or obsolete triggers.

• Segmentation triggers with earning and deduction assignments.

• Defining triggers manually.

Trigger Uses

In Global Payroll, the mechanism used to detect online data changes that should result in iterative, retroactive, or segmentation processing is called a trigger. To set up triggers, you select the database records and fields that you want to make sensitive to data changes such as pay increases, job location changes, and terminations; then, when the change occurs, the system writes a line of data to a table called a trigger table to tell the system how to process the change.

There are three types of triggers:

• Iterative

  An iterative trigger tells the system to process (or reprocess) a payee in the current open calendar, possibly because payee data has changed or the payee was placed in suspended mode during batch processing. The system generates only one iterative trigger per payee per open calendar group, regardless of the number of calendars in the calendar group. When data changes for the payee, the system (using 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.

• Retroactive

  A retroactive (or retro)trigger tells the system to reprocess previously calculated (closed) calendars. For example, this can occur when a payee's rate of pay changes and the change goes back to a prior calendar. The payroll data must be reprocessed to ensure that the payee receives the correct payment amounts.

  See Defining Retroactive Processing.

• Segmentation

  A segmentation trigger tells the system to segment all or a subset of payroll elements in a pay run in response to a change in payee data.

  See Defining 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.

  See Managing Automatically Generated Triggers and Defining Triggers Manually.

  Note. You can generate triggers manually only for retroactive and segmentation triggers.

• Automatically: Requires 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, the system writes the data needed to process the change to a trigger table. Each type of trigger has a separate table for storing this data.

Iterative Trigger Table

The information generated by an iterative trigger is stored in the iterative trigger table (GP_ITER_TRGR). This table contains the following data:

When an iterative trigger is generated by a data change, the system writes the employee ID, the country, and the calendar run ID along with other information to the trigger table to facilitate iterative processing by the batch code.

Among other things, this data tells the system:

• Which payees to process or reprocess.

• Which open calendars to process.

In addition, the system uses the RECNAME, FIELDNAME, TRGR_FLD_VAL_CHAR, TRGR_FLD_VAL_DT, and TRGR_FLD_VAL_NUM fields to identify the source of an iterative trigger (the record, field, and/or field value changes that generate a trigger). This information enables a clearer understanding of what causes iterative processing of a payee's earnings, and can be used to facilitate debugging or answer queries.

Note. You can view the trigger source data stored in this table on the Iterative page.

See Viewing or Changing the Trigger Status for Iterative Triggers.

Retroactive Trigger Table

The information generated by a retroactive trigger is stored in the retroactive trigger table (GP_RTO_TRGR). This table contains the following data:

When a retroactive trigger is generated by a data change, the system writes the employee ID, the effective date of the change (also called the trigger effective date), the country, and the associated event ID along with other information to the trigger table 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 to use to recalculate prior periods.

In addition, the system uses the RECNAME, FIELDNAME, TRGR_FLD_VAL_CHAR, TRGR_FLD_VAL_DT, and TRGR_FLD_VAL_NUM fields to identify the source of a retro trigger (the record, field, and/or field value changes that generate a trigger). This information enables a clearer understanding of what causes retroactive processing of a payee's earnings, and can be used to facilitate debugging or answer queries.

Note. You can view the trigger source data stored in this table on the Retro page.

See Viewing, Adding, or Canceling Retroactive Triggers.

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 change in hire date and a retroactive change in pay group might both generate retro triggers for the same event. In the case of multiple retro triggers, 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). This table contains the following data:

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

Among other things, this data tells the system:

• Which payees to process.

• The dates to use for the period segments or slices.

• What type of segmentation to use and the elements to segment (in the case of element segmentation).

In addition, the system uses the RECNAME, FIELDNAME, TRGR_FLD_VAL_CHAR, TRGR_FLD_VAL_DT, TRGR_FLD_VAL_NUM, and TRGR_FLD_VAL_PIN fields to identify the source of a segmentation trigger (the record, field, and/or field value changes that generate a trigger). This information enables a clearer understanding of what causes segmentation of a payee's earnings, and can be used to facilitate debugging or answer queries.

Note. You can view the trigger source data stored in this table on the Segmentation page.

See Viewing, Adding, or Canceling Segmentation Triggers.

Trigger Generation

This section discusses the concept of trigger effective date types and trigger levels, and describes how and when the system generates triggers based on effective date types and trigger levels.

Effective Dates and Effective Date Types

All triggers except iterative triggers are stored in the trigger tables with their trigger effective dates (TRGR_EFFDT). These dates are based on—but are not necessarily identical to—the dates of the database changes that cause the triggers to be generated. In the PeopleSoft system, these database change dates are recorded in the following fields: Effective Date, Begin and End Date, and Fixed Date fields. Because of the central role played by these fields, retro and segmentation triggers can only be generated from dated records: retroactive triggers can only be defined for records with Effective or Begin and End Date fields, or records with Fixed Date fields; and segmentation triggers can only be defined for records with Effective Date fields, with one exception: the system can also generate segmentation triggers from the begin and end dated earning/deduction assignment record GP_PYE_OVRD.

Based on which date field is the source of the trigger effective date, every retro and segmentation trigger falls into one of the following effective date types:

• Effective Date: Trigger date is based on an Effective Date field.

• Begin/End Date: Trigger date is based on a Begin or End Date field.

• Fixed Date: Trigger date is based on a fixed date that has been passed as a parameter to the generic PeopleCode function Generate_Triggers.

  See Implementing Triggers.

When the system processes retro and segmentation triggers, it uses the effective date type determine what date to use as the trigger effective date.

Note. Iterative triggers do not use the concept of trigger effective dates, since the change date is irrelevant to their function, which is to trigger the calculation or recalculation of the current pay run for a specific payee. They can be defined for non-effective-dated records as well as effective dated and begin and end dated records.

Trigger Levels

When you set up triggers in PeopleSoft Global Payroll, you must specify the level at which the system responds to database changes: you can set up the system to generate triggers in response to effective or begin and end dated changes to any field in a record (trigger level = Record), to all changes to a specific field in the record (trigger level = Field, Non Value Based), or only when a specific value is entered in the field (trigger level = Field, Value Based). The trigger level determines when and under what conditions the system generates triggers.

Rules for Iterative Triggers: Generating Triggers

Iterative triggers are generated only when an open calendar group exists; the calendar group must have been "Identified."

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

When the trigger level is Field, Non-Value-based, the system generates an iterative trigger if:

• A row and the field are changed.

• A row is added or deleted.

  Note. For Field, Non-Value-based triggers, adding a row causes a trigger to be generated only if the field value changes.

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

Rules for Retroactive Triggers: Setting Trigger Effective Dates and Generating Triggers

When Trigger Effective Date Type is Effective Date:

• By default, if a row is added, the system uses the effective date as the trigger effective date.

  Note. Although the default is to use the change date (the effective date of the added row) as the trigger effective date, you can modify effective dating of retro triggers on the Trigger Definitions – Field Values page so that the trigger date falls before or after the actual change date.

  See Indicating Which Field Values Initiate Actions.

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

• If a row is changed, the system uses the earlier of the initial effective date and the changed effective date as the trigger effective date.

The initial effective date is the effective date with which the row was loaded. The changed effective date is the effective date of 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 is different from the initial effective date.

When Trigger Effective Date Type is Begin/End Date:

• By default, if a row is added, the system uses the begin date as the trigger effective date.

  Note. Although the default is to use the change date (the begin date of the added row) as the trigger effective date, you can modify effective dating of retro triggers on the Trigger Definitions – Field Values page so that the trigger date falls before or after the actual change date.

  See Indicating Which Field Values Initiate Actions.

• If a row is deleted, the system uses the initial begin date as the trigger effective date.

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

The initial begin date is the begin date with which the row was loaded. The changed begin date is the begin date of 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 is 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, the system uses the begin date as the trigger effective date even if you change the end date. If an existing row is voided, and a new row is created, the system uses the begin date as the trigger effective date.

When Trigger Effective Date 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:

• The system generates a retro trigger if a row is added, changed, or deleted.

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

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

• If a row is added or deleted, the system finds 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, the system generates a retroactive trigger.

• If a row and the field value are changed, the system generates a retroactive trigger regardless of whether 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 the "old date" and that the effective date after the change is the "new date"):

  • If the field is changed, the system generates a retroactive trigger.

  • The system finds 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.

  • The system finds 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.

  In this case, 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, the system generates a retroactive trigger only if the value of the added, changed, or deleted row matches a value you specified earlier or you've chosen to generate a trigger even if no values match.

Rules for Segmentation Triggers: Setting Trigger Effective Dates and Generating Triggers

With the exception of the begin and end dated earning and deduction assignment record GP_PYE_OVRD, you can generate segmentation triggers only from records whose Trigger Effective Date Type is Effective Date.

See Segmentation Triggers with Earning and Deduction Assignments.

Segmentation triggers aren't generated for deleted rows.

When Trigger Effective Date Type is Effective Date:

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

• If a row is changed, the system uses the effective date of the change as the trigger effective date (not the initial effective date).

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

When Trigger Effective Date Type is Begin/End Date:

Note. The only begin and end dated record for which you can define segmentation triggers is the earning and deduction assignment record GP_PYE_OVRD

• If a row is added, the system uses the begin date as the effective date of the initial trigger, and the end date + 1 as the effective date of the terminal trigger.

  Note. When a segmentation trigger is generated from the begin and end dated record GP_PYE_OVRD, the system creates two triggers, each with a different trigger effective date—one based on the begin date, and another based on the end date. For example, assume that you assign a deduction to a payee with begin and end dates of June 10 and June 20, and that you process payrolls on a monthly calendar. The system creates a trigger with an effective date of June 10 (the initial trigger), and a second trigger with an effective date of June 21 (the terminal trigger with an effective date of end date + 1). Based on these trigger dates, the system divides the period into three segments: 1–10 June, 11–20 June, and 21–30 June.

• If a row is changed and the end date is the only changed field, the system uses the changed end date + 1 as the new terminal trigger effective date. If a row is changed and the begin date is the only changed field, the system uses the changed begin date as the new initial trigger effective date.

The initial begin date is the begin date with which the row was loaded. The changed begin date is the begin date of 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 is 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.

When Trigger Level is Record, the system generates a segmentation trigger if a row is added or changed.

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

• If a row is added or changed, the system finds 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, the system generates a segmentation trigger.

• If a prior row cannot be found:

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

  • If it is a new row, the system generates a segmentation trigger for all specified fields.

When Trigger Level is Field, Value-based, besides observing the rules for non-value-based triggers, the system generates a segmentation trigger only if the value of the added or changed row matches a value you specified earlier or you have chosen to generate triggers even if no values match.

Managing Used or Obsolete Triggers

The Global Payroll system automatically marks retro and iterative triggers as used once they initiate the required processing so that they do not affect future calculations. In addition, you can manually cancel both iterative and retro triggers that have been created in error or that you do not want to impact payroll processing. By contrast, segmentation triggers are designed to remain active in the system, since if a segmentation event occurs during a calculation period, it should trigger segmentation every time the period is processed. However, there are times when segmentation events need to be modified or removed after they are entered in the system, either because they should not have been entered at all, the dates of the event were entered incorrectly, or other data was recorded incorrectly. The Global Payroll system addresses the problem of unnecessary triggers left by segmentation events by automatically deleting them in response to the following data changes at each of the three trigger levels (Record, Field-Non Value Based, Field-Value Based ):

Important! The system only deletes automatically generated triggers, not manually generated triggers or mass triggers.

Note. Although the system automatically removes segmentation triggers in the situations described here, you can also manually cancel segmentation triggers just as you can iterative and retro triggers. To manage and cancel triggers, use the pages in the Review Triggers (GP_TRIGGER) and Review Iterative Triggers (GP_TRGRITER_CALRUN) components.

Example: Removing a Segmentation Trigger In Response to a Change In the Effective Date of a Row

Assume that there is a Field, Value Based trigger on the JOB record.

The field and field values defined to generate triggers are Action and PAY (pay rate change) or TER (termination).

Assume that you change the effective date of a termination action (TER) from November 15 to November 20.

When the effective date associated with this action changes, the system should:

• Delete the old trigger associated with the changed source row.

• Insert a new trigger with a new trigger effective date.

In this example, the effective date of the November 15 termination row changes to November 20. As a result, the system deletes the November 15 trigger and creates a new trigger with an effective date of November 20.

Example: Removing a Segmentation Trigger In Response to a Change In a Field Value

Assume that there is a Field, Value Based trigger on the JOB record.

The field and field values defined to generate triggers are Action and PAY (pay rate change) or TER (termination).

Assume that you change the Action value of an October 20 effective dated row from TER (termination) to DTA (data change).

When the effective date associated with this action changes, the system should delete the old trigger without creating a new one:

In this example, the value of the October 20 effective dated row changes from TER to DTA. Because DTA is not a recognized value for trigger generation (only TER and PAY are set up to generate triggers), the system deletes the trigger with the October 20 effective date without generating a new one.

Example: Removing a Segmentation Trigger In Response to a Change In a Field Value

Assume that there is a Field, Value Based trigger on the JOB record.

The field and field values defined to generate triggers are Action and PAY (pay rate change) or TER (termination).

Assume that you change the Action value of a July 1, 2005 effective dated row from DTA (data change) to PAY (pay rate change), and that there is a second, preexisting row with a value of PAY and an effective date of January 1, 2006. This example shows that the latter row is affected by the change to the earlier row:

In this example, the value of the July 1, 2005 effective dated row changes from DTA to PAY. Because trigger generation is based on field value changes, and there is no change between the July 1, 2005 and January 1, 2006 rows (both have a field value of PAY), the system deletes the trigger originally created for the latter row, and inserts a new trigger with a July 1, 2005 effective date. Note that there are no triggers for the DTA rows, as DTA is not a value that has been defined for trigger generation.

Special Rules for Field-Based Segmentation Triggers for Records Containing EFFSEQ (Effective Sequence) Field

There are special rules for managing field-based segmentation triggers if the record contains the field EFFSEQ (for example, the JOB record):

• When the trigger definition is Field – Non Value Based, the trigger generation PeopleCode inserts a trigger for a given effective date using only the highest effective sequence row. That is, only the highest effective sequence row per effective date matters when the trigger definition is Field – Non Value based. This prevents unnecessary trigger generation when you enter first one effective sequence row and then another with the same effective date to correct errors in the first row.

• When the trigger definition is Field – Value Based, the trigger generation PeopleCode inserts a separate trigger for each effective sequence row with a given effective date. In other words, all effective sequence rows are processed when the trigger definition is value based. This is to accommodate situations in which it is necessary or desirable to have multiple effective sequence rows. For example, there are some fields such as JOB.ACTION in which you might enter a transfer and a promotion one after another on the same day. This field would most likely have a value-based trigger definition.

Segmentation Triggers with Earning and Deduction Assignments

In Global Payroll you can define segmentation triggers only for effective dated records, with one exception: you can define segmentation triggers for the begin and end dated earning and deduction assignment record GP_PYE_OVRD. This exception enables you to assign an earning or deduction to a payee on the Element Assignment by Payee (GP_ED_PYE) or Payee Assignment by Element (GP_ED_ELEM) components, and segment (and prorate) the element when the assignment begin date comes after the pay period begin date, and/or the assignment end date comes before the period end date.

For example, assume that an earning element E1 for 300 USD is assigned to a payee with begin and end dates of 10 and 20 June respectively (assume a monthly pay period), and that the system is set up to trigger segmentation from the earning and deduction assignment record for this element. Based on the assignment begin and end dates, the system will slice the pay period into three segments and process–and prorate–the element in the second slice:

Note. The only type of segmentation that can be defined for the GP_PYE_OVRD record is element segmentation.

See Also

Setting Up Segmentation Triggers for The Begin and End-Dated Earning and Deduction Assignment Record (GP_PYE_OVRD)

Defining Triggers Manually

In addition to setting up the system to generate triggers automatically, you can enter triggers manually on the Review Triggers component (GP_TRIGGER) by selecting the trigger type, the trigger effective date, the process definition, and other data needed by the system to initiate retroactive or segmentation processing.

See Managing Automatically Generated Triggers and Defining Triggers Manually.

Setting Up Trigger Definitions

This section provides an overview of trigger definition for iterative, retro, and segmentation triggers, and describes the pages used to set up triggers.

See Also

Using Calendars

Defining Retroactive Processing

Defining Segmentation

Defining Segmentation Events and Types

Understanding Trigger Definition Setup

This section discusses the setup steps for automatic trigger generation by the online system.

Note. PeopleSoft recommends 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 phase.

Setting Up Iterative Triggers

Iterative triggers can be defined for both effective and begin and end dated records, as well as for non-dated records.

To set up iterative Triggers:

1. Select Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Triggers, Trigger Definitions.

   The search page for the Trigger Definitions component (GP_TRGR_SETUP) appears.

2. Select the Add a New Value tab.

3. On the Add a New Value tab, select a country, identify the record you want to make sensitive to data changes in the Record (Table) Name field, and select a trigger type of Iterative.

4. Click the Add button.

   The Trigger Definitions page appears.

5. On the Trigger Definitions page, select a Trigger Level of Record or Field.

   Select Record to generate a trigger in response to a change to any field in the record; select Field if you want the system to generate a trigger only in response to changes to a specific field or group of fields in the record.

   If you select Field, you must list the fields that you want to make sensitive to data changes in the List Fields With Trigger group box. You can further restrict the data changes that generate triggers by selecting the Dependent on Field Value Action check box for a specific field and specifying the values that trigger iterative processing.

Setting Up Retro Triggers

Retro triggers can be defined for both effective and begin and end dated records, as well as for fixed date records.

To set up retro triggers:

1. Select Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Triggers, Trigger Definitions.

   The search page for the Trigger Definitions component (GP_TRGR_SETUP) appears.

2. Select the Add a New Value tab.

3. On the Add a New Value tab, select a country, identify the record you want to make sensitive to data changes in the Record (Table) Name field, and select a trigger type of Retro.

4. Click the Add button.

   The Trigger Definitions page appears.

5. On the Trigger Definitions page, select a trigger event ID (or primary event ID if the trigger level is Field).

   Trigger event IDs tell the system how to process retroactive data.

   Note. Define trigger event IDs on the Retro Event Definition page.

   See Defining Trigger Event IDs.

6. On the Trigger Definitions page, select a Trigger Level of Record or Field.

   Select Record if you want the system to generate a trigger in response to a change to any field in the record; select Field if you want to system to generate a trigger in response to changes to a specific field or group of fields in the record.

   If you select Field, you must list the fields that you want to make sensitive to data changes in the List Fields With Trigger group box. You can further restrict the data changes that generate triggers by selecting the Dependent on Field Value Action check box for a specific field, clicking the List Field Values link, and specifying the values that trigger retro processing.

7. In addition, you must specify a trigger event ID or primary event ID at one of the following levels:

   • If you select Record as the trigger level, specify the trigger event ID in theTrigger Event ID field at the record level on the Trigger Definitions page.

   • If you select Field as the trigger level, and trigger generation is not dependent on specific field values, specify the trigger event ID at the field level in the List Fields With Trigger group box on the Trigger Definitions page.

   • If you select Field as the trigger level, and segmentation is dependent on specific field values, click the List Field Values link and specify the trigger event ID at the field value level in the Field Values group box on the Trigger Definitions – Field Values page.

   • In addition, if you select Field as the trigger level, you must enter a primary event ID at the record level in the Primary Event ID field on the Trigger Definitions page. This ID functions as the default event ID when the changed, added, or deleted row that triggers retro processing is the first row in the buffer (that is, a prior row cannot be found).

     Note. The Primary Event ID field appears only when the trigger type is Retro and the trigger level is Field.

Setting Up Segmentation Triggers for Effective Dated Records

In Global Payroll, you can set up segmentation triggers for effective dated records and for a single begin and end-dated record—the earning and deduction assignment record GP_PYE_OVRD. In this section we discuss the steps for setting up segmentation triggers for effective dated records.

To set up segmentation triggers for effective dated records:

1. Select Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Triggers, Trigger Definitions.

   The search page for the Trigger Definitions component (GP_TRGR_SETUP) appears.

2. Select the Add a New Value tab.

3. On the Add a New Value tab, select a country, identify the record you want to make sensitive to data changes in the Record (Table) Name field, and select a trigger type of Segmentation.

4. Click the Add button.

   The Trigger Definitions page appears.

5. On the Trigger Definitions page, select a Trigger Level of Record or Field.

   Select Record if you want the system to generate a trigger in response to a change to any field in the record; select Field if you want to system to generate a trigger in response to changes to a specific field or group of fields in the record.

   If you select Field, you must list the fields that you want to make sensitive to data changes in the List Fields With Trigger group box. You can further restrict the data changes that generate triggers by selecting the Dependent on Field Value Action check box for a specific field, clicking the List Field Values link, and specifying the values that trigger segmentation.

6. In addition, you must define a trigger event ID at the appropriate level:

   • If you select Record as the trigger level, define the trigger event ID at the record level on the Trigger Definitions page.

   • If you select Field as the trigger level, and segmentation is not dependent on specific field values, specify the trigger event ID at the field level in the List Fields With Trigger group box on the Trigger Definitions page.

   • And if you select Field as the trigger level, and segmentation is dependent on specific field values, click the List Field Values link and specify the trigger event ID at the field value level in the Field Values group box on the Trigger Definitions – Field Values page.

Note. The trigger event IDs tells the system what type of segmentation to use (period or element segmentation), and in the case of element segmentation, what elements (earnings, deductions, and other elements) to segment in response to a change in data. You define trigger event IDs on the Segmentation Event Definition page.

See Defining Segmentation Events and Types.

Setting Up Segmentation Triggers for The Begin and End-Dated Earning and Deduction Assignment Record (GP_PYE_OVRD)

You can set up segmentation triggers for the earning and deduction assignment record (GP_PYE_OVRD) if you want an assigned element to be sliced and prorated based on the assignment begin and end dates.

Note. If you want a segmented element to be prorated, you must associate the element with a proration rule on the earning and deduction definition pages.

To define a segmentation trigger for the earning and deduction assignment record:

1. Select Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Triggers, Trigger Definitions.

   The search page for the Trigger Definitions component (GP_TRGR_SETUP) appears.

2. Select the Add a New Value tab.

3. On the Add a New Value tab, select a country, enter GP_PYE_OVRD in the Record (Table) Name field, and select a trigger type of Segmentation.

4. Click the Add button.

   The Trigger Definitions page appears.

   When you define a segmentation trigger for the earning and deduction assignment record (GP_PYE_OVRD), the system automatically populates the fields on the Trigger Definitions page with these values:

   Field	Value	Explanation
   Trigger Level	Field	Segmentation triggers generated from the GP_PYE_OVRD record are field level triggers. The field is automatically defined as PIN_NUM (Element Name). This means that segmentation triggers are generated only when earnings or deductions are assigned to payees and entered in the PIN_NUM (Element Name) field on the Payee Assignment by Element or Element Assignment by Payee components.
   Trigger Effective Date Type	Begin-End Date	The GP_PYE_OVRD record is a begin and end dated record.
   Field Name	PIN_NUM	This is the only field on the GP_PYE_OVRD record that is defined to trigger segmentation.
   Dependent on Field Value	Selected	When you define Segmentation triggers for the GP_PYE_OVRD record, the system requires that you positively identify the specific earning or deduction elements that trigger segmentation. These elements are the field values that must be entered in the Element Name (PIN_NUM) field on the Payee Assignment by Element or Element Assignment by Payee components.

5. Click the List Field Values link to bring up the Trigger Definitions - Field Values page.

6. Use the Entry Type and Element fields on the Trigger Definitions – Field Values page to list the earnings and deductions that should trigger element segmentation when the assignment begin date comes after the pay period begin date, and/or the assignment end date comes before the period end date.

   In addition, specify one of the following trigger options for each element:

   • Segment This Element

     If you select this option, the system slices only the specified element.

   • Specify Trigger Event ID

     If you select this option, you must specify a trigger event ID. The system then slices the selected element and any other elements included in the element list identified by the trigger event ID.

     Note. The trigger event ID tells the system what elements (earnings, deductions, and other elements) to segment in response to a change in data. You define trigger event IDs on the Segmentation Event Definition page.

     See Defining Segmentation Events and Types.

     Warning! You must select the Active Anytime Within the Segment Period option on the Countries component (GP_COUNTRY) to fully implement segmentation triggers with the earning and deduction assignment record (GP_PYE_OVRD). If you do not select this option, the system issues the following warning when you add a segmentation trigger to a record: Warning -- 'Active Anytime within the Segment Period' on the Countries component has not been selected. (17000,4637) In order to take advantage of the functionality when the Earning/Deduction Assignment record (GP_PYE_OVRD) is indicated, you must select 'Active Anytime within the Segment Period' in the Process Payee Assignments group box on the Countries component.

Pages Used to Set Up Trigger Definitions

Defining Triggers

Access the Trigger Definitions page (Set Up HRMS, Product Related, Global Payroll & Absence Mgmt, Triggers, Trigger Definitions, Trigger Definitions).

Note. The fields on this page vary depending on the type of trigger you are creating and the values you select.

List Fields with Trigger

If you selectField in the Trigger Level field, the List Fields With Trigger group box becomes available.

Indicating Which Field Values Initiate Actions

Access the Trigger Definitions - Field Values page (click the List Field Values link on the Trigger Definitions page).

Field Values

No Match on Field Value Option

Use the fields in this group box to specify a default trigger event ID to use when a change to a field involves values other than those listed on the Trigger Definitions – Field Values page. Use these fields only if you want these other values to trigger iterative, retro, or segmentation processing.

Example: Using Offset Days with Retro Triggers

The PeopleSoft system considers the effective date of a termination entered in the Action field in the JOB record to be the first day that a payee is no longer working (in other words, the day before the termination is the last day the payee is considered active). If you attach a trigger to this field to process retroactive terminations, the system, by default, sets the trigger effective date equal to the date of the termination row in JOB. This can create problems when the termination effective date is equal to the pay period begin date (meaning, the last day worked is the last day of the prior pay period). For example, assume that you enter a termination in JOB on February 1 after processing and closing the January calendar. In this situation, the system generates a trigger with an effective date of February 1, which is within the current period—a period in which the payee is "inactive" and will not be picked up for processing. Because there is no trigger in the prior, closed period (January), this period will not be recalculated and any rules you have set up to generate termination payments will not be processed. To avoid this problem, set the offset days for the Termination action value in the JOB record equal to -1.

See Also

Defining Retroactive Processing

Implementing Triggers

To implement the trigger definitions you have defined, you must set up your system so that the records used in these definitions declare and call the function Generate_Triggers in one of their field's SavePostChange PeopleCode. This PeopleCode has already been added to most of the records for which you are likely to define triggers—such as JOB—so it is unlikely that you will have to perform this step more than a few times. However, if you do need to add a trigger to a record, complete these steps.

Note. We provide a list of the records to which the SavePostChange PeopleCode has been added at the end of this chapter.

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

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

• &P_EMPLID

  Identifies the EMPLID for which a trigger should be generated. Use field EMPLID for &P_EMPLID.

• &P_FIXED_DT

  Holds the value of the trigger effective date for records with a Trigger Effective Date Type of Fixed Date. It is ignored for records with a Trigger Effective Date Type of Effdt or Begin-End Date. Use &L_DT for &P_FIXED_DT.

The variable &L_DT needs to be assigned a value only in the case of Fixed Date type 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 invokes this function only if certain conditions are met, as discussed in example 2 below.

The following examples are taken from PeopleCode delivered with the database. They illustrate how to configure the PeopleCode for additional records in the system.

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

In this example, &L_DT isn't assigned a value, because the Trigger Effective Date 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 a Trigger Effective Date Type of 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;

In this example, &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 as follows:

&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 the 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. PeopleSoft recommends that when you define a retroactive or segmentation trigger, you also 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

Managing Automatically Generated Triggers and Defining Triggers Manually

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.

Understanding Trigger Management And Manual Trigger Entry

Use the Review Triggers (GP_TRIGGER) and Review Iterative Triggers (GP_TRGRITER_CALRUN) components to:

• Review and manage triggers generated automatically by the online system.

• Define retro and segmentation triggers manually when you want to bypass the setup for online trigger generation.

• View the source record or field for a trigger as well as the field value changes that cause iterative, segmentation, or retroactive processing. This information is useful for debugging and troubleshooting when you are trying to determine why a particular instance of iterative, retro, or segmentation processing took place.

Note. The system does not display source data for manually defined triggers.

Note. You cannot define iterative triggers manually using the Review Triggers (GP_TRIGGER) or Review Iterative Triggers (GP_TRGRITER_CALRUN) components.

Warning! The pages in the Review Triggers and Review Iterative Triggers components enable you to cancel triggers. Do not cancel triggers while a payroll run is processing. This can lead to errors in your payroll results.

Pages Used to Manage Triggers and Enter Trigger Manually

Viewing, Adding, or Canceling Segmentation Triggers

Access the Segmentation page (Global Payroll & Absence Mgmt, Absence and Payroll Processing, Prepare Payroll, Review Triggers, Segmentation).

Event ID

Select the Event ID tab.

Use the fields on the Event ID tab to view basic data such as the trigger effective date and trigger event ID for an automatically generated segmentation trigger, or add this data to define a trigger manually.

Source

Select the Source tab.

Use the Source tab to view the source record and field for a segmentation trigger.

The system displays either the source record, or both the source record and field for a trigger, depending on the trigger level:

Values

Select the Values tab.

Use the Values tab to determine what field value change caused the system to generate a segmentation trigger.

The system displays field values only for triggers at the following trigger levels:

Adding Manual Segmentation Triggers

To manually insert a segmentation trigger:

• Enter a country and an effective date on the Segmentation page – Event ID tab. The system uses the effective date entered here as the basis for the trigger effective date.

• Specify an event ID for the trigger on the Segmentation page – Event ID tab.

  The system uses the event ID to determine what type of segmentation to use and which elements to segment in the case of element segmentation.

The system sets the trigger source to Manual, and the trigger status to Active.

Note. Unlike automatically generated triggers, manual triggers are independent of any database change defined by a record or record and field combination on the Triggers Definition page. It is 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:

• You can change the event ID.

• 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 Segmentation page is the date in relation to which segmentation occurs.

• You can change the effective date of 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 Retro page (Global Payroll & Absence Mgmt, Absence and Payroll Processing, Prepare Payroll, Review Triggers, Retro).

Event ID

Select the Event ID Tab.

Use the fields on the Event ID tab to view basic data such as the trigger effective date and trigger event ID for an automatically generated retro trigger, or add this data to define a trigger manually.

Source

Select the Source tab.

Use the Source tab to view the source record and field for a retro trigger.

The system displays either the source record, or both the source record and field for a trigger, depending on the trigger level:

Values

Select the Values tab.

Use the Values tab to determine what field value change caused the system to generate a retro trigger.

The system displays field values (character, date, or numeric values) only for triggers at the following trigger levels:

• Field, Non-Value Based.

• Field, Value-Based.

Adding Manual Retroactive Triggers

To manually insert a retro trigger:

• Enter the country and an effective date on the Retro page.

  The system uses the effective date to determine which periods to recalculate, as in standard retroactivity.

• Connect the trigger to an event ID.

  The system uses the event ID that you specify to determine how retroactivity should be processed.

The system sets the trigger source to Manual and the trigger status to Unprocessed.

Note. Unlike automatically generated triggers, manual triggers are independent of any database changes to a record or a record and field combination. 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 periods where nothing has changed.

Warning! If you add or cancel a retroactive trigger, you should adjust the corresponding retroactive data in the database.

Updating and Canceling Retroactive Triggers

For automatically and manually generated rows of trigger data:

• You can change the event ID.

• 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 Retro page.

• 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 Retro page is the date the system uses to determine what periods to process.

• You can change the trigger effective date of a manually generated trigger (trigger source = 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 Iterative page (Global Payroll & Absence Mgmt, Absence and Payroll Processing, Prepare Payroll, Review Triggers, Iterative).

Calendar Group

Select the Calendar Group tab.

Use the fields on the Calendar Group tab to view basic data such as the trigger effective date and calendar group ID for an automatically generated iterative trigger.

Source

Select the Source tab.

Use the Source tab to view the source record and field for an iterative trigger.

The system displays either the source record, or both the source record and field for a trigger, depending on the trigger level:

Values

Select the Values tab.

Use the Values tab to determine what field value change caused the system to generate an iterative trigger.

The system displays field values (character, date, or numeric values) only for triggers at the following trigger levels:

• Field, Non-Value Based.

• Field, Value-Based.

Adding Manual Iterative Triggers

You cannot manually insert a row of trigger data on this page.

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 Iterative page.

Viewing Iterative Triggers by Calendar Group ID

Access the Review Iterative Triggers page (Global Payroll & Absence Mgmt, Absence and Payroll Processing, Prepare Payroll, Review Iterative Triggers, Review Iterative Triggers).

Name

Select the Name tab.

Use the fields on the Name tab to view basic data such as the EmplID, employee name, and status associated with an automatically generated trigger.

Source

Select the Source tab.

Use the Source tab to view the source record and field for an iterative trigger.

The system displays either the source record, or both the source record and field for a trigger, depending on the trigger level:

Values

Select the Values tab.

Use the Values tab to determine what field value change caused the system to generate an iterative trigger.

The system displays field values (character, date, or numeric values) only for triggers at the following trigger levels:

• Field, Non-Value Based.

• Field, Value-Based.

Reviewing PeopleSoft Delivered Triggers

To facilitate trigger generation, Global Payroll delivers the following records with trigger PeopleCode attached. These are delivered as a starting point. You can add trigger-generating PeopleCode to other records to meet your specific business needs, or delete the PeopleCode from any of these records:

Note. Global Payroll trigger-generation logic is stored in the FUNCLIB_GP.TRGR_FUNCTIONS FieldFormula PeopleCode. In order for a record to generate triggers, the GENERATE_TRIGGERS function stored there must be declared and called from the record in SavePostChange PeopleCode.

See Implementing Triggers.

• ADDRESSES

• BEN_PROG_PARTIC

• COMPENSATION

• CONTRACT_DATA

• DEP_BEN_ADDR

• DEP_BEN_EFF

• DEP_BEN_NAME

• GP_ABS_EVNT

• GP_ABS_OVRD

• GP_OFFCYCL_A_VW

• GP_OFFCYCL_M_VW

• GP_OFFCYCL_M_VW

• GP_OFFCYCL_U_VW

• GP_PI_MNL_DATA

• GP_PI_MNL_D_VW

• GP_PI_MNL_E_VW

• GP_PI_MNL_SOVR

• GP_PI_MNL_SSN

• GP_PYE_OVRD

• GP_PYE_OVR_SOVR

• GP_PYE_SECT_DTL

• GP_PYE_SOVR

• GP_RTO_TRGR

• GP_RTO_TRGR_VW

• HEALTH_BENEFIT

• JOB

• JOB_JR

• LIFE_ADD_BEN

• LIFE_ADD_BENEFC

• PERSON

• PERS_DATA_EFFDT

• PER_ORG_ASGN

• PRIMARY_JOBS

• SCH_ASSIGN

• SCH_MNG

• SCH_TBL

• WKF_CNT_TYPE

Note. PeopleSoft recommends that you set up period segmentation triggers for changes in the Pay System Flag and Pay Group fields on the JOB record.