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:

Field	Purpose
EMPLID	Iterative triggers are payee-level triggers generated from records that have Employee ID as part of their key structure. The EMPLID identifies the payee affected by the change that generates the trigger. Mass triggers function differently and are not restricted to records that have Employee ID as part of their key structure. See Understanding Mass Triggers, .
CAL_RUN_ID	Identifies the calendar run in which the iterative trigger is processed.
TRGR_CREATE_TS	The system date and time when a trigger is generated (for information only). If you change data so that the same iterative trigger is generated repeatedly, a timestamp is needed to keep the instances unique.
ITER_TRGR_STATUS	Identifies whether the system is processing a trigger. Options are: Canceled: You can cancel a trigger whose status is Unprocessed on the Payee Triggers - Iterative page. In-Process: For triggers that are being considered by the batch process. Processed: For triggers that were processed by the system and can't be reconsidered. Unprocessed: For triggers that haven't been processed by the system.
ITER_TRGR_SRC	Identifies how the iterative trigger is generated. Options are: Batch: For triggers that are generated during batch processing. Online: For triggers that are generated by the online code.
COUNTRY	The country code associated with the iterative trigger.
RECNAME	Identifies the source record from which the iterative trigger is generated.
FIELDNAME	Identifies the field that generates the iterative trigger in response to a data change.
TRGR_FLD_VAL_CHAR	Identifies the character value change that causes the iterative trigger to be generated. This field is not populated if the trigger is defined at the record level only.
TRGR_FLD_VAL_DT	Identifies the date value change that causes the iterative trigger to be generated. This field is not populated if the trigger is defined at the record level only.
TRGR_FLD_VAL_NUM	Identifies the numeric value change that causes the iterative trigger to be generated. This field is not populated if the trigger is defined at the record level only.

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

Field	Purpose/Description
EMPLID	Retroactive (or retro) triggers are payee-level triggers generated from records that have Employee ID as part of their key structure. The EMPLID identifies the payee affected by the change that generates the trigger. Mass triggers function differently and are not restricted to records that have Employee ID as part of their key structure. See Understanding Mass Triggers.
COUNTRY	The country code associated with a retroactive trigger.
TRGR_EVENT_ID	The trigger event ID associated with record, field, or value changes as defined in the trigger setup.
TRGR_EFFDT	The effective date tells the system which pay periods to process retroactively (for example, a retro trigger with an effective date of January 1, 2000 tells the system to reprocess all calendars beginning with the January 2000 payroll run).
TRGR_CREATE_TS	The system date and time when a trigger is generated (for information only). If you change data so that the same retroactive trigger is generated repeatedly, a timestamp is needed to keep the instances unique.
RTO_TRGR_SRC	Identifies how the retro trigger is generated. Options are: Automatic: Identifies triggers that are generated by the online code. Manual: Denotes manually generated triggers. Utility-Generated: Not available.
TRGR_STATUS	Identifies whether the system is processing a trigger. Options are: Canceled: You can cancel a trigger whose status is Unprocessed on the Payee Triggers page. In-Process: Denotes triggers that are being considered by the batch process. Processed: Identifies triggers that were processed by the system and can't be reconsidered. Unprocessed: Identifies triggers that haven't been processed by the system.
TRGR_DESCR	This field serves as the trigger tag or description of a trigger. For use with the Utility-Generated source value.
CAL_RUN_ID	Identifies the calendar run in which the retroactive trigger is processed.
RECNAME	Identifies the source record from which the retro trigger is generated.
FIELDNAME	Identifies the field that generates the retro trigger in response to a data change.
TRGR_FLD_VAL_CHAR	Identifies the character value change that causes the retro trigger to be generated. This field is not populated if the triggered is defined at the record level only.
TRGR_FLD_VAL_DT	Identifies the date value change that causes the retro trigger to be generated. This field is not populated if the triggered is defined at the record level only.
TRGR_FLD_VAL_NUM	Identifies the numeric value change that causes the retro trigger to be generated. This field is not populated if the triggered is defined at the record level only.

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 Retro Page.

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:

Field	Purpose
EMPLID	Segmentation triggers are payee-level triggers generated from records that have Employee ID as part of their key structure. The EMPLID identifies the payee affected by the change that generates the trigger. Mass triggers function differently and are not restricted to records that have Employee ID as part of their key structure. See Understanding Mass Triggers.
EMPL_RCD	Identifies the job affected by a segmentation event.
COUNTRY	The country code associated with the segmentation trigger.
TRGR_EVENT_ID	The trigger event ID associated with a triggering condition, as defined in your setup. It tells the system what type of segmentation to apply and the elements to segment (in the case of element segmentation).
TRGR_EFFDT	The effective date tells the system how to segment a pay period (for example, a segmentation trigger with an effective date of June 15 tells the system to divide the June pay period into two segments, one with the dates June 1 to June 15, and another with the dates June 16 to June 30).
TRGR_CREATE_TS	The system date and time when a trigger is generated (for information only). If you change data so that the same segmentation trigger is generated repeatedly, a timestamp is needed to keep the instances unique.
SEG_TRGR_SRC	Identifies how the segmentation trigger is generated. Options are: Automatic: Identifies triggers generated by the online code. Manual: Denotes manually generated triggers.
SEG_TRGR_STATUS	Identifies whether the system is processing a trigger. Options are: Active: Indicates that the trigger has been written out and will remain active until canceled by a user. Canceled: You can cancel a trigger whose status is Active on the Payee Triggers page.
SEG_TRGR_LVL	Specifies whether a trigger is a payee-level or a payee-job (EMPL_RCD) level trigger. Instructs the system to process for one job only or for all jobs.
RECNAME	Identifies the source record from which the segmentation trigger is generated.
FIELDNAME	Identifies the field that generates the segmentation trigger in response to a data change.
TRGR_FLD_VAL_CHAR	Identifies the character value change that causes the segmentation trigger to be generated. This field is not populated if the triggered is defined at the record level only.
TRGR_FLD_VAL_DT	Identifies the date value change that causes the segmentation trigger to be generated. This field is not populated if the triggered is defined at the record level only.
TRGR_FLD_VAL_NUM	Identifies the numeric value change that causes the segmentation trigger to be generated. This field is not populated if the triggered is defined at the record level only.
TRGR_FLD_VAL_PIN	Contains the PIN number of the element (earning or deduction) that causes the segmentation trigger to be generated. This applies only to triggers that result from an element assignment in the earning/deduction assignment record GP_PYE_OVRD. See Understanding Overrides.

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 Segmentation Page.