Trigger Generation

This topic 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 Trigger Definitions - Field Values Page.

  • 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 Trigger Definitions - Field Values Page.

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