Understanding Triggers

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 absences, and can be used to facilitate debugging or answer queries.

See Iterative Page.

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 absences, and can be used to facilitate debugging or answer queries.

See Retro Page.

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, and TRGR_FLD_VAL_NUM 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 absences, and can be used to facilitate debugging or answer queries.

See Segmentation Page.

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.

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 to determine what date to use as the trigger effective date.

Trigger Levels

When you set up triggers in Absence Management, 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 date 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 be "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 Effdt 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 Effdt 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.

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:

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

For Absence Management, you can generate segmentation triggers only from records whose Trigger Effdt Type is Effective Date.

See Segmentation Page.

Segmentation triggers aren't generated for deleted rows.

When Trigger Effdt Type is Effective Date:

• If a row is added, the system uses 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).

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

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

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 DTA (data 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 DTA (data change) or TER (termination).

Assume that you change the Action value of a July 1, 2005 effective-dated row from PAY (pay rate change) to DTA (data change), and that there is a second, preexisting row with a value of DTA 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 PAY to DTA. 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 DTA), 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 PAY rows, as PAY 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.